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

Unë kam shkruar sajtet e mia të para në fund të viteve '90. Atëherë, ta bëje ata funksional ishte shumë e lehtë. Kishte një server Apache në ndonjë host të përbashkët, në të cilin mund të hyje përmes FTP-së, duke shkruar në shiritin e shfletuesit diçka si ftp://ftp.example.com. Pastaj duhej të shtoja emrin dhe fjalëkalimin dhe të ngarkoja skedarët në server. Ishin kohë të tjera, gjithçka ishte më e thjeshtë atëherë sesa tani.

Që nga ajo kohë, shumë ka ndryshuar. Saitet janë bërë më komplekse, dhe para se të dilnin në produkte, duhen mbledhur. Një server i vetem është bërë një numër serverash që punojnë pas balancuesve të ngarkesës, dhe përdorimi i sistemeve të kontrollit të versioneve është bërë diçka e zakonshme.

Për projektin tim personal, kisha një konfigurim të veçantë. Dija se më nevojitej mundësia për të shpërndarë sajtin në prodhim, duke kryer vetëm një veprim: shkruaj kodin në degën master në GitHub. Për më tepër, dija se për të siguruar operimin e aplikacionit tim të vogël në internet, nuk dëshiroja të merresha me menaxhimin e një klasteri të madh Kubernetes, të përdorja teknologjinë Docker Swarm, ose të mbështesja një park serverash me podë, agjentë dhe çdo lloj ndërlikimi tjetër. Për të arritur qëllimin e thjeshtimit maksimal të punës, më duhej të mësoja për CI/CD.

Nëse keni një projekt të vogël (në këtë rast po flasim për një projekt Node.js) dhe dëshironi të dini se si të automatizoni shpërndarjen e këtij projekti, duke siguruar që ajo që ndodhet në depo, përputhet saktësisht me atë që funksionon në prodhim, mendoj se ky artikull mund t'ju interesojë.

Kërkesat paraprake

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

Qëllimet

Nuk do të thoja se ky artikull mund të quhet pa kushte "udhëzues mësimor". Kjo është më shumë një dokument në të cilin përshkruaj atë që kam mësuar dhe shpjegoj procesin e pranueshëm për testimin dhe shpërndarjen e kodit në prodhim, i kryer në një kalim të vetëm automatizuar.

Ja si ka dalë në fund procesi im i punës.

Për kodin e dërguar në çdo degë të depozitës, përveç master, kryhen këto veprime:

• Nis një ndërtim të projektit në Travis CI.
• Kryhen të gjitha testet modulare, integruese dhe përmes.

Vetëm për kodin që kalon në master, zbatohet e mëposhtmja:

• Çdo gjë që u tha më sipër, plus…
• Ndërtimi i imazhit Docker në bazë të kodit aktual, konfigurimeve dhe mjedisit.
• Vendosja e imazhit në Docker Hub.
• Lidhja me serverin e prodhimit.
• Ngarkimi i imazhit nga Docker Hub në server.
• Ndalesa e kontejnerit aktual dhe fillimi i një të riut, bazuar në imazhin e ri.

Nëse nuk e dini asgjë për Docker, imazhet dhe kontejnerët — mos u shqetësoni. Unë do t’ju tregoj të gjitha për këtë.

Çfarë është CI/CD?

Akrilateria CI/CD do të thotë «integrimi i vazhdueshëm/komponenti i vazhdueshëm» — «integrimi i vazhdueshëm/vazhdueshmëri në prodhim».

▍Integrimi i vazhdueshëm

Integrimi i vazhdueshëm është procesi kur zhvilluesit bëjnë komitet në depo kryesore të kodit burim të projektit (zakonisht në degën master). Gjatë kësaj periudhe, cilësia e kodit sigurohet përmes testeve automatike.

▍Vazhdueshmëria në prodhim

Vazhdueshmëria në prodhim është një shpërndarje e shpeshtë automatike e kodit në prodhim. Pjesa e dytë e akrilatës CI/CD shpesh zbulohet si «ndarje e vazhdueshme». Kjo, në përmbledhje, është e njëjtë me «vazhdueshmërinë në prodhim», por «ndarja e vazhdueshme» nënkupton nevojën për konfirmimin manual të ndryshimeve para se të fillojë procesi i shpërndarjes së projektit.

Fillimi i punës

Aplikacioni me të cilin kam mësuar gjithçka është quajtur TakeNote. Ky është një projekt web, mbi të cilin unë po punoj, i dedikuar për marrjen e shënimeve. Fillimisht, u përpoqa të bëj një projekte JAMStack- ose vetëm një aplikacion frontend pa server, për të shfrytëzuar mundësitë standarde për hostimin dhe shpërndarjen e projekteve që ofron Netlify. Ndërsa kompleksiteti i aplikacionit rritej, më duhej të krijoja gjithashtu pjesën e tij serverike, e cila nënkuptonte që do të duhej të formuloja një strategji të vetme për integrimin e automatizuar dhe shpërndarjen e automatizuar të projektit.

Në rastin tim, aplikacioni është një server Express që funksionon në ambientin Node.js, i cili shërben një aplikacion React një-faqëshe dhe mbështet një API të sigurt serverik. Kjo arkitekturë ndjek një strategji që mund të gjendet në këtë udhëzues për autentifikimin fullstack.

Diskutova me tjetër, i cili është një ekspert i automatizimit, dhe e pyesa se çfarë duhet të bëj që gjithçka të funksionojë ashtu siç kam nevojë. Ai më sugjeroi një ide se si duhet të duket procesi i automatizuar i punës, i paraqitur në seksionin 'Qëllimet' të këtij artikulli. Dëshira ime për të vendosur qëllime të tilla do të thotë që duhet të kuptoj si të përdor Docker.

Docker

Docker është një mjet që, falë teknologjisë së kontejnerizimit, lejon që të shpërndahen aplikacione me lehtësi, si dhe të realizohet vendosja dhe ekzekutimi i tyre në të njëjtin mjedis, edhe kur vetë platforma Docker funksionon në mjedise të ndryshme. Fillimisht, duhet të kem në dispozicion mjetet e komandës (CLI) të Docker-it. Udhëzimi për instalimin e Docker-it nuk mund të quhet shumë i qartë dhe i kuptueshëm, por prej tij mund të mësohet se për të bërë hapin e parë të instalimit, duhet të shkarkohet Docker Desktop (për Mac ose Windows).

Docker Hub është përafërsisht si GitHub për depozitat git, ose regjistri npm për paketat JavaScript. Ky është një depo online për imazhet Docker. Docker Desktop lidhet me të.

Pra, për të filluar punën me Docker, duhet të bëni 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ë verifikuar versionin e Docker-it:

docker -v

Më pas, 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ë si një plan që përmban udhëzime për ndërtimin e një konteineri. Ky është një snapshot i pandryshueshëm i sistemit të skedarëve dhe konfigurimeve të aplikacionit. Zhvilluesit mund të ndajnë imazhe me lehtësi.

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

Kjo komandë do të nxjerrë një tabelë me këtë titull:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

Më pas do të shqyrtojmë disa shembuj komandash në të njëjtin format — fillimisht vjen komanda me koment, dhe pastaj një shembull të asaj që ajo mund të nxjerrë.

▍Kontejnerët

Kontejneri është një paketë ekzekutuese që përmban gjithçka të nevojshme për të ekzekutuar një aplikacion. Aplikacioni në këtë qasje do të funksionojë gjithmonë në të njëjtën mënyrë, pavarësisht nga infrastruktura: në një mjedis të izoluar dhe në të njëjtën mjedis. Këtu flitet për faktin se në mjedise të ndryshme ekzekutohen instancat e së njëjtës figurë.

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

▍Etiketat

Etiketa është një tregues për një version të caktuar të figurës.

▍Shqyrtim i shkurtër i komandave Docker

Këtu është një përmbledhje e disa komandave të shpeshta të Docker.

Ekipa

Konteksti

Veprim

docker build

Imazh

