-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implementation of the Docker environment #833
Conversation
docker/php/Dockerfile
Outdated
RUN \ | ||
curl -sS https://getcomposer.org/installer | php && \ | ||
mv composer.phar /usr/local/bin/composer && \ | ||
composer global require "hirak/prestissimo:dev-master" --no-suggest --optimize-autoloader --classmap-authoritative |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not needed IMO. Flex already optimizes the downloading of packages to do it in parallel (and it might now play well with hirak/prestissimo
if they both try to do it)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You were right! It's no longer needed with the next version of Composer. I've tested with 1.7.0-RC when I saw the announcement and the time spent to install dependencies is exactly the same with or without hirak/prestissimo
.
Makefile
Outdated
## | ||
|
||
composer: ## Install Composer dependencies from the "php" container | ||
$(DOCKER_COMPOSE) exec php sh -c "composer install --optimize-autoloader" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if it's a good idea to add --optimize-autoloader
as an option since it's not recommended to enable it in a dev environment https://getcomposer.org/doc/articles/autoloader-optimization.md
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From my understanding, there is no real issue with --optimize-autoloader
as its purpose is to generate a classmap file to avoid filesystem checks. A thing quite interesting in term of performances while you are using OPcache.
If a class is not present in the classmap, the autoload will still request the filesystem to load it. You can find more details a little bit further in the documentation you linked (https://getcomposer.org/doc/articles/autoloader-optimization.md#trade-offs).
The |
I've tested this and i's great! I tested most of the A minor comment: the first-time installation was too long because I think it compiled PHP. If this is true, could we instead install a minimal PHP binary for a modern PHP 7.2 version instead of building it from source? Thanks! |
@javiereguiluz It doesn't compile. Docker has to build all required images before the application could be started. For the very first run this build takes quite some time as no layer exists in the cache yet and all needed PHP packages have to be downloaded (think of |
I'm afraid my experience was different than this. I have literally thousands and thousands of compiling lines like this:
Is there a way to have PHP extensions precompiled? Also, can we check if we are installing just the minimum number of extensions needed to run this app? Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A minor comment: would a h2-proxy service not be relevant?
Hi @javiereguiluz, and thanks for your feedbacks! As @frastel nicely explained, what you see is the "image build process" performed by Docker when required cache layers are not available your local machine. This is completely normal to have thousands of lines during that step:
The Here is the list of PHP compiled modules.
Finally, I made some additional adjustments to reduce the installation time (from ~4:20m to ~2:35m) by removing the assets compilation (already present in the repository) and moving to the preview version of Composer (to take advantage of the latest improvements). @maxhelias : I don't think a h2 proxy is required here, but I let @javiereguiluz answer. 😉 |
.env.dist
Outdated
@@ -10,9 +14,9 @@ APP_SECRET=67d829bf61dc5f87a73fd814e2c9f629 | |||
|
|||
###> doctrine/doctrine-bundle ### | |||
# Format described at http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/configuration.html#connecting-using-a-url | |||
# For a sqlite database, use: "sqlite:///%kernel.project_dir%/var/data.db" | |||
# For a sqlite database, use: "sqlite:///%kernel.project_dir%/var/data.db?charset=utf8mb4" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utf8mb4
does not make sense for sqlite AFAIK. That's a MySQL thing
docker/php/Dockerfile
Outdated
RUN \ | ||
curl -sS https://getcomposer.org/installer | php && \ | ||
mv composer.phar /usr/local/bin/composer && \ | ||
/usr/local/bin/composer self-update --preview |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
all that can be simplify: curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer --preview
(and this will avoid downloading the phar twice)
Ubuntu: tried to run phpunit - inside php container everything OK, running
|
Do you have additional questions or concerns? If it's good enough for you, I'll start to write a small documentation. |
I'm sorry this PR stalled. I was waiting for more approvals from Docker experienced users. May I ask why did you close it? Note that we're still super interested in having Docker enabled for this repo. Thanks! |
I closed it for several reasons. 😉
Long story short, that's not a renouncement as I'm still looking for the best solution. |
Here is a first implementation of what has been requested in #802.
I made the pull request earlier in order to receive your feedbacks about the design itself. The documentation still has to be updated. Basically, I took the decision to create something very simple (SQLite without HTTPS) and that can be used to test Symfony by directly editing the project.
The installation process is currently composed of three steps:
git clone [email protected]:ajardin/demo.git symfony-demo
cd symfony-demo
make install
And that's all! The browser will be automatically open once the application is ready.
@javiereguiluz, could you have a look at this and tell me what you think?