Docker promises easy container management. Amazon EC2 Container Service (ECS) promises quick deployments. Solano CI takes advantage of both to provide safe automatic deployments whenever you merge a pull request. One action and your cloud is running your latest code.
When a Solano Labs engineer brought up the idea of updating a docker example repository to demonstrate a Solano CI+Amazon ECS integration, I have to admit my first thoughts bordered on dread. I envisioned writing an extensive list of arguably obscure
aws commands and explaining every one of them in too much detail.
After re-visiting AWS’s excellent documentation on ECS, my thoughts turned much sunnier. Not only was most of the documentation already done, almost all of it could be done in the AWS console. Updating the CI memes example repository to integrate with Amazon ECS was so simple, I procrastinated by updating the container’s webserver output (the earlier web 0.1 look of it kind of bugged me).
These are the steps I took starting from a fresh AWS account:
- Read the Setting Up with Amazon ECS documentation and followed the steps outlined therein.
- Instead of using the Amazon ECS sample, I created a custom task definition on the Amazon ECS console first run wizard.
- For the Task Definition Name I entered “ci_memes”, and then used the Configure via JSON button to add the JSON, although for the initial task revision I set some static values:
123"family": "ci_memes""name": "ci_memes""image": "isaacchapman/ci_memes"
- On the Schedule Tasks step I selected “Create a Service”, set the desired number of tasks to 1, and the service name to “ci_memes-service”.
- To configure the cluster, I selected 1 instance, “t2.micro” as the instance type, the key pair I created in step 1 above, secured non-HTTP access to my network’s IP address range, and set the ECS instance role to the IAM role also created in step 1.
- I updated the solano.yml file in the repo to include non-sensitive environment variables.
- I used the
solano config:addcommand to set environment variables that shouldn’t be checked into the repo:
123456solano config:add repo AWS_ACCESS_KEY_ID <value>solano config:add repo AWS_SECRET_ACCESS_KEY <value>solano config:add repo AWS_DEFAULT_REGION <value>solano config:add repo DOCKER_USER <value>solano config:add repo DOCKER_EMAIL <value>solano config:add repo DOCKER_PASSWORD <value>
- Solano CI was already building the container in the pre_setup hook script , and running the defined tests, so all I had to do was deploy in the post_build hook script. The script is fairly well commented, but the TL;DR version:
- Only deploy if the tests pass.
- Deploy to docker hub.
- Write a new JSON task definition file, replacing the place holders with environment and build defined values.
- Determine the existing revision number of the task in Amazon ECS.
- Update the Amazon ECS task.
As silly as the CI memes and quotes are, it is nice to know that any time I merge a pull request, Solano CI will automatically build, test, and deploy to both Docker Hub and Amazon ECS. It is so easy, I’m looking forward to integrating Amazon EC2 Container Registry (ECR) once it is released.