Vytvorenie reťazca CI/CD a automatizácia práce s Dockerom

Svoje prvé webové stránky som napísal koncom 90. rokov. Vtedy bolo veľmi jednoduché uviesť ich do prevádzkyschopného stavu. Na nejakom zdieľanom hostingu bol server Apache, na tento server ste sa mohli prihlásiť cez FTP napísaním niečoho podobného ftp://ftp.example.com. Potom ste museli zadať svoje meno a heslo a nahrať súbory na server. Boli iné časy, všetko bolo vtedy jednoduchšie ako teraz.

Za dve desaťročia odvtedy sa všetko veľmi zmenilo. Webové stránky sa stali zložitejšími, pred uvedením do výroby musia byť zostavené. Z jedného jediného servera sa stalo mnoho serverov bežiacich za nástrojmi na vyrovnávanie záťaže a používanie systémov správy verzií sa stalo samozrejmosťou.

Pre môj osobný projekt som mal špeciálnu konfiguráciu. A vedel som, že potrebujem možnosť nasadiť lokalitu do produkcie vykonaním iba jednej akcie: napísaním kódu do pobočky master na GitHub. Okrem toho som vedel, že na zabezpečenie chodu mojej malej webovej aplikácie nechcem spravovať obrovský klaster Kubernetes, používať technológiu Docker Swarm, ani udržiavať flotilu serverov s modulmi, agentmi a všelijakými inými zložitosti. Aby som dosiahol cieľ čo najviac uľahčiť prácu, potreboval som sa zoznámiť s CI/CD.

Ak máte malý projekt (v tomto prípade projekt Node.js) a chceli by ste vedieť, ako automatizovať nasadenie tohto projektu a zároveň zabezpečiť, aby to, čo je uložené v úložisku, presne zodpovedalo tomu, čo funguje vo výrobe, potom myslím, že by vás tento článok mohol zaujímať.

Predpoklady

Od čitateľa tohto článku sa očakáva, že bude mať základné znalosti o príkazovom riadku a písaní skriptov Bash. Okrem toho bude potrebovať účty Travis C.I. и Docker hub.

ciele

Nehovorím, že tento článok možno bezpodmienečne nazvať „návodom“. Toto je skôr dokument, v ktorom hovorím o tom, čo som sa naučil a popisujem proces, ktorý mi vyhovuje na testovanie a nasadenie kódu do produkcie, vykonávané v jednom automatizovanom prechode.

Takto skončil môj pracovný postup.

Pre kód zaslaný do ktorejkoľvek pobočky úložiska okrem master, vykonajú sa tieto akcie:

• Začína sa projekt postavený na Travis CI.
• Vykonajú sa všetky testy jednotky, integrácie a end-to-end testy.

Iba pre kód, ktorý spadá do master, vykonáva sa nasledovné:

• Všetko spomenuté vyššie, plus...
• Vytvorenie obrazu Docker na základe aktuálneho kódu, nastavení a prostredia.
• Nasadenie obrázka do Docker Hub.
• Pripojenie k produkčnému serveru.
• Odovzdanie obrázka z Docker Hub na server.
• Zastavenie aktuálneho kontajnera a spustenie nového na základe nového obrázka.

Ak o Dockeri, obrázkoch a kontajneroch neviete absolútne nič, nebojte sa. Poviem vám o tom všetko.

Čo je CI/CD?

Skratka CI/CD znamená „kontinuálna integrácia/kontinuálne nasadenie“.

▍Nepretržitá integrácia

Nepretržitá integrácia je proces, v ktorom sa vývojári zaväzujú k hlavnému úložisku zdrojového kódu projektu (zvyčajne pobočka master). Zároveň je kvalita kódu zabezpečená prostredníctvom automatizovaného testovania.

▍Nepretržité nasadenie

Nepretržité nasadzovanie je časté, automatizované nasadzovanie kódu do produkcie. Druhá časť skratky CI/CD sa niekedy uvádza ako „nepretržité doručovanie“. Je to v podstate to isté ako „nepretržité nasadzovanie“, ale „priebežné doručovanie“ znamená potrebu manuálneho potvrdenia zmien pred začatím procesu nasadenia projektu.

Začíname

