AWS Service Connect With Terraform - amazon-web-services

Looking for a working terraform plan to configure AWS Service Connect With ECS (FARGATE).
This is what I have:
resource "aws_service_discovery_http_namespace" "my-cloudmap-namespace" {
name = "<namespace>"
description = "Namespace for Service Discovery"
}
Container Definition:
[
{
"name": "my-service-container",
"image": "XXXXXXXXXXX",
"cpu": 0,
"essential": true,
"portMappings": [{
"name": "my-service",
"containerPort": 4002,
"hostPort": 4002,
"protocol": "tcp",
"appProtocol": "http"
}]
}
]
Then In the Service Definition:
service_connect_configuration {
enabled = true
namespace = aws_service_discovery_http_namespace.my-cloudmap-namespace.arn
service {
client_alias {
dns_name = "my-service"
port = "4002"
}
discovery_name = "my-service"
port_name = "my-service"
}
}
This does not seem to work. I am not able to reach my service on http://my-service:4002/ from another instance.
Has anyone successfully configured Service Connect with ECS (FARGATE) using terraform ?

Related

Traefik 502 Bad Gateway with WSS on AWS ECS Fargate

I'm trying to run a secured websocket service, as well as a HTTPS service in an AWS Fargate task.
I use traefik with an ECS provider to do the routing inside the task.
My HTTPS service is working great but the WSS isn't : I get a 502 Bad Gateway error
Here is the log that I get :
level=debug msg="'502 Bad Gateway' caused by: EOF"
Here is my (simplified) JSON file that I use to deploy my task definition :
Container 1 is the one with WSS,
Container 2 is the one with HTTPS,
{
"containerDefinitions": [
{
"portMappings": [
{
"hostPort": 443,
"protocol": "tcp",
"containerPort": 443
},
{
"hostPort": 8080,
"protocol": "tcp",
"containerPort": 8080
}
],
"image": "traefik",
"name": "Traefik",
"command": [
"--api.dashboard=true",
"--api.insecure=true",
"--log.level=DEBUG",
"--providers.ecs=true",
"--providers.ecs.exposedbydefault=false",
"--providers.ecs.autoDiscoverClusters=false",
"--providers.ecs.clusters=ClusterName",
"--entrypoints.websecure.address=:443",
"--serversTransport.insecureSkipVerify=true"
]
},
{
"portMappings": [
{
"hostPort": 1234,
"protocol": "tcp",
"containerPort": 1234
}
],
"image": "xxx",
"name": "Container1",
"dockerLabels": {
"traefik.enable": "true",
"traefik.port": "1234",
"traefik.http.routers.container1-router.tls": "true",
"traefik.http.routers.container1-router.rule": "PathPrefix(`/container1`)",
"traefik.http.routers.container1-router.entrypoints": "websecure",
"traefik.http.middlewares.container1-strip.stripprefix.prefixes": "/container1",
"traefik.http.middlewares.container1-strip.stripprefix.forceSlash": "false",
"traefik.http.routers.container1-router.middlewares": "container1-strip"
}
},
{
"portMappings": [
{
"hostPort": 5000,
"protocol": "tcp",
"containerPort": 5000
}
],
"image": "xxx",
"name": "Container2",
"dockerLabels": {
"traefik.enable": "true",
"traefik.port": "5000",
"traefik.http.routers.container2-router.tls": "true",
"traefik.http.routers.container2-router.rule": "PathPrefix(`/container2`)",
"traefik.http.routers.container2-router.entrypoints": "websecure",
"traefik.http.middlewares.container2-strip.stripprefix.prefixes": "/container2",
"traefik.http.middlewares.container2-strip.stripprefix.forceSlash": "false",
"traefik.http.routers.container2-router.middlewares": "container2-strip"
}
}
]
}
The traefik dashboard displays my router just fine so I can't figure what might be the issue ?
Thanks,

Deploying a docker image from gitlab container registry to ECS

