M-am gândit o dată la automatizarea desfășurării proiectului meu. gitlab.com oferă toate instrumentele necesare pentru aceasta și, bineînțeles, am decis să profit de această oportunitate, învățând și scriind un mic scenariu pentru desfășurare. În acest articol, îmi împărtășesc experiența cu comunitatea.
TL;DR
- Configurarea VPS: dezactivarea root, autentificare prin parolă, instalarea dockerd, configurarea ufw.
- Generarea certificatelor pentru server și client. Activarea gestionării dockerd prin socket TCP: eliminarea opțiunii -H fd:// din configurația Docker.
- Прописать пути до сертификатов в docker.json
- Definiți variabilele în GitLab în setările CI/CD cu conținutul certificatelor. Scrieți un script .gitlab-ci.yml pentru desfășurare.
Toate exemplele vor fi prezentate pe distribuția Debian.
Configurarea inițială a VPS-ului.
Ați achiziționat un instanț de exemplu de la , primul lucru pe care trebuie să-l faceți este să vă protejați serverul de lumea externă agresivă. Nu voi demonstra nimic, doar voi arăta jurnalul /var/log/messages al serverului meu virtual:
Captură de ecran
În primul rând, să instalăm firewall-ul ufw:
apt-get update && apt-get install ufwSă activăm politica implicită: blocăm toate conexiunile intrante, permitem toate conexiunile externe:
ufw default deny incoming
ufw default allow outgoingImportant: să nu uităm să permitem conexiunea prin ssh:
ufw allow OpenSSHSintaxa generală este: Permiteți conexiunea pe port: ufw allow 12345, unde 12345 este numărul portului sau numele serviciului. Interziceți: ufw deny 12345
Activăm firewall-ul:
ufw enableIeșiți din sesiune și conectați-vă din nou prin ssh.
Adăugați un utilizator, stabiliți-i o parolă și adăugați-l în grupul sudo.
apt-get install sudo
adduser scoty
usermod -aG sudo scotyUrmătorul pas este dezactivarea autentificării prin parolă. Pentru aceasta, copiați cheia dvs. ssh pe server:
ssh-copy-id root@10.101.10.28ip-ul serverului trebuie să fie cel corespunzător. Încercați acum să vă conectați cu utilizatorul creat anterior, parola nu va mai fi necesară. Apoi, în setările de configurare, schimbați următoarele:
sudo nano /etc/ssh/sshd_configdezactivate autentificarea prin parolă:
PasswordAuthentication noRepornim demonul sshd:
sudo systemctl reload sshdAcum, dacă dumneavoastră sau altcineva încercați să vă conectați prin utilizatorul root, nu va reuși.
Următorul pas este instalarea dockerd, nu voi descrie acest proces aici, deoarece s-ar putea să fi fost deja schimbat, accesați linkul de mai sus la site-ul oficial și urmați pașii pentru instalarea docker pe mașina virtuală:
Generarea certificatelor
Pentru a gestiona demoni Docker de la distanță, este necesară o conexiune TLS criptată. Pentru aceasta, trebuie să aveți un certificat și o cheie, care trebuie generate și transferate pe mașina dvs. de la distanță. Urmați pașii indicați în instrucțiunile de pe site-ul oficial Docker: Toate fișierele *.pem generate pentru server, și anume ca.pem, server.pem, key.pem, trebuie plasate în directorul /etc/docker pe server.
Configurarea dockerd
În scriptul de pornire al demonului Docker, eliminăm opțiunea -H df://, această opțiune răspunde de pe ce gazdă poate fi gestionat demonul Docker.
# At /lib/systemd/system/docker.service
[Service]
Type=notify
ExecStart=/usr/bin/dockerdUrmătorul pas este să creăm un fișier de setări, dacă nu există deja, și să specificăm 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 conexiunile pe portul 2376:
sudo ufw allow 2376Să repornim dockerd cu noile setări:
sudo systemctl daemon-reload && sudo systemctl restart dockerSă verificăm:
sudo systemctl status dockerDacă totul este „verde”, înseamnă că am configurat cu succes Docker pe server.
Configurarea livrării continue pe GitLab
Pentru ca worker-ul de pe GitLab să poată executa comenzi pe gazda Docker la distanță, trebuie să stabilim cum și unde să stocăm certificatele și cheia pentru conexiunea criptată la dockerd. Am rezolvat această problemă pur și simplu specificând în variabilele din setările GitLab:
Titlu spoiler
Pur și simplu afișați conținutul certificatelor și cheii cu ajutorul comenzii cat: cat ca.pem. Copiați și lipiți în valoarea variabilelor.
Să scriem un script pentru desfășurare prin GitLab. Vom folosi imaginea docker-in-docker (dind).
.gitlab-ci.yml
image:
name: docker/compose:1.23.2
# să rescriem entrypoint-ul, pentru a funcționa în 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 # scriptul de desfășurare aici
Conținutul scriptului de desfășurare 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
Principala problemă a fost să „extragi” din variabilele GitLab CI/CD conținutul certificatelor într-o formă corespunzătoare. Nu reușeam să înțeleg de ce nu funcționa conexiunea cu gazda de la distanță. Am verificat jurnalul gazdei cu sudo journalctl -u docker, unde era o eroare la negociere. Am decis să văd ce se depozitează în variabile, pentru aceasta se poate verifica așa cat -A $DOCKER_CERT_PATH/key.pem. Am rezolvat eroarea, adăugând eliminarea caracterului de întoarcere a cursei tr -d ‘r’.
Mai departe, în scenariul poate fi adăugat, la alegerea dumneavoastră, sarcini post-reliză. Puteți consulta versiunea de lucru în repo-ul meu.
Sursa: habr.com
