You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Could you explain a bit why Composer has its own Docker image? Is it best practice to use official Composer's Docker image instead of manually installing Composer to my custom php:fpm image? Any benefit? In this case, I need to share my PHP-FPM environment with the composer image in order to use Composer as a standalone container. is it a good idea to duplicate my php.ini config for PHP-FPM with Composer? I'd love to hear any thoughts about it.
I also think it would be nice to have the answer to these questions in the readme file of Composer's Docker image.
The text was updated successfully, but these errors were encountered:
Composer does not need php-fpm, it only needs the cli binary.
I am not sure what to answer to your question. This image simply serves as a minimalistic docker container that can run composer (and nothing else).
In regards to, "what is best practice", it really depends on what you accept as the definition of "best practice". We are not here to tell you what the "best practice" is. We merely try to keep our image in line with general Docker best practices.
Ah, you probably misunderstand me a bit. Let me explain with a simple example.
I have an application which consists of a few containers: nginx:latest and php:fpm. So my question is should I prefer to add the standalone Composer container based on composer:latest in my Docker workflow or better to install Composer manually right to the php:fpm container since I already use it?
I think you could help with it because I believe you based on some good use cases when created Composer Docker image :)
Entirely up to you. The Composer image will likely not contain extra extensions you might need. Also it is based on PHP 7 and the Alpine distro. Whether or not this is an issue, depends on your use case. The readme on the docker hub mentions this caveat also and possible work-arounds. Worst case scenario, it does not fulfill your use-case, you can just copy the install instructions from our Dockerfile :-)
Could you explain a bit why Composer has its own Docker image? Is it best practice to use official Composer's Docker image instead of manually installing Composer to my custom php:fpm image? Any benefit? In this case, I need to share my PHP-FPM environment with the composer image in order to use Composer as a standalone container. is it a good idea to duplicate my php.ini config for PHP-FPM with Composer? I'd love to hear any thoughts about it.
I also think it would be nice to have the answer to these questions in the readme file of Composer's Docker image.
The text was updated successfully, but these errors were encountered: