Add mysql-client, openssh-client and rsync to CLI images

[zaporylie]

This way it will be much easier for everyone to use local Drush or Console with custom Drupal project.

[zaporylie]

In ref to https://github.com/drupal-docker/php/issues/67#issuecomment-277732357 @iBobik: I fully support adding mysql-client, openssh-client and rsync to all cli images. However these packages shouldn't be added to apache or fpm images as these images are not meant to be used in CLI mode.

[iBobik]

As I explained, apache or fpm images ARE often used in CLI mode also, because it makes sence in many cases, even in projects based on composer. Separation of webserver and CLI services is also very impractical in cases where app is included in the image.

[zaporylie]

I must disagree. I believe either we're talking about two different things or there's some misunderstanding coming from treating Dockerized environment as traditional LAMP stack.

In Docker-based, multicontainer environment, each container should live as long as it has process to run. In other words you should never run more than one process in a single container. This is one for the most important Docker principles. Taking typical Drupal installation as an example (or vanilla https://github.com/drupal-composer/drupal-project if you prefer) there must be (at least):

• 1x container for MySQL/Percona/MariaDB (deamon - single process) AND
• 1x container for php:apache (apache with mod_php - single process) OR
• 1x container for php:fpm (single process) AND 1x container for apache deamon OR nginx deamon (single process)

You should never perform command-line script execution in existing container (i.e. running docker exec) because it creates additional PHP process and that's direct violation to Docker principle I've mentioned above.

Instead, any invocation of command-line php script should spin up its own php:cli container, and kill it when process terminates.

That is strictly related to another Docker principle I must mention here - containers are (or should be treated as) immutable. It implies that you should never interact with existing container.

Separation of webserver and CLI services is also very impractical in cases where app is included in the image.

Practically you will encounter this problem only for the simplest possible scenario - single container apache with mod_php, no scaling, no nothing ;) Even stupid, so to speak, nginx+fpm will requires volume to share application codebase between these two containers. And once you have that volume, it becomes natural to spin up new container for command-line service (such as backup, etc) using that volume in, preferably, read-only mode.

Of course, I'm referring here to application lifecycle. Development process has its own rules which could never covered by generic drupal-docker/php images, since every project has its own requirements.

If you have your own opinion in this subject, especially if its different than mine, please share it here. I am eager to read more about your needs, routines and visions.

[iBobik]

Thanks for an extensive answer.

I know Docker’s best practice to have one process for one container. But to be correct, this is very rare even in official images where are some more complex daemons (PHP-FPM, Apache, Nginx, MariaDB runs multiple processes in a container).

In my eyes it is not big difference to scenario where Drush will run in app’s container, at least if it is only for dev and debug purposes.

Or running cron. With Drupal’s „poormanscron“ it will run on a webserver like all other requests. Isn’t it the same like to run it by external cron service by curl http://drupal/cron.php?

My use cases for having this executables in the app’s container are:

1. App dependencies are maintained by Composer ran in the build process in CI. It makes no sence to not include Composer inside app image, because without it there building will be much more complex task.
2. In normal daily development we need to run Drush or Console. There is only one instance of everything, so problems about scaling will not happen. For developer is the most handy way to have Drush to just docker exec … into app container.

Jan Pobořil

2017-02-20 22:30 GMT+01:00 Jakub Piasecki notifications@github.com:

I must disagree. I believe either we're talking about two different things or there's some misunderstanding coming from treating Dockerized environment as traditional LAMP stack.

In Docker-based, multicontainer environment, each container should live as long as it has process to run. In other words you should never run more than one process in a single container. This is one for the most important Docker principles. Taking typical Drupal installation as an example (or vanilla https://github.com/drupal-composer/drupal-project if you prefer) there must be (at least):

• 1x container for MySQL/Percona/MariaDB (deamon - single process) AND
• 1x container for php:apache (apache with mod_php - single process) OR
• 1x container for php:fpm (single process) AND 1x container for apache deamon OR nginx deamon (single process)

You should never perform command-line script execution in existing container (i.e. running docker exec) because it creates additional PHP process and that's direct violation to Docker principle I've mentioned above.

Instead, any invocation of command-line php script should spin up its own php:cli container, and kill it when process terminates.

That is strictly related to another Docker principle I must mention here - containers are (or should be treated as) immutable. It implies that you should never interact with existing container.

Separation of webserver and CLI services is also very impractical in cases where app is included in the image.

Practically you will encounter this problem only for the simplest possible scenario - single container apache with mod_php, no scaling, no nothing ;) Even stupid, so to speak, nginx+fpm will requires volume to share application codebase between these two containers. And once you have that volume, it becomes natural to spin up new container for command-line service (such as backup, etc) using that volume in, preferably, read-only mode.

Of course, I'm referring here to application lifecycle. Development process has its own rules which could never covered by generic drupal-docker/php images, since every project has its own requirements.

If you have your own opinion in this subject, especially if its different than mine, please share it here. I am eager to read more about your needs, routines and visions.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/drupal-docker/php/issues/70#issuecomment-281185497, or mute the thread https://github.com/notifications/unsubscribe-auth/AAlfWCYhdXGCFT7OsWLhp8e2x2bpWJ5Wks5regXrgaJpZM4Lsvpf .