Krei CI/KD-ĉenon kaj aŭtomatigi laboron kun Docker

Mi verkis miajn unuajn retejojn fine de la 90-aj jaroj. Tiam estis tre facile alporti ilin en laborkondiĉon. Estis Apache-servilo en iu komuna gastigado, ĉi tiu servilo estis alirebla per FTP skribante en la retumila linio ion kiel ftp://ftp.example.com. Tiam necesis enigi nomon kaj pasvorton kaj alŝuti la dosierojn al la servilo. Estis aliaj tempoj, ĉio estis pli simpla tiam ol nun.

Aferoj multe ŝanĝiĝis en la lastaj du jardekoj. Ejoj fariĝis pli kompleksaj, ili devas esti kunvenitaj antaŭ esti liberigitaj en produktadon. Unu ununura servilo fariĝis multaj serviloj kurantaj malantaŭ ŝarĝbalanciloj, la uzo de versio-kontrolsistemoj fariĝis ordinara.

Por mia persona projekto, mi havis specialan agordon. Kaj mi sciis, ke mi bezonas la kapablon deploji retejon en produktado, farante nur unu agon: skribi kodon al branĉo. master sur GitHub. Mi ankaŭ sciis, ke mi ne volis administri grandegan Kubernetes-areton, aŭ uzi Docker Swarm-teknologion, aŭ konservi servilan parkon kun podoj, agentoj kaj ĉiaj aliaj kompleksaĵoj, por funkciigi mian malgrandan TTT-aplikaĵon. Por atingi la celon fari laboron kiel eble plej facila, mi bezonis konatiĝi kun CI / KD.

Se vi havas malgrandan projekton (en nia kazo, projekto Node.js) kaj ŝatus lerni kiel aŭtomatigi la deplojon de ĉi tiu projekto, certigante, ke tio, kio estas konservita en la deponejo, ĝuste kongruas kun tio, kio funkcias en produktado, mi pensas. vi eble interesiĝos pri ĉi tiu artikolo.

Antaŭkondiĉoj

La leganto de ĉi tiu artikolo estas atendita havi bazan komandlinion kaj Bash-skriptscion. Krome, li bezonos kontojn Travis C.I. и Docker-nabo.

Objektivoj

Mi ne diros, ke ĉi tiu artikolo povas senkondiĉe nomi "trejnadgvidilo". Ĉi tio estas pli ol dokumento, en kiu mi parolas pri tio, kion mi lernis kaj priskribas la procezon, kiu konvenas al mi por testi kaj disfaldi kodon al produktado, farita en unu aŭtomata paŝo.

Jen kiel mia laborfluo aspektis.

Por kodo puŝita al iu ajn branĉo de la deponejo krom master, la sekvaj agoj estas faritaj:

• Projekto konstruo sur Travis CI komenciĝas.
• Ĉiuj unuopaj, integrigaj kaj fin-al-finaj testoj estas faritaj.

Nur por kodo kiu finiĝas en master, la sekvanta estas farita:

• Ĉio ĉi-supra, plus...
• Konstruante Docker-bildon bazitan sur la nuna kodo, agordoj kaj medio.
• Gastigante la bildon sur Docker Hub.
• Konekto al la produktadservilo.
• Alŝutante bildon de Docker Hub al la servilo.
• Haltu la nunan ujon kaj komencu novan bazitan sur la nova bildo.

Se vi scias absolute nenion pri Docker, bildoj kaj ujoj, ne maltrankviliĝu. Mi rakontos al vi ĉion pri ĝi.

Kio estas CI/KD?

La mallongigo CI / KD signifas "kontinua integriĝo / kontinua deplojo" - "kontinua integriĝo / kontinua deplojo".

▍Kontinua Integriĝo

Kontinua Integriĝo estas la procezo per kiu programistoj faras engaĝiĝojn al la ĉefa fontkoddeponejo de projekto (kutime branĉo master). Samtempe, la kvalito de la kodo estas certigita per aŭtomata testado.

▍Kontinua Deplojo

