CI/CD lánc létrehozása és a munka automatizálása a Dockerrel

Az első weboldalaimat a 90-es évek végén írtam. Akkoriban nagyon könnyű volt üzembe helyezni őket. Valamelyik megosztott tárhelyen volt egy Apache szerver, erre a szerverre FTP-n keresztül lehetett bejelentkezni valami hasonló írással ftp://ftp.example.com. Ezután meg kellett adnia a nevét és jelszavát, és feltöltenie kellett a fájlokat a szerverre. Más idők voltak, akkor minden egyszerűbb volt, mint most.

Az azóta eltelt két évtized alatt minden sokat változott. A weboldalak összetettebbé váltak, a gyártás megkezdése előtt össze kell őket szerelni. Egyetlen szerverből sok terheléselosztó mögött futó szerver lett, és általánossá vált a verziókezelő rendszerek használata.

A személyes projektemhez egy speciális konfigurációm volt. És tudtam, hogy szükségem van a webhely éles üzembe helyezéséhez egyetlen művelet végrehajtásával: kód írásával egy fiókba. master a GitHubon. Ráadásul tudtam, hogy a kis webalkalmazásom működésének biztosítása érdekében nem szeretnék egy hatalmas Kubernetes-fürtöt kezelni, sem Docker Swarm technológiát használni, sem szerverparkot karbantartani podokkal, ügynökökkel és mindenféle mással. bonyolultságokat. A munka minél könnyebbé tétele érdekében meg kellett ismerkednem a CI/CD-vel.

Ha van egy kis projektje (jelen esetben egy Node.js projekt), és szeretné tudni, hogyan automatizálhatja ennek a projektnek a telepítését, miközben gondoskodik arról, hogy a tárolóban tárolt adatok pontosan megegyezzenek azzal, ami a termelésben működik, akkor én úgy gondolja, hogy érdekelheti ez a cikk.

Előfeltételek

A cikk olvasójának alapvető ismeretekkel kell rendelkeznie a parancssorról és a Bash-szkriptek írásáról. Ezenkívül szüksége lesz számlákra Travis C.I. и Docker hub.

célok

Nem mondom, hogy ezt a cikket feltétel nélkül „oktatóanyagnak” lehet nevezni. Ez inkább egy dokumentum, amelyben a tanultakról beszélek, és leírom a számomra megfelelő folyamatot a teszteléshez és a kód éles üzembe helyezéséhez, egy automata menetben végrehajtva.

Ez lett a munkafolyamatom.

Bármely lerakatágba feladott kódhoz, kivéve master, a következő műveleteket hajtják végre:

• A Travis CI-re épülő projekt elindul.
• Minden egység-, integrációs és végponttól végpontig terjedő tesztet végrehajtanak.

Csak a beleeső kódhoz master, a következőket hajtják végre:

• Minden, ami fent van, plusz...
• Docker-kép létrehozása az aktuális kód, beállítások és környezet alapján.
• A kép telepítése a Docker Hub-ra.
• Csatlakozás a termelési szerverhez.
• Kép feltöltése a Docker Hubról a szerverre.
• Az aktuális tároló leállítása és egy új indítása az új kép alapján.

Ha semmit sem tud a Dockerről, a képekről és a konténerekről, ne aggódjon. Elmesélek mindent.

Mi az a CI/CD?

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

▍Folyamatos integráció

A folyamatos integráció egy olyan folyamat, amelyben a fejlesztők kötelezettségeket vállalnak a projekt fő forráskód-tárára (általában egy ágra) master). Ugyanakkor a kód minőségét automatizált tesztelés biztosítja.

▍Folyamatos telepítés

A folyamatos üzembe helyezés a kód gyakori, automatizált üzembe helyezése a termelésben. A CI/CD mozaikszó második részét néha „folyamatos kézbesítés”-ként írják le. Ez alapvetően ugyanaz, mint a „folyamatos telepítés”, de a „folyamatos kézbesítés” azt jelenti, hogy a projekttelepítési folyamat megkezdése előtt manuálisan meg kell erősíteni a változtatásokat.

Az első lépések

Az alkalmazás, amellyel mindezt megtanultam, az úgynevezett Írd fel. Ez egy webprojekt, amin dolgozom, jegyzetelésre tervezték. Eleinte megpróbáltam csinálni JAMStack-projekt, vagy csak egy szerver nélküli front-end alkalmazás, hogy kihasználhassa az általa kínált szabványos hosting és projekttelepítési lehetőségeket netlify. Az alkalmazás összetettségének növekedésével meg kellett alkotnom a szerver részét, ami azt jelentette, hogy meg kellett fogalmaznom a saját stratégiámat az automatizált integrációhoz és a projekt automatizált telepítéséhez.

Az én esetemben az alkalmazás egy Node.js környezetben futó Express szerver, amely egyoldalas React alkalmazást szolgál ki, és támogatja a biztonságos szerveroldali API-t. Ez az architektúra a benne található stratégiát követi ezt Teljes verem hitelesítési útmutató.

-vel konzultáltam más, aki automatizálási szakértő, és megkérdezte tőle, mit kell tennem, hogy minden úgy működjön, ahogy szeretném. Ő adott nekem egy ötletet, hogyan nézzen ki egy automatizált munkafolyamat, amelyet a cikk Célok szakaszában vázol fel. E célok elérése azt jelentette, hogy ki kellett találnom, hogyan kell használni a Dockert.

Dokkmunkás

A Docker egy olyan eszköz, amely a konténerezési technológiának köszönhetően lehetővé teszi az alkalmazások egyszerű elosztását, üzembe helyezését és futtatását ugyanabban a környezetben, még akkor is, ha maga a Docker platform különböző környezetekben fut. Először is meg kellett ismernem a Docker parancssori eszközöket (CLI). utasítás A Docker telepítési útmutatója nem nevezhető túl világosnak és érthetőnek, de megtudhatja belőle, hogy az első telepítési lépés megtételéhez le kell töltenie a Docker Desktopot (Mac vagy Windows rendszerre).

A Docker Hub nagyjából ugyanaz, mint GitHub git tárolókhoz vagy rendszerleíró adatbázishoz NPM JavaScript-csomagokhoz. Ez a Docker képek online tárháza. Ehhez csatlakozik a Docker Desktop.

Tehát a Docker használatának megkezdéséhez két dolgot kell tennie:

• Készlet Docker Asztal.
• Regisztráljon a Docker hub.

Ezt követően a következő parancs futtatásával ellenőrizheti, hogy a Docker CLI működik-e a Docker verzió ellenőrzéséhez:

docker -v

Ezután jelentkezzen be a Docker Hubba a felhasználónév és a jelszó megadásával, amikor a rendszer megkérdezi:

docker login

A Docker használatához meg kell értenie a képek és tárolók fogalmát.

▍Képek

A kép olyan, mint egy tervrajz, amely utasításokat tartalmaz a tartály összeállításához. Ez az alkalmazás fájlrendszerének és beállításainak megváltoztathatatlan pillanatképe. A fejlesztők könnyedén megoszthatják a képeket.

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

Ez a parancs egy táblázatot ad ki a következő fejléccel:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

Ezután megnézünk néhány példát az azonos formátumú parancsokra – először van egy parancs megjegyzéssel, majd egy példa arra, hogy mit tud kiadni.

▍ Konténerek

A tároló egy végrehajtható csomag, amely mindent tartalmaz, ami egy alkalmazás futtatásához szükséges. Az ilyen megközelítést alkalmazó alkalmazások mindig ugyanúgy működnek, függetlenül az infrastruktúrától: elszigetelt környezetben és ugyanabban a környezetben. A lényeg az, hogy ugyanazon kép példányai különböző környezetekben indulnak el.

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

▍Címkék

A címke a kép egy adott verziójának jelzése.

▍Gyors áttekintés a Docker-parancsokhoz

Íme néhány gyakran használt Docker-parancs áttekintése.

Csapat

Kontextus

hatás

dokkoló épít

kép

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

dokkoló címke

kép

Képcímkézés

docker képek

kép