Krijimi i figurës nga Dockerfile

docker tag

Imazh

Etiketimi i figurës

docker images

Imazh

Shfaqja e listës së figurave

docker run

Konteineri

Ekzekutimi i kontejnerit të bazuar në figurë

docker push

Imazh

Dërgimi i figurës në regjistrin

docker pull

Imazh

Shkarkimi i figurës nga regjistri

docker ps

Konteineri

Shfaqja e listës së kontejnerëve

docker system prune

Figura/Kontejneri

Fshirja e kontejnerëve dhe figurave të papërdorura

▍Dossier Dockerfile

Unë di si të ekzekutoj lokalish aplikacionin për prodhim. Kam një konfigurim Webpack, të destinuar për krijimin e një aplikacioni të gatshëm React. Më tej, kam një komandë që ekzekuton një server të bazuar në Node.js, në portin 5000. Duket kështu:

npm i        # instalimi i varësive
npm run build # krijimi i aplikacionit React
npm run start # ekzekutimi i serverit Node

Duhet të theksohet se nuk kam një aplikacion-shembull për këtë material. Por, këtu, për eksperimente, do të shkonte çdo aplikacion të thjeshtë Node.

Për të përdorur kontejnerin, do t'ju duhet të jepni instrukcione Docker. Kjo bëhet përmes një dosje të quajtur Dockerfile, e cila ndodhet në direktorinë themelore të projektit. Kjo dosje, në fillim, duket mjaft e paqartë.

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

• FROM — Kjo komandë fillon dosjen. Në të specifikohet figura bazë, mbi të cilën ndërtohet kontejneri.
• COPY — Kopjimi i skedave nga burimi lokal në kontejner.
• WORKDIR — Caktimi i direktorive të punës për komandat e mëpasshme.
• RUN — Ekzekutimi i komandave.
• EXPOSE — Caktimi i portit.
• ENTRYPOINT — Specifikimi i komandës që do të ekzekutohet.

Dockerfile mund të duket në këtë mënyrë:

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

Sipas imazhit të bazës së zgjedhur, mund t'ju nevojiten disa varësi të tjera. Problemi është që disa imazhe të bazës (si Node Alpine Linux) janë krijuar për t'u bërë sa më kompakte. Si rezultat, mund të mungojnë disa programe në të cilat ju po mendoni.

▍Ndërtimi, etiketimi dhe nisja e kontejnerit

Ndërtimi dhe nisja lokale e kontejnerit — kjo është, pasi të kemi Dockerfile, detyrat janë mjaft të thjeshta. Para se ta dërgoni imazhin në Docker Hub, duhet ta testoni lokalisht.

▍Ndërtimi

