No caso de ser de interesse de qualquer pessoa, eu acho que, no mínimo, posso dar um relatório de experiência do usuário tendo feito meu primeiro uso do recurso de envio do Ansible no contexto de gerenciamento de patches de configurações de multi-host da missão sistemas críticos na nuvem da Amazon.
Para entender meus preconceitos ou vieses, devo explicar que tenho uma preferência por Ruby no nível de script de automação e configurei projetos para usar configuração de puppet de agente mestre por projeto-Vpc no passado. Então minha experiência desmente preconceitos do passado, se houvesse algum.
Minha experiência recente foi muito favorável ao envio dinâmico para um estado de mudança de dezenas a centenas de servidores que podem ser ampliados ou desativados, finalizados e atualizados. Na minha situação, um simples comando ad hoc do Ansible 1.7 era tudo o que eu precisava para fazer o patch. No entanto, tendo em vista a eficácia da criação de um AnsibleController (em um t2.micro) por VPC para o efeito, no futuro, pretendo expandir a técnica para requisitos mais complexos.
Então deixe-me retornar à pergunta feita neste tópico: prós e contras de empurrar em uma propriedade que muda dinamicamente.
As suposições do tipo de propriedade de servidor que eu almejei eram:
- Nenhuma suposição de que endereços IP ou nomes de host locais gerados pela Amazon sejam duradouros - eles podem entrar e sair
- Todas as instâncias foram criadas a partir de imagens de máquinas que já tinham a capacidade de tornar o acesso ssh possível a partir de um único usuário administrativo privilegiado
- Para individualizar servidores e particioná-los em grupos, de acordo com a função ou de acordo com o estágio de desenvolvimento (por exemplo, teste ou prod), isso seria feito através do lançamento de tags específicas da Amazon de nomes convencionais acordados
- O patch seria administrar servidores Linux e Windows separadamente, com diferentes comandos ad hoc, portanto, permitir que os logins específicos do Linux falhem ao entrar em contato com um servidor Windows era perfeitamente aceitável
Com essas condições em mente, criar uma imagem de máquina de um AnsibleController para incluir vários Vpcs e configurar (com credenciais) in situ dentro das contas de servidor existentes é muito simples. Automatizado em cada instância criada a partir da imagem é
- Um cron job para enviar o patch para os servidores em execução em intervalos regulares, para que o estado necessário seja acessado continuamente em intervalos
- Uma maneira de calcular o inventário Ansible em cada intervalo.
O segundo item pode ser relativamente sofisticado, se necessário (através da estrutura Info do inventário Ansible). Mas, se a sofisticação não for necessária, aqui está um exemplo muito simples de um script para calcular todas as instâncias do Amazon EC2 em cada intervalo do cron e direcionar os resultados para um arquivo de inventário apropriado (por exemplo, /etc/ansible/hosts)…
#!/bin/bash
# Assumes aws-cli/1.3.4 Python/2.6.9 Linux/3.4.73-64.112.amzn1.x86_64 or greater
# http://aws.amazon.com/releasenotes/8906204440930658
# To check yum list aws-cli
# Assumes that server is equipped with AWS keys and is able to access some or all
# instances in the account within it is running.
# Provide a list of host IPs each on a separate line
# If an argument is passed then treat it as the filename, whether local or absolute
# path, to which the list is written
function list-of-ips {
/usr/bin/aws ec2 describe-instances --filters '[ {"Name": "instance-state-code", "Values": [ "16" ] } ]' | grep -w PrivateIpAddress | awk '{x=$2; gsub("\"","", x); gsub(",","", x); if(x && FNR!=1){print x;}}' | uniq
}
if [ -n "$1" ]; then
list-of-ips > "$1"
else
list-of-ips
fi
A única ressalva para o caso de uso é que o comando patch deve ser idempotente. É desejável fazer um pré-teste para garantir que isso seja satisfeito, como parte de garantir que o patch faça exatamente o que se pretende.
Então, para resumir, ilustrei um caso de uso em que o push dinâmico é eficaz contra as metas que defini. É uma solução repetível (no sentido de ser encapsulado em uma imagem que pode ser implementada em várias contas e regiões). Na minha experiência, até hoje, a técnica de push dinâmico é muito mais fácil de fornecer - e entrar em ação - do que as alternativas disponíveis nos conjuntos de ferramentas disponíveis no momento.