Képek listázása

docker fut

Konténer

Tároló futtatása kép alapján

dokkoló push

kép

Kép feltöltése a rendszerleíró adatbázisba

dokkoló húzza

kép

Kép betöltése a rendszerleíró adatbázisból

docker ps

Konténer

Konténerek listázása

docker rendszer aszalt szilva

Kép/tároló

A nem használt tárolók és képek eltávolítása

▍Dockerfile

Tudom, hogyan kell helyben futtatni egy éles alkalmazást. Van egy Webpack konfigurációm, amelyet egy kész React alkalmazás létrehozására terveztek. Ezután van egy parancsom, amely elindít egy Node.js alapú szervert a porton 5000. Ez így néz ki:

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

Megjegyzendő, hogy ehhez az anyaghoz nincs példaalkalmazásom. De itt a kísérletekhez bármely egyszerű Node alkalmazás megteszi.

A tároló használatához utasításokat kell adnia a Dockernek. Ez egy nevû fájlon keresztül történik Dockerfile, amely a projekt gyökérkönyvtárában található. Ez a fájl elsőre eléggé érthetetlennek tűnik.

De amit tartalmaz, az csak a munkakörnyezet beállításához hasonlót ír le speciális parancsokkal. Íme néhány ilyen parancs:

• FROM — Ez a parancs elindít egy fájlt. Meghatározza azt az alapképet, amelyre a tároló épül.
• COPY — Fájlok másolása helyi forrásból egy tárolóba.
• WORKDIR — A munkakönyvtár beállítása a következő parancsokhoz.
• FUTÁS - Parancsok futtatása.
• KIFEJEZNI — Portbeállítások.
• BELÉPÉSI PONT — A végrehajtandó parancs jelzése.

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 előfordulhat, hogy további függőségeket kell telepítenie. A helyzet az, hogy néhány alapkép (mint például a Node Alpine Linux) azzal a céllal jön létre, hogy azok a lehető legkompaktabbak legyenek. Ennek eredményeként előfordulhat, hogy nem rendelkeznek az Ön által várt programokkal.

▍A tároló felépítése, címkézése és üzemeltetése

A konténer helyi összeszerelése és elindítása utánunk van Dockerfile, a feladatok meglehetősen egyszerűek. Mielőtt átküldi a képet a Docker Hubnak, helyileg kell tesztelnie.

▍Összeszerelés

Először is gyűjteni kell kép, amely megad egy nevet és opcionálisan egy címkét (ha nincs megadva címke, a rendszer automatikusan címkét rendel a képhez latest).

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

A parancs futtatása után megnézheti, hogy a Docker felállítja a képet.

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

A felépítés eltarthat néhány percig – minden attól függ, hogy hány függőséggel rendelkezik. A felépítés befejezése után futtathatja a parancsot docker images és nézd meg az új képed leírását.

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

▍ Indítsa el

A kép elkészült. Ez azt jelenti, hogy ez alapján futtathat egy tárolót. Mert szeretném elérni a címen található tárolóban futó alkalmazást localhost:5000, én, a pár bal oldalán 5000:5000 a következő telepített parancsban 5000. A jobb oldalon található a konténernyílás.

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

Most, hogy a tároló létrejött és fut, használhatja a parancsot docker ps a tárolóra vonatkozó információk megtekintéséhez (vagy használhatja a parancsot docker ps -a, amely az összes tárolóról jelenít meg információkat, nem csak a futókat).

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

Ha most megy a címre localhost:5000 — egy futó alkalmazás oldalát láthatja, amely pontosan ugyanúgy néz ki, mint egy éles környezetben futó alkalmazás oldala.

▍Címkézés és közzététel

Ahhoz, hogy a létrehozott lemezképek egyikét az éles szerveren használhassuk, le kell tudnunk tölteni ezt a képet a Docker Hubról. Ez azt jelenti, hogy először létre kell hoznia egy tárat a projekthez a Docker Hubon. Ezek után lesz egy helyünk ahova elküldhetjük a képet. A képet át kell nevezni, hogy a neve a Docker Hub felhasználónevünkkel kezdődjön. Ezt követnie kell az adattár nevének. Bármely címke elhelyezhető a név végére. Az alábbiakban egy példa látható a képek elnevezésére ezzel a sémával.

Most létrehozhatja a képet új néven, és futtathatja a parancsot docker push hogy tolja be a Docker Hub tárolójába.

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

Ha minden jól megy, a kép elérhető lesz a Docker Hubon, és könnyen feltölthető a szerverre, vagy átvihető más fejlesztőknek.

Következő lépések

Mostanra ellenőriztük, hogy az alkalmazás egy Docker-tároló formájában helyileg fut. Feltöltöttük a tárolót a Docker Hub-ra. Mindez azt jelenti, hogy már nagyon jól haladtunk célunk felé. Most még két kérdést kell megválaszolnunk:

• CI-eszköz beállítása a kód teszteléséhez és telepítéséhez.
• Az éles kiszolgáló beállítása, hogy letölthesse és futtassa a kódunkat.

A mi esetünkben használjuk Travis C.I.. szerverként - DigigalOcean.

Meg kell jegyezni, hogy itt a szolgáltatások másik kombinációját is használhatja. Például a Travis CI helyett használhatja a CircleCI-t vagy a Github Actions-t. DigitalOcean helyett pedig AWS vagy Linode.

Úgy döntöttünk, hogy a Travis CI-vel dolgozunk, és ebben a szolgáltatásban már konfiguráltam valamit. Ezért most röviden beszélek arról, hogyan kell felkészíteni a munkára.

Travis C.I.

A Travis CI egy eszköz a kód tesztelésére és telepítésére. Nem szeretnék belemenni a Travis CI felállításának bonyodalmaiba, mivel minden projekt egyedi, és ez nem hoz sok hasznot. De leírom az alapokat, hogy elindulhasson, ha a Travis CI használata mellett dönt. Akár Travis CI-t, CircleCI-t, Jenkinst vagy valami mást választ, mindenhol hasonló konfigurációs módszereket fognak használni.

A Travis CI használatának megkezdéséhez látogasson el ide projekt honlapja és hozzon létre egy fiókot. Ezután integrálja a Travis CI-t GitHub-fiókjával. A rendszer beállításakor meg kell adnia azt a tárolót, amellyel automatizálni szeretné a munkát, és engedélyeznie kell a hozzáférést. (GitHubot használok, de biztos vagyok benne, hogy a Travis CI képes integrálni a BitBucket, a GitLab és más hasonló szolgáltatásokkal).

A Travis CI minden indításakor a szerver elindul, végrehajtva a konfigurációs fájlban megadott parancsokat, beleértve a megfelelő lerakatágak telepítését.

▍Munka életciklusa

Travis CI konfigurációs fájl hívva .travis.yml és a projekt gyökérkönyvtárában tárolva támogatja az események koncepcióját életciklus feladatokat. Ezek az események az előfordulásuk sorrendjében vannak felsorolva:

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

▍Tesztelés

A konfigurációs fájlban a helyi Travis CI szervert fogom konfigurálni. A 12-es csomópontot választottam nyelvként, és azt mondtam a rendszernek, hogy telepítse a Docker használatához szükséges függőségeket.

Minden ami benne van .travis.yml, akkor kerül végrehajtásra, amikor az összes lekérési kérelmet a lerakat összes ágához eljuttatják, hacsak másképp nincs megadva. Ez egy hasznos funkció, mert azt jelenti, hogy minden, a tárolóba érkező kódot tesztelhetünk. Ez jelzi, hogy a kód készen áll-e az ágba való írásra. master, és hogy ez megszakítja-e a projekt felépítési folyamatát. Ebben a globális konfigurációban mindent helyileg telepítek, a háttérben futtatom a Webpack dev szervert (ez a munkafolyamatom egyik jellemzője), és teszteket futtatok.

Ha azt szeretné, hogy az adattárban megjelenjenek a tesztlefedettséget jelző jelvények, itt Rövid utasításokat talál a Jest, a Travis CI és a Overalls használatáról ezen információk összegyűjtésére és megjelenítésére.

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 érnek véget a lerakat összes ága és a lekérési kérések esetében végrehajtott műveletek.

