Configurarea CD-ului prin gitlab

M-am gândit odată să automatizez implementarea proiectului meu. gitlab.com oferă cu amabilitate toate instrumentele pentru aceasta și, bineînțeles, am decis să profit de el, dându-mi seama și scriind un mic script de implementare. În acest articol împărtășesc experiența mea cu comunitatea.

TL; DR

  1. Configurați VPS: dezactivați root, conectați-vă cu parolă, instalați dockerd, configurați ufw
  2. Generați certificate pentru server și client docs.docker.com/engine/security/https/#create-a-ca-server-and-client-keys-with-openssl Activați controlul dockerd prin socketul tcp: eliminați opțiunea -H fd:// din configurația docker.
  3. Înregistrați căile către certificate în docker.json
  4. Înregistrați-vă în variabilele gitlab în setările CI/CD cu conținutul certificatelor. Scrieți un script .gitlab-ci.yml pentru implementare.

Voi arăta toate exemplele despre distribuția Debian.

Configurare VPS inițială

Deci ați cumpărat o instanță, de exemplu, la DO, primul lucru pe care trebuie să-l faceți este să vă protejați serverul de lumea exterioară agresivă. Nu voi dovedi și nu voi afirma nimic, voi afișa doar jurnalul /var/log/messages al serverului meu virtual:

ScreenshotConfigurarea CD-ului prin gitlab

Mai întâi, instalați paravanul de protecție ufw:

apt-get update && apt-get install ufw

Să activăm politica implicită: blocați toate conexiunile de intrare, permiteți toate conexiunile de ieșire:

ufw default deny incoming
ufw default allow outgoing

Important: nu uitați să permiteți conexiunea prin ssh:

ufw allow OpenSSH

Sintaxa generală este următoarea: Permite o conexiune prin port: ufw allow 12345, unde 12345 este numărul portului sau numele serviciului. Deny: ufw deny 12345

Porniți firewall-ul:

ufw enable

Ieșim din sesiune și ne conectăm din nou prin ssh.

Adăugați un utilizator, atribuiți-i o parolă și adăugați-l în grupul sudo.

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

Apoi, conform planului, ar trebui să dezactivați autentificarea prin parolă. pentru a face acest lucru, copiați cheia ssh pe server:

ssh-copy-id [email protected]

IP-ul serverului trebuie să fie al tău. Acum încercați să vă conectați folosind utilizatorul creat anterior; nu mai trebuie să introduceți o parolă. Apoi, în setările de configurare, modificați următoarele:

sudo nano /etc/ssh/sshd_config

dezactivați autentificarea prin parolă:

PasswordAuthentication no

Reporniți demonul sshd:

sudo systemctl reload sshd

Acum, dacă dvs. sau altcineva încercați să vă conectați ca utilizator root, nu va funcționa.

Apoi, instalați dockerd, nu voi descrie procesul aici, deoarece totul poate fi deja schimbat, urmați linkul către site-ul oficial și parcurgeți pașii de instalare a docker pe mașina dvs. virtuală: https://docs.docker.com/install/linux/docker-ce/debian/

Generarea certificatelor

Pentru a controla demonul docker de la distanță, este necesară o conexiune TLS criptată. Pentru a face acest lucru, trebuie să aveți un certificat și o cheie, care trebuie să fie generate și transferate pe mașina dvs. de la distanță. Urmați pașii indicați în instrucțiunile de pe site-ul web oficial docker: https://docs.docker.com/engine/security/https/#create-a-ca-server-and-client-keys-with-openssl Toate fișierele *.pem generate pentru server, și anume ca.pem, server.pem, key.pem, trebuie să fie plasate în directorul /etc/docker de pe server.

Se instalează dockerd

În scriptul de lansare a demonului docker, eliminăm opțiunea -H df://, această opțiune determină pe ce gazdă poate fi controlat demonul docker.

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

Apoi, ar trebui să creați un fișier de setări, dacă nu există deja, și să specificați opțiunile:

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

Să permitem conexiuni pe portul 2376:

sudo ufw allow 2376

Să repornim dockerd cu noile setări:

sudo systemctl daemon-reload && sudo systemctl restart docker

Sa verificam:

sudo systemctl status docker

Dacă totul este „verde”, atunci considerăm că am configurat cu succes docker pe server.

Configurarea livrării continue pe gitlab

Pentru ca lucrătorul Gitalaba să poată executa comenzi pe o gazdă Docker la distanță, este necesar să se decidă cum și unde să stocheze certificatele și cheia pentru o conexiune criptată cu Dockerd. Am rezolvat această problemă adăugând pur și simplu următoarele la variabilele din setările gitlbab:

titlu spoilerConfigurarea CD-ului prin gitlab

Doar scoateți conținutul certificatelor și cheii prin cat: cat ca.pem. Copiați și lipiți în valorile variabilei.

Să scriem un script pentru implementare prin GitLab. Se va folosi imaginea docker-in-docker (dind).

.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 # скрипт деплоя тут

Conținutul scriptului de implementare cu comentarii:

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

Problema principală a fost să „trageți” conținutul certificatelor într-o formă normală din variabilele CI/CD gitlab. Nu mi-am putut da seama de ce conexiunea la gazda la distanță nu funcționa. Pe gazdă m-am uitat la jurnalul sudo journalctl -u docker, a apărut o eroare în timpul strângerii de mână. Am decis să mă uit la ceea ce este în general stocat în variabile; pentru a face acest lucru, puteți arăta astfel: cat -A $DOCKER_CERT_PATH/key.pem. Am depășit eroarea prin adăugarea eliminării caracterului transport tr -d 'r'.

Apoi, puteți adăuga sarcini post-lansare la script, la discreția dvs. Puteți vizualiza versiunea de lucru în depozitul meu https://gitlab.com/isqad/gitlab-ci-cd

Sursa: www.habr.com

Adauga un comentariu