CI/CD ahela loomine ja töö automatiseerimine Dockeriga

Kirjutasin oma esimesed veebisaidid 90ndate lõpus. Siis oli neid väga lihtne töökorda viia. Mõnes jagatud hostimises oli Apache server, sellesse serverisse sai FTP kaudu sisse logida, kirjutades midagi sellist ftp://ftp.example.com. Seejärel tuli sisestada oma nimi ja parool ning failid serverisse üles laadida. Olid teised ajad, siis oli kõik lihtsam kui praegu.

Sellest ajast möödunud kahe aastakümne jooksul on kõik palju muutunud. Veebisaidid on muutunud keerukamaks, need tuleb enne tootmisse lubamist kokku panna. Ühest serverist sai palju koormuse tasakaalustajate taga töötavaid servereid ja versioonikontrollisüsteemide kasutamine muutus tavapäraseks.

Isikliku projekti jaoks oli mul spetsiaalne konfiguratsioon. Ja ma teadsin, et vajan võimalust juurutada sait tootmises, tehes vaid ühe toimingu: kirjutades harule koodi master GitHubis. Lisaks teadsin, et oma väikese veebirakenduse töö tagamiseks ei soovi ma hallata tohutut Kubernetese klastrit ega kasutada Docker Swarmi tehnoloogiat ega hooldada serveriparki koos podide, agentide ja kõikvõimaliku muuga. keerukusi. Et saavutada eesmärk muuta töö võimalikult lihtsaks, oli mul vaja tutvuda CI/CD-ga.

Kui teil on väike projekt (antud juhul Node.js projekt) ja soovite teada, kuidas selle projekti juurutamist automatiseerida, tagades samal ajal, et hoidlas talletatu vastab täpselt tootmises töötavale, siis ma arvan, et see artikkel võib teile huvi pakkuda.

Eeldused

Selle artikli lugejalt eeldatakse põhiteadmisi käsurealt ja Bashi skriptide kirjutamisest. Lisaks vajab ta kontosid Travis C.I. и Dockeri jaotur.

Eesmärgid

Ma ei ütle, et seda artiklit saab tingimusteta "õpetuseks" nimetada. See on pigem dokument, milles räägin õpitust ja kirjeldan mulle sobivat protsessi testimiseks ja koodi tootmisse juurutamiseks, mis tehakse ühe automaatkäiguga.

Sellega mu töövoog lõppes.

Koodi jaoks, mis on postitatud mis tahes hoidla harusse, v.a master, tehakse järgmised toimingud:

• Algab Travis CI-le tuginev projekt.
• Tehakse kõik üksuse-, integratsiooni- ja lõpptestid.

Ainult koodile, mis satub master, tehakse järgmist:

• Kõik eelpool mainitud, pluss...
• Dockeri pildi loomine praeguse koodi, sätete ja keskkonna põhjal.
• Pildi juurutamine Docker Hubi.
• Ühendus tootmisserveriga.
• Pildi üleslaadimine Docker Hubist serverisse.
• Praeguse konteineri peatamine ja uue alustamine uue pildi põhjal.

Kui te ei tea Dockerist, piltidest ja konteineritest absoluutselt midagi, ärge muretsege. Ma räägin teile sellest kõigest.

Mis on CI/CD?

Lühend CI/CD tähistab pidevat integreerimist/pidevat juurutamist.

▍Pidev integreerimine

Pidev integreerimine on protsess, mille käigus arendajad võtavad kohustusi projekti peamisse lähtekoodihoidlasse (tavaliselt haru master). Samas tagatakse koodi kvaliteet läbi automatiseeritud testimise.

▍Pidev juurutamine

Pidev juurutamine on koodi sagedane automatiseeritud juurutamine tootmisse. CI/CD akronüümi teine ​​osa on mõnikord kirjutatud kui "pidev kohaletoimetamine". See on põhimõtteliselt sama mis "pidev juurutamine", kuid "pidev kohaletoimetamine" tähendab vajadust muudatused käsitsi kinnitada enne projekti juurutamise protsessi alustamist.

Alustamine

Rakendust, mida ma selle kõige õppimiseks kasutasin, nimetatakse Võtta teadmiseks. See on veebiprojekt, mille kallal ma töötan ja mis on mõeldud märkmete tegemiseks. Algul proovisin teha JAMSstack-projekt või lihtsalt ilma serverita esiotsarakendus, et kasutada ära selle pakutavaid standardseid hostimis- ja projekti juurutamisvõimalusi võrgustada. Rakenduse keerukuse kasvades oli mul vaja luua selle serveriosa, mis tähendas, et mul oli vaja sõnastada oma strateegia automatiseeritud integratsiooniks ja projekti automatiseeritud juurutamiseks.

Minu puhul on rakenduseks Node.js keskkonnas töötav Express-server, mis teenindab ühelehelist Reacti rakendust ja toetab turvalist serveripoolset API-d. See arhitektuur järgib strateegiat, mille võib leida see Täielik virna autentimise juhend.

Pidasin nõu sõber, kes on automaatikaekspert, ja küsis temalt, mida ma pean tegema, et see kõik toimiks nii, nagu ma soovin. Ta andis mulle idee, milline peaks välja nägema automatiseeritud töövoog, mida kirjeldatakse selle artikli jaotises Eesmärgid. Nende eesmärkide saavutamine tähendas, et mul oli vaja välja mõelda, kuidas Dockerit kasutada.

laevalaadija

Docker on tööriist, mis tänu konteineritehnoloogiale võimaldab rakendusi hõlpsalt levitada, juurutada ja samas keskkonnas käitada, isegi kui Dockeri platvorm ise töötab erinevates keskkondades. Esiteks pidin ma Dockeri käsurea tööriistad (CLI) kätte saama. juhendamine Dockeri installijuhendit ei saa nimetada väga selgeks ja arusaadavaks, kuid sealt saab teada, et esimese installisammu tegemiseks tuleb alla laadida Docker Desktop (Maci või Windowsi jaoks).

Docker Hub on ligikaudu sama mis GitHub git-hoidlate või registri jaoks npm JavaScripti pakettide jaoks. See on Dockeri piltide veebihoidla. See on see, millega Docker Desktop ühendub.

Dockeri kasutamise alustamiseks peate tegema kaks asja.

• Komplekt Dockeri töölaud.
• Registreeru Dockeri jaotur.

Pärast seda saate kontrollida, kas Dockeri CLI töötab, käivitades Dockeri versiooni kontrollimiseks järgmise käsu:

docker -v

Järgmisena logige sisse Docker Hubi, sisestades oma kasutajanime ja parooli, kui teilt küsitakse:

docker login

Dockeri kasutamiseks peate mõistma piltide ja konteinerite mõisteid.

▍Pildid

Pilt on midagi plaani sarnast, mis sisaldab juhiseid konteineri kokkupanekuks. See on muutumatu hetktõmmis rakenduse failisüsteemist ja sätetest. Arendajad saavad hõlpsalt pilte jagada.

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

See käsk väljastab järgmise päisega tabeli:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

Järgmisena vaatame mõnda näidet samas vormingus käskudest – kõigepealt on käsk koos kommentaariga ja seejärel näide, mida see väljastada saab.

▍Konteinerid

Konteiner on käivitatav pakett, mis sisaldab kõike, mis on rakenduse käitamiseks vajalik. Selle lähenemisviisiga rakendus töötab alati ühtemoodi, olenemata infrastruktuurist: eraldatud keskkonnas ja samas keskkonnas. Asi on selles, et sama pildi eksemplarid käivitatakse erinevates keskkondades.

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

▍Sildid

Silt näitab pildi konkreetset versiooni.

▍Kiirviide Dockeri käskudele

Siin on ülevaade mõnedest sagedamini kasutatavatest Dockeri käskudest.

Meeskond

Kontekst

mõju

doki ehitamine

Pilt

Kujutise loomine Dockerfile'ist

doki silt

Pilt

Pildi märgistamine

