Do different development and production environments break the Docker concept?

Question

Web development

The point of docker is to do everything 1 in 1 as in production, but while you are developing, you need to connect php.ini-development, not production. xdebug. Composer. NodeJs is needed to compile resources. Forward the local user so that there are files in the volume not from under the root.
You don't need any of this in production.
It turns out different docker-composes, different Dockerfiles (although I heard about multi-stage, yes), different forwarded configs? Have an example of a well-written boilerplate php application with docker?

Answer 1

The dev environment almost never has the same image as the prod one. But docker allows you to get very close to the production using inheritance. That is, prod is inherited from, say, php:7.3.3-fpm, installs the necessary modules and php.ini options, and the dev image is inherited from prod and installs xdebug, composer, node, modifies only the php.ini options necessary for the dev.
Such an organization allows you to almost not spend time updating the dev image. Prod has changed - dev has also been rebuilt into one command. Very comfortably.
The root of the entire hierarchy will be this base prod image, which does not contain any project files. dev and images with a packaged application are already inherited from it. Mount the working directory of the project into a container based on the dev image and work as you like.
The inheritance hierarchy looks something like this:

php:7.3.3-fpm
└─ prod:base
   ├─ dev:latest
   ├─ prod:0.0.1
   ├─ prod:0.1.15
   └─ prod:1.0.4
      └─ prod:latest  (плавающий тег, указывающий
                       на самый свежий релиз)

With this approach, you will have 3 dockerfiles - prod:base, dev and final prod.
You can get by with two docker files if you put project scripts on the prod via volume, as in dev. I just use this option, since my company uses continuous delivery. Roughly speaking, this is when almost every commit in master immediately flies to the production. If you build a new image each time, there are too many images that you have to separately monitor and remove old ones to avoid overflowing the registry. Plus, there are difficulties with ensuring the atomicity of the deployment, since the service becomes unavailable at the moment the container is restarted, which is why balancing and / or blue-green deployment has to be fenced.
With volume, everything is simple - fill it with new code, switch the symlink and you're done. And the base image changes relatively infrequently - usually when a new version of PHP comes out. In this case, you can also manually update the base image on the server. But this option is only good when there are few servers. For large clusters, of course, the option of packing the application into a separate image works better.