Como tornar sua infraestrutura de TI chata

Michael DeHaan é o homem que criou o Ansible. Muitas das coisas que os administradores de sistemas, engenheiros de lançamento e DevOps fazem regularmente são, para dizer o mínimo, desinteressantes. DeHaan quer que essas pessoas liberem seu tempo para coisas mais interessantes (no trabalho ou fora da porta do escritório) e escrevam um código de produto que libere o tempo do administrador.
Mais tempo, menos adrenalina durante o horário comercial, menos scripts e menos erros.
A propósito, você pode terminar de ler este parágrafo conectando-se à transmissão ao vivo em 6 de junho aqui .



Se você ainda continuasse lendo ...

Responsável: Integração e Entrega Contínuas

Ansible é uma poderosa linguagem de automação de código aberto. Sim, é ótimo não apenas para gerenciamento, mas também para a implantação e orquestração de sistemas de TI. O Ansible foi criado originalmente para resolver efetivamente uma ampla gama de tarefas de automação e como uma base universal simples para substituir os controles tradicionais, mas no final acabou sendo muito útil em muitas áreas. Por exemplo, garantindo zero tempo de inatividade durante a integração contínua e a entrega de aplicativos (CI / CD). Geralmente, esse problema é resolvido devido ao refinamento extensivo do software, ao uso de vários pacotes de software e a muitos truques exclusivos de cada configuração específica. O Ansible foi originalmente projetado especificamente para esses cenários de orquestração e oferece uma solução pronta para uso "tudo em um".

Integração contínua e entrega de aplicativos (CI / CD)

Algumas verdades comuns. A prática de desenvolver sistemas de software nos últimos 10 anos mostra que o longo ciclo de vida das versões de software (modelo de desenvolvimento em cascata) tem uma sobrecarga muito maior em comparação com um ciclo curto (o chamado desenvolvimento "iterativo" ou ágil). É uma questão de arritmia: quando os programadores estão começando a trabalhar em uma nova versão, simplesmente não há nada para a equipe de TI responsável pelos testes e pela implantação. Porém, quanto mais próxima a versão do lançamento, mais profissionais de TI estão ocupados e mais frequentemente os programadores precisam alternar entre contextos, alternando entre trabalhar em bugs e planejar a próxima versão.

Além disso, um longo ciclo aumenta o intervalo entre a identificação e a eliminação de erros e deficiências de software, o que é especialmente crítico para grandes sistemas da web com um público de usuários multimilionário. Portanto, a indústria de software está adotando rapidamente metodologias ágeis sob o slogan "liberar mais rápido e com mais frequência", para que os participantes no processo de desenvolvimento possam mudar seu contexto de trabalho com menos frequência e criar, depurar e implementar melhorias e inovações muito mais rapidamente.

A automação do controle de qualidade, o desenvolvimento do TDD por meio de testes e outras técnicas relacionadas aumentam ainda mais a eficácia dos novos métodos de trabalho. Onde está a automação? Onde estão as tecnologias que tornam as engrenagens mais rápidas e reduzem a participação humana ao mínimo estritamente necessário?

E aqui, por exemplo, a Ansible e a Ansible Tower da Red Hat para orquestrar sistemas de TI como parte dos modernos processos de desenvolvimento de software.

Zero tempo de inatividade

Um pouco mais óbvio. Tempo de inatividade significa lucros perdidos e clientes insatisfeitos. Portanto, em sistemas de enfileiramento da Web, cujos usuários estão distribuídos em todos os fusos horários, o desligamento agendado é permitido apenas em casos realmente graves, cuja lista claramente não inclui a atualização de versões de aplicativos. A situação é semelhante em ambientes corporativos, onde a inacessibilidade de uma intranet ou sistema de contabilidade reduz drasticamente a produtividade dos funcionários. Portanto, qualquer automação de processo deve fornecer atualizações sem interromper as operações - em outras palavras, com tempo de inatividade zero.

É bem possível obter tempo de inatividade zero, mas para isso precisamos de ferramentas apropriadas - como fornecer orquestração avançada, em vários níveis e vários estágios, como, por exemplo, o sistema Ansible.

Sistemas de criação de aplicativos

A entrega contínua (CD) começa com a integração contínua (IC). Um sistema que monitora os repositórios de códigos-fonte em busca de alterações, executa independentemente os testes correspondentes e cria automaticamente (e testa, idealmente) uma nova versão do aplicativo a cada atualização de código, por exemplo, o projeto Jenkins (jenkins.io).

