🥇Vytváření CI/CD řetězce a automatizace práce s Dockerem

Svůj první web jsem napsala na konci 90. let. Tehdy bylo jejich uvedení do provozu velmi jednoduché. Byl tu server Apache na nějakém sdíleném hostingu, na který se dalo připojit přes FTP napsáním něčeho jako ftp://ftp.example.com. Poté bylo nutné zadat jméno a heslo a nahrát soubory na server. Byly to jiné časy, všechno bylo tehdy jednodušší než dnes.

Během těch uplynulých dvaceti let se toho hodně změnilo. Weby se staly složitějšími, před uvedením do produkce je potřeba je sestavit. Jeden jediný server se stal mnoha servery pracujícími za load balancery, běžné je používání systémů pro správu verzí.

Pro svůj osobní projekt jsem měla speciální konfiguraci. A věděla jsem, že potřebuji možnost deployovat web do produkce jediným krokem: zápisem kódu do větve master na GitHubu. Také jsem věděla, že pro zajištění fungování mého malého webového projektu se mi nechce zabývat správou obrovského Kubernetes klastru, používat technologii Docker Swarm, nebo spravovat park serverů s kontejnery, agenty a dalšími složitostmi. Abych dosáhla cíle maximálního zjednodušení práce, musela jsem se seznámit s CI/CD.

Pokud máte malý projekt (v našem případě se jedná o projekt Node.js) a chtěli byste vědět, jak automatizovat jeho nasazení, přičemž to, co je uloženo v repozitáři, by přesně odpovídalo tomu, co funguje v produkci, pak by vás tento článek mohl zajímat.

Požadavky

Očekává se, že čtenář tohoto článku má základní znalosti o práci s příkazovým řádkem a psaní skriptů v Bash. Dále budou potřebné účty Travis CI a Docker Hub.

Cíle

Nehodlám tvrdit, že tento článek může být bezpodmínečně považován za "výukového průvodce". Je to spíše dokument, ve kterém popisuji, co jsem se naučila, a zmiňuji vyhovující proces testování a nasazování kódu do produkce, který se provádí za jeden automatizovaný průchod.

Takto vypadal nakonec můj pracovní proces.

Pro kód odeslaný do jakékoli větve repozitáře kromě master, se provádějí následující akce:

Spustí se sestavení projektu na Travis CI.
Všechny modulové, integrační a end-to-end testy se provedou.

Pouze pro kód, který spadá do master, platí následující:

Všechno, co bylo řečeno výše, plus…
Vytvoření Docker obrazu na základě aktuálního kódu, konfigurací a prostředí.
Umístění obrazu na Docker Hub.
Připojení k produkčnímu serveru.
Stažení obrazu z Docker Hub na server.
Zastavení aktuálního kontejneru a spuštění nového, založeného na novém obrazu.

Pokud o Dockeru, obrazech a kontejnerech nevíte vůbec nic — nebojte se. O všem vám to podrobně povím.

Co je CI/CD?

Zkratka CI/CD znamená 'continuous integration/continuous deployment' — 'pravidelná integrace/pravidelné nasazení'.

▍Pravidelná integrace

Pravidelná integrace je proces, při kterém vývojáři provádějí commity do hlavního úložiště zdrojového kódu projektu (obvykle do větve master). Kvalita kódu je zajištěna prováděním automatizovaných testů.

▍Pravidelné nasazení

Pravidelné nasazení je časté automatizované nasazení kódu do produkce. Druhá část zkratky CI/CD se někdy rozvádí jako 'continuous delivery' ('pravidelná dodávka'). To je v podstatě totéž jako 'pravidelné nasazení', ale 'pravidelná dodávka' implikuje potřebu ručního potvrzení změn před spuštěním procesu nasazení projektu.

Začínáme

Aplikace, na které jsem to všechno osvojila, se jmenuje TakeNote. Je to webový projekt, na kterém pracuji, určený k provádění poznámek. Nejprve jsem se pokusila vytvořit JAMStack-projekt, nebo pouze frontendovou aplikaci bez serveru, abych využila standardní možnosti hostingu a nasazení projektů, které nabízí Netlify. Jak se složitost aplikace zvyšovala, potřebovala jsem vytvořit i její serverovou část, což znamenalo, že jsem musela vytvořit vlastní strategii pro automatizovanou integraci a automatizované nasazení projektu.

V mém případě aplikace představuje Express server běžící ve prostředí Node.js, obsluhující jednopageovou React aplikaci a podporující zabezpečené serverové API. Tato architektura následuje strategii, kterou lze nalézt v této příručce pro full-stack autentizaci.