Aplikácia, pomocou ktorej som sa to všetko naučil, sa volá Zaznamenať si. Toto je webový projekt, na ktorom pracujem, určený na písanie poznámok. Najprv som sa o to pokúšal JAMStack-projekt alebo len front-end aplikácia bez servera, aby ste mohli využiť štandardné možnosti hosťovania a nasadenia projektov, ktoré ponúka Netlify. S rastúcou zložitosťou aplikácie som potreboval vytvoriť jej serverovú časť, čo znamenalo, že budem musieť sformulovať vlastnú stratégiu pre automatizovanú integráciu a automatizované nasadenie projektu.

V mojom prípade je aplikáciou Express server bežiaci v prostredí Node.js, ktorý obsluhuje jednostránkovú aplikáciu React a podporuje zabezpečené API na strane servera. Táto architektúra sleduje stratégiu, ktorú možno nájsť v toto Sprievodca overením úplného zásobníka.

Konzultoval som s priateľa, ktorý je odborníkom na automatizáciu, a spýtal sa ho, čo musím urobiť, aby to všetko fungovalo tak, ako chcem. Poskytol mi predstavu o tom, ako by mal vyzerať automatizovaný pracovný postup, načrtnutý v časti Ciele tohto článku. Mať tieto ciele znamenalo, že som potreboval prísť na to, ako používať Docker.

prístavný robotník

Docker je nástroj, ktorý vďaka technológii kontajnerizácie umožňuje aplikáciu jednoducho distribuovať, nasadzovať a spúšťať v rovnakom prostredí, aj keď samotná platforma Docker beží v rôznych prostrediach. Najprv som potreboval dostať do rúk nástroje príkazového riadka Docker (CLI). poučenie Pokyny na inštaláciu Docker nemožno nazvať veľmi jasnými a zrozumiteľnými, ale z nich sa dozviete, že ak chcete urobiť prvý krok inštalácie, musíte si stiahnuť Docker Desktop (pre Mac alebo Windows).

Docker Hub je zhruba to isté ako GitHub pre git repozitáre alebo register NPM pre balíky JavaScript. Toto je online úložisko obrázkov Docker. K tomu sa pripája Docker Desktop.

Ak teda chcete začať s Dockerom, musíte urobiť dve veci:

• Sada DockerDesktop.
• Zaregistrujte sa pre Docker hub.

Potom môžete skontrolovať, či rozhranie Docker CLI funguje spustením nasledujúceho príkazu na kontrolu verzie Docker:

docker -v

Potom sa prihláste do Docker Hub zadaním svojho používateľského mena a hesla, keď sa zobrazí výzva:

docker login

Ak chcete používať Docker, musíte pochopiť koncepty obrázkov a kontajnerov.

▍ Obrázky

Obrázok je niečo ako plán, ktorý obsahuje návod na zostavenie nádoby. Toto je nemenná snímka systému súborov a nastavení aplikácie. Vývojári môžu jednoducho zdieľať obrázky.

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

Tento príkaz vytvorí výstup tabuľky s nasledujúcou hlavičkou:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

Ďalej sa pozrieme na niekoľko príkladov príkazov v rovnakom formáte - najprv je príkaz s komentárom a potom príklad toho, čo môže vypísať.

▍ Nádoby

Kontajner je spustiteľný balík, ktorý obsahuje všetko potrebné na spustenie aplikácie. Aplikácia s týmto prístupom bude vždy fungovať rovnako, bez ohľadu na infraštruktúru: v izolovanom prostredí a v rovnakom prostredí. Ide o to, že inštancie toho istého obrazu sa spúšťajú v rôznych prostrediach.

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

▍ Značky

Značka je označenie konkrétnej verzie obrázka.

▍Rýchly odkaz na príkazy Docker

Tu je prehľad niektorých bežne používaných príkazov Docker.

Tím

kontext

účinok

zostava dockera

obraz

Vytvorenie obrázka zo súboru Dockerfile

docker tag

obraz

Označovanie obrázkov

dokovacia snímka

obraz

Zoznam obrázkov

docker run

Kontajner

Spustenie kontajnera na základe obrázka

docker push

obraz

Nahrávanie obrázka do registra

docker ťahať

obraz

Načítavanie obrázka z registra

docker ps

Kontajner

Výpis kontajnerov

docker systém prerezávať

Obrázok/kontajner

Odstránenie nepoužívaných kontajnerov a obrázkov

▍Dockerfile

