Harness has some great docs around deploying to ECS for e.g. ECS Deployments Overview - Harness.io Docs , AWS ECS Deployments Overview - Harness.io Docs etc.
In this article, I just want to go over a little background on how harness handles the deployments and ASGs associated.
Setting up the ECS Deploy
-
We start with downloading a ECS delegate spec to be able to do tasks on our ECS cluster.
-
Once we have our task-spec with us we can create a task-definition on AWS with the harness spec, be sure to change the “family” in the json to whatever you want to use to identify the delegate. and deploy your service with this task-spec. You should see something like below:
Once the status is “running” the delegate should be visible in your Harness UI.
-
Setup a AWS Cloud Provider in Harness, this cloud provider will be used to connect to your aws account. Make sure the Test works with a “Success” code
-
Setup your ECS service: Your service of type ECS needs to be setup. You can choose to add a service definition and task definition which harness will use to override the existing one and create and deploy this service, or you can leave at as default to take the one set by you in AWS
- Setup Environment and Infra-definition: This point is important as t sets the context of the deployment.
You can choose a fargate or EC2 deployments type depending on your ECS cluster created.
Now setting this infra will map Harness to the specific VPC, subnet, Security groups and task execution role. Incorrectly setting the infra will lead to deployment failures.
- Once all of this is set you can actually create your Workflow for the ECS deployment
Here you give the Service name you want the deployed service to be identified by in the “ECS Service Setup” step this is by default “${app.name}${service.name}${env.name}”, also you can give resizing strategy.
- Do the Deploy! Once you have your workflow setup you can choose to deploy your container i your ECS cluster, after a successful deploy you would be able to see your new service in the AWs console.
This will show the delegate service (vipul-test-ecs-1) as well as the new service you deployed with the name as set in the above step.
Deployment Behaviour:
Harness by default keeps the new (x) and 1 old (x-1) service at a time deleting all the older ones. It identifies this with the service name. Thus, if you want to keep all older revisions of a service, one way to achieve this is by making the service name instead of “${app.name}${service.name}${env.name}” to something which is unique and changes everytime e.g. “${app.name}${service.name}${env.name}_${artifact.buildNo}” Now artifact build no changes with each deploy thus Harness will take each deploy as a new service and keep all older ones