dokkide pildid

Pilt

Piltide loend

dock käivitada

Konteiner

Konteineri käitamine pildi põhjal

doki lükkamine

Pilt

Pildi üleslaadimine registrisse

doki tõmbamine

Pilt

Pildi laadimine registrist

docker ps

Konteiner

Konteinerite loend

dokkimissüsteem ploomi

Pilt/konteiner

Kasutamata konteinerite ja piltide eemaldamine

▍ Dockeri fail

Ma tean, kuidas tootmisrakendust kohapeal käivitada. Mul on veebipaketi konfiguratsioon, mis on loodud valmis Reacti rakenduse loomiseks. Järgmiseks on mul käsk, mis käivitab pordist Node.js-põhise serveri 5000. See näeb välja selline:

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

Tuleb märkida, et mul pole selle materjali jaoks näidisrakendust. Kuid siin sobib katsete jaoks iga lihtne Node rakendus.

Konteineri kasutamiseks peate Dockerile juhiseid andma. Seda tehakse faili nimega Dockerfile, mis asub projekti juurkataloogis. See fail tundub alguses üsna arusaamatu.

Kuid see, mida see sisaldab, kirjeldab ainult spetsiaalsete käskudega midagi sarnast töökeskkonna seadistamisega. Siin on mõned neist käskudest:

• ALATES — See käsk käivitab faili. See määrab baaskujutise, millele konteiner on ehitatud.
• COPY — failide kopeerimine kohalikust allikast konteinerisse.
• TÖÖDIREKTOR — Töökataloogi seadistamine järgmiste käskude jaoks.
• RUN - Käivita käsud.
• KOKKUPUUDE — pordi seaded.
• SISENEMISPUNKT — märge täidetava käsu kohta.

Dockerfile võib välja näha umbes selline:

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

Olenevalt valitud põhipildist peate võib-olla installima täiendavaid sõltuvusi. Fakt on see, et mõned baaspildid (nt Node Alpine Linux) luuakse eesmärgiga muuta need võimalikult kompaktseks. Seetõttu ei pruugi neil olla mõnda programmi, mida ootate.

▍Mahuti ehitamine, märgistamine ja käitamine

Kohalik kokkupanek ja konteineri käivitamine on pärast seda, kui oleme Dockerfile, ülesanded on üsna lihtsad. Enne pildi Docker Hubi edastamist peate seda kohapeal testima.

▍Kokkupanek

Kõigepealt peate koguma образ, mis määrab nime ja soovi korral sildi (kui silti pole määratud, määrab süsteem pildile automaatselt sildi latest).

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

Pärast selle käsu käivitamist saate vaadata, kuidas Docker pildi loob.

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

Ehitamine võib võtta paar minutit – kõik sõltub sellest, kui palju sõltuvusi teil on. Kui ehitamine on lõpetatud, saate käsu käivitada docker images ja vaadake oma uue pildi kirjeldust.

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

▍ Käivitage

Pilt on loodud. See tähendab, et saate selle põhjal konteinerit käivitada. Kuna ma tahan pääseda juurde konteineris töötavale rakendusele aadressil localhost:5000, mina, paari vasakul küljel 5000:5000 järgmises installitud käsus 5000. Paremal küljel on konteineri port.

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

Nüüd, kui konteiner on loodud ja töötab, saate kasutada käsku docker ps selle konteineri kohta teabe vaatamiseks (või võite kasutada käsku docker ps -a, mis kuvab teavet kõigi konteinerite kohta, mitte ainult töötavate konteinerite kohta).

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

Kui lähete nüüd aadressile localhost:5000 — näete töötava rakenduse lehte, mis näeb välja täpselt samasugune kui tootmiskeskkonnas töötava rakenduse leht.

▍Märgistamine ja avaldamine

