-
-
Notifications
You must be signed in to change notification settings - Fork 202
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add more flavours for min/common/full #7
Comments
How about something like |
@and800 |
How about |
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 |
|
Maybe we can write what we currently understand under minCurrently nothing more that PHP itself, example: https://github.com/schmunk42/eucliid
commonLet's say the current images.
full
|
@rob006 @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.
Given the mass of available extensions I'm not even sure if |
I don't know, whether it is a common practice or only I do things that way, but:
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. |
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. |
What's about adding We have a separate 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
I'd say the former is |
@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 About the other build tools (npm et. al.): I really think, they don't belong into any of our images. |
So, if we have a min
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? |
Does Pro:
Con:
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 Opinions? |
The number of layers is not the only thing to care about.
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 |
Right, I didn't say that it's the only thing. It's still something to consider.
You can achieve the same by grouping them in the
These tools depend a lot on the workflow. To me it's not clear at all that someone using That's why I still think, tooling for all images should be the same to make them coherent. |
Valid point, that's why I brought up the term
I absolutely agree. For me a
But, if I have another build workflow I could also do this:
|
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. 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) And I think we need use a ENV for depend a version of package ( |
@mikehaertl Let's decide this one also. min
common (in addition to
|
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. |
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
? |
Those are not extensions - which is the topic here. We discuss composer in #4. Here we talk about which extensions should go into the |
|
I think there's currently no need for this, please open a new issue if appropriate. |
To provide better support for different DBMS and other PHP extensions how about creating different package levels? We could have the following flavours:
-min
(or no suffix) only contains the bare minimum (what we have now)-common
contains the most common extensions and DB drivers-full
contains almost all extensions and DB driversEach handled by a dedicated
Dockerfile
e.g.Dockerfile.full
in the respective directory. The final images would then becomeyiisoft/yii2-php:7.1.2-apache-common
.Of course this now opens the box for endless discussion: What is part of "common" and what is part of "full".
The text was updated successfully, but these errors were encountered: