Every time I submit a batch job, does a new Docker container get created or the old container will be reused.
If a new Docker container is created every time, what happens to the container when the job is done.
In AWS ECS, ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION variable sets the time duration to wait from when a task is stopped until the Docker container is removed(by default 3 hours)
If all these containers only get cleanup after three hours, wouldn't the ECS container instance get filled up quick easily if I submit a lot of jobs?
Getting this error CannotCreateContainerError: API error (500): devmapper when running a batch job. Does it help if I clean up the docker container files at the end of the job?
Every time I submit a batch job, does a new Docker container get created or the old container will be reused.
Yes. Each job run on Batch will be run as a new ECS Task, meaning a new container for each job.
If all these containers only get cleanup after three hours, wouldn't the ECS container instance get filled up quick easily if I submit a lot of jobs?
This all depends on your job workloads, lengths, of jobs, disk usage, etc. With large quantities of short jobs that consume disk, this is entirely possible.
CannotCreateContainerError: API error (500): devmapper
Documentation for this error indicates a few possible solutions, however the first, which you've already called out may not help in this case.
ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION which defaults to 3h on ECS, seems to be set to 2m by default on Batch Clusters - you can inspect the EC2 User Data on one of your batch instances to validate that it is set this way on your clusters. Depending on the age of the cluster, these settings may change. Batch does not automatically update to the latest ECS Optimized AMI without creation of a whole new cluster, so I would not be surprised if it does not change settings either.
If your cleanup duration setting is currently set low, you might try creating a custom AMI which provisions a larger than normal docker volume. By default, the ECS optimized AMIs ship with an 8GB root drive, and 22GB volume for docker.
Related
I'm spinning up a docker container once a day on an EC2 instance to run some scheduled tasks. I've noticed over time that the unused docker containers will use up disk space. Occasionally, the EC2 will raise a failure because of a lack of disk space.
In this case I generally run the command docker system df to see how much disk space docker is using on the EC2, and then run docker system prune to remove all those unused containers and free up disk space.
I'd like to be able to automate the second command, however I probably want to retain logs for a couple of days/weeks.
Is there a way to schedule / have filtering so say like "remove unused docker containers older than X number of days. or only keep 30 unused containers, remove the oldest one when we reach the limit of 30.?
I am trying to automate Autoscaling system in AWS.
Normal deployment for us is just checking code into Gitlab and creating a new Tag, then Gitlab CI\CD runs automatically and pushes the code up to artifactory. we have 3 instances. we autosclaue up to 6 and then reduces it to 3.But then we just need to scale out our auto scaling group in AWS, and it builds 3 new servers that pull the new code down, and then scale the ASG back out, killing the 3 old servers. I want to automate this process. Can anyone help me if we can achieve this after deployment
There is a new feature called "Instance Refresh" that will probably do what you want. You just need to call the StartInstanceRefresh API and give the MinHealthy% (which determines the batch size) and the warmup time (which determines the time between batches).
If will terminate and launch the instances in a batch at about the same time, so unless you're ok with a bit of downtime, probably leave the MinHealthy% at the default of 90% so that it only does 1 instance per batch
https://docs.aws.amazon.com/cli/latest/reference/autoscaling/start-instance-refresh.html
I have setup a batch environment with
Managed Compute environment
Job Queue
Job Definitions
The actual job(docker container) does a lot of video encoding and hence uses up most of the CPU. The process itself takes a few minutes (close to 5 minutes to get all the encoders initialized). Ideally I would want one job per instance so that the encoders are not CPU starved.
My issue is when I launch multiple jobs at the same time or close enough, AWS batch decides launch both of them in the same instance as the first container is still initializing and has not started using CPUs yet.
It seems like a race condition to me where both jobs see the instance created as available.
Is there a way I can launch one instance for each job without looking for instances that are already running? Or any other solution to lock an instance once it is designated for a particular job?
Thanks a lot for your help.
You shouldn't have to worry about separating the jobs onto different instances because the containers the jobs run in are limited in how many vCPUs they can use. For example, if you launch two jobs that each require 4 vCPUs, Batch might spin up an instance that has 8 vCPUs and run both jobs on the same instance. Each job will have access to only 4 of the vCPUs, so performance should be identical to a job running on its own with no other jobs on the instance.
However, if you still want to separate the jobs onto separate instances, you can do so by matching the vCPUs of the job with the instance type in the compute environment. For example, if you have a job that requires 4 vCPUs, you can configure your compute environment to only allow c5.xlarge instances, so each instance can run only one job. However, if you want to run other jobs with higher vCPU requirements, you would have to run them in a different compute environment.
I am conceptually trying to understand how to use AWS ECS to run my "cluster" jobs.
I have some scientific software inside a Docker container, that natively takes advantage of as many cores as the underlying instance has to offer.
My question in this case is, can I use AWS ECS to "increase" the number of "visible" cores to the task running inside my Docker container. For instance, is my "cluster" limited to only a single instance? Or is a "cluster" expandable to multiple instances?
I haven't been able to find any answers my looking through he AWS docs.
Cluster is just some EC2 instances that are ECS-enabled (are running special agent software) and grouped together. Tasks that you run on this cluster are spread across these instances. Each task can involve multiple containers. However, each container stays within its instance ‘boundaries’, hardware-wise. It is allocated a number of “CPU units” and shares them with other containers running on the same instance.
From my understanding, running a process spanning multiple cores in a container is not quite fitting ECS architecture idea—it seems like trying to do part of ECS’s scheduler job.
I found these resources useful when I was reading about it:
My notes on Amazon's ECS post by Jérôme Petazzoni
Application Architecture in ECS docs
Task Definition Parameters in ECS docs
I had a similar situation moving a Python app that used a script to spawn copies of itself based on the number of cores. The answer to this isn't so much an ECS problem as it is a Docker best practice... you should strive to use 1 process per container. (see https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/)
How I ended up implementing this was using a Dockerfile to run each process and then used essential ECS tasks so it will reload itself if the task died.
Your cluster is a collection of EC2 instances with the ECS service running. Each instance has a certain number of CPU 'units' (typically 1024 units === 1 core) and RAM. I profiled my app at peak load and tweaked the mix until I got it where I liked it. If your app can use more CPU than that, try giving it 2048 CPU or some other amount and see how it performs. I used Meros (https://meros.io/) to profile my app.
Hope this helps!
"increase" the number of "visible" cores to the task running inside my Docker container
Container and cluster is different things, you may run lot of containers on one instance, but you can't run one container on multiply instances.
Cluster - it is set of docker containers.
is my "cluster" limited to only a single instance?
no, you may choose number of instances in cluster
I am programming some short-lived EC2 instances. They will exist for only a few hours to do a job every now and again but will require a very large EBS volume; to keep it around all the time would cost hundreds of dollars a month. Because EBS volumes are pro-rated, I can just allocate this volume when I need it and discard it after the job is complete so the cost will not be all that high (EBS volumes are billed hourly after all).
Unfortunately the elastic file store is not yet available in my region, and it's also in a preview mode at the moment so probably not suitable for production use yet anyway.
Anyway, that's really just background. What I'd like to do is is have my instance automatically configure itself when it is started using user data. I would like it to download a script from an S3 repository that instructs it to install chef-client and execute a chef-client run that will set up the node. It will then run another command which will kick off the job. Once that's complete, the AWS Data Pipeline will automatically terminate the instance.
The one point I don't like about the above is that when I register the node, the node will be registered in my Chef server. I'd like to just download the configuration for a specified role without actually registering anything. I'll never need to run the configuration again because the instance will be gone in a couple of hours once the job is complete.
I could of course script the entire setup and execution of the above using shell scripts but I'd rather tie it in with all the Chef infrastructure we've already built, which is integrated with our CI server and is fully source-controlled and so on.
You could use chef-provisioning and/or knife-zero.
They start a chef-zero in-memory server locally, then bootstrap a node which connects through the SSH connection back to your local chef-zero server. After the converge, the connection is shut down. It's much like rsync+chef-solo but on steroids.
See:
https://github.com/higanworks/knife-zero
https://github.com/chef/chef-provisioning
https://github.com/chef/chef-provisioning-aws