Viem, ako spustiť produkčnú aplikáciu lokálne. Mám konfiguráciu Webpack navrhnutú na zostavenie hotovej aplikácie React. Ďalej mám príkaz, ktorý spustí server založený na Node.js na porte 5000. Vyzerá to takto:

npm i         # установка зависимостей
npm run build # сборка React-приложения
npm run start # запуск Node-сервера

Treba poznamenať, že pre tento materiál nemám príklad aplikácie. Ale tu, pre experimenty, bude stačiť akákoľvek jednoduchá aplikácia Node.

Ak chcete použiť kontajner, budete musieť dať Dockerovi pokyny. To sa vykonáva prostredníctvom súboru s názvom Dockerfile, ktorý sa nachádza v koreňovom adresári projektu. Tento súbor sa na prvý pohľad zdá dosť nezrozumiteľný.

Ale to, čo obsahuje, iba popisuje pomocou špeciálnych príkazov niečo podobné ako nastavenie pracovného prostredia. Tu sú niektoré z týchto príkazov:

• Z — Tento príkaz spustí súbor. Určuje základný obrázok, na ktorom je kontajner postavený.
• COPY — Kopírovanie súborov z lokálneho zdroja do kontajnera.
• WORKDIR — Nastavenie pracovného adresára pre nasledujúce príkazy.
• RUN - Spustenie príkazov.
• VYSTAVIŤ — Nastavenia portu.
• VSTUPNÝ BOD — Označenie príkazu, ktorý sa má vykonať.

Dockerfile môže vyzerať nejako 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 od zvoleného základného obrazu možno budete musieť nainštalovať ďalšie závislosti. Faktom je, že niektoré základné obrázky (ako Node Alpine Linux) sú vytvorené s cieľom urobiť ich čo najkompaktnejšie. V dôsledku toho nemusia mať niektoré z programov, ktoré očakávate.

▍ Zostavenie, označovanie a prevádzka kontajnera

Miestna montáž a spustenie kontajnera je po nás Dockerfile, úlohy sú celkom jednoduché. Pred odoslaním obrázka do Docker Hub ho musíte otestovať lokálne.

▍ Montáž

Najprv musíte zbierať obrazs uvedením názvu a prípadne značky (ak nie je zadaná značka, systém automaticky priradí značku k obrázku latest).

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

Po spustení tohto príkazu môžete sledovať, ako Docker vytvára obrázok.

Sending build context to Docker daemon   2.88MB
Step 1/9 : FROM node:12-alpine
 ---> ...выполнение этапов сборки...
Successfully built 123456789123
Successfully tagged <image>:<tag>

Zostavenie môže trvať niekoľko minút - všetko závisí od toho, koľko závislostí máte. Po dokončení zostavovania môžete príkaz spustiť docker images a pozrite sa na popis vášho nového obrázka.

REPOSITORY          TAG               IMAGE ID            CREATED              SIZE
<image>             latest            123456789123        About a minute ago   x.xxGB

▍ Spustite

Obrázok bol vytvorený. To znamená, že na jeho základe môžete spustiť kontajner. Pretože chcem mať prístup k aplikácii spustenej v kontajneri na adrese localhost:5000, ja, na ľavej strane páru 5000:5000 v nasledujúcom príkaze nainštalovaný 5000. Na pravej strane je kontajnerový prístav.

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

Teraz, keď je kontajner vytvorený a spustený, môžete použiť príkaz docker ps na zobrazenie informácií o tomto kontajneri (alebo môžete použiť príkaz docker ps -a, ktorý zobrazuje informácie o všetkých kontajneroch, nielen o spustených).

CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS                      PORTS                    NAMES
987654321234        <image>             "/bin/sh -c 'npm run…"   6 seconds ago        Up 6 seconds                0.0.0.0:5000->5000/tcp   stoic_darwin

Ak teraz prejdete na adresu localhost:5000 — môžete vidieť stránku spustenej aplikácie, ktorá vyzerá úplne rovnako ako stránka aplikácie spustenej v produkčnom prostredí.

▍Označovanie a publikovanie

