search

codemix / yii2-dockerbase

Yii 2 base image for dockerized yii2 projects
39 stars 22 forks source link

Join forces building a PHP base-image for Yii? #6

Closed schmunk42 closed 7 years ago

schmunk42 commented 7 years ago

If you want to I'd contribute our base-image stuff under the codemix namespace.

@mikehaertl While we may not create the same applications from it ;) this would still make sense. Let me know if we should start a discussion or work on this.

We're nowadays almost only using alpine without any Yii packages on the base image, but that would be a subject to be discussed, we're still building several other images...

mikehaertl commented 7 years ago

@schmunk42 Sure, if it makes sense, why not. After almost 2 years I also considered to reorganize things a little. For sure there are some arguable design decisions here - most depend on personal preference of the developer (i.e. me ;) ).

Can you explain a bit more, how this could look? And which features you'd like to merge? (If merging things here is what you meant...)

schmunk42 commented 7 years ago

I'll try to summarize:

The fpm+nginx combo is almost identical.

We're both creating a base image (runtime) for Yii2 from the official php image, along with the asset plugin & a global codeception installation. We were also installing a Yii application, but dropped that since the prestissimo plugin does a perfect job here, regarding development speed & reliability. That would be something to think about.

We're building images with GitLab, so it would be nice to have a config for that, totally optional feature. Images can be build anywhere, but GitLab allows us to build several versions and flavors automatically. We're also running some basic tests before images are pushed.

Another thing to think of is that Codeception could be removed, but on the other hand it would be nice to have a x-debug setup for coverage tests, which would lead to the question if we build a production and dev image...

WDYT?

mikehaertl commented 7 years ago

There are so many decisions to be made - and many of them are debatable forever :). There's only one core principle that is paramount to me: Try to keep it simple! (i.e. the image should be "purist friendly" :smile:).

It my sound weird, but I wonder if it makes sense to include any yii2 packages at all. For me there are two main directions this image can take:

  1. Include Yii2 composer packages as we already do now. Implications:
    • For this to make sense, we moved the vendor/ directory to /var/www/vendor/ to not have it overwritten when you mount your local app directory. I think we'd have to keep this setup - or what sense does it make to bundle yii2 if you'd overwrite it anyway when you build your actual app image?
    • We always have to decide, how often we rebuild the images, e.g. should we create a new image if there's no new Yii2 release, but maybe yii2-bootstrap was updated?
    • We get many permutations for all combinations of PHP version + Yii2 version. Quite cumbersome to maintain.
  2. Provide only the crucial PHP runtime environment for Yii2. Concrete Yii2 projects would then extend from this image and could install the Yii2 version they like. This basically solves all the problems of 1) above. But then again: does the image make much sense at all anymore?

I'm really not sure yet, what's the best approach. But maybe 2) is really something to consider.

More random questions:

There's for sure much more to discuss.

mikehaertl commented 7 years ago

As I've brought up the heretic question, if our base image makes sense at all, I had a look at the collection of official images:

https://github.com/docker-library/official-images/tree/master/library

Apart from rails, I can't find any framework related images there. But even that now has a deprecation note:

For most usages of this image, it was already not bringing in rails from this image, but actually from your project's Gemfile, so the only "value" being added here was the pre-installing of nodejs, mysql-client, postgresql-client, and sqlite3 for various uses of the rails framework.

This pretty much is also true for any base image we could build for Yii2.

We could say: "But we can optimize the image for Yii2, for example add Nginx tweaks!". That's what you do here for example. But that's also very debatable: Not everyone needs/wants these same optimizations. IMO this rather belongs to the official php-fpm base image. If they don't include this, we shouldn't either. If someone needs this, they can do so when they build their app image from our base. We should not make assumptions like "what's good for my setup is good for everyone". It's probably not.

But keeping things as "pure" as this - our image again is very poor and adds not much real value. Hmm.

schmunk42 commented 7 years ago

@mikehaertl Thanks a lot for the feedback!

I'm really not sure yet, what's the best approach. But maybe 2) is really something to consider.

We're going with this since a while and it's working pretty well. We had the core Yii Framework files on the image, but that was mainly for faster builds. We solve this now with hirak/prestissimo.

As a sidenote, we're currently adding codeception to the base-image, but I think we will remove that, would be just consequent. The reason behind that is that we wanted to limit the amount of packages installed, because of the (formerly) slow asset-plugin, but this is already vastly improved. More below...

If we stick with 1) above, how should we deal with new PHP releases?

I would like to have something similar to the official images, like having latest, 7, 7.1 and 7.1.1 also with different flavours like fpm, apache and so on, but that's a lot of work to setup, test and maintain. I think we have to go with a few versions first.

