drupaldocker/php:2.x - roadmap

[zaporylie]

First iteration was a great journey and it helped understand a lot - how Docker works and what are the up- and down-sides when adapting Docker for Drupal projects. This issue is to define what must be done in order to release new major version of this image.
Releasing new major version is always a great opportunity to change architecture of the image in order to mitigate some risks old architecture brings, and get rid off limitations it has.

All the basics must remain the same - we base on official packages and extend them by settings/tools/configs which are universally suitable for Drupal. This was always core principle of this organisation.

If you have objections to the list below - now is the time to step out and say it :)

• Remove all non-alpine images
• Remove all pre-assumed VOLUMEs
• Remove most of the docker tags
• Remove latest tag
• Figure out beter way of -dev images maintenance
• Add test which runs container based on tested image in standard Drupal Docker stack

Few words of explanation:

• Alpine images - people love alpine because it's small and handy. It's time to break every reference we have to debian based images and fully adopt to alpine. NB: That involves removing apache/mod_php versions which do not have their alpine equivalents.
• VOLUME - in order to adopt multi-stage build pattern we must remove VOLUMEs. Multi-stage builds can be very beneficial in our industry, especially for production and production-alike environments (eg. CI) and help us build immutable multi-container environments.
• tags - tags are almost unmaintenable ATM. We must find out better way of tagging versions and releases. I am thinking about fully adopting Add version (release, tag) from Git to Docker Tag #54 with maybe small changes. This is how it looks today:
  
• with latest tag using image is pretty simple, just docker run drupaldocker/php and you're done. However we won't always be able to keep latest image backward compatible. So I see two options here - either encourage people to lock on major version, or remove lates tag and force them to do so
• tests - we must run some actual tests, at least some dead simple ones, to verify not only if image builds but also if it react as we expect it to

Preview:
https://github.com/drupal-docker/php/tree/2.x

[iBobik]

About maintaining tags, how to automate it?

I use automatic reusing of base image tags here: https://gitlab.com/janpoboril/drupal-composer-docker

It uses GitLab CI to mirror tags of base image. Feedback wellcome.