🥇A CI/CD lánc létrehozása és a Docker automatizálása

Az első weboldalaimat a 90-es évek végén írtam. Akkoriban nagyon egyszerű volt őket működésbe hozni. Volt egy Apache szerver valamilyen megosztott hosztingon, ahová FTP-n keresztül be lehetett lépni, ha beírtál a böngésző címsorába valami ilyesmit ftp://ftp.example.com. Aztán be kellett írni a felhasználónevet és a jelszót, majd feltölteni a fájlokat a szerverre. Más idők voltak, akkor minden sokkal egyszerűbb volt, mint most.

Azóta, a két évtized alatt, sok minden megváltozott. A weboldalak bonyolultabbá váltak, a kiadás előtt össze kell őket állítani. Egyetlen szerverből sok szerver lett, amelyek terheléselosztók mögött működnek, és a verziókezelő rendszerek használata mindennapossá vált.

A személyes projektemhez különleges konfigurációra volt szükségem. Tudtam, hogy szükségem van arra a lehetőségre, hogy a weboldalt a termelési környezetben egyetlen lépéssel telepítsem: a kódot a master GitHub ágba kell írnom. Emellett tudtam, hogy a kis webalkalmazásom működésének biztosításához nem szeretnék óriási Kubernetes klaszter kezeléssel foglalkozni, vagy Docker Swarm technológiát használni, vagy egy szerverparkot fenntartani podokkal, ügynökökkel és mindenféle egyéb bonyodalommal. A munkám maximális egyszerűsítése érdekében meg kellett ismerkednem a CI/CD-vel.

Ha van egy kis projekted (ebben az esetben egy Node.js projektről beszélünk) és szeretnéd megtudni, hogyan automatizáld ennek a projektnek a telepítését úgy, hogy a tárolóban tárolt fájlok pontosan megegyezzenek azzal, ami a termelésben fut, akkor azt hiszem, érdekelhet ez a cikk.

Előfeltételek

A cikk olvasójától elvárt alapvető ismeretek a parancssor használatában és Bash szkriptek írásában. Ezen kívül szüksége lesz fiókokra Travis CI és Docker Hub.

Célok

Nem mondanám, hogy ezt a cikket mindenféle kétség nélkül "útmutatónak" lehet nevezni. Inkább egy dokumentum, amelyben elmesélem, amit megtudtam, és leírom a számomra megfelelő tesztelési és kódtelepítési folyamatot, amelyet egy automatizált lépésben hajtanak végre.

Íme, milyen lett végül a munkafolyamatom.

Bármilyen ágba feltöltött kód esetén, kivéve a master, a következő műveletek történnek:

A projekt építése a Travis CI-n indul.
Minden moduláris, integrációs és end-to-end teszt fut.

Csak a kód esetében, amely a masteralá tartozik, a következő történik:

Mindez, amit fentebb említettünk, plusz…
Docker kép építése a jelenlegi kód, beállítások és környezet alapján.
A kép elhelyezése a Docker Hub-on.
Kapcsolódás a produkciós szerverhez.
Kép letöltése a Docker Hub-ról a szerverre.
A jelenlegi konténer leállítása és új indítása, amely új képen alapul.

Ha teljesen ismeretlen vagy a Dockerrel, képekkel és konténerekkel kapcsolatban – ne aggódj. Mindezt elmondom neked.

Mi az a CI/CD?

A CI/CD rövidítés jelentése: „folyamatos integráció/folyamatos telepítés”.

▍Folyamatos integráció

A folyamatos integráció egy olyan folyamat, amely során a fejlesztők elkötelezik a projekt fő forráskód tárolójába (általában a master) a kód minősége automatizált tesztelés révén biztosított.

▍Folyamatos telepítés

A folyamatos telepítés a kód gyakori automatizált telepítése a produkcióban. A CI/CD rövidítés második része néha „folyamatos kiszállítást” (continuous delivery) is jelent. Ez lényegében ugyanaz, mint a „folyamatos telepítés”, de a „folyamatos kiszállítás” szükségessé teszi a változások manuális megerősítését a projekt telepítési folyamatának elindítása előtt.

Munka kezdetek

Az alkalmazás, amellyel mindezt elsajátítottam, a következő neve: TakeNote. Ez egy webes projekt, amelyen dolgozom, és amely a jegyzeteléshez készült. Először próbáltam létrehozni egy JAMStack-projektet, vagy csak frontend alkalmazást kiszolgáló nélkül, hogy kihasználhassam a Netlify-tól elérhető standard lehetőségeket a projektek hosztolására és telepítésére. Ahogy az alkalmazás bonyolultsága növekedett, szükségessé vált a szerveroldali rész létrehozása, ami azt jelentette, hogy saját stratégiát kellett kialakítanom az automatizált integrációra és telepítésre.

Az én esetemben az alkalmazás egy Express szerver, amely a Node.js környezetében működik, és egy egylapos React alkalmazást szolgál ki, valamint támogat egy biztonságos szerveroldali API-t. Ez az architektúra egy stratégiát követ, amely a következő helyen található: ebben a teljes körű hitelesítésről szóló útmutatóban.

Consultáltam egy barátommal, aki automatizálási szakértő, és megkérdeztem tőle, hogy mit kell tenni ahhoz, hogy minden úgy működjön, ahogy szeretném. Ő adott nekem egy ötletet arról, hogyan kell kinéznie az automatizált munkafolyamatnak, amelyet a cikk "Célok" szakaszában vázoltam. Az, hogy ilyen célokat tűztem ki magam elé, azt jelentette, hogy meg kell tanulnom, hogyan használhatom a Dockert.

Docker

A Docker egy eszköz, amely a konténerizációs technológia révén lehetővé teszi az alkalmazások egyszerű terjesztését, valamint azok telepítését és futtatását ugyanabban a környezetben, még akkor is, ha magának a Docker platformnak a működése különböző környezetekben zajlik. Először tehát szükségem volt a Docker parancssori eszközeire (CLI). A Docker telepítési utasítást nem lehet nagyon világosnak és érthetőnek nevezni, de megtudható belőle, hogy az első telepítési lépéshez le kell tölteni a Docker Desktopot (Macra vagy Windowsra).

A Docker Hub nagyjából ugyanolyan, mint GitHub a git-tárolók, vagy nyilvántartás npm JavaScript-csomagokhoz. Ez egy online tároló a Docker képek számára. Ehhez csatlakozik a Docker Desktop.

Tehát, hogy elkezdhesd a munkát a Dockerrel, két dolgot kell tenned:

Telepítse Docker Desktop.
Regisztrálj a Docker Hub.

Ezután ellenőrizheted a Docker CLI működését a következő parancs végrehajtásával a Docker verzió ellenőrzésére:

docker -v

Következő lépésként jelentkezz be a Docker Hubba, amikor megkérdezik, add meg a felhasználónevét és a jelszavát:

docker login

A Docker használatához meg kell értened a képek és konténerek koncepcióját.

▍Képek

A kép egyfajta terv, amely tartalmazza a konténer összeszereléséhez szükséges utasításokat. Ez egy változhatatlan pillanatkép a fájlrendszerről és az alkalmazás beállításairól. A fejlesztők könnyedén cserélhetnek képeket.

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

Ez a parancs egy táblázatot fog megjeleníteni a következő fejlécsel:

TÁROLÓ     TAG     KÉP AZONOSÍTÓ     LÉTREHOZVA     MÉRET
---

Később néhány parancs példát fogunk megvizsgálni hasonló formátumban - először jön a parancs egy megjegyzéssel, aztán egy példa arra, hogy mit hozhat létre.

▍Konténerek

A konténer egy végrehajtható csomag, amely mindent tartalmaz, amire az alkalmazás futtatásához szükség van. E megközelítés esetén az alkalmazás mindig azonos módon működik, függetlenül az infrastruktúrától: izolált környezetben és ugyanabban a környezetben. Arról van szó, hogy ugyanazon kép példányai indulnak el különböző környezetekben.

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

▍Címkék

A címke a kép egy adott verziójára való hivatkozás.

▍Rövid útmutató a Docker parancsokhoz

Itt egy áttekintés néhány gyakran használt Docker parancsról.

A parancs

Környezet

Művelet

docker build

Kép

Kép építése Dockerfile-ból

docker tag

Kép

Kép címkézése

docker images

Kép

Képek listájának megjelenítése

docker run

Konténer

Konténer indítása a kép alapján

docker push

Kép

Kép küldése a tárolóba

docker pull

Kép

Kép letöltése a tárolóból

docker ps

Konténer

Konténerek listájának megjelenítése

docker system prune

Kép/Konténer

Nem használt konténerek és képek eltávolítása

▍Dockerfile

Tudom, hogyan indítsam el helyben az alkalmazást élesben. Van egy Webpack-konfigurációm, amely a kész React-alkalmazás építésére szolgál. Ezen kívül van egy parancsom, amely egy Node.js alapú szervert indít el a 5000porton. Így néz ki:

npm i         # függőségek telepítése
npm run build # React-alkalmazás építése
npm run start # Node-szerver indítása

Meg kell jegyezni, hogy nincs példaprogramom ehhez az anyaghoz. De itt, kísérletezéshez, bármilyen egyszerű Node-alkalmazás megfelel.

Ahhoz, hogy a konténert használhassa, utasításokat kell adnia a Dockernak. Ez a Dockerfile, a projekt gyökérkönyvtárában található fájl segítségével történik. Ez a fájl eleinte elég érthetetlennek tűnik.

De amit tartalmaz, az csupán különféle parancsokkal leírja, hogy mi hasonlít a munkakörnyezet beállítására. Íme néhány ilyen parancs:

FROM — Ez a parancs indítja el a fájlt. Itt van megadva az alap kép, amely alapján a konténer épül.
COPY — Fájlok másolása a helyi forrásból a konténerbe.
WORKDIR — Munkakönyvtár beállítása a következő parancsokhoz.
RUN — Parancsok futtatása.
EXPOSE — Port beállítása.
ENTRYPOINT — A végrehajtandó parancs megadása.

Dockerfile valahogy így nézhet ki:

# Загрузить базовый образ
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

A választott alapképtől függően lehet, hogy további függőségeket kell telepítenie. Az a helyzet, hogy egyes alapképek (például a Node Alpine Linux) úgy készültek, hogy a lehető legkompaktabbak legyenek. Ennek eredményeként hiányozhatnak belőlük bizonyos programok, amelyekre számít.

▍A konténer összeállítása, címkézése és indítása

A konténer helyi összeállítása és indítása — ez azután történik, hogy van egy Dockerfile, a feladatok meglehetősen egyszerűek. Mielőtt az elkészült képet feltöltené a Docker Hub-ra, helyben le kell tesztelni.

▍Összeállítás

Először is össze kell állítani a image, megadva a nevét, és opcionálisan a címkét (ha nem ad meg címkét, a rendszer automatikusan hozzárendel egyet a képhez latest).

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

E parancs végrehajtása után figyelemmel kísérheti, ahogyan a Docker összeállítja a képet.

A build környezet elküldése a Docker démonnak   2.88MB
1/9 lépés: NODE-ból:12-alpine
 ---> ...építési lépések végrehajtása...
Sikeresen létrehozva 123456789123
Sikeresen címkézve <kép>:<címke>

Az összeállítás néhány percet igénybe vehet — minden a rendelkezésre álló függőségektől függ. Az összeállítás befejezése után kiadhatja a parancsot docker images és megtekintheti az új képének leírását.

TÁRHELY          TAG            KÉPID            LÉTREHOZVA          MÉRET
<kép>             legfrissebb       123456789123        Körülbelül egy perce    x.xxGB

▍Indítás

A kép létrejött. Ez azt jelenti, hogy konténert indíthatunk rajta. Mivel szeretném, hogy hozzáférhessek a konténerben futó alkalmazáshoz a címről localhost:5000, a parancs bal oldalán beállítottam a 5000:5000 . A jobb oldalon a konténer portja található. 5000Most, hogy a konténer létrejött és elindult, kiadhatja a parancsot

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

hogy megtekintse az adott konténer adatait (vagy használhatja a parancsot docker ps docker ps -a , amely az összes konténer adatait megjeleníti, nemcsak az aktívakat).KONTÉNER AZONOSÍTÓ KÉP PARANCS LÉTREHOZVA ÁLLAPOT PORTOK NÉV

987654321234        <kép>          "/bin/sh -c 'npm run…"   6 másodperce       Fel 6 másodperce         0.0.0.0:5000->5000/tcp   stoic_darwin

Most, ha az alábbi címre navigálunk localhost:5000 — láthatjuk a futó alkalmazás oldalát, amely pontosan úgy néz ki, mint a produktív környezetben futó alkalmazás oldala.

▍Címke hozzárendelése és közzététel

Ahhoz, hogy a létrehozott képeket használni tudjuk a produkciós szerveren, biztosítanunk kell, hogy lehetőségünk legyen ezt a képet feltölteni a Docker Hub-ra. Ez azt jelenti, hogy először egy repót kell létrehoznunk a Docker Hub-on a projekthez. Ezt követően rendelkezésünkre áll egy hely, ahová el lehet küldeni a képet. A képet úgy kell elnevezni, hogy a neve a Docker Hub-on a felhasználónevünkkel kezdődjön. Ezt követi a repó neve. A név végén bármilyen címke elhelyezhető. Az alábbiakban egy példa látható a képek elnevezésére ezen a séma alapján.

