1. Introdução
Recentemente, a popularidade do Kubernetes está crescendo rapidamente - mais e mais projetos estão implementando-o em casa. Eu queria tocar em um orquestrador como o Nomad: é perfeito para projetos que já usam outras soluções da HashiCorp, por exemplo, Vault e Consul, e os projetos em si não são complicados em termos de infraestrutura. Este artigo fornecerá instruções para instalar o Nomad, combinar dois nós em um cluster e integrar o Nomad ao Gitlab.
Suporte de teste
Um pouco sobre a bancada de testes: três servidores virtuais são usados com as características de 2 CPU, 4 RAM, SSD de 50 Gb, unidos em uma rede local comum. Seus nomes e endereços IP:
- nomad-livelinux-01 : 172.30.0.5
- nomad-livelinux-02 : 172.30.0.10
- consul-livelinux-01 : 172.30.0.15
Instalação do Nomad, Consul. Criando um cluster Nomad
Vamos prosseguir para a instalação básica. Apesar da facilidade de instalação, descreverei a integridade do artigo: na verdade, ele foi criado a partir de rascunhos e notas para acesso rápido, se necessário.
Antes de iniciar a prática, discutiremos a parte teórica, porque nesta fase é importante entender a estrutura futura.
Temos dois nós nômades e queremos mesclá-los em um cluster, também para o futuro precisaremos de dimensionamento automático do cluster - para isso, precisamos do Consul. Usando essa ferramenta, o armazenamento em cluster e a adição de novos nós se tornam uma tarefa muito simples: o nó Nomad criado se conecta ao agente Consul e, em seguida, ao cluster Nomad existente. Portanto, no início, instalaremos o servidor Consul, configuramos a autorização http básica para o painel da web (por padrão, sem autorização e pode ser acessado por um endereço externo), bem como os próprios agentes Consul nos servidores Nomad, após o qual apenas iniciamos o Nomad.
A instalação das ferramentas HashiCorp é muito simples: na verdade, simplesmente movemos o arquivo binário para o diretório bin, configuramos o arquivo de configuração da ferramenta e criamos seu arquivo de serviço.
Faça o download do arquivo binário Consul e descompacte-o no diretório inicial do usuário:
root@consul-livelinux-01:~
Agora temos um arquivo consul binário pronto para configuração adicional.
Para trabalhar com o Consul, precisamos criar uma chave exclusiva usando o comando keygen:
root@consul-livelinux-01:~
Vamos para a configuração do Consul, crie o diretório /etc/consul.d/ com a seguinte estrutura:
/etc/consul.d/ ├── bootstrap │ └── config.json
O diretório de inicialização conterá o arquivo de configuração config.json - nele, definiremos as configurações do Consul. Seu conteúdo:
{ "bootstrap": true, "server": true, "datacenter": "dc1", "data_dir": "/var/consul", "encrypt": "your-key", "log_level": "INFO", "enable_syslog": true, "start_join": ["172.30.0.15"] }
Vamos examinar separadamente as principais diretrizes e seus significados:
- bootstrap : verdadeiro. Ativamos a adição automática de novos nós, se estiverem conectados. Observo que não indicamos aqui o número exato de nós esperados.
- servidor : verdadeiro. Ative o modo servidor. O cônsul nesta máquina virtual será o único servidor e mestre no momento, o VM Nomad será o cliente.
- datacenter : dc1. Especifique o nome do datacenter para criar um cluster. Ele deve ser idêntico em clientes e servidores.
- criptografar : sua chave. Uma chave que também deve ser exclusiva e corresponder a todos os clientes e servidores. Gerado usando o comando consul keygen.
- start_join . Nesta lista, indicamos a lista de endereços IP com os quais a conexão será feita. No momento, deixamos apenas nosso próprio endereço.
Neste ponto, podemos iniciar o consul usando a linha de comando:
root@consul-livelinux-01:~
Essa é uma boa maneira de depurar agora, no entanto, de forma contínua, o uso desse método não funcionará por razões óbvias. Crie um arquivo de serviço para gerenciar o Consul através do systemd:
root@consul-livelinux-01:~
O conteúdo do arquivo consul.service:
[Unit] Description=Consul Startup process After=network.target [Service] Type=simple ExecStart=/bin/bash -c '/usr/local/bin/consul agent -config-dir /etc/consul.d/bootstrap -ui' TimeoutStartSec=0 [Install] WantedBy=default.target
Execute o Consul através do systemctl:
root@consul-livelinux-01:~
Verificamos: nosso serviço deve ser iniciado e, executando o comando consul members, devemos ver nosso servidor:
root@consul-livelinux:/etc/consul.d
A próxima etapa: instalando o Nginx e configurando o proxy, a autorização http. Instale o nginx através do gerenciador de pacotes e crie o arquivo de configuração consul.conf no diretório / etc / nginx / sites-enabled com o seguinte conteúdo:
upstream consul-auth { server localhost:8500; } server { server_name consul.doman.name; location / { proxy_pass http://consul-auth; proxy_set_header Host $host; auth_basic_user_file /etc/nginx/.htpasswd; auth_basic "Password-protected Area"; } }
Não se esqueça de criar um arquivo .htpasswd e gerar um nome de usuário e senha para ele. Este item é necessário para que o painel da Web não seja acessível a todos que conhecem nosso domínio. No entanto, ao configurar o Gitlab, teremos que abandonar isso - caso contrário, não poderemos implantar nosso aplicativo no Nomad. No meu projeto, o Gitlab e o Nomad estão apenas na rede cinza, então não existe esse problema.
Nos outros dois servidores, instale os agentes do Consul de acordo com as seguintes instruções. Repita as etapas com o arquivo binário:
root@nomad-livelinux-01:~
Por analogia com o servidor anterior, criamos um diretório para os arquivos de configuração /etc/consul.d com a seguinte estrutura:
/etc/consul.d/ ├── client │ └── config.json
O conteúdo do arquivo config.json:
{ "datacenter": "dc1", "data_dir": "/opt/consul", "log_level": "DEBUG", "node_name": "nomad-livelinux-01", "server": false, "encrypt": "your-private-key", "domain": "livelinux", "addresses": { "dns": "127.0.0.1", "https": "0.0.0.0", "grpc": "127.0.0.1", "http": "127.0.0.1" }, "bind_addr": "172.30.0.5", # "start_join": ["172.30.0.15"], # "ports": { "dns": 53 } }
Salvamos as alterações e prosseguimos para a configuração do arquivo de serviço, seu conteúdo:
/etc/systemd/system/consul.service:
[Unit] Description="HashiCorp Consul - A service mesh solution" Documentation=https://www.consul.io/ Requires=network-online.target After=network-online.target [Service] User=root Group=root ExecStart=/usr/local/bin/consul agent -config-dir=/etc/consul.d/client ExecReload=/usr/local/bin/consul reload KillMode=process Restart=on-failure [Install] WantedBy=multi-user.target
Começamos o consul no servidor. Agora, após iniciar, devemos ver o serviço configurado nos membros nsul. Isso significa que ele se conectou com êxito ao cluster como um cliente. Repita o mesmo no segundo servidor e, depois disso, poderemos começar a instalar e configurar o Nomad.
Uma instalação mais detalhada do Nomad é descrita em sua documentação oficial. Existem dois métodos de instalação tradicionais: baixar um arquivo binário e compilar a partir do código-fonte. Eu vou escolher o primeiro método.
Nota : o projeto está se desenvolvendo muito rápido, novas atualizações geralmente são lançadas. Talvez uma nova versão seja lançada quando este artigo for concluído. Portanto, recomendo que, antes de ler, verifique a versão atual do Nomad no momento e faça o download.
root@nomad-livelinux-01:~
Após descompactar, obteremos um arquivo binário Nomad'a com 65 MB - ele deve ser movido para / usr / local / bin.
Crie um diretório de dados para o Nomad e edite seu arquivo de serviço (provavelmente não existirá no início):
root@nomad-livelinux-01:~
Insira as seguintes linhas lá:
[Unit] Description=Nomad Documentation=https://nomadproject.io/docs/ Wants=network-online.target After=network-online.target [Service] ExecReload=/bin/kill -HUP $MAINPID ExecStart=/usr/local/bin/nomad agent -config /etc/nomad.d KillMode=process KillSignal=SIGINT LimitNOFILE=infinity LimitNPROC=infinity Restart=on-failure RestartSec=2 StartLimitBurst=3 StartLimitIntervalSec=10 TasksMax=infinity [Install] WantedBy=multi-user.target
No entanto, não temos pressa em executar o nomad - ainda não criamos seu arquivo de configuração:
root@nomad-livelinux-01:~
A estrutura final do diretório será a seguinte:
/etc/nomad.d/ ├── nomad.hcl └── server.hcl
O arquivo nomad.hcl deve conter a seguinte configuração:
datacenter = "dc1" data_dir = "/opt/nomad"
O conteúdo do arquivo server.hcl:
server { enabled = true bootstrap_expect = 1 } consul { address = "127.0.0.1:8500" server_service_name = "nomad" client_service_name = "nomad-client" auto_advertise = true server_auto_join = true client_auto_join = true } bind_addr = "127.0.0.1" advertise { http = "172.30.0.5" } client { enabled = true }
Não se esqueça de alterar o arquivo de configuração no segundo servidor - será necessário alterar o valor da diretiva http.
O último nesta fase é a configuração do Nginx para fazer proxy e definir a autorização http. O conteúdo do arquivo nomad.conf:
upstream nomad-auth { server 172.30.0.5:4646; } server { server_name nomad.domain.name; location / { proxy_pass http://nomad-auth; proxy_set_header Host $host; auth_basic_user_file /etc/nginx/.htpasswd; auth_basic "Password-protected Area"; } }
Agora podemos acessar o painel da web através de uma rede externa. Nós nos conectamos e vamos para a página de servidores:
Figura 1. Lista de servidores em um cluster Nomad
Ambos os servidores são exibidos com sucesso no painel, a mesma coisa que veremos na saída do comando nomad node status:
Figura 2. A saída do comando nomad node status
E o Consul? Vamos ver Vá para o painel de controle do Consul, para a página de nós:
Figura 3. Lista de nós no cluster Consul
Agora preparamos o Nomad, trabalhando em conjunto com o Consul. Na etapa final, começaremos a parte mais interessante: configuraremos a entrega de contêineres do Docker do Gitlab para o Nomad e também falaremos sobre alguns de seus outros recursos distintos.
Criar corredor do Gitlab
Para implantar imagens do docker no Nomad, usaremos um corredor separado com o arquivo binário Nomad (aqui, a propósito, mais um recurso dos aplicativos Hashicorp pode ser observado - individualmente, eles são o único arquivo binário). Faça o download para o diretório do corredor. Para ele, crie o Dockerfile mais simples com o seguinte conteúdo:
FROM alpine:3.9 RUN apk add --update --no-cache libc6-compat gettext COPY nomad /usr/local/bin/nomad
No mesmo projeto, crie .gitlab-ci.yml:
variables: DOCKER_IMAGE: nomad/nomad-deploy DOCKER_REGISTRY: registry.domain.name stages: - build build: stage: build image: ${DOCKER_REGISTRY}/nomad/alpine:3 script: - tag=${DOCKER_REGISTRY}/${DOCKER_IMAGE}:latest - docker build --pull -t ${tag} -f Dockerfile . - docker push ${tag}
Como resultado, teremos uma imagem acessível do corredor Nomad no Registro Gitlab, agora podemos ir diretamente para o repositório do projeto, criar um pipeline e configurar o trabalho nômade Nomad.
Configuração do projeto
Vamos começar com o arquivo do trabalho para o Nomad. Meu projeto neste artigo será bastante primitivo: consistirá em uma tarefa. O conteúdo de .gitlab-ci será o seguinte:
variables: NOMAD_ADDR: http://nomad.address.service:4646 DOCKER_REGISTRY: registry.domain.name DOCKER_IMAGE: example/project stages: - build - deploy build: stage: build image: ${DOCKER_REGISTRY}/nomad-runner/alpine:3 script: - tag=${DOCKER_REGISTRY}/${DOCKER_IMAGE}:${CI_COMMIT_SHORT_SHA} - docker build --pull -t ${tag} -f Dockerfile . - docker push ${tag} deploy: stage: deploy image: registry.example.com/nomad/nomad-runner:latest script: - envsubst '${CI_COMMIT_SHORT_SHA}' < project.nomad > job.nomad - cat job.nomad - nomad validate job.nomad - nomad plan job.nomad || if [ $? -eq 255 ]; then exit 255; else echo "success"; fi - nomad run job.nomad environment: name: production allow_failure: false when: manual
Aqui a implantação ocorre no modo manual, mas você pode configurá-lo para alterar o conteúdo do diretório do projeto. O pipeline consiste em duas etapas: da montagem da imagem e sua implantação ao nômade. No primeiro estágio, coletamos a imagem do docker e a inserimos em nosso Registro; no segundo, lançamos nosso trabalho no Nomad.
job "monitoring-status" { datacenters = ["dc1"] migrate { max_parallel = 3 health_check = "checks" min_healthy_time = "15s" healthy_deadline = "5m" } group "zhadan.ltd" { count = 1 update { max_parallel = 1 min_healthy_time = "30s" healthy_deadline = "5m" progress_deadline = "10m" auto_revert = true } task "service-monitoring" { driver = "docker" config { image = "registry.domain.name/example/project:${CI_COMMIT_SHORT_SHA}" force_pull = true auth { username = "gitlab_user" password = "gitlab_password" } port_map { http = 8000 } } resources { network { port "http" {} } } } } }
Observe que eu tenho um registro privado e, para um conjunto de imagens de janela de encaixe bem-sucedido, preciso fazer login nele. A melhor solução, neste caso, é inserir um login e senha no Vault com sua subsequente integração com o Nomad. O Nomad suporta nativamente o Vault. Mas primeiro, no próprio Vault, instalaremos as políticas necessárias para o Nomad, você poderá baixá-las:
Agora, tendo criado as políticas necessárias, adicionaremos a integração com o Vault no bloco de tarefas no arquivo job.nomad:
vault { enabled = true address = "https://vault.domain.name:8200" token = "token" }
Eu uso autorização por token e escrevo diretamente aqui, também há a opção de especificar o token como uma variável ao executar o agente nômade:
$ VAULT_TOKEN=<token> nomad agent -config /path/to/config
Agora podemos usar as chaves com o Vault. O princípio de operação é simples: criamos um arquivo no trabalho Nomad, que armazena os valores das variáveis, por exemplo:
template { data = <<EOH {{with secret "secrets/pipeline-keys"}} REGISTRY_LOGIN="{{ .Data.REGISTRY_LOGIN }}" REGISTRY_PASSWORD="{{ .Data.REGISTRY_LOGIN }}{{ end }}" EOH destination = "secrets/service-name.env" env = true }
Com essa abordagem simples, você pode configurar a entrega de contêineres para o cluster Nomad e trabalhar com ele no futuro. Eu direi que, até certo ponto, simpatizo com o Nomad - é mais adequado para pequenos projetos em que o Kubernetes pode causar dificuldades adicionais e não perceberá seu potencial até o fim. Além disso, o Nomad é perfeito para iniciantes - é fácil de instalar e configurar. No entanto, ao testar em alguns projetos, encontro o problema de suas versões anteriores - muitas funções básicas simplesmente não existem ou não funcionam corretamente. No entanto, acredito que o Nomad continuará se desenvolvendo e, no futuro, adquirirá todas as funções necessárias.
Postado por Ilya Andreev, editado por Alexei Zhadan e Live Linux Team