Að búa til CI/CD keðju og gera sjálfvirkan vinnu með Docker

Ég skrifaði fyrstu vefsíðurnar mínar seint á tíunda áratugnum. Þá var mjög auðvelt að koma þeim í gang. Það var Apache þjónn á einhverri sameiginlegri hýsingu, þú gætir skráð þig inn á þennan netþjón í gegnum FTP með því að skrifa eitthvað eins og ftp://ftp.example.com. Þá þurftirðu að slá inn nafnið þitt og lykilorð og hlaða skránum inn á netþjóninn. Það voru aðrir tímar, allt var einfaldara þá en nú.

Að búa til CI/CD keðju og gera sjálfvirkan vinnu með Docker

Á þessum tveimur áratugum síðan þá hefur allt breyst mikið. Vefsíður eru orðnar flóknari; þær verða að vera settar saman áður en þær eru gefnar út í framleiðslu. Einn netþjónn varð að mörgum netþjónum sem keyrðu á bak við álagsjafnara og notkun útgáfustýringarkerfa varð algeng.

Fyrir mitt persónulega verkefni var ég með sérstaka uppsetningu. Og ég vissi að ég þyrfti getu til að dreifa síðunni í framleiðslu með því að framkvæma aðeins eina aðgerð: að skrifa kóða í útibú master á GitHub. Þar að auki vissi ég að til að tryggja rekstur litla vefforritsins míns vildi ég ekki stjórna risastórum Kubernetes klasa, eða nota Docker Swarm tækni, eða halda úti flota netþjóna með belgjum, umboðsmönnum og alls kyns öðru. margbreytileika. Til þess að ná því markmiði að gera vinnu sem auðveldasta þurfti ég að kynna mér CI/CD.

Ef þú ert með lítið verkefni (í þessu tilfelli Node.js verkefni) og þú vilt vita hvernig á að gera sjálfvirkan dreifingu þessa verkefnis, á sama tíma og þú tryggir að það sem er geymt í geymslunni samsvari nákvæmlega því sem virkar í framleiðslu, þá held að þú gætir haft áhuga á þessari grein.

Forkröfur

Gert er ráð fyrir að lesandi þessarar greinar hafi grunnskilning á skipanalínunni og ritun Bash forskrifta. Auk þess mun hann þurfa reikninga Travis C.I. и Docker miðstöð.

Markmið

Ég mun ekki segja að þessa grein sé skilyrðislaust hægt að kalla „kennsluefni“. Þetta er meira skjal þar sem ég tala um það sem ég hef lært og lýsi því ferli sem hentar mér til að prófa og dreifa kóða til framleiðslu, framkvæmt í einni sjálfvirkri umferð.

Þetta er það sem vinnuflæðið mitt endaði á að vera.

Fyrir kóða sem er settur á hvaða útibú sem er geymslu nema master, eru eftirfarandi aðgerðir gerðar:

  • Verkefnið byggir á Travis CI hefst.
  • Öll eininga-, samþættingar- og enda-til-enda próf eru framkvæmd.

Aðeins fyrir kóða sem fellur inn í master, eftirfarandi er framkvæmt:

  • Allt sem nefnt er hér að ofan, auk...
  • Byggja Docker mynd byggða á núverandi kóða, stillingum og umhverfi.
  • Dreifir myndinni í Docker Hub.
  • Tenging við framleiðsluþjóninn.
  • Hleður upp mynd frá Docker Hub á netþjóninn.
  • Stöðva núverandi gám og hefja nýjan á grundvelli nýju myndarinnar.

Ef þú veist nákvæmlega ekkert um Docker, myndir og ílát, ekki hafa áhyggjur. Ég skal segja þér allt um það.

Hvað er CI/CD?

Skammstöfunin CI/CD stendur fyrir „samfelld samþætting/samfelld dreifing“.

▍Stöðug samþætting

Stöðug samþætting er ferli þar sem verktaki skuldbindur sig til aðal frumkóðageymslu verkefnisins (venjulega útibú master). Á sama tíma eru gæði kóðans tryggð með sjálfvirkum prófunum.

▍Stöðug dreifing

Stöðug dreifing er tíð, sjálfvirk dreifing kóða í framleiðslu. Seinni hluti CI/CD skammstöfunarinnar er stundum skrifuð út sem „samfelld afhending“. Þetta er í grundvallaratriðum það sama og „samfelld dreifing“, en „samfelld afhending“ felur í sér nauðsyn þess að staðfesta breytingar handvirkt áður en byrjað er á dreifingarferli verkefnisins.

getting Started

Appið sem ég notaði til að læra allt þetta heitir Takið eftir. Þetta er vefverkefni sem ég er að vinna að, hannað til að taka minnispunkta. Í fyrstu reyndi ég að gera JAMStack-verkefni, eða bara framendaforrit án netþjóns, til að nýta staðlaða hýsingar- og verkefnadreifingargetu sem það býður upp á Netlify. Þegar forritið var flókið, þurfti ég að búa til miðlarahluta þess, sem þýddi að ég þyrfti að móta mína eigin stefnu fyrir sjálfvirka samþættingu og sjálfvirka dreifingu verkefnisins.

Í mínu tilfelli er forritið Express netþjónn sem keyrir í Node.js umhverfinu, þjónar einni síðu React forriti og styður öruggt API á netþjóni. Þessi arkitektúr fylgir stefnunni sem er að finna í þetta Full stafla auðkenningarleiðbeiningar.

Ég ráðfærði mig við vinur, sem er sérfræðingur í sjálfvirkni og spurði hann hvað ég þyrfti að gera til að allt virki eins og ég vildi. Hann gaf mér hugmyndina um hvernig sjálfvirkt verkflæði ætti að líta út, sem lýst er í markmiðshluta þessarar greinar. Að hafa þessi markmið þýddi að ég þurfti að finna út hvernig ég ætti að nota Docker.

Docker

Docker er tæki sem, þökk sé gámatækni, gerir kleift að dreifa, dreifa og keyra forritum á auðveldan hátt í sama umhverfi, jafnvel þó að Docker pallurinn sjálfur keyri í mismunandi umhverfi. Í fyrsta lagi þurfti ég að hafa hendurnar á Docker skipanalínuverkfærunum (CLI). Leiðbeiningar Ekki er hægt að kalla Docker uppsetningarhandbókina mjög skýra og skiljanlega, en af ​​honum geturðu lært að til að taka fyrsta uppsetningarskrefið þarftu að hlaða niður Docker Desktop (fyrir Mac eða Windows).

Docker Hub er nokkurn veginn það sama og GitHub fyrir git geymslur eða skrásetningu npm fyrir JavaScript pakka. Þetta er netgeymsla fyrir Docker myndir. Þetta er það sem Docker Desktop tengist.

Svo, til að byrja með Docker þarftu að gera tvennt:

Eftir þetta geturðu athugað hvort Docker CLI sé að virka með því að keyra eftirfarandi skipun til að athuga Docker útgáfuna:

docker -v

Næst skaltu skrá þig inn á Docker Hub með því að slá inn notandanafn og lykilorð þegar spurt er:

docker login

Til að nota Docker verður þú að skilja hugtökin um myndir og ílát.

▍Myndir

Mynd er eitthvað eins og teikning sem inniheldur leiðbeiningar um að setja ílátið saman. Þetta er óbreytanleg skyndimynd af skráarkerfi og stillingum forritsins. Hönnuðir geta auðveldlega deilt myndum.

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

Þessi skipun mun gefa út töflu með eftirfarandi haus:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

Næst munum við skoða nokkur dæmi um skipanir á sama sniði - fyrst er skipun með athugasemd og síðan dæmi um hvað hún getur gefið út.

▍Gámar

Gámur er keyranleg pakki sem inniheldur allt sem þarf til að keyra forrit. Forrit með þessari nálgun mun alltaf virka eins, óháð innviðum: í einangruðu umhverfi og í sama umhverfi. Málið er að tilvik af sömu mynd eru sett í mismunandi umhverfi.

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

▍ Merki

Merki er vísbending um ákveðna útgáfu af mynd.

▍ Fljótleg tilvísun í Docker skipanir

Hér er yfirlit yfir nokkrar algengar Docker skipanir.

Team

Samhengi

áhrif

bryggjusmíði

Mynd

Byggja mynd úr Dockerfile

docker merki

Mynd

Myndamerking

Docker myndir

Mynd

Listamyndir

skipakví

ílát

Að keyra ílát byggt á mynd

hafnarverkamaður ýta

Mynd

Að hlaða upp mynd í skránni

hafnarmaður draga

Mynd

Hleður mynd úr skránni

bryggju ps

ílát

Skráning gáma

docker kerfi prune

Mynd/ílát

Fjarlægir ónotuð ílát og myndir

▍Dockerskrá

Ég veit hvernig á að keyra framleiðsluforrit á staðnum. Ég er með Webpack uppsetningu sem er hönnuð til að búa til tilbúið React forrit. Næst er ég með skipun sem ræsir Node.js miðlara á portinu 5000. Það lítur svona út:

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

Það skal tekið fram að ég er ekki með dæmi um umsókn fyrir þetta efni. En hér, fyrir tilraunir, mun hvaða einfalt Node forrit duga.

Til þess að nota ílátið þarftu að gefa Docker leiðbeiningar. Þetta er gert í gegnum skrá sem heitir Dockerfile, staðsett í rótarskrá verkefnisins. Þessi skrá virðist í fyrstu frekar óskiljanleg.

En það sem það inniheldur lýsir aðeins, með sérstökum skipunum, eitthvað svipað og að setja upp vinnuumhverfi. Hér eru nokkrar af þessum skipunum:

  • FRÁ — Þessi skipun ræsir skrá. Það tilgreinir grunnmyndina sem gámurinn er byggður á.
  • COPY — Afrita skrár frá staðbundnum uppruna í gám.
  • VERKSTJÓR — Stilla vinnuskrána fyrir eftirfarandi skipanir.
  • RUN - Keyra skipanir.
  • AFHJÚPA — Hafnarstillingar.
  • AÐGANGUR — Tilkynning um skipunina sem á að framkvæma.

Dockerfile gæti litið eitthvað svona út:

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

Það fer eftir grunnmyndinni sem þú velur, þú gætir þurft að setja upp fleiri ósjálfstæði. Staðreyndin er sú að sumar grunnmyndir (eins og Node Alpine Linux) eru búnar til með það að markmiði að gera þær eins þéttar og mögulegt er. Þar af leiðandi geta þeir ekki verið með sum forritin sem þú býst við.

▍ Byggja, merkja og reka gáminn

Staðbundin samkoma og sjósetning gámsins er eftir að við höfum Dockerfile, verkefnin eru frekar einföld. Áður en þú ýtir myndinni í Docker Hub þarftu að prófa hana á staðnum.

▍Samsetning

Fyrst þarftu að safna mynd, tilgreinir nafn og, valfrjálst, merki (ef merki er ekki tilgreint mun kerfið sjálfkrafa úthluta merki á myndina latest).

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

Eftir að hafa keyrt þessa skipun geturðu horft á Docker byggja myndina.

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

Byggingin gæti tekið nokkrar mínútur - það fer allt eftir því hversu mörg ósjálfstæði þú hefur. Þegar smíði er lokið geturðu keyrt skipunina docker images og skoðaðu lýsinguna á nýju myndinni þinni.

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

▍ Ræsa

Myndin er búin til. Þetta þýðir að þú getur keyrt ílát byggt á því. Vegna þess að ég vil geta nálgast forritið sem keyrir í gámnum kl localhost:5000, ég, vinstra megin við parið 5000:5000 í næstu skipun sem er uppsett 5000. Hægra megin er gámahöfnin.

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

Nú þegar ílátið er búið til og keyrt geturðu notað skipunina docker ps til að skoða upplýsingar um þennan ílát (eða þú getur notað skipunina docker ps -a, sem sýnir upplýsingar um alla gáma, ekki bara hlaupandi).

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

Ef þú ferð núna á heimilisfangið localhost:5000 — þú getur séð síðu í gangi forrits sem lítur nákvæmlega eins út og síða forrits sem keyrir í framleiðsluumhverfi.

▍Merking og birting

Til þess að nota eina af myndunum sem búið er til á framleiðsluþjóninum þurfum við að geta halað niður þessari mynd frá Docker Hub. Þetta þýðir að þú þarft fyrst að búa til geymslu fyrir verkefnið á Docker Hub. Eftir þetta munum við hafa stað þar sem við getum sent myndina. Endurnefna þarf myndina þannig að nafn hennar byrji á Docker Hub notendanafninu okkar. Þessu ætti að fylgja nafn geymslunnar. Hægt er að setja hvaða merki sem er aftast í nafninu. Hér að neðan er dæmi um að nefna myndir með þessu kerfi.

Nú geturðu smíðað myndina með nýju nafni og keyrt skipunina docker push til að ýta því í Docker Hub geymsluna.

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

Ef allt gengur upp verður myndin fáanleg á Docker Hub og auðvelt er að hlaða henni upp á netþjóninn eða flytja hana til annarra forritara.

Næstu skref

Núna höfum við staðfest að forritið, í formi Docker gáms, sé í gangi á staðnum. Við höfum hlaðið ílátinu upp á Docker Hub. Allt þetta þýðir að við höfum þegar náð mjög góðum árangri í átt að markmiði okkar. Nú þurfum við að leysa tvær spurningar í viðbót:

  • Að setja upp CI tól til að prófa og dreifa kóða.
  • Að setja upp framleiðsluþjóninn þannig að hann geti halað niður og keyrt kóðann okkar.

Í okkar tilviki notum við Travis C.I.. Sem þjónn - DitigalOcean.

Það skal tekið fram að hér er hægt að nota aðra samsetningu þjónustu. Til dæmis, í stað Travis CI, geturðu notað CircleCI eða Github Actions. Og í stað DigitalOcean - AWS eða Linode.

Við ákváðum að vinna með Travis CI og ég er nú þegar með eitthvað stillt í þessari þjónustu. Þess vegna mun ég tala stuttlega um hvernig á að undirbúa það fyrir vinnu.

Travis C.I.

Travis CI er tæki til að prófa og dreifa kóða. Ég myndi ekki vilja fara út í ranghala við að setja upp Travis CI, þar sem hvert verkefni er einstakt og þetta mun ekki hafa mikinn ávinning. En ég mun fara yfir grunnatriðin til að koma þér af stað ef þú ákveður að nota Travis CI. Hvort sem þú velur Travis CI, CircleCI, Jenkins eða eitthvað annað, þá verða svipaðar uppsetningaraðferðir notaðar alls staðar.

Til að byrja með Travis CI skaltu fara á heimasíðu verkefnisins og stofna reikning. Settu síðan Travis CI inn við GitHub reikninginn þinn. Þegar þú setur upp kerfið þarftu að tilgreina geymsluna sem þú vilt gera sjálfvirkan vinnu með og gera aðgang að henni kleift. (Ég nota GitHub, en ég er viss um að Travis CI geti samþætt við BitBucket og GitLab og aðrar svipaðar þjónustur).

Í hvert skipti sem Travis CI er ræst er þjónninn ræstur og framkvæmir skipanirnar sem tilgreindar eru í stillingarskránni, þar á meðal að dreifa samsvarandi geymslugreinum.

▍Lífsferill starfsins

Travis CI stillingarskrá kölluð .travis.yml og geymt í rótarskrá verkefnisins, styður hugmyndina um atburði lífsferil verkefni. Þessir atburðir eru taldir upp í þeirri röð sem þeir gerast:

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

▍Próf

Í stillingarskránni ætla ég að stilla Travis CI þjóninn á staðnum. Ég valdi Node 12 sem tungumálið og sagði kerfinu að setja upp ósjálfstæðin sem þarf til að nota Docker.

Allt sem er skráð í .travis.yml, verður keyrt þegar allar dráttarbeiðnir eru gerðar til allra útibúa geymslunnar, nema annað sé tekið fram. Þetta er gagnlegur eiginleiki vegna þess að það þýðir að við getum prófað allan kóða sem kemur inn í geymsluna. Þetta lætur þig vita hvort kóðinn sé tilbúinn til að vera skrifaður í útibúið. master, og hvort það muni brjóta upp byggingarferlið verkefnisins. Í þessari alþjóðlegu uppsetningu set ég allt upp á staðnum, keyri Webpack þróunarþjóninn í bakgrunni (þetta er eiginleiki í vinnuflæðinu mínu) og keyri próf.

Ef þú vilt að geymslan þín sýni prófunartákn, hér Þú getur fundið stuttar leiðbeiningar um notkun Jest, Travis CI og yfirbuxna til að safna og birta þessar upplýsingar.

Svo hér er innihald skráarinnar .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

Þetta er þar sem aðgerðirnar sem eru gerðar fyrir allar greinar geymslunnar og fyrir dráttarbeiðnir enda.

▍Dreifing

Byggt á þeirri forsendu að öllum sjálfvirkum prófunum hafi verið lokið með góðum árangri, getum við, sem er valfrjálst, sett kóðann á framleiðsluþjóninn. Þar sem við viljum gera þetta aðeins fyrir kóða frá útibúinu master, gefum við kerfinu viðeigandi leiðbeiningar í dreifingarstillingunum. Áður en þú reynir að nota kóðann sem við munum skoða næst í verkefninu þínu, vil ég vara þig við að þú verður að hafa raunverulegt handrit sem kallað er á dreifingu.

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

Dreifingarhandritið leysir tvö vandamál:

  • Byggðu, merktu og sendu myndina til Docker Hub með því að nota CI tól (í okkar tilfelli, Travis CI).
  • Hleður myndinni á netþjóninn, stöðvaði gamla gáminn og ræsir nýjan (í okkar tilviki keyrir þjónninn á DigitalOcean pallinum).

Fyrst þarftu að setja upp sjálfvirkt ferli til að byggja, merkja og ýta myndinni í Docker Hub. Þetta er allt mjög svipað því sem við höfum þegar gert handvirkt, nema að við þurfum stefnu til að úthluta einstökum töggum á myndir og sjálfvirka innskráningu. Ég átti í erfiðleikum með smá upplýsingar um dreifingarhandritið, svo sem merkingarstefnu, innskráningu, SSH lyklakóðun, SSH tengingu. En sem betur fer er kærastinn minn mjög góður í bash eins og með margt annað. Hann hjálpaði mér að skrifa þetta handrit.

Svo, fyrsti hluti handritsins er að hlaða myndinni upp á Docker Hub. Þetta er frekar auðvelt að gera. Merkingarkerfið sem ég notaði felur í sér að sameina git hash og git tag, ef það er til. Þetta tryggir að merkið sé einstakt og gerir það auðveldara að bera kennsl á samsetninguna sem það er byggt á. DOCKER_USERNAME и DOCKER_PASSWORD eru notendaumhverfisbreytur sem hægt er að stilla með Travis CI viðmótinu. Travis CI mun sjálfkrafa vinna viðkvæm gögn svo þau lendi ekki í rangar hendur.

Hér er fyrsti hluti handritsins 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}

Hver seinni hluti handritsins verður fer algjörlega eftir því hvaða gestgjafi þú ert að nota og hvernig tengingunni við hann er skipulögð. Í mínu tilfelli, þar sem ég nota Digital Ocean, nota ég skipanirnar til að tengjast þjóninum doctl. Þegar unnið er með AWS verður tólið notað aws, og svo framvegis.

Það var ekkert sérstaklega erfitt að setja upp netþjóninn. Svo setti ég upp dropa byggt á grunnmyndinni. Það skal tekið fram að kerfið sem ég valdi þarfnast handvirkrar uppsetningar á Docker í eitt skipti og Docker handvirkt í eitt skipti. Ég notaði Ubuntu 18.04 til að setja upp Docker, þannig að ef þú ert líka að nota Ubuntu til að gera það sama geturðu bara fylgst með þetta einföld leiðarvísir.

Ég er ekki að tala hér um sérstakar skipanir fyrir þjónustuna, þar sem þessi þáttur getur verið mjög mismunandi í mismunandi tilvikum. Ég mun bara gefa almenna áætlun um aðgerðir sem á að framkvæma eftir að hafa tengst í gegnum SSH við netþjóninn sem verkefnið verður sent á:

  • Við þurfum að finna gáminn sem er í gangi núna og stöðva hann.
  • Þá þarftu að ræsa nýjan ílát í bakgrunni.
  • Þú þarft að stilla staðbundið tengi miðlarans á 80 - þetta gerir þér kleift að slá inn síðuna á heimilisfang eins og example.com, án þess að tilgreina höfnina, frekar en að nota heimilisfang eins og example.com:5000.
  • Að lokum þarftu að eyða öllum gömlum gámum og myndum.

Hér er framhald handritsins.

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

Nokkur atriði til að borga eftirtekt til

Hugsanlegt er að þegar þú tengist þjóninum í gegnum SSH frá Travis CI muntu sjá viðvörun sem kemur í veg fyrir að þú haldir áfram með uppsetninguna þar sem kerfið mun bíða eftir svari notandans.

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

Ég komst að því að strengjalykill er hægt að umrita í base64 til að vista hann á því formi sem hægt er að vinna með hann á þægilegan og áreiðanlegan hátt. Á uppsetningarstigi geturðu afkóða opinbera lykilinn og skrifað hann í skrá known_hosts til að losna við ofangreinda villu.

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

Í reynd gæti þessi skipun litið svona út:

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

Og hér er það sem það framleiðir - base64 kóðaðan streng:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Hér er skipunin sem nefnd er hér að ofan

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

Sama nálgun er hægt að nota með einkalykli þegar tenging er komið á þar sem þú gætir þurft einkalykil til að fá aðgang að þjóninum. Þegar þú vinnur með lykilinn þarftu bara að tryggja að hann sé geymdur á öruggan hátt í Travis CI umhverfisbreytu og að hann sé hvergi sýndur.

Annað sem þarf að hafa í huga er að þú gætir þurft að keyra allt dreifingarforritið sem eina línu, til dæmis - með doctl. Þetta gæti þurft auka áreynslu.

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

TLS/SSL og álagsjöfnun

Eftir að ég gerði allt sem nefnt var hér að ofan var síðasta vandamálið sem ég lenti í að þjónninn var ekki með SSL. Þar sem ég nota Node.js miðlara, til að þvinga að vinna reverse proxy Nginx og Let's Encrypt, þú þarft að fikta mikið.

Ég vildi virkilega ekki gera alla þessa SSL stillingu handvirkt, svo ég bjó bara til álagsjafnara og skráði upplýsingar þess í DNS. Þegar um DigitalOcean er að ræða, til dæmis, er einföld, ókeypis og fljótleg aðferð að búa til sjálfkrafa endurnýjun sjálfundirritaðs vottorðs á álagsjafnara. Þessi nálgun hefur þann ávinning að það gerir það mjög auðvelt að setja upp SSL á mörgum netþjónum sem keyra á bak við álagsjafnara ef þörf krefur. Þetta gerir netþjónunum sjálfum kleift að „hugsa“ alls ekki um SSL, en á sama tíma nota portið eins og venjulega 80. Svo að setja upp SSL á álagsjafnara er miklu auðveldara og þægilegra en aðrar aðferðir við að setja upp SSL.

Nú geturðu lokað öllum höfnum á þjóninum sem taka á móti tengingum - nema höfninni 80, notað til að hafa samskipti við álagsjafnara og höfnina 22 fyrir SSH. Fyrir vikið mun tilraun til að fá beinan aðgang að þjóninum á öðrum höfnum en þessum tveimur mistakast.

Niðurstöður

Eftir að ég gerði allt sem ég talaði um í þessu efni hræddu hvorki Docker vettvangurinn né hugtökin um sjálfvirkar CI/CD keðjur mig lengur. Ég gat sett upp samfellda samþættingarkeðju, þar sem kóðinn er prófaður áður en hann fer í framleiðslu og kóðinn er sjálfkrafa settur á netþjóninn. Þetta er allt enn tiltölulega nýtt fyrir mér og ég er viss um að það eru til leiðir til að bæta sjálfvirka vinnuflæðið mitt og gera það skilvirkara. Svo ef þú hefur einhverjar hugmyndir um þetta mál, vinsamlegast láttu mig vita. mig vita. Ég vona að þessi grein hafi hjálpað þér í viðleitni þinni. Ég vil trúa því að eftir að hafa lesið hana hafirðu lært jafn mikið og ég á meðan þú varst að finna út allt sem ég talaði um í henni.

PS Í okkar markaðstorg það er mynd Docker, sem hægt er að setja upp með einum smelli. Hægt er að athuga rekstur gáma á VPS. Allir nýir viðskiptavinir fá 3 daga próf án endurgjalds.

Kæru lesendur! Notar þú CI/CD tækni í verkefnum þínum?

Að búa til CI/CD keðju og gera sjálfvirkan vinnu með Docker

Heimild: www.habr.com

Bæta við athugasemd