Best way to install security updates on amazon ECS instances
Upgrading a container in place is a complete anti-pattern. It is cumbersome, as you need to upgrade each one of them and possibly commit each one of them.
Instead, update the image used to spawn your containers. This is normally done by having a section on your Dockerfile
to ensure the image is up to date, so the process of patching is basically rebuilding the image. As an example:
FROM centos:7.2.1511
MAINTAINER Jane Doe <[email protected]>
RUN yum update -y && \
yum install -y \
bar \
foo && \
yum clean all
# The rest of your Dockerfile
Rolling out the new image, though, is where I find ECS lacking. You need to build an strategy yourself to ensure no downtime.
It is also a best practice to have a service scanning the images in your registry for vulnerabilities.
Patching the host OS (which might require a reboot) without downtime, is yet another area where I found ECS lacking orchestration capabilities, as in, nothing out of the box is built into the product other than ELB balancing between nodes.
Other container platforms (such as OpenShift) have the ability of evacuating containers (pods,since this is kubernetes) from nodes, and scheduling them elsewhere. The load balancer is aware of this changes, ensuring zero downtime. Additionally,the OS typically used with OpenShift has an improved patching mechanism based on RPM OSTree that greatly reduces the complexity of patchingthe host operating system.
Whenever there is a new host that I had not connected to before, the following message is displayed and must be confirmed manually. [ ] Is there a solution for this problem?
Modify the ssh_connection
of the ansible.cfg
, so that it contains -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null
arguments.
For example:
[ssh_connection]
ssh_args = -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes -o ControlMaster=auto -o ControlPersist=60s