CI / CD ķēdes izveide un darba automatizācija ar Docker

Savas pirmās tīmekļa vietnes es uzrakstīju 90. gadu beigās. Toreiz tos bija ļoti viegli ievietot darba kārtībā. Kaut kādā dalītā mitināšanā bija Apache serveris, jūs varētu pieteikties šajā serverī, izmantojot FTP, rakstot kaut ko līdzīgu ftp://ftp.example.com. Pēc tam jums bija jāievada savs vārds un parole un jāaugšupielādē faili serverī. Bija dažādi laiki, toreiz viss bija vienkāršāk nekā tagad.

Divu gadu desmitu laikā kopš tā laika viss ir ļoti mainījies. Tīmekļa vietnes ir kļuvušas sarežģītākas; tās ir jāsamontē pirms laišanas ražošanā. Viens serveris kļuva par daudziem serveriem, kas darbojas aiz slodzes līdzsvarotājiem, un versiju kontroles sistēmu izmantošana kļuva par ierastu lietu.

Manam personīgajam projektam man bija īpaša konfigurācija. Un es zināju, ka man ir nepieciešama iespēja izvietot vietni ražošanā, veicot tikai vienu darbību: ierakstot kodu filiālē. master vietnē GitHub. Turklāt es zināju, ka, lai nodrošinātu savas mazās tīmekļa lietojumprogrammas darbību, es nevēlos pārvaldīt milzīgu Kubernetes klasteru vai izmantot Docker Swarm tehnoloģiju, vai uzturēt serveru parku ar podiem, aģentiem un visādiem citiem. sarežģītības. Lai sasniegtu mērķi padarīt darbu pēc iespējas vieglāku, man vajadzēja iepazīties ar CI/CD.

Ja jums ir neliels projekts (šajā gadījumā Node.js projekts) un vēlaties uzzināt, kā automatizēt šī projekta izvietošanu, vienlaikus nodrošinot, ka repozitorijā glabātais precīzi atbilst tam, kas darbojas ražošanā, tad es domāju, ka šis raksts jūs varētu interesēt.

Priekšnosacījumi

Paredzams, ka šī raksta lasītājam būs pamatzināšanas par komandrindu un Bash skriptu rakstīšanu. Turklāt viņam būs nepieciešami konti Travis CI и Dokera centrmezgls.

Mērķi

Es neteikšu, ka šo rakstu var bez ierunām saukt par "pamācību". Šis drīzāk ir dokuments, kurā es stāstu par to, ko esmu iemācījies, un aprakstu procesu, kas man ir piemērots testēšanai un koda izvietošanai ražošanā, kas tiek veikts vienā automatizētā piegājienā.

Tā beidzās mana darbplūsma.

Par kodu, kas ievietots jebkurā repozitorija filiālē, izņemot master, tiek veiktas šādas darbības:

• Sākas projekta izveide uz Travis CI.
• Tiek veiktas visas vienības, integrācijas un end-to-end pārbaudes.

Tikai kodam, kas ietilpst master, tiek veiktas šādas darbības:

• Viss iepriekš minētais, kā arī...
• Docker attēla izveide, pamatojoties uz pašreizējo kodu, iestatījumiem un vidi.
• Attēla izvietošana Docker Hub.
• Savienojums ar ražošanas serveri.
• Attēla augšupielāde no Docker Hub serverī.
• Pašreizējā konteinera apturēšana un jauna sākšana, pamatojoties uz jauno attēlu.

Ja jūs absolūti neko nezināt par Docker, attēliem un konteineriem, neuztraucieties. Es jums par to visu pastāstīšu.

Kas ir CI/CD?

Saīsinājums CI/CD nozīmē “nepārtraukta integrācija/nepārtraukta izvietošana”.

▍Nepārtraukta integrācija

Nepārtraukta integrācija ir process, kurā izstrādātāji uzņemas saistības projekta galvenajā pirmkoda krātuvē (parasti filiālē master). Tajā pašā laikā koda kvalitāte tiek nodrošināta ar automatizētas pārbaudes palīdzību.

▍Nepārtraukta izvietošana

Nepārtraukta izvietošana ir bieža, automatizēta koda izvietošana ražošanā. CI/CD akronīma otrā daļa dažreiz tiek rakstīta kā “nepārtraukta piegāde”. Tas būtībā ir tas pats, kas “nepārtraukta izvietošana”, bet “nepārtraukta piegāde” nozīmē nepieciešamību manuāli apstiprināt izmaiņas pirms projekta izvietošanas procesa sākšanas.

