🥇CI/CD ahela loomine ja töö automatiseerimine Dockeriga

Ma tahtsin oma esimesi saite 90ndate lõpus. Toona oli nende tööle saamine väga lihtne. Ükskõik milline jagatud hostings, kus oli Apache-server, võimaldas FTP-dele siseneda, kirjutades brauseri aadressiribale midagi sellist nagu ftp://ftp.example.com. Siis tuli sisestada nimi ja parool ning failid serverisse laadida. Need olid teised ajad, kõik oli toona lihtsam kui nüüd.

Viimase kahekümne aasta jooksul on asjad tõsiselt muutunud. Saite on keerukamaks muutunud, neid tuleb enne tootmisse saatmist kokku panna. Üksik server on muutunud paljudeks serveriteks, mis töötavad koormuste tasakaalustajate taga, ja versioonikontrolli süsteemide kasutamine on tavaline.

Minu isikliku projekti jaoks oli mul eriline konfigureerimine. Ja ma teadsin, et mul on vaja, et saaksin saiti tootmisesse tuua, tehes vaid ühe tegevuse: koodi salvestamine harusse master GitHubis. Samuti teadsin, et ma ei soovi oma väikese veebirakenduse toimimise tagamiseks hallata suurt Kubernetes-klastri või kasutada Docker Swarm'i tehnoloogiat või hooldada serverite parki, millel on podid, agentuurid ja muud keerukused. Maximaalse lihtsuse saavutamiseks oli mul vaja tutvuda CI/CD'ga.

Kui teil on väike projekt (meie puhul räägime Node.js projektist) ja te soovite teada, kuidas selle projekti juurutamist automatiseerida, tehes samas nii, et sellesse repos olev sisaldus vastab täpselt sellele, mis töötab tootmises, siis usun, et teid võib see artikkel huvitada.

Eeltingimused

Oodatav on, et selle artikli lugejal on põhilised teadmised käsurea kasutamisest ja Bash-skriptide kirjutamisest. Samuti on vaja arve Travis CI ja Docker Hub.

Eesmärgid

Ma ei ütle, et see artikkel on üheselt mõistetav "õpik". Pigem on see dokument, kus räägin sellest, mida õppisin, ja kirjeldan enda rahuldavat protsessi koodi testimise ja juurutamise kohta tootmises, mis toimub ühe automatiseeritud läbimisega.

Nii see lõppkokkuvõttes välja näeb mu tööprotsess.

Koodi, mis saadetakse mis tahes harusse repos, välja arvatud master, viiakse ellu järgmised tegevused:

Projekt ehitatakse Travis CI's.
Käideldakse kõik moodulitest, integreerimisest ja lõpp-punktitest testid.

Ainult koodi jaoks, mis langeb master, kehtib järgmine:

KÕIK, mis on eespool öeldud, pluss…
Docker-pildi koostamine praeguse koodi, seadistuste ja keskkonna põhjal.
Pildi paigutamine Docker Hub'i.
Ühendamine tootmisserveriga.
Pildi laadimine Docker Hub'ist serverisse.
Praeguse konteineri peatamine ja uue käivitamine, mis põhineb uuel pildil.

Kui sa ei tea absoluutselt midagi Dockerist, piltidest ja konteineritest — ära muretse. Räägin sellest kõigest sulle.

Mis on CI/CD?

Lühend CI/CD tähistab «continuous integration/continuous deployment» — «pidev integraatsioon/pidev juurutamine».

▍Pidev integraatsioon

Pidev integraatsioon on protsess, kus arendajad teevad muudatusi projekti koodihoidlas (tavaliselt harus master). Sellega tagatakse koodi kvaliteet automatiseeritud testimise kaudu.

▍Pidev juurutamine

Pidev juurutamine on sagedane automatiseeritud koodi juurutamine tootmisüksuses. CI/CD lühendi teine osa avatakse mõnikord kui «continuous delivery» («pidev kohaletoimetamine»). See on sisuliselt sama mis «pidev juurutamine», kuid «pidev kohaletoimetamine» eeldab muudatuste käsitsi kinnitamist enne projekti juurutamisprotsessi käivitamist.

Esimene samm