▍Bevezetés

Abból a feltételezésből kiindulva, hogy az összes automatizált teszt sikeresen lezajlott, a kódot a termelési szerverre telepíthetjük, ami nem kötelező. Mivel ezt csak az ágból származó kódhoz szeretnénk megtenni master, megfelelő utasításokat adunk a rendszernek a telepítési beállításoknál. Mielőtt megpróbálná használni a kódot, amelyet a következő lépésben megvizsgálunk a projektben, szeretném figyelmeztetni, hogy telepíteni kell egy tényleges szkriptet.

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

A telepítési szkript két problémát old meg:

• Készítse el, címkézze és küldje el a képet a Docker Hubnak egy CI-eszköz (esetünkben Travis CI) segítségével.
• A kép betöltése a szerverre, a régi konténer leállítása és egy új indítása (esetünkben a szerver a DigitalOcean platformon fut).

Először is be kell állítania egy automatikus folyamatot a kép felépítéséhez, címkézéséhez és a Docker Hub-ba küldéséhez. Ez mind nagyon hasonlít ahhoz, amit már kézzel csináltunk, kivéve, hogy stratégiára van szükségünk a képekhez egyedi címkék hozzárendeléséhez és a bejelentkezések automatizálásához. Nehézségeim voltak a telepítési szkript néhány részletével, mint például a címkézési stratégia, bejelentkezés, SSH-kulcskódolás, SSH-kapcsolat létrehozása. De szerencsére a barátom nagyon ért a bashhoz, mint sok máshoz is. Ő segített megírni ezt a forgatókönyvet.

Tehát a szkript első része a kép feltöltése a Docker Hub-ra. Ezt meglehetősen könnyű megtenni. Az általam használt címkézési séma egy git hash és egy git címke kombinálását foglalja magában, ha létezik ilyen. Ez biztosítja, hogy a címke egyedi legyen, és könnyebben azonosítható az összeállítás, amelyen alapul. DOCKER_USERNAME и DOCKER_PASSWORD olyan felhasználói környezeti változók, amelyek a Travis CI interfész segítségével állíthatók be. A Travis CI automatikusan feldolgozza az érzékeny adatokat, hogy azok ne kerüljenek rossz kezekbe.

Íme a forgatókönyv 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}

Hogy mi lesz a szkript második része, az teljes mértékben attól függ, hogy milyen gazdagépet használsz, és hogyan van megszervezve a kapcsolat. Az én esetemben, mivel Digital Ocean-t használok, a parancsokat használom a szerverhez való csatlakozáshoz doktl. Amikor az AWS-szel dolgozik, a segédprogram kerül felhasználásra aws, stb.

A szerver beállítása nem volt különösebben nehéz. Szóval, az alapkép alapján beállítottam egy cseppet. Meg kell jegyezni, hogy az általam választott rendszer a Docker egyszeri kézi telepítését és a Docker egyszeri kézi indítását igényli. A Docker telepítéséhez az Ubuntu 18.04-et használtam, tehát ha Ön is Ubuntut használ ugyanerre, csak kövesse ezt egyszerű útmutató.

Itt nem a szolgáltatás konkrét parancsairól beszélek, mivel ez a szempont a különböző esetekben nagyon eltérő lehet. Csak egy általános cselekvési tervet adok, amelyet az SSH-n keresztüli csatlakozás után kell végrehajtani ahhoz a szerverhez, amelyen a projektet telepíteni fogják:

• Meg kell találnunk az éppen futó tárolót, és le kell állítani.
• Ezután új tárolót kell indítania a háttérben.
• Be kell állítania a szerver helyi portját 80 - ez lehetővé teszi, hogy olyan címen lépjen be az oldalra, mint a example.com, a port megadása nélkül, ahelyett, hogy olyan címet használna, mint például example.com:5000.
• Végül törölnie kell az összes régi tárolót és képet.

Íme a forgatókönyv 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 figyelni kell