Ühe loodud kujutise kasutamiseks tootmisserveris peame saama selle pildi Docker Hubist alla laadida. See tähendab, et peate esmalt looma Docker Hubis projekti hoidla. Pärast seda on meil koht, kuhu saame pildi saata. Pilt tuleb ümber nimetada nii, et selle nimi algaks meie Docker Hubi kasutajanimega. Sellele peaks järgnema hoidla nimi. Nime lõppu võib panna mis tahes sildi. Allpool on näide selle skeemi abil piltide nimetamisest.

Nüüd saate luua pildi uue nimega ja käivitada käsu docker push et lükata see Docker Hubi hoidlasse.

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

Kui kõik läheb hästi, on pilt saadaval Docker Hubis ja seda saab hõlpsasti serverisse üles laadida või teistele arendajatele üle kanda.

Järgmised sammud

Nüüdseks oleme kontrollinud, et rakendus Dockeri konteineri kujul töötab kohapeal. Laadisime konteineri üles Docker Hubi. Kõik see tähendab, et oleme oma eesmärgi suunas juba väga hästi edasi liikunud. Nüüd peame lahendama veel kaks küsimust:

• CI tööriista seadistamine koodi testimiseks ja juurutamiseks.
• Tootmisserveri seadistamine, et see saaks meie koodi alla laadida ja käivitada.

Meie puhul kasutame Travis C.I.. serverina - Digitaalne ookean.

Tuleb märkida, et siin saate kasutada teist teenuste kombinatsiooni. Näiteks saate Travis CI asemel kasutada CircleCI või Githubi toiminguid. Ja DigitalOceani asemel - AWS või Linode.

Otsustasime teha koostööd Travis CI-ga ja mul on selles teenuses juba midagi konfigureeritud. Seetõttu räägin nüüd lühidalt, kuidas seda tööks ette valmistada.

Travis C.I.

Travis CI on tööriist koodi testimiseks ja juurutamiseks. Ma ei tahaks Travis CI seadistamise keerukustesse laskuda, kuna iga projekt on ainulaadne ja see ei too palju kasu. Kuid ma käsitlen põhitõdesid, et saaksite alustada, kui otsustate kasutada Travis CI-d. Olenemata sellest, kas valite Travis CI, CircleCI, Jenkinsi või mõne muu, kasutatakse kõikjal sarnaseid konfigureerimismeetodeid.

Travis CI-ga alustamiseks minge aadressile projekti veebisait ja loo konto. Seejärel integreerige Travis CI oma GitHubi kontoga. Süsteemi seadistamisel peate määrama hoidla, millega soovite tööd automatiseerida, ja võimaldama sellele juurdepääsu. (Ma kasutan GitHubi, kuid olen kindel, et Travis CI saab integreerida BitBucketi, GitLabi ja muude sarnaste teenustega).

Iga kord, kui Travis CI käivitatakse, käivitatakse server, mis täidab konfiguratsioonifailis määratud käske, sealhulgas juurutab vastavad hoidla harud.

▍Töö elutsükkel

Travis CI konfiguratsioonifail kutsus .travis.yml ja salvestatud projekti juurkataloogi, toetab sündmuste kontseptsiooni eluring ülesandeid. Need sündmused on loetletud nende toimumise järjekorras:

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

▍Testimine

Konfiguratsioonifailis konfigureerin kohaliku Travis CI serveri. Valisin keeleks sõlme 12 ja käskisin süsteemil installida Dockeri kasutamiseks vajalikud sõltuvused.

Kõik, mis on loetletud .travis.yml, täidetakse siis, kui kõik tõmbetaotlused esitatakse hoidla kõikidele harudele, kui pole teisiti määratud. See on kasulik funktsioon, kuna see tähendab, et saame testida kogu hoidlasse saabuvat koodi. See annab teile teada, kas kood on harusse kirjutamiseks valmis. masterja kas see katkestab projekti koostamise protsessi. Selles globaalses konfiguratsioonis installin kõik lokaalselt, käivitan taustal Webpacki arendajaserveri (see on minu töövoo funktsioon) ja käivitan testid.

Kui soovite, et teie hoidla kuvaks märgid, mis näitavad testi katvust, siin Leiate lühikesed juhised selle teabe kogumiseks ja kuvamiseks Jesti, Travis CI ja kombinesoonide kasutamise kohta.