Rakendus, millega ma seda kõike õppisin, on nimega TakeNote. See on veebiprojekt, millega ma töötan, et teha märkmeid. Alguses proovisin ma teha JAMStack-projekti või lihtsalt front-end rakendust ilma serverita, et kasutada standardseid võimalusi projektide hostimiseks ja juurutamiseks, mida pakub Netlify. Kui rakenduse keerukus kasvas, pidin looma ka serveri osa, mis tähendas, et mul tuli välja töötada oma automatiseeritud integreerimise ja automatiseeritud juurutamise strateegia.

Minu puhul on rakendus Express-server, mis töötab Node.js keskkonnas, teenindab ühtset React-rakendust ja toetab turvalist serveri API-d. See arhitektuur järgib strateegiat, mille leiad sellest täieliku stacki autentimise juhendist.

Konsulteerisin teises, kes on automatiseerimise ekspert, ja küsisin temalt, mida pean tegema, et kõik see toimiks nagu ma vajasin. Ta viskas mulle idee, milline peaks olema automatiseeritud töövoog, mis on toodud käesoleva artikli jaotises "Eesmärgid". See, et ma seadsin endale sellised eesmärgid, tähendas, et pean aru saama, kuidas kasutada Dockerit.

Docker

Docker on tööriist, mis tänu konteineritehnoloogiale võimaldab hõlpsasti levitada rakendusi ning käivitada ja juurutada neid ühes ja samas keskkonnas, isegi kui Docker ise töötab erinevates keskkondades. Alguses pidin hankima endale Docker CLI käsurea tööriistad. Juhend Docker'i installimiseks ei saa nimetada väga selgeks ja arusaadavaks, kuid sellest saab teada, et esimese paigaldusastme tegemiseks tuleb alla laadida Docker Desktop (Maci või Windowsi jaoks).

Docker Hub on ligikaudu sama, mis GitHub git-reposiitide jaoks, või registri npm JavaScripti pakettide jaoks. See on veebipõhine register Docker'i piltide jaoks. Just sellele on ühendatud Docker Desktop.

Nii et, et alustada Docker'iga töötamist, peate tegema kaks asja:

Installige Docker Desktop.
Registreerige end Docker Hub.

Pärast seda saate kontrollida Docker CLI toimivust, käivitades järgmise käsu Docker'i versiooni kontrollimiseks:

docker -v

Seejärel logige sisse Docker Hubi, sisestades, kui teilt seda küsitakse, oma kasutajanime ja parooli:

docker login

Docker'iga töötamiseks peate mõistma kujundite ja konteinerite kontseptsioone.

▍Kujundid

Kujund on midagi nagu plaan, mis sisaldab juhiseid konteineri kokkupanekuks. See on muutumatu failisüsteemi ja rakenduse seadete pilt. Arendajad saavad kujundeid hõlpsasti vahetada.

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

See käsk toob välja tabeli järgmise pealkirjaga:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

Seejärel vaatame mõningaid käskude näiteid samas formaadis – esmalt käsk koos kommentaariga ja seejärel näide sellest, mida see võib välja anda.

▍Konteinerid

Konteiner on teostatav paket, mis sisaldab kõike, mis on vajalik rakenduse käitamiseks. Sellise lähenemisega töötab rakendus alati ühtemoodi, sõltumata infrastruktuurist: isoleeritud keskkonnas ja samas keskkonnas. See tähendab, et erinevates keskkondades käivitatakse sama pildi eksemplare.

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

▍Sildid

Silt on viide konkreetsele pildi versioonile.

▍Lühike ülevaade Docker käskudest

Siin on ülevaade mõnest sageli kasutatavast Docker käsust.

Meeskond

Kontekst

Tegevus

docker build

Tüüp

Pildi koostamine Dockerfile'ist

docker tag

Tüüp

Pildi sildistamine

docker images

Tüüp

Piltide nimekirja kuvamine

docker run

Konteiner

Konteineri käivitamine pildi alusel

docker push

Tüüp

Pildi saatmine registrisse

docker pull

Tüüp

Pildi allalaadimine registrist

docker ps

Konteiner

Konteinerite nimekirja kuvamine

docker system prune

Pilt/Konteiner

Nelikud ja mittekasutatud konteinerite ja piltide eemaldamine

▍Dockerfile

