Configurazione CD tramite gitlab

Un giorno ho pensato all'automazione del deployment del mio progetto. gitlab.com offre tutti gli strumenti necessari, quindi ho deciso di approfittarne, comprendendo e scrivendo un piccolo script di deployment. In questo articolo condivido la mia esperienza con la comunità.

TL;DR

  1. Configurare VPS: disabilitare root, accesso con password, installare dockerd, configurare ufw
  2. Generare certificati per il server e il client docs.docker.com/engine/security/https/#create-a-ca-server-and-client-keys-with-openssl Abilitare la gestione di dockerd tramite socket tcp: rimuovere l'opzione -H fd:// dalla configurazione di Docker.
  3. Прописать пути до сертификатов в docker.json
  4. Inserire nelle variabili gitlab nelle impostazioni CI/CD il contenuto dei certificati. Scrivere lo script .gitlab-ci.yml per il deployment.

Tutti gli esempi verranno mostrati su una distribuzione Debian.

Configurazione iniziale del VPS

Avete acquistato un'istanza, ad esempio su DO, la prima cosa da fare è proteggere il vostro server da un mondo esterno aggressivo. Non voglio dimostrare nulla, ma farò vedere il log /var/log/messages del mio server virtuale:

ScreenshotConfigurazione CD tramite gitlab

Prima di tutto installiamo il firewall ufw:

apt-get update && apt-get install ufw

Impostiamo la politica predefinita: blocchiamo tutte le connessioni in ingresso, consentiamo tutte le connessioni in uscita:

ufw default deny incoming
ufw default allow outgoing

Importante: non dimentichiamo di consentire la connessione via ssh:

ufw allow OpenSSH

La sintassi generale è la seguente: Per consentire la connessione su una porta: ufw allow 12345, dove 12345 è il numero della porta o il nome del servizio. Per vietare: ufw deny 12345

Attiviamo il firewall:

ufw enable

Esci dalla sessione e riconnettiti tramite ssh.

Aggiungi un utente, assegna una password e aggiungilo al gruppo sudo.

apt-get install sudo
adduser scoty
usermod -aG sudo scoty

Successivamente dobbiamo disabilitare l'accesso con password. Per fare questo, copia la tua chiave ssh sul server:

ssh-copy-id root@10.101.10.28

L'ip del server deve essere il tuo. Prova ora a accedere con l'utente creato in precedenza, non è più necessario inserire la password. Successivamente, nella configurazione delle impostazioni cambiamo quanto segue:

sudo nano /etc/ssh/sshd_config

disabilitiamo l'accesso con password:

PasswordAuthentication no

Riavviamo il demone sshd:

sudo systemctl reload sshd

Ora, se tu o qualcun altro provate a entrare come utente root, non ci riuscirà.

Successivamente installiamo dockerd, qui non descriverò il processo, poiché potrebbe essere già cambiato; segui il link al sito ufficiale e segui i passaggi per installare Docker sulla tua virtual machine: https://docs.docker.com/install/linux/docker-ce/debian/

Generazione certificati

Per gestire il demone Docker da remoto è richiesta una connessione TLS crittografata. È necessario disporre di un certificato e di una chiave, che devono essere generati e trasferiti sulla vostra macchina remota. Seguite i passaggi indicati nelle istruzioni sul sito ufficiale di Docker: https://docs.docker.com/engine/security/https/#create-a-ca-server-and-client-keys-with-openssl Tutti i file *.pem generati per il server, ossia ca.pem, server.pem, key.pem, devono essere collocati nella directory /etc/docker sul server.

Impostazione di dockerd

Nel file di avvio del demone Docker, rimuoviamo l'opzione -H df://, questa opzione determina su quale host è possibile gestire il demone Docker.

# At /lib/systemd/system/docker.service
[Service]
Type=notify
ExecStart=/usr/bin/dockerd

Successivamente, occorre creare un file di configurazione, se non esiste ancora, e specificare le opzioni:

/etc/docker/docker.json

{
  "hosts": [
    "unix://var/run/docker.sock",
    "tcp://0.0.0.0:2376"
  ],
  "labels": [
    "is-our-remote-engine=true"
  ],
  "tls": true,
  "tlscacert": "/etc/docker/ca.pem",
  "tlscert": "/etc/docker/server.pem",
  "tlskey": "/etc/docker/key.pem",
  "tlsverify": true
}

Abilitiamo le connessioni sulla porta 2376:

sudo ufw allow 2376

Riavviamo dockerd con le nuove impostazioni:

sudo systemctl daemon-reload && sudo systemctl restart docker

Controlliamo:

sudo systemctl status docker

Se tutto è «verde», consideriamo che abbiamo configurato correttamente Docker sul server.

Impostazione della continuous delivery su GitLab

Affinché il worker di GitLab possa eseguire comandi su un host Docker remoto, è necessario decidere come e dove archiviare i certificati e la chiave per la connessione crittografata con dockerd. Ho risolto questo problema semplicemente scrivendo nelle variabili nelle impostazioni di GitLab:

Titolo dello spoilerConfigurazione CD tramite gitlab

Basta visualizzare il contenuto dei certificati e della chiave tramite cat: cat ca.pem. Copiate e incollate nel valore delle variabili.

Scriviamo uno script per il deploy tramite GitLab. Useremo l'immagine docker-in-docker (dind).

.gitlab-ci.yml

image:
  name: docker/compose:1.23.2
  # riscriviamo l'entrypoint per far funzionare dind
  entrypoint: ["/bin/sh", "-c"]

variables:
  DOCKER_HOST: tcp://docker:2375/
  DOCKER_DRIVER: overlay2

services:
  - docker:dind

stages:
  - deploy

deploy:
  stage: deploy
  script:
    - bin/deploy.sh # script di deploy qui

Il contenuto dello script di deploy con commenti:

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

Il problema principale era «estrarre» dalle variabili di GitLab CI/CD il contenuto dei certificati in un formato normale. Non riuscivo a capire perché non funzionasse la connessione con l'host remoto. Sul server ho controllato il log con sudo journalctl -u docker, c'era un errore durante l'handshake. Ho deciso di controllare cosa ci fosse effettivamente nelle variabili, per questo posso usare cat -A $DOCKER_CERT_PATH/key.pem. Ho risolto l'errore, aggiungendo la rimozione del carattere di ritorno tr -d 'r'.

Successivamente, nello script puoi aggiungere attività post-rilascio a tua discrezione. Puoi visionare la versione di lavoro nel mio repository https://gitlab.com/isqad/gitlab-ci-cd

Fonte: habr.com

Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server 🔥 Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server | ProHoster