Lehetséges, hogy amikor SSH-n keresztül csatlakozik a kiszolgálóhoz a Travis CI-ről, egy figyelmeztetés jelenik meg, amely megakadályozza, hogy folytassa a telepítést, mivel a rendszer a felhasználó válaszára vár.

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)?

Megtanultam, hogy egy karakterlánc-kulcsot a base64-ben kódolhatunk, hogy olyan formában mentsük el, amelyben kényelmesen és megbízhatóan lehet vele dolgozni. A telepítési szakaszban dekódolhatja a nyilvános kulcsot, és fájlba írhatja known_hosts a fenti hiba kiküszöbölése érdekében.

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

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== [email protected]" | base64

És itt van, amit előállít – egy base64 kódolású karakterláncot:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Itt van a fent említett parancs

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

Ugyanez a megközelítés használható a privát kulccsal kapcsolat létesítésekor, mivel a szerver eléréséhez szükség lehet egy privát kulcsra. Amikor a kulccsal dolgozik, csak arról kell gondoskodnia, hogy azt biztonságosan tárolja egy Travis CI környezeti változóban, és ne jelenjen meg sehol.

Egy másik dolog, amit meg kell jegyezni, hogy előfordulhat, hogy a teljes telepítési parancsfájlt egy sorként kell futtatnia, például - with doctl. Ez további erőfeszítést igényelhet.

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

TLS/SSL és terheléselosztás

Miután mindent megtettem, amit fent említettem, az utolsó probléma, amivel találkoztam, az volt, hogy a szerveren nem volt SSL. Mivel én egy Node.js szervert használok, az erőltetés érdekében dolgozni fordított proxy Nginx és Let's Encrypt, sokat kell bütykölni.

Valójában nem akartam mindezt az SSL-konfigurációt manuálisan elvégezni, ezért csak létrehoztam egy terheléselosztót, és rögzítettem a részleteket a DNS-ben. A DigitalOcean esetében például egy automatikusan megújuló önaláírt tanúsítvány létrehozása a terheléselosztón egyszerű, ingyenes és gyors eljárás. Ennek a megközelítésnek az a további előnye, hogy nagyon egyszerűvé teszi az SSL beállítását több terheléselosztó mögött futó szerveren, ha szükséges. Ez lehetővé teszi, hogy maguk a szerverek egyáltalán ne „gondoljanak” az SSL-re, ugyanakkor a szokásos módon használják a portot 80. Tehát az SSL beállítása a terheléselosztón sokkal egyszerűbb és kényelmesebb, mint az SSL beállításának alternatív módszerei.

Most bezárhatja a kiszolgáló összes portját, amely fogadja a bejövő kapcsolatokat – a port kivételével 80, amely a terheléselosztóval és a porttal való kommunikációra szolgál 22 az SSH számára. Ennek eredményeként a kiszolgáló közvetlen elérése e kettőtől eltérő portokon meghiúsul.

Eredményei

Miután mindent megtettem, amiről ebben az anyagban beszéltem, sem a Docker platform, sem az automatizált CI/CD láncok koncepciója nem ijesztett többé. Sikerült felállítani egy folyamatos integrációs láncot, melynek során a kód tesztelésre kerül, mielőtt gyártásba kerül, és a kód automatikusan telepítésre kerül a szerveren. Mindez még viszonylag új számomra, és biztos vagyok benne, hogy vannak módok az automatizált munkafolyamat javítására és hatékonyabbá tételére. Szóval, ha bármilyen ötlete van ezzel a témával kapcsolatban, kérem, jelezze. nekem tud. Remélem, hogy ez a cikk segített a törekvéseiben. Azt akarom hinni, hogy miután elolvastad, annyit tanultál, mint én, miközben kitaláltam mindazt, amiről beszéltem benne.

PS A miénkben piactér van egy kép Dokkmunkás, amely egy kattintással telepíthető. A konténerek működését a címen ellenőrizheti VPS. Minden új ügyfél 3 napos ingyenes tesztelést kap.

Kedves olvasók! Használ CI/CD technológiákat a projektjei során?

Forrás: will.com