Para retransmitir o bastão para o sistema de CD após criar com êxito uma nova versão do aplicativo, o subsistema de criação do sistema de CI pode chamar Ansible para fornecer imediatamente essa nova versão para aqueles que executam testes de unidade ou integração. Em particular, Jenkins pode usar o Tower para implantar montagens em vários ambientes, e o ambiente de teste ou intermediário pode ser modelado com base no ambiente de produção, o que melhora bastante a previsibilidade ao longo do ciclo de vida do software. Os dados retornados pela Ansible a partir dos resultados da execução de scripts de automação podem estar diretamente envolvidos nas tarefas Build Systems do sistema Tower. De fato, o Tower ainda permite testar cenários de implantação em um ambiente intermediário antes de executá-los em servidores de "combate".

Atualização de aplicativo multinível, um por um

O sistema de CD deve ser capaz de orquestrar os processos de atualização sem interrupção de aplicativos multiníveis. Graças à arquitetura push e aos recursos da orquestração de vários níveis, o Ansible pode lidar com essa tarefa atualizando qualquer nível de aplicativo por nível e trocando dados entre eles.

Para implementar atualizações um por um, o Ansible usa scripts Play que permitem especificar com precisão o grupo de hosts de destino e atribuir tarefas (Função) que devem ser executadas neles. As tarefas geralmente são anúncios de que um recurso de TI específico deve estar em um determinado estado, por exemplo, para uma versão do software, um pacote específico deve ser instalado e, para outra, é necessário verificar o repositório de códigos. As topologias de aplicativos da Web, como regra, exigem atualizá-las em ordem estrita, e você ainda não pode atualizar aplicativos e configurações do sistema em todas as máquinas ao mesmo tempo.

Quando o serviço é reiniciado, ele permanece indisponível por algum tempo e a substituição da versão do aplicativo também não ocorre instantaneamente. Portanto, antes de atualizar o sistema, o retiramos do pool de balanceamento. Como resultado, você precisa automatizar as operações de conexão e desconexão de máquinas do pool. Consistentemente é a palavra-chave. O Ansible pode controlar com muita precisão o tamanho da janela de uma atualização sucessiva. Bem, o desenvolvimento dessas atualizações é realizado com muito cuidado e, em algum momento, ocorre uma falha, a atualização é suspensa para não desativar o restante da infraestrutura de TI.

Implantação contínua para scripts de automação

Além da funcionalidade de CD para serviços que operam no modo de operação comercial, você também pode organizar a implantação contínua de scripts de automação (conjuntos de instruções do Ansible Playbook. Não pare de ler, na segunda parte, haverá exemplos de playbooks). Isso permite que administradores de sistema e desenvolvedores gerenciem scripts usando o repositório de código-fonte, testem esses scripts em um ambiente intermediário e os transfiram automaticamente para o ambiente de produção em caso de invasão bem-sucedida. Em outras palavras, ao trabalhar com scripts, você obtém todas as vantagens metodológicas e outras do repositório de códigos central ao qual está acostumado ao desenvolver software.

Fazer alterações nas configurações de software e sistema é um dos principais motivos de interrupções não planejadas. Portanto, além dos testes automatizados, há controle humano. Ele pode ser organizado integrando-se a um sistema de inspeção de código como o Gerrit , e aplicando as alterações somente depois de aprovadas pelos camaradas responsáveis.

Atualizações alternativas e sistemas de balanceamento de carga

O Ansible funciona de maneira muito independente com os sistemas de balanceamento de carga ao executar atualizações sucessivas. Portanto, você pode simplesmente escrever em um script do Playbook, em qualquer ciclo para um grupo de hosts, algo como "executar esta ação no sistema X em nome do host Y", e o Ansible cuidará do resto.

O Ansible interage bem com balanceadores de carga de todos os tipos e pode definir um sinalizador para desconectar temporariamente um host, a fim de desativar o monitoramento de disponibilidade durante o período de atualização. O esquema simples "desligar o monitoramento - remover do pool - atualizar o nível de software desejado - retornar ao pool - ativar o monitoramento" implementa facilmente uma atualização seqüencial com tempo de inatividade zero e sem alarmes falsos. E tudo isso em um modo totalmente automatizado, sem intervenção do operador.

Teste Intermediário Integrado