Daŭra deplojo estas la ofta aŭtomatigita deplojo de kodo al produktado. La dua parto de la mallongigo CI/KD foje estas rivelita kiel "kontinua livero" ("kontinua livero"). Ĉi tio estas esence la sama kiel "kontinua deplojo", sed "kontinua livero" implicas ke ŝanĝoj devas esti permane konfirmitaj antaŭ komenci la projektan deplojprocezon.

Kiel ekuzi

La aplikaĵo sur kiu mi regis ĉion ĉi nomiĝas Notu. Ĉi tio estas retprojekto pri kiu mi laboras por preni notojn. Unue mi provis fari JAMStako-project, aŭ nur antaŭa aplikaĵo sen servilo, por utiligi la normajn gastigajn kaj projektajn opciojn kiujn ĝi proponas netlify. Ĉar la komplekseco de la aplikaĵo kreskis, mi bezonis krei ĝian back-end, kio signifis, ke mi devus formi mian propran strategion por aŭtomatigita integriĝo kaj aŭtomatigita deplojo de la projekto.

En mia kazo, la aplikaĵo estas Express-servilo funkcianta en Node.js-medio, servanta unupaĝan React-aplikaĵon kaj subtenanta sekuran servilflankan API. Ĉi tiu arkitekturo sekvas strategion, kiu troviĝas en ĉi plena staka aŭtentikiggvidilo.

Mi konsultis kun amiko, kiu estas fakulo pri aŭtomatigo, kaj demandis lin, kion mi devas fari por ke ĉio funkciu kiel mi volas. Li donis al mi ideon pri kiel devus aspekti la aŭtomata laborfluo skizita en la sekcio Celoj de ĉi tiu artikolo. Fiksi tiajn celojn signifis, ke mi devis eltrovi kiel uzi Docker.

Docker

Docker estas ilo kiu, danke al kontenerigo teknologio, faciligas distribui aplikaĵojn, same kiel deploji kaj ruli ilin en la sama medio, eĉ se la Docker-platformo mem funkcias en malsamaj medioj. Unue, mi devis akiri miajn manojn sur la komandliniajn ilojn (CLI) de Docker. instrukcio La instala gvidilo por Docker ne estas tre klara, sed vi povas lerni de ĝi, ke por fari la unuan paŝon de la instalado, vi devas elŝuti Docker Desktop (por Mac aŭ Vindozo).

Docker Hub estas proksimume la sama kiel GitHub por git-deponejoj, aŭ registro npm por JavaScript-pakaĵoj. Ĉi tio estas interreta deponejo por bildoj de Docker. Ĉi tie estas kie Docker Desktop konektas.

Do, por komenci kun Docker, vi devas fari du aferojn:

• Instali docker labortablo.
• Registru por Docker-nabo.

Post tio, vi povas kontroli ĉu la Docker CLI funkcias per la sekva komando por kontroli la Docker-version:

docker -v

Poste, ensalutu al Docker Hub enigante vian uzantnomon kaj pasvorton kiam oni petas:

docker login

Por uzi Docker, vi devas kompreni la konceptojn de bildoj kaj ujoj.

▍Bildoj

Bildo estas speco de skizo enhavanta instrukciojn por konstrui ujon. Ĉi tio estas neŝanĝebla momentfoto de la dosiersistemo kaj aplikaĵagordoj. Programistoj povas facile dividi bildojn.

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

Ĉi tiu komando eligos tabelon kun la sekva titolo:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

Poste, ni konsideros kelkajn ekzemplojn de komandoj en la sama formato - unue estas komando kun komento, kaj poste ekzemplo de tio, kion ĝi povas eligi.

▍Ujoj

Ujo estas plenumebla pako, kiu enhavas ĉion necesan por ruli aplikaĵon. Apliko kun ĉi tiu aliro ĉiam funkcios same, sendepende de la infrastrukturo: en izolita medio kaj en la sama medio. Ni parolas pri la fakto, ke okazoj de la sama bildo estas lanĉitaj en malsamaj medioj.

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

▍Etikedoj

Etikedo estas indiko de specifa versio de bildo.

▍Rapida referenco por Docker-komandoj

Jen superrigardo de kelkaj ofte uzataj Docker-komandoj.

teamo

Kunteksto

efiko

docker konstruo

Bildo

Konstruante bildon el Dockerfile

docker-etikedo

Bildo

Bilda etikedado

Docker bildoj

Bildo

Montrante liston de bildoj

Docker kuri

Ujo

Kurante bild-bazitan ujon

docker push

Bildo

Sendante Bildon al la Registro

docker tiro

Bildo

Ŝargante Bildon el la Registro

docker ps

Ujo

Listo de ujoj

docker-sistemo pritondi

Bildo/Ujo

Forigo de neuzataj ujoj kaj bildoj

▍Dockerfile

Mi scias kiel prizorgi produktan aplikaĵon loke. Mi havas retan agordon por konstrui finitan React-apon. Poste, mi havas komandon, kiu lanĉas Node.js bazitan servilon sur la haveno 5000. Ĝi aspektas jene:

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

Oni devas rimarki, ke mi ne havas ekzemplon por ĉi tiu materialo. Sed ĉi tie, por eksperimentoj, ajna simpla Node-apliko funkcios.

Por uzi la ujon, vi devos doni instrukciojn al Docker. Ĉi tio estas farita per dosiero nomita Dockerfiletroviĝas en la radika dosierujo de la projekto. Ĉi tiu dosiero, komence, ŝajnas sufiĉe nekomprenebla.

Sed tio, kion ĝi enhavas, nur priskribas, en specialaj komandoj, ion kiel starigi labormedion. Jen kelkaj el tiuj komandoj:

• FROM — Ĉi tiu komando komencas dosieron. Ĝi specifas la bazan bildon el kiu la ujo estas konstruita.
• COPY - Kopiado de dosieroj de loka fonto al ujo.
• LABORODIR - Agordi la labordosierujon por la sekvaj komandoj.
• KURI - Rulu komandojn.
• EKPONI — Haveno agordo.
• ENIRPUNTO — Indiko pri la plenumota komando.

Dockerfile povus aspekti kiel ĉi tio:

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

Depende de la baza bildo, kiun vi elektas, vi eble bezonos instali pliajn dependecojn. Fakte, iuj bazaj bildoj (kiel Node Alpine Linux) estas desegnitaj por esti kiel eble plej kompaktaj. Kiel rezulto, ili eble ne inkluzivas iujn el la programoj, kiujn vi atendas.

▍Konstrui, etikedi kaj funkcii ujon

Loka muntado kaj lanĉo de la ujo estas, post kiam ni havas Dockerfilela taskoj estas sufiĉe simplaj. Antaŭ puŝi bildon al Docker Hub, ĝi devas esti provita loke.

▍Asembleo

Unue vi devas kolekti bildo, specifante nomon, kaj, laŭvole, etikedon (se neniu etikedo estas specifita, la sistemo aŭtomate asignos etikedon al la bildo latest).

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

Post rulado de ĉi tiu komando, vi povas rigardi Docker konstrui la bildon.

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

Konstruado povas daŭri kelkajn minutojn - ĉio dependas de kiom da dependecoj vi havas. Post kiam la konstruo estas kompleta, vi povas ruli la komandon docker images kaj rigardu la priskribon de via nova bildo.

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

▍Lanĉo

La bildo estas kreita. Kaj ĉi tio signifas, ke sur ĝia bazo vi povas ruli ujon. Ĉar mi volas povi aliri la aplikaĵon kurantan en la ujo ĉe localhost:5000, i, sur la maldekstra flanko de la paro 5000:5000 en la sekva komandaro 5000. Sur la dekstra flanko estas la kontenera haveno.

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

Nun kiam la ujo estas kreita kaj funkcianta, vi povas uzi la komandon docker ps por rigardi informojn pri ĉi tiu ujo (aŭ vi povas uzi la komandon docker ps -a, kiu montras informojn pri ĉiuj ujoj, ne nur pri la kurantaj).

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

Se vi nun iru al localhost:5000 - vi povas vidi la paĝon de la funkcianta aplikaĵo, kiu aspektas ĝuste same kiel la paĝo de la aplikaĵo funkcianta en la produktadmedio.

▍Tag-Asigno kaj Publikigo

Por uzi unu el la kreitaj bildoj sur la produktadservilo, ni devas povi elŝuti ĉi tiun bildon de Docker Hub. Ĉi tio signifas, ke vi unue devas krei deponejon por la projekto en Docker Hub. Post tio, ni havos lokon kie ni povas sendi la bildon. La bildo devas esti renomita tiel ke ĝia nomo komencu per nia uzantnomo de Docker Hub. Ĉi tio estu sekvata de la nomo de la deponejo. Ĉiu etikedo povas esti metita ĉe la fino de la nomo. Malsupre estas ekzemplo de nomado de bildoj laŭ ĉi tiu skemo.

Nun vi povas konstrui la bildon kun nova nomo atribuita al ĝi kaj ruli la komandon docker push por puŝi ĝin al la deponejo de Docker Hub.

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

Se ĉio iras bone, la bildo estos havebla sur Docker Hub kaj povas esti facile alŝutita al la servilo aŭ dividita kun aliaj programistoj.

Sekvaj paŝoj

Nuntempe ni kontrolis, ke la aplikaĵo, en la formo de Docker-ujo, funkcias loke. Ni alŝutis la ujon al Docker Hub. Ĉio ĉi signifas, ke ni jam tre bone progresis al nia celo. Nun ni devas solvi du pliajn demandojn:

• Agordi CI-ilon por testi kaj disfaldi kodon.
• Agordante la produktadservilon por ke ĝi povu elŝuti kaj ruli nian kodon.

En nia kazo, kiel CI/KD-solvo, ni uzas Travis C.I.. Kiel servilo - DigitalOcean.

Oni devas rimarki, ke ĉi tie vi povas uzi alian kombinaĵon de servoj. Ekzemple, anstataŭ Travis CI, vi povas uzi CircleCI aŭ Github-Agojn. Kaj anstataŭ DigitalOcean - AWS aŭ Linode.

Ni decidis labori kun Travis CI, kaj mi jam havas ion starigitan en ĉi tiu servo. Tial nun mi mallonge parolos pri kiel prepari ĝin por laboro.

Travis C.I.

Travis CI estas ilo por testi kaj disfaldi kodon. Mi ne volas eniri la detalojn pri starigo de Travis CI, ĉar ĉiu projekto estas unika kaj ĝi ne multe utilos. Sed mi kovros la bazaĵojn por komenci vin se vi decidas uzi Travis CI. Kion ajn vi elektas - Travis CI, CircleCI, Jenkins, aŭ io alia, similaj agordaj metodoj aplikiĝos ĉie.

Por komenci kun Travis CI, iru al projektejo kaj kreu konton. Poste integru Travis CI kun via GitHub-konto. Kiam vi agordas la sistemon, vi devos specifi la deponejon, kiun vi volas aŭtomatigi kaj ebligi aliron al ĝi. (Mi uzas GitHub, sed mi certas, ke Travis CI povas integri kun BitBucket, GitLab kaj aliaj similaj servoj).

Ĉiufoje kiam Travis CI estas komencita, servilo estas komencita, kiu plenumas la komandojn specifitajn en la agorda dosiero, inkluzive de deplojado de la taŭgaj branĉoj de la deponejo.

▍ Labora vivociklo

Travis CI-agorda dosiero vokita .travis.yml kaj stokita en la projekta radika dosierujo, subtenas la koncepton de eventoj vivciklo taskoj. Jen la eventoj, listigitaj en la ordo en kiu ili okazas:

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

▍Testado

En la agorda dosiero, mi starigos lokan Travis CI-servilon. Mi elektis Nodon 12 kiel la lingvon kaj diris al la sistemo instali la dependecojn necesajn por uzi Docker.

Ĉio listigita en .travis.yml, estos efektivigita sur ĉiuj tiraj petoj al ĉiuj branĉoj de la deponejo, krom se alie specifita. Ĉi tio estas utila funkcio, ĉar ĝi signifas, ke ni povas testi la tutan kodon, kiu eniras la deponejon. Ĉi tio permesas vin scii ĉu la kodo estas preta por esti skribita al la branĉo. master, kaj ĉu ĝi rompos la konstruprocezon de la projekto. En ĉi tiu tutmonda agordo, mi instalas ĉion loke, rulas la Webpack-dev-servilon en la fono (ĉi tio estas trajto de mia laborfluo), kaj rulas la testojn.

Se vi volas, ke via deponejo aperu ikonojn pri koda kovrado, tie vi povas trovi rapidan lernilon pri kiel uzi Jest, Travis CI kaj Coveralls por kolekti kaj montri ĉi tiujn informojn.

Do jen la enhavo de la dosiero .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

Ĉi tie finiĝas la agoj kiuj estas faritaj por ĉiuj branĉoj de la deponejo kaj por tirpetoj.

▍Deplojo

Surbaze de la supozo, ke ĉiuj aŭtomatigitaj testoj sukcese finiĝis, ni povas laŭvole deploji la kodon al la produktadservilo. Ĉar ni volas fari tion nur por branĉokodo master, ni donas al la sistemo la taŭgajn instrukciojn en la disfaldaj agordoj. Antaŭ ol vi provos uzi la kodon, kiun ni rigardos poste en via projekto, mi ŝatus averti vin, ke vi devas havi realan skripton, kiu estas vokita por deplojo.

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

La deploja skripto faras du aferojn:

• Konstruante, etikedante kaj sendi la bildon al Docker Hub per CI-ilo (en nia kazo ĝi estas Travis CI).
• Ŝargante la bildon sur la servilo, haltigante la malnovan ujon kaj lanĉante novan (en nia kazo, la servilo funkcias sur la platformo DigitalOcean).

Unue, vi devas agordi aŭtomatan procezon por konstrui, etikedi kaj puŝi la bildon al Docker Hub. Ĉio ĉi estas tre simila al tio, kion ni jam faris permane, krom ke ĉi tie ni bezonas strategion por atribui unikajn etikedojn al bildoj kaj aŭtomatigi ensaluton. Mi havis malfacilaĵojn kun iuj detaloj de la deploja skripto, kiel etiked-strategio, ensaluti, kodi SSH-ŝlosilojn, establi SSH-konekton. Sed feliĉe, mia koramiko tre lertas pri bash, same kiel pri multaj aliaj aferoj. Li helpis min skribi ĉi tiun skripton.

Do, la unua parto de la skripto sendas la bildon al Docker Hub. Fari ĉi tion estas sufiĉe simpla. La etikedskemo, kiun mi uzis, implikas kombini la git hash kaj la git-etikedo se ĝi ekzistas. Ĉi tio certigas, ke la etikedo estas unika kaj faciligas identigi la kunigon, sur kiu ĝi baziĝas. DOCKER_USERNAME и DOCKER_PASSWORD estas uzant-difinitaj mediovariabloj kiuj povas esti agorditaj uzante la Travis CI-interfacon. Travis CI aŭtomate prilaboros sentemajn datumojn por ke ĝi ne falu en malĝustajn manojn.

Jen la unua parto de la skripto 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}

Kio estos la dua parto de la skripto dependas tute de kiu gastiganto vi uzas kaj kiel la konekto al ĝi estas organizita. En mia kazo, ĉar mi uzas Digital Ocean, la komandoj estas uzataj por konekti al la servilo doktl. Kiam vi laboras kun Aws, la ilo estos uzata aws, kaj tiel plu.

Agordi la servilon ne estis precipe malfacila. Do, mi starigis guteton bazitan sur la baza bildo. Oni devas rimarki, ke la sistemo, kiun mi elektis, postulas unufojan manan instaladon de Docker kaj unufojan manan ekfunkciigon de Docker. Mi uzis Ubuntu 18.04 por instali Docker, do se vi ankaŭ uzas Ubuntu, vi povas simple sekvi ĉi tio simpla gvidado.

Mi ne parolas pri specifaj komandoj por la servo ĉi tie, ĉar ĉi tiu aspekto povas multe varii en malsamaj kazoj. Mi nur donos ĝeneralan agadplanon por esti farita post konekto per SSH al la servilo, kie la projekto estos deplojita:

• Vi devas trovi la ujon kiu nun funkcias kaj haltigi ĝin.
• Tiam vi devas komenci novan ujon en la fono.
• Vi devos agordi la lokan havenon de la servilo al 80 - ĉi tio permesos al vi eniri la retejon ĉe la adreso de la formularo example.com, sen specifi havenon, prefere ol uzi adreson kiel example.com:5000.
• Kaj finfine, vi devas forigi ĉiujn malnovajn ujojn kaj bildojn.

