mcneely / php-skeleton Goto Github PK

https://github.com/mcneely/skeleton/blob/f5a862e7bc739df0b70557e2ec992fd08a0f665f/.docker/apache/Dockerfile#L8-L11

while not necessarily a "bad practice", managing configuration inside a dockerfile is a bit obfuscated, consider either copying the configuration into it during the build, or doing these actions at runtime in entrypoint.sh

consider using LE for cert management, and some sort of proxy/lb on the front end to manage your projects. assuming you have more than one running at any given time this will get complicated. the company I work for does both, and works well with docker-compose/swarm. (this also works really well with something like ngrok.io where you can have domains live on the internet tunnel'd to your local machine)

also, highly recommend looking into using monitoring tools on your projects. xdebug is great for local, but how are your services running in prod? look at extending your apps with stuff like prometheus and jaeger. yes, those things get hard running at scale, but by that point you hopefully have budget to go with a managed solution like datadog or whatever.

overall, nice work, seems like it has helped you manage both your development workflow and production environments, which is the whole point, rite?

https://github.com/mcneely/skeleton/blob/f5a862e7bc739df0b70557e2ec992fd08a0f665f/.docker/php/fpm/Dockerfile#L7-L17

this one is tricky, mainly because you need these dev/buildtools in order to compile. take a look around at other fpm/php dockerfiles for the usage of multi-stage builds - which allow you to build another image after you compile in the first one, copy the binaries/objects you need, and install just the runtime dependencies. you'll likely see a large (20-40%) reduction in image size.

https://github.com/mcneely/skeleton/blob/f5a862e7bc739df0b70557e2ec992fd08a0f665f/.docker/apache/Dockerfile#L3

in the event you change your entrypoint, this would trigger a full rebuild