AWS Open Source Blog
Building Spinnaker features for Amazon ECS
For the past year, AWS Container Services has been contributing to Amazon ECS support in Spinnaker, the popular cloud-based continuous delivery platform. Originally open sourced by Netflix in 2015, Spinnaker has become a compelling CI/CD solution for customers looking to standardize their deployment process across multiple platforms and integrate with existing tools like Jenkins or TravisCI.
In early 2018, deploying to Amazon ECS with Spinnaker was possible thanks to contributions from Lookout and other community members who enabled deployment of a container image to Amazon ECS through a pipeline. Later that year, the Amazon ECS team began exploring a variety of open source tools, including Spinnaker, to find where we could help improve open source integrations with ECS. We engaged with the Spinnaker community and began asking our customers what they wanted to see in the ECS integrations with Spinnaker. Customers told us they needed a more fully-featured experience, something closely resembling what they could do when deploying to Amazon ECS directly. For example, we heard from customers who were eager to deploy their Amazon ECS services on AWS Fargate, but couldn’t yet configure the required settings from their Spinnaker pipeline. Customers also wanted more flexibility in how they ran their service, such as without a load balancer, or using placement constraints – options which were either missing or used hard-coded values at the time.
An Amazon ECS team member, AWS Principal Software Engineer Clare Liguori, began tackling some of these gaps in August of 2018. Since then, we’ve submitted 50+ pull requests across five Spinnaker repositories, adding support for service features like AWS Fargate, service discovery with AWS Cloud Map, resource tagging, and task placement constraints.
We’ve also added support for all task definition fields and multi-container applications through the use of task definition artifacts. This feature is especially exciting because it gives customers complete control over the contents of their task definition and makes it easier to automatically deploy new configurations. For example, I can now store my task definition as a JSON file in GitHub and set up my Spinnaker pipeline to trigger on changes to that repository. This means that when I edit my task definition – say, to increase the memory limit for one of my containers – and push that change, my Spinnaker pipeline automatically kicks off a new deployment to apply that change to my ECS service! I can also define up to 10 containers in my task definition vs. being limited to one in the pipeline configuration.
Using a file to store your task definition also means that the time between new Amazon ECS features being launched and your ability to use them in Spinnaker is greatly reduced. Prior to this work, only about 25% of the 100+ available task definition attributes were configurable in Spinnaker, with the potential for new attributes to be added as new features were released. Individually building support for each new and existing field would put substantial time and engineering effort between customers and their ability to use these features. By storing and retrieving task definitions as files, all Spinnaker maintainers have to do is bump the AWS SDK version, and customers can start adding the new features to their task definition and deploying them to their Amazon ECS services.
Thanks to these contributions, customers can now leverage all supported task definition attributes, adopt new features faster, run their Amazon ECS services on either EC2 or AWS Fargate, and take advantage of numerous service options, all within their existing Spinnaker pipeline.
Current work
We’re still working to bring all Amazon ECS service features into Spinnaker, including the recently-launched support for multiple target groups per service, and existing scheduling options like daemon sets and custom placement strategies.
But we’ve also realized that there’s more work to do outside of just adding missing service features. As more customers try out the ECS provider in Spinnaker, we’ve realized that we need to support larger accounts, with more resources, and address intermittent problems such as race conditions and caching inefficiencies, which have a bigger impact as your services grow. So we’ll be investing in performance enhancements to make it easier for Amazon ECS customers to scale up their Spinnaker-managed services along with the demands on their applications.
Finally, collaborating with customers and the larger Spinnaker community will continue to be essential. To make sure our work aligns with the priorities of the community, we have partnered with Armory and Netflix to form the Spinnaker AWS Special Interest Group (SIG). The goal of the AWS SIG is to share updates on in-progress work and provide another channel for the community to ask questions, give feedback, and see new feature demos. The AWS SIG meets monthly on Google Hangouts and anyone is welcome to join! Our team will use these meetings as a forum to discuss the Amazon ECS on Spinnaker roadmap and prioritize contributions based on customer needs.
Join us!
Amazon ECS contributions to Spinnaker are 100% driven by customers. If you’re already using Spinnaker to deploy to Amazon ECS and would like to collaborate with us on new features, please join us on Slack #ecs and tell us what you’re working on! We also welcome feature requests, bug reports, or other feedback via GitHub issues. Big thanks to all the Spinnaker community members who have already helped make the Amazon ECS provider what it is today!
If you’re new to Spinnaker or ECS and are interested in trying it out, take a look at the AWS Quickstart guide and Amazon ECS setup documentation to get started.
re:Invent 2019
Want to learn more about Spinnaker and AWS? Join us at re:Invent for: