CI/CD grandinės kūrimas ir darbo su Docker automatizavimas

Pirmąsias savo svetaines parašiau 90-ųjų pabaigoje. Tada buvo labai lengva juos sutvarkyti. Kažkokiame bendrame priegloboje buvo Apache serveris, prie šio serverio galėjai prisijungti per FTP parašydamas kažką panašaus ftp://ftp.example.com. Tada reikėjo įvesti savo vardą ir slaptažodį bei įkelti failus į serverį. Buvo kiti laikai, tada viskas buvo paprasčiau nei dabar.

Per du dešimtmečius nuo to laiko viskas labai pasikeitė. Tinklalapiai tapo sudėtingesni, jas reikia surinkti prieš išleidžiant į gamybą. Vienas serveris tapo daugybe serverių, veikiančių už apkrovos balansavimo įrenginių, o versijų valdymo sistemų naudojimas tapo įprastas.

Savo asmeniniam projektui turėjau specialią konfigūraciją. Ir aš žinojau, kad man reikia galimybės įdiegti svetainę gamyboje, atliekant tik vieną veiksmą: rašant kodą į filialą master „GitHub“. Be to, žinojau, kad norėdamas užtikrinti savo mažos žiniatinklio programos veikimą, nenoriu nei valdyti didžiulio Kubernetes klasterio, nei naudoti Docker Swarm technologijos, nei prižiūrėti serverių parko su podais, agentais ir visokiais kitais. sudėtingumo. Kad pasiekčiau tikslą kuo lengviau dirbti, man reikėjo susipažinti su CI/CD.

Jei turite nedidelį projektą (šiuo atveju Node.js projektą) ir norėtumėte sužinoti, kaip automatizuoti šio projekto diegimą, tuo pačiu užtikrinant, kad saugykloje saugoma informacija tiksliai atitiktų tai, kas veikia gamyboje, tada aš manote, kad jums gali būti įdomus šis straipsnis.

Būtinos sąlygos

Tikimasi, kad šio straipsnio skaitytojas išmanys komandų eilutę ir Bash scenarijų rašymą. Be to, jam reikės sąskaitų Travisas CI и „Docker Hub“.

Tikslai

Nesakysiu, kad šis straipsnis gali būti besąlygiškai vadinamas „mokomuoju mokymu“. Tai daugiau dokumentas, kuriame aš kalbu apie tai, ko išmokau, ir aprašysiu man tinkantį procesą, kad būtų galima išbandyti ir įdiegti kodą į gamybą, atliekamą vienu automatiniu būdu.

Taip baigėsi mano darbo eiga.

Kodui, paskelbtam bet kuriam saugyklos filialui, išskyrus master, atliekami šie veiksmai:

• Prasideda Travis CI kūrimo projektas.
• Atliekami visi vienetiniai, integravimo ir galutiniai testai.

Tik kodui, kuris patenka į master, atliekami šie veiksmai:

• Viskas, kas paminėta aukščiau, plius...
• „Docker“ vaizdo kūrimas pagal dabartinį kodą, nustatymus ir aplinką.
• Vaizdo diegimas „Docker Hub“.
• Prisijungimas prie gamybos serverio.
• Vaizdo įkėlimas iš „Docker Hub“ į serverį.
• Sustabdomas dabartinis sudėtinis rodinys ir pradedamas naujas pagal naują vaizdą.

Jei visiškai nieko nežinote apie „Docker“, vaizdus ir konteinerius, nesijaudinkite. Aš tau viską papasakosiu.

Kas yra CI/CD?

Santrumpa CI/CD reiškia „nuolatinis integravimas/nepertraukiamas diegimas“.

▍Nuolatinė integracija

Nuolatinis integravimas yra procesas, kurio metu kūrėjai įsipareigoja naudoti pagrindinę projekto šaltinio kodo saugyklą (dažniausiai filialą master). Tuo pačiu metu kodo kokybė užtikrinama automatizuotu testavimu.

▍Nuolatinis diegimas

Nuolatinis diegimas yra dažnas, automatizuotas kodo diegimas gamyboje. Antroji CI / CD akronimo dalis kartais rašoma kaip „nuolatinis pristatymas“. Tai iš esmės tas pats, kas „nuolatinis diegimas“, tačiau „nuolatinis pristatymas“ reiškia, kad prieš pradedant projekto diegimo procesą reikia rankiniu būdu patvirtinti pakeitimus.

Darbo pradžia

Programėlė, kuria visa tai išmokau, vadinasi Užsirašyti. Tai internetinis projektas, prie kurio dirbu, skirtas užrašams daryti. Iš pradžių bandžiau daryti „JAMStack“-projektas arba tiesiog priekinė programa be serverio, kad galėtumėte pasinaudoti jo siūlomomis standartinėmis prieglobos ir projekto diegimo galimybėmis „Netlify“. Augant programos sudėtingumui, man reikėjo sukurti jos serverio dalį, o tai reiškė, kad turėjau suformuluoti savo automatizuotos integracijos ir automatizuoto projekto diegimo strategiją.

Mano atveju, programa yra „Express“ serveris, veikiantis Node.js aplinkoje, aptarnaujantis vieno puslapio „React“ programą ir palaikantis saugią serverio API. Ši architektūra atitinka strategiją, kurią galima rasti tai Visas kamino autentifikavimo vadovas.

Pasitariau su drauge, kuris yra automatikos ekspertas, ir paklausė jo, ką turėčiau daryti, kad viskas veiktų taip, kaip noriu. Jis davė man idėją, kaip turėtų atrodyti automatizuota darbo eiga, aprašyta šio straipsnio skiltyje „Tikslai“. Turėdamas šiuos tikslus, turėjau išsiaiškinti, kaip naudoti „Docker“.

dokininkas

„Docker“ yra įrankis, kuris dėl konteinerizacijos technologijos leidžia lengvai paskirstyti, diegti ir paleisti programas toje pačioje aplinkoje, net jei pati „Docker“ platforma veikia skirtingose ​​aplinkose. Pirmiausia turėjau pasinaudoti „Docker“ komandų eilutės įrankiais (CLI). nurodymas „Docker“ diegimo vadovas negali būti vadinamas labai aiškiu ir suprantamu, tačiau iš jo galite sužinoti, kad norint žengti pirmąjį diegimo žingsnį, reikia atsisiųsti „Docker Desktop“ („Mac“ arba „Windows“).

„Docker Hub“ yra maždaug tas pats, kas GitHub Git saugykloms arba registrui npm „JavaScript“ paketams. Tai internetinė „Docker“ vaizdų saugykla. Prie to prisijungia „Docker Desktop“.

Taigi, norėdami pradėti naudoti „Docker“, turite atlikti du dalykus:

• Nustatyti „Docker“ darbalaukis.
• Registruokitės „Docker Hub“.

Po to galite patikrinti, ar „Docker“ CLI veikia, vykdydami šią komandą, kad patikrintumėte „Docker“ versiją:

docker -v

Tada prisijunkite prie „Docker Hub“ įvesdami vartotojo vardą ir slaptažodį, kai to paklaus:

docker login

Norėdami naudoti „Docker“, turite suprasti vaizdų ir konteinerių sąvokas.

▍Vaizdai

Vaizdas yra kažkas panašaus į brėžinį, kuriame yra konteinerio surinkimo instrukcijos. Tai yra nepakeičiamas programos failų sistemos ir nustatymų momentinis vaizdas. Kūrėjai gali lengvai dalytis vaizdais.

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

Ši komanda išves lentelę su šia antrašte:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

Toliau apžvelgsime keletą to paties formato komandų pavyzdžių – pirmiausia yra komanda su komentaru, o tada pavyzdys, ką ji gali išvesti.

▍ Konteineriai

Konteineris yra vykdomasis paketas, kuriame yra viskas, ko reikia programai paleisti. Taikant šį metodą programa visada veiks taip pat, nepaisant infrastruktūros: izoliuotoje aplinkoje ir toje pačioje aplinkoje. Esmė ta, kad to paties vaizdo egzemplioriai paleidžiami skirtingose ​​aplinkose.

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

▍Žymos

Žyma yra konkrečios vaizdo versijos nuoroda.

▍Greita nuoroda į Docker komandas

Čia pateikiama kai kurių dažniausiai naudojamų „Docker“ komandų apžvalga.

Komanda

Kontekstas

poveikis

dokerio konstrukcija

Vaizdas

Vaizdo kūrimas iš Dockerfile

dokerio žyma

Vaizdas

Vaizdo žymėjimas

dockerio vaizdai

Vaizdas

Sąrašo vaizdai

Docker paleisti

Konteineris

Sudėtinio rodinio paleidimas pagal vaizdą

doko stumti

Vaizdas

Vaizdo įkėlimas į registrą

dokeris traukimas

Vaizdas

Vaizdo įkėlimas iš registro

docker ps

Konteineris

Konteinerių sąrašas

Docker sistemos slyva

Vaizdas / sudėtinis rodinys

Nenaudojamų konteinerių ir vaizdų pašalinimas

▍Docker failas

Žinau, kaip vietoje paleisti gamybinę programą. Turiu Webpack konfigūraciją, skirtą sukurti paruoštą React programą. Tada turiu komandą, kuri paleidžia Node.js pagrįstą serverį prie prievado 5000. Tai atrodo taip:

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

Reikėtų pažymėti, kad neturiu šios medžiagos pavyzdžio. Bet čia eksperimentams tiks bet kuri paprasta „Node“ programa.

Norėdami naudoti konteinerį, turėsite duoti nurodymus „Docker“. Tai atliekama naudojant failą, vadinamą Dockerfile, esantis projekto šakniniame kataloge. Šis failas iš pradžių atrodo gana nesuprantamas.

Tačiau tai, kas jame yra, su specialiomis komandomis apibūdina tik kažką panašaus į darbo aplinkos nustatymą. Štai keletas iš šių komandų:

• IŠ — Ši komanda paleidžia failą. Jis nurodo pagrindinį vaizdą, ant kurio pastatytas konteineris.
• KOPIJA - Failų kopijavimas iš vietinio šaltinio į konteinerį.
• DARBO VADOVAS — Darbo katalogo nustatymas šioms komandoms.
• RUN - Vykdyti komandas.
• POVEIKIS — Prievado nustatymai.
• ĮEJIMAS — Vykdytinos komandos nurodymas.

Dockerfile gali atrodyti maždaug taip:

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

Atsižvelgiant į pasirinktą pagrindinį vaizdą, gali tekti įdiegti papildomų priklausomybių. Faktas yra tas, kad kai kurie pagrindiniai vaizdai (pvz., Node Alpine Linux) yra sukurti siekiant juos padaryti kuo kompaktiškesnius. Dėl to jie gali neturėti kai kurių programų, kurių tikitės.

▍Sudėtinio rodinio kūrimas, žymėjimas ir paleidimas

Vietinis konteinerio surinkimas ir paleidimas yra po to Dockerfile, užduotys gana paprastos. Prieš perkeldami vaizdą į Docker Hub, turite jį išbandyti vietoje.

▍Surinkimas

Pirmiausia reikia surinkti vaizdas, nurodant pavadinimą ir, pasirinktinai, žymą (jei žyma nenurodyta, sistema automatiškai priskirs žymą vaizdui latest).

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

Paleidę šią komandą galite žiūrėti, kaip „Docker“ kuria vaizdą.

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

Sukūrimas gali užtrukti keletą minučių – viskas priklauso nuo to, kiek priklausomybių turite. Kai kūrimas bus baigtas, galite paleisti komandą docker images ir pažiūrėkite į savo naujo vaizdo aprašymą.

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

▍Paleisti

Vaizdas sukurtas. Tai reiškia, kad pagal jį galite paleisti konteinerį. Kadangi noriu turėti prieigą prie programos, veikiančios konteineryje adresu localhost:5000, aš, kairėje poros pusėje 5000:5000 kitoje įdiegtoje komandoje 5000. Dešinėje pusėje yra konteinerio prievadas.

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

Dabar, kai konteineris sukurtas ir paleistas, galite naudoti komandą docker ps norėdami peržiūrėti informaciją apie šį konteinerį (arba galite naudoti komandą docker ps -a, kuriame rodoma informacija apie visus konteinerius, ne tik veikiančius).

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

Jei dabar eisite adresu localhost:5000 – galite matyti veikiančios programos puslapį, kuris atrodo lygiai taip pat, kaip ir gamybinėje aplinkoje veikiančios programos puslapis.

▍Žymėjimas ir publikavimas

Kad galėtume naudoti vieną iš sukurtų vaizdų gamybos serveryje, turime turėti galimybę atsisiųsti šį vaizdą iš Docker Hub. Tai reiškia, kad pirmiausia turite sukurti projekto saugyklą „Docker Hub“. Po to turėsime vietą, kur galėsime siųsti vaizdą. Vaizdas turi būti pervardytas taip, kad jo pavadinimas prasidėtų mūsų Docker Hub vartotojo vardu. Po to turėtų būti nurodytas saugyklos pavadinimas. Vardo pabaigoje galima įdėti bet kokią žymą. Žemiau pateikiamas vaizdų pavadinimo naudojant šią schemą pavyzdys.

Dabar galite sukurti vaizdą nauju pavadinimu ir paleisti komandą docker push kad nustumtumėte jį į „Docker Hub“ saugyklą.

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

Jei viskas klostysis gerai, vaizdas bus pasiekiamas „Docker Hub“ ir bus lengvai įkeltas į serverį arba perduotas kitiems kūrėjams.

Kitas žingsnis

Iki šiol patikrinome, ar programa „Docker“ konteinerio pavidalu veikia vietoje. Įkėlėme konteinerį į „Docker Hub“. Visa tai reiškia, kad mes jau padarėme labai gerą pažangą savo tikslo link. Dabar turime išspręsti dar du klausimus:

• CI įrankio, skirto kodui išbandyti ir diegti, nustatymas.
• Gamybos serverio nustatymas, kad jis galėtų atsisiųsti ir paleisti mūsų kodą.

Mūsų atveju mes naudojame Travisas CI. Kaip serveris - DitigalOcean.

Reikėtų pažymėti, kad čia galite naudoti kitą paslaugų derinį. Pavyzdžiui, vietoj Travis CI galite naudoti CircleCI arba Github Actions. O vietoj DigitalOcean – AWS arba Linode.

Nusprendėme dirbti su „Travis CI“, ir aš jau turiu kažką sukonfigūruotas šioje paslaugoje. Todėl dabar trumpai pakalbėsiu apie tai, kaip jį paruošti darbui.

Travisas CI

Travis CI yra kodo testavimo ir diegimo įrankis. Nenorėčiau gilintis į „Travis CI“ kūrimo subtilybes, nes kiekvienas projektas yra unikalus ir tai neduos daug naudos. Tačiau apžvelgsiu pagrindus, kad galėtumėte pradėti, jei nuspręsite naudoti „Travis CI“. Nesvarbu, ar pasirinksite Travis CI, CircleCI, Jenkins ar ką nors kita, panašūs konfigūravimo metodai bus naudojami visur.

Norėdami pradėti naudotis Travis CI, eikite į projekto svetainė ir susikurti paskyrą. Tada integruokite Travis CI su savo GitHub paskyra. Nustatydami sistemą turėsite nurodyti saugyklą, su kuria norite automatizuoti darbą ir įgalinti prieigą prie jos. (Naudoju „GitHub“, bet esu tikras, kad „Travis CI“ gali integruotis su „BitBucket“, „GitLab“ ir kitomis panašiomis paslaugomis).

Kiekvieną kartą paleidus Travis CI, paleidžiamas serveris, kuris vykdo konfigūracijos faile nurodytas komandas, įskaitant atitinkamų saugyklos šakų diegimą.

▍Darbo gyvavimo ciklas

Travis CI konfigūracijos failas vadinamas .travis.yml ir saugomi projekto šakniniame kataloge, palaiko įvykių koncepciją gyvenimo ciklas užduotys. Šie įvykiai išvardyti tokia tvarka, kokia jie vyksta:

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

▍Testavimas

Konfigūracijos faile ketinu sukonfigūruoti vietinį Travis CI serverį. Kaip kalbą pasirinkau 12 mazgą ir liepiau sistemai įdiegti priklausomybes, reikalingas naudoti „Docker“.

Viskas, kas nurodyta .travis.yml, bus vykdomas, kai visos ištraukimo užklausos bus pateiktos visoms saugyklos šakoms, jei nenurodyta kitaip. Tai naudinga funkcija, nes tai reiškia, kad galime išbandyti visą į saugyklą patenkantį kodą. Tai leidžia sužinoti, ar kodas yra paruoštas rašyti filialui. masterir ar tai nesutrukdys projekto kūrimo procesui. Šioje visuotinėje konfigūracijoje aš viską įdiegiu vietoje, paleidžiu Webpack dev serverį fone (tai yra mano darbo eigos funkcija) ir atlieku testus.

Jei norite, kad saugykloje būtų rodomos bandomosios aprėpties piktogramos, čia Galite rasti trumpas instrukcijas, kaip naudoti Jest, Travis CI ir kombinezonus šiai informacijai rinkti ir rodyti.

Taigi čia yra failo turinys .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

Čia baigiasi veiksmai, kurie atliekami visoms saugyklos šakoms ir ištraukimo užklausoms.

▍Įdiegimas

Darydami prielaidą, kad visi automatizuoti testai buvo sėkmingai užbaigti, galime (nebūtina) įdiegti kodą gamybos serveryje. Kadangi norime tai padaryti tik kodui iš filialo master, mes pateikiame sistemai atitinkamas instrukcijas diegimo nustatymuose. Prieš bandydami naudoti kodą, kurį toliau apžvelgsime jūsų projekte, norėčiau jus įspėti, kad turite turėti tikrą scenarijų, iškviestą diegti.

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

Diegimo scenarijus išsprendžia dvi problemas:

• Sukurkite, pažymėkite ir nusiųskite vaizdą į Docker Hub naudodami CI įrankį (mūsų atveju Travis CI).
• Vaizdo įkėlimas į serverį, seno konteinerio sustabdymas ir naujo paleidimas (mūsų atveju serveris veikia DigitalOcean platformoje).

Pirmiausia turite nustatyti automatinį vaizdo kūrimo, žymėjimo ir perkėlimo į Docker Hub procesą. Visa tai labai panašu į tai, ką jau padarėme rankiniu būdu, išskyrus tai, kad mums reikia strategijos, kaip priskirti unikalias žymas vaizdams ir automatizuoti prisijungimus. Man kilo sunkumų dėl kai kurių diegimo scenarijaus detalių, tokių kaip žymėjimo strategija, prisijungimas, SSH rakto kodavimas, SSH ryšio užmezgimas. Bet laimei, mano vaikinas labai gerai moka su bash, kaip ir su daugeliu kitų dalykų. Jis man padėjo parašyti šį scenarijų.

Taigi, pirmoji scenarijaus dalis yra vaizdo įkėlimas į „Docker Hub“. Tai padaryti gana paprasta. Mano naudojama žymėjimo schema apima git maišos ir git žymos, jei tokia yra, derinimą. Taip užtikrinama, kad žyma būtų unikali, ir lengviau atpažinti agregatą, kurio pagrindu ji sukurta. DOCKER_USERNAME и DOCKER_PASSWORD yra vartotojo aplinkos kintamieji, kuriuos galima nustatyti naudojant Travis CI sąsają. „Travis CI“ automatiškai apdoros slaptus duomenis, kad jie nepatektų į netinkamas rankas.

Čia yra pirmoji scenarijaus dalis 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}

Kokia bus antroji scenarijaus dalis, visiškai priklauso nuo to, kokį pagrindinį kompiuterį naudojate ir kaip organizuotas ryšys su juo. Mano atveju, kadangi naudoju Digital Ocean, prisijungimui prie serverio naudoju komandas docl. Dirbant su AWS, bus naudojamas įrankis aws, ir taip toliau.

Serverio nustatymas nebuvo ypač sunkus. Taigi, aš nustatiau lašelį pagal pagrindinį vaizdą. Reikėtų pažymėti, kad mano pasirinktai sistemai reikia vieną kartą rankiniu būdu įdiegti „Docker“ ir vieną kartą rankiniu būdu paleisti „Docker“. „Docker“ įdiegimui naudojau „Ubuntu 18.04“, taigi, jei jūs taip pat naudojate „Ubuntu“, kad padarytumėte tą patį, galite tiesiog sekti tai paprastas vadovas.

Čia nekalbu apie konkrečias tarnybos komandas, nes šis aspektas įvairiais atvejais gali labai skirtis. Tiesiog pateiksiu bendrą veiksmų planą, kurį reikia atlikti prisijungus per SSH prie serverio, kuriame bus įdiegtas projektas:

• Turime rasti šiuo metu veikiantį konteinerį ir jį sustabdyti.
• Tada turite paleisti naują konteinerį fone.
• Turėsite nustatyti vietinį serverio prievadą į 80 - tai leis jums patekti į svetainę tokiu adresu kaip example.com, nenurodant prievado, o ne naudojant tokį adresą kaip example.com:5000.
• Galiausiai turite ištrinti visus senus konteinerius ir vaizdus.

Čia yra scenarijaus tęsinys.

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