O Tower pode trabalhar com vários arquivos de inventário de recursos (Inventory), o que facilita o teste de cenários de atualização sucessivos em um ambiente intermediário antes de executá-los em servidores "de batalha". Para fazer isso, basta simular o ambiente de produção no ambiente de teste, executar Ansible com o parâmetro “-i” e indicar qual arquivo de inventário deve ser usado ao executar o script - no ambiente de teste ou no ambiente de produção. O script em si não precisa ser modificado.

Implantação do Controle de Versão

Algumas pessoas gostam de empacotar aplicativos juntamente com pacotes de SO (RPM, debs etc.) mais quentes, mas geralmente, especialmente para aplicativos da Web, esse empacotamento não é necessário. Portanto, o Ansible inclui vários módulos para implantar aplicativos diretamente dos sistemas de controle de versão. No script Playbook, você pode escrever uma reconciliação com o repositório de códigos para a marca ou número de versão especificado, após o qual o Ansible verificará essa condição em todos os servidores de destino e ativará as próximas etapas apenas se a versão precisar ser substituída, eliminando assim a reinicialização desnecessária do serviço.

Integração com ferramentas de monitoramento

Como um sistema de orquestração completo, o Ansible suporta a integração com sistemas de gerenciamento de desempenho de aplicativos baseados em APM no nível de monitoramento. Por exemplo, durante a fase de teste de implementação ou integração, você deve instalar ou atualizar o agente de software APM com o aplicativo. O Ansible tem uma função especial para isso e, após instalar e ativar o agente, o Ansible pode configurá-lo na pilha de monitoramento do APM (se ainda não estiver configurado) para que os gerentes de aplicativos possam verificar imediatamente se a nova versão foi instalada e funciona sem problemas. .

Se algo der errado após a atualização do aplicativo no ambiente de produção, as ferramentas de monitoramento podem chamar Ansible para reverter para a versão anterior. Obviamente, apenas se essa reversão for permitida.

Notificação de evento

No paradigma de CI / CD, todos desejam receber notificações de eventos o mais rápido possível. O Ansible oferece ambas as funções integradas, incluindo um módulo de e-mail, além de integração com ferramentas de notificação externas, como mensageiros instantâneos, redes sociais ou sistemas de registro de eventos.

Implantação usando um modelo de estado de recurso

Um dos principais recursos do Ansible, que o torna uma ferramenta muito útil para implantar aplicativos, é o uso regular do modelo de estado de recurso nos processos de atualização de software, que ganhou popularidade no gerenciamento de configurações do sistema. Ao contrário dos controles tradicionais de código aberto, o Ansible não precisa estar equipado com nenhum software adicional ou scripts especiais para organizar a entrega do aplicativo.

No Ansible, você pode registrar e controlar com precisão a ordem dos eventos em diferentes níveis da arquitetura, o que permite delegar ações a outros sistemas, bem como combinar diretivas do modelo de recursos (como "o pacote X deve estar no estado Y") e comandos de script tradicionais (como "executar script .sh ") dentro de um processo.

O Ansible também facilita a execução de verificações de várias condições e a tomada de decisões com base em seus resultados. A combinação dos processos de configuração do sistema e implantação de aplicativos em uma única cadeia de ferramentas é muito mais eficiente que um esquema com várias ferramentas especializadas e, além disso, aumenta a consistência das políticas e aplicativos do SO.

Teste de implantação

Quanto mais oportunidades, maior a responsabilidade. A automação de processos de entrega contínua aumenta drasticamente o risco de implantar uma configuração com falha em todos os nós do sistema. Para reduzir os riscos, o Ansible sugere inserir testes de controle no script, o que interromperá a atualização seqüencial se algo der errado. Para testar várias condições, incluindo o status do funcionamento dos serviços, você pode implantar testes arbitrários usando os módulos Comando ou Script e até criar testes como módulos Ansible separados.

O módulo Fail pode interromper a execução do script no host a qualquer momento, o que permite detectar falhas no estágio inicial da atualização seqüencial. Por exemplo, devido à diferença entre o ambiente intermediário e o ambiente de produção, o último gera um erro de configuração, que desativa os servidores de "combate". Nesse caso, uma saída de emergência pode ser registrada no script Playbooks no primeiro estágio da atualização seqüencial. E se você tiver 100 servidores e o tamanho da janela de atualização sucessiva for 10, essa parada de emergência dará a você tempo para descobrir com calma, corrigir o script e continuar a atualização.