Poraďila jsem se s přítelem, který je odborníkem na automatizaci, a zeptala jsem se ho, co musím udělat, aby to všechno fungovalo, jak potřebuji. Navrhl mi myšlenku, jak by měl vypadat automatizovaný pracovní proces, jak je uvedeno v části „Cíle“ tohoto článku. To, že jsem si stanovila podobné cíle, znamenalo, že se musím naučit používat Docker.

Docker

Docker je nástroj, který díky technologii kontejnerizace umožňuje snadno distribuovat aplikace, stejně jako je nasazovat a spouštět v jednom a tom samém prostředí, i když samotná platforma Docker funguje v různých prostředích. Nejdříve jsem potřebovala získat své nástroje příkazové řádky (CLI) Docker. Návod na instalaci Dockeru nelze nazvat příliš jasným a srozumitelným, ale lze se z něj dozvědět, že abych provedla první krok instalace, musím stáhnout Docker Desktop (pro Mac nebo Windows).

Docker Hub je zhruba to samé, co GitHub pro git repozitáře, neboli registr npm pro JavaScript balíčky. Je to online repozitář pro obrazy Dockeru. Právě do něj se připojuje Docker Desktop.

Takže abych začala pracovat s Dockerem, musím udělat dvě věci:

Nainstalujte Docker Desktop.
Zaregistrujte se na Docker Hub.

Poté můžete zkontrolovat funkčnost Docker CLI, spuštěním následujícího příkazu pro kontrolu verze Dockeru:

docker -v

Poté se přihlaste do Docker Hubu tím, že, až vás o to požádají, zadáte své uživatelské jméno a heslo:

docker login

Abych mohla používat Docker, musím chápat koncepty obrazů a kontejnerů.

▍Obrazy

Obraz je jakýsi plán obsahující pokyny pro sestavení kontejneru. Je to neměnný snímek souborového systému a nastavení aplikace. Vývojáři si mohou snadno vyměňovat obrazy.

# Вывод сведений обо всех образах
docker images

Tento příkaz zobrazí tabulku s následujícím nadpisem:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

Dále budeme zvažovat některé příklady příkazů ve stejném formátu — nejprve jde příkaz s komentářem a pak — příklad toho, co může vyprodukovat.

▍Kontejnery

Kontejner je exekuční balíček, který obsahuje vše potřebné k běhu aplikace. Aplikace v tomto přístupu bude vždy fungovat stejně, bez ohledu na infrastrukturu: v izolovaném prostředí a ve stejné prostředí. Jde o to, že v různých prostředích běží instance jedné a téže obrazce.

# Перечисление всех контейнеров
docker ps -a
CONTAINER ID     IMAGE     COMMAND     CREATED     STATUS     PORTS     NAMES
---

▍Tagy

Tag je označení pro konkrétní verzi obrazu.

▍Stručný přehled příkazů Docker

Zde je přehled některých často používaných příkazů Docker.

Tým

Kontext

Činnost

docker build

Obraz

Sestavení obrazu z Dockerfile

docker tag

Obraz

Označení obrazu

docker images

Obraz

Výstup seznamu obrazů

docker run

Kontejner

Spuštění kontejneru na základě obrazu

docker push

Obraz

Odeslání obrazu do registru

docker pull

Obraz

Stažení obrazu z registru

docker ps

Kontejner

Výstup seznamu kontejnerů

docker system prune

Obraz/Kontejner

Odstranění nepoužívaných kontejnerů a obrazů

▍Soubor Dockerfile

Vím, jak lokálně spustit aplikaci pro produkční prostředí. Mám konfiguraci Webpack, určenou k sestavení hotové React aplikace. Dále mám příkaz, který spouští server založený na Node.js na portu 5000. Vypadá to takto:

npm i         # instalace závislostí
npm run build # sestavení React aplikace
npm run start  # spuštění Node serveru

Je třeba poznamenat, že nemám aplikační příklad pro tento materiál. Ale zde, pro experimenty, by vyhovoval jakýkoli jednoduchý Node.js aplikace.

Abychom mohli využít kontejner, musíte dát instrukce Dockeru. To se děje prostřednictvím souboru, který se nazývá Dockerfile, nacházejícího se v kořenovém adresáři projektu. Tento soubor se zpočátku zdá být poněkud nepřehledný.

Ale to, co obsahuje, pouze popisuje, pomocí zvláštních příkazů, něco podobného nastavení pracovního prostředí. Zde jsou některé z těchto příkazů:

FROM — Tento příkaz začíná soubor. Uvádí základní obraz, na jehož základě se kontejner staví.
COPY — Kopírování souborů z místního zdroje do kontejneru.
WORKDIR — Nastavení pracovního adresáře pro následující příkazy.
RUN — Spuštění příkazů.
EXPOSE — Nastavení portu.
ENTRYPOINT — Určení vykonávaného příkazu.

Dockerfile může vypadat přibližně takto:

# Загрузить базовый образ
FROM node:12-alpine

# Скопировать файлы из текущей директории в директорию app/
COPY . app/

# Использовать app/ в роли рабочей директории
WORKDIR app/

# Установить зависимости (команда npm ci похожа npm i, но используется для автоматизированных сборок)
RUN npm ci --only-production

# Собрать клиентское React-приложение для продакшна
RUN npm run build

# Прослушивать указанный порт
EXPOSE 5000

# Запустить Node-сервер
ENTRYPOINT npm run start

V závislosti na vybraném základním obraze může být nutné nainstalovat další závislosti. Některé základní obrazy (jako Node Alpine Linux) byly vytvořeny s cílem co nejvíce zmenšit jejich velikost. V důsledku toho mohou chybět některé programy, na které spoléháte.

▍Sestavení, označení a spuštění kontejneru

Lokální sestavení a spuštění kontejneru — to je, jakmile máme Dockerfile, úkoly jsou docela jednoduché. Než pošlete obraz na Docker Hub, musíte ho nejprve otestovat lokálně.

▍Sestavení

Nejprve musíte sestavit obraz, určete název a, pokud je to potřeba, také označení (pokud označení nezadáte, systém automaticky přiřadí obrazu označení latest).

# Сборка образа
docker build -t <image>:<tag> .

Po provedení tohoto příkazu můžete sledovat, jak Docker provádí sestavení obrazu.

Odesílání kontextu sestavení na Docker daemon   2.88MB
Krok 1/9 : ZÁKLAD node:12-alpine
 ---> ...spouštění kroků sestavení...
Úspěšně sestaveno 123456789123
Úspěšně označeno <image>:<tag>

Sestavení může trvat několik minut — to závisí na tom, kolik máte závislostí. Po dokončení sestavení můžete spustit příkaz docker images a podívat se na popis svého nového obrazu.

REPOSITÁŘ          TAG               ID OBRAZU            VYTVOŘENO              VELIKOST
<image>             latest            123456789123        Před asi minutou   x.xxGB

▍Spuštění

Obraz byl vytvořen. To znamená, že na jeho základě lze spustit kontejner. Jelikož chci mít možnost přistupovat k aplikaci běžící v kontejneru na adrese localhost:5000, v levé části páru 5000:5000 v následujícím příkazu jsem nastavila 5000. V pravé části je port kontejneru.

# Запуск с использованием локального порта 5000 и порта контейнера 5000
docker run -p 5000:5000 <image>:<tag>

Nyní, když je kontejner vytvořen a spuštěn, můžete použít příkaz docker ps abyste se podívali na informace o tomto kontejneru (nebo můžete použít příkaz docker ps -a, který zobrazuje informace o všech kontejnerech, nikoli pouze o běžících).

ID KONTEJNERU        OBRAZ               PŘÍKAZ                  VYTVOŘENO              STAV                      PORTY                    NÁZVY
987654321234        <image>             "\/bin\/sh -c 'npm run…"   6 sekundami zpět        Běží 6 sekund                0.0.0.0:5000->5000\/tcp   stoic_darwin

Pokud nyní přejdete na adresu localhost:5000 — můžete vidět stránku běžící aplikace, která vypadá úplně stejně jako stránka aplikace běžící v produkčním prostředí.

▍Přiřazení označení a publikace

Aby skorzystać z jednego z utworzonych obrazów na serwerze produkcyjnym, musimy mieć możliwość załadowania tego obrazu z Docker Hub. Oznacza to, że najpierw musimy utworzyć na Docker Hub repozytorium dla projektu. Po tym będziemy mieć miejsce, w które możemy wysłać obraz. Należy zmienić nazwę obrazu, tak aby zaczynała się od naszej nazwy użytkownika na Docker Hub. Następnie powinna być podana nazwa repozytorium. Na końcu nazwy może znajdować się dowolny tag. Poniżej przedstawiono przykład nazewnictwa obrazów według tej schemy.