Aby sme mohli použiť jeden z vytvorených obrázkov na produkčnom serveri, musíme mať možnosť stiahnuť si tento obrázok z Docker Hub. To znamená, že najprv musíte vytvoriť úložisko pre projekt na Docker Hub. Potom budeme mať miesto, kam môžeme poslať obrázok. Obrázok je potrebné premenovať tak, aby jeho názov začínal naším používateľským menom Docker Hub. Za ním by mal nasledovať názov úložiska. Na koniec mena je možné umiestniť akúkoľvek značku. Nižšie je uvedený príklad pomenovania obrázkov pomocou tejto schémy.

Teraz môžete vytvoriť obrázok s novým názvom a spustiť príkaz docker push aby ste ho poslali do úložiska Docker Hub.

docker build -t <username>/<repository>:<tag> .
docker tag <username>/<repository>:<tag> <username>/<repository>:latest
docker push <username>/<repository>:<tag>

# На практике это может выглядеть, например, так:
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

Ak všetko pôjde dobre, obrázok bude dostupný na Docker Hub a dá sa jednoducho nahrať na server alebo preniesť k iným vývojárom.

Ďalšie kroky

Teraz sme overili, že aplikácia vo forme kontajnera Docker beží lokálne. Nahrali sme kontajner do Docker Hub. To všetko znamená, že sme už dosiahli veľmi dobrý pokrok smerom k nášmu cieľu. Teraz musíme vyriešiť ďalšie dve otázky:

• Nastavenie nástroja CI na testovanie a nasadzovanie kódu.
• Nastavenie produkčného servera tak, aby si mohol stiahnuť a spustiť náš kód.

V našom prípade používame Travis C.I.. Ako server - DitigalOcean.

Treba poznamenať, že tu môžete využiť inú kombináciu služieb. Napríklad namiesto Travis CI môžete použiť CircleCI alebo Github Actions. A namiesto DigitalOcean - AWS alebo Linode.

Rozhodli sme sa spolupracovať s Travisom CI a v tejto službe už mám niečo nakonfigurované. Preto teraz stručne poviem, ako ho pripraviť na prácu.

Travis C.I.

Travis CI je nástroj na testovanie a nasadzovanie kódu. Nerád by som zachádzal do zložitosti nastavenia Travis CI, pretože každý projekt je jedinečný a neprinesie to veľa výhod. Ale preberiem vám základy, aby ste mohli začať, ak sa rozhodnete používať Travis CI. Či už si vyberiete Travis CI, CircleCI, Jenkins alebo niečo iné, podobné metódy konfigurácie sa budú používať všade.

Ak chcete začať s Travis CI, prejdite na webová stránka projektu a vytvorte si účet. Potom integrujte Travis CI so svojím účtom GitHub. Pri nastavovaní systému budete musieť špecifikovať úložisko, s ktorým chcete automatizovať prácu a povoliť k nemu prístup. (Používam GitHub, ale som si istý, že Travis CI sa dokáže integrovať s BitBucket a GitLab a inými podobnými službami).

Pri každom spustení Travis CI sa spustí server, ktorý vykoná príkazy špecifikované v konfiguračnom súbore, vrátane nasadenia príslušných vetiev úložiska.

▍ Životný cyklus práce

Nazvaný konfiguračný súbor Travis CI .travis.yml a uložené v koreňovom adresári projektu, podporuje koncepciu udalostí životný cyklus úlohy. Tieto udalosti sú uvedené v poradí, v akom sa vyskytujú:

• apt addons
• cache components
• before_install
• install
• before_script
• script
• before_cache
• after_success или after_failure
• before_deploy
• deploy
• after_deploy
• after_script

▍ Testovanie

V konfiguračnom súbore nakonfigurujem lokálny server Travis CI. Ako jazyk som vybral Node 12 a povedal som systému, aby nainštaloval závislosti potrebné na používanie Dockera.

Všetko, čo je uvedené v .travis.yml, sa vykoná, keď budú všetky požiadavky na stiahnutie odoslané do všetkých pobočiek úložiska, pokiaľ nie je uvedené inak. Toto je užitočná funkcia, pretože to znamená, že môžeme otestovať všetok kód prichádzajúci do úložiska. To vám dá vedieť, či je kód pripravený na zápis do pobočky. mastera či to naruší proces zostavovania projektu. V tejto globálnej konfigurácii nainštalujem všetko lokálne, spustím webový server pre vývojárov na pozadí (toto je funkcia môjho pracovného postupu) a spustím testy.

