ProHoster > Blog > administration > Configuration du CD via gitlab

Configuration du CD via gitlab

Une fois, j'ai pensé à automatiser le déploiement de mon projet. gitlab.com fournit gentiment tous les outils pour cela, et bien sûr j'ai décidé de l'utiliser en le découvrant et en écrivant un petit script de déploiement. Dans cet article, je partage mon expérience avec la communauté.

TL; DR

  1. Configurer VPS : désactiver la racine, la connexion par mot de passe, installer dockerd, configurer ufw
  2. Générer des certificats pour le serveur et le client docs.docker.com/engine/security/https/#create-a-ca-server-and-client-keys-with-openssl Activer le contrôle dockerd via le socket tcp : supprimez l'option -H fd:// de la configuration du docker.
  3. Définir les chemins d'accès aux certificats dans docker.json
  4. Enregistrez-vous dans les variables gitlab dans les paramètres CI / CD avec le contenu des certificats. Écrivez un script .gitlab-ci.yml pour le déploiement.

Je vais montrer tous les exemples sur la distribution Debian.

Configuration initiale du VPS

Ici vous avez acheté une instance par exemple sur DO, la première chose à faire est de protéger votre serveur du monde extérieur agressif. Je ne prouverai ni n'affirmerai rien, je montrerai juste le log /var/log/messages de mon serveur virtuel :

Capture d'écranConfiguration du CD via gitlab

Tout d'abord, installez le pare-feu ufw :

apt-get update && apt-get install ufw

Activez la politique par défaut : bloquer toutes les connexions entrantes, autoriser toutes les connexions sortantes :

ufw default deny incoming
ufw default allow outgoing

Important : n'oubliez pas d'autoriser la connexion via ssh :

ufw allow OpenSSH

La syntaxe générale est la suivante : Autoriser la connexion sur le port : ufw allow 12345, où 12345 est le numéro de port ou le nom du service. Refuser: ufw refuser 12345

Activez le pare-feu :

ufw enable

Nous quittons la session et nous reconnectons via ssh.

Ajoutez un utilisateur, attribuez-lui un mot de passe et ajoutez-le au groupe sudo.

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

Ensuite, selon le plan, vous devez désactiver la connexion par mot de passe. pour cela, copiez votre clé ssh sur le serveur :

ssh-copy-id [email protected]

L'IP du serveur doit être la vôtre. Essayez maintenant de vous connecter sous l'utilisateur créé précédemment, vous n'avez plus besoin de saisir de mot de passe. Ensuite, dans les paramètres de configuration, modifiez les éléments suivants :

sudo nano /etc/ssh/sshd_config

désactiver la connexion par mot de passe :

PasswordAuthentication no

Redémarrez le démon sshd :

sudo systemctl reload sshd

Maintenant, si vous ou quelqu'un d'autre essayez de vous connecter en tant que root, cela échouera.

Ensuite, nous installons dockerd, je ne décrirai pas le processus ici, puisque tout peut déjà être modifié, suivez le lien vers le site officiel et suivez les étapes d'installation de docker sur votre machine virtuelle : https://docs.docker.com/install/linux/docker-ce/debian/

Génération de certificat

Pour contrôler le démon docker à distance, une connexion TLS chiffrée est requise. Pour ce faire, vous devez disposer d'un certificat et d'une clé que vous devez générer et transférer sur votre machine distante. Suivez les étapes indiquées dans les instructions sur le site Web officiel de docker : https://docs.docker.com/engine/security/https/#create-a-ca-server-and-client-keys-with-openssl Tous les fichiers *.pem générés pour le serveur, à savoir ca.pem, server.pem, key.pem, doivent être placés dans le répertoire /etc/docker sur le serveur.

configuration du menu fixe

Dans le script de démarrage du démon docker, supprimez l'option -H df://, cette option indique sur quel hôte le démon docker peut être contrôlé.

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

Ensuite, créez un fichier de paramètres s'il n'existe pas déjà et définissez les options :

/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
}

Autoriser les connexions sur le port 2376 :

sudo ufw allow 2376

Redémarrez dockerd avec de nouveaux paramètres :

sudo systemctl daemon-reload && sudo systemctl restart docker

Chèque:

sudo systemctl status docker

Si tout est vert, alors nous considérons que nous avons configuré avec succès docker sur le serveur.

Mise en place de la livraison continue sur gitlab

Pour que le travailleur gitalab puisse exécuter des commandes sur un hôte docker distant, vous devez décider comment et où stocker les certificats et une clé pour une connexion chiffrée à dockerd. J'ai résolu ce problème en écrivant simplement aux variables dans les paramètres de gitlbab :

titre spoilerConfiguration du CD via gitlab

Sortez simplement le contenu des certificats et de la clé via cat : cat ca.pem. Copiez et collez dans les valeurs variables.

Écrivons un script pour le déploiement via gitlab. L'image docker-in-docker (dind) sera utilisée.

.gitlab-ci.yml

image:
  name: docker/compose:1.23.2
  # перепишем entrypoint , чтобы работало в 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 # скрипт деплоя тут

Le contenu du script de déploiement avec des commentaires :

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

Le problème principal était de "sortir" le contenu des certificats sous la forme normale des variables CI / CD de gitlab. Je ne pouvais pas comprendre pourquoi la connexion à l'hôte distant ne fonctionnait pas. J'ai regardé le journal sudo journalctl -u docker log sur l'hôte, il y a une erreur avec la poignée de main. J'ai décidé de regarder ce qui est généralement stocké dans les variables, pour cela vous pouvez voir cat -A $DOCKER_CERT_PATH/key.pem. Surmonté l'erreur en ajoutant la suppression du caractère caret tr -d 'r'.

De plus, vous pouvez ajouter des tâches post-publication au script à votre discrétion. Vous pouvez consulter la version de travail dans mon référentiel https://gitlab.com/isqad/gitlab-ci-cd

Source: habr.com

Ajouter un commentaire