Most összerakhatjuk a képet, új nevet adva neki, és végrehajthatjuk a parancsot docker push a Docker Hub repóba való feltöltéshez.

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

# A gyakorlatban ez így nézhet ki például:
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

Ha minden rendben zajlik, a kép elérhető lesz a Docker Hub-on, és könnyen letölthetjük a szerverre, vagy átadhatjuk más fejlesztőknek.

Következő lépések

Eddig megbizonyosodtunk arról, hogy a Docker konténerben lévő alkalmazás helyben működik. Feltöltöttük a konténert a Docker Hub-ra. Ez azt jelenti, hogy már elég jól haladtunk a cél felé. Most még két kérdést kell megoldanunk:

A CI-eszköz beállítása a kód tesztelésére és telepítésére.
A produkciós szerver beállítása úgy, hogy képes legyen letölteni és futtatni a kódunkat.

Az esetünkben a CI/CD megoldásként a Travis CIhasználatos. A szerver pedig a DigitalOcean..

Fontos megjegyezni, hogy itt más szolgáltatások kombinációját is igénybe lehet venni. Például a Travis CI helyett használható a CircleCI vagy a Github Actions. A DigitalOcean helyett pedig az AWS vagy a Linode.

Döntöttünk a Travis CI mellett, és ebben a szolgáltatásban már van néhány beállításom. Ezért most röviden elmondom, hogyan készítsük elő a működéshez.

Travis CI

A Travis CI — egy eszköz a kód tesztelésére és telepítésére. Nem szeretnék a Travis CI beállításának részleteibe belemenni, mivel minden projekt egyedi, és ez nem hozna sok hasznot. De elmondom az alapokat, amelyek lehetővé teszik, hogy elkezdje a munkát, ha úgy dönt, hogy használja a Travis CI-t. Akár a Travis CI-t, a CircleCI-t, a Jenkinst vagy valami mást választ, hasonló beállítási módszerek fognak érvényesülni.

Ahhoz, hogy elkezdhesse a Travis CI használatát, látogasson el a projekt weboldalára és hozzon létre egy fiókot. Ezután integrálja a Travis CI-t a GitHub-fiókjával. A rendszer beállítása során meg kell adnia a repót, amellyel automatizálni kívánja a munkát, és engedélyeznie kell hozzáférést ehhez. (Én a GitHub-ot használom, de biztos vagyok benne, hogy a Travis CI integrálható a BitBucket-tel, a GitLab-bal és más hasonló szolgáltatásokkal is.)

Minden alkalommal, amikor a Travis CI munkához lát, egy szerver indul el, amely végrehajtja a konfigurációs fájlban megadott parancsokat, beleértve a megfelelő repozitórium ágak telepítését.

▍A feladat életciklusa

A Travis CI konfigurációs fájlja, amelyet .travis.yml -nak hívnak, és a projekt gyökérkönyvtárában található, az események fogalmát támogatja, amelyek a feladat életciklusa alatt történnek. Íme ezek az események, az előfordulásuk sorrendjében: apt addons

cache components
before_install
before_script
install
before_cache
script
after_success vagy after_failure
before_deploy
deploy
after_deploy
after_script
▍Tesztelés

A konfigurációs fájlban egy helyi Travis CI szervert fogok beállítani. A nyelvnek a Node 12 verzióját választottam, és megadtam a rendszernek, hogy telepítse a Docker használatához szükséges függőségeket.

Minden, ami a

-ban van, végrehajtódik minden pull request során az összes repozitórium ágra, hacsak másként nem rendelkeznek. Ez egy hasznos funkció, mivel azt jelenti, hogy tesztelhetjük az összes kódot, ami a repozitóriumba érkezik. Ez lehetővé teszi, hogy tudjuk, készen áll-e a kód az ágba írásra, .travis.yml-ben, és hogy nem fogja-e megszakítani a projekt összeállítási folyamatát. Ebben a globális konfigurációban minden beállítok helyben, elindítom a Webpack fejlesztői szervert a háttérben (ez a munkafolyamatom sajátossága), és futtatom a teszteket. masterHa szeretné, hogy a repozitóriumában megjelenjenek a tesztlefedettséggel kapcsolatos jelvények,

