Certa vez, pensei em automatizar a implantação do meu projeto. O gitlab.com gentilmente fornece todas as ferramentas para isso, e é claro que decidi aproveitar isso, descobrindo e escrevendo um pequeno script de implantação. Neste artigo compartilho minha experiência com a comunidade.
TL, DR
Configure o VPS: desative o root, faça login com senha, instale o dockerd, configure o ufw
Registre caminhos para certificados em docker.json
Cadastre-se nas variáveis do gitlab nas configurações do CI/CD com o conteúdo dos certificados. Escreva um script .gitlab-ci.yml para implantação.
Mostrarei todos os exemplos da distribuição Debian.
Configuração inicial do VPS
Então você comprou uma instância, por exemplo, em DO, a primeira coisa que você precisa fazer é proteger seu servidor do mundo externo agressivo. Não vou provar ou afirmar nada, apenas mostrarei o log /var/log/messages do meu servidor virtual:
Capturas de tela
Primeiro, instale o firewall ufw:
apt-get update && apt-get install ufw
Vamos habilitar a política padrão: bloquear todas as conexões de entrada, permitir todas as conexões de saída:
Importante: não esqueça de permitir a conexão via ssh:
ufw allow OpenSSH
A sintaxe geral é a seguinte: Permitir conexão por porta: ufw permitir 12345, onde 12345 é o número da porta ou o nome do serviço. Negar: ufw negar 12345
Ative o firewall:
ufw enable
Saímos da sessão e fazemos login novamente via ssh.
Adicione um usuário, atribua uma senha a ele e adicione-o ao grupo sudo.
O ip do servidor deve ser seu. Agora tente fazer login usando o usuário que você criou anteriormente; você não precisa mais digitar uma senha. A seguir, nas definições de configuração, altere o seguinte:
sudo nano /etc/ssh/sshd_config
desabilitar login com senha:
PasswordAuthentication no
Reinicie o daemon sshd:
sudo systemctl reload sshd
Agora, se você ou outra pessoa tentar fazer login como usuário root, não funcionará.
A seguir instale o dockerd, não vou descrever o processo aqui, pois tudo já pode ser alterado, siga o link para o site oficial e siga os passos de instalação do docker na sua máquina virtual: https://docs.docker.com/install/linux/docker-ce/debian/
Gerando certificados
Para controlar o daemon docker remotamente, é necessária uma conexão TLS criptografada. Para fazer isso, você precisa ter um certificado e uma chave, que deve ser gerada e transferida para sua máquina remota. Siga as etapas fornecidas nas instruções no site oficial do docker: https://docs.docker.com/engine/security/https/#create-a-ca-server-and-client-keys-with-openssl Todos os arquivos *.pem gerados para o servidor, nomeadamente ca.pem, server.pem, key.pem, devem ser colocados no diretório /etc/docker no servidor.
Configurando o dockerd
No script de inicialização do docker daemon, removemos a opção -H df://, esta opção determina em qual host o daemon do docker pode ser controlado.
# At /lib/systemd/system/docker.service
[Service]
Type=notify
ExecStart=/usr/bin/dockerd
A seguir, você deve criar um arquivo de configurações, caso ainda não exista, e especificar as opções:
Se tudo estiver “verde”, consideramos que configuramos o docker no servidor com sucesso.
Configurando entrega contínua no gitlab
Para que o trabalhador Gitalaba possa executar comandos em um host Docker remoto, é necessário decidir como e onde armazenar os certificados e a chave para uma conexão criptografada com o Dockerd. Resolvi esse problema simplesmente adicionando o seguinte às variáveis nas configurações do gitlbab:
Título do spoiler
Basta exibir o conteúdo dos certificados e da chave via cat: cat ca.pem. Copie e cole nos valores das variáveis.
Vamos escrever um script para implantação via GitLab. A imagem docker-in-docker (dind) será usada.
Conteúdo do script de implantação com comentários:
bin/deploy.sh
#!/usr/bin/env sh
# Падаем сразу, если возникли какие-то ошибки
set -e
# Выводим, то , что делаем
set -v
#
DOCKER_COMPOSE_FILE=docker-compose.yml
# Куда деплоим
DEPLOY_HOST=185.241.52.28
# Путь для сертификатов клиента, то есть в нашем случае - gitlab-воркера
DOCKER_CERT_PATH=/root/.docker
# проверим, что в контейнере все имеется
docker info
docker-compose version
# создаем путь (сейчас работаем в клиенте - воркере gitlab'а)
mkdir $DOCKER_CERT_PATH
# изымаем содержимое переменных, при этом удаляем лишние символы добавленные при сохранении переменных.
echo "$CA_PEM" | tr -d 'r' > $DOCKER_CERT_PATH/ca.pem
echo "$CERT_PEM" | tr -d 'r' > $DOCKER_CERT_PATH/cert.pem
echo "$KEY_PEM" | tr -d 'r' > $DOCKER_CERT_PATH/key.pem
# на всякий случай даем только читать
chmod 400 $DOCKER_CERT_PATH/ca.pem
chmod 400 $DOCKER_CERT_PATH/cert.pem
chmod 400 $DOCKER_CERT_PATH/key.pem
# далее начинаем уже работать с удаленным docker-демоном. Собственно, сам деплой
export DOCKER_TLS_VERIFY=1
export DOCKER_HOST=tcp://$DEPLOY_HOST:2376
# проверим, что коннектится все успешно
docker-compose
-f $DOCKER_COMPOSE_FILE
ps
# логинимся в docker-регистри, тут можете указать свой "местный" регистри
docker login -u $DOCKER_USER -p $DOCKER_PASSWORD
docker-compose
-f $DOCKER_COMPOSE_FILE
pull app
# поднимаем приложение
docker-compose
-f $DOCKER_COMPOSE_FILE
up -d app
O principal problema era “puxar” o conteúdo dos certificados de forma normal das variáveis CI/CD do gitlab. Não consegui descobrir por que a conexão com o host remoto não estava funcionando. No host olhei o log sudo journalctl -u docker, houve um erro durante o handshake. Decidi dar uma olhada no que geralmente é armazenado em variáveis; para fazer isso, você pode ficar assim: cat -A $DOCKER_CERT_PATH/key.pem. Superei o erro adicionando a remoção do caractere de carro tr -d 'r'.
Em seguida, você pode adicionar tarefas pós-lançamento ao script a seu critério. Você pode ver a versão funcional em meu repositório https://gitlab.com/isqad/gitlab-ci-cd