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

Ma kirjutasin oma esimesed veebilehed 90ndate lõpus. Siis oli neid käivitada väga lihtne. Üks Apache-server mõnel jagatud hostimisel, sellele serverile sai sisse logida FTP kaudu, kirjutades brauserisse midagi sellist nagu ftp://ftp.example.com. Siis tuli sisestada nimi ja parool ning laadida failid serverisse. Need olid teised ajad, kõik oli siis lihtsam kui praegu.

Viimase kahekümne aasta jooksul on palju muutunud. Veebilehed on keerukamaks läinud, neid tuleb enne tootmisse saatmist koguda. Üksik server on muutunud paljususeks serveriteks, mis töötavad koormuse tasakaalustajate taga, ja versioonihaldussüsteemide kasutamine on saanud tavaliseks.

Minu isikliku projekti jaoks oli mul eriline konfiguratsioon. Ja ma teadsin, et mul on vaja võimalust saata veebilehte tootmisse, tehes ainult ühe toimingu: koodi salvestamine harusse. master GitHubis. Ma teadsin ka, et minu väikeses veebirakenduses töö tagamiseks ei soovi ma hallata suurt Kubernetes'i klastrit, kasutada Docker Swarmi tehnoloogiat või hoida serverite parki koos podide, agentide ja muude keerukustega. Töö maksimaalse lihtsuse saavutamiseks pidin tutvuma CI/CD-ga.

Kui teil on väike projekt (antud juhul Node.js projekt) ja soovite teada, kuidas automatiseerida selle projekti juurutamist, tehes nii, et lähtekood, mis on hoidlas, vastaks täpselt sellele, mis töötab tootmises, siis arvan, et see artikkel võib teid huvitada.

Eeltingimused

Oodatakse, et selle artikli lugejal on põhiteadmised käsurea kasutamisest ja Bash-skriptide kirjutamisest. Tal on samuti vajalikud kontod. Travis CI ja Docker Hub.

Eesmärgid

Ma ei ütle, et see artikkel võiks üldiselt kandideerida "õppejuhiste" tiitlile. See on pigem dokument, milles ma räägin sellest, mida olen õppinud, ja kirjeldan enda poolt aktsepteeritavat koodi testimise ja juurutamise protsessi tootmises, mis toimub ühe automatiseeritud etapi käigus.

Selliseks kujunes minu tööprotsess.

Koodi, mis saadetakse mistahes repositooriumi harusse peale master, teostatakse järgmised toimingud:

Projekti ehitamine Travis CI-s.
Teostatakse kõik moodulitestid, integratsioonitestid ja risttestid.

Ainult koodi, mis jõuab master, puhul teostatakse järgmist:

Kõik eeltoodud, pluss…
Dockeri pildi koostamine, lähtudes praegusest koodist, seadistustest ja keskkonnast.
Pildi paigutamine Docker Hub-i.
Ühendamine tootmiserveriga.
Pildi allalaadimine Docker Hub-ist serverisse.
Praeguse konteineri peatamine ja uue käivitamine, mis põhineb uuel pildil.

Kui te ei tea Dockerist, piltidest ja konteineritest mitte midagi — ärge muretsege. Ma räägin sellest kõik.

Mis on CI/CD?

CI/CD lühend tähistab „continuous integration/continuous deployment“ – „katkestamata integratsioon/katkestamata juurutamine“.

▍Katkestamata integratsioon

Katkestamata integratsioon on protsess, mille käigus arendajad teevad muudatusi projekti peamises koodihaldusmaterjalis (tavaliselt haru master). Selle käigus tagatakse koodi kvaliteet automaatsete testide kaudu.

▍Katkestamata juurutamine

Katkestamata juurutamine on koodi sagedane automaatne juurutamine tootmises. CI/CD lühendi teine osa lahti seletatakse mõnikord kui „continuous delivery“ („katkestamata kohaletoimetamine“). See tähendab üldiselt sama, mis „katkestamata juurutamine“, kuid „katkestamata kohaletoimetamine“ eeldab käsitsi kinnitust muudatuste tegemiseks enne projekti juurutamise protsessi käivitamist.

Alustamine

Rakendus, milles ma seda kõike õppisin, nimetatakse TakeNote. See on veebiprojekt, mille kallal ma töötan, et teha märkmeid. Alguses püüdsin ma luua JAMStack- projekt või lihtsalt frontend-rakendus ilma serverita, et kasutada standardseid hostimise ja projektide juurutamise võimalusi, mida pakub Netlify. Kui rakenduse keerukus kasvas, pidin looma selle serveripoolse osa, mis tähendas, et mul oleks vaja välja töötada oma strateegia automatiseeritud integreerimise ja rakenduse automatiseeritud juurutamise jaoks.

Minu puhul on rakendus Express-server, mis töötab Node.js keskkonnas, teenindades ühesõnalist React-rakendust ja toetades turvalist serveripoolset API-d. See arhitektuur järgib strateegiat, mida võib leida sellest täiendavast füllstack-i autentimise juhendist.

Konsulteerisin sõbraga, kes on automatiseerimise ekspert, ja küsisin temalt, mida peaksin tegema, et kõik toimiks nii, nagu ma soovin. Ta viskas mulle idee, kuidas peaks välja nägema automatiseeritud tööprotsess, nagu on kirjeldatud käesoleva artikli jaotises "Eesmärgid". See, et seadsin endale sarnased eesmärgid, tähendas, et pean õppima, kuidas Dockerit kasutada.

Docker

Docker on tööriist, mis konteineritehnoloogia abil võimaldab lihtsasti rakendusi jagada ning neid sama keskkonna sees juurutada ja käivitada, isegi kui Docker ise töötab erinevates keskkondades. Alustamiseks pidin hankima endale Docker CLI (komandirealise liidese) tööriistad. Juhend Docker installimiseks ei saa nimetada väga selgeks ja arusaadavaks, kuid sellest saab teada, et esimese sammu tegemiseks tuleb alla laadida Docker Desktop (Maci või Windowsi jaoks).

Docker Hub on umbes nagu GitHub git-repositooriumide jaoks või register npm JavaScripti pakettide jaoks. See on veebirepositoorium Docker-piltide jaoks. Just selle kaudu ühendub Docker Desktop.

Nii et Dockeriga alustamiseks on vaja teha kaks asja:

Installige Docker Desktop.
Registreeruge Docker Hub.

Seejärel saate kontrollida Docker CLI toimimist, käivitades järgmise käsu Docker'i versiooni kontrollimiseks:

docker -v

Seejärel logige sisse Docker Hub'i, sisestades, kui teilt küsitakse, oma kasutajanime ja parooli:

docker login

Dockerit kasutamiseks peate mõistma piltide ja konteinerite kontseptsioone.

▍Pildid

Pilt on nagu plaan, mis sisaldab juhiseid konteineri kokkupanemiseks. See on muutumatu failisüsteemi ja rakenduse seadete snapshot. Arendajad saavad hõlpsasti pilte vahetada.

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

See käsk väljastab tabeli järgmise pealkirjaga:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

Jätkame mõne käskluse näidete uurimist samas formaadis — esmalt on käsk koos kommentaariga ja seejärel on näide, mida see võib välja anda.

▍Konteinerid

Konteiner on teadetav pakett, mis sisaldab kõike, mis vajalik rakenduse käitamiseks. Selle lähenemisega töötab rakendus alati sama sõltumata infrastruktuurist: eraldatud 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 näitaja konkreetse pildi versioonile.

▍Docker'i käskude lühike ülevaade

Siin on ülevaade mõnest sageli kasutatavast Docker'i käskudest.

Meeskond

Kontekst

Tegevus

docker build

Pilt

Pildi koostamine Dockerfile'ist

docker tag

Pilt

Pildi sildistamine

docker images

Pilt

Piltide loendi väljastamine

docker run

Konteiner

Konteineri käivitamine pildi põhjal

docker push

Pilt

Pildi saatmine registrisse

docker pull

Pilt

Pildi allalaadimine registrist

docker ps

Konteiner

Konteinerite loendi väljastamine

docker system prune

Pilt/Konteiner

Kasutamata konteinide ja piltide eemaldamine

▍Dockerfile

Ma tean, kuidas kohalikult rakendust produtsiooniks käivitada. Mul on Webpack-i konfiguratsioon, mis on mõeldud valmis React-rakenduse koostamiseks. Edasi on mul käsk, mis käivitab Node.js-põhise serveri porti 5000. See näeb välja nii:

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

Oluline on märkida, et mul ei ole selle materjali jaoks näidisrakendust. Kuid siia sobib katsetamiseks ükskõik milline lihtne Node-rakendus.

Konteineri kasutamiseks peate andma Dockerile juhised. Seda tehakse faili kaudu, mida nimetatakse Dockerfile, mis asub projekti põhikaustas. See fail näib alguses üsna arusaamatu.

Kuid see, mis seal on, kirjeldab lihtsalt eriliste käsudega midagi, mis sarnaneb töökeskkonna seadistamisega. Siin on mõned neist käskudest:

FROM — See käsk käivitab faili. Selles määratakse aluskuju, mille põhjal konteiner ehitatakse.
COPY — Failide kopeerimine kohaliku allika ja konteineri vahel.
WORKDIR — Töökatalooge seadmine järgmiste käsu jaoks.
RUN — Käskude käivitamine.
EXPOSE — Porti seadmine.
ENTRYPOINT — Teostatava käsu määramine.

Dockerfile võib 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

Valitud põhja põhjal võib osutuda vajalikuks installida täiendavaid sõltuvusi. Mõned põhjad (nagu Node Alpine Linux) on loodud võimalikult kompaktseks. Tulemuseks võib olla, et neis puuduvad mõned programmid, mida te ootate.

▍Konteineri ehitamine, sildistamine ja käivitamine

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

▍Ehitamine

Esimese sammuna tuleb ehitada pildi, määrates nime ja, mitte kohustuslikult, sildi (kui sild ei ole määratud, määrab süsteem automaatselt pildile sildi latest).

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

Selle käsu täitmisel saab jälgida, kuidas Docker ehitab pilti.

Saadan ehituskonteksti Docker daemonile   2.88MB
Samm 1/9 : FROM node:12-alpine
 ---> ...ehitusetapid on käimas...
Ehitamine õnnestus 123456789123
Ehitamine sildistatud <image>:<tag>

Ehitamine võib võtta paar minutit — see sõltub sellest, kui palju sõltuvusi teil on. Pärast ehitamise lõpetamist saate käivitada käsu docker images ja vaadata oma uue pildi kirjeldust.

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

▍Käivitamine

Pilt on loodud. See tähendab, et selle alusel saab konteineri käivitada. Kuna soovin, et mul oleks juurdepääs konteineris töölevale rakendusele aadressilt localhost:5000, siis määrasin vasakul paaris 5000:5000 järgmises käsus 5000. Paremal on konteineri port.

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

Nüüd, kui konteiner on loodud ja käivitatud, saab kasutada käsku docker ps konteineri ülevaate vaatamiseks (või võib kasutada käsku docker ps -a, mis kuvab teavet kõigi konteiners, mitte ainult töötavate kohta).

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

Kui minna nüüd aadressile localhost:5000 — saab näha töötava rakenduse lehte, mis näeb välja täpselt sama nagu tootmisümpärves töötava rakenduse leht.

▍Sildi määramine ja avaldamine

Ettevalmistatakse, et kasutada ühte loodud pilti tootmisserveris, peab meil olema võimalus laadida see pilt Docker Hubist. See tähendab, et kõigepealt tuleb luua Docker Hubis projekti jaoks hoidla. Pärast seda on meil koht, kuhu pilt saata. Pilt tuleb nimetada nii, et selle nimi algab meie kasutajanimega Docker Hubis. Peale seda tuleb hoidla nimi. Nime lõpus võib olla mis tahes silt. Allpool on näidatud näide piltide nimetamisest selle skeemi järgi.

Nüüd saame luua pildi, andes talle uue nime ja kasutades käsku docker push selle saatmiseks Docker Hubi hoidlasse.

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

# Praktiliselt võib 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 hästi, on pilt saadaval Docker Hubis ja selle saab lihtsalt laadida serverisse või edastada teistele arendajatele.

Järgmised sammud

Käesolevaks ajaks oleme veendunud, et rakendus Docker-konteinerina töötab kohapeal. Oleme konteineri üles laadinud Docker Hubi. See kõik tähendab, et oleme juba väga hästi eesmärgi poole edenenud. Nüüd tuleb lahendada veel kaks küsimust:

CI-tööriista seadistamine koodi testimiseks ja juurutamiseks.
Tootmiserveri seadistamine nii, et see saaks meie koodi laadida ja käivitada.

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

Tuleb märkida, et siin on võimalik kasutada ka teisi teenuste kombinatsioone. Näiteks Travis CI asemel võib kasutada CircleCI või Github Actions. Ja DigitalOcean'i asemel — AWS või Linode.

Otsustasime töötada Travis CI-ga, ja selles teenuses on mul juba mõned seadistused olemas. Seega räägin nüüd lühidalt, kuidas seda tööks ette valmistada.

Travis CI

Travis CI on tööriist koodi testimiseks ja juurutamiseks. Ei olnud soovist minna süvitsi Travis CI seadistamise nüanssidega, kuna iga projekt on ainulaadne ja see ei too erilist kasu. Kuid räägin põhialustest, mis võimaldavad teil alustada, kui otsustate kasutada Travis CI-d. Ükskõik, kas valite Travis CI, CircleCI, Jenkins või midagi muud, kasutatakse sarnaseid seadistusmeetodeid.

Kuna alustada Travis CI kasutamist, minge aadressile projekti veebilehe ja looge konto. Seejärel integreerige Travis CI oma GitHubi kontoga. Seadistamise käigus peate näitama repositooriumi, millega soovite automatiseeritud tööd teha, ning andma sellele juurdepääsu. (Kasutades GitHubi, kuid olen kindel, et Travis CI saab integreeruda ka BitBucketi, GitLabi ja teiste sarnaste teenustega).

Iga kord, kui Travis CI alustab tööd, käivitub server, mis täidab konfiguratsioonifailis määratud käske, sealhulgas vastavate harude repositooriumi juurutamist.

▍Ülesande elutsükkel

Travis CI konfiguratsioonifail, mida nimetatakse .travis.yml ja ja hoitav, mis asub projekti juurkaustas, toetab sündmuste kontseptsiooni eluring ülesanne. Siin on need sündmused, esitatud järjekorras, milles need juhtuvad:

apt lisandmoodulid
vahemälu komponendid
enne_installeerimist
install
before_script
script
enne_vahemälu
pärast_õnnestumist või pärast_ebaõnnestumist
enne_deployimist
deploy
pärast_deployimist
pärast_skripti

▍Testimine

Konfiguratsioonifailis kavatsen seadistada kohaliku Travis CI serveri. Keeleks valisin Node 12 versiooni ja näitasin süsteemile, et see peab installima sõltuvused, mis on vajalikud Docker'i kasutamiseks.

Kõik, mis on loetletud .travis.yml, käivitatakse kõikide pull-päringute puhul kõigis ladude harudes, välja arvatud juhul, kui on määratud teisiti. See on kasulik omadus, kuna see tähendab, et saame testida kogu koodi, mis laekub ladudele. See aitab teada, kas kood on valmis haru kirjutamiseks master, ja ei riku projekti ehitamise protsessi. Selles globaalsetes seadistustes installin kõik kohalikult, käivitan Webpack arendaja serveri taustal (see on minu tööprotsessi spetsiifika) ja sooritan testid.