Darba sākšana

Lietotne, kuru es izmantoju, lai to visu iemācītos, saucas Ņemt vērā. Šis ir tīmekļa projekts, pie kura es strādāju, un tas ir paredzēts piezīmju veikšanai. Sākumā es mēģināju darīt JAMSsteck-projekts vai tikai priekšgala lietojumprogramma bez servera, lai izmantotu tā piedāvātās standarta mitināšanas un projektu izvietošanas iespējas netlify. Pieaugot lietojumprogrammas sarežģītībai, man bija jāizveido tā servera daļa, kas nozīmēja, ka man bija jāformulē sava stratēģija automatizētai integrācijai un projekta automatizētai izvietošanai.

Manā gadījumā lietojumprogramma ir Express serveris, kas darbojas Node.js vidē, apkalpo vienas lapas React lietojumprogrammu un atbalsta drošu servera puses API. Šī arhitektūra seko stratēģijai, kas atrodama šis Pilna kaudzes autentifikācijas rokasgrāmata.

Es konsultējos ar draugs, kurš ir automatizācijas eksperts, un jautāja viņam, kas man jādara, lai tas viss darbotos tā, kā es vēlos. Viņš man sniedza ideju par to, kādai vajadzētu izskatīties automatizētai darbplūsmai, kas izklāstīta šī raksta sadaļā Mērķi. Šo mērķu sasniegšana nozīmēja, ka man bija jāizdomā, kā izmantot Docker.

dokers

Docker ir rīks, kas, pateicoties konteinerizācijas tehnoloģijai, ļauj viegli izplatīt, izvietot un palaist lietojumprogrammas vienā vidē, pat ja pati Docker platforma darbojas dažādās vidēs. Pirmkārt, man vajadzēja apgūt Docker komandrindas rīkus (CLI). instrukcija Docker instalēšanas rokasgrāmatu nevar saukt par ļoti skaidru un saprotamu, taču no tās var uzzināt, ka, lai veiktu pirmo instalēšanas soli, ir nepieciešams lejupielādēt Docker Desktop (operētājsistēmai Mac vai Windows).

Docker Hub ir aptuveni tas pats, kas GitHub git krātuvēm vai reģistram npm JavaScript pakotnēm. Šī ir tiešsaistes Docker attēlu krātuve. Tas ir tas, ar ko savieno Docker Desktop.

Tātad, lai sāktu darbu ar Docker, jums ir jāveic divas darbības:

• Komplekts Docker darbvirsma.
• Reģistrējieties Dokera centrmezgls.

Pēc tam varat pārbaudīt, vai Docker CLI darbojas, izpildot šo komandu, lai pārbaudītu Docker versiju:

docker -v

Pēc tam piesakieties Docker Hub, ievadot savu lietotājvārdu un paroli, kad tiek prasīts:

docker login

Lai izmantotu Docker, jums ir jāsaprot attēlu un konteineru jēdzieni.

▍Attēli

Attēls ir kaut kas līdzīgs projektam, kurā ir instrukcijas konteinera salikšanai. Šis ir nemainīgs lietojumprogrammas failu sistēmas un iestatījumu momentuzņēmums. Izstrādātāji var viegli koplietot attēlus.

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

Šī komanda izvadīs tabulu ar šādu galveni:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

Tālāk mēs apskatīsim dažus komandu piemērus tādā pašā formātā - vispirms ir komanda ar komentāru un pēc tam piemērs tam, ko tā var izvadīt.

▍Konteineri

Konteiners ir izpildāma pakotne, kurā ir viss nepieciešamais lietojumprogrammas palaišanai. Lietojumprogramma ar šo pieeju vienmēr darbosies vienādi neatkarīgi no infrastruktūras: izolētā vidē un tajā pašā vidē. Lieta ir tāda, ka viena un tā paša attēla gadījumi tiek palaisti dažādās vidēs.

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

▍ Birkas

Tags ir norāde uz konkrētu attēla versiju.

▍Ātra atsauce uz Docker komandām

Šeit ir pārskats par dažām biežāk lietotajām Docker komandām.

Komanda

Konteksts

efekts

dokera uzbūve

Attēls

Attēla izveide no Dockerfile

docker tag

Attēls

Attēlu marķēšana

docker attēlus

Attēls

Sarakstu attēli

docker palaist

Konteiners

Konteinera palaišana, pamatojoties uz attēlu

docker push

Attēls

Attēla augšupielāde reģistrā

docker-pull

Attēls

Notiek attēla ielāde no reģistra

docker ps

Konteiners

Saraksts konteineri

docker sistēmas plūme

Attēls/konteiners

Nelietoto konteineru un attēlu noņemšana

▍Dokera fails

Es zinu, kā lokāli palaist ražošanas lietojumprogrammu. Man ir Webpack konfigurācija, kas izstrādāta, lai izveidotu gatavu React lietojumprogrammu. Tālāk man ir komanda, kas portā startē Node.js serveri 5000. Tas izskatās šādi:

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

Jāpiebilst, ka man nav šī materiāla pielietojuma parauga. Bet šeit eksperimentiem der jebkura vienkārša Node lietojumprogramma.

Lai izmantotu konteineru, jums būs jāsniedz norādījumi uzņēmumam Docker. Tas tiek darīts, izmantojot failu ar nosaukumu Dockerfile, kas atrodas projekta saknes direktorijā. Šis fails sākumā šķiet diezgan nesaprotams.

Bet tas, ko tas satur, tikai apraksta ar īpašām komandām kaut ko līdzīgu darba vides izveidošanai. Šeit ir dažas no šīm komandām:

• NO — Šī komanda palaiž failu. Tas norāda bāzes attēlu, uz kura ir izveidots konteiners.
• COPY — failu kopēšana no lokālā avota konteinerā.
• DARBA DIREKTĪVĀ — Darba direktorija iestatīšana šādām komandām.
• RUN - Palaist komandas.
• ATKLĀJOT — Portu iestatījumi.
• IEEJAS PUNKTS — norāde par izpildāmo komandu.

Dockerfile varētu izskatīties apmēram šādi:

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

Atkarībā no izvēlētā pamata attēla, iespējams, būs jāinstalē papildu atkarības. Fakts ir tāds, ka daži pamata attēli (piemēram, Node Alpine Linux) ir izveidoti ar mērķi padarīt tos pēc iespējas kompaktākus. Tā rezultātā viņiem var nebūt dažas no tām programmām, kuras jūs gaidāt.

▍Konteinera izveide, marķēšana un darbināšana

Vietējā konteinera montāža un palaišana notiek pēc tam Dockerfile, uzdevumi ir pavisam vienkārši. Pirms attēla nosūtīšanas uz Docker Hub, tas ir jāpārbauda lokāli.

▍ Montāža

Vispirms jums ir jāsavāc attēls, norādot nosaukumu un pēc izvēles tagu (ja atzīme nav norādīta, sistēma attēlam automātiski piešķirs atzīmi latest).

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

Pēc šīs komandas palaišanas varat skatīties, kā Docker veido attēlu.

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

Būvēšana var ilgt dažas minūtes — tas viss ir atkarīgs no tā, cik daudz atkarību jums ir. Kad izveide ir pabeigta, varat palaist komandu docker images un apskatiet sava jaunā attēla aprakstu.

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

▍Palaist

Attēls ir izveidots. Tas nozīmē, ka varat palaist konteineru, pamatojoties uz to. Tā kā es vēlos piekļūt lietojumprogrammai, kas darbojas konteinerā vietnē localhost:5000, es, pāra kreisajā pusē 5000:5000 nākamajā instalētajā komandā 5000. Labajā pusē ir konteinera ports.

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

Tagad, kad konteiners ir izveidots un darbojas, varat izmantot komandu docker ps lai apskatītu informāciju par šo konteineru (vai arī varat izmantot komandu docker ps -a, kurā tiek parādīta informācija par visiem konteineriem, ne tikai tiem, kas darbojas).

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

Ja tagad dodaties uz adresi localhost:5000 — jūs varat redzēt darbīgas lietojumprogrammas lapu, kas izskatās tieši tāpat kā lietojumprogrammas lapa, kas darbojas ražošanas vidē.

▍Atzīmēšana un publicēšana

Lai izmantotu kādu no izveidotajiem attēliem ražošanas serverī, mums ir jāspēj lejupielādēt šo attēlu no Docker Hub. Tas nozīmē, ka vispirms Docker Hub ir jāizveido projekta repozitorijs. Pēc tam mums būs vieta, kur mēs varam nosūtīt attēlu. Attēls ir jāpārdēvē, lai tā nosaukums sāktos ar mūsu Docker Hub lietotājvārdu. Tam seko repozitorija nosaukums. Nosaukuma beigās var ievietot jebkuru tagu. Tālāk ir sniegts piemērs attēlu nosaukšanai, izmantojot šo shēmu.

