ho-nl / docker-development-box Goto Github PK

ERROR: for mysql  Cannot create container for service mysql: failed to copy file info for /var/lib/docker/volumes/12go_mysql-mount/_data: failed to chown /var/lib/docker/volumes/12go_mysql-mount/_data: lchown /var/lib/docker/volumes/12go_mysql-mount/_data: operation not permitted

When removing the var/.mysqldata (because the database has become corrupt) and removing the mysql volume (docker volume ls && docker volume rm <mysql_volume>) the mysql instance can't be started because of the above error.

Workaround

docker-compose down
rm -rf var/.mysqldata
docker volume ls
docker volume rm <mysql_volume from list>
mkdir var/.mysqldata
touch var/.mysqldata/something
docker-compose up -d
rm var/.mysqldata/something
docker-compose up -d

Note: don't stop docker containers before removing the something file.

On some admin configuration pages I get a ERR_HTTP2_PROTOCOL_ERROR. Sometimes this can be solved by clearing the cookies and doing it again, but sometimes that doesn't work.

My current workaround is to disable web/cookie/cookie_httponly in the Magento configuration. This seems to solve the issue for now.

As measured when running a query inside the docker container to mysql we see a network latency of 0.281ms compared to 0.085ms on dedicated server.

go to your mysql container using ctop (exec shell) and run:

mysql -uroot -pmagento

ALTER USER magento IDENTIFIED WITH 'mysql_native_password' BY 'magento';
SET PERSIST log_bin_trust_function_creators=1;
GRANT ALL ON *.* TO 'magento'@'%';

Change in docker-compose.yml:

FPM_PORT: 9074
FPM_XDEBUG: 9174

to:

FPM_PORT: 9072
FPM_XDEBUG: 9172

Switch php back to php 7.2 for cli

brew unlink [email protected]
brew link [email protected] --force

restart docker:
docker-compose down && docker-compose up -d

