Hoje falaremos sobre o que é SCM e contaremos algumas histórias cujo prisma será considerado Ansible, SaltStack, Chef e Puppet, escolhendo a melhor opção para uma tarefa específica.
O material é baseado na transcrição de um
relatório de Andrei Filatov , engenheiro líder de sistemas da EPAM Systems, da conferência DevOops 2017 de outubro de 2017.
O que é SCM e com o que ele come?
O que é SCM? Antes de tudo, é algo que permite que nossa infraestrutura do estado A execute o estado B. Ao executar algum tipo de código, muitos desenvolvedores que não são engenheiros de DevOps na prática acham que algo está acontecendo de alguma maneira "automática" em infraestrutura.
O método "automático" implementa o SCM (System Configuration Management). Para que é isso? Principalmente para construir infraestruturas repetíveis e consistentes. O SCM estende bem os processos de CI / CD. Como esse é um código, ele pode ser armazenado em qualquer sistema de controle de versão: Git, Mercurial. É bastante simples de desenvolver e manter.
A final é um ciclo fechado de automação: tudo pode ser feito automaticamente, desde a criação da infraestrutura até a implantação e implantação do código.
O que é SCM: Ansible
Considere nossos candidatos. O primeiro é Ansible. Ele tem uma arquitetura sem agente; se estamos falando de uma versão de código aberto, ela é escrita em Python, possui uma DSL semelhante a Yaml, é facilmente extensível devido a módulos escritos em Python, é muito simples e leve. O Ansible tem o limite de entrada mais baixo - você pode ensinar qualquer um.
Há experiência em que uma pessoa que não conhecia Python, não sabia nada sobre SCM, entrou no Ansible em apenas dois dias e já começou a fazer alguma coisa.
Abaixo está um exemplo de ChatOps: um notificador no Slack. O código Ansible que viu Yaml não é novidade.
- block: - name: "SlackNotify : Deploy Start" local_action: module: slack token: "{{ slack_url }}" attachments: - title: "Deploy to {{ inventory_hostname }} has been Started" text: "<!here> :point_up_2:" color: "#551a8b" - include: configure.yml tags: - configure - include: remote-fetch.yml tags: - remote - include: assets.yml
O que é SCM: Chef
Chef é uma arquitetura cliente-servidor, há um servidor Chef e um cliente Chef. A configuração baseada em pesquisa, escrita em Ruby, possui Ruby DSL. Assim, dentro de seus livros de receitas e receitas, você pode usar todo o poder do Ruby, mas eu não aconselho fazer isso. O Chef tem uma comunidade enorme e o maior conjunto de ferramentas entre todos os SCMs. É assim que o código do Chef se parece: é a implantação do Jetty.
O que é SCM: SaltStack
O SaltStack possui uma arquitetura sem agente que funciona no modo push usando Salt-SSH e uma arquitetura cliente-servidor quando há Salt-master e Salt-minion. A ênfase está na automação em tempo real, execução paralela imediata de todos os processos e escrita em Python. Também uma linguagem semelhante ao Yaml, o código é muito semelhante ao Ansible.
#ntp-packages: pkg.installed: - pkgs: - ntp - ntpdate #/etc/ntp.conf: file: - managed - source: salt:
O que é SCM: Puppet
O último dos nossos licitantes é o Puppet. Ele também possui uma arquitetura cliente-servidor, como Chef, a configuração não é baseada em pesquisa, mas nos "fatos" que acompanham o Puppet-master, escrito em Ruby, possui uma DSL semelhante a Ruby. Mas os caras do Puppet não têm permissão para usar o código Ruby puro em seus manifestos. Isso é um mais e um menos. É assim que o código do manifesto do Puppet se parece:
class { 'mysql::server' : root_password => 'password' } mysql::db{ ['test', 'test2', 'test3']: ensure => present, charset => 'utf8', require => Class['mysql::server'], } mysql::db{ 'test4': ensure => present, charset => 'latin1', } mysql::db{ 'test5': ensure => present, charset => 'binary', collate => 'binary', }
SCM na prática
SaltStack em um ambiente desmilitarizado
Antes de mais, gostaria de compartilhar um projeto que foi escrito no SaltStack. Este é o nosso projeto anterior e a dor mais recente, e a dor mais recente é sempre a mais dolorosa. Nosso cliente está envolvido no armazenamento de dados - essa é a produção de servidores de ferro para armazenamento de dados no GPFS, GlusterFS, mas compilações personalizadas. Ele veio até nós com as seguintes tarefas:
- Criando um instalador de USB / DVD. Você precisa criar uma mídia a partir da qual tudo está instalado. Isso é feito para clientes clientes que moram em áreas fechadas, onde os servidores geralmente não têm Internet. Precisamos incluir um ISO, enviar para os engenheiros de campo que implementarão tudo o que é necessário no local.
- Implante um cluster de produtos. Os clientes têm vários produtos de grande porte, precisamos poder implantá-los no modo de cluster.
- Gerenciamento, configuração e manutenção do cluster usando o utilitário CLI. Nossa estrutura deve ajudar os engenheiros de campo a gerenciar o cluster.
O cliente tinha vários requisitos. Primeiro de tudo, ele possui uma enorme experiência em Python, na verdade apenas desenvolvedores de C e Python. O cliente disse imediatamente: "Queremos o SaltStack", não deixando escolha.
O que estamos enfrentando? O cliente possui vários produtos na instalação, todos devem estar com a Salt-Masters. Mas estamos diante do problema de dimensionar a configuração do Multi-Master. Por exemplo, no NODE Info (o status de um servidor específico), selecionamos milissegundos com uma configuração de dois mestres, segundos com três mestres e com cinco nunca esperamos a conclusão da operação. O MultiMaster é um bom recurso, mas não escala bem.
O segundo problema que encontramos foi o trabalho em equipe: o SaltStack possui Runner e Module. O módulo é uma extensão que roda no Salt Minion, no lado da máquina. O corredor é executado no lado do servidor. Muitas vezes tivemos batalhas: o que fazer Runner e o que fazer Módulos.
Então encontramos uma pequena surpresa do cache.mine:
ime = ImeActions() id = __grains__['id'] if id == ime.master_id: ret = __salt__['mine.get'](id, 'ime_actions.make_bfs_uuid') ime_dict = ret.get(id, None) if not ime_dict: try: result = __salt__['mine.send']('ime_actions.make_bfs_uuid') except Exeption, e: log.error("Failed to generate uuid: {0}.".format(str(e))) result = False else:
Temos um utilitário que está escrito em C. Nós o rodamos, ele gera um ID aleatório. Ele deve ser único entre todos os participantes do cluster, respectivamente. Precisamos fazer isso uma vez no mestre e distribuí-lo entre as máquinas. Usamos cache.mine para isso. Como se viu, ele não está passando por uma reinicialização.
"Condição de corrida". A paralelização é boa, mas na configuração básica state.orchestrate entra state.sls está sendo executado se ocorrerem longos processos. Com o tempo limite, ele acredita que o Estado já tenha concluído, embora ainda esteja em execução, e esteja tentando iniciar o próximo. Ocorre um erro. E esse problema ainda não foi corrigido.
Você pode
olhar para o GitHub .
O que poderíamos usar além do SaltStack?
SaltStack em um ambiente DMZ
- DMZ Chef pacotes grandes, Puppet também. E com o Ansible, o problema é - se não houver torre - não há como iniciar a configuração no modo Pull a partir de nossos nós, o que deve ser feito na zona desmilitarizada.
- Framework para CLI (em Python). Chef e Puppet não são muito adequados, mas se você não tiver restrições para usar apenas Python, poderá escrever em Ruby e usar as APIs Chef ou Puppet. O kit de ferramentas Ansible não suporta isso.
- Gerenciamento de cluster. O Chef é adequado para gerenciar clusters, o Puppet também e o Ansible foi originalmente escrito para gerenciar clusters na Amazon.
Chef em um ambiente amplo e dinâmico
O cliente teve a tarefa de consolidar todos os recursos em uma nuvem - foi o Openstack. Antes disso, tudo estava disperso: algo na Rackspace Cloud, algo em servidores dedicados ou em seus data centers privados.
Eles queriam um gerenciamento de recursos totalmente dinâmico e também para que seus aplicativos pudessem adicionar capacidade a si mesmos, se necessário. Ou seja, precisamos de uma infraestrutura dinâmica completa e de um ambiente totalmente dinâmico, tanto para cima quanto para baixo.
Para criar adequadamente o processo do CD, você precisa de um ambiente totalmente automatizado. Criamos o SDLC - Software Development Lifecycle para eles e o aplicamos, inclusive para o SCM. Eles passam nos testes de integração não apenas de aplicativos, mas também de infraestrutura.
Dessa forma, quando algo der errado conosco, nós, como os caras da Netflix, poderemos matar recursos defeituosos e restaurar trabalhadores novos e garantidos em seu lugar.
Que problemas encontramos:
- Foi em 2013, utilizado o Chef 10, em que uma busca lenta. Iniciamos a busca, percorrendo todos os carros e levou uma eternidade. Tentamos resolver o problema com a convenção de nomenclatura, assim como a seleção e a pesquisa de fqdn. Isso reduziu o escopo da pesquisa, devido à qual ela foi acelerada.
Mas algumas operações precisam ser realizadas em todo o ambiente. Dessa forma, a pesquisa foi executada uma vez no início, o resultado foi armazenado no atributo e, usando Ruby, filtramos os resultados: analisamos as peças necessárias e fizemos o que era necessário.
if !Chef::Config[:solo] search(:node, "fqdn:*metro-#{node[:env]}-mongodb*").each do |mongo| @mongodbs << mongo.fqdn end else @mongodbs = ["lvs-metro-#{node[:env]}-mongodb3001.qa.example.com"] end
Conclusão: use convenções de nomenclatura, execute a pesquisa uma vez, use Ruby para filtrar os resultados desejados.
- Usar "node.save" não é seguro, tenha cuidado e cuidado. Encontramos esse problema ao implantar clusters MySQL e usamos node.save dentro da receita em um nó MySQL incompletamente configurado. E no momento da expansão, alguns aplicativos deram um erro de 500. Descobrimos que estávamos salvando o nó na hora errada: ele vai para o servidor Chef, ali mesmo, o cliente Chef na interface do usuário pega um novo nó que não foi configurado antes do modo operacional.
- A falta de "splay" pode matar o servidor do chef. Splay é um parâmetro do cliente Chef que permite definir o intervalo quando o cliente vai ao servidor para configuração. Com uma carga pesada, quando você precisa implantar muitos nós ao mesmo tempo, isso não mata o servidor.
O que podemos usar em vez de chef?
- Provisionamento dinâmico O SaltStack é perfeito porque possui o SaltCloud que se integra perfeitamente em qualquer lugar. O Puppet tem funcionalidade semelhante, mas só está disponível no Puppet Enterprise, por dinheiro. O Ansible é adequado se a empresa "vive" na Amazônia, se houver algo mais - você pode associá-lo a alternativas, mas não é tão conveniente.
- SDLC. O Chef tem tudo, desde o Test Kitchen até a escolha de ferramentas para testes de integração. O SaltStack tem todas as ferramentas Python disponíveis, agora o Puppet tem tudo. O Ansible tem uma especificação de função, você pode usar a cozinha de teste do Chef, mas não é uma ferramenta nativa.
- Substituição de recursos. Tudo está bem no Chef, no SaltStack você pode finalizar o SaltCloud no estado desejado, nas ferramentas Puppet estão apenas na versão Enterprise e o Ansible funciona bem apenas com a Amazon.
Nuvem Privada EPAM com Chef
Um ano e meio antes do advento do AWS OpsWorks, queríamos criar um Amazon CloudFormation avançado, integrando o Chef para que os recursos não fossem apenas implantados, mas também configurados.
A segunda tarefa global é criar um catálogo de serviços para que clientes e usuários possam usar a CLI para implantar uma pilha LAMP completamente pronta para uso, por exemplo.
Escolhemos o Chef, mas o projeto teve que suportar diferentes SCMs. Começamos com o Chef-Server interno, e os usuários também podem usar o próprio Chef-Server, que é hospedado em algum lugar com eles. Ou seja, não tivemos acesso aos recursos do usuário e laptops, mas funcionou de qualquer maneira.
Qualquer SCM pode ser usado para implementar o CloudFormation + OpsWork, todos são adequados. Para criar um catálogo - todos, exceto o SaltStack, farão isso bem. O SaltStack tem suas nuances: é extremamente difícil encontrar um especialista que conheça bem o SaltStack e possa criar um serviço e preencher o catálogo.
A popularidade do SCM no EPAM
Estas são estatísticas da popularidade do SCM no EPAM. O SaltStack está muito atrás. Em primeiro lugar, Ansible, é o mais simples e com um baixo limite de entrada. Quando tentamos encontrar alguém no mercado com conhecimento de SCM, o mercado se parece com o mesmo.
Trabalhar com Ansible
Dicas que posso dar ao trabalhar com o Ansible:
- Use 'accelerate', ele implementa configurações 2-6 vezes mais rápido que o SSH (para el6). Para todos os outros, há 'pipelining'. Ele está desativado para compatibilidade com versões anteriores, mas ativar o pipelining novamente é muito fácil, eu recomendo fazê-lo.
- Use 'with_items'
- name: project apt dependencies installed apt: name: "{{ item }}" become: yes with_items: - build-essential - acl - git - curl - gnupg2 - libpcre3-dev - python-apt - python-pycurl - python-boto - imagemagick - libmysqlclient-dev
Neste exemplo, instalamos pacotes, esse esquema pode ser usado para criar usuários e operações semelhantes.
- Use com cuidado 'local_action' e 'delegated'. O primeiro permite que você obtenha algo semelhante ao SaltStack Runner, o segundo é capaz de delegar tarefas a máquinas específicas.
- name: create postgresql database postgresql_db: name: "{{ database_name }}" login_host: "{{ database_host }}" login_user: "{{ database_master_user }}" login_password: "{{ database_master_password }}" encoding: "UTF-8" lc_collate: "en_US.UTF-8" lc_ctype: "en_US.UTF-8" template: "template0" state: present delegate_to: "{{ groups.pg_servers|random}}"
Este é um pedaço de criação de banco de dados. Sem a última linha, a operação seria executada várias vezes e caiu na segunda tentativa de criar o mesmo banco de dados.
- Otimize suas funções e desempenho com tags. Isso pode reduzir significativamente o lead time.
Conclusões
Para mim, Ansible é um favorito. O SaltStack é muito bom, muito flexível, mas requer conhecimento de Python, sem eles o SaltStack é melhor não usar. Chef é uma bala de prata universal para qualquer tarefa e qualquer escala, mas requer mais conhecimento do que o Ansible. E quem usa Puppet - eu não sei. Em princípio, é muito semelhante ao Chef, mas com suas próprias nuances.
Minuto de publicidade. Se você gostou deste relatório da conferência DevOops - observe que em 14 de outubro o novo DevOops 2018 será realizado em São Petersburgo, haverá muitas coisas interessantes em seu programa. O site já tem os primeiros oradores e relatórios.