Tagad varat izveidot attēlu ar jaunu nosaukumu un palaist komandu docker push lai to nosūtītu uz Docker Hub repozitoriju.

docker build -t <username>/<repository>:<tag> .
docker tag <username>/<repository>:<tag> <username>/<repository>:latest
docker push <username>/<repository>:<tag>

# На практике это может выглядеть, например, так:
docker build -t user/app:v1.0.0 .
docker tag user/app:v1.0.0 user/app:latest
docker push user/app:v1.0.0

Ja viss noritēs labi, attēls būs pieejams Docker Hub, un to varēs viegli augšupielādēt serverī vai pārsūtīt citiem izstrādātājiem.

Nākamās darbības

Šobrīd esam pārliecinājušies, ka lietojumprogramma Docker konteinera veidā darbojas lokāli. Mēs esam augšupielādējuši konteineru Docker Hub. Tas viss nozīmē, ka mēs jau esam ļoti labi virzījušies uz savu mērķi. Tagad mums jāatrisina vēl divi jautājumi:

• CI rīka iestatīšana koda testēšanai un izvietošanai.
• Ražošanas servera iestatīšana, lai tas varētu lejupielādēt un palaist mūsu kodu.

Mūsu gadījumā mēs izmantojam Travis CI. Kā serveris - DitigalOcean.

Jāatzīmē, ka šeit varat izmantot citu pakalpojumu kombināciju. Piemēram, Travis CI vietā varat izmantot CircleCI vai Github Actions. Un DigitalOcean vietā - AWS vai Linode.

Mēs nolēmām sadarboties ar Travis CI, un man šajā pakalpojumā jau ir kaut kas konfigurēts. Tāpēc tagad īsi runāšu par to, kā to sagatavot darbam.

Travis CI

Travis CI ir rīks koda testēšanai un izvietošanai. Es negribētu iedziļināties Travis CI izveides sarežģītībā, jo katrs projekts ir unikāls, un tas nedos lielu labumu. Bet es apskatīšu pamatus, lai jūs varētu sākt, ja nolemjat izmantot Travis CI. Neatkarīgi no tā, vai izvēlaties Travis CI, CircleCI, Jenkins vai kaut ko citu, līdzīgas konfigurācijas metodes tiks izmantotas visur.

Lai sāktu darbu ar Travis CI, dodieties uz projekta vietne un izveidot kontu. Pēc tam integrējiet Travis CI savā GitHub kontā. Iestatot sistēmu, jums būs jānorāda repozitorijs, ar kuru vēlaties automatizēt darbu, un jāiespējo piekļuve tai. (Es izmantoju GitHub, bet esmu pārliecināts, ka Travis CI var integrēties ar BitBucket, GitLab un citiem līdzīgiem pakalpojumiem).

Katru reizi, kad tiek startēts Travis CI, tiek palaists serveris, izpildot konfigurācijas failā norādītās komandas, tostarp izvietojot atbilstošās repozitorija filiāles.

▍Darba dzīves cikls

Izsaukts Travis CI konfigurācijas fails .travis.yml un glabājas projekta saknes direktorijā, atbalsta notikumu koncepciju dzīves cikls uzdevumus. Šie notikumi ir uzskaitīti secībā, kādā tie notiek:

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

▍Pārbaude

Konfigurācijas failā es konfigurēšu vietējo Travis CI serveri. Es izvēlējos Node 12 kā valodu un liku sistēmai instalēt Docker lietošanai nepieciešamās atkarības.

Viss, kas ir norādīts .travis.yml, tiks izpildīts, kad visi izvilkšanas pieprasījumi tiks veikti visiem repozitorija filiālēm, ja vien nav norādīts citādi. Šī ir noderīga funkcija, jo tā nozīmē, ka mēs varam pārbaudīt visu kodu, kas nonāk repozitorijā. Tas ļauj jums zināt, vai kods ir gatavs rakstīšanai filiālē. master, un vai tas izjauks projekta veidošanas procesu. Šajā globālajā konfigurācijā es visu instalēju lokāli, fonā palaižu Webpack dev serveri (tā ir manas darbplūsmas funkcija) un izpildu testus.

Ja vēlaties, lai jūsu krātuvē tiktu rādītas pārbaudes pārklājuma ikonas, šeit Jūs varat atrast īsus norādījumus par Jest, Travis CI un Overalls lietošanu šīs informācijas apkopošanai un attēlošanai.