Ha azt szeretné, hogy a tárolójában tesztelési kódlefedettségi információkat megjelenítő ikonok jelenjenek meg, itt A Jest, Travis CI és Coveralls használatáról egy rövid útmutatót találhat.

Tehát itt van a fájl tartalma .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

Itt végződnek azok a lépések, amelyeket minden ágon és pull kérésen végrehajtunk.

▍Telepítés

Feltételezve, hogy minden automatizált teszt sikeresen befejeződött, lehetőség szerint telepíthetjük a kódot a produkciós szerverre. Mivel ezt csak az ágból származó kódra szeretnénk végrehajtani, master, megadjuk a megfelelő utasításokat a telepítési beállításokban. Mielőtt megpróbálná használni a projektjéhez a következő kódrészt, szeretnék figyelmeztetni arra, hogy valós telepítési szkriptre van szüksége.

deploy:
  # Docker konténer összeállítása és küldés a Docker Hub-ra
  provider: script
  script: bash deploy.sh
  on:
    branch: master

A telepítési szkript két feladatot lát el:

A kép összeállítása, címkézése és a Docker Hub-ra való küldése CI eszközök, esetünkben a Travis CI segítségével.
A kép betöltése a szerverre, a régi konténer leállítása és az új indítása (esetünkben a szerver a DigitalOcean platformon működik).

Először is be kell állítani az automatikus folyamatot a kép összeállításához, címkézéséhez és Docker Hub-ra való küldéséhez. Mindez nagyon hasonló ahhoz, amit már manuálisan csináltunk, kivéve, hogy itt szükség van egy stratégiára a képek egyedi címkéinek hozzárendelésére és a bejelentkezés automatizálására. Volt néhány nehézségem a telepítési szkript egyes részleteivel, mint például a címkézési stratégia, a bejelentkezés, az SSH kulcsok kódolása és az SSH kapcsolat létrehozása. De szerencsére a barátom nagyon jól érti a bash-t, mint sok más dologhoz is. Segített nekem megírni ezt a szkriptet.

Tehát a szkript első része a kép Docker Hub-ra küldése. Ezt viszonylag egyszerűen meg lehet valósítani. Az általam használt címkézési séma a git hash és a git címke kombinálását feltételezi, ha létezik. Ez biztosítja az egyedi címke létrehozását és megkönnyíti a kapcsolódó építés azonosítását. DOCKER_USERNAME és DOCKER_PASSWORD — ezek környezeti változók, amelyeket a Travis CI felületén be lehet állítani. A Travis CI automatikusan kezeli a titkos adatokat, biztosítva, hogy ne kerülhessenek illetéktelen kezekbe.

Ez tehát a szkript első része 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}

A második rész script teljesen attól függ, hogy milyen hosztot használ, és hogyan van megszervezve a hozzáférés. Az én esetemben, mivel a Digital Ocean-t használom, a szerverhez a következő parancsokat használjuk doctl. Az AWS-nal az awseszközt fogjuk használni, és így tovább.

A szerver beállítása nem volt különösebben nehéz. Beállítottam egy dropletet, amely egy alapképre épül. Meg kell jegyeznem, hogy az általam választott rendszer egyszeri kézi Docker telepítést és egyszeri kézi Docker elindítást igényel. A Docker telepítéséhez az Ubuntu 18.04-et használtam, így ha ön is Ubuntu-t használ, ugyanazt könnyen megteheti, csak kövesse ezért az egyszerű útmutatót.

Nem fogok konkrét parancsokról beszélni a szolgáltatáshoz, mivel ez a szempont különböző esetekben jelentősen eltérhet. Csak egy általános lépés tervet fogok bemutatni, amelyet SSH kapcsolaton keresztül kell végrehajtani a szerveren, ahol a projektet telepíteni fogják:

Meg kell találni a jelenleg futó tárolót, és le kell állítani.
Ezután a háttérben új tárolót kell indítani.
Be kell állítania a szerver helyi portját a következő értékre 80 — ez lehetővé teszi, hogy a weboldalt az alábbi módon érje el: example.com, port megadása nélkül, nem pedig olyan címként, mint example.com:5000.
Végül el kell távolítania az összes régi tárolót és képet.

Ez a script folytatása.

# Найти 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éhány dolog, amire érdemes figyelni

Lehetséges, hogy amikor SSH-n keresztül csatlakozik a szerverhez a Travis CI-ből, figyelmeztetést fog látni, amely megakadályozza a telepítést, mert a rendszer a felhasználói interakcióra vár.