Së pari, duhet të ndërtosh imazh, duke specifikuar emrin, dhe, çka nuk është e nevojshme, etiketën (nëse nuk jepet etiketa, sistemi automatikisht do t'i caktohet një etiketë imazhit latest).

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

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

Dërgimi i kontekstit të ndërtimit në daemon-in Docker   2.88MB
Hapi 1/9 : FROM node:12-alpine
 ---> ...përfundimi i hapave të ndërtimit...
Ndërtuar me sukses 123456789123
Etiketuar me sukses <image>:<tag>

Ndërtimi mund të zgjasë disa minuta — gjithçka varet nga sa shumë varësi keni. Pas përfundimit të ndërtimit, mund të ekzekutoni komandën docker images dhe të shikoni përshkrimin e imazhit tuaj të ri.

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

▍Nisja

Imazhi është krijuar. Kjo do të thotë se mbi të mund të nisni një kontejner. Sepse unë dua të kem mundësinë të qasem në aplikacionin që punon në kontejner në adresën localhost:5000, unë, në anën e majtë të çiftit 5000:5000 në komandën e ardhshme vendosa 5000. Në anën e djathtë ndodhet 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ë informacionin mbi këtë kontejner (ose mund të përdorni komandën docker ps -a, e cila tregon informacionin mbi të gjithë kontejnerët, jo vetëm ato që janë duke punuar).

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

Nëse tani kaloni në adresën localhost:5000 — mund të shihni faqen e aplikacionit që punon, e cila dukej qartë ashtu si faqja e aplikacionit që punon në mjedisin e prodhimit.

▍Caktimi i etiketës dhe publikimi

Për të përdorur një nga imazhet e krijuara në serverin e prodhimit, na nevojitet që të kemi mundësinë të ngarkojmë këtë imazh nga 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ë imazhin. Imazhi duhet të rinominohet në mënyrë që emri të fillojë me emrin tonë të përdoruesit në Docker Hub. Pas kësaj duhet të vijë emri i depos. Në fund të emrit mund të jetë çfarëdo etikete. Më poshtë jepet një shembull i emërtesës së imazheve sipas kësaj skeme.

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

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

# Në praktikë, kjo mund të duket, për shembull, si më poshtë:
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 gjërat shkojnë siç duhet, imazhi do të jetë i disponueshëm në Docker Hub dhe mund të ngarkohet lehtësisht në server ose të transferohet te zhvilluesit e tjerë.

Hapat e ardhshëm

Derisa arritëm në këtë pikë, ne konfirmuam se aplikacioni, në formën e një konteineri Docker, funksionon lokal. Ne ngarkuam konteinerin në Docker Hub. Të gjitha këto do të thotë se tashmë kemi bërë një përparim të mirë drejt qëllimit. Tani duhet të zgjidhim dy çështje të tjera:

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

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

Duhet theksuar 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ërdorni CircleCI ose Github Actions. Ndërsa në vend të DigitalOcean — AWS ose Linode.

Ne vendosëm të punojmë me Travis CI, dhe në këtë shërbim kam tashmë disa gjëra të konfigurura. Prandaj tani do t'ju tregoj shkurtimisht se si ta përgatisim për punë.

Travis CI

Travis CI është një mjet për testimin dhe zhvillimin e kodit. Nuk do të doja të hyja në hollësi rreth konfigurimit të Travis CI, pasi çdo projekt është unik dhe kjo nuk do të sjellë ndihmë të madhe. Por do të flas për bazat që do t'ju ndihmojnë të filloni punën në rast se vendosni të përdorni Travis CI. Çfarëdo që të zgjidhni — Travis CI, CircleCI, Jenkins, ose diçka tjetër, do të aplikohen metoda të ngjashme konfigurimi.

Për të filluar punën me Travis CI, shkoni në faqja e projektit dhe krijoni një llogari. Pastaj integrojeni Travis CI me llogarinë tuaj GitHub. Gjatë konfigurimit të sistemit, do t'ju duhet të specifikoni depozitën me të cilën dëshironi të automatizoni punën, si dhe të jepni akses në të. (Unë përdor GitHub, por jam e sigurt se Travis CI mund të integrohet gjithashtu me BitBucket, GitLab dhe shërbime të tjera të ngjashme).

Çdo herë që Travis CI fillon punën e tij, aktivohet një server që ekzekuton komandat e përshkruara në skedarin e konfigurimit, duke përfshirë shpërndarjen e degëve përkatëse të depozitës.

▍Cikli i jetës së detyrës

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

• apt addons
• cache components
• before_install
• instalo
• before_script
• script
• before_cache
• after_success ose after_failure
• before_deploy
• deploy
• after_deploy
• after_script

▍Testimi

Në skedarin e konfigurimit, unë do të rregulloj një server lokal Travis CI. Si gjuhë kam zgjedhur Node version 12 dhe i kam treguar sistemit se duhet të instalohet varësitë e nevojshme për të përdorur Docker.

Çdo gjë që është e listuar në .travis.yml, do të ekzekutohet kur ekzekutohen të gjitha pull request-et në të gjitha degët e depozitës, përveç nëse nuk është specifikuar ndryshe. Kjo është një veçori e dobishme, pasi do të thotë se mund të testojmë të gjithë kodin që hyn në depo. Kjo na lejon të dimë nëse kodi është i gatshëm për t'u regjistruar në degën master, dhe nuk do të dëmtojë procesin e ndërtimit të projektit. Në këtë konfigurim globale, unë instaloj gjithçka lokalisht, aktivizoj 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ë depozitën tuaj të shfaqen gjithashtu simbole me informacion mbi mbulimin e kodit me teste, këtu mund të gjeni një udhëzues të shkurtër mbi përdorimin e Jest, Travis CI dhe Coveralls për grumbullimin dhe shfaqjen e këtyre informacionit.

Pra, 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ë ekzekutohen për të gjitha degët e depozitës dhe për pull request-et.

▍Shpërndarja

Duke marrë parasysh supozimin se të gjitha testet automatizuese përfunduan me sukses, ne, gjë që nuk është e nevojshme, mund të shpërndajmë kodin në serverin e prodhimit. Qëllimi ynë është që të bëjmë këtë vetëm për kodin nga dega master, ne japim sistemit udhëzimet përkatëse në cilësimet e implementimit. Para se të provoni të përdorni në projektin tuaj kodin që do të shqyrtojmë më poshtë, do të doja t'ju paralajmëroja se duhet të keni një skritp real që thirret për implementim.

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

Skritpi i implementimit zgjidh dy detyra:

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

Së pari, duhet të konfigurojmë procesin automatike të ndërtimit, etiketimit dhe dërgimit të imazhit në Docker Hub. Të gjitha këto janë shumë të ngjashme me ato që kemi bërë me dorë, përveç se këtu na nevojitet një strategji për të caktuar etiketat unike për imazhet dhe automatizimi i hyrjes në sistem. Kam pasur vështirësi me disa detaje të skritpit të implementimit, siç janë strategjia e etiketimeve, hyrja në sistem, kodimi i çelësave SSH, vendosja e lidhjes SSH. Por, për fat të mirë, i dashuri im është shumë i afërt me bash-in, ashtu si me shumë gjëra të tjera. Ai më ndihmoi të shkruaj këtë skritp.

Pra, pjesa e parë e skritpit është dërgimi i imazhit në Docker Hub. Ta bësh këtë është mjaft e thjeshtë. Schema e etiketimeve që kam përdorur parashikon 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 nga i cili bazohet. DOCKER_USERNAME dhe DOCKER_PASSWORD — janë variabla të përdoruesve të ambientit që mund të caktohen përmes ndërfaqes së Travis CI. Travis CI automatikisht do të përpunojë të dhënat e ndjeshme në mënyrë që ato të mos bien në duar të gabuara.

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

Të dhënat se cila do të jetë pjesa e dytë e skritpit, varen krejtësisht nga cili host po përdorni dhe se si është organizuar lidhja me të. Në rastin tim, pasi po përdor Digital Ocean, komandat që përdoren për t'u lidhur me serverin janë doctl. Kur punoni me Aws do të përdoret utilitar aws, e kështu me radhë.

Konfigurimi i serverit nuk ishte shumë i komplikuar. Kështu, kam konfiguruar një droplet të bazuar në imazhin bazë. Duhet të theksoj se sistemi që kam zgjedhur kërkon një instalim manual një herë të Docker-it dhe një aktivizim manual një herë të Docker-it. Unë përdora Ubuntu 18.04 për të instaluar Docker, kështu që ju, nëse gjithashtu përdorni Ubuntu, për të bërë të njëjtën gjë, mund të ndiqni këtë udhëzimin e thjeshtë.

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

• Duhet të gjeni kontejnerin që është aktualisht në punë dhe ta ndaloni atë.
• Pastaj duhet të aktivizoni një kontejner të ri në sfond.
• Do t'ju duhet të vendosni portin lokal të serverit në vlerën 80 — kjo do të lejojë hyrjen në faqe në adresën e tipit example.com, pa specifikuar portin, dhe jo të përdorni adresën si example.com:5000.
• dhe, më në fund, duhet të fshini të gjithë kontejnerët dhe imazhet e vjetra.

Ja 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 për të cilat duhet të jepni vëmendje

Mund të ndodhë që kur të lidhemi 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 host-it '<hostname> (<IP address>)' nuk mund të vendoset.
Shenja e çelësit RSA është <key fingerprint>.
A jeni të sigurt se dëshironi të vazhdoni lidhjen (po/jo)?

Mësova se mund të kodoj çelësin e vargut në base64 për ta ruajtur në një formë që mund të punojmë lehtësisht dhe në mënyrë të sigurt me të. Në fazën e instalimit, mund të dekodoj çelësin publik dhe ta ruaj në skedarin known_hosts për të eliminur gabimin e përshkruar më sipër.

echo <public key> | base64 # shfaq <çelësi publik i koduar në base64>

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 si duket ajo që ajo jep — një varg në kodimin base64:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Kjo tenho é tim 'de simptoma, se qi shumë, chun mui panasit

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

I njëjti qasje mund të përdoret me çelësin privat kur krijoni lidhjen, pasi për t'u aksesuar serverin ju nevojitet mjaftueshëm çelësi privat. Ndërsa punoni me çelësin, duhet të siguroni ruajtjen e tij të sigurt në variablën e mjedisit Travis CI, dhe zgjedhjen që të mos shfaqet askund.

Një gjë tjetër që duhet të keni parasysh është se mund të keni nevojë të ekzekutoni të gjithë skriptin e shpërndarjes, i paraqitur si një varg, për shembull — me ndihmën e 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

Pas asaj që bëra gjithçka që përmendi më sipër, problemi i fundit që u shfaq ishte se serveri nuk kishte SSL. Duke përdorur serverin Node.js, për të bërë që të punojë Një proksi i kthyer Nginx dhe Let’s Encrypt kërkon mjaft punë.

Nuk doja aspak të bëja të gjitha këto konfigurime SSL manualisht, kështu që thjesht krijova një balancues ngarkesash dhe regjistrova informacionin mbi të në DNS. Në rastin e DigitalOcean, për shembull, krijimi i një certifikate të vetë-nënshkruar që përditësohet automatikisht në balancuesin e ngarkesave është një procedurë e thjeshtë, falas dhe e shpejtë. Ky qasje ka një avantazh shtesë, që është se nëse është e nevojshme, lejon të konfigurohen shumë lehtë SSL në shumë servera që punojnë prapa balancuesit të ngarkesave. Ky i fundit bën që serverat të mos "mendojnë" për SSL, por të përdorin, si zakonisht, portin 80. Pra, konfigurimi i SSL në balancuesin e ngarkesave është shumë më i lehtë dhe më i përshtatshëm se metodat alternative të konfigurimit të SSL.

Tani është e mundur të mbyllet në server të gjitha portet që pranojnë lidhje hyrëse - përveç portit 80, që përdoret për komunikimin me balancuesin e ngarkesave, dhe portin 22 për SSH. Si pasojë, përpjekja për t'u qasur drejtpërdrejt në server nëpërmjet portave të tjerë, përveç këtyre dyve, do të dështojë.

Përfundime

Pas faktit që unë bëra gjithçka që përmenda në këtë material, as platforma Docker dhe konceptet e automatizuar të CI/CD nuk më frikësonin më. Arrita të konfigur një varg të integrimit të vazhdueshëm, gjatë të cilit testimi i kodit përfundohet para se të kalojë në prodhim dhe automatizimi i vendosjes së kodit në server. Gjithçka kjo është ende relativisht e re për mua, dhe jam e sigurt se ka mënyra për ta përmirësuar procesin tim të punës automatizuar dhe për ta bërë atë më efikas. Prandaj, nëse keni ndonjë ide lidhur me këtë - lajmëroni. mua Shpresoj se ky artikull ju ndihmoi në punët tuaja. Dua të besoj se pas leximit të tij, keni mësuar aq sa mësova unë gjatë gjithë procesit me gjithçka që përshkrova në të.

P.S. Në tonin marketin tonë ka një imazh Docker, i cili instalohet me një klik. Ju mund të kontrolloni funksionimin e kontejnerëve në VPS. Të gjithë klientët e rinj u ofrohen falas 3 ditë për provë.

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

Burimi: habr.com