Teraz możemy zbudować obraz, nadając mu nową nazwę i wykonać polecenie docker push aby wysłać go do repozytorium Docker Hub.

docker build -t /: .
docker tag /: /:latest
docker push /:

# W praktyce może to wyglądać na przykład tak:
docker build -t user/app:v1.0.0 .
docker tag user/app:v1.0.0 user/app:latest
docker push user/app:v1.0.0

Jeśli wszystko pójdzie zgodnie z planem, obraz będzie dostępny na Docker Hub i można go łatwo załadować na serwer lub przekazać innym programistom.

Další kroky

Do tej pory upewniliśmy się, że aplikacja w postaci kontenera Docker działa lokalnie. Załadowaliśmy kontener do Docker Hub. To wszystko oznacza, że jesteśmy już na bardzo dobrej drodze do celu. Teraz musimy rozwiązać jeszcze dwa pytania:

Konfiguracja narzędzia CI do testowania i wdrażania kodu.
Konfiguracja serwera produkcyjnego tak, aby mógł pobierać i uruchamiać nasz kod.

W naszym przypadku jako rozwiązania CI/CD używamy Travis CI. Jako serwera — DigitalOcean.

Należy zauważyć, że można skorzystać z innej kombinacji usług. Na przykład zamiast Travis CI można użyć CircleCI lub Github Actions. A zamiast DigitalOcean — AWS lub Linode.

Postanowiliśmy pracować z Travis CI, a w tym serwisie mam już coś skonfigurowane. Dlatego teraz krótko opowiem, jak przygotować go do pracy.

Travis CI

Travis CI to narzędzie do testowania i wdrażania kodu. Nie chciałbym zagłębiać się w szczegóły konfiguracji Travis CI, ponieważ każdy projekt jest unikalny, a to nie przyniesie szczególnych korzyści. Ale opowiem o podstawach, które pozwolą Ci rozpocząć pracę, jeśli zdecydujesz się na korzystanie z Travis CI. Cokolwiek wybierzesz — Travis CI, CircleCI, Jenkins, czy coś innego, wszędzie będą stosowane podobne metody konfiguracji.

Abyste mohli začít pracovat s Travis CI, přejděte na webovou stránku projektu a vytvořte si účet. Poté integrujte Travis CI s vaším účtem na GitHubu. Při nastavování systému budete muset určit repozitář, se kterým chcete automatizovat práci, a povolit k němu přístup. (Používám GitHub, ale jsem si jistá, že Travis CI může být integrován také s BitBucket, GitLab a dalšími podobnými službami).

Každýkrát, když Travis CI začne pracovat, spustí se server, který vykonává příkazy uvedené v konfiguračním souboru, včetně nasazení příslušných větví repozitáře.

▍Cyklus úlohy

Konfigurační soubor Travis CI, nazývaný .travis.yml a uložený v kořenovém adresáři projektu, podporuje koncept událostí cyklu života úlohy. Zde jsou tyto události uvedeny v pořadí, v jakém se vyskytují:

apt addons
cache components
before_install
install
before_script
script
before_cache
after_success nebo after_failure
before_deploy
deploy
after_deploy
after_script

▍Testování

V konfiguračním souboru hodlám nastavit lokální server Travis CI. Jako jazyk jsem zvolila Node verze 12 a označila jsem systému, že je třeba nainstalovat závislosti potřebné pro používání Dockeru.

Vše, co je uvedeno v .travis.yml, bude prováděno při všech pull requestech do všech větví repozitáře, pokud nebude uvedeno jinak. To je užitečná funkce, protože to znamená, že můžeme testovat celý kód přicházející do repozitáře. To nám umožňuje vědět, zda je kód připraven k záznamu do větve master, a zda nenaruší proces sestavení projektu. V této globální konfiguraci instaluji vše lokálně, spouštím server vývojáře Webpack na pozadí (to je charakteristika mého pracovního procesu) a provádím testy.

Pokud chcete, aby ve vašem repozitáři byly zobrazeny ikonky se statistikami pokrytí kódu testy, tady můžete najít stručný návod k použití Jest, Travis CI a Coveralls ke shromažďování a zobrazení těchto údajů.

Takže, zde je obsah souboru .travis.yml:

# Установить язык
language: node_js

# Установить версию Node.js
node_js:
  - '12'

services:
  # Использовать командную строку Docker
  - docker

install:
  # Установить зависимости для тестов
  - npm ci

before_script:
  # Запустить сервер и клиент для тестов
  - npm run dev &

