Sidecars
Sidecars are additional containers that run along side the main container. They are usually used to perform peripheral tasks such as logging, configuration, or proxying requests.
Attention
Sidecars are not supported for Request-Driven Web Services.
Attention
If your main container is using a Windows image, FireLens, AWS X-Ray, and AWS App Mesh are not supported. Please check if your sidecar container supports Windows.
AWS also provides some plugin options that can be seamlessly incorporated with your ECS service, including but not limited to FireLens, AWS X-Ray, and AWS App Mesh.
If you have defined an EFS volume for your main container through the storage
field in the manifest, you can also mount that volume in any sidecar containers you have defined.
How to add sidecars with Copilot?
There are two ways of adding sidecars using the Copilot manifest: by specifying general sidecars or by using sidecar patterns.
General sidecars
You'll need to provide the URL for the sidecar image. Optionally, you can specify the port you'd like to expose and the credential parameter for private registry.
port
Integer
Port of the container to expose (optional).
image
String
Image URL for the sidecar container (required).
essential
Bool
Whether the sidecar container is an essential container (optional, default true).
credentialsParameter
String
ARN of the secret containing the private repository credentials (optional).
variables
Map
Environment variables for the sidecar container (optional)
secrets
Map
Secrets to expose to the sidecar container (optional)
mount_points
Array of Maps
Mount paths for EFS volumes specified at the service level (optional).
mount_points.source_volume
String
Source volume to mount in this sidecar (required).
mount_points.path
String
The path inside the sidecar container at which to mount the volume (required).
mount_points.read_only
Boolean
Whether to allow the sidecar read-only access to the volume (default true).
labels
Map
Docker labels to apply to this container (optional).
depends_on
Map
Container dependencies to apply to this container (optional).
entrypoint
String or Array of Strings
Override the default entrypoint in the sidecar.
# String version.
entrypoint: "/bin/entrypoint --p1 --p2"
# Alteratively, as an array of strings.
entrypoint: ["/bin/entrypoint", "--p1", "--p2"]
command
String or Array of Strings
Override the default command in the sidecar.
# String version.
command: ps au
# Alteratively, as an array of strings.
command: ["ps", "au"]
healthcheck
Map
Optional configuration for sidecar container health checks.
healthcheck.command
Array of Strings
The command to run to determine if the sidecar container is healthy.
The string array can start with CMD
to execute the command arguments directly, or CMD-SHELL
to run the command with the container's default shell.
healthcheck.interval
Duration
Time period between health checks, in seconds. Default is 10s.
healthcheck.retries
Integer
Number of times to retry before container is deemed unhealthy. Default is 2.
healthcheck.timeout
Duration
How long to wait before considering the health check failed, in seconds. Default is 5s.
healthcheck.start_period
Duration
Length of grace period for containers to bootstrap before failed health checks count towards the maximum number of retries. Default is 0s.
Example
Below is an example of specifying the nginx sidecar container in a load balanced web service manifest.
name: api
type: Load Balanced Web Service
image:
build: api/Dockerfile
port: 3000
http:
path: 'api'
healthcheck: '/api/health-check'
# Target container for Load Balancer is our sidecar 'nginx', instead of the service container.
target_container: 'nginx'
cpu: 256
memory: 512
count: 1
sidecars:
nginx:
port: 80
image: 1234567890.dkr.ecr.us-west-2.amazonaws.com/reverse-proxy:revision_1
variables:
NGINX_PORT: 80
Below is a fragment of a manifest including an EFS volume in both the service and sidecar container.
storage:
volumes:
myEFSVolume:
path: '/etc/mount1'
read_only: false
efs:
id: fs-1234567
sidecars:
nginx:
port: 80
image: 1234567890.dkr.ecr.us-west-2.amazonaws.com/reverse-proxy:revision_1
variables:
NGINX_PORT: 80
mount_points:
- source_volume: myEFSVolume
path: '/etc/mount1'
Below is an example of running the AWS Distro for OpenTelemetry sidecar with a custom configuration. The example custom configuration will not only collect X-Ray trace data, but also ship ECS metrics to a third party. The example will require an SSM secret and additional IAM permissions.
To use the OpenTelemetry sidecar, first, create a valid configuration file. Next, check the size of the configuration file. A standard parameter is limited to 4KB. If the configuration file is larger than 4K, an advanced SSM parameter must be used.
If an advanced parameter is required, it will need to be created and tagged manually. If the configuration fits within a standard parameter, create an SSM secret using the secret init
. The YAML document below can be used as-is with New Relic after updating the API key written as "YOUR-API-KEY-HERE".
In the example YAML, the inclusion of empty keys is deliberate. The sidecar will use the collector defaults for those keys.
receivers:
awsxray:
transport: udp
awsecscontainermetrics:
processors:
batch:
exporters:
awsxray:
region: us-west-2
otlp:
endpoint: otlp.nr-data.net:4317
headers:
api-key: YOUR-API-KEY-HERE
service:
pipelines:
traces:
receivers: [awsxray]
processors: [batch]
exporters: [awsxray]
metrics:
receivers: [awsecscontainermetrics]
exporters: [otlp]
Writing X-Ray traces needs additional IAM permissions as shown below. Include this in addons according to the published documentation
Resources:
XrayWritePolicy:
Type: AWS::IAM::ManagedPolicy
Properties:
PolicyDocument:
Version: '2012-10-17'
Statement:
- Sid: CopyOfAWSXRayDaemonWriteAccess
Effect: Allow
Action:
- xray:PutTraceSegments
- xray:PutTelemetryRecords
- xray:GetSamplingRules
- xray:GetSamplingTargets
- xray:GetSamplingStatisticSummaries
Resource: "*"
Outputs:
XrayAccessPolicyArn:
Description: "The ARN of the ManagedPolicy to attach to the task role."
Value: !Ref XrayWritePolicy
The configuration for the OpenTelemetry collector will be passed into the sidecar as an environment variable.
sidecars:
otel_sidecar:
image: 'public.ecr.aws/aws-observability/aws-otel-collector:latest'
secrets:
AOT_CONFIG_CONTENT: /copilot/${COPILOT_APPLICATION_NAME}/${COPILOT_ENVIRONMENT_NAME}/secrets/otel_config
Sidecar patterns
Sidecar patterns are predefined Copilot sidecar configurations. For now, the only supported pattern is FireLens, but we'll add more in the future!
# In the manifest.
logging:
# The Fluent Bit image. (Optional, we'll use "public.ecr.aws/aws-observability/aws-for-fluent-bit:stable" by default)
image: <image URL>
# The configuration options to send to the FireLens log driver. (Optional)
destination:
<config key>: <config value>
# Whether to include ECS metadata in logs. (Optional, default to true)
enableMetadata: <true|false>
# Secret to pass to the log configuration. (Optional)
secretOptions:
<key>: <value>
# The full config file path in your custom Fluent Bit image. (Optional)
configFilePath: <config file path>
# Environment variables for the sidecar container. (Optional)
variables:
<key>: <value>
# Secrets to expose to the sidecar container. (Optional)
secrets:
<key>: <value>
logging:
destination:
Name: cloudwatch
region: us-west-2
log_group_name: /copilot/sidecar-test-hello
log_stream_prefix: copilot/
You might need to add necessary permissions to the task role so that FireLens can forward your data. You can add permissions by specifying them in your addons. For example:
Resources:
FireLensPolicy:
Type: AWS::IAM::ManagedPolicy
Properties:
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- logs:CreateLogStream
- logs:CreateLogGroup
- logs:DescribeLogStreams
- logs:PutLogEvents
Resource: "<resource ARN>"
Outputs:
FireLensPolicyArn:
Description: An addon ManagedPolicy gets used by the ECS task role
Value: !Ref FireLensPolicy
Info
Since the FireLens log driver can route your main container's logs to various destinations, the svc logs
command can track them only when they are sent to the log group we create for your Copilot service in CloudWatch.
Info
We're going to make this easier and more powerful! Currently, we only support using remote images for sidecars, which means users need to build and push their local sidecar images. But we are planning to support using local images or Dockerfiles. Additionally, FireLens will be able to route logs for the other sidecars (not just the main container).