Ma tean, kuidas käitada rakendust kohalikult tootmises. Mul on Webpack konfiguratsioon, mis on mõeldud valmis React rakenduse koostamiseks. Edasi on mul käsk, mis käivitab Node.js baasil serveri, port. 5000. See näeb välja nii:

npm i          # sõltuvuste installimine
npm run build # React rakenduse koostamine
npm run start # Node serveri käivitamine

Pean märkima, et mul ei ole selle materjali jaoks näidisarendust. Kuid siia sobib katsetamiseks iga lihtne Node rakendus.

Konteineri kasutamiseks peate andma Dockerile juhised. Seda tehakse faili abil, mida nimetatakse. Dockerfile, mis asub projekti juurkataloogis. Alguses näib see fail üsna segane.

Kuid see, mis selles sisaldub, kirjeldab lihtsalt eriliste käskudega midagi, mis sarnaneb töökeskkonna seadistamisele. Siin on mõned nendest käskudest:

KUST — See käsk alustab faili. See määratleb baaspildi, mille alusel konteiner ehitatakse.
COPY — Failide kopeerimine kohalikust allikast konteinerisse.
WORKDIR — Järgmiste käskude töödirektori seadmine.
KÄIVITA — Käskude käivitamine.
EXPOSE — Sadama seadistamine.
ENTRYPOINT — Teostatava käsku määramine.

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

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

Sõltuvalt valitud baasipildist võib olla vajalik lisade installimine. Teatud baasipildid (nagu Node Alpine Linux) on loodud võimalikult kompaktsena, mistõttu võivad need sisaldada puuduvaid programme, millele te lootsite.

▍Konteineri ehitamine, märgistamine ja käivitamine

Kohalik konteineri ehitamine ja käivitamine — see on see, kui meil on Dockerfile, ülesanded on üsna lihtsad. Enne, kui pildi Docker Hub'i saatmisega edasi minna, tuleb see kohapeal testida.

▍Ehitus

Esiteks tuleb ehitada pilt, määrates nime ja valikuliselt ka märgise (kui märgis pole määratud, määrab süsteem automaatselt pildile märgise latest).

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

Pärast selle käsu täitmist saab jälgida, kuidas Docker pildi ehitamise lõpule viib.

Sending build context to Docker daemon   2.88MB
Step 1/9 : FROM node:12-alpine
  ---> ...ehitusetappide täitmine...
Successfully built 123456789123
Successfully tagged <image>:<tag>

Ehitus võib võtta paar minutit — see sõltub teie sõltuvustest. Kui ehitus on lõpetatud, saab välja anda käsu docker images ja vaadata oma uue pildi kirjeldust.

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

▍Käivitamine

Pilt on loodud. See tähendab, et selle alusel saab käivitada konteineri. Kuna ma tahan, et mul oleks võimalik lugeda konteineritöötavat rakendust aadressilt localhost:5000, siis olen vasakus osas määranud 5000:5000 . Paremas osas on konteineri port. 5000Nüüd, kui konteiner on loodud ja käivitatud, saab kasutada käsku

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

et vaadata selle konteineri teavet (või võib kasutada käsku docker ps docker ps -a , mis kuvab teavet kõigi konteinerite kohta, mitte ainult töötavate 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 nüüd minna aadressile

— saab näha töötava rakenduse lehte, mis näeb välja täpselt nagu tootmiskeskkonnas töötava rakenduse leht. localhost:5000 ▍Märgise määramine ja avaldamine

▍Назначение тега и публикация

Ette, et kasutada ühte loodud pilti tootmisserveris, peab meil olema võimalus see pilt laadida Docker Hub'ist. See tähendab, et kõigepealt tuleb luua Docker Hub'is projekti jaoks repository. Pärast seda on meil koht, kuhu pilti saata. Pilt tuleb nimetada nii, et selle nimi algab meie kasutajanimeniga Docker Hub'is. Seejärel peab olema repository nimi. Nime lõpus võib olla ükskõik milline silt. Allpool on näidatud näide piltide nimetamisest selle skeemi järgi.

Nüüd saab pildi kokku panna, andes sellele uue nime ja käivitades käsu docker push selle saatmiseks Docker Hub'i repository'sse.

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

# Praktiliselt võiks see välja näha näiteks nii:
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 nagu peab, siis on pilt saadaval Docker Hub'is ja seda on lihtne serverisse laadida või teistele arendajatele edastada.

Järgmised sammud

Praeguseks oleme veendunud, et rakendus Docker konteinerina töötab kohapeal. Oleme konteineri laadinud Docker Hub'i. See kõik tähendab, et oleme juba üsna kaugele eesmärgi suunas liikunud. Nüüd tuleb lahendada veel kaks küsimust:

CI tööriista seadistamine koodi testimiseks ja juurutamiseks.
Tootmisserveri seadistamine nii, et see suudab meie koodi laadida ja käivitada.

Meie juhul kasutatakse CI/CD lahendusena Travis CI. Serverina — DigitalOcean.

Tuleb märkida, et siin saab kasutada ka teist kombinatsiooni teenustest. Näiteks, Travis CI asemel võib kasutada CircleCI või Github Actions. Ja DigitalOcean'i asemel — AWS või Linode.

Oleme otsustanud töötada Travis CI-ga, ja selle teenuse osas on mul juba midagi seadistatud. Seetõttu räägin nüüd lühidalt, kuidas seda tööks ette valmistada.

Travis CI

Travis CI on tööriist koodi testimiseks ja juurutamiseks. Ma ei sooviks minna Travis CI seadistamise nüanssidesse, kuna iga projekt on unikaalne ning see ei tooks erilist kasu. Kuid räägin põhialustest, mis võimaldavad teil alustada, juhul kui otsustate kasutada Travis CI-d. Ükskõik, mida te valite — Travis CI, CircleCI, Jenkins või midagi muud, on kõikjal rakendatavad sarnased seadistamismeetodid.

Ettevalmistamiseks Travis CI-ga minge projekti sait ja looge konto. Integreerige seejärel Travis CI oma GitHubi kontoga. Seadmise käigus peate määrama hoidla, mille automatiseerimist soovite, ja lubama sellele ligipääsu. (Kasutamisel on mul GitHub, aga olen kindel, et Travis CI saab integreeruda ka BitBucketi, GitLabi ja teiste sarnaste teenustega).

Iga kord, kui Travis CI alustab tööd, töötab server, mis täidab konfiguratsioonifailis määratud käske, sealhulgas vastava hoidla harude juurutamist.

▍Ülesande elutsükkel

Travis CI konfiguratsioonifail, mida nimetatakse .travis.yml ja mis asub projekti juurkataloogis, toetab sündmuste kontseptsiooni RHEL 6 ja 7 levitustes ning RHEL 8 jaoks koostab see pakettide uuendusi Application Stream'is kuni juuni 2024. Meeldetuletuseks, Python 2.7 haru ülesande jaoks. Siin on need sündmused, esitatud järjekorras, milles need esinevad:

apt addons
cache components
before_install
install
before_script
script
before_cache
after_success või after_failure
before_deploy
deploy
after_deploy
after_script

▍Testimine

Konfiguratsioonifailis kavatsen seadistada kohaliku Travis CI serveri. Keelena valisin Node 12 versiooni ja andsin süsteemile teada, et tuleb installida Dockeriks vajalikud sõltuvused.

Kõik, mis on loetletud .travis.yml, täidetakse kõikide pull-päringute puhul kõigis hoidla harudes, välja arvatud juhul, kui on märgitud teisiti. See on kasulik funktsioon, kuna see tähendab, et saame testida kogu koodi, mis jõuab hoidlasse. See annab teada, kas kood on haru master, salvestamiseks valmis ja ei rikku ehitusprotsessi. Selle globaalsete konfiguratsioonide korral installin kõik kohaliku, käitan Webpacki arendaja serverit taustal (see on minu tööprotsessi eripära) ja teen teste.

Kui soovite, et teie hoidlas kuvatakse märgid testa katteandmete kohta, siit võite leida lühikese juhendi Jest, Travis CI ja Coverallsi kasutamiseks nende andmete kogumiseks ja kuvamiseks.

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õppevad kõik toimingud, mis viiakse läbi kõigi hoidla harude ja pull-päringute jaoks.

▍Juurutamine

Oletades, et kõik automatiseeritud testid on lõppenud edutult, saame, kuigi see ei ole vajalik, juurutada koodi tootmiserverisse. Kuna soovime seda teha ainult koodi puhul harust master, me anname süsteemile vastavad juhised arendus- ja paigaldusseadetes. Enne kui proovite oma projektis kasutada koodi, mida me hiljem vaatame, sooviksin teid hoiatada, et teil peab olema reaalne skript, mida kasutada paigaldamiseks.

deploy:
  # Koguge Docker-konteiner ja saatke see Docker Hub'i
  provider: script
  script: bash deploy.sh
  on:
    branch: master

Paigaldusskripti eesmärgiks on kaks ülesannet:

Kogumine, sildistamine ja pildi saatmine Docker Hub'i CI-tööriista (meie puhul Travis CI) kaudu.
Pildi üleslaadimine serverisse, vana konteineri peatamine ja uue käivitamine (meie juhul töötab server DigitalOcean'i platvormil).

Esiteks tuleb seadistada automaatne protsess pildi kogumiseks, sildistamiseks ja saatmiseks Docker Hub'i. Kõik see on väga sarnane sellele, mida oleme juba käsitsi teinud, välja arvatud see, et meil on vaja strateegiat piltide ainulaadsete siltide määramiseks ja sisselogimise automatiseerimist. Mul olid raskused mõnede arendus-skripti detailide, näiteks sildistamisstrateegia, sisselogimise, SSH-võtmete kodeerimise ja SSH-ühenduse loomisega. Kuid õnneks oskab mu poiss-sõber bash'iga ja paljude teiste asjadega väga hästi hakkama. Ta aitas mul selle skripti kirjutada.

Nii et skripti esimene osa on pildi saatmine Docker Hub'i. See on üsna lihtne. Kasutatud sildistamisstrateegia eeldab git-hashi ja git-sildi (kui see eksisteerib) kombinatsiooni. See tagab ainulaadse sildi loomise ja lihtsustab sellise versiooni tuvastamist, millel see põhineb. DOCKER_USERNAME ja DOCKER_PASSWORD — need on kasutaja keskkonnamuutujad, mille saab seadistada Travis CI liidese abil. Travis CI töötleb automaatselt tundlikke andmeid, et need ei satuks valedesse kätesse.

See on skripti 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}

Kuidas näeb välja skripti teine osa, sõltub täielikult sellest, millist hosti te kasutate ja kuidas ühendus on korraldatud. Minu juhtumil, kuna kasutan Digital Ocean'i, kasutatakse serverisse ühendamiseks käske doctl. AWS-i kasutamisel kasutatakse utiliiti aws, ja nii edasi.

Serveri seadistamine ei olnud eriti keeruline. Nii et seadistasin dropleti, mis põhineb põhijoonisel. Tuleb märkida, et valitud süsteem nõuab Docker'i ühekordset käsitsi installimist ja ühekordset käsitsi käivitamist. Docker'i installimiseks kasutasin Ubuntu 18.04, seega kui ka teie kasutate Ubuntu, et teha sama, võite lihtsalt järgida sellele lihtsat juhendit.

Ma ei räägi siin teenuse konkreetsetest käskudest, kuna see aspekt võib erinevates olukordades tugevalt varieeruda. Toon vaid välja üldise tegevuskava, mis toimub pärast SSH-ga serverisse sisselogimist, kuhu projekt arendatakse:

Peate leidma konteineri, mis praegu töötab, ja peatama selle.
Seejärel peate taustal käivitama uue konteineri.
Teil on vaja seadistada serveri kohalik ports väärtuseks 80 — see võimaldab siseneda saidile aadressil example.com, ilma porti näitamata, ja mitte kasutada aadressi nagu example.com:5000.
Ja lõpuks peate eemaldama kõik vanad konteinerid ja pildid.

Siin on skripti 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 tasub tähelepanu pöörata

Võib-olla, kui logite serverisse SSH kaudu Travis CI-st, näete hoiatust, mis takistab installimist, kuna süsteem ootab kasutaja reaktsiooni.

Hosti autentimine '<hostname> (<IP address>)' ei saa olla kindlaks tehtud.
RSA võtme sõrmejälg on <key fingerprint>.
Kas soovite tõepoolest jätkata ühenduse loomist (jah/ei)?

Ma sain teada, et stringi võtme saab kodeerida base64 formaati, et salvestada see selliselt, mille abil on mugav ja usaldusväärne töötada. Installimise etapis on võimalik avalik võti dekodeerida ja salvestada see faili known_hosts et vabaneda ülaltoodud veast.

echo <public key> | base64 # väljastab <avalik võtme, kodeeritud base64 vormingus>

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

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

Ning see on see, mida see väljastab — string base64-kodeeringus:

123.45.67.89 ssh-rsa AABAB3NzaC1yc2EAAABBAklwAAQEAlkOUpkDHehrF17SbrmTipNLTGL9Tjmo/BWDUSU/GPl+nazlsHDTWY7hdI4la5ew18JH4KW9jYbhFRvqiVzM7xlELVVm4h9lFX5QkbPpSwg0cdaM3PBy7k9OdJ/MTyBlWXFCR+HBo3FXRitBxiX1NfXpHqHahpHqAqO1dNFQK5HGdB0W1AqwrLUx6HnaYFlXiUQv0/TgDXJXqdDmsXlkBxxSVWz9PzqA2e8sK3E3zFaoJoAscM1R9x5k9GjFCsg2Z1bA9W+QffDOVZm2Ja8L88B6p0tutMbA== user@example.com

Siin on eelnevalt mainitud käsk.

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

Sama lähenemist saab kasutada ka privaatvõtmega ühenduse loomisel, kuna teil võib serverisse sisenemiseks olla vajalik privaatvõti. Võtmega töötades peate vaid tagama selle ohutu hoidmise Travis CI keskkonna muutuja sees ning et see ei kuvata kuskil.

Veel üks asi, millele tähelepanu pöörata, on see, et võite vajada kogu deploy skripti käivitamist ühes reas, näiteks — kasutades doctl. See võib nõuda mõningaid lisapingutusi.

doctl compute ssh  --ssh-command "kõik käsklused on siin && siin"

TLS/SSL ja koormuse jaotamine

Pärast seda, kui ma tegin kõik eelnevalt mainitu, oli viimane probleem, millega ma silmitsi seisin, see, et serveril ei olnud SSL-i. Kuna kasutan Node.js-serverit, et sundida töötamist Nginx tagapoolt ja Let’s Encrypt'i, tuleb natuke vaeva näha.

Ma ei tahtnud kõiki neid SSL-i seadeid käsitsi teha, seega lõin lihtsalt koormusejaoturi ja registreerisin selle andmed DNS-is. Näiteks DigitalOcean'i puhul on pidevalt uueneva iseallkirjastatud sertifikaadi loomine koormusejaoturis lihtne, tasuta ja kiire protsess. Selle lähenemisega on veel üks lisahüve, et see võimaldab väga lihtsalt seadistada SSL-i paljudele serveritele, mis töötavad koormusejaoturi taga. See võimaldab serveritel mitte "muretseda" SSL-i üle, kuid kasutada siiski tavapäraselt porti 80. Seega on SSL-i seadistamine koormusejaoturi peal palju lihtsam ja mugavam kui alternatiivsed SSL-i seadistamise meetodid.

Nüüd saab serveris sulgeda kõik sissetulevad ühendused aktsepteerivad portid — välja arvatud port 80, mida kasutatakse koormusejaoturiga suhtlemiseks ning port 22 SSH jaoks. Seetõttu ebaõnnestub otsene ühendus serveriga mistahes sadamate kaudu, välja arvatud need kaks.

Summary

Pärast kõike, mida ma selles materjalis rääkisin, ei hirmutanud mind enam ei Docker platvorm ega automatiseeritud CI/CD kontseptsioonid. Suutsin seadistada pideva integreerimise ahela, mille käigus testitakse koodi enne selle tootmisesse jõudmist ja koodi automaatset juurutamist serveris. Kõik see on mulle endiselt suhteliselt uus ning olen kindel, et on viise, kuidas oma automatiseeritud töövoogu parandada ja efektiivsemaks muuta. Seetõttu, kui teil on selles osas ideid - andke mulle teada. Loodan, et see artikkel aitas teil teie asjades. Loodan, et pärast selle lugemist õppisite sama palju, kui mina õppisin, kui uurisin kõike, millest siin räägin.

P.S. Meie turul on olemas pilt Docker, mis installitakse ühe klikiga. Saate kontrollida konteinerite toimimist VPS. Kõigile uutele klientidele antakse tasuta 3 päeva testimise jaoks.

Lugupeetud lugejad! Kasutate oma projektides CI/CD tehnoloogiaid?

Allikas: habr.com