Tātad šeit ir faila saturs .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

Šeit beidzas darbības, kas tiek veiktas visiem repozitorija atzariem un izvilkšanas pieprasījumiem.

▍Izvietošana

Pamatojoties uz pieņēmumu, ka visas automatizētās pārbaudes ir veiksmīgi pabeigtas, mēs varam izvietot kodu ražošanas serverī, kas nav obligāti. Tā kā mēs vēlamies to darīt tikai kodam no filiāles master, mēs sniedzam sistēmai atbilstošus norādījumus izvietošanas iestatījumos. Pirms mēģināt izmantot kodu, kuru mēs turpmāk aplūkosim jūsu projektā, es vēlos jūs brīdināt, ka jums ir nepieciešams īsts skripts, kas tiek izsaukts izvietošanai.

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

Izvietošanas skripts atrisina divas problēmas:

• Izveidojiet, atzīmējiet un nosūtiet attēlu uz Docker Hub, izmantojot CI rīku (mūsu gadījumā Travis CI).
• Attēla ielāde serverī, vecā konteinera apturēšana un jauna palaišana (mūsu gadījumā serveris darbojas DigitalOcean platformā).

Pirmkārt, jums ir jāiestata automātisks process attēla izveidei, marķēšanai un nosūtīšanai uz Docker Hub. Tas viss ir ļoti līdzīgs tam, ko jau esam izdarījuši manuāli, izņemot to, ka mums ir nepieciešama stratēģija unikālu tagu piešķiršanai attēliem un pieteikšanās automatizēšanai. Man bija grūtības ar dažām izvietošanas skripta detaļām, piemēram, marķēšanas stratēģiju, pieteikšanos, SSH atslēgas kodējumu, SSH savienojuma izveidi. Bet par laimi mans puisis ļoti labi pārvalda bash, tāpat kā daudzas citas lietas. Viņš man palīdzēja uzrakstīt šo scenāriju.

Tātad, skripta pirmā daļa ir attēla augšupielāde Docker Hub. Tas ir diezgan viegli izdarāms. Manā izmantotā marķēšanas shēma ietver git hash un git taga apvienošanu, ja tāds pastāv. Tas nodrošina, ka tags ir unikāls, un ļauj vieglāk identificēt komplektāciju, uz kuras tas ir balstīts. DOCKER_USERNAME и DOCKER_PASSWORD ir lietotāja vides mainīgie, kurus var iestatīt, izmantojot Travis CI saskarni. Travis CI automātiski apstrādās sensitīvos datus, lai tie nenonāktu nepareizās rokās.

Šeit ir skripta pirmā daļa 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}

Kāda būs skripta otrā daļa, ir pilnībā atkarīgs no tā, kādu resursdatoru jūs izmantojat un kā tiek organizēts savienojums ar to. Manā gadījumā, tā kā es izmantoju Digital Ocean, es izmantoju komandas, lai izveidotu savienojumu ar serveri doktl. Strādājot ar AWS, tiks izmantota utilīta aws, un tā tālāk.

Servera iestatīšana nebija īpaši sarežģīta. Tātad, es iestatīju pilienu, pamatojoties uz pamata attēlu. Jāatzīmē, ka sistēmai, kuru es izvēlējos, ir nepieciešama vienreizēja manuāla Docker instalēšana un vienreizēja manuāla Docker palaišana. Es izmantoju Ubuntu 18.04, lai instalētu Docker, tāpēc, ja jūs izmantojat arī Ubuntu, lai darītu to pašu, varat vienkārši sekot šis vienkāršs ceļvedis.

Es šeit nerunāju par konkrētām pakalpojuma komandām, jo ​​šis aspekts dažādos gadījumos var ievērojami atšķirties. Es tikai sniegšu vispārīgu darbības plānu, kas jāveic pēc savienojuma izveides, izmantojot SSH, ar serveri, kurā projekts tiks izvietots:

• Mums ir jāatrod konteiners, kas pašlaik darbojas, un jāpārtrauc tas.
• Pēc tam fonā jāpalaiž jauns konteiners.
• Jums būs jāiestata servera lokālais ports uz 80 - tas ļaus jums ievadīt vietni tādā adresē kā example.com, nenorādot portu, nevis izmantojot adresi, piemēram, example.com:5000.
• Visbeidzot, jums ir jāizdzēš visi vecie konteineri un attēli.

Šeit ir skripta turpinājums.

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

