A Spinnaker server group maps to an Amazon ECS service.
There are two ways to specify server group settings for Amazon ECS:
Inputs (default): Specify the container image, resource limits, and other settings needed to create an Amazon ECS task definition and service directly in the server group. This option supports deploying one container per Amazon ECS task (equivalent to a Spinnaker “instance”).
Artifact (supported as of 1.15.0): Specify a pipeline artifact to use as an Amazon ECS task definition for the service. The artifact should be a JSON file in the format of an Amazon ECS Register Task Definiton request. This option also requires that you specify
imageDescriptionmappings for each image in your pipeline that you want to be deployed within the service. You can deploy multiple containers (up to 10) per Amazon ECS task using this option.
A Spinnaker instance maps to an Amazon ECS task. Amazon ECS services manage tasks to ensure desired capacity is reached.
An Amazon ECS cluster does not map to any core Spinnaker concept. You can choose what cluster you deploy to in your deploy stage parameters.
Deploys a new Amazon ECS service to the specified server group(s). For load balanced services, the previous service will be drained after the new service is considered healthy.
Deployments to Amazon ECS take two actions in regards to Amazon ECS resources:
- Register a new Amazon ECS task definition that contains the specified container(s), their image(s), and other information needed for your application to run.
- Create a new Amazon ECS service that runs the registered task definition with the desired instance (task) count, load balancer, and scaling policies.
Scales the desired count for the Amazon ECS service down to 0 instances (tasks), then deletes the service.
Scales the desired count for the Amazon ECS service down to 0 instances (tasks), so no instances are running.
Scales the Amazon ECS service up or down to the desired number of instances (tasks).
From Spinnaker 1.24 the ECS provider can be configured to use either Frigga or a tag based naming strategy which Spinnaker manages using its Moniker library. The naming strategy is configurable per-account or applied as a default across all accounts.
ecs: enabled: true defaultNamingStrategy: "default" <--- 'default' naming used by default (field absent) or if specified accounts: - name: "ecs-moniker-acct" awsAccount: "ec2-aws-acct" namingStrategy: "tags" <--- 'tags' specified for specific account
default Naming Strategy
default naming strategy uses the Frigga naming convention to parse information about resources. This derives all values for application, stack, detail, etc from the name of the resource.
tags Naming Strategy
tags naming strategy uses information from tags on the resource to derive information like application, stack, detail, etc.
To use ECS service tags, your Amazon ECS account must be opted into using the long Amazon Resource Name (ARN) format. In addition, your AWS
SpinnakerManaged role will need to call
ecs:ListAccountSettings in order to validate whether your account is compatible with tags.
Currently these tags are only applied at the ECS service level which is then configured to propagate the tags to any tasks created by the service scheduler.
Several tags are used as metadata by Spinnaker to describe a resource. Tags listed below followed by a 📝 symbol may also be written by Spinnaker.
The application this resource belongs to.
This affects where the resource is accessible in the UI, and depending on your Spinnaker Authorization setup, can affect which users can read/write to this resource.
The cluster this resource belongs to.
This is purely a logical grouping for rendering resources in the UI and to help with dynamic target selection in Pipeline stages. For example, some stages allow you to select “the newest workload in cluster X”. How you set up these groupings depends on your delivery needs.
These provide ways to group resources using Spinnaker’s cluster filters as well as apply policies such as Traffic Guards.
The sequence number of the release this resource belongs to.
Each modification of a resource is deployed with a new sequence number in the format
vNNN. This allows for multiple versions to be running and provides for rollback.