Likewise, if you had a configuration where minimum % = 100, and maximum % = 150 (assuming you have capacity), ECS will launch an additional task once it's up, you have a healthy percent of 133%, and it can safely kill one of the old tasks. Once the new task comes up, the service is again at 100%, and ECS can continue with rolling the deploy to the next instance.
ECS will kill one of your tasks, making the healthy % drop to 66%, still above 50%. We have 3 running tasks, but allow for >=50% healthy. If you change the task definition that your service is pointing at, it will initiate a rolling deploy. So for a real example, let's assume you have the following configuration: Number of tasks: 3
Maximum percent - The maximum % of n that can be added when deploying new tasks. Minimum healthy percent - The minimum healthy % of n when deploying new tasks. Number of tasks - The number of tasks your service wants to run (n). The below settings are where the magic happens for enabling rolling deploys you can find these configuration options in your service settings.įor you to be able to do rolling deploys, you have to have at least 2 tasks running. Note that it's reliant on the task definition number, and doesn't care about the container tags in the way that the EC2 instance will. However, you can do rolling deploys.Īs you're probably aware already, your Service relies on a task definition that's specified. To your question then, unfortunately for now there aren't any great built-in mechanics from AWS for performing a rolling restart of tasks. If you want to put multiple copies of the same container on a single box, definitely look at the suggestions from the other answers (in addition to the details below), but for rolling deploys, dynamic ports are by no means required. I say this because it's a problem my team has faced as well, and doesn't really have anything to do with trying to launch multiple containers on the same instance - if I understand correctly, you're just trying to replace the existing container from an updated task definition. While the other answers are correct, I don't think they apply to the problem you have. Now I have no static port mappings on the hosts, the NLB does the routing for me and deploys work as expected All I had to do was change my task definition to set the host port to "0". I added a load balancer but kept that static port mapping not understanding how dynamic port mapping worked. Of course in order to do this I had to expose a static port on the EC2 host. Initially, when I first started I didn't have a load balancer so I was hitting the EC2 instances directly to access the running containers. Just to follow up, as stated in the answers I just needed to use dynamic port mapping. Not sure if there is a feature to automate that beyond my own scripting #Servetome port mapping needed update
So I can update my service and "force new deploy" then stop one task at a time to get a sort of a rolling update. Will I have to stop all tasks and update the service each time I want to deploy a new image? Or is there a "right" way to do this? EDIT: So if I stop one task the service will automatically replace it. Then went back to my Service and updated with force new deploy again. I then went to my cluster and stopped all tasks. is already using a port required by your task When I update my service though and "force new deployment" i look at the events and see this: service MYSERVICE was unable to place a task because no container instance met all of its requirements. The task definition my Service uses is pulling the "latest" tagged version of my image.
0 kommentar(er)
