Introduction to Amazon EC2 Container Service
Today’s success is no secret (or even news) for the success of containerization technologies in general and the Docker platform, as a successful practical solution, in particular. Anyone who has tried to pack his application into a container at least once has experienced this feeling of purely childlike happiness from the understanding that here it is - a packaged and ready-to-work component that will unfold anywhere, in any quantities, and will work there as well. well, how it worked on the developer's computer. Deployment was pleasure, not punishment. “Flexibility” and “scalability” have ceased to be marketing nonsense from promotional leaflets and become real achievable things. Writing microservices has become not just "fashionable", but simply logical and practical. Containers have changed the world forever. (It was true that yesterday, the thought that containers are evil , but in the comments it seems to have sorted out that it’s not exactly the containers that are in containers, but in the general approach to security)
Less than 100 years have passed, as Amazon has noticed, having released its new service, Amazon EC2 Container Service, at the end of 2014 to beta. The general meaning of the service is to give the opportunity to deploy Docker-containers in a convenient way. “Convenient” means, without need to delve into the insides of the Docker, and generally do something with your hands in the console of the host machine. You simply create a new cluster, add virtuals to it, on which the containers will work, and then indicate how many and which containers you need to run. Everything else (the choice on which machine to run the container, access rights, port forwarding) Amazon takes over. In addition, you can use the entire Amazon infrastructure from the Docker container - save files on S3, use SQS queues, fasten Amazon Amazon load balancer at the input, and Amazon logs and analytics services at the output. Containers can “see” each other, share (or not share) resources, start and be stopped from the AWS console (manually or according to specified rules).
')
Let's try to launch something in the Amazon EC2 Container Service. For example, we will lift Wordpress + Mysql.
In principle, you can go here , click the “Get started” button and go through the wizard, which will guide you through the process of setting up a cluster and tasks, but I personally don’t like this approach - you don’t see the power of the system and the flexibility of settings. Close the wizard. Open the "Clusters" tab , on which we do not yet have a single cluster.
Well, let's create one!
And open:
So, we see that the cluster is created and is in the active state, although nothing is happening in it yet. Well, it is no wonder - we have not given him any tasks so far. In order for everything to turn out, we need to tell the cluster what tasks and on which machines it should perform.
ECS Instances
These are EC2 virtualkeys that you will allocate for cluster operation. You can run any number of any type of virtual machines in one cluster. Well, not any, the limit is 1000 machines per cluster, it should be enough? There are only two requirements for the machine: a Docker must be installed there and an Amazon ECS Container Agent must be installed there - this is a utility from Amazon for managing the cluster. The source is open - github.com/aws/amazon-ecs-agent . Put simply:
But, in general, installing Docker and the agent on a more or less standard Linux is a trivial and uninteresting task, so Amazon has already made images for virtual machines with all necessary, here they are:
So, we need to run at least one such virtual machine from the EC2 control panel :
In the previous step, you may need to create an IAM User, IAM Role, and VPC. What is it, why and how it is created can be read here .
In the next step, make sure that the security rules allow access to port 80 (we were going to pick up WordPress, do you still remember?):
We are waiting for a couple of minutes until our virtual machine goes into the “Running” state:
Now on the tab of our cluster we can see the node added to it:
If you need more cars - it's time to start them, but one is enough for us.
Tasks are a description of what will actually work in our cluster. The task includes one or several associated Docker containers, a description of their environment, their resource requirements, mount points, port mapping, launch parameters, etc. Here is a task that describes two related Docker containers: one for Wordpress and one for Mysql.
Let's briefly describe what's where:
There are more parameters in the documentation , some of them (entryPoint, cmd, mountPoints) are taken directly from the Docker documentation.
Let's add the task described above:
Now you need to run the task. This can be done on our cluster page, in two ways:
One would think that the difference is that the service allows you to set several tasks to start, but not - this can be done in the first method. The difference is in the concept: in the first case, it is considered that we are launching some “background” task, which must work out and die. In the second case, we are raising some service, which must be accessible from the outside for a long time, so firstly for the service we can immediately turn on the Elastic Load Balancer, and secondly, fallen tasks (and even failed virtuals) will re-raise the service so that maintain the number of active tasks at a given level.
Since our Wordpress is rather a “service” in terms of ECS, we’ll launch it like this:
The task will hang in the “Pending” state for some time (you still need to download, build and run two containers) and will switch to “Running”:
Everything, you can take the address of our virtual machine in EC2 and open it in a browser:
Less than 100 years have passed, as Amazon has noticed, having released its new service, Amazon EC2 Container Service, at the end of 2014 to beta. The general meaning of the service is to give the opportunity to deploy Docker-containers in a convenient way. “Convenient” means, without need to delve into the insides of the Docker, and generally do something with your hands in the console of the host machine. You simply create a new cluster, add virtuals to it, on which the containers will work, and then indicate how many and which containers you need to run. Everything else (the choice on which machine to run the container, access rights, port forwarding) Amazon takes over. In addition, you can use the entire Amazon infrastructure from the Docker container - save files on S3, use SQS queues, fasten Amazon Amazon load balancer at the input, and Amazon logs and analytics services at the output. Containers can “see” each other, share (or not share) resources, start and be stopped from the AWS console (manually or according to specified rules).
')
Let's try to launch something in the Amazon EC2 Container Service. For example, we will lift Wordpress + Mysql.
In principle, you can go here , click the “Get started” button and go through the wizard, which will guide you through the process of setting up a cluster and tasks, but I personally don’t like this approach - you don’t see the power of the system and the flexibility of settings. Close the wizard. Open the "Clusters" tab , on which we do not yet have a single cluster.
Well, let's create one!
And open:
So, we see that the cluster is created and is in the active state, although nothing is happening in it yet. Well, it is no wonder - we have not given him any tasks so far. In order for everything to turn out, we need to tell the cluster what tasks and on which machines it should perform.
ECS Instances
These are EC2 virtualkeys that you will allocate for cluster operation. You can run any number of any type of virtual machines in one cluster. Well, not any, the limit is 1000 machines per cluster, it should be enough? There are only two requirements for the machine: a Docker must be installed there and an Amazon ECS Container Agent must be installed there - this is a utility from Amazon for managing the cluster. The source is open - github.com/aws/amazon-ecs-agent . Put simply:
touch /etc/ecs/ecs.config mkdir -p /var/log/ecs docker run --name ecs-agent -d -v /var/run/docker.sock:/var/run/docker.sock -v /var/log/ecs:/log -p 127.0.0.1:51678:51678 --env-file /etc/ecs/ecs.config -e ECS_LOGFILE=/log/ecs-agent.log amazon/amazon-ecs-agent But, in general, installing Docker and the agent on a more or less standard Linux is a trivial and uninteresting task, so Amazon has already made images for virtual machines with all necessary, here they are:
| Region | AMI Name | AMI ID |
|---|---|---|
| us-east-1 | amzn-ami-2015.03.b-amazon-ecs-optimized | ami-d0b9acb8 |
| us-west-2 | amzn-ami-2015.03.b-amazon-ecs-optimized | ami-6b88b95b |
| eu-west-1 | amzn-ami-2015.03.b-amazon-ecs-optimized | ami-ed7c149a |
| ap-northeast-1 | amzn-ami-2015.03.b-amazon-ecs-optimized | ami-c6c609c6 |
| ap-southeast-2 | amzn-ami-2015.03.b-amazon-ecs-optimized | ami-39017e03 |
So, we need to run at least one such virtual machine from the EC2 control panel :
In the previous step, you may need to create an IAM User, IAM Role, and VPC. What is it, why and how it is created can be read here .
In the next step, make sure that the security rules allow access to port 80 (we were going to pick up WordPress, do you still remember?):
We are waiting for a couple of minutes until our virtual machine goes into the “Running” state:
Now on the tab of our cluster we can see the node added to it:
If you need more cars - it's time to start them, but one is enough for us.
Tasks
Tasks are a description of what will actually work in our cluster. The task includes one or several associated Docker containers, a description of their environment, their resource requirements, mount points, port mapping, launch parameters, etc. Here is a task that describes two related Docker containers: one for Wordpress and one for Mysql.
{ "containerDefinitions": [ { "name": "wordpress", "links": [ "mysql" ], "image": "wordpress", "essential": true, "portMappings": [ { "containerPort": 80, "hostPort": 80 } ], "memory": 300, "cpu": 10 }, { "environment": [ { "name": "MYSQL_ROOT_PASSWORD", "value": "password" } ], "name": "mysql", "image": "mysql", "cpu": 10, "memory": 300, "essential": true } ], "family": "hello_world" } Let's briefly describe what's where:
- name - the name of the container. Used to reference one container to another.
- links - link of one container to another. Note that the Wordpress container refers to Mysql, which means that it can open the port of the database server without an additional port mapping.
- image - link to the container repository on Docker Hub. In the example above, we expand two images: registry.hub.docker.com/_/wordpress and registry.hub.docker.com/_/mysql
- essential — marks the container’s “criticality”. The stopping of the “critical” container can be the reason for stopping the whole task (and its possible restarting). Stopping the “non-critical” container does not affect anything
- portMappings - forwarding ports from a container to a host machine. In the example above, we open the 80th port
- memory, cpu - requirements for free resources of the host machine. Memory is counted in megabytes, but the processor resources are in conditional parrots, of which 1024 are allocated for each virtual kernel. Those. you can run two containers with cpu = 500 on a single-core machine, but the third one will not start
- environment - environment variables passed to the container
There are more parameters in the documentation , some of them (entryPoint, cmd, mountPoints) are taken directly from the Docker documentation.
Let's add the task described above:
Now you need to run the task. This can be done on our cluster page, in two ways:
- Run the task as such (Cluster-Tasks-Run new task- <choose our task> -Run task)
- Start a service consisting of our task (Cluster-Services-Create- <choose a task, name of the service, number of tasks> -Create service)
One would think that the difference is that the service allows you to set several tasks to start, but not - this can be done in the first method. The difference is in the concept: in the first case, it is considered that we are launching some “background” task, which must work out and die. In the second case, we are raising some service, which must be accessible from the outside for a long time, so firstly for the service we can immediately turn on the Elastic Load Balancer, and secondly, fallen tasks (and even failed virtuals) will re-raise the service so that maintain the number of active tasks at a given level.
Since our Wordpress is rather a “service” in terms of ECS, we’ll launch it like this:
The task will hang in the “Pending” state for some time (you still need to download, build and run two containers) and will switch to “Running”:
Everything, you can take the address of our virtual machine in EC2 and open it in a browser:
Source: https://habr.com/ru/post/258657/
All Articles