Respostas:
Eu nunca usei o Ansible, mas há algumas semanas tento descobrir como o Ansible pode ser bom em comparação com os scripts de shell - o que prova, pelo menos no meu caso, que as campanhas publicitárias assustadoras que eles executam são eficazes! Depois de muitas tentativas malsucedidas - o que prova como a documentação deles falha em responder a uma das perguntas mais óbvias - acho que finalmente consegui:
Agora, vamos assistir ao vídeo de introdução e passar aleatoriamente como um potencial novo usuário através do material de introdução ao Ansible e compará-lo com o que um programador de shell especializado pode produzir imediatamente.
Minha conclusão é que, em scripts de shell, o Ansible oferece essencialmente 1. A possibilidade de verificar se um sistema concorda com o estado desejado, 2. a capacidade de integrar-se ao Ansible Tower, que é um sistema pagador que parece incluir habilidades de monitoramento. Em alguns casos importantes, como na implementação do padrão imutável do servidor, o ponto 1 provavelmente não é muito útil, portanto a lista é bastante fina.
Minha conclusão é que os benefícios oferecidos pelo Ansible sobre o script de shell, conforme a documentação os apresenta, podem ser sensíveis em alguns poucos casos otimistas bem cobertos pelos módulos disponíveis, mas são pequenos ou até hipotéticos no caso geral. Para um programador de shell experiente, provavelmente, esses benefícios provavelmente serão contrabalançados por outros aspectos do trade-off.
Mas isso talvez comprove o quão ruim é o material de introdução!
Há um vídeo de início rápido . Começa com uma página alegando que ... bem, essas não são realmente reivindicações, são listas de marcadores, um artefato comumente usado para suspender o julgamento crítico em apresentações (como a lógica não é mostrada, não pode ser criticada!)
1.1 Automação legível por humanos - As especificações são documentos técnicos, como poderia
name: upgrade all packages
yum:
name: '*'
state: latest
ser mais fácil de ler do que a chamada yum correspondente encontrada em um shell-script? Além disso, qualquer pessoa que tenha tido contato com o AppleScript morre de rir ao ler "automação legível por humanos".
1.2 Nenhuma habilidade especial de codificação é necessária - O que é codificação se não houver especificações formais? Eles têm condicionais, variáveis, então, como não está codificando? E por que eu precisaria de algo que não posso programar, que passaria a ser inflexível? A afirmação é felizmente imprecisa!
1.3 Tarefas executadas em ordem - Bem, talvez alguns aficionados por codegolfe estejam cientes de linguagens que executam tarefas em desordem, mas a execução de tarefas em ordem dificilmente parece excepcional.
1.4 Torne-se produtivo rapidamente - os programadores de shell qualificados são produtivos agora. Esse contra-argumento é tão sério quanto o argumento inicial.
Um truque popular do vendedor para vender artefatos é enganar as pessoas, acreditando que elas adquirirão o "poder" desses artefatos. A história da propaganda de carros ou bebidas isotônicas deve fornecer uma lista convincente de exemplos.
Aqui, o Ansible pode fazer "implantação de aplicativo" - mas o shell script certamente faz, "gerenciamento de configuração", mas esta é uma mera declaração do objetivo da ferramenta, não um recurso, e "orquestração de fluxo de trabalho", que parece um pouco pretensiosa, mas nenhum exemplo é necessário. além do que o GNU Parallel pode fazer.
Para preencher a coluna, eles escreveram de três maneiras diferentes que isso só precisa de ssh, o que, como todos sabem, é um daemon e não tem nada a ver com esses agentes que permeiam o gerenciamento de configuração mundial!
O restante do vídeo apresenta inventários, que são listas estáticas de recursos (como servidores) e demonstram como implantar o Apache em três servidores simultaneamente. Isso realmente não corresponde à minha maneira de trabalhar, onde os recursos são altamente dinâmicos e podem ser enumerados pelas ferramentas de linha de comando fornecidas pelo meu provedor de nuvem e consumidas pelas minhas funções de shell usando o |operador de tubulação . Além disso, eu não implanto o Apache em três servidores simultaneamente; construo uma imagem de instância principal que eu uso para iniciar 3 instâncias que são réplicas exatas uma da outra. Portanto, a parte "orquestradora" da argumentação não parece muito pertinente.
O EC2 é o serviço de computação da Amazon, interagindo com ele é suportado por algum módulo Ansible . (Outros fornecedores populares de computação em nuvem também são fornecidos):
# demo_setup.yml
- hosts: localhost
connection: local
gather_facts: False
tasks:
- name: Provision a set of instances
ec2:
key_name: my_key
group: test
instance_type: t2.micro
image: "{{ ami_id }}"
wait: true
exact_count: 5
count_tag:
Name: Demo
instance_tags:
Name: Demo
register: ec2
O shell-script correspondente seria essencialmente idêntico ao YAML substituído por JSON:
provision_a_set_of_instances()
{
aws --output=text ec2 run-instances --image-id …
}
ou a versão JSON
provision_a_set_of_instances()
{
aws --output=text ec2 run-instances --cli-input-json "$(provision_a_set_of_instances__json)"
}
provision_a_set_of_instances__json()
{
cat <<EOF
{
"ImageId": …
}
EOF
}
Ambas as versões são essencialmente idênticas, a maior parte da carga útil é a enumeração dos valores de inicialização em estruturas YAML ou JSON.
A maior parte deste guia não exibe nenhum recurso realmente interessante: ele apresenta variáveis (IIRC, scripts de shell também possuem variáveis) !, e um módulo Ansible lida com mysql, de modo que, em vez de pesquisar “como criar um usuário mysql” com privilégios em XY "e termine com algo como
# Create Application DB User
mysql --host "${mysql_host}" --user "${mysql_user}" --password "${mysql_password}" "${mysql_table}" <<EOF
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%';
EOF
você pesquisa “como eu crio um usuário mysql com privilégios no XY em ansible ” e termino com
- name: Create Application DB User
mysql_user: name={{ dbuser }} password={{ upassword }}
priv=*.*:ALL host='%' state=present
A diferença ainda provavelmente não é muito significativa. Nessa página, também descobrimos que o Ansible possui uma linguagem de meta-programação de modelos
{% for host in groups['monitoring'] %}
-A INPUT -p tcp -s {{ hostvars[host].ansible_default_ipv4.address }} --dport 5666 -j ACCEPT
{% endfor %}
Quando vejo isso, eu realmente estou na minha zona de conforto. Esse tipo de metaprogramação simples para linguagens declarativas é exatamente o mesmo paradigma teórico que o BSD Makefiles! O que aconteceu por ter programado extensivamente Este trecho mostra que a promessa de trabalhar com o arquivo YAML está quebrada (portanto, não posso executar meus playbooks através de um analisador YAML, por exemplo ). Também mostra que Ansible deve discutir a arte sutil da ordem de avaliação: temos que decidir se as variáveis são expandidas na "parte declarativa" da linguagem ou na meta-parte "imperativa" da linguagem. Aqui a programação do shell é mais simples, não há metaprogramação, além do fornecimento explícito eval ou externo de scripts. O hipotético trecho equivalente do shell seria
enumerate_group 'monitoring' | {
while read host; do
…
done
}
cuja complexidade em comparação com a variante Ansible é provavelmente tolerável: ela usa apenas as construções simples, regulares e chatas da linguagem.
Por fim, encontramos o que acaba por ser o primeiro recurso realmente interessante do Ansible: “Os recursos do Ansible são modelos do estado desejado. Como tal, não deve ser necessário testar se os serviços foram iniciados, os pacotes estão instalados ou outras coisas assim. Ansible é o sistema que garantirá que essas coisas sejam declarativamente verdadeiras. Em vez disso, afirme essas coisas nos seus playbooks. ”Agora isso começa a ser um pouco interessante, mas:
Além de várias situações padrão prontamente implementadas pelos módulos disponíveis, terei que alimentar os bits implementando o teste, o que provavelmente envolverá alguns comandos do shell.
A verificação da conformidade das instalações pode não ser muito relevante no contexto em que o padrão imutável do servidor é implementado: onde todos os sistemas em execução normalmente são gerados a partir de uma imagem principal (imagem da instância ou imagem do docker, por exemplo) e nunca são atualizados - eles são substituídos por novo em seu lugar.
O material introdutório da Ansible ignora a questão da manutenção. Com praticamente nenhum sistema de tipos, o shell-scripting tem a facilidade de manutenção de JavaScript, Lisp ou Python: refatorações extensas só podem ser alcançadas com sucesso com a ajuda de um amplo conjunto de testes automatizados - ou pelo menos projetos que permitem testes interativos fáceis. Dito isto, embora o script de shell seja a língua franca da configuração e manutenção do sistema, quase cada linguagem de programação possui uma interface com o shell. Portanto, é totalmente viável aproveitar a vantagem de manutenção de linguagens avançadas, usando-as para colar os vários bits de bits de configuração de shell. Para OCaml, escrevi Rashell que essencialmente fornece uma mão de padrões de interação comuns para subprocessos, o que torna a tradução de scripts de configuração no OCaml essencialmente trivial.
No lado do Ansible, a estrutura muito fraca dos playbooks e a presença de um recurso de metaprogramação tornam a situação essencialmente tão ruim quanto é para scripts de shell, com os pontos negativos de que não é óbvio como escrever testes de unidade para o Ansible , e o argumento de introduzir ad-hoc uma linguagem de nível superior não pode ser imitado.
A documentação do Ansible chama a atenção sobre a necessidade de escrever etapas de configuração idempotentes. Mais precisamente, as etapas de configuração devem ser escritas para que a sequência de etapas aba possa ser simplificada para ab , ou seja, não precisamos repetir a etapa de configuração. Essa é uma condição mais forte que a idempotência. Como o Ansible permite que os playbooks usem comandos arbitrários do shell, o próprio Ansible não pode garantir que essa condição mais forte seja respeitada. Isso depende apenas da disciplina do programador.
Quando você coloca dessa maneira, mesmo que o Ansible tenha algumas vantagens inerentes, os benefícios do uso de ferramentas conhecidas (nesse caso, scripts de shell) devem ser superados. Eu não acho que haja uma resposta clara para isso.
Se a equipe conseguir o que o Ansible oferece com shell:
então eles provavelmente poderiam ficar com o que sabem.
Afinal, você pode implementar "guardas" no BASH. Você pode encontrar muitos trabalhos existentes do BASH por aí para resolver uma variedade de tarefas de configuração do servidor (essencialmente qualquer arquivo Dockerfile disponível com 90% de código de instalação do bash). Você pode se aproximar bastante do que o Ansible / Salt / Chef-Zero oferece a você, sem precisar transportar toda a solução existente para essas ferramentas.
É um ato de equilíbrio entre as tendências do NIH (não inventadas aqui) e lançar scripts bons e estabelecidos em favor de uma solução mais robusta.
Uma consideração final a ter em mente: como a sua tecnologia se comporta quando você tenta recrutar mais pessoas para a equipe. Encontrar pessoas com experiência em Ansible é muito mais fácil do que encontrar pessoas que tenham experiência em sua ferramenta específica de criação de scripts de criação em casa. Esta não é uma consideração estritamente técnica, mas cultural. Você quer ser a organização estranha que inventa o seu próprio Ansible ou deseja ser a organização razoável que encontra a ferramenta certa para o trabalho? Essas decisões afetam sua capacidade de atrair talentos.
A resposta acima cobre parte dela, mas perde um dos elementos importantes: design convergente. Escrevi algumas palavras há um tempo atrás sobre isso no contexto do Chef em https://coderanger.net/thinking/, mas a versão curta é que um script bash é um conjunto de instruções, enquanto um manual Ansible (ou receita do Chef, Salt state, etc) é uma descrição do estado desejado. Ao documentar o estado desejado em vez das etapas que você deseja executar para chegar lá, você pode lidar com muito mais estados iniciais. Esse foi o coração da Teoria da Promessa, conforme descrito no CFEngine, há muito tempo, e um design que nós (as ferramentas de gerenciamento de configuração) todos copiamos desde então.
O código ansible diz o que você quer, o código bash diz como fazer uma coisa.
É importante notar que você terá menos problemas ao executar seus playbooks ansible em hosts remotos também. Como é a principal razão para a execução do ansible. Quando você está usando scripts de shell, ainda precisa ter uma maneira de criar scripts da scp'ing para o host remoto.
É 2019 e passei alguns dias em uma curva de aprendizado ansiosa e aqui está a verdade absoluta: Ansible não vale a pena.
não está concluído, não é executado no Windows e a combinação de configuração do YAML e mensagens de erro enganosas fará com que seus olhos sangrem. Parece quase deliberadamente terrível e quero dizer isso seriamente. É claramente o produto de um projeto frustrado do desenvolvedor do sysadmins. Provavelmente um hipster.
Se você não precisar de nenhum desses recursos além do provisionamento, e estará provisionando apenas um SO em particular. Pelo amor de Deus, escreva um shell.script decente.
A partir de agora, todo o projeto me lembra dos primeiros fóruns do Linux, onde os noobs foram informados ao RTFM e zombaram de perguntar por que alguém não podia escrever uma GUI para definir as configurações gráficas. Você simplesmente não entende, não é? Deveria manter-se nas janelas ... talvez eu acasale ... feliz em ver.
Use o Docker. Em preferência a qualquer coisa. O Docker é escandalosamente simples e poderoso.
Mas e se você precisar absolutamente fornecer estanho pré-existente? Quais são as alternativas reais?
Bem ... ainda não há. Mas eu prometo a você que, a menos que o ansible melhore, haverá em breve. Porque não importa o quão duro os fanboys o pressionem, e perdoe suas falhas ... são 5 em 10 por esforço.
SCP acima um script bash, e salve-se o problema.