Estamos usando o Ansible para lançar atualizações de segurança em todas as instâncias do EC2 que executam serviços com estado, como bancos de dados, mecanismos de pesquisa, etc. Isso funciona bem.
Gostaria de saber qual é a melhor maneira de fazer atualizações de segurança nas instâncias do ECS (que estão executando aplicativos da Web sem estado em contêineres do Docker). Devido ao dimensionamento automático, há muita dinâmica no número de instâncias e seus endereços IP. O Ansible usa uma lista codificada de endereços IP (o arquivo hosts), então parece não se encaixar no propósito.
É mesmo uma boa ideia atualizar essas instâncias ou devemos preferir reduzi-las e gerar novas de vez em quando?
Quais são as melhores práticas do pessoal do DevOps por aí?
Atualização:
Descobri que o Ansible suporta inventário dinâmico. Existe um um script que busca informações sobre os hosts da AWS e gera uma dinâmica inventário para Ansible, isso funciona bem.
No entanto, um problema permanece. Sempre que houver um novo host ao qual eu não estava conectado antes, a seguinte mensagem será exibida e deverá ser confirmada manualmente.
The authenticity of host '10.0.1.247 (10.0.1.247)' can't be established.
ECDSA key fingerprint is SHA256:GSogs6P6CzbOzLm9ByWsXkfz7/2A4qwj4PDvczApS/I.
Are you sure you want to continue connecting (yes/no)? yes
Isso é muito chato, pois quero implementar um mecanismo de atualização totalmente automatizado. Existe uma solução para este problema?
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?
Modifique as ssh_connection do ansible.cfg , para que elas contenham -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null arguments.
Por exemplo:
[ssh_connection]
ssh_args = -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes -o ControlMaster=auto -o ControlPersist=60s
Atualizar um contêiner no lugar é um anti-padrão completo. É complicado, pois você precisa atualizar cada um deles e possivelmente comprometer cada um deles.
Em vez disso, atualize a imagem usada para gerar seus contêineres. Isso normalmente é feito com uma seção no seu Dockerfile para garantir que a imagem esteja atualizada, então o processo de correção é basicamente reconstruir a imagem. Como exemplo:
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
Continuando a nova imagem, porém, é onde eu acho falta ECS. Você precisa criar uma estratégia para garantir que não haja tempo de inatividade.
Também é uma prática recomendada ter um serviço varrendo as imagens do seu registro em busca de vulnerabilidades.
Corrigir o SO do host (que pode exigir uma reinicialização) sem tempo de inatividade, é outra área em que achei o ECS sem recursos de orquestração, como em, nada pronto para ser incluído no produto que não seja o balanceamento ELB entre nós.
Outras plataformas de contêiner (como o OpenShift) têm a capacidade de evacuar contêineres ( pods, já que este é o kubernetes) dos nós e agendá-los em outro lugar. O balanceador de carga está ciente dessas alterações, garantindo tempo de inatividade zero . Além disso, o sistema operacional normalmente usado com o OpenShift possui um mecanismo de correção aprimorado baseado em RPM OSTree que reduz bastante a complexidade do patch do sistema operacional host.