Dažas lietas, kurām jāpievērš uzmanība

Iespējams, ka, izveidojot savienojumu ar serveri, izmantojot SSH no Travis CI, jūs redzēsit brīdinājumu, kas neļaus jums turpināt instalēšanu, jo sistēma gaidīs lietotāja atbildi.

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

Es uzzināju, ka virknes taustiņu var iekodēt base64, lai saglabātu to formā, kurā ar to var ērti un droši strādāt. Instalēšanas stadijā varat atšifrēt publisko atslēgu un ierakstīt to failā known_hosts lai atbrīvotos no iepriekš minētās kļūdas.

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

Praksē šī komanda varētu izskatīties šādi:

echo "123.45.67.89 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3
Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA
t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En
mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
NrRFi9wrf+M7Q== [email protected]" | base64

Un lūk, ko tas rada - base64 kodētu virkni:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Šeit ir iepriekš minētā komanda

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

To pašu pieeju var izmantot ar privāto atslēgu, veidojot savienojumu, jo, lai piekļūtu serverim, var būt nepieciešama privātā atslēga. Strādājot ar atslēgu, jums vienkārši jāpārliecinās, ka tā tiek droši saglabāta Travis CI vides mainīgajā un ka tā nekur netiek rādīta.

Vēl viena lieta, kas jāņem vērā, ir tāda, ka jums var būt nepieciešams palaist visu izvietošanas skriptu kā vienu rindiņu, piemēram, - ar doctl. Tas var prasīt papildu pūles.

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

TLS/SSL un slodzes līdzsvarošana

Kad es izdarīju visu iepriekš minēto, pēdējā problēma, ar kuru es saskāros, bija tā, ka serverim nebija SSL. Tā kā es izmantoju Node.js serveri, lai piespiestu darbs reversais starpniekserveris Nginx un Let’s Encrypt, jums ir daudz jāpieliek.

Es patiešām negribēju visu šo SSL konfigurāciju veikt manuāli, tāpēc es vienkārši izveidoju slodzes līdzsvarotāju un ierakstīju tā informāciju DNS. Piemēram, DigitalOcean gadījumā automātiski atjaunojoša pašparakstīta sertifikāta izveide slodzes balansētājā ir vienkārša, bezmaksas un ātra procedūra. Šai pieejai ir papildu priekšrocība, ka tā ļauj ļoti viegli iestatīt SSL vairākos serveros, kas vajadzības gadījumā darbojas aiz slodzes līdzsvarotāja. Tas ļauj pašiem serveriem vispār “nedomāt” par SSL, bet tajā pašā laikā izmantot portu kā parasti 80. Tāpēc SSL iestatīšana slodzes balansētājā ir daudz vienkāršāka un ērtāka nekā alternatīvas SSL iestatīšanas metodes.

Tagad varat aizvērt visus servera portus, kas pieņem ienākošos savienojumus, izņemot portu 80, ko izmanto, lai sazinātos ar slodzes balansētāju un portu 22 par SSH. Rezultātā mēģinājums tieši piekļūt serverim visos portos, izņemot šos divus, neizdosies.

Rezultāti

Kad es izdarīju visu, par ko runāju šajā materiālā, ne Docker platforma, ne automatizēto CI/CD ķēžu koncepcijas mani vairs nebiedēja. Man izdevās izveidot nepārtrauktu integrācijas ķēdi, kuras laikā kods tiek pārbaudīts, pirms tas nonāk ražošanā, un kods tiek automātiski izvietots serverī. Tas viss man joprojām ir salīdzinoši jauns, un esmu pārliecināts, ka ir veidi, kā uzlabot automatizēto darbplūsmu un padarīt to efektīvāku. Tāpēc, ja jums ir kādas idejas par šo jautājumu, lūdzu, dariet man to zināmu. mani zināt. Es ceru, ka šis raksts jums ir palīdzējis jūsu centienos. Es gribu ticēt, ka pēc tā izlasīšanas jūs uzzinājāt tikpat daudz, cik es uzzināju, izdomājot visu, par ko es tajā runāju.

PS Mūsos tirgus laukums ir attēls dokers, kuru var instalēt ar vienu klikšķi. Konteineru darbību varat pārbaudīt plkst VPS. Visiem jaunajiem klientiem tiek dota 3 dienu pārbaude bez maksas.

Cienījamie lasītāji! Vai savos projektos izmantojat CI/CD tehnoloģijas?

Avots: www.habr.com