ProHoster > Blog > administracja > Konfigurowanie płyty CD za pomocą gitlab

Konfigurowanie płyty CD za pomocą gitlab

Kiedyś myślałem o zautomatyzowaniu wdrażania mojego projektu. gitlab.com uprzejmie zapewnia wszystkie narzędzia do tego celu i oczywiście zdecydowałem się z niego skorzystać, rozpracowując to i pisząc mały skrypt wdrożeniowy. W tym artykule dzielę się swoimi doświadczeniami ze społecznością.

TL; DR

  1. Skonfiguruj VPS: wyłącz root, zaloguj się hasłem, zainstaluj dockerd, skonfiguruj ufw
  2. Generuj certyfikaty dla serwera i klienta docs.docker.com/engine/security/https/#create-a-ca-server-and-client-keys-with-openssl Włącz kontrolę dockerda przez gniazdo TCP: usuń opcję -H fd:// z konfiguracji dokera.
  3. Zarejestruj ścieżki do certyfikatów w pliku docker.json
  4. Zarejestruj się w zmiennych gitlab w ustawieniach CI/CD z zawartością certyfikatów. Napisz skrypt .gitlab-ci.yml do wdrożenia.

Pokażę wszystkie przykłady dotyczące dystrybucji Debiana.

Wstępna konfiguracja VPS

Kupiłeś więc instancję np DO, pierwszą rzeczą, którą musisz zrobić, to chronić swój serwer przed agresywnym światem zewnętrznym. Nie będę niczego udowadniał ani zapewniał, po prostu pokażę logi /var/log/messages mojego wirtualnego serwera:

Zrzut ekranuKonfigurowanie płyty CD za pomocą gitlab

Najpierw zainstaluj zaporę ufw:

apt-get update && apt-get install ufw

Włączmy domyślną politykę: blokuj wszystkie połączenia przychodzące, zezwalaj na wszystkie połączenia wychodzące:

ufw default deny incoming
ufw default allow outgoing

Ważne: nie zapomnij zezwolić na połączenie przez ssh:

ufw allow OpenSSH

Ogólna składnia jest następująca: Zezwól na połączenie według portu: ufw zezwolenia 12345, gdzie 12345 to numer portu lub nazwa usługi. Odmów: ufw odmów 12345

Włącz zaporę sieciową:

ufw enable

Wychodzimy z sesji i logujemy się ponownie przez ssh.

Dodaj użytkownika, przypisz mu hasło i dodaj go do grupy sudo.

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

Następnie zgodnie z planem należy wyłączyć logowanie hasłem. aby to zrobić, skopiuj klucz ssh na serwer:

ssh-copy-id [email protected]

IP serwera musi być Twoje. Teraz spróbuj zalogować się przy użyciu utworzonego wcześniej użytkownika, nie musisz już wpisywać hasła. Następnie w ustawieniach konfiguracyjnych zmień:

sudo nano /etc/ssh/sshd_config

wyłącz logowanie hasłem:

PasswordAuthentication no

Uruchom ponownie demona sshd:

sudo systemctl reload sshd

Teraz, jeśli Ty lub ktoś inny spróbuje zalogować się jako użytkownik root, nie zadziała.

Następnie zainstaluj dockerd, nie będę tutaj opisywał procesu, ponieważ wszystko można już zmienić, kliknij link do oficjalnej strony i wykonaj kroki instalacji dockera na swojej maszynie wirtualnej: https://docs.docker.com/install/linux/docker-ce/debian/

Generowanie certyfikatów

Aby zdalnie sterować demonem dokującym, wymagane jest szyfrowane połączenie TLS. Aby to zrobić, musisz mieć certyfikat i klucz, który należy wygenerować i przesłać na zdalną maszynę. Postępuj zgodnie z instrukcjami na oficjalnej stronie dokera: https://docs.docker.com/engine/security/https/#create-a-ca-server-and-client-keys-with-openssl Wszystkie wygenerowane pliki *.pem dla serwera, a mianowicie ca.pem, serwer.pem, key.pem, muszą zostać umieszczone w katalogu /etc/docker na serwerze.

Konfigurowanie dockerda

W skrypcie uruchamiającym demona dokującego usuwamy opcję -H df://, opcja ta określa, na którym hoście można sterować demonem dokującym.

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

Następnie należy utworzyć plik ustawień, jeśli jeszcze nie istnieje, i określić opcje:

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

Zezwólmy na połączenia na porcie 2376:

sudo ufw allow 2376

Uruchommy ponownie Dockerd z nowymi ustawieniami:

sudo systemctl daemon-reload && sudo systemctl restart docker

Sprawdźmy:

sudo systemctl status docker

Jeśli wszystko jest „zielone”, uważamy, że pomyślnie skonfigurowaliśmy doker na serwerze.

Konfigurowanie ciągłego dostarczania na gitlabie

Aby pracownik Gitalaby mógł wykonywać polecenia na zdalnym hoście Dockera, należy zdecydować, jak i gdzie przechowywać certyfikaty oraz klucz do szyfrowanego połączenia z Dockerdem. Rozwiązałem ten problem, po prostu dodając następujące elementy do zmiennych w ustawieniach gitlbaba:

tytuł spoileraKonfigurowanie płyty CD za pomocą gitlab

Po prostu wyprowadź zawartość certyfikatów i klucza za pośrednictwem cat: cat ca.pem. Skopiuj i wklej do wartości zmiennych.

Napiszmy skrypt do wdrożenia poprzez GitLab. Zostanie użyty obraz okna dokowanego w oknie dokowanym (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 # скрипт деплоя тут

Zawartość skryptu wdrożeniowego wraz z komentarzami:

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

Głównym problemem było „wyciągnięcie” zawartości certyfikatów w normalnej formie ze zmiennych CI/CD gitlaba. Nie mogłem zrozumieć, dlaczego połączenie ze zdalnym hostem nie działa. Na hoście zajrzałem do okna dokowanego dziennika Sudo journalctl -u, wystąpił błąd podczas uzgadniania. Postanowiłem przyjrzeć się temu, co zazwyczaj jest przechowywane w zmiennych; w tym celu możesz wyglądać tak: cat -A $DOCKER_CERT_PATH/key.pem. Pokonałem błąd, dodając usunięcie znaku karetki tr -d „r”.

Następnie możesz według własnego uznania dodać do skryptu zadania po wydaniu. Działającą wersję możesz zobaczyć w moim repozytorium https://gitlab.com/isqad/gitlab-ci-cd

Źródło: www.habr.com

Dodaj komentarz