I have a basic node app that I've wrapped in a Dockerfile
FROM node:lts-alpine3.15
WORKDIR /app
COPY package.json ./
RUN npm install
COPY . .
EXPOSE 8080
CMD [ "npm", "run", "serve" ]
I push that to Gitlab's container registry. I'm trying to deploy it from there to AWS, but running into problems on the ECS side. In ECS I have:
a cluster (frontend)
a service (frontend)
both of which are configured in terraform
resource "aws_ecs_cluster" "frontend" {
name = "frontend"
setting {
name = "containerInsights"
value = "enabled"
}
}
resource "aws_ecs_service" "frontend" {
name = "frontend"
cluster = aws_ecs_cluster.frontend.id
deployment_controller {
type = "EXTERNAL"
}
tags = {
Name = "WebAppFrontend"
}
}
The web app is in a different repository from the terraform infrastructure. In my .gitlab-ci.yml I'm trying to register a new task definition for the web app I'm trying to register a new task definition with a json file.
I want when there's been changes to the web app I was to perform a rolling update so both the new version and old version are running, but I can't get one version deployed to ecs. My .gitlab-ci.yml is
deploy_ecs:
stage: deploy_ecs
script:
- aws ecs register-task-definition --cli-input-json file://task_definition.json
task_definition.json is:
{
"family": "frontend",
"containerDefinitions": [
{
"name": "frontend",
"image": "registry.gitlab.com/myproject/application/myimage:latest",
"memory": 300,
"portMappings": [
{
"containerPort": 8080,
"hostPort": 80
}
],
"essential": true,
"environment": [
{
"name": "Frontend",
"value": "dev"
}
]
}
]
}
Attempting to create a service from the console I get this error
The selected task definition is not compatible with the selected compute strategy.
Manually on the ec2 instance infrastructure for the ecs cluster I can run
docker run -d -p 80:8080 myimage
which does run the app. Am I able to:
Deploy the task definition file as above and run the service in my cluster
Deploy in a way so that there will be both versions in a rolling update to avoid any downtime
Do both of the above from my .gitlab-ci.yml
The ec2 instance is confirmed to be running the ecs-agent and I can see the container instance showing correctly so I know ecs is running.
I used console and the service was created successfully.
{
"requiresCompatibilities": [
"EC2"
],
"family": "frontend",
"containerDefinitions": [
{
"name": "frontend",
"image": "registry.gitlab.com/myproject/application/myimage:latest",
"memory": 300,
"portMappings": [
{
"containerPort": 8080,
"hostPort": 80
}
],
"essential": true,
"environment": [
{
"name": "Frontend",
"value": "dev"
}
]
}
]
}
The task eventually failed with access denied but the rest everything worked. Plus you need to add the " ecsTaskExecutionRole" for the task to function.

When creating an ECS task with terraform it is missing required attributes for pulling image from ECR

When I try to create an AWS ECS task with terraform ecs_task_definition the task is created successfully but it is missing some required attributes (com.amazonaws.ecs.capability.ecr-auth, ecs.capability.execution-role-ecr-pull
) which prevents from the container to pull the image from ECR.
When I create the task using AWS CLI with the same parameters (including the same roles for 'execution role' and 'task role') it do add all required attributes and the container successfully pull the image from ECR.
The container definition json is:
{
"containerDefinitions": [
{
"name": "container_main_env-test1",
"image": "586289480321.dkr.ecr.eu-west-1.amazonaws.com/XXXX-saas:latest",
"cpu": 1024,
"memory": 5000,
"essential": true,
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/XXXX-test1",
"awslogs-region": "eu-west-1",
"awslogs-stream-prefix": "ecs"
}
},
"portMappings": [
{
"containerPort": 80,
"hostPort": 80
}
]
}
]
}
The task definition is:
resource "aws_ecs_task_definition" "XXXX_task_definition" {
family = var.name
task_role_arn = aws_iam_role.XXXX_ecs_task_role.arn
execution_role_arn = "arn:aws:iam::586289480321:role/ecsTaskExecutionRole"
container_definitions = var.container_definition_content
}
The json above is passed as parameter to this definition on 'var.container_definition_content'
Is there a known bug about it or some tweak that I am missing?
Thanks,
Ronen

Problem with setting a service in AWS ECS

