Thank you for sharing this great and detailed post, it really helped me.
I've have just a question as I am bloody beginner here: You are combining PHP and NGINX into one container. Until now, I always tried to avoid this by following the one function per container principle.
Especially if you want to scale the application you will scale NGINX as well, which might not be necessary. Is there es special reason why you go this way and do not use a separate container for NGINX?
Experience in Software and DevOps Engineering, with an in-depth interest in technology. Outside of work, I find joy in savoring a cup of coffee, music, and spending time with dogs and guinea pigs.
I use both ways, but here is what I usually try to consider before doing one way or the other. I usually like to analyze the context of the teams and projects. Decouple NGINX can make your container smaller or make your container use a little less hardware, but it's not necessarily the simplest or the easier or the safest way to go through, specially if you have a few projects.
In my opinion decouple NGINX from PHP it makes sense when in your context your team has a good understanding of containers and minimum knowledge of server architecture or if you have a significant number of microservices, and you explicitly want to use NGINX as a reverse proxy to upstream requests to the containers.
But if your reverse proxy runs in a single container you will be creating a single point of failure and if your container goes offline even for a few seconds all of your container will be offline and this may cause problems, specially if you have a high volume of requests/transactions, with NGINX embedded with the application container you don't have the proxy created by you in the middle of the request process removing this single point of failure.
Also, the technology being used to manage the container will influence in your decision as well, let's take AWS ECS and AWS EKS as example:
If you choose to run your containers using ECS it doesn't matter that much if NGINX is, or it isn't, embedded in the container image because ECS is a simpler cluster abstraction that accept both ways, and you could suffer with problems that I've described above.
But if you are running your containers on EKS it may be preferable to not have NGINX because Kubernetes has the ingress controller "component" tight to the cluster, the ingress controller is a special implementation of NGINX, so you could just configure the upstream and your proxy would be running and in this case, we don't have a single point of failure because if the ingress controller stop working the entire cluster would go offline, so it's not a problem of how you architected your infrastructure but a problem with a piece of your infrastructure.
Finally, I would like to reinforce that I don't discourage anyone to try to remove NGINX completely, this is just me sharing the way I do things. Not only that, but I don't know other people's context, so fell free to adapt anything that you saw in the article to your context, and if there is anything that I can help, let me know.
Don't sound like much of a beginner to me! I agree 100% on separating your web server from your PHP app container, especially if you're using nginx as a reverse proxy to php-fpm. It's super easy to setup using docker-compose and the base nginx container. You can still use alpine as the base for your app container.
I also don't see the need for some of the adds. You don't need/want composer in your app--you can use the composer docker image as part of the build process to install app dependencies. Of course, you can use a docker compose override to add it to your local for dev purposes as well. Same goes for node/npm, supervisor, and bash.
Hi James ... sorry for a question years later ... but just starting my "docker containers" journey. I began with separate nginx and php-fpm containers. I pass php requests via the internal network - whatever:9000
This works fine, all good. However I mount the same (host) web dir into both containers (using volumes - and I would prefer not to have the same codebase copying to 2 containers). I'm building an API using Laravel/Breeze ... there are no static files other than project docs that I can handle in the nginx config.
That said, this is not 'reverse proxying' ... which I cannot understand since php-fpm is of course not handling http requests. So, if I start another webserver as either a separate container or integrated in one with php-fpm, have I not just added complexity? and pretty much recreated the author's solution?
What am I missing in this "super easy to setup" reverse proxy in container land ?
Any advice or directions-to-docs etc would be appreciated.
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thank you for sharing this great and detailed post, it really helped me.
I've have just a question as I am bloody beginner here: You are combining PHP and NGINX into one container. Until now, I always tried to avoid this by following the one function per container principle.
Especially if you want to scale the application you will scale NGINX as well, which might not be necessary. Is there es special reason why you go this way and do not use a separate container for NGINX?
Hi @myfriendlyusername,
I use both ways, but here is what I usually try to consider before doing one way or the other. I usually like to analyze the context of the teams and projects. Decouple NGINX can make your container smaller or make your container use a little less hardware, but it's not necessarily the simplest or the easier or the safest way to go through, specially if you have a few projects.
In my opinion decouple NGINX from PHP it makes sense when in your context your team has a good understanding of containers and minimum knowledge of server architecture or if you have a significant number of microservices, and you explicitly want to use NGINX as a reverse proxy to upstream requests to the containers.
But if your reverse proxy runs in a single container you will be creating a single point of failure and if your container goes offline even for a few seconds all of your container will be offline and this may cause problems, specially if you have a high volume of requests/transactions, with NGINX embedded with the application container you don't have the proxy created by you in the middle of the request process removing this single point of failure.
Also, the technology being used to manage the container will influence in your decision as well, let's take AWS ECS and AWS EKS as example:
If you choose to run your containers using ECS it doesn't matter that much if NGINX is, or it isn't, embedded in the container image because ECS is a simpler cluster abstraction that accept both ways, and you could suffer with problems that I've described above.
But if you are running your containers on EKS it may be preferable to not have NGINX because Kubernetes has the ingress controller "component" tight to the cluster, the ingress controller is a special implementation of NGINX, so you could just configure the upstream and your proxy would be running and in this case, we don't have a single point of failure because if the ingress controller stop working the entire cluster would go offline, so it's not a problem of how you architected your infrastructure but a problem with a piece of your infrastructure.
Finally, I would like to reinforce that I don't discourage anyone to try to remove NGINX completely, this is just me sharing the way I do things. Not only that, but I don't know other people's context, so fell free to adapt anything that you saw in the article to your context, and if there is anything that I can help, let me know.
Don't sound like much of a beginner to me! I agree 100% on separating your web server from your PHP app container, especially if you're using nginx as a reverse proxy to php-fpm. It's super easy to setup using docker-compose and the base nginx container. You can still use alpine as the base for your app container.
I also don't see the need for some of the adds. You don't need/want composer in your app--you can use the composer docker image as part of the build process to install app dependencies. Of course, you can use a docker compose override to add it to your local for dev purposes as well. Same goes for node/npm, supervisor, and bash.
Hi James ... sorry for a question years later ... but just starting my "docker containers" journey. I began with separate nginx and php-fpm containers. I pass php requests via the internal network - whatever:9000
This works fine, all good. However I mount the same (host) web dir into both containers (using volumes - and I would prefer not to have the same codebase copying to 2 containers). I'm building an API using Laravel/Breeze ... there are no static files other than project docs that I can handle in the nginx config.
That said, this is not 'reverse proxying' ... which I cannot understand since php-fpm is of course not handling http requests. So, if I start another webserver as either a separate container or integrated in one with php-fpm, have I not just added complexity? and pretty much recreated the author's solution?
What am I missing in this "super easy to setup" reverse proxy in container land ?
Any advice or directions-to-docs etc would be appreciated.