Ak chcete, aby sa na vašom úložisku zobrazovali ikony testovacieho pokrytia, tu Môžete nájsť krátke pokyny na používanie Jest, Travis CI a kombinézy na zhromažďovanie a zobrazovanie týchto informácií.

Takže tu je obsah súboru .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

Tu končia akcie, ktoré sa vykonávajú pre všetky vetvy úložiska a pre požiadavky na stiahnutie.

▍ Nasadenie

Na základe predpokladu, že všetky automatizované testy prebehli úspešne, môžeme, čo je voliteľné, nasadiť kód na produkčný server. Keďže to chceme urobiť len pre kód z pobočky master, dávame systému príslušné pokyny v nastaveniach nasadenia. Predtým, ako sa pokúsite použiť kód, na ktorý sa pozrieme ďalej vo vašom projekte, by som vás rád upozornil, že musíte mať skutočný skript, ktorý sa má nasadiť.

deploy:
  # Собрать Docker-контейнер и отправить его на Docker Hub
  provider: script
  script: bash deploy.sh
  on:
    branch: master

Skript nasadenia rieši dva problémy:

• Vytvorte, označte a odošlite obrázok do Docker Hub pomocou nástroja CI (v našom prípade Travis CI).
• Načítanie obrazu na server, zastavenie starého kontajnera a spustenie nového (v našom prípade server beží na platforme DigitalOcean).

Najprv musíte nastaviť automatický proces vytvárania, označovania a odosielania obrázka do Docker Hub. Toto všetko je veľmi podobné tomu, čo sme už robili manuálne, až na to, že potrebujeme stratégiu na priraďovanie jedinečných značiek k obrázkom a automatizáciu prihlasovania. Mal som problémy s niektorými detailmi skriptu nasadenia, ako je stratégia označovania, prihlásenie, kódovanie kľúča SSH, nadviazanie pripojenia SSH. Ale našťastie môj priateľ vie s bashom, ako s mnohými inými vecami, veľmi dobre. Pomohol mi napísať tento scenár.

Prvou časťou skriptu je teda nahranie obrázka do Docker Hub. Je to celkom jednoduché. Schéma označovania, ktorú som použil, zahŕňa kombináciu hash git a značky git, ak existuje. To zaisťuje, že štítok je jedinečný a uľahčuje identifikáciu zostavy, na ktorej je založený. DOCKER_USERNAME и DOCKER_PASSWORD sú premenné používateľského prostredia, ktoré je možné nastaviť pomocou rozhrania Travis CI. Travis CI automaticky spracuje citlivé údaje, aby sa nedostali do nesprávnych rúk.

Tu je prvá časť scenára 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}

Aká bude druhá časť skriptu, úplne závisí od toho, aký hostiteľ používate a ako je zorganizované pripojenie k nemu. V mojom prípade, keďže používam Digital Ocean, používam príkazy na pripojenie k serveru doctl. Pri práci s AWS sa použije utilita aws, a tak ďalej.

Nastavenie servera nebolo obzvlášť ťažké. Nastavil som teda kvapôčku na základe základného obrázka. Treba si uvedomiť, že mnou zvolený systém vyžaduje jednorazovú manuálnu inštaláciu Dockera a jednorazové manuálne spustenie Dockera. Na inštaláciu Dockera som použil Ubuntu 18.04, takže ak na to isté používate aj Ubuntu, môžete jednoducho sledovať tento jednoduchý návod.

Nehovorím tu o konkrétnych príkazoch pre službu, pretože tento aspekt sa môže v rôznych prípadoch značne líšiť. Uvediem len všeobecný plán činnosti, ktorý sa má vykonať po pripojení cez SSH k serveru, na ktorom bude projekt nasadený:

• Musíme nájsť kontajner, ktorý práve beží, a zastaviť ho.
• Potom musíte spustiť nový kontajner na pozadí.
• Budete musieť nastaviť lokálny port servera na 80 - to vám umožní vstúpiť na stránku s adresou ako example.com, bez zadania portu, namiesto použitia adresy ako example.com:5000.
• Nakoniec musíte odstrániť všetky staré kontajnery a obrázky.

Tu je pokračovanie scenára.

# Найти 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

Niektoré veci, ktorým treba venovať pozornosť

Je možné, že keď sa pripojíte k serveru cez SSH z Travis CI, uvidíte varovanie, ktoré vám zabráni pokračovať v inštalácii, pretože systém bude čakať na odpoveď používateľa.