No caso de uma falha, o Ansible não continua funcionando, deixando os sistemas em um estado semi-configurado e gera um erro para atrair a atenção do operador e informar a ele em quais hosts o ciclo de atualização ocorreu com erros e quantas alterações foram feitas em cada plataforma. O Ansible possui um modo de execução de simulação, quando o sistema gera um relatório sobre quais alterações teriam sido feitas se o script tivesse sido executado sem sua execução real.

Verificação de conformidade

Existem ambientes em que as configurações mudam apenas quando não há como não existir. Quaisquer alterações nesses ambientes são pré-analisadas. Utiliza sistemas de entrega contínua "com reservas".

O Ansible possui um modo de execução de simulação (ativado pelo sinalizador "--check"), quando o sistema gera um relatório sobre quais alterações seriam feitas quando o script fosse executado. Nesse caso, a execução real do script não ocorre, a execução da simulação não permite a captura de erros, mas ajuda a entender e analisar melhor os detalhes e os resultados das alterações propostas.

Por outro lado, mesmo com a implantação contínua de novos assemblies, o Ansible permite executar verificações de conformidade com muito mais frequência para capturar o momento em que algumas coisas no ambiente de produção mudam como resultado da intervenção humana e precisam ser corrigidas executando o script Ansible correspondente, por exemplo, para alterar versão do software, ajustar permissões, etc.

Implantação do piloto automático

Se você mora em um mundo de orquestração de vários estágios em vários níveis de processos sequenciais de atualização de software com tempo de inatividade zero, o CI / CD provavelmente é executado exclusivamente por operadores (manualmente e com automação parcial) e exige, como em uma rodada, ações coordenadas de todos os participantes do processo. O Ansible, juntamente com sua arquitetura exclusiva e a ausência de agentes de software nos hosts de destino (aumentando a segurança e eliminando a necessidade de gerenciar o próprio sistema de gerenciamento), pode facilmente descrever e automatizar processos de implantação complexos, ou seja, o Ansible implementa aqui o modo de piloto automático completo.

Exemplos de scripts de automação Ansible podem ser encontrados no GitHub , e agora daremos uma base e um exemplo de como escrever um script do Playbook que pode ser executado no Ansible ou no Ansible Tower. Juntamente com uma lista de módulos e outros documentos, ela ajudará você a aprender como criar seus próprios scripts de Playbooks.

O que é um manual?

Um script do Playbook é essencialmente um conjunto de execuções enviadas para execução em um único host remoto ou grupo de hosts. É como um guia de montagem de móveis da IKEA: siga as instruções exatamente e obtenha exatamente o que você viu na loja. É assim que os scripts funcionam.

Módulos

Criaremos um Playbook que instalará o servidor da web no host RHEL / CentOS 7 e criaremos um arquivo index.html nele, com base no modelo especificado no script. O script de exemplo mostrado aqui está totalmente operacional e pronto para uso. Abaixo, veremos um exemplo de script do Playbook e mostraremos como usar os módulos.

Autores (Autores)

