Fixing user permissions is very slow
Running any command when UPDATE_UID_GID is set takes orders of magnitude more time, once Magento is downloaded and installed:
> time docker-compose run --rm cli echo "Done"
Starting magento2environment_appdata_1
Starting magento2environment_dbdata_1
Updating www-data uid and gid
Docker: uid = 501, gid = 20
Incumbent: user = , group = dialout
Xdebug is enabled
You are running composer with xdebug enabled. This has a major impact on runtime performance. See https://getcomposer.org/xdebug
Running composer as root/super user is highly discouraged as packages, plugins and scripts cannot always be trusted
You are running composer with xdebug enabled. This has a major impact on runtime performance. See https://getcomposer.org/xdebug
Running composer as root/super user is highly discouraged as packages, plugins and scripts cannot always be trusted
Done
real 1m34.164s
user 0m0.402s
sys 0m0.180s
The shell output just hangs at the Incumbent line, probably trying to enumerate every file in Magento and update the permissions on it.
This has now been confirmed on multiple environments.
I've experimented with not mounting the entire magento directory, which has worked pretty well so far. By not mounting Magento we no longer need to manage permissions which eliminates this issue completely.
To implement this, I modified by docker-compose.yml so that only my code is mounted (in my case it was the extensions dir of the meanbee/magento2-environment setup). I made sure /var/www/magento is defined as a volume on appdata to ensure the files persists. My current.env will then had UPDATE_UID_GID=false (I'd propose removing this functionality completely though of course).
We can use docker cp to copy the files locally so that they are available for our IDE. But, the problem is when new extensions are installed, or code written that depends on generated code (located in var/generation within the magento root), you would need to re-sync each time. We would also want the re-sync anytime composer dependencies change too.
I think using docker cp to copy the files is a good trade off, considering the performance benefit. However, it would be interesting to investigate the potential of other solutions like docker-unison, not sure if that's the right fit, but certainly worth trying (it doesn't need to be a 2 way sync imo, just getting the files from the container and keeping them up to date would be suitable)
Documentation would have to be updated for this across repo's (including the meanbee/magento2-environment), and other clients.
Played around with unison, doesn't appear to solve the permission issue. I'm sure it makes file reading/writing faster. But permissions are incorrect which Magento whinges about. I fear we'll still run into slowness by resetting permissions, which is a pain when starting up our containers or running cli tools.
I'm left with two ideas:
- Document how to copy files locally (once on install to copy everything, then you'd need to run it fetch
var/generationandvendorfolders anytime they may have been updated). We would then remove the mounting of./magentoand instead specifically mount./magento/app. - Create an rsync container. It would attach to the
appdatavolume, and sync files from/var/www/magentoto somewhere else in the container that can then be mounted. This way we receive updated files locally, and updated files locally are added toappdatavia mounting./magento/app.
Thoughts?