É difícil dizer que as melhores pessoas
encontram alegria através do sofrimento.
Ludwig van Beethoven
Eu sou Sergey, trabalho na Yandex.Money na equipe de pesquisa de desempenho. Quero contar a vocês o começo da história sobre nosso caminho para o uso de orquestração — como escolhemos as ferramentas e o que consideramos. Todos os eventos do artigo acontecem em tempo real, então vocês, caros leitores, estão acompanhando o desenvolvimento da situação praticamente ao vivo.
Por que precisamos de um maestro na equipe?
Quem é um maestro? Do francês diriger — gerenciar, dirigir, liderar — no mundo da música, é a pessoa que lidera o ensaio e a execução da música em conjunto. No nosso caso, esse papel é desempenhado 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, direcionar e organizar sua execução.
Normalmente, a equipe possui um certo conjunto de recursos — chamemos de servidores, nos quais eles implementam seus projetos.
A abordagem para obtenção e exploração desses servidores é variada. Alguns exemplos:
- A equipe faz uma solicitação, por exemplo, ao grupo de operações, para que lhes forneçam recursos com parâmetros específicos.
- O grupo de operações fornece a quantidade necessária — cloud ou bare metal (“hardware simples”) — e se compromete a mantê-los em boas condições de acordo com o SLA. A configuração também é feita pela equipe de operações.
- A equipe recebe apenas recursos de cloud ou bare metal do grupo de operações, a configuração é feita por eles mesmos.
- A equipe mesma ‘compra’ recursos e os mantém/configura totalmente sozinha.
Na nossa equipe, usamos servidores que precisam ser mantidos — atualizando o SO, instalando novos pacotes etc.
Para nós, eles são divididos em dois tipos principais:
- grupo de tanques,
- grupo de serviços.
O grupo de tanques consiste em hosts com Yandex.Tank.
O grupo de serviços inclui tudo relacionado ao suporte — são vários serviços para garantir o suporte do ciclo de lançamento, geração de relatórios automáticos etc.
Em um determinado momento, tornou-se inconveniente gerenciar tudo manualmente, e decidimos automatizar todo o processo, desde a 'instalação' dos servidores até o desenvolvimento, implantação e lançamento do nosso serviço interno.
Por que um maestro é necessário, mesmo que a orquestra saiba tocar sozinha?
Para começar, dominamos o Ansible e começamos a 'instalar' nossos servidores bare metal, para ficarmos menos dependentes dos administradores de sistema — todos ganham com isso, adquirimos novas habilidades e liberamos os administradores para outras tarefas que eles sempre têm de sobra. Buscamos desenvolver fora da nossa especialidade e a autonomia da equipe, tanto quanto possível.
Na empresa, o trabalho com Ansible já está configurado e regulamentado há bastante tempo, portanto, conseguimos integrar facilmente nossa solução a esse processo.
Atualmente, a instalação de hosts consiste em três papéis do Ansible:
- o primeiro papel instala o sistema operacional,
- o segundo aplica as configurações básicas para o host, como a autenticação LDAP,
- e o terceiro instala o Yandex.Tank em um contêiner Docker e suas dependências associadas.
Vamos passar para os serviços que usamos dentro da equipe.
Para nossas tarefas, utilizamos igualmente Kotlin e Python, além de um pouco de Golang. Para unificar o desenvolvimento e a implantação de nossos serviços, decidimos empacotá-los em contêineres Docker. Isso nos dá liberdade de escolher a linguagem de programação e ao mesmo tempo regula um formato único de entrega de nossas aplicações.
Uma pequena observação sobre ipv6 no Docker
Parte dos serviços com os quais interagimos estão disponíveis apenas por ipv6, então tivemos que descobrir como habilitar o ipv6 para os contêineres.
De acordo com a documentação sobre 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 fornecer um bloco ipv6, que você anotará em fixed-cidr-v6.
No entanto, escolhemos uma abordagem diferente — NAT ipv6, e aqui está o porquê:
- Atualmente, o docker apenas com ipv6.
- A presença de um endereço globalmente roteável em cada contêiner significa que todas as portas (mesmo as não publicadas) ficam disponíveis para todos, a menos que uma filtragem adicional seja aplicada.
- userland proxy para publicar portas, .
NAT ipv6 — é , que gerencia as regras no ip6tables e as edita ao adicionar um novo contêiner.
Para que essa solução funcione corretamente, foi necessário realizar uma série de manobras adicionais. É essencial inicializar o ip6table_nat no sistema. A presença do módulo instalado no sistema não garante que, ao iniciar, o módulo será carregado no kernel. Enfrentamos isso quando recebemos o seguinte erro ao iniciar um contêiner com NAT em um host novo:
2019/01/22 14:59:54 executando [/sbin/ip6tables -t filter -N DOCKER --wait]: status de saída 3: modprobe: não é possível alterar o diretório para '/lib/modules': Arquivo ou diretório não existe
ip6tables v1.6.2: não é possível inicializar a tabela ip6tables `filter': A tabela não existe (você precisa executar insmod?)O problema foi resolvido após adicionar à função Ansible a inicialização com o módulo modprobe e o carregamento na inicialização do SO com lineinfile:
- name: Adicionar o módulo ip6table_nat
modprobe:
name: ip6table_nat
state: present
- name: Adicionar ip6table_nat na inicialização
lineinfile:
path: /etc/modules
line: 'ip6table_nat'A propósito, há um bom artigo no Habr , que descreve de forma concisa e clara as vantagens e desvantagens de cada método para trabalhar com ipv6 no docker.
Mas vamos voltar à nossa pergunta feita no início:
Por que um maestro é necessário, mesmo que a orquestra saiba tocar sozinha?
Agora todos entendem como jogar na nossa equipe:
- o processo de 'preparação' dos servidores foi criado,
- o desenvolvimento e a implantação de serviços foram unificados.
Surge a pergunta razoável — como implantar, atualizar e controlar nossos serviços em contêineres docker de maneira eficiente e o mais automatizada possível?
Apesar de cada membro da orquestra conhecer sua parte, ele pode se desviar da ideia inicial. Aqui chegamos ao ponto de que, sem o maestro, nossa orquestra não ensaiará de forma eficaz e não tocará em harmonia. O maestro é responsável por todos os parâmetros da execução, assegurando que tudo esteja alinhado em um único ritmo e sentimento.
Como obter um bom maestro com investimentos mínimos?
O tema da orquestração está bem desenvolvido no mercado. Mas primeiro, vamos falar sobre ferramentas auxiliares que podem ajudar o maestro.
— um sistema que fornece duas funções principais:
- descoberta de serviços (service discovery),
- armazenamento distribuído de chave-valor.
Na nossa orquestra, o Consul será responsável pelo registro de serviços e armazenamento de suas configurações. Existem duas opções de registro:
- Ativo — quando o serviço se registra automaticamente usando a API HTTP;
- Passivo — o serviço deve ser registrado manualmente.
Vault é um repositório que padroniza e unifica o armazenamento seguro e o manuseio de segredos - senhas, certificados.
Aqui estão as vantagens que teremos ao usar esta ferramenta:
- Um centro unificado para a criação e armazenamento de segredos, gerenciamento de seu ciclo de vida através da API HTTP.
- Transit Secrets Engine - criptografia e descriptografia de dados sem a sua retenção. A capacidade de transmitir dados de forma criptografada por canais de comunicação não seguros.
- Políticas de acesso que são fáceis de configurar.
- Auditoria de acesso a segredos.
- A capacidade de criar sua própria CA (Autoridade Certificadora) para gerenciar certificados autoassinados dentro de sua infraestrutura.
Considerando todas as nossas exigências, dois candidatos foram adequados para o papel de orquestrador - Kubernetes e Nomad.
Kubernetes
Quantos artigos e livros já foram escritos sobre ele (aqui está ), é um verdadeiro canivete suíço que pode fazer praticamente tudo. O preço a pagar por isso - nem sempre é fácil configurar e manter um cluster no Kubernetes.
Nomad
da HashiCorp, uma empresa conhecida pelos mencionados consul e vault.
Achamos que Nomad é bastante simples de instalar e configurar, em comparação ao Kubernetes. Um único arquivo binário funciona tanto no modo servidor quanto cliente. Além disso, o Nomad cobre toda a lista de tarefas que queremos que ele resolva: gerenciamento de cluster, planejador rápido, suporte a multidata centers. E ao usar consul e vault, obtemos uma integração mais estreita para a orquestração de nossos serviços.
O que está atualmente em andamento:
- preparamos os servidores para a implementação do Consul,
- a configuração do cluster nomad será inserida no Consul, com a qual o nomad deve ser implantado automaticamente,
- paralelamente estaremos instalando o vault para armazenamento de segredos.
A questão para a plateia - deve haver um orquestrador para tais tarefas ou a orquestra se sai bem sem ele? Compartilhe nos comentários o que você pensa sobre isso.
Siga nosso blog e mantenha-se atualizado - em breve contaremos o que conseguimos, e se configuramos o cluster nomad como desejávamos.
Junte-se ao nosso aconchegante , onde você pode sempre pedir conselhos, ajudar colegas e simplesmente conversar sobre pesquisa de desempenho e muito mais.
Fonte: habr.com
