I have an ecs architecture, which has an application running as a container and a nginx side car container. So each task has 2 containers(nginx+app). These two containers are linked through bridge network mode. We currently observe increase in response time. We suspected it may be because of docker bridge network.So, we are trying to change to aws vpc mode networking. But when we tried to update to aws vpc network mode, it gave us an error 'Links are not supported when networkMode=awsvpc.'. So how to use aws vpc networking for these kind of side car architectures?
Linking is not supported in AWSVPC network mode.you need to use service discovery.
links
Type: string array
Required: no
The link parameter allows containers to communicate with each other
without the need for port mappings. Only supported if the network mode
of a task definition is set to bridge.
Note
This parameter is not supported for Windows containers or tasks using
the awsvpc network mode.
task_definition_parameters
Related
I am trying to create a new EC2 based ECS task definition using the new ECS console (https://ap-south-1.console.aws.amazon.com/ecs/v2/task-definitions?region=ap-south-1). But in the port mapping section (which is part of Step 1) I only see the option to set Container port. I want this for an nginx container so container port 80 is fine, but I don't see any option to change host port (to 8080 for example).
When I go to the next step I see Fargate is chosen as the default app environment. I change that to EC2 only and go to create the definition. It creates the definition with host port as 80 as well. If I try to create a new revision I see the same options as above and no way to change host port.
Is this just something that's not been implemented in the new console design ? Or am I missing something here ? As I see the proper options to change host port in the classic UI.
Additionally, with this new UI I'm also not able to change things like network (defaults to awsvpc). It seems like this UI is geared completely to a Fargate type of application since all these options I talk about are not required to be configured for Fargate (as per my knowledge).
Thanks!
Unfortunately you cannot set host port, because the new ECS V2 console currently supports only awsvpc for the network mode.
From the console if we click the Info link:
The new Amazon ECS console experience currently only supports the awsvpc network mode, which provides the task with an elastic network interface (ENI).
For the awsvpc network mode, you can set only the container port, since this will be exposed through an ENI to your VPC. You would need bridge mode for being able to configure both the container and host ports.
The V2 console at this point is lacking in functionality compared to the older one. You would want to stick with the older one.
in the new console, Network mode has been moved to the 2nd page. only awsvpc and bridge are supported right now (and it defaults to awsvpc) while we are working to add more features.
The host port field will appear once the network mode is set to bridge - please note Fargate only supports awsvpc network mode.
By the way, please do submit feedback/feature requests/comments about the new console here: https://github.com/aws/containers-roadmap
Thanks!
when I enable Auto-configure CloudWatch Logs a warning about Network mode appears, it says Your containers in the task will share an ENI using a common network stack. Port mappings can only specify container ports (any existing host port specifications will be removed).
This is the warning that appears, I don't understand what that means
I don't think this has anything to do with the logging configuration. This has to do more with the networking option you picked (awsvpc). When you select that you are basically landing your task right inside the VPC and the task will get a VPC ip address. In other words there is no docker host natting where you expose the port 80 of your nginx container on port 12345 of the host. The warning is just saying that you need to make sure all your containers in the task do not overlap ports because they are reachable as-is on the VPC ip address assigned to the task. Note that awsvpc is the only networking mode supported on Fargate (because with Fargate there is not host anyway). See here for background on ECS networking modes.
I'm trying to configure ECS task on EC2 instance. Network mode in task definition is Bridge
My task has two containers inside, that should communicate with each other. e.g. ContainerA makes requests to ContainerB and ContainerB makes requests to ContainerA.
Everything works well when I use docker-compose, containers can communicate by their names. But when I deploy on ECS those containers don't see each other. Partly I can fix this problem using Links in the task definition, however, it works only in one direction, I mean if set links for both containers I receive such error message during creation task definition:
Unable to create a new revision of Task Definition web-app:12
Container links should not have a cycle
It would be great to hear any thoughts, what did I miss and if it's actually possible. Honestly, I thought that containers inside one task should communicate automatically by container names, especially when they are under the same Bridge network.
I know that there is a feature Service Discovery that allow communication between to services by names, but still, I would prefer to have one service and task with two containers inside.
Thank you for any help.
ContainerA NETWORK SETTINGS
If both containers are defined in the same task definition they are available via localhost:
For instance, if ContainerA is listening on port 8081 and ContainerB is listening on port 8082, they can simply reach each other by:
localhost:8081
localhost:8082
Side note: same concept as in Kubernetes pod with two containers - they are accessible via localhost
EDIT: that's relevant for awsvpc network mode as you can see in the documentation:
containers that belong to the same task can communicate over the
localhost interface
docker-compose uses not a bridge, but user-defined network by default. That's by addressing by service name works:
By default Compose sets up a single network for your app. Each container for a service joins the default network and is both reachable by other containers on that network, and discoverable by them at a hostname identical to the container name.
https://docs.docker.com/compose/networking/
ECS EC2 uses links by default, which are deprecated by Docker and not cannot have cycles, as you've found out.
Unfortunately user-defined networks are not supported by AWS despite a long-standing issue: https://github.com/aws/containers-roadmap/issues/184
That's what I've figured out so far. I guess the only option left is to use the awsvpc network mode which allows containers to communicate via localhost (which I find rather awkward):
This means that all containers in a task are addressable by the IP addresses of the elastic network interface, and they can communicate with each other over the localhost interface.
https://aws.amazon.com/blogs/compute/under-the-hood-task-networking-for-amazon-ecs/
I don't know if the issue is one of time (i.e. it'll get added eventually) or that the Windows network stack just simply isn't able to support giving a container/task its own ip address - does anyone have any insight on this?
From my perspective, having the dedicated ip means each task can have a dedicated security group thereby providing a network level security layer between tasks (very useful in multitenant environments).
Thanks
It's been delayed but better late than never. AWS announced the support for awsvpc network mode with the Windows tasks on ECS EC2. The steps to get started are available here.
I have 2 ECS Services running with EC2 launch type and bridge networking mode. each service is having 1 task and both tasks are running on same EC2 container host.
on the Same ECS host, API container in 1st task is trying to communicate DB container in 2nd task by host name and port number( ex: http://abc-def:5000). what are the ways to achieve this ?
Your options are:
Put everything in a single task definition. Then you can use the link attribute to enable container A to communicate with container B like so B:port. Notice that link does not support circular relations meaning if A can talk with B, B will not be able to do that as well.
Switch to network mode host. This way you can communicate with localhost.
Proper service discovery with a tool like Consul or AWS ECS Service Discovery. I have no experience with the latter. See here.
Put your tasks behind ALB and use this load balancer to communicate between tasks.