Add more flavours for min/common/full about yii2-docker HOT 24 CLOSED

• no DB drivers in -min
• MySQL + PgSQL in -common

from yii2-docker.

How about something like dev branch? Which will be extending base image with the tools which are not likely to be deployed on production like xdebug, asset-plugins, (?)composer, etc

from yii2-docker.

@and800 -dev sounds like it's not stable. But that's not what we mean here. I also think, that you should not use a different image for local development as for production. That's one of the selling points of docker: That you have the same environment everywhere.

from yii2-docker.

How about -experimental?

from yii2-docker.

The names should reflect what they contain, not what they are used for. And our images are not experimental. They are universal and some may even want to use -full in production.

from yii2-docker.

-debug

from yii2-docker.

Maybe we can write what we currently understand under min, common, full...

min

Currently nothing more that PHP itself, example: https://github.com/schmunk42/eucliid

• composer ?

common

Let's say the current images.

• MySQL ?
• PgSQL ?

full

• npm ? (Just an example: Most asset bundling tools are installed via npm, yarn or similar)
• composer plugins ? (hirak prestissimo, wikimedia merge)
• x-debug ?

from yii2-docker.

@rob006 -debug sounds useful. Even if I'm not totally sure: We probably will not use -debug for production, right? But if you have to debug stuff, it's usually because things break in production. So you should debug with the same image. Anyway, we can add it on top of full.

@schmunk42 Hmm, I was more thinking about PHP extensions. If someone needs npm, there are dedicated images for this. We should stay focused on yii and also not include any composer packages. -full doesn't mean we should bloat the image with each and every external tool we can think of :).

• min should be what we have now: Bare minimums, no DB drivers.
• common: MySQL + PgSQL sound reasonable. But I'm sure, whatever we include, people will complain that their driver is missing. But they will always be able to add their own extensions either to min or to common. Apart from DB drivers, what other extensions should go into common?
• full I think, including all extensions is unrealistic. So we need to make choices here too: http://php.net/manual/de/extensions.alphabetical.php
• debug: full + x-debug ?

Given the mass of available extensions I'm not even sure if -full really makes much sense. Whatever we include, something will be missing. So for complex projects developers should build their image extending from our min or common. Should we drop it (and keep debug as common + x-debug)?

from yii2-docker.

@mikehaertl,

But if you have to debug stuff, it's usually because things break in production. So you should debug with the same image

I don't know, whether it is a common practice or only I do things that way, but:

• there is always a common, base, reusable php-fpm image
• in dev environments, it is extended by dev, build, test tools. We can build child image, or mount these tools via volumes, or do it any other way, but: we definitely need that tools. And we definitely not need them in production.
• in production, we want to make deploy process simple and secure, so it is a good idea to extend the base image and put all the source code inside it. Like COPY . /usr/src/app. Also Docker provides ONBUILD commands for it.

So we cannot deal with just the only single image. But despite it we can still keep environments as close as possible by reusing base image. So it may be a good idea to think about the perfect base image, and let devs extend it by anything they want (that would be easy). Or make these additional extended images, too.

But in my opinion, we cannot throw everything in a single image. Maybe we can install composer, as you said in #4, because it's small and cute. But we cannot install most of helping tools, because they are often large and insecure.

from yii2-docker.

I wanna use xdebug, but I don't know how to use and reuse it easily without committing it to docker image. So I would rather violate your suggestion to debug with same image.

from yii2-docker.

What's about adding xdebug to full, but not enabling (loading) it at? FYI: The layer is just about 2MB for xdebug.

We have a separate xdebug flavour of our images at: https://github.com/dmstr/docker-php-yii2 - but it's too much to have an extra image just for that.

About the way to enable them later. We do this currently via an ENV variable: https://github.com/dmstr/docker-php-yii2/blob/master/php-7.1/image-files/usr/local/bin/docker-entrypoint.sh#L16 So it should not be touched at all in production environments.

The discussion about the tools actually start with composer, to me there you start splitting the two ways of building images:

• use tools on the image to build itself (composer + assets, later also less-compiler, minifier, xdebug, bash-editor) - you could argue that it's great to have an image which could be started separately in a production environment with xdebug enabled - 👀
• just use a runtime-time and build the source outside the container - this way you get really small images, without any tools on them - you could arge that it's great to have no additional tools in production ;)

I'd say the former is common and later full, while the latter is min.

from yii2-docker.

So it may be a good idea to think about the perfect base image, and let devs extend it by anything they want (that would be easy).

@and800 That's exactly what I do: I create my custom image in my dev environment. I think that's the most practical workflow. So I agree, most users will always extend from what we have.