I was trying to set up a ECS service running a container image on a cluster, but could not get the setup working.
I have basically followed the guide on https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-blue-green.html, except that I was trying to host the containers on EC2 instances.
I wonder if the issue is related to the network mode (used "awsvpc").
Expectation
It should show something on index.html on access witht eh ALB link
Observation
When I tried to access with the load balancer link, it gives HTTP 503, and the health-check also showed unhealthy
And it seems ECS keeps "re-creating" the conatiners? (Forgive me as I am still not familiar with ECS)
Tried to access the container instance directly but also could not reach
I had a look on the ECS agent log (/var/logs/ecs-agent.log) on the container instance, the image should have been pulled sucessfully
And the task should have been started
ECS service events
It seems it kept register and deregister target
Security groups have been set to accept HTTP traffic
Setup
Tomcat server on container starts on port 80
ALB
Listener
Target group
ECS task definition creation
{
"family": "TestTaskDefinition",
"networkMode": "awsvpc",
"containerDefinitions": [
{
"name": "TestContainer",
"image": "<Image URI>",
"portMappings": [
{
"containerPort": 80,
"hostPort": 80,
"protocol": "tcp"
}
],
"essential": true
}
],
"requiresCompatibilities": [
"EC2"
],
"cpu": "256",
"memory": "512",
"executionRoleArn": "<ECS execution role ARN>"
}
ECS service creation
{
"cluster": "TestCluster",
"serviceName": "TestService",
"taskDefinition": "TestTaskDefinition",
"loadBalancers": [
{
"targetGroupArn": "<target group ARN>",
"containerName": "TestContainer",
"containerPort": 80
}
],
"launchType": "EC2",
"schedulingStrategy": "REPLICA",
"deploymentController": {
"type": "CODE_DEPLOY"
},
"networkConfiguration": {
"awsvpcConfiguration": {
"assignPublicIp": "DISABLED",
"securityGroups": [ "sg-0f9b629686ca3bd08" ],
"subnets": [ "subnet-05f47b367df4f50d4", "subnet-0fd76fc8e47ea3be7" ]
}
},
"desiredCount": 1
}
Based on the comments.
To investigate the issue, it was recommended to tested the ECS service without ALB. Based on the test, it was found that the ALB was treating the ECS service as unhealthy due to long application starting time.
The issue was solved by increasing ALB health-check grace period to (e.g. 300s).
not sure if EC2 launch type must use "bridge"
You can use awsvpc on EC2 instances as well, but bridge is easier to use in this case.

ASP.NET Core for AWS ECS requires VIRTUAL_HOST

I'm deploying an ASP.NET Core Web API app as a docker image to AWS ECS, so use a task definition file for that.
It turns out the app only works if I specify environment variable VIRTUAL_HOST with the public DNS of my EC2 instance (as highlighted here: http://docs.servicestack.net/deploy-netcore-docker-aws-ecs), see taskdef.json below:
{
"family": "...",
"networkMode": "bridge",
"containerDefinitions": [
{
"image": "...",
"name": "...",
"cpu": 128,
"memory": 256,
"essential": true,
"portMappings": [
{
"containerPort": 80,
"hostPort": 0,
"protocol": "http"
}
],
"environment": [
{
"name": "VIRTUAL_HOST",
"value": "ec2-xx-xxx-xxx-xxx.compute-1.amazonaws.com"
}
]
}
]
}
Once the app is deployed to AWS ECS, I hit the endpoints - eg http://ec2-xx-xxx-xxx-xxx.compute-1.amazonaws.com/v1/ping
with the actual public DNS of my EC2 instance in VIRTUAL_HOST all works fine
without the env variable I'm getting "503 Service Temporarily Unavailable" from nginx/1.13.0
and if I put an empty string to VIRTUAL_HOST I'm getting a "502 Bad Gateway" from nginx/1.13.0.
Now, I'd like to avoid specifying virtual host in the taskdef file - is that possible? Is my problem ASP.NET Core related or nginx related?
Amazon ECS have a secret management system using Amazon S3. You have to create a secret in your ECS interface, and then you will be able to reference it in your configuration, as an environment variable.
{
"family": "...",
"networkMode": "bridge",
"containerDefinitions": [
{
"image": "...",
"name": "...",
"cpu": 128,
"memory": 256,
"essential": true,
"portMappings": [
{
"containerPort": 80,
"hostPort": 0,
"protocol": "http"
}
],
"environment": [
{
"name": "VIRTUAL_HOST",
"value": "SECRET_S3_VIRTUAL_HOST"
}
]
}
]
}
Store secrets on Amazon S3, and use AWS Identity and Access Management (IAM) roles to grant access to those stored secrets in ECS.
Full blog post
You could also make your own NGinx Docker image, which will already contain the environment variable.
FROM nginx
LABEL maintainer YOUR_EMAIL
ENV "VIRTUAL_HOST" "ec2-xx-xxx-xxxxxx.compute1.amazonaws.com"
And you would just have to build it, ship it privately and then use it for your configuration.