script:
  # Запустить тесты
  - npm run test

Tímto končí akce, které se provádějí pro všechny větve repozitáře a pro pull requesty.

▍Nasazení

Předpokládáme-li, že všechny automatizované testy byly úspěšně dokončeny, můžeme (což není povinné) nasadit kód na produkční server. Jelikož to chceme dělat pouze pro kód z větve master, dáváme systému odpovídající pokyny v nastavení nasazení. Než budete moci ve svém projektu použít kód, který budeme dále zkoumat, chtěla bych vás varovat, že musíte mít skutečný skript, který se spouští pro nasazení.

deploy:
  # Sestavit Docker kontejner a odeslat ho na Docker Hub
  provider: script
  script: bash deploy.sh
  on:
    branch: master

Skript pro nasazení řeší dvě úlohy:

Sestavení, tagování a odeslání obrazu na Docker Hub pomocí CI nástroje (v našem případě Travis CI).
Nahrání obrazu na server, zastavení starého kontejneru a spuštění nového (v našem případě server běží na platformě DigitalOcean).

Nejprve je třeba nastavit automatický proces sestavování, tagování a odesílání obrazu na Docker Hub. To vše je velmi podobné tomu, co jsme již dělali ručně, s výjimkou toho, že potřebujeme strategii přiřazování unikátních tagů obrazům a automatizaci přihlášení. Měla jsem potíže s některými detaily skriptu nasazení, jako jsou strategie tagování, přihlášení, kódování SSH klíčů, ustanovení SSH spojení. Ale naštěstí se můj přítel velmi dobře vyzná v bash, stejně jako v mnoha dalších věcech. Pomohl mi napsat tento skript.

Takže první část skriptu je odeslání obrazu na Docker Hub. Je to docela jednoduché. Schéma tagování, které používám, zahrnuje kombinaci git hash a git tag, pokud existuje. To umožňuje vytváření unikátního tagu a usnadňuje identifikaci sestavení, na které je založeno. DOCKER_USERNAME a DOCKER_PASSWORD — to jsou uživatelské proměnné prostředí, které lze nastavit pomocí rozhraní Travis CI. Travis CI automaticky zpracovává tajné údaje tak, aby se nedostaly do cizích rukou.

Zde je první část skriptu. deploy.sh.

#!/bin/sh
set -e # Остановить скрипт при наличии ошибок

IMAGE="<username>/<repository>"                             # Образ Docker
GIT_VERSION=$(git describe --always --abbrev --tags --long) # Git-хэш и теги

# Сборка и тегирование образа
docker build -t ${IMAGE}:${GIT_VERSION} .
docker tag ${IMAGE}:${GIT_VERSION} ${IMAGE}:latest

# Вход в Docker Hub и выгрузка образа
echo "${DOCKER_PASSWORD}" | docker login -u "${DOCKER_USERNAME}" --password-stdin
docker push ${IMAGE}:${GIT_VERSION}

Jak bude vypadat druhá část skriptu, závisí zcela na tom, jakého hostitele používáte a jak je připojení k němu uspořádáno. V mém případě, protože používám Digital Ocean, se pro přístup k serveru používají příkazy doctl. Při práci s AWS se bude používat nástroj aws, a tak dále.

Nastavení serveru nebylo příliš složité. Tak jsem nastavila droplet založený na základním obrazu. Je třeba poznamenat, že vybraný systém vyžaduje jednorázovou ruční instalaci Dockeru a jednorázové ruční spuštění Dockeru. Pro instalaci Dockeru jsem použila Ubuntu 18.04, takže pokud také používáte Ubuntu, abyste udělali totéž, můžete jednoduše následovat tohoto jednoduchý návod.

Nemluvím zde o konkrétních příkazech pro službu, protože se tento aspekt v různých případech může výrazně lišit. Uvedu pouze obecný plán činností, které se provádějí po připojení přes SSH k serveru, na kterém bude projekt nasazen:

Je třeba najít kontejner, který je právě spuštěn, a zastavit ho.
Poté je nutné spustit nový kontejner na pozadí.
Budete potřebovat nastavit místní port serveru na hodnotu 80 — to umožní přístup na webovou stránku na adrese typu example.com, bez zadání portu, místo adresy jako example.com:5000.
A nakonec je třeba odstranit všechny staré kontejnery a obrazy.

Toto je pokračování skriptu.

# Найти ID работающего контейнера
CONTAINER_ID=$(docker ps | grep takenote | cut -d" " -f1)