Currently we automatically map to the xdebug backend based on the XDEBUG_SESSION cookie being set, but not via the query parameter that xdebug also supports as activation trigger (https://xdebug.org/docs/step_debug#manual-init)

Supporting query parameter activation would make debugging things like GraphQL calls (or any API calls) a lot easier

Currently we map based on $cookie_* in our nginx config: https://github.com/ho-nl/docker-development-box/blob/master/nginx/conf.d/default.conf#L2-L5

Changing this to $query is trivial, but we need to combine the two somehow to support both activation mechanisms

Known issue with a workaround (see README.md), but still needs a proper fix; on initial install, PHP 7.2 is broken and php-fpm dervices fail to start.

Root cause of the problem is that the php binary is linked with tidy-html5, but this library is not present during install (maybe we can just install tidy-html5 manually ahead of installing PHP 7.2?), resulting in:

dyld: Library not loaded: /usr/local/opt/tidy-html5/lib/libtidy.5.dylib
  Referenced from: /usr/local/Cellar/[email protected]/7.2.34_4/bin/php
  Reason: image not found

The workaround is to run brew reinstall tidy-html5 afterwards

MailHog geconfigureerd zoals in de README.md, maar lijkt niet te werken (ook niet na activeren mageplaza/module-smtp).

Gaat in mijn geval om de 2FA activation e-mail, misschien dat dat een uitzondering is en wordt die anders verstuurd en komt de rest wel in MailHog, in welk geval dit issue wel dicht kan aangezien 2FA toch uit kan voor development.

Zal dit zelf even verifiëren als ik tijd heb.

fruitcake/magento2-email-advanced-config has proven to be less hassle than the other options for using Mailhog for local e-mail testing

-  # composer require fruitcake/magento2-email-advanced-config
-  # php bin/magento module:enable Fruitcake_EmailAdvancedConfig
+  # composer require magepal/magento2-gmailsmtpapp
   # php bin/magento setup:upgrade
   # bin/magento config:set --lock-env system/smtp/disable 0
-  # bin/magento config:set --lock-env fruitcake_email_advanced/smtp/transport smtp
-  # bin/magento config:set --lock-env fruitcake_email_advanced/smtp/auth none
-  # bin/magento config:set --lock-env fruitcake_email_advanced/smtp/ssl none
-  # bin/magento config:set --lock-env fruitcake_email_advanced/smtp/host localhost
-  # bin/magento config:set --lock-env fruitcake_email_advanced/smtp/port 1025
+  # bin/magento config:set --lock-env system/gmailsmtpapp/active 1
+  # bin/magento config:set --lock-env system/gmailsmtpapp/auth NONE
+  # bin/magento config:set --lock-env system/gmailsmtpapp/ssl none
+  # bin/magento config:set --lock-env system/gmailsmtpapp/smtphost localhost
+  # bin/magento config:set --lock-env system/gmailsmtpapp/smtpport 1025

Project 1:
Sightful/src
Project 2:
Foreyes/src

All of the project files are located in the src folder which causes the local mounts to be prefixed with "src_" . This means that multiple projects will have to use the same src_mysql-mount and src_nginx_mount. You will have to manually remove the mounts from project 1 to start project 2.

When running docker-compose up

Creating volume "src_nginx-mount" with local driver ERROR: Configuration for volume mysql-mount specifies "device" driver_opt :/Users/billydegraaf/Sites/foreyes/src/var/.mysqldata, but a volume with the same name uses a different "device" driver_opt (:/Users/billydegraaf/Sites/Sightful/src/var/.mysqldata). If you wish to use the new configuration, please remove the existing volume "src_mysql-mount" first: $ docker volume rm src_mysql-mount

Without a named volume, you end up with a lot of extra volumes that are no longer used, as a new one is created each time you start the service. (These can be cleaned with for example docker volume prune

We should use a named volume instead so it is reused

• Vanmoof 12s vs 3s on configurator page.
• Waardijk ~3s vs 1.5s on category page.

Install werkt niet als oude php versie er nog is. Ik moest perse een "brew reinstall php-versie" doen anders klopt het path voor de nieuwe ini locatie niet.

It seems we're missing the php intl extension

Check which extension are required with Magento and install them as well.

@paales is er een reden dat custom php files niet gebruikt kunnen worden voor lokale development?

Automatically set up node + nvm locally + https://stackoverflow.com/questions/29653036/automatically-switch-to-correct-version-of-node-based-on-project

Ik kreeg deze error tijdens de install script https://raw.githubusercontent.com/ho-nl/docker-development-box/master/install.sh:
dyld: Library not loaded: /usr/local/opt/openssl/lib/libssl.1.0.0.dylib

Dit fixte het voor mij

brew uninstall --ignore-dependencies openssl
brew install https://github.com/tebelorg/Tump/releases/download/v1.0.0/openssl.rb

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

No Slack web-hook defined.

A Slack Webhook must be created and set in the SLACK_WEBHOOK environment variable on your CI environment.

Please make sure to create a Slack Webhook and to set it in the SLACK_WEBHOOK environment variable on your CI environment. Alternatively, provide slackWebhook as a configuration option.

Good luck with your project ✨

Your semantic-release bot 📦🚀

We want this:

Create a new Major 3.x.x release to support Magento 2.4? Keep Magento 2.3 on docker-development-box 2.x.x?

• Advise PHP 7.4 as default in the README
• MySQL 8.0 requires the latest mysqlclient (#37)
• MySQL 8.0 requires different configuration, make configuration compatible with old version.
• ElasticSearch 7.6
• Keep branch for Magento 2.3 that can receive new features or fixes, but no breaking changes

When static content is running in developer mode the system creates symlinks, but those symlinks are absolute. That wont work for static assets served over nginx. The patches change the the symlinks to relative.

mysqldump: [Warning] Using a password on the command line interface can be insecure.
mysqldump: Couldn't execute 'SELECT COLUMN_NAME,                       JSON_EXTRACT(HISTOGRAM, '$."number-of-buckets-specified"')                FROM information_schema.COLUMN_STATISTICS                WHERE SCHEMA_NAME = 'magento' AND TABLE_NAME = 'admin_analytics_usage_version_log';': Unknown table 'COLUMN_STATISTICS' in information_schema (1109)

This prevents executing database dumps with n98-magerun2 on your local machine.

Xdebug not working for PHP7.2. Have to use Xdebug 2.7.0alpha1

It seems that requests are cached and not updating on the website when a file is edited, even though CMD+SHIFT+R. Due to Nginx micro caching? Sync issues with Nginx?

Inspired by https://github.com/wodby/docker4drupal, a similar project but for Drupal, it would be nice to have a Makefile that facilitates some common tasks while developing.

Some of the shortcuts that the Makefile provides (via the referenced file docker.mk) are:

• start
• stop
• help
• open a ssh session
• run drush commands (we could run php bin/magento commands and n98-magerun2 too)

As mentioned in #17, this file could be a good place to have startup/shutdown commands, for example.

Currently "Project installation" assumes there is no project yet and new developer can get confused.
Add a section called "Project installation for already existing project" in which these steps are only needed:

- Install this in the current project: `composer install`
- Update or create an env.php file and with the following info 'host' => '127.0.0.1', 'dbname' => 'magento', 'username' => 'magento', 'password' => 'magento',

Needed for the 2.3x and 2.4x branch.

In the README it's suggested to execute:

curl -s https://raw.githubusercontent.com/ho-nl/docker-development-box/master/install.sh | bash -s -- -i

There is no validation of the remove script. It's a best practice to avoid somebody from impersonating/replacing the script that will do crucial system tasks.

References:

• https://superuser.com/a/498940/87723
• https://optimalbi.com/checking-a-checksum-cryptographic-hash-function-with-powershell-and-bash-shell/

Varnish is configured differently in the development box vs code

Magento should provide proper cache-control headers, else Varnish will over-cache.

cache-control: max-age=86400, public, s-maxage=86400

Should be

cache-control: max-age=20, public, s-maxage=86400

Mysql did not start. Had to give write permission to the folder:
chmod -R g+w var/.mysqldata

Having to keep two branches up to date with install.sh en README.md changes is a bit of a hassle (or more importantly: we just forget to keep them updated). Since (I think?) the only difference between the branches is having to apply a different static content patch (depending on M2 version), I propose we just handle this by having only a main branch with the two patches in the repo with appropriate instructions in a single unified README

https://www.docker.com/blog/docker-desktop-3-0-0-smaller-faster-releases/
https://docs.docker.com/docker-for-mac/release-notes/#docker-desktop-community-2500

We are currently on Docker 2.1.x.x because performance from host to container has way lower latency.

After the switch to the shivammathur/php brew tap, we install all php-fpm services with the version in the service name. Before, we installed a php-fpm service without version included, which always ran the latest available PHP version from brew (which back then was PHP 7.4, but currently is PHP 8.1).

Because this service is not removed/cleaned up currently by the install.sh script, it will still attempt to start and listen on port 9074, causing one to (depending on which service happens to start first and listen on port 9074) unexpectedly run PHP 8.1.

• Ensure install.sh script cleans up legacy service

After installing PHP with the installation script, the execution of Magento is still very slow - without observing any bottleneck in the usage of resources.

The logs are full of entries like this:

==> /usr/local/var/log/php-fpm.log <==
[26-Aug-2020 12:56:21] ERROR: unable to bind listening socket for address '127.0.0.1:9072': Address already in use (48)
[26-Aug-2020 12:56:21] ERROR: FPM initialization failed

And killing the PHP process does not help, the errors appear almost instantly:

==> /usr/local/var/log/php-fpm.log <==
[26-Aug-2020 13:13:43] NOTICE: fpm is running, pid 14034
[26-Aug-2020 13:13:43] NOTICE: ready to handle connections
[26-Aug-2020 13:13:53] NOTICE: [pool www] 'user' directive is ignored when FPM is not running as root
[26-Aug-2020 13:13:53] NOTICE: [pool www] 'user' directive is ignored when FPM is not running as root
[26-Aug-2020 13:13:53] NOTICE: [pool www] 'group' directive is ignored when FPM is not running as root
[26-Aug-2020 13:13:53] NOTICE: [pool www] 'group' directive is ignored when FPM is not running as root
[26-Aug-2020 13:13:53] ERROR: unable to bind listening socket for address '127.0.0.1:9072': Address already in use (48)
[26-Aug-2020 13:13:53] ERROR: unable to bind listening socket for address '127.0.0.1:9072': Address already in use (48)
[26-Aug-2020 13:13:53] ERROR: FPM initialization failed
[26-Aug-2020 13:13:53] ERROR: FPM initialization failed

• Add php here https://github.com/ho-nl/docker-development-box/blob/master/install.sh#L4
• Move to a pecl install? https://github.com/ho-nl/docker-development-box/blob/master/install.sh#L93-L98
• Upgrade Xdebug to version 3.0 https://xdebug.org/docs/compat
• Add the correct directory for php 8.0 xdebug https://github.com/ho-nl/docker-development-box/blob/master/install.sh#L126

@paales Ik probeer 12Go M2 te updaten naar 206, maar hou nog steeds MySQL problemen, moet ik nog iets meer doen dan alleen maar package updaten en opnieuw opstarten?

( ! ) Fatal error: Uncaught PDOException: SQLSTATE[HY000] [2002] Connection refused in /Users/maikelkoek/Sites/project-12gobiking-m2/vendor/magento/zendframework1/library/Zend/Db/Adapter/Pdo/Abstract.php on line 144

Originally posted by @Maikel-Koek in #29 (comment)