I know this is a tough one for you as you're emotionally invested 😬 : Should we move to asset-packagist? [...]

No :) Or at least wait for the outcome of https://github.com/fxpio/composer-asset-plugin/pull/278#issue-209950381 I fear that it might raise other issues, for details see https://github.com/yiisoft/yii2/issues/8688#issuecomment-242099524

I also don't want to include all kind of fancy config tweaks that make c-a-p cache stuff, just to make composer usable again

About the config "tweaks" ... what, if those settings would be the default? :) There are upcoming changes, which allow settings this via ENV variables, so this could be done in the base-image and you wouldn't have to care about it in your project. It would be "just" a preconfigured environment. Anyway, let's postpone this for now :)

Removing codeception is really to consider. [...]

Yes, because also Codeception updates rather often introduce minor breaks.

We're still using manual builds with docker hub [...]

An issue with Docker Hub is that builds are not really flexible, that's why we are building the images with GitLab. Private in our case, but this can also be done on gitlab.com with free runners or even with dedicated runners - which is far more stable than Docker Hub or Travis CI. We can provide these resources.

See also

We are already having a pretty complex pipeline there, not necessarily a good thing - it should be simplified - but it gives you a few nice options, more below....

Add more DB drivers

I've added postgresql support to our images, because we received several issues about it. But I would not add more. I also played around with other db drivers for building the dockerized testing setup of Yii2 and it was a huge pain!

Basically, my goal would be to have an image as minimal as possible where Yii's requirement checker shows no warnings, see also https://git.hrzg.de/dmstr/docker-php-yii2/builds/79670

As a benchmark: https://github.com/schmunk42/eucliid - a 63 MB Yii 2 CLI application. Actually directly built on alpine, I wonder a bit why this is running 💃 😄

But there are other tools more essential to me, like asset bundlers or xdebug, like an additional -debug or -development flavour. I.e. you could develop with images built from the -development images and use the minimal image during tests and release builds.

Those could also be build from separate repos, but on the other hand, you download a base image just once, and there's always a tradeoff between different aspects. I'd go with the 80/20 rule here. It's just about working out-of-the-box with sensible defaults.

What's about a goal of less than 100 MB 👍 We're currently at 117 MB zipped size

A measurement for me would be, that all Yii 2 framework tests except platform-specific and db tests run from the image.

so the only "value" being added here was the pre-installing of nodejs, mysql-client, postgresql-client, and sqlite3 for various uses of the rails framework.

That's actually a high value to me ;)

About the enabled gzip, yes debatable ... I actually don't mind the value, there just needs to be a documentation how to customize it, see https://github.com/dmstr/docker-php-yii2/issues/8

About the heretic question ... we're building a Yii2 flavor of PHP, which means that you can use the vast majority of the framework without having to think about what to install. Take APC, APCu or xdebug versions for example and especially installing system libraries in a minimal way. There are so many more things ... composer auth-token, composer ENV settings, permissions, etc...

To me the base image should be also "production-grade" (subject to definition) For example, I recently ran Docker Cloud security scans against an updated PHP alpine image and it should feasible to pass those.

It's all about the things we're discussing here, from design over building, configuration, customization and so on. Even more, like using it with host-volumes, other services in Yii context like Redis, ...

And we're already building those 😸 so there's a need for it.

CC: @handcode @Quexer69

mikehaertl commented 7 years ago

After more thinking I came the conclusion that there are really only two options that make sense:

  1. Have no public base image at all and build bespoke base images for each of your yii2 applications
  2. Have a very lightweight base image, close to the official PHP flavours that only include the absolute basic yii2 requirements (i.e. PHP extensions)

Anything else is making too many assumptions about the usage scenario of such an image. This is something we simply can't know. There's no "one size fits all". Whatever you include in the base image, almost any moderately complex project will have different dependencies for PHP extensions. The alternative would be to include everything - which is also a no go.

Including only mysql and/or postgresql as you proposed is just another assumption about what most users will need. This may help the newbie - but to put it frankly: That's not really the target audience I have in mind here.

To make everyone happy, how about this: Let yiisoft provide these PHP images! As they would only contain the most crucial extensions there's not much to debate about. And as we simply have to build one image per PHP docker flavour it's also pretty easy to maintain.

Pros:

Cons:

What do you think? Should we talk to the core devs? We could even propose to take care of maintenance.

schmunk42 commented 7 years ago

I agree with all of your statements, because even a minimal base-image, eg. without any db-driver at all would be better than nothing ;)

Will close this one and open a new one at yii2.