Não é falso dizer que as melhores pessoas
obter alegria através do sofrimento.
Ludwig van Beethoven

Sou Sergey, trabalho na Yandex.Money em uma equipe de pesquisa de desempenho. Quero contar o início de uma história sobre o caminho para usar a orquestração - como escolhemos instrumentos e o que levamos em conta. Todos os eventos do artigo acontecem em tempo real, para que vocês, queridos leitores, acompanhem o desenvolvimento da situação quase ao vivo.
Por que precisamos de um condutor na equipe?
Quem é um condutor? De fr. diriger - gerencie, dirija, conduza - no mundo da música - essa é uma pessoa, líder do aprendizado e performance da música ensemble. No nosso caso, esse local é ocupado por sistemas de orquestração e automação.
O papel deles não é diferente do papel do maestro na música - eles são necessários para ajudar a equipe, dirigir e organizar sua peça.
Como regra, uma equipe tem um certo conjunto de capacidades - vamos chamá-las de servidores nos quais eles implementam seus projetos.
A abordagem para obter e operar esses servidores é diversa. Alguns exemplos:
- A equipe faz uma solicitação, por exemplo, ao grupo de operações, para fornecer recursos com determinados parâmetros.
- O grupo de operação fornece a quantia necessária - nuvem ou bare metal (“bare metal”) - e compromete-se a mantê-los em boas condições, de acordo com o SLA. O ajuste também é realizado pela equipe de operações.
- A equipe recebe apenas recursos de nuvem ou bare metal do grupo de operações e executa suas próprias configurações.
- A própria equipe "compra" recursos e os suporta / os configura de forma totalmente independente.
Nossa equipe usa servidores que precisam de suporte - atualize o sistema operacional, instale novos pacotes, etc.
Nós mesmos os distinguimos em dois tipos principais:
- grupo tanque
- grupo de serviço.
O grupo de tanques consiste em hosts com o Yandex.Tank.
O grupo de serviços inclui tudo relacionado à manutenção - esses são vários serviços para fornecer suporte ao ciclo de liberação, gerar relatórios automáticos etc.
A certa altura, tornou-se inconveniente gerenciar tudo isso manualmente, e pensamos em automatizar todo o processo, começando pelo “preenchimento” dos servidores e finalizando com o desenvolvimento, o layout e o lançamento do nosso serviço interno.
Por que é necessário um maestro, mesmo que a própria orquestra possa tocar?
Para começar, dominamos o Ansible e começamos a "derramar" nossos servidores bare metal para ser menos dependente dos administradores de sistema - todos ganham aqui, adquirimos novas habilidades e aliviamos os administradores da parte do trabalho que eles sempre têm sem a gente. Nós nos esforçamos para desenvolver nossa equipe fora de nossa especialidade e autonomia, tanto quanto possível.
A empresa trabalha com a Ansible há muito tempo, já configurada e regulamentada, por isso integramos facilmente nossa solução nesse processo.
A hospedagem agora consiste em três funções Ansible:
- a primeira função instala o sistema operacional,
- o segundo rola configurações básicas para o host, autorização LDAP, por exemplo,
- e o terceiro instala o Yandex.Tank e dependências relacionadas no contêiner do docker.
Vamos seguir para os serviços que usamos dentro da equipe.
Para nossas tarefas, usamos igualmente Kotlin e Python, e um pouco mais de Golang. Para unificar o desenvolvimento e a implantação de nossos serviços, decidimos embalá-los em contêineres de encaixe. Isso dá liberdade para escolher uma linguagem de programação e, ao mesmo tempo, regula o formato de entrega uniforme de sua aplicação.
Alguns dos serviços com os quais interagimos estão disponíveis apenas via ipv6, então tive que descobrir como fazer o ipv6 para contêineres.
De acordo com a documentação do ipv6 no site oficial do Docker, o ipv6 é ativado adicionando parâmetros ao daemon.json:
{ "ipv6": true, "fixed-cidr-v6": "2001:db8:1::/64" }
Nesse caso, o provedor deve emitir a sub-rede ipv6, que você fixed-cidr-v6.
em fixed-cidr-v6.
No entanto, escolhemos outra opção - NAT do ipv6, e aqui está o porquê:
- Agora, a janela de encaixe não pode ser usada apenas com o ipv6.
- A presença de um endereço roteável globalmente em cada contêiner significa que todas as portas (mesmo as não publicadas) ficam disponíveis para todos se a filtragem adicional não for realizada.
- proxy da userland para portas de publicação, iptables apenas para ipv4 .
O ipv6 NAT é um contêiner de docker que gerencia as regras em ip6tables e as edita quando um novo contêiner é adicionado.
Para que essa solução funcionasse corretamente, várias manipulações precisavam ser feitas. Certifique-se de inicializar ip6table_nat no sistema. A presença de um módulo instalado no sistema não garante que, na inicialização, o módulo seja carregado no kernel. Descobrimos isso quando recebemos esse erro ao iniciar um contêiner com NAT em um novo host:
2019/01/22 14:59:54 running [/sbin/ip6tables -t filter -N DOCKER --wait]: exit status 3: modprobe: can't change directory to '/lib/modules': No such file or directory ip6tables v1.6.2: can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?)
O problema foi resolvido após adicionar a inicialização à função Ansible usando o módulo modprobe e carregá-lo na inicialização usando lineinfile:
- name: Add ip6table_nat module modprobe: name: ip6table_nat state: present - name: Add ip6table_nat to boot lineinfile: path: /etc/modules line: 'ip6table_nat'
A propósito, há um bom artigo sobre o Haber, que descreve de forma breve e clara as vantagens e desvantagens de um método específico para trabalhar com o ipv6 no docker.
Mas voltando à nossa pergunta feita no começo:
Por que é necessário um maestro, mesmo que a própria orquestra possa tocar?
Agora todo mundo sabe como jogar em nossa equipe:
- o processo de "preenchimento" dos servidores é criado,
- desenvolvimento e implantação de serviços são unificados.
Surge uma pergunta razoável - como implantar, atualizar, controlar nossos serviços em contêineres de encaixe de forma eficiente e automatizada possível?
Apesar do fato de que cada membro da orquestra conhece sua parte, ele pode se perder, afastar-se da idéia original. Aqui chegamos ao fato de que sem um maestro nossa orquestra não ensaiará nem tocará harmoniosamente. O condutor é responsável por todos os parâmetros de desempenho, por garantir que tudo esteja unido por um único ritmo e humor.
Como obter um bom condutor com um investimento mínimo?
O tema da orquestração é bem desenvolvido no mercado. Mas primeiro, vamos falar sobre ferramentas de suporte que podem ajudar o condutor.
O Consul é um sistema que fornece duas funções principais:
- descoberta de serviço
- armazenamento de valor-chave distribuído.
Em nossa orquestra, o Consul será responsável por registrar os serviços e armazenar suas configurações. Existem duas opções de registro:
- Ativo - é quando o próprio serviço se registra usando a API HTTP;
- Passivo - o serviço deve ser registrado manualmente.
O Vault é um repositório que padroniza e unifica o armazenamento seguro e trabalha com segredos - senhas, certificados.
Aqui estão os benefícios que obteremos usando esta ferramenta:
- Um único centro para criar e manter segredos, gerenciando seu ciclo de vida por meio da API HTTP.
- Transit Secrets Engine - criptografia-decriptografia de dados sem salvá-los. A capacidade de transmitir dados em formato criptografado através de canais de comunicação não seguros.
- Políticas de acesso convenientes para configurar.
- Auditoria de acesso a segredos.
- Capacidade de criar sua própria CA (autoridade de certificação) para gerenciar certificados autoassinados em sua infraestrutura.
Considerando todos os nossos requisitos, duas opções se adequavam ao papel do condutor - Kubernetes e Nomad.
Kubernetes
Quantos artigos e livros já foram escritos sobre ele (este, por exemplo), foram informados relatórios que eu escreverei resumidamente - essa é uma combinação universal que pode fazer quase qualquer coisa. Pagar nem sempre é fácil de configurar e oferecer suporte a um cluster no Kubernetes.
Nomad
A ferramenta é da HashiCorp, uma empresa conhecida pelo cônsul e cofre mencionados acima.
O Nomad nos pareceu bastante simples de instalar e configurar do que o Kubernetes. Um arquivo binário funciona no modo servidor e cliente. Ao mesmo tempo, o Nomad cobre toda a lista de tarefas que queremos que ele resolva: gerenciamento de cluster, agendador rápido, suporte a vários centros. Além disso, ao usar o consul e o vault, obtemos uma integração mais rígida para orquestrar nossos serviços.
O que está agora no trabalho:
- preparou os servidores para a implantação do Consul,
- a configuração do cluster nomad será inserida no Consul, com o qual o nómada deve ser implantado automaticamente,
- Paralelamente, instalaremos o Vault para guardar segredos.
A questão no salão é se vale a pena ter um maestro para tais tarefas ou uma orquestra é boa sem ele? Diga-nos nos comentários o que você pensa sobre isso.
Assine o nosso blog e fique em contato - em breve contaremos o que aconteceu no final e se configuramos o cluster nômade, como queríamos.
Visite nossa aconchegante sala de bate-papo por telegrama, onde você sempre pode pedir conselhos, ajudar colegas e apenas falar sobre pesquisa de desempenho e muito mais.