Kui soovite, et teie ladudes kuvataks koodi katte teabe ikoone, siin võite leida lühikese juhendi Jest'i, Travis CI ja Coveralls'i kasutamiseks nende andmete kogumiseks ja esitamiseks.

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 kõik tegevused, mida täidetakse kõigi hoidla harude ja pull-küsimuste jaoks.

▍Deployment

Eeldades, et kõik automatiseeritud testid on edukalt lõpetatud, saame vajadusel koodi tootmisse serverisse edastada. Kuna soovime seda teha ainult haru koodiga master, anname süsteemile vastavad juhised paigaldamise seadetes. Enne kui proovite oma projektis koodi, millest edasi räägime, sooviksin teid hoiatada, et teil peab olema reaalne skript, mida kasutatakse paigaldamiseks.

deploy:
  # Koguda Docker konteiner ja saata see Docker Hub'isse
  provider: script
  script: bash deploy.sh
  on:
    branch: master

Paigaldusskript täidab kahte ülesannet:

Konteineri koostamine, sildistamine ja saatmine Docker Hub'i CI-tööriista (meie puhul Travis CI) abil.
Pildi laadimine serverisse, vana konteineri peatamine ja uue käivitamine (meie puhul töötab server DigitalOcean'i platvormil).

Esiteks tuleb seadistada automaatne build'i, märgistamise ja pildi saatmise protsess Docker Hub'i. Kõik see sarnaneb väga sellele, mida oleme juba käsitsi teinud, välja arvatud see, et siin on meil vaja strateegiat, kuidas määrata piltidele unikaalsed märgid ja automatiseerida sisselogimist. Mul olid mõned probleemid deploy skripti detailidega, nagu märgistamisstrateegia, sisselogimine, SSH võtmete kodeerimine, SSH ühenduse loomine. Õnneks on mu poiss-sõber bashiga väga osav, nagu ka paljude muude asjadega. Ta aitas mul selle skripti kirjutada.

Nii et skripti esimene osa — see on pildi saatmine Docker Hub'i. Seda on suhteliselt lihtne teha. Minu kasutatud märgistusmeetod põhineb git-hash'i ja git-märgise, kui see eksisteerib, kombineerimisel. See tagab unikaalse märgi loomise ja lihtsustab build'i tuvastamist, millele see põhineb. DOCKER_USERNAME ja DOCKER_PASSWORD — need on kasutaja keskkonnamuutujad, mille saab seada Travis CI liidese kaudu. Travis CI käsitleb automaatselt salajasi andmeid nii, et need ei satuks valedesse kätesse.

Siin 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}

Teise osa skripti sisu sõltub täielikult sellest, millist hostimist kasutate ja kuidas sellele on ühendus korraldatud. Minu puhul kasutan ma Digital Ocean'i, kus serveriga ühendamiseks kasutatakse käske doctl. AWS-i puhul kasutatakse tööriista aws, ja nii edasi.

Serveri seadistamine ei olnud eriti keeruline. Nii sättisin ma dropleti, mis põhines põhiversioonil. Tuleb märkida, et valitud süsteem vajab Docker'i ühekordset käsitsi installimist ja Docker'i ühekordset käsitsi käivitamist. Mina kasutasin Docker'i installimiseks Ubuntu 18.04, seega kui kasutate samuti Ubuntu't, võite lihtsalt järgida seda lihtsat juhendit.

Ma ei räägi siin konkreetsetest käskudest teenusele, kuna see aspekt võib erinevatel juhtudel olla väga erinev. Toon lihtsalt välja üldise tegevuskava, mis tuleb läbi viia pärast SSH kaudu serverisse ühendamist, kus projekt käivitatakse:

Peate leidma konteineri, mis praegu töötab, ja peatama selle.
Seejärel peate taustal käivitama uue konteineri.
Kohalik serveri port tuleb seada väärtusele 80 — see võimaldab pääseda veebisaidile aadressil example.com, ilma pordi määramiseta, mitte kasutades aadressi nagu example.com:5000.
Ja lõpuks tuleb eemaldada 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 juhtuda, et kui ühendate end serveriga SSH kaudu Travis CI-st, näete hoiatust, mis takistab paigaldamise jätkamist, kuna süsteem ootab kasutaja reaktsiooni.

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

Olen teada saanud, et stringi võtme saab kodeerida base64 formaati, et salvestada see sellisel viisil, millega on mugav ja usaldusväärne töötada. Installimise etapis saab avaliku võtme dekodeerida ja salvestada faili known_hosts et vabaneda eeltoodud veast.

echo  | base64 # väljastab .

Tavas praktikas võib see käsk välja näha selline:

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

Nii on, kuidas see välja näeb — rida base64-koodis:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2punMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Siin on käsk, millest varem räägiti

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

Sama lähenemist võib kasutada ka privaatvõtme puhul ühenduse loomisel, kuna serverisse pääsemiseks võib teil olla vajalik privaatvõti. Töö käigus võtmega tuleb lihtsalt kindlustada selle turvaline hoidmine Travis CI keskkonnamuutujas ning et see ei väljenduks kunagi.

Veel üks asi, millele tasub tähelepanu pöörata, on see, et peate võib-olla käivitama kogu juurutusskripti, esitatuna ühes reas, näiteks — kasutades doctl. See võib nõuda mõningaid täiendavaid jõupingutusi.

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

TLS/SSL ja koormuse tasakaalustamine

Pärast seda, kui ma tegin kõike eelnevat, oli viimane probleem, millega ma silmitsi seisn, see, et serveril puudus SSL. Kuna kasutan Node.js serverit, et lasta töötada Nginxi pöördproksil ja Let’s Encrypt'il on vaja palju vaeva näha.

Ma ei soovinud neid SSL-seadeid käsitsi teha, seetõttu lõin lihtsalt koormustasakaidaja ja salvestasin selle andmed DNS-i. Näiteks DigitalOceanis on automaatselt uueneva isesigneeritud sertifikaadi loomine koormustasakaidajal lihtne, tasuta ja kiire protseduur. Selle lähenemise eeliste hulka kuulub ka asjaolu, et see võimaldab vajadusel väga lihtsalt seadistada SSL-i paljudele serveritele, mis töötavad koormustasakaidja taga. See tähendab, et serverid ei pea SSL-i osas üldse „muretsema”, kuid võivad siiski kasutada porti tavapäraselt. 80Nii et SSL-i seadistamine koormustasakaidjal on tunduvalt lihtsam ja mugavam kui alternatiivsed SSL-i seadistamise meetodid.

Nüüd saab serveris sulgeda kõik sisenevaid ühendusi aktsepteerivad pordid — välja arvatud port 80, mida kasutatakse koormustasakaidjaga suhtlemiseks, ja port 22 SSH jaoks. Seetõttu ebaõnnestub otse serverisse pöördumine mistahes pordile, välja arvatud need kaks.

Kokkuvõte

Pärast seda, kui olin teinud kõike, millest selles materjalis rääkisin, ei häirinud mind enam ei platvorm Docker ega automatiseeritud CI/CD ahelate kontseptsioonid. Olin suutnud seadistada pideva integreerimise ahela, mille käigus testitakse koodi enne selle jõudmist tootmisse ja toimub automaatne koodi juurutamine serverisse. See kõik on minu jaoks veel suhteliselt uus ja olen kindel, et on olemas viise, kuidas oma automatiseeritud tööprotsessi parandada ja efektiivsemaks muuta. Seetõttu, kui teil on selle kohta ideid — andke mulle teada. Loodan, et see artikkel aitas teid teie tegemistes. Soovin uskuda, et lugedes sellest, õppisite te sama palju, kui mina, kui sellega tegelema hakkasin.

P.S. Meie turul on olemas pilt Docker, mis installitakse ühe klõpsuga. Saate kontrollida konteinerite tööd VPS. Kõigile uutele klientidele antakse tasuta 3 päeva katsetamiseks.

Lugupidamisega lugejad! Kasutate tehnoloogiaid CI/CD oma projektides?

Allikas: habr.com