Um autor é alguém que cria instruções que serão executadas por módulos (geralmente juntamente com valores adicionais: argumentos, locais etc.). Os módulos são executados no host de destino na ordem em que seguem o script do Playbook (incluindo include'y e outros arquivos adicionais incluídos nele). O estado do host muda (ou não muda), dependendo dos resultados da execução do módulo, que são exibidos na forma de saída Ansible e Tower.

Execução de script do Playbook

Primeiro, há algumas coisas que você precisa saber sobre a execução de scripts do Playbook. O Playbook é um tipo de sistema simbólico que informa o módulo sobre a necessidade de executar alguma tarefa. Para iniciar com êxito o seu Playbook, é importante entender os seguintes pontos:

1. Sistema de destino (Target)
Como os scripts do Playbook fornecem instruções e interagem com os módulos, o Ansible acredita que você entende o que está tentando fazer e o automatiza. É por isso que dizemos que os Playbooks são como instruções ou instruções: você diz aos elementos automatizados como deseja configurar a tarefa. Mas, ao mesmo tempo, você precisa entender muito bem como o host de destino no qual o script do Playbook é executado está funcionando.

2. Tarefas
Se você precisar iniciar um servidor Web em alguma parte do Playbook, precisará entender como isso é feito para saber qual módulo de serviço usar para isso e iniciar o servidor Web por nome. Se o Playbook instalar o pacote de software, você deve saber como fazer isso no host de destino. Você também deve entender, pelo menos em um nível básico, a essência das tarefas executadas. É necessária uma configuração de host adicional para o software que você deseja instalar? Existem ramificações dependendo das condições e valores dos argumentos? Se alguma variável for passada no processo, você deverá entender exatamente o que e por quê.

Exemplo de script do manual
O exemplo de script do Playbook a seguir ajudará você a entender o que acabou de ler. O host de destino é o servidor RHEL / CentOS 7, no qual nosso script instala o servidor da web NGINX e, em seguida, cria o arquivo index.html no diretório padrão da raiz da web.Após concluir a instalação e criar o índice, o servidor da web é iniciado.

* Nota: Para executar este exemplo de script do Playbook no Ansible Tower, você deve primeiro configurar o inventário e as contas.

Os Playbooks começam com três hífens YAML (---), seguidos por:

Nome : simplesmente o nome do script para preservar a legibilidade do Playbook.

Hosts : Uma lista de hosts de destino nos quais o Ansible deve trabalhar.

Torne - se : aqui escrevemos uma declaração verdadeira para garantir que o nginx seja instalado sem problemas (esse campo nem sempre é obrigatório).

1 --- 2 - name: Install nginx 3 hosts: host.name.ip 4 become: true 

Com o recuo como nas três linhas anteriores, há as tarefas : diretiva, após a qual, com recuo adicional (de acordo com as regras de aninhamento de YAML), as tarefas são listadas (reproduzidas). Neste exemplo, temos duas tarefas e ambas usam o módulo Yum. A primeira tarefa adiciona um repositório epel-release para que você possa instalar o nginx. Depois que o epel aparece no sistema, a segunda tarefa instala o pacote nginx.

A diretiva state : significa que o Ansible deve verificar o estado do host de destino antes de executar outras ações. Em nosso exemplo, se já existe um repositório ou nginx no host, o Ansible entende que não é necessário executar essas duas tarefas e prossegue para o seguinte.

 1 tasks: 2 - name: Add epel-release repo 3 yum: 4 name: epel-release 5 state: present 6 7 - name: Install nginx 8 yum: 9 name: nginx 10 state: present 

A página de download, que é usada por padrão no nginx, é ótima para verificar se o nginx foi instalado corretamente, mas você provavelmente desejará fazer isso usando o arquivo html start. Neste exemplo, por simplicidade, o modelo do arquivo de índice está no mesmo diretório em que o Playbook é iniciado. O destino é apenas o caminho padrão no nginix sem sites configurados.

 1 - name: Insert Index Page 2 template: 3 src: index.html 4 dest: /usr/share/nginx/html/index.html 

A última linha do nosso Playbook serve apenas para verificar se o serviço nginx foi iniciado com êxito (ou para iniciá-lo, se não).

 1 - name: Start NGiNX 2 service: 3 name: nginx 4 state: started 

Todo o script do Playbook tinha aproximadamente o mesmo tamanho do parágrafo de abertura deste post:

 1 --- 2 - name: Install nginx 3 hosts: host.name.ip 4 become: true 5 6 tasks: 7 - name: Add epel-release repo 8 yum: 9 name: epel-release 10 state: present 11 12 - name: Install nginx 13 yum: 14 name: nginx 15 state: present 16 17 - name: Insert Index Page 18 template: 19 src: index.html 20 dest: /usr/share/nginx/html/index.html 21 22 - name: Start NGiNX 23 service: 24 name: nginx 25 state: started 

Sumário

Os scripts do Playbook são uma maneira fácil e conveniente de fazer muitas coisas com um pouco de código. No exemplo acima, usamos três módulos - yum, modelo e serviço, para instalar o repositório e o pacote de software no servidor, criar um arquivo a partir do modelo local e iniciar o serviço que acabou de ser instalado. Ao mesmo tempo, nosso script do Playbook saiu um pouco mais do que esta oferta! E, embora o rodássemos em um host, ele também poderia ser executado em dezenas e centenas de servidores; para isso, é necessário fazer apenas pequenas alterações. Além disso, o Tower permite colocar um script do Playbook em um modelo de trabalho para executar em um grupo de servidores na nuvem da AWS ou em um data center corporativo.

Os recursos arquiteturais possíveis e a capacidade de integração com os sistemas de CI, como o Jenkins, automatizam não apenas os processos de gerenciamento de configuração, mas também uma gama muito maior de tarefas de TI. É por isso que chamamos carinhosamente o Ansible de um sistema de orquestração integrado, e não apenas uma ferramenta de gerenciamento de implantação e configuração de software.