A host '<hostname> (<IP address>)' hitelessége nem állapítható meg.
Az RSA kulcs ujjlenyomata: <key fingerprint>.
Biztos benne, hogy folytatni akarja a kapcsolódást (igen/nem)?

Felfedeztem, hogy a kulcsot base64 formátumra is kódolhatjuk, hogy olyan formában tárolhassuk, amellyel kényelmesen és biztonságosan dolgozhatunk. A telepítési szakaszban a nyilvános kulcsot dekódolni lehet és egy fájlba rögzíteni known_hosts hogy megszabaduljon a fent említett hibától.

echo <public key> | base64 # kiírja <public key, base64 formátumban>

A gyakorlatban ez a parancs így nézhet ki:

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

Íme, hogyan néz ki az, amit generál — egy base64 kódolású sor:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Itt van a korábban említett parancs:

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

Ugyanezt a megközelítést a privát kulccsal is alkalmazhatjuk a kapcsolat létrehozásakor, mivel a szerverhez való hozzáféréshez szüksége lehet a privát kulcsra. A kulcs használata során csak annyit kell biztosítania, hogy biztonságosan tárold a Travis CI környezeti változójában, és hogy sehol ne legyen kiírva.

Egy másik dolog, amire figyelni érdemes, hogy lehet, hogy az egész deploy scriptet egyetlen sorban kell futtatni, például — a következő használatával: doctlEz némi extra erőfeszítést igényelhet.

doctl compute ssh  --ssh-command "minden parancs itt lesz && itt"

TLS/SSL és terheléselosztás

Miután mindent megtettem, amiről eddig beszéltem, az utolsó probléma, amivel szembesültem, az volt, hogy a szervernek nem volt SSL-je. Mivel Node.js szervert használok, hogy működjön a fordított proxy Nginx és a Let’s Encrypt, elég sokat kell barkácsolni. Nginx fordított proxy és a Let’s Encrypt, sokat kell vacakolni.

Nem akartam manuálisan beállítani az SSL-t, ezért egyszerűen létrehoztam egy terheléselosztót, és feljegyeztem az adatokat a DNS-ben. Például a DigitalOcean esetében egy automatikusan frissülő önaláírt tanúsítvány létrehozása a terheléselosztón egyszerű, ingyenes és gyors folyamat. Ennek az eljárásnak van egy további előnye is, hogy ha szükséges, nagyon egyszerűen beállítható az SSL több, a terheléselosztó mögött futó szerveren. Ez lehetővé teszi, hogy maguk a szerverek egyáltalán ne „törődjenek” az SSL-lel, de a portot a megszokott módon használják. 80Így az SSL beállítása a terheléselosztón sokkal egyszerűbb és kényelmesebb, mint az alternatív SSL-beállítási módszerek.

Most minden olyan portot bezárhatunk a szerveren, amely bejövő kapcsolatokra fogad — kivéve a portot, 80, amelyet a terheléselosztóval való kapcsolatra használunk, és a 22 SSH számára fenntartott portot. Ennek eredményeként a szerver közvetlen elérésére tett kísérletek ezen két port kivételével minden esetben meghiúsulnak.

Összegzés

Miután elvégeztem mindazt, amiről ebben a cikkben beszéltem, már nem ijedtem meg sem a Docker platformtól, sem az automatizált CI/CD láncok koncepciójától. Be tudtam állítani egy folyamatos integrációs láncot, amely során a kód tesztelése történik, mielőtt élesbe kerül, és automatikus kódtelepítés történik a szerveren. Mindez még viszonylag új számomra, és biztos vagyok benne, hogy léteznek módok az automatizált munkafolyamatom javítására és hatékonyabbá tételére. Ezért ha van javaslatod ez ügyben, kérlek, tudasd velem. Remélem, hogy ez a cikk segített nektek a dolgaikban. Szeretném hinni, hogy miután elolvastátok, annyit tanultatok, mint én, miközben minden olyan dologgal foglalkoztam, amiről beszéltem benne. A mi

P.S. rendszerünkben van egy marketplace-ünkben , amely egy kattintással telepíthető. Ellenőrizheti a konténerek működését a Docker. Minden új ügyfél számára ingyenesen biztosítunk 3 napos tesztelési lehetőséget. VPSTisztelt olvasóink!

Használjátok a CI/CD technológiákat a projektjeitekben? RabbitMQ. 1. rész. Bevezetés. Erlang, AMQP

Forrás: habr.com