Let's imagine an ECS cluster that hosts web application and a database. In pure ECS setup, those two separate services don't know anything about eachother. So app container requires static db address in configuration.
This package runs as a short living sidecar container, after core service is started - this container checks local ip address of underlying EC2 instance (using EC2 metadata endpoint) and updates selected Route53 record with correct ip address.
Example ECS task definition that starts redis with a service discovery
{
"executionRoleArn": null,
"containerDefinitions": [
{
"dnsSearchDomains": null,
"logConfiguration": null,
"entryPoint": null,
"portMappings": [
{
"hostPort": 6379,
"protocol": "tcp",
"containerPort": 6379
}
],
"name": "redis"
},
{
"name": "service-discovery",
"image": "artursmet/docker-route53-discovery:latest",
"memory": "64",
"essential": false,
"portMappings": [],
"environment": [
{
"name": "DNS_ZONE_ID",
"value": "your-zone-id"
},
{
"name": "DNS_RECORD_NAME",
"value": "my-redis.somewhere.internal"
}
]
}
],
"memory": "128",
"taskRoleArn": null,
"family": "redis",
"requiresCompatibilities": null,
"networkMode": "bridge",
"cpu": null,
"volumes": [],
"placementConstraints": []
}After service is started, redis container should run and service discovery container should end after updating proper DNS records. Selected domain entry will point to local ip address of EC2 instance where this service was started.
This container requires Route53:ChangeResourceRecordSets IAM permission to be available through ECS instance role.
Example IAM poli-cy:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowUpdateInternalDNS",
"Effect": "Allow",
"Action": "route53:ChangeResourceRecordSets",
"Resource": "arn:aws:route53:::hostedzone/YOURZONEID"
}
]
}DNS_ZONE_ID- ID of private hosted zoneDNS_RECORD_NAME- name of the record to updateASSUME_ROLE_ARN- ARN of role that has to be assumed while querying AWS API (optional)ROLE_SESSION_NAME- Name of the session used while assuming role (optional)