Nii et siin on faili sisu .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

Siin lõpevad toimingud, mida tehakse hoidla kõigi harude ja tõmbamispäringute jaoks.

▍Kasutuselevõtt

Eeldusel, et kõik automatiseeritud testid on edukalt lõpule viidud, saame koodi tootmisserverisse juurutada, mis pole kohustuslik. Kuna me tahame seda teha ainult filiaali koodi jaoks master, anname süsteemile juurutusseadetes vastavad juhised. Enne kui proovite kasutada koodi, mida oma projektis järgmisena vaatame, hoiatan teid, et teil peab olema juurutamiseks kutsutud tegelik skript.

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

Juurutusskript lahendab kaks probleemi:

• Ehitage, märgistage ja saatke pilt Docker Hubi, kasutades CI tööriista (meie puhul Travis CI).
• Pildi laadimine serverisse, vana konteineri seiskamine ja uue käivitamine (meie puhul töötab server DigitalOceani platvormil).

Esiteks peate seadistama automaatse protsessi pildi loomiseks, märgistamiseks ja Docker Hubi edastamiseks. See kõik on väga sarnane sellega, mida oleme juba käsitsi teinud, välja arvatud see, et vajame strateegiat piltidele ainulaadsete siltide määramiseks ja sisselogimiste automatiseerimiseks. Mul oli raskusi juurutusskripti mõnede üksikasjadega, nagu sildistamisstrateegia, sisselogimine, SSH-võtme kodeering, SSH-ühenduse loomine. Aga õnneks on mu poiss-sõber bashiga väga osav, nagu ka paljude muude asjadega. Ta aitas mul seda stsenaariumi kirjutada.

Niisiis, skripti esimene osa on pildi üleslaadimine Docker Hubi. Seda on üsna lihtne teha. Minu kasutatud sildistamisskeem hõlmab git-räsi ja git-sildi kombineerimist, kui see on olemas. See tagab, et silt on kordumatu, ja hõlbustab selle koostu tuvastamist, millel see põhineb. DOCKER_USERNAME и DOCKER_PASSWORD on kasutajakeskkonna muutujad, mida saab määrata Travis CI liidese abil. Travis CI töötleb tundlikke andmeid automaatselt, et need ei satuks valedesse kätesse.

Siin on stsenaariumi esimene osa 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}

See, milline saab olema skripti teine ​​osa, sõltub täielikult sellest, millist hosti te kasutate ja kuidas sellega ühendus on korraldatud. Kuna ma kasutan Digital Oceanit, siis kasutan serveriga ühenduse loomiseks käske docl. AWS-iga töötamisel kasutatakse utiliiti aws, ja nii edasi.

Serveri seadistamine ei olnud eriti keeruline. Niisiis, ma seadistasin tilgakese põhipildi põhjal. Tuleb märkida, et minu valitud süsteem nõuab Dockeri ühekordset käsitsi installimist ja Dockeri ühekordset käsitsi käivitamist. Kasutasin Dockeri installimiseks Ubuntu 18.04, nii et kui kasutate sama tegemiseks ka Ubuntut, võite lihtsalt järgida see lihtne juhend.

Ma ei räägi siin teenuse konkreetsetest käskudest, kuna see aspekt võib erinevatel juhtudel oluliselt erineda. Annan lihtsalt üldise tegevusplaani, mis tuleb läbi viia pärast SSH kaudu ühenduse loomist serveriga, kuhu projekt juurutatakse:

• Peame leidma praegu töötava konteineri ja selle peatama.
• Seejärel peate taustal käivitama uue konteineri.
• Peate määrama serveri kohaliku pordi 80 - see võimaldab teil siseneda saidile aadressil nagu example.com, pordi täpsustamata, selle asemel, et kasutada aadressi nagu example.com:5000.
• Lõpuks peate kustutama kõik vanad konteinerid ja pildid.

Siin on stsenaariumi jätk.

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

Mõned asjad, millele tähelepanu pöörata