@schmunk42 Yes, I think we could even keep composer out of min. I've not checked how much space it eats, but it requires the zip extension and git. So it probably adds some MB. If it's not too much, we could also keep it. But as I always extend my own base images I can add it there, too.

About the other build tools (npm et. al.): I really think, they don't belong into any of our images. composer is an exception as we have a PHP project here. Anything else is project specific. You would rather build a custom image with only those build tools inside (that's what I do). No need to blow up our images with non-PHP stuff.

from yii2-docker.

So, if we have a min Dockerfile and we build a common from that, what do we write into the FROM section?

• FROM yiisoft/php-fpm:latest
• FROM yiisoft/php-fpm:7.1.2
• FROM yiisoft/php-fpm:7.1

Using a version can be cumbersome to update correctly, using latest can give you an unexpected version, if a latest build failed.

Either way we will have to build, test and push first min, then build, test & push common and so on.

This can be done with linked repos on DockerHub or with build-pipelines on GitLab. Any idea how to do this on Travis?

from yii2-docker.

So, if we have a min Dockerfile and we build a common from that, what do we write into the FROM section?

Does -common really have to extend from -min?

Pro:

• If you switch from -min to -common you have shared layers (shorter download time, less disk usage)

Con:

• -common has more layers than neccessary.
• more complexity

Let's keep testing aside for a moment as this is a different topic. It should not affect our choice here. I tend a little more to really build all images from scratch (i.e. from php). The benefit of having a couple of shared layers is IMO neglectible compared to having a clear setup for each image.

Opinions?

from yii2-docker.

common has more layers than neccessary.

The number of layers is not the only thing to care about.

more complexity

Not really, it is also complex or hard to understand which system-packages and PHP extensions belong together.

To add it here, min/common/full is not only about PHP extensions, while all other tools have to be the same.

In my understanding min is a minimalistic runtime image.
We should also consider a usage for the images like builder.

from yii2-docker.

The number of layers is not the only thing to care about.

Right, I didn't say that it's the only thing. It's still something to consider.

Not really, it is also complex or hard to understand which system-packages and PHP extensions belong together.

You can achieve the same by grouping them in the Dockerfile and adding some comments. That doesn't require extending one from the other.

To add it here, min/common/full is not only about PHP extensions, while all other tools have to be the same.

These tools depend a lot on the workflow. To me it's not clear at all that someone using common would have a different workflow than someone using min. That's just another assumption we would make and we should avoid that. It's never a good idea to add diversity just for the sake of it unless it's absolutely clear that it makes sense.

That's why I still think, tooling for all images should be the same to make them coherent.

from yii2-docker.

To me it's not clear at all that someone using common would have a different workflow than someone using min.

Valid point, that's why I brought up the term -builder.

That's why I still think, tooling for all images should be the same to make them coherent.

I absolutely agree.

For me a -common or a custom image from -min (either as base-image or as merged Dockerfile) would start like so:

FROM yiisoft/yii2-php:min
RUN docker-composer-install
[...]

But, if I have another build workflow I could also do this:

FROM yiisoft/yii2-php:min
COPY build-files /

from yii2-docker.

So, if we have a min Dockerfile and we build a common from that, what do we write into the FROM section?

Con: Dockerfile bind to the inner dependence. Not simple rebase (end user). Not simple for understanding (need see into multiply Dockerfile)

I think we must create all of the "official" image from the official image of other team, not from the inner image.
Image must be is crystal сlean, not suspicious.

Layer can be created inside biggest image separated by smallest image (more time for building - install/remove package for each layer, less time to download)
for example: alpine and alpine-xdebug diff: Dockerfile#L85-L98

And I think we need use a ENV for depend a version of package (pecl install apcu-5.1.8 -> pecl install apcu-"$APCU_VERSION")

from yii2-docker.

@mikehaertl Let's decide this one also.

min

• Yii2 runtime extensions
• composer
• OpenSSH, git

common (in addition to min)

• MySQL, PgSQL (PDO)
• fxp

Currently no other flavours. OK?

from yii2-docker.

Again you repeat yourself here, so I can also only repeat myself again: Tooling for all flavours should be the same, because we can't assume different workflows. The only difference should be extensions we add.

At some point I thought you agree to that, but obviously that's not the case.

from yii2-docker.

I repeat myself because I have to, since you're not reading my proposals and comments carefully.

I consider tooling to also cover the installation script, which should be the same everywhere.

I don't really care about the rest anymore.

Do you want

• fxp in -min or
• composer not in -min

?

from yii2-docker.

Those are not extensions - which is the topic here. We discuss composer in #4. Here we talk about which extensions should go into the -min and -common versions.

from yii2-docker.

#34

from yii2-docker.

I think there's currently no need for this, please open a new issue if appropriate.

from yii2-docker.