Este artigo descreve a capacidade / ideia / conceito de alterar configurações globais em servidores de comando locais em uma grande infraestrutura usando o Gitlab CI e o Ansible.
Digamos que você tenha 20 equipes de desenvolvimento e 1 equipe de admin / DevOps. Como alterar senhas de administrador em todos os servidores? Como adicionar o certificado raiz da empresa a todos os servidores? Etc.
Que problema ele resolve?
Situação típica:
Existem administradores globais / DevOps.
Existem configurações globais (NTP, DNS, Proxy etc.)
Existem equipes de desenvolvimento local: TeamA, TeamB, TeamC, TeamD, etc.
Existem desenvolvedores que podem apenas acessar os servidores de sua equipe.
Como adicionar / atualizar administradores globais, configurações globais?
A tarefa é complicada pelo fato de as configurações globais serem armazenadas separadamente das configurações de comando local em repositórios particulares.
Se você tiver poucos servidores em toda a empresa, poderá iniciar o Ansible de modo simples - comece a atualizar administradores globais e configurações globais em todos os servidores de uma só vez.
Para grandes instalações, as empresas costumam usar o Puppet, Chef.
Conceito
Para alterar as configurações globais em servidores de comando locais em uma grande infraestrutura, proponho um mecanismo de sub-módulo git.
O repositório com configurações locais usa sub-módulos git com configurações globais.
Abaixo está um diagrama esquemático da conexão de um repositório privado com configurações globais aos repositórios de comandos locais.
Você pode usar o conceito de atualizar configurações globais usando o submódulo git na infraestrutura com Puppet, Chef, Salt, mas o artigo fornece um exemplo com Ansible.
Por exemplo, instale o tomcat, mysql, nginx e aplique configurações globais a eles em uma equipe chamada team.
Há um grupo comum no gitlab que contém configurações gerais.
No grupo comum, há um projeto de base de inicialização que contém administradores, configurações de sysctl etc.
Normalmente, em uma empresa, existem vários departamentos de desenvolvimento - mais freqüentemente eles são chamados de equipes.
No gitlab, crie um grupo de equipes (você terá seu próprio nome de equipe).
No grupo de equipes, criamos projetos: aplicativo, banco de dados, loadbalancer.
Captura de tela do bootstrap base, aplicativo, banco de dados, loadbalancer:
O repositório base-bootstrap é incluído como um submódulo git no aplicativo, banco de dados, repositório loadbalancer.
Cada vez que o aplicativo, banco de dados e balanceador de carga no repositório começa a atualizar o sub-módulo base-bootstrap.
Depois disso, o ansible-playbook da base-bootstrap e o ansible-playbook da base-bootstrap são aplicados aos aplicativos, bancos de dados e servidores do loadbalancer.
Ou seja, se você adicionar um novo administrador ao bootstrap base ou alterar as configurações do sistema no bootstrap base, com aplicativo, banco de dados, loadbalancer, as novas configurações do bootstrap básico serão aplicadas ao aplicativo, banco de dados e loadbalancer.
Preparação
Você deve ler artigos sobre o Ansible para iniciantes:
# Ansible por onde começar
# Guia Ansible
Você deve ter o gitlab e o gitlab-runner implantados com o docker instalado.
O executor do docker é usado como exemplo aqui - você pode usar o executor do Shell.
Como implantar o gitlab e o gitlab-runner:
# Artigo do Southbridge Gitlab-CI
# Integração e implantação contínua do Docker no GitLab CI
Você deve ter 3 servidores (por exemplo, no ubuntu): aplicativo, banco de dados, balanceador de carga.
Aplicativo, banco de dados, loadbalancer são nomes comuns.
Todos os exemplos podem ser expandidos, aprimorados, usados por outros softwares - o artigo mostra o princípio geral.
Como implementar
Os repositórios e todo o código para o teste podem ser obtidos aqui: https://github.com/patsevanton/ansible-gitlab-habr
Se você for ao servidor usando o nome de usuário / senha, no grupo desejado (nesse caso, equipe) crie a variável userpassword (quando alterar, também será necessário alterar a variável no código também) e especifique a senha (a senha da senha é usada no código)
Não esqueça de criar o usuário necessário com os direitos sudo nos servidores finais (o código do usuário é usado no código).
Para aqueles que acessam o servidor usando chaves SSH, é necessário criar a variável SSH_PRIVATE_KEY no grupo de equipes e adicionar a chave privada do usuário à que se conectará ao servidor.
Este é um exemplo simples de conexão com servidores, portanto, os problemas de segurança não são abordados neste artigo.
Em cada repositório (aplicativo, banco de dados, loadbalancer), crie um submódulo git:
git submodule add git@gitlab.example.com:common/base-bootstrap.git git submodule add git@gitlab.example.com:team/team-users.git
O submódulo é necessário para acessar o repositório privado compartilhado.
No nosso caso, este é o repositório com as configurações gerais do base-bootstrap e o repositório de usuários da equipe de usuários da equipe.
Onde gitlab.example.com é o seu servidor gitlab.
Em .gitmodules, mudamos o caminho para o repositório para relativo
Um exemplo:
[submodule "team-users"] path = team-users url = ../team-users.git [submodule "base-bootstrap"] path = base-bootstrap url = ../../common/base-bootstrap.git
Em cada repositório nos hosts, mudamos o IP para o nosso, no ansible.cfg, mudamos o remote_user para o nosso usuário.
Se você não recebeu nenhum commit nas últimas horas / dias e precisa implantar novas alterações gerais nos servidores (por exemplo, você precisa adicionar um novo administrador) - para essas situações, há um puxão possível.
Configure ansible-pull para baixar o repositório comum / base-bootstrap.
Para fazer isso, adicione o repositório de token de implantação.
Vá para o repositório common / base-bootstrap e, em seguida, vá para settings / repository / Deploy Tokens.
Crie um token. O nome de usuário e a senha resultantes são registrados em base-bootstrap / vars / cron.yml.
Depois de verificar se tudo funciona corretamente - acho que vale a pena alterar o horário de início do ansible-pull de "a cada 2 minutos" para aquele que mais lhe convier.
Se o ansible-pull caiu, significa que o IC desse serviço será eliminado, o que será iniciado toda vez que você confirmar esse repositório de serviços (digamos que o serviço seja chamado de aplicativo)
Verifique
Crie um novo administrador.
Tente adicionar um novo administrador em https://github.com/patsevanton/ansible-gitlab-habr/blob/master/commons/base-bootstrap/vars/users.yml
Alteração Sysctl
Tente adicionar / alterar configurações sysctl em https://github.com/patsevanton/ansible-gitlab-habr/blob/master/commons/base-bootstrap/vars/sysctl.yml
Adicionando entradas ao cron
Tente adicionar entradas cron em https://github.com/patsevanton/ansible-gitlab-habr/blob/master/commons/base-bootstrap/vars/cron.yml
Estendendo ou Instalando seus Aplicativos
Primeiro, você precisa encontrar uma função para instalar seus aplicativos.
Acesse https://galaxy.ansible.com/ e encontre a função para instalar seu aplicativo.
Tente instalar seu aplicativo usando a função do console em seus servidores. Normalmente, todas as funções têm instruções nas descrições.
Por exemplo, tente instalar o java ao lado do tomcat. Primeiro instale a função geerlingguy.java
ansible-galaxy install geerlingguy.java
Crie o padrão ansible.cfg igual aos repositórios.
Crie um inventário:
[java] java ansible_host=IP-
Crie um manual java.yml
- hosts: java become: yes vars_files: - vars/main.yml roles: - { role: geerlingguy.java }
Execute ansible-playbook java.yml
Se tudo correu com sucesso, adicione ao projeto desejado (neste caso, o aplicativo)
A função de geerlingguy.java é adicionada após a função de robertdebock.tomcat https://github.com/patsevanton/ansible-gitlab-habr/blob/master/team/application/tomcat-app.yml#L11
O mesmo acontece com todos os outros aplicativos que você precisa instalar no servidor.
Teste e segurança do manual
Para simplificar o artigo, a questão do armazenamento e teste de senhas não é abordada.
Existem artigos sobre o teste do manual:
# Ansible: testando playbooks (parte 1)
# Teste e integração contínua para funções Ansible com Molecule e Jenkins
Respostas às perguntas
1) Mentat: E por que, afinal, não é como está escrito na doca ansível, com os ambientes? Desde a primeira leitura, parece uma tentativa de reinventar tudo de novo. É conveniente aplicar tudo isso, como o ansible-playbook -i env / teamA personalAPlaybook.yml
Resposta: Esse esquema possibilita alterar as configurações globais. O que está descrito na pergunta é alterar as configurações locais dos comandos.
PS Talvez a mesma funcionalidade seja implementada no Ansible Tower. Mas não posso dizer nada sobre isso - não trabalhei com a Ansible Tower.