The authenticity of host '<hostname> (<IP address>)' can't be established.
RSA key fingerprint is <key fingerprint>.
Are you sure you want to continue connecting (yes/no)?

Dozvedel som sa, že reťazcový kľúč je možné zakódovať v base64, aby som ho uložil vo forme, v ktorej sa s ním dá pohodlne a spoľahlivo pracovať. Vo fáze inštalácie môžete dekódovať verejný kľúč a zapísať ho do súboru known_hosts aby ste sa zbavili vyššie uvedenej chyby.

echo <public key> | base64 # выводит <публичный ключ, закодированный в base64>

V praxi môže tento príkaz vyzerať 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== [email protected]" | base64

A tu je to, čo produkuje - reťazec kódovaný base64:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Tu je príkaz uvedený vyššie

install:
  - echo < публичный ключ, закодированный в base64> | base64 -d >> $HOME/.ssh/known_hosts

Rovnaký prístup možno použiť so súkromným kľúčom pri vytváraní spojenia, pretože na prístup k serveru môžete potrebovať súkromný kľúč. Pri práci s kľúčom stačí zabezpečiť, aby bol bezpečne uložený v premennej prostredia Travis CI a aby sa nikde nezobrazoval.

Ďalšia vec, ktorú treba poznamenať, je, že možno budete musieť spustiť celý skript nasadenia ako jeden riadok, napríklad - s doctl. Môže to vyžadovať určité úsilie navyše.

doctl compute ssh <droplet> --ssh-command "все команды будут здесь && здесь"

TLS/SSL a vyrovnávanie záťaže

Keď som urobil všetko uvedené vyššie, posledným problémom, s ktorým som sa stretol, bolo, že server nemal SSL. Keďže používam server Node.js, aby som vynútil práce reverzný proxy Nginx a Let's Encrypt, musíte veľa makať.

Naozaj sa mi nechcelo robiť celú túto konfiguráciu SSL ručne, tak som len vytvoril load balancer a zaznamenal jeho detaily v DNS. V prípade DigitalOcean je napríklad vytvorenie samoobnovujúceho sa vlastnoručne podpísaného certifikátu na load balancer jednoduchým, bezplatným a rýchlym postupom. Tento prístup má ďalšiu výhodu v tom, že v prípade potreby veľmi uľahčuje nastavenie SSL na viacerých serveroch spustených za vyrovnávačom zaťaženia. To umožňuje samotným serverom „nepremýšľať“ o SSL, ale zároveň používať port ako zvyčajne 80. Takže nastavenie SSL na vyrovnávacom zaťažení je oveľa jednoduchšie a pohodlnejšie ako alternatívne spôsoby nastavenia SSL.

Teraz môžete zatvoriť všetky porty na serveri, ktoré prijímajú prichádzajúce pripojenia - okrem portu 80, ktorý sa používa na komunikáciu s vyrovnávačom zaťaženia a portom 22 pre SSH. Výsledkom je, že pokus o priamy prístup k serveru na iných portoch ako na týchto dvoch zlyhá.

Výsledky

Potom, čo som urobil všetko, o čom som hovoril v tomto materiáli, už ma platforma Docker ani koncepty automatizovaných reťazcov CI/CD nevystrašili. Podarilo sa mi nastaviť kontinuálny integračný reťazec, počas ktorého sa kód pred spustením do výroby testuje a kód sa automaticky nasadí na server. Toto všetko je pre mňa stále relatívne nové a som si istý, že existujú spôsoby, ako zlepšiť môj automatizovaný pracovný postup a zefektívniť ho. Takže ak máte nejaké nápady v tejto veci, dajte mi vedieť. ma vedieť. Dúfam, že vám tento článok pomohol vo vašom úsilí. Chcem veriť, že po prečítaní ste sa naučili toľko, čo som sa naučil ja, keď ste prišli na všetko, o čom som v ňom hovoril.

PS V našom trhovisko je tam obrázok prístavný robotník, ktorý je možné nainštalovať jedným kliknutím. Prevádzku kontajnerov si môžete skontrolovať na VPS. Všetci noví klienti majú 3 dni na testovanie zdarma.

Vážení čitatelia! Používate vo svojich projektoch CI/CD technológie?

Zdroj: hab.com