Jen la daŭrigo de la skripto.

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

Kelkaj aferoj por atenti

Eblas, ke kiam vi konektas al la servilo per SSH de Travis CI, vi vidos averton, kiu ne permesos al vi daŭrigi kun la instalado, ĉar la sistemo atendos la respondon de la uzanto.

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

Mi lernis, ke ĉenŝlosilo povas esti kodita en bazo64 por konservi ĝin en formo, en kiu oni povas oportune kaj fidinde labori kun ĝi. En la instala stadio, vi povas malkodi la publikan ŝlosilon kaj skribi ĝin al dosiero known_hosts por forigi la supran eraron.

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

En praktiko, ĉi tiu komando povus aspekti jene:

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

Kaj jen kion ĝi donas - baz64 kodita ĉeno:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Jen la komando menciita supre

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

La sama aliro povas esti uzata per privata ŝlosilo dum establado de konekto, ĉar vi eble bezonas privatan ŝlosilon por aliri la servilon. Kiam vi laboras kun ŝlosilo, vi nur bezonas certigi, ke ĝi estas sekure konservita en mediovariablo de Travis CI, kaj ke ĝi ne aperos ie ajn.

Alia afero por noti estas, ke vi eble bezonos ruli la tutan deplojan skripton kiel ununura linio, ekzemple kun doctl. Ĉi tio povas postuli iom da ekstra peno.

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

TLS/SSL kaj ŝarĝo-ekvilibro

Post kiam mi faris ĉion supre, la lasta problemo, kiun mi havis, estis ke la servilo ne havis SSL. Ĉar mi uzas Node.js-servilon, por devigi labori inversa prokurilo Nginx kaj Let's Encrypt, vi devas tre rumpi.

Mi vere ne volis fari ĉiujn ĉi tiujn SSL-agordojn permane, do mi ĵus kreis ŝargilon kaj registris informojn pri ĝi en DNS. En la kazo de DigitalOcean, ekzemple, krei aŭtomaten renovigantan memsubskribitan atestilon sur la ŝarĝbalancilo estas simpla, senpaga kaj rapida proceduro. Ĉi tiu aliro havas la kroman avantaĝon tre facile agordi SSL sur pluraj serviloj kurantaj malantaŭ ŝarĝbalancilo se necese. Tio ebligas al la serviloj mem tute ne "pensi" pri SSL, sed samtempe uzi, kiel kutime, la havenon. 80. Do agordi SSL sur ŝarĝbalancilo estas multe pli facila kaj pli oportuna ol alternativaj SSL-agordaj metodoj.

Nun vi povas fermi ĉiujn havenojn de la servilo, kiuj akceptas envenantajn konektojn - krom la haveno 80, uzata por komuniki kun la ŝarĝbalancilo, kaj la haveno 22 por SSH. Kiel rezulto, provo kontakti la servilon rekte sur iuj havenoj krom ĉi tiuj du malsukcesos.

Rezultoj

Post kiam mi faris ĉion, pri kio mi parolis en ĉi tiu artikolo, nek la Docker-platformo nek la koncepto de aŭtomatigitaj CI / KD-ĉenoj timigis min plu. Mi povis starigi kontinuan integrigan ĉenon, dum kiu la kodo estas provita antaŭ ol ĝi iras en produktadon kaj la kodo estas aŭtomate deplojita al la servilo. Ĉio ĉi estas ankoraŭ relative nova por mi, kaj mi certas, ke ekzistas manieroj plibonigi mian aŭtomatigitan laborfluon kaj fari ĝin pli efika. Do se vi havas ideojn pri tio - donu mi scias. Mi esperas, ke ĉi tiu artikolo helpis vin en viaj klopodoj. Mi volas kredi, ke legante ĝin, vi lernis tiom multe kiom mi lernis dum mi pritraktis ĉion, pri kio mi rakontis en ĝi.

PS En nia foirejo estas bildo Docker, kiu estas instalita per unu klako. Vi povas kontroli, ke la ujoj funkcias VPS. Ĉiuj novaj klientoj ricevas 3 tagojn da testado senpage.

Karaj legantoj! Ĉu vi uzas CI/CD-teknologiojn en viaj projektoj?

fonto: www.habr.com