The environment
I want to spin up a project in amazon ECS which has the following components(simplyfied):
- PHP as backend
- Nginx as a webserver
Currently there is some simple frontend built with webpack, which is accessible in the php and nginx container. In best case we can scale the amounts of nginx and php containers independently.
To reach the website we have one application load balancer which forwards client request to nginx. Each nginx container sends the php requests to a network load balancer which forwards the requests to the php containers. This setup works fine so far.
The deployment of nginx and php is currently done independent of each other with aws blue/green deployment. So we can ensure that we are always only having one nginx image version and one php image version receiving traffic.
The issue
The issue comes once we take the frontend into account. Having some changes for the frontend will lead to have a new minified css file which has a different name. The problem is, that we might face the situation that we are routing the traffic to the new nginx containers but they are still sending requests to "old" php containers(as shown in the image above). The result is that the nginx containers do only have the updated css file and the old php containers reference the old css file. So there might be a certain time frame where the websites won't be styled at all.
Ideas to resolve it
I already thought about some ways but none feels like the right one:
- I could put nginx and php into one container so that each php has its own nginx and therefore the requested css will always be available. But this seems to break the docker philosophy of having just one process per container. Further more we probably have much more nginx instances then needed.
- I could have one task which contains one container for nginx and one container for php and make them communicate by defining links in the task definition. I am not sure though but i guess that would use the legacy "--link" docker flag, which sounds like a bad idea. Apart of this I would again have a lot more nginx instances than needed.
- I could try to somehow synchronize the deployments by using the hook functions within the deployments. So both load balancers would reroute the traffic at the same time. On the one hand it sounds quite valid but on the other hand it feels really hacky to implement such a behavior via lambda functions.
Can somebody out there help me finding a decision which way to go? Or does someone has even other ideas or things to consider?