Krijimi i një zinxhiri CI/CD dhe automatizimi i punës me Docker

Unë dozha faqet e mia të para në fund të viteve '90. Atëherë ishte shumë e thjeshtë t'i bënim ato funksionale. Kishim një server Apache në ndonjë host të zakonshëm, ku mund të lidhesha përmes FTP-së, duke shkruar në shiritin e shfletuesit diçka si ftp://ftp.example.com. Pastaj duhej të tregoheshin emri dhe fjalëkalimi për të ngarkuar skedaret në server. Ishin kohë të tjera, gjithçka ishte më e thjeshtë se tani.

Gjatë dy dekadave që nga ajo kohë, gjithçka ka ndryshuar dukshëm. Faqet janë bërë më komplekse, duhet të mblidhen para se të dalin në prodhim. Një server i vetëm është bërë një shumëllojshmëri serverash, që punojnë nën balancuesit e ngarkesës, dhe përdorimi i sistemeve të kontrollit të versioneve është bërë diçka e zakonshme.

Për projektin tim personal, unë kisha një konfigurim të veçantë. Dhe e dija se më nevojitej mundësia për të çelur faqen në prodhim, duke kryer vetëm një veprim: shënimin e kodit në një degë. master në GitHub. Unë gjithashtu dija se për të siguruar funksionimin e aplikacionit tim të vogël në web, nuk doja të merresha me menaxhimin e një klasteri të madh Kubernetes, ose të përdorja teknologjinë Docker Swarm, ose të mbaja një парк serverash me pod-e, agjentë dhe kompleksitete të tjera. Për të arritur qëllimin e maksimalizimit të thjeshtësisë së punës, më duhej të njihem me CI/CD.

Nëse keni një projekt të vogël (në këtë rast flasim për një projekt Node.js) dhe dëshironi të mësoni se si të automatizoni shpërndarjen e këtij projekti, duke siguruar që ajo që ruhet në repository të përputhet saktësisht me atë që punon në prodhim, besoj se ky artikull mund t'ju interesojë.

Kërkesat paraprake

Pritet që lexuesi i këtij artikulli të ketë njohuri bazike në përdorimin e komandave në terminal dhe në shkruarjen e skripteve Bash. Për më tepër, do t'i nevojiten llogari Travis CI dhe Docker Hub.

Qëllimet

Nuk do të them se ky artikull mund të quhet pa marrë parasysh 'udhëzimi mësimor'. Ky është më shumë një dokument ku tregoj atë që kam mësuar dhe përshkruaj procesin e testimit dhe implementimit të kodit në prodhim që i bëhet në një kalim të automatizuar.

Këtu është si u formua procesi im i punës.

Për kodin që dërgohet në çdo degë të repositorit, përveç master, bëhen këto veprime:

• Niset ndërtimi i projektit në Travis CI.
• Kryhen të gjitha testet modulare, integruese dhe end-to-end.

Vetëm për kodin që arrin në master, kryhet e siguiente:

• Të gjitha ato që janë thënë më sipër, plus...
• Ndërtohet imazhi Docker me kodin aktual, konfigurimet dhe ambientin.
• Postohet imazhi në Docker Hub.
• Konektimi me serverin e prodhimit.
• Ngarkohet imazhi nga Docker Hub në server.
• Ndalohet kontejneri aktual dhe nisett një i ri, bazuar në imazhin e ri.

Nëse nuk dini asgjë për Docker, për imazhet dhe kontejnerët — mos u shqetësoni. Unë do t'ju tregoj gjithçka rreth kësaj.

Çfarë është CI/CD?

Acroni CI/CD qëndron për "integrim të vazhdueshëm/zhvillim të vazhdueshëm".

▍Integrimi i vazhdueshëm

Integrimi i vazhdueshëm është një proces ku zhvilluesit bëjnë komitete në depo kryesore të kodit burimor të projektit (zakonisht në një degë master). Cilësia e kodit sigurohet përmes testimit automatizuar.

▍Zhvillimi i vazhdueshëm

Zhvillimi i vazhdueshëm është një shpërndarje të shpeshtë automatizuar të kodit në prodhim. Pjesa e dytë e akronimit CI/CD ndonjëherë shpjegohet si "dërgimi i vazhdueshëm". Kjo, në përgjithësi, është e njëjta gjë si "zhvillimi i vazhdueshëm", por "dërgimi i vazhdueshëm" nënkupton nevojën për konfirmimin manual të ndryshimeve përpara se të fillojë procesi i shpërndarjes së projektit.

Fillimi i punës

Aplikacioni mbi të cilin po e mësoj këtë është TakeNote. Ky është një projekt web-i mbi të cilin po punoj, i destinuar për të bërë shënime. Fillimisht, përpiqesha të bëja JAMStack-projekt, ose vetëm një aplikacion frontend pa server, për të shfrytëzuar mundësitë standarde për hostimin dhe dislokimin e projekteve që ofron Netlify. Me rritjen e kompleksitetit të aplikacionit, më nevojitej të krijoja gjithashtu pjesën e serverit, dhe kjo do të thoshte se do të duhej të formuloja një strategji të vetën për integrimin e automatizuar dhe dislokimin automatizuar të projektit.

Në rastin tim, aplikacioni përbëhet nga një server Express, që funksionon në ambientin Node.js, që shërben një aplikacion React me një faqe dhe mbështet një API të mbrojtur serveri. Kjo arkitekturë ndjek një strategji që mund të gjendet në këtë udhëzues për autentifikimin fullstack.

Unë konsultova me një tjetër, i cili është ekspert në automatizim, dhe e pyeta se çfarë duhet të bëja për ta bërë gjithçka të funksionojë ashtu siç më nevojitej. Ai më dha një ide se si duhet të dukej procesi i automatizuar i punës, i përshkruar në seksionin ‘Qëllimet’ të këtij artikulli. Ajo që vendosa përpara vetes si qëllime të tilla, do të thoshte se duhej të kuptoja se si të përdorja Docker.

Docker

Docker — është një mjet që, falë teknologjisë së kontejnerizimit, lejon shpërndarjen e lehtë të aplikacioneve dhe gjithashtu mundësinë e instalimit dhe funksionimit të tyre në të njëjtin mjedis, përveç nëse vetë platforma Docker punon në mjedise të ndryshme. Për të filluar, më nevojitej të siguroja mjetet e komandës (CLI) të Docker. Udhëzimi për instalimin e Docker-it nuk mund të quhet shumë i saktë dhe i kuptueshëm, por nga ai mund të mësohet se për të bërë hapin e parë të instalimit, është e nevojshme të shkarkohet Docker Desktop (për Mac ose Windows).

Docker Hub — është ngjashëm si GitHub për repozitat git, ose regjistri npm për paketat JavaScript. Ky është një repozit online për imazhet Docker. Kështu lidhet Docker Desktop.

Pra, për të filluar punën me Docker, nevojiten dy gjëra:

• Instaloni Docker Desktop.
• Regjistrohuni në Docker Hub.

Pas kësaj, mund të kontrolloni funksionimin e Docker CLI duke ekzekutuar komandën e mëposhtme për të kontrolluar versionin e Docker:

docker -v

Pastaj, hyni në Docker Hub, duke futur, kur t'ju kërkohet, emrin tuaj të përdoruesit dhe fjalëkalimin:

docker login

Për të përdorur Docker, duhet të kuptoni konceptet e imazheve dhe kontejnerëve.

▍Imazhet

Një imazh është diçka si një plan, që përmban udhëzime për ndërtimin e një kontenieri. Ai është një snapshots i pandryshueshëm i sistemit të skedarëve dhe konfigurimeve të aplikacionit. Zhvilluesit mund të shkëmbejnë lehtësisht imazhe.

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

Ky komandë do të shfaqë një tabelë me titullin si më poshtë:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

Më pas do të shohim disa shembuj të komandave në këtë format — së pari shfaqet komanda me koment, e më pas një shembull se çfarë ajo mund të japë si rezultat.

▍Kontenierët

Konteneri është një paketë ekzekutivë që përmban gjithçka që nevojitet për të ekzekutuar aplikacionin. Aplikacioni në këtë qasje do të funksionojë gjithmonë njësoj, pavarësisht nga infrastruktura: në një mjedis të izoluar dhe në të njëjtin ambient. Kjo do të thotë se në mjedise të ndryshme, ekzekutimet e imazhit të njëjtë janë të mundshme.

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

▍Etiketat

Etiketa është një tregues për një version të veçantë të imazhit.

▍Këshilla e shkurtër për komandat Docker

Ja një përmbledhje e disa komandave të përdorura shpesh në Docker.

Ekipa

Konteksti

Veprimi

docker build

Imazhi

Ndërtimi i një imazhi nga Dockerfile

docker tag

Imazhi

Etiketimi i imazhit

docker images

Imazhi

Shfaqja e listës së imazheve

docker run

Kontejner

Ekzekutimi i kontenierit në bazë të imazhit

docker push

Imazhi

Dërgimi i imazhit në regjistrin

docker pull

Imazhi

Ngarkimi i imazhit nga regjistri

docker ps

Kontejner

Shfaqja e listës së kontejnerëve

docker system prune

Imazh/Kontejner

Fshirja e kontejnerëve dhe imazheve të pavaruara

▍Skedari Dockerfile

E di si të nis një aplikacion për prodhim lokal. Kam një konfigurim Webpack, i cili është menduar për ndërtimin e një aplikacioni të gatshëm React. Më pas, kam një komandë që nis një server, i bazuar në Node.js, në portin 5000. Kjo duket kështu:

npm i         # instalimi i varësive
npm run build # ndërtimi i aplikacionit React
npm run start # nisja e serverit Node

Duhet të theksoj se nuk kam një aplikacion shembuj për këtë material. Por këtu, për eksperimentet, do të përshtatet ndonjë aplikacion të thjeshtë Node.

Për të përdorur kontejnerin, do t'ju nevojitet të jepni udhëzime për Docker. Kjo bëhet përmes një skedari, i quajtur Dockerfile, që ndodhet në direktorinë rrënjësore të projektit. Ky skedar, fillimisht, duket mjaft i pazakontë.

Por ajo që përmban, thjesht përshkruan, me komanda të veçanta, diçka të ngjashme me konfigurimin e mjedisit të punës. Ja disa nga këto komanda:

• FROM — Kjo komandë fillon skedarin. Ajo specifikon imazhin bazë, mbi të cilin ndërtohet kontejneri.
• COPY — Kopjimi i skedarëve nga burimi lokal në kontejner.
• WORKDIR — Përcaktimi i direktorisë punuese për komandat që vijnë.
• RUN — Ekzekutimi i komandave.
• EXPOSE — Konfigurimi i portit.
• ENTRYPOINT — Përcaktimi i komandës që do të ekzekutohet.

Dockerfile mund të duket diçka si kjo:

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

Në varësi të imazhit bazë të zgjedhur, mund të jetë e nevojshme të instaloni varësi shtesë. Është e vërtetë që disa imazhe bazë (siç është Node Alpine Linux) janë krijuar për ta bërë sa më të vogël të mundshme. Si rezultat, disa programe që mund të prisni të mungojnë.

▍Ndërtimi, etiketimi dhe ekzekutimi i kontejnerit

Ndërtimi dhe ekzekutimi lokal i kontejnerit — është, pasi kemi Dockerfile, detyra janë mjaft të thjeshta. Para se ta dërgoni imazhin në Docker Hub, duhet ta testoni lokalshëm.

▍Ndërtimi

Së pari, duhet të ndërtoni imazhi, duke specifikuar emrin, dhe, e cila nuk është e domosdoshme, etiketën (nëse nuk caktohet etiketa, sistemi automatikisht do të caktojë një etiketë për imazhin) latest).

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

Pas ekzekutimit të kësaj komande, mund të shikoni se si Docker kryen ndërtimin e imazhit.

Dërgimi i kontekstit të ndërtimit në daemon-in Docker   2.88MB
Hapi 1/9 : NGA node:12-alpine
 ---> ...ekzekutimi i fazave të ndërtimit...