Kai kurie dalykai, į kuriuos reikia atkreipti dėmesį

Gali būti, kad prisijungus prie serverio per SSH iš Travis CI, pamatysite įspėjimą, kuris neleis tęsti diegimo, nes sistema lauks vartotojo atsakymo.

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)?

Sužinojau, kad eilutės raktas gali būti užkoduotas bazėje base64, kad būtų galima jį išsaugoti tokia forma, kad su juo būtų galima patogiai ir patikimai dirbti. Diegimo etape galite iššifruoti viešąjį raktą ir įrašyti jį į failą known_hosts siekdami atsikratyti aukščiau nurodytos klaidos.

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

Praktiškai ši komanda gali atrodyti taip:

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

Ir štai ką jis sukuria – base64 užkoduotą eilutę:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Čia yra aukščiau minėta komanda

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

Tą patį metodą galima naudoti su privačiu raktu užmezgant ryšį, nes norint pasiekti serverį gali prireikti privataus rakto. Dirbdami su raktu tereikia užtikrinti, kad jis būtų saugiai saugomas Travis CI aplinkos kintamajame ir niekur nerodomas.

Kitas dalykas, į kurį reikia atkreipti dėmesį, yra tai, kad jums gali tekti paleisti visą diegimo scenarijų kaip vieną eilutę, pavyzdžiui, su doctl. Tam gali prireikti papildomų pastangų.

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

TLS/SSL ir apkrovos balansavimas

Kai padariau viską, kas paminėta aukščiau, paskutinė problema, su kuria susidūriau, buvo ta, kad serveris neturėjo SSL. Kadangi naudoju Node.js serverį, norėdamas priversti darbas atvirkštinis tarpinis serveris Nginx ir Let's Encrypt, jums reikia daug dirbti.

Tikrai nenorėjau visos šios SSL konfigūracijos atlikti rankiniu būdu, todėl tiesiog sukūriau apkrovos balansavimo priemonę ir įrašiau jos duomenis į DNS. Pavyzdžiui, „DigitalOcean“ atveju apkrovos balansavimo priemonėje sukurti automatiškai atnaujinamą savarankiškai pasirašytą sertifikatą yra paprasta, nemokama ir greita procedūra. Šis metodas turi papildomą pranašumą, nes prireikus labai lengva nustatyti SSL keliuose serveriuose, kuriuose veikia apkrovos balansavimo priemonė. Tai leidžia patiems serveriams visiškai „negalvoti“ apie SSL, bet tuo pat metu naudoti prievadą kaip įprasta 80. Taigi SSL nustatymas apkrovos balansavimo priemonėje yra daug lengvesnis ir patogesnis nei alternatyvūs SSL nustatymo būdai.

Dabar galite uždaryti visus serverio prievadus, kurie priima įeinančius ryšius, išskyrus prievadą 80, naudojamas bendrauti su apkrovos balansavimo įrenginiu ir prievadu 22 už SSH. Dėl to bandymas tiesiogiai pasiekti serverį naudojant bet kuriuos kitus prievadus, išskyrus šiuos du, nepavyks.

rezultatai

Kai padariau viską, apie ką kalbėjau šioje medžiagoje, nei Docker platforma, nei automatizuotų CI/CD grandinių koncepcijos manęs nebegąsdino. Man pavyko sukurti nenutrūkstamą integravimo grandinę, kurios metu kodas yra išbandomas prieš pradedant gamybą ir automatiškai įdiegiamas serveryje. Visa tai man dar gana nauja, ir esu tikras, kad yra būdų, kaip pagerinti automatizuotą darbo eigą ir padaryti ją veiksmingesnę. Taigi, jei turite kokių nors idėjų šiuo klausimu, praneškite man. mane žinoti. Tikiuosi, kad šis straipsnis jums padėjo jūsų pastangose. Noriu tikėti, kad jį perskaitęs sužinojai tiek, kiek aš išmokau, suprasdamas viską, apie ką jame kalbėjau.

PS Mumyse turgavietėje yra vaizdas dokininkas, kurį galima įdiegti vienu paspaudimu. Konteinerių veikimą galite patikrinti adresu VPS. Visiems naujiems klientams suteikiamos 3 dienos nemokamai.

Mieli skaitytojai! Ar savo projektuose naudojate CI/CD technologijas?

Šaltinis: www.habr.com