Võimalik, et kui loote Travis CI-st SSH kaudu serveriga ühenduse, näete hoiatust, mis takistab teil installimist jätkamast, kuna süsteem ootab kasutaja vastust.

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

Sain teada, et stringi võtme saab kodeerida base64-sse, et see salvestada sellisel kujul, et sellega saab mugavalt ja usaldusväärselt töötada. Installimisetapis saate avaliku võtme dekodeerida ja faili kirjutada known_hosts ülaltoodud veast vabanemiseks.

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

Praktikas võib see käsk välja näha järgmine:

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

Ja siin on see, mida see toodab – base64 kodeeritud string:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Siin on ülalmainitud käsk

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

Sama lähenemisviisi saab kasutada ka privaatvõtmega ühenduse loomisel, kuna serverile juurdepääsuks võib vaja minna privaatvõtit. Võtmega töötades peate lihtsalt tagama, et see oleks turvaliselt Travis CI keskkonnamuutujas salvestatud ja et seda ei kuvata kuskil.

Veel tuleb märkida, et võib-olla peate kogu juurutusskripti käivitama ühe reana, näiteks koos doctl. See võib nõuda lisapingutusi.

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

TLS/SSL ja koormuse tasakaalustamine

Pärast seda, kui tegin kõik ülalmainitud, oli viimane probleem, millega puutusin kokku, see, et serveril ei olnud SSL-i. Kuna ma kasutan Node.js serverit, siis selleks, et sundida töö pöördpuhverserver Nginx ja Let's Encrypt, peate palju nuputama.

Ma tõesti ei tahtnud kogu seda SSL-i konfiguratsiooni käsitsi teha, nii et lõin lihtsalt koormuse tasakaalustaja ja salvestasin selle üksikasjad DNS-i. Näiteks DigitalOceani puhul on koormuse tasakaalustajal automaatselt uueneva iseallkirjastatud sertifikaadi loomine lihtne, tasuta ja kiire protseduur. Selle lähenemisviisi eeliseks on see, et see muudab vajaduse korral SSL-i seadistamise väga lihtsaks mitmes serveris, mis töötavad koormuse tasakaalustaja taga. See võimaldab serveritel endil SSL-ile üldse mitte “mõelda”, vaid samal ajal kasutada porti nagu tavaliselt 80. Seega on SSL-i seadistamine koormuse tasakaalustajal palju lihtsam ja mugavam kui alternatiivsed SSL-i seadistamise meetodid.

Nüüd saate sulgeda kõik serveri pordid, mis võtavad vastu sissetulevaid ühendusi – välja arvatud port 80, mida kasutatakse koormuse tasakaalustaja ja pordiga suhtlemiseks 22 SSH jaoks. Selle tulemusena nurjub katse pääseda otse serverile juurde mis tahes muul pordil peale nende kahe.

Tulemused

Pärast seda, kui tegin kõike, millest selles materjalis rääkisin, ei hirmutanud mind enam ei Dockeri platvorm ega automatiseeritud CI/CD-kettide kontseptsioonid. Sain luua pideva integratsiooniahela, mille käigus testitakse koodi enne tootmisse minekut ja kood võetakse automaatselt serverisse. See kõik on minu jaoks veel suhteliselt uus ja ma olen kindel, et on olemas viise oma automatiseeritud töövoo täiustamiseks ja tõhusamaks muutmiseks. Nii et kui teil on selles küsimuses ideid, andke mulle teada. mind tea. Loodan, et see artikkel aitas teid teie püüdlustes. Ma tahan uskuda, et pärast selle lugemist õppisite sama palju kui mina, kui sain aru, millest ma selles rääkisin.

PS Meie turuplats pilt on olemas laevalaadija, mille saab installida ühe klõpsuga. Konteinerite tööd saate kontrollida aadressil VPS. Kõikidele uutele klientidele antakse 3 päeva tasuta testimist.

Kallid lugejad! Kas kasutate oma projektides CI/CD tehnoloogiaid?

Allikas: www.habr.com