# Остановить старый контейнер, запустить новый, очистить систему
docker stop ${CONTAINER_ID}
docker run --restart unless-stopped -d -p 80:5000 ${IMAGE}:${GIT_VERSION}
docker system prune -a -f

Některé věci, na které byste měli dávat pozor

Možná, když se připojíte k serveru přes SSH z Travis CI, uvidíte varování, které neumožní pokračovat v instalaci, protože systém čeká na reakci uživatele.

Ověření hostitele '<hostname> (<IP address>)' nemůže být provedeno.
Otisk RSA klíče je <key fingerprint>.
Opravdu chcete pokračovat v připojení (ano/nejde)?

Zjistila jsem, že řetězový klíč lze zakódovat do base64, aby bylo možné ho uchovat v takové podobě, se kterou bude snadné a spolehlivé pracovat. Ve fázi instalace lze veřejný klíč dešifrovat a uložit do souboru known_hosts aby se zbavili výše uvedené chyby.

echo <public key> | base64 # zobrazí <veřejný klíč zakódovaný v base64>

V praxi může tento příkaz vypadat takto:

echo "123.45.67.89 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3
Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA
t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En
mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
NrRFi9wrf+M7Q== you@example.com" | base64

A takto vypadá to, co to vydává — řetězec v kódování base64:

123.45.67.89 ssh-rsa AABAB3NzaC1y... (base64 encoded public key)

Toto je příkaz, o kterém se hovořilo výše

install:
  - echo  | base64 -d >> $HOME/.ssh/known_hosts

Stejný přístup lze použít i s privátním klíčem při navazování připojení, protože pro přístup na server může být nutný privátní klíč. Při práci s klíčem je důležité zajistit jeho bezpečné uchovávání v proměnné prostředí Travis CI, a aby se nikde nezobrazoval.

Ještě jedna věc, na kterou je dobré myslet, je, že budete možná potřebovat spustit celý skript pro nasazení jako jeden řádek, například pomocí doctl. To může vyžadovat dodatečné úsilí.

doctl compute ssh  --ssh-command "všechny příkazy budou zde && zde"

TLS/SSL a load balancing

Poté, co jsem udělala všechno, o čem byla řeč výše, byla posledním problémem, který jsem čelila, absence SSL na serveru. Protože používám Node.js server, abych přiměla pracovat Nginx reverse proxy a Let’s Encrypt, je třeba se s tím trošku poprat.

Nechtěla jsem všechny tyto SSL nastavení provádět ručně, takže jsem jednoduše vytvořila load balancer a zapsala jeho informace do DNS. V případě DigitalOcean například, vytvoření automaticky obnovitelného self-signed certifikátu na load balanceru je jednoduchý, bezplatný a rychlý postup. Tento přístup má také další výhodu, kterou je to, že velmi snadno umožňuje nastavit SSL na mnoha serverech pracujících za load balancerem. To umožňuje samotným serverům „není přemýšlet“ o SSL, ale stále používat port 80. Takže nastavení SSL na load balanceru je mnohem jednodušší a pohodlnější než alternativní metody nastavení SSL.

Nyní lze na serveru zavřít všechny porty, které přijímají příchozí připojení — kromě portu 80, používaného pro komunikaci s load balancerem, a portu 22 pro SSH. V důsledku toho pokus o přímý přístup k serveru na jakýchkoli portech, kromě těchto dvou, bude neúspěšný.

Závěry

Jakmile jsem udělala všechno, o čem jsem v tomto článku psala, už mě nelekala ani platforma Docker, ani koncept automatizovaných CI/CD řetězců. Dokázala jsem nastavit řetězec kontinuální integrace, během kterého se provádí testování kódu před jeho nasazením do produkce a automatické nasazení kódu na serveru. To všechno je pro mě zatím relativně nové a jsem si jistá, že existují způsoby, jak zlepšit můj automatizovaný pracovní proces a učinit ho efektivnějším. Takže pokud máte nějaké nápady, dejte mi vědět. Doufám, že vám tento článek pomohl ve vašich projektech. Chci věřit, že jste se z něj naučili tolik, kolik jsem se naučila já, když jsem se zabývala vším, o čem v něm píšu.

P.S. V našem marketplace existuje obraz Docker, který se instaluje jedním kliknutím. Můžete zkontrolovat funkčnost kontejnerů na VPS. Všem novým klientům se poskytují 3 dny testování zdarma.

Vážení čtenáři! Používáte technologie CI/CD ve svých projektech?

Zdroj: habr.com