Ndërtimi me sukses 123456789123
Etiketimi me sukses <imazhi>:<etiketa>

Krijimi mund të marrë disa minuta - gjithçka varet nga sa shumë varësi keni. Pasi të përfundojë krijimi, mund të ekzekutoni komandën docker images dhe të shihni përshkrimin e imazhit tuaj të ri.

REPOSITORY          TAG               IMAGE ID             CREATED              SIZE
             latest            123456789123        Para një minute   x.xxGB

▍ Nisja

Imazhi është krijuar. Dhe kjo do të thotë se mbi të mund të nisni një kontejner. Duke qenë se unë dua që të kem mundësinë të aksesoj aplikacionin, i cili punon në kontejner, në adresën localhost:5000, unë, në anën e majtë të çiftit 5000:5000 në komandën tjetër kam vendosur 5000. Në anën e djathtë është porta e kontejnerit.

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

Tani, kur kontejneri është krijuar dhe nisur, mund të përdorni komandën docker ps për të parë informacionet rreth këtij kontejneri (apo mund të përdorni komandën docker ps -a, e cila shfaq informacionet për të gjithë kontejnerët, jo vetëm për ata që janë aktivë).

CONTAINER ID        IMAGE               COMMAND                   CREATED              STATUS                   PORTS                    NAMES
987654321234                    "/bin/sh -c 'npm run…"   6 sekonda më parë        Aktiv 6 sekonda             0.0.0.0:5000->5000/tcp   stoic_darwin

Nëse tani kaloni në adresën localhost:5000 — mund të shihni faqen e një aplikacioni në funksionim, e cila duket njësoj si faqe aplikacioni që funksionon në ambientin e prodhimit.

▍Qëllimi i etiketës dhe publikimi

Për ta përdorur njërin nga imazhet e krijuara në serverin e prodhimit, ne duhet të kemi mundësinë ta ngarkojmë këtë imazh në Docker Hub. Kjo do të thotë se së pari duhet të krijojmë një depo në Docker Hub për projektin. Pas kësaj, do të kemi një vend ku mund ta dërgojmë imazh. Imazhi duhet të rinovohet në mënyrë që emri i tij të fillojë me emrin tonë të përdoruesit në Docker Hub. Më pas duhet të vijë emri i depozitës. Në fund të emrit mund të ketë një etiketë të çfarëdo dore. Më poshtë është një shembull i emërimit të imazheve sipas kësaj skeme.

Tani mund të ndërtojmë imazhin duke i dhënë një emër të ri dhe të ekzekutojmë komandën docker push për ta dërguar në depozitën e Docker Hub.

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

# Në praktikë, kjo mund të duket, për shembull, kështu:
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

Nëse gjithçka shkon siç duhet, imazhi do të jetë i disponueshëm në Docker Hub dhe do të jetë lehtësisht i shkarkueshëm në server ose i transferueshëm tek zhvillues të tjerë.

Hapat e ardhshëm

Në këtë moment, ne kemi konfirmuar që aplikacioni, si një kontejner Docker, funksionon lokal. Ne kemi ngarkuar kontejnerin në Docker Hub. Të gjitha këto do të thotë se ne kemi avancuar shumë në arritjen e qëllimit. Tani duhet të zgjidhim dy çështje të tjera:

• Konfigurimi i mjetit CI për testimin dhe vendosjen e kodit.
• Konfigurimi i serverit të prodhimit në mënyrë që ai të mund të ngarkojë dhe ekzekutojë kodin tonë.

Në rastin tonë, si zgjidhje CI/CD përdoret Travis CI. Si server — DigitalOcean.

Duhet të theksohet se këtu mund të përdoret edhe një kombinim tjetër shërbimesh. Për shembull, në vend të Travis CI mund të përdorim CircleCI ose Github Actions. Dhe në vend të DigitalOcean — AWS ose Linode.

Ne kemi vendosur të punojmë me Travis CI, dhe në këtë shërbim kam krijuar tashmë disa konfigurime. Prandaj tani do të tregoj shkurtimisht se si ta përgatisim për punë.

Travis CI

Travis CI — një mjet për testimin dhe deploy-in e kodit. Nuk do të doja të hyj në detaje të konfigurimit të Travis CI, pasi çdo projekt është unik dhe kjo nuk do të sjellë shumë përfitim. Por do të flas për të gjitha bazat që do t'ju ndihmojnë të filloni në rast se vendosni të përdorni Travis CI. Çfarëdo që të zgjidhni — Travis CI, CircleCI, Jenkins, ose diçka tjetër, metoda e konfigurimit do të jenë të ngjashme.

Për të filluar me Travis CI, shkoni te faqen e projektit dhe krijoni një llogari. Më pas, integroni Travis CI me llogarinë tuaj në GitHub. Në procesin e konfigurimit, do t'ju duhet të tregoni repo që dëshironi të automatizoni dhe të aktivizoni aksesin në të. (Unë përdor GitHub, por jam e sigurt që Travis CI mund të integrohet edhe me BitBucket, edhe me GitLab, dhe shërbime të tjera të ngjashme).

Çdo herë që Travis CI fillon punën, aktivizohet një server që ekzekuton komandat e caktuara në skedarin e konfigurimit, duke përfshirë deploy-in e degëve përkatëse të repo-s.

▍Cikli i jetës së detyrës

Skedari i konfigurimit të Travis CI, i quajtur .travis.yml dhe ruan në direktorinë kryesore të projektit, mbështet konceptin e ngjarjeve të ciklit të jetës të detyrave. Këto janë ngjarjet, të renditura në rendin në të cilin ndodhin:

• apt addons
• komponentet e cache
• before_install
• install
• before_script
• script
• before_cache
• after_success ose after_failure
• before_deploy
• deploy
• after_deploy
• after_script

▍Testimi

Në skedarin e konfigurimit do të konfiguroj serverin lokal Travis CI. Si gjuhë kam zgjedhur versionin Node 12 dhe i kam bërë të ditur sistemit që të instalohet varësitë e nevojshme për përdorimin e Docker.

Gjithçka që është listuar në .travis.yml, do të ekzekutohet kur të kryhen të gjitha pull-request-et në të gjitha degët e repositorit, përveç nëse ndryshe është specifikuar. Kjo është një veçori e dobishme, pasi do të thotë që mund të testojmë të gjithë kodin që hyn në repositor. Kjo lejon të dimë nëse kodi është i gatshëm për të u shkruar në degën master, dhe nuk do ta prishë procesin e ndërtimit të projektit. Në këtë konfigurim global, unë e bëj gjithçka lokal, aktive serverin e zhvilluesit Webpack në sfond (kjo është një veçori e procesit tim të punës) dhe ekzekutoj testet.

Nëse dëshironi që në repositorin tuaj të shfaqen simbole me informacion për mbulimin e kodit nga testet, këtu mund të gjeni një udhëzues të shkurtër për përdorimin e Jest, Travis CI dhe Coveralls për mbledhjen dhe paraqitjen e këtyre të dhënave.

Ja përmbajtja e skedarit .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

Këtu përfundojnë ato veprime që kryhen për të gjitha degët e depozitës dhe për kërkesat për bashkim.

▍Zhvillimi

Duke u bazuar në supozimin se të gjitha testet automatike përfunduan me sukses, ne mund të publikojmë kodin në serverin e prodhimit. Të gjitha këto përbëjnë nga kodi në degën master, ne u japim sistemit udhëzime përkatëse në cilësimet e zhvillimit. Para se të provoni të përdorni në projektin tuaj kodin që do të shqyrtojmë më pas, do të doja t'ju paralajmëroja se duhet të keni një skenar të vërtetë që thirret për publikimin.

deploy:
  # Ndërto kontejnerin Docker dhe dërgoje në Docker Hub
  provider: script
  script: bash deploy.sh
  on:
    branch: master

Skenari i publikimit zgjidh dy detyra:

• Ndërtesa, etiketimi dhe dërgimi i imazhit në Docker Hub me mjete CI (në rastin tonë, është Travis CI).
• Ngarkimi i imazhit në server, ndalimi i kontejnerit të vjetër dhe nisja e të riut (në rastin tonë, serveri funksionon në platformën DigitalOcean).

Së pari, duhet të konfigurojmë një proces automatik për ndërtimin, etiketimin dhe dërgimin e imazhit në Docker Hub. E gjithë kjo është shumë e ngjashme me atë që kemi bërë tashmë manualisht, përveç se këtu na nevojitet një strategji për caktimin e etiketave unike për imazhet dhe automatizimi i hyrjes në sistem. Kam pasur vështirësi me disa detaje të skriptit të implementimit, si strategjia e etiketimit, hyrja në sistem, kodimi i çelësave SSH dhe vendosja e lidhjes SSH. Por, për fat të mirë, i dashuri im është shumë i mirë me bash, ashtu si me shumë gjëra të tjera. Ai më ndihmoi të shkruaj këtë skript.

Pra, pjesa e parë e skriptit është dërgimi i imazhit në Docker Hub. Ta bësh këtë është mjaft e thjeshtë. Skema e etiketimit që kam përdorur përfshin kombinimin e hash-it git dhe etiketës git, nëse ekziston. Kjo siguron krijimin e një etikete unike dhe lehtëson identifikimin e ndërtimit mbi të cilin është bazuar. DOCKER_USERNAME dhe DOCKER_PASSWORD — janë variabla të personalizuar të ambientit që mund të caktosh përmes ndërfaqes Travis CI. Travis CI do të përpunojë automatikisht të dhënat sekrete në mënyrë që ato të mos bien në duar të gabshme.

Ja pjesa e parë e skriptit 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}

Ajo, se si do të duket pjesa e dytë e skriptit, varet plotësisht nga hosti që po përdorni dhe mënyra se si është organizuar lidhja me të. Në rastin tim, pasi po përdor Digital Ocean, për lidhjen me serverin përdoren komandat doctl. Ndërsa kur punoni me AWS, do të përdoret utilita aws, e kështu me radhë.

Të konfiguroni punën e serverit nuk ishte shumë e komplikuar. Në këtë mënyrë, unë konfigurova një droplet të bazuar në imazhin bazë. Duhet të theksoj se sistemi që kam zgjedhur kërkon një instalim manual të Docker një herë dhe një nisje manuale të Docker një herë. Për instalimin e Docker, unë përdorova Ubuntu 18.04, kështu që ju, nëse gjithashtu përdorni Ubuntu, për të bërë të njëjtën gjë, mund të ndiqni këtu udhëzimin e thjeshtë.

Nuk po flas këtu për komandat e konkretizuar për shërbimin, pasi ky aspekt mund të ndryshojë ndjeshëm në raste të ndryshme. Unë do të jap vetëm një plan të përgjithshëm të veprimeve që do të kryhen pas lidhjes përmes SSH me serverin ku do të zhvillohet projekti:

• Duhet të gjeni kontejnerin që aktualisht po ekzekutohet dhe ta ndaloni atë.
• Më pas duhet, në sfond, të nisni një kontejner të ri.
• Do të nevojitet të vendosni portin lokal të serverit në vlerën 80 — kjo do t'ju lejojë të hyni në faqen e internetit në adresën si example.com, pa specifikuar portin, dhe jo duke përdorur adresën si example.com:5000.
• Dhe, përfundimisht, duhet të hiqni të gjitha kontejnerët dhe imazhet e vjetra.

Këtu është vazhdimi i skriptit.

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

Disa gjëra që duhet të keni parasysh

Mund të ndodhë që kur të lidhni me serverin përmes SSH nga Travis CI, do të shihni një paralajmërim që nuk do të lejojë vazhdimin e instalimit, pasi sistemi do të presë reagimin e përdoruesit.

Autenticiteti i hostit ' ()' nuk mund të vendoset.
Nyja e çelësit RSA është .
A jeni të sigurt që doni të vazhdoni të lidheni (po/jo)?

Kam mësuar se çelësi i vargut mund të kodifikohet në base64 për të ruajtur atë në një format ku është e lehtë dhe e sigurt të punoni me të. Gjatë fazës së instalimit, mund të dekodoni çelësin publik dhe ta regjistroni atë në skedarin known_hosts për t'u liruar nga gabimi i përshkruar më sipër.

echo  | base64 # shfaq

Në praktikë, kjo komandë mund të duket kështu:

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

Ja këtu është si duket ajo që ajo jep — një varg në kodimin base64:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHpaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Ja është komanda, për të cilën u fol më sipër

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

Të njëjtin qasje mund të përdorim me çelësin privat kur krijojmë një lidhje, sepse ju, për të hyrë në server, mund të nevojitet çelësi privat. Kur punoni me çelësin, duhet ta siguroni ruajtjen e tij në një variabël mjedisi në Travis CI dhe të siguroheni që ai të mos printohet askund.

Një gjë tjetër që meriton vëmendje është se mund t'ju nevojitet të ndihmoni gjithë skriptin e implementimit, i paraqitur si një rresht, për shembull — përmes doctl. Kjo mund të kërkojë disa përpjekje shtesë.

doctl compute ssh  --ssh-command "të gjitha komandat do të jenë këtu && këtu"

TLS/SSL dhe balancimi i ngarkesës

Pasi bëra të gjitha ato që u diskutuan më sipër, problemi i fundit që u paraqit ishte se serveri nuk kishte SSL. Duke qenë se përdor një server Node.js, për të bërë të funksionojë proksi i kthyer Nginx dhe Let’s Encrypt, duhet të punosh shumë.

Nuk më pëlqente aspak të bëja të gjitha këto konfigurime SSL manualisht, kështu që thjesht krijova një balancues ngarkese dhe regjistrova informacionin e tij në DNS. Në rastin e DigitalOcean, për shembull, krijimi i një certificati self-signed që auto-update në balancuesin e ngarkesës është një procedurë e thjeshtë, pa pagesë dhe e shpejtë. Ky qasje ka gjithashtu një avantazh të shtuar, që është se nëse është e nevojshme, lehtëson shumë konfigurimin e SSL në shumë servera që punojnë pas balancuesit të ngarkesës. Kjo i lejon serverët vetë të mos “mendojnë” fare për SSL, por megjithatë të përdorin, si zakonisht, portin 80. Pra, konfigurimi i SSL në balancuesin e ngarkesës është shumë më i lehtë dhe më komod se metodat alternativë të konfigurimit të SSL.

Tani mund të mbyllni të gjitha portet në server që pranojnë lidhje okolike — përveç portit 80, i cili përdoret për komunikim me balancuesin e ngarkesës, dhe portit 22 për SSH. Si rezultat, përpjekja për t'u drejtuar drejtpërsëdrejti në server përmes porteve të tjera, përveç këtyre dy, do të dështojë.

Përfundimet

Pas pas, pas kam bëra gjithçka që përmenda në këtë material, nuk kisha më frikë nga platforma Docker as nga konceptet e automatizuara të rrjedhave CI/CD. Arrita të konfigurita një rrjedhë të integrimit të vazhdueshëm, gjatë të cilës realizohet testimi i kodit para se të kalojë në prodhim dhe shpërndarja automatike e kodit në server. Të gjitha këto janë ende relativisht të reja për mua, dhe jam e sigurt që ka mënyra për të përmirësuar procesin tim të punës automatizuar dhe ta bëj atë më efikas. Prandaj, nëse keni ide për këtë, më informoni. Shpresoj që ky artikull ju ka ndihmuar në punën tuaj. Dua të besoj se, duke e lexuar atë, ju mësuat të paktën aq sa mësova unë, ndërsa u merresha me gjithçka që kam përmendur në të.

P.S. Në shërbimin tonë merkatplace-in tonë ka një imazh Docker, i cili instalohet me një klik. Mund të kontrolloni punën e kontejnerëve në VPS. Të gjithë klientët e rinj ofrohen falas 3 ditë për testim.

Të nderuar lexues! A përdorni teknologjitë CI/CD në projektet tuaja?

Burimi: habr.com