Ustvarjanje CI/CD verige in avtomatizacija dela z Dockerjem

Svoje prve spletne strani sem napisal v poznih 90. letih. Takrat jih je bilo zelo enostavno spraviti v delovno stanje. Na nekem deljenem gostovanju je bil strežnik Apache, v ta strežnik si se lahko prijavil prek FTP, tako da si napisal nekaj takega ftp://ftp.example.com. Nato ste morali vnesti svoje ime in geslo ter naložiti datoteke na strežnik. Bili so drugačni časi, takrat je bilo vse bolj preprosto kot zdaj.

V dveh desetletjih od takrat se je vse zelo spremenilo. Spletne strani so postale bolj zapletene, preden jih damo v proizvodnjo, jih je treba sestaviti. Iz enega samega strežnika je postalo veliko strežnikov, ki delujejo za izravnalniki obremenitve, in uporaba sistemov za nadzor različic je postala običajna.

Za svoj osebni projekt sem imel posebno konfiguracijo. In vedel sem, da potrebujem možnost umestitve spletnega mesta v produkcijo z izvedbo samo enega dejanja: pisanje kode v vejo master na GitHubu. Poleg tega sem vedel, da za zagotovitev delovanja moje majhne spletne aplikacije ne želim upravljati ogromne gruče Kubernetes ali uporabljati tehnologije Docker Swarm ali vzdrževati flote strežnikov s podi, agenti in vsemi drugimi zapletenosti. Da bi dosegel cilj čim lažjega dela, sem se moral seznaniti s CI/CD.

Če imate majhen projekt (v tem primeru projekt Node.js) in bi radi vedeli, kako avtomatizirati uvajanje tega projekta, hkrati pa zagotoviti, da se tisto, kar je shranjeno v repozitoriju, natančno ujema s tem, kar deluje v proizvodnji, potem jaz mislim, da bi vas ta članek morda zanimal.

Predpogoji

Od bralca tega članka se pričakuje, da bo imel osnovno razumevanje ukazne vrstice in pisanja skriptov Bash. Poleg tega bo potreboval račune Travis CI и Dock pesto.

Cilji

Ne bom rekel, da lahko ta članek brezpogojno imenujemo "vadnica". To je bolj dokument, v katerem govorim o tem, kar sem se naučil, in opisujem postopek, ki mi ustreza za testiranje in uvajanje kode v produkcijo, izvedeno v enem avtomatiziranem prehodu.

Tako se je končal moj potek dela.

Za kodo, objavljeno v kateri koli veji skladišča, razen master, se izvedejo naslednja dejanja:

• Začne se gradnja projekta na Travis CI.
• Izvedeni so vsi testi enot, integracija in preskusi od konca do konca.

Samo za kodo, ki spada v master, se izvede naslednje:

• Vse zgoraj omenjeno, plus...
• Gradnja slike Docker na podlagi trenutne kode, nastavitev in okolja.
• Uvajanje slike v Docker Hub.
• Povezava s produkcijskim strežnikom.
• Nalaganje slike iz Docker Huba na strežnik.
• Zaustavitev trenutnega vsebnika in zagon novega na podlagi nove slike.

Če o Dockerju, slikah in vsebnikih ne veste prav nič, ne skrbite. Vse ti bom povedal.

Kaj je CI/CD?

Okrajšava CI/CD pomeni »neprekinjena integracija/neprekinjeno uvajanje«.

▍Nenehna integracija

Nenehna integracija je proces, v katerem se razvijalci zavežejo k glavnemu repozitoriju izvorne kode projekta (običajno veji master). Hkrati je kakovost kode zagotovljena z avtomatiziranim testiranjem.

▍Neprekinjeno uvajanje

Neprekinjeno uvajanje je pogosto, avtomatizirano uvajanje kode v proizvodnjo. Drugi del akronima CI/CD je včasih napisan kot »neprekinjena dostava«. To je v bistvu enako kot »neprekinjeno uvajanje«, vendar »neprekinjeno uvajanje« pomeni potrebo po ročni potrditvi sprememb pred začetkom postopka uvajanja projekta.

Začetek

Aplikacija, s katero sem se vsega tega naučil, se imenuje TakeNote. To je spletni projekt, na katerem delam, zasnovan za zapisovanje. Sprva sem poskušal narediti JAMStack-projekt ali samo sprednja aplikacija brez strežnika, da bi izkoristili standardno gostovanje in zmožnosti uvajanja projektov, ki jih ponuja Izčrpajte. Ker je kompleksnost aplikacije rasla, sem moral ustvariti njen strežniški del, kar je pomenilo, da sem moral oblikovati lastno strategijo za avtomatsko integracijo in avtomatizirano uvedbo projekta.

V mojem primeru je aplikacija strežnik Express, ki deluje v okolju Node.js, služi enostranski aplikaciji React in podpira varen API na strani strežnika. Ta arhitektura sledi strategiji, ki jo lahko najdete v ta Vodnik za preverjanje pristnosti celotnega sklada.

Posvetoval sem se z prijatelj, ki je strokovnjak za avtomatizacijo, in ga vprašal, kaj moram narediti, da bo vse delovalo tako, kot želim. Dal mi je idejo o tem, kako naj bi izgledal avtomatiziran potek dela, ki je opisan v razdelku Cilji tega članka. Imeti te cilje je pomenilo, da sem moral ugotoviti, kako uporabljati Docker.

Lučki delavec

Docker je orodje, ki zahvaljujoč tehnologiji kontejnerizacije omogoča enostavno distribucijo, namestitev in izvajanje aplikacij v istem okolju, tudi če sama platforma Docker deluje v različnih okoljih. Najprej sem se moral dokopati do Dockerjevih orodij ukazne vrstice (CLI). navodilo Vodnika za namestitev Dockerja ne moremo imenovati zelo jasnega in razumljivega, vendar se iz njega lahko naučite, da morate za prvi korak namestitve prenesti Docker Desktop (za Mac ali Windows).

Docker Hub je približno enaka stvar kot GitHub za repozitorije git ali register npm za pakete JavaScript. To je spletno skladišče slik Docker. To je tisto, s čimer se poveže Docker Desktop.

Torej, če želite začeti uporabljati Docker, morate narediti dve stvari:

• Set DockerDesktop.
• Registrirajte se za Dock pesto.

Po tem lahko preverite, ali Docker CLI deluje tako, da zaženete naslednji ukaz za preverjanje različice Dockerja:

docker -v

Nato se prijavite v Docker Hub tako, da na vprašanje vnesete svoje uporabniško ime in geslo:

docker login

Če želite uporabljati Docker, morate razumeti koncepte slik in vsebnikov.

▍Slike

Slika je nekaj podobnega načrtu, ki vsebuje navodila za sestavljanje posode. To je nespremenljiv posnetek datotečnega sistema in nastavitev aplikacije. Razvijalci lahko preprosto delijo slike.

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

Ta ukaz bo prikazal tabelo z naslednjo glavo:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

Nato si bomo ogledali nekaj primerov ukazov v istem formatu - najprej je ukaz s komentarjem, nato pa primer, kaj lahko izpiše.

▍Zabojniki

Vsebnik je izvršljiv paket, ki vsebuje vse, kar je potrebno za zagon aplikacije. Aplikacija s tem pristopom bo vedno delovala enako, ne glede na infrastrukturo: v izoliranem okolju in v istem okolju. Bistvo je, da se primerki iste slike zaženejo v različnih okoljih.

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

▍Oznake

Oznaka je indikacija določene različice slike.

▍Hiter sklic na ukaze Docker

Tukaj je pregled nekaterih pogosto uporabljenih ukazov Docker.

Ekipa

Kontekst

učinek

gradnjo dockerja

Slika

Gradnja slike iz datoteke Docker

docker oznaka

Slika

Označevanje slik

slike priklopnikov

Slika

Seznam slik

Docker teče

posoda

Zagon vsebnika na podlagi slike

Docker push

Slika

Nalaganje slike v register

docker pull

Slika

Nalaganje slike iz registra

docker ps

posoda

Vsebniki za sezname

obrezovanje docker sistema

Slika/vsebnik

Odstranjevanje neuporabljenih vsebnikov in slik

▍Dockerfile

Znam zagnati produkcijsko aplikacijo lokalno. Imam konfiguracijo Webpack, zasnovano za izdelavo že pripravljene aplikacije React. Nato imam ukaz, ki na vratih zažene strežnik, ki temelji na Node.js 5000. Videti je takole:

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

Opozoriti je treba, da nimam vzorčne aplikacije za ta material. Toda tukaj je za poskuse primerna katera koli preprosta aplikacija Node.

Če želite uporabiti vsebnik, boste morali dati navodila Dockerju. To se naredi prek datoteke, imenovane Dockerfile, ki se nahaja v korenskem imeniku projekta. Ta datoteka se na prvi pogled zdi precej nerazumljiva.

Toda tisto, kar vsebuje, le opisuje s posebnimi ukazi nekaj podobnega nastavitvi delovnega okolja. Tukaj je nekaj teh ukazov:

• OD — Ta ukaz zažene datoteko. Določa osnovno sliko, na kateri je zgrajen vsebnik.
• COPY — Kopiranje datotek iz lokalnega vira v vsebnik.
• DELOVNI DIR — Nastavitev delovnega imenika za naslednje ukaze.
• RUN - Zagon ukazov.
• IZPOSTAVITEV — Nastavitve vrat.
• VSTOPNA TOČKA — Navedba ukaza, ki naj se izvede.

Dockerfile lahko izgleda nekako takole:

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

Odvisno od osnovne slike, ki jo izberete, boste morda morali namestiti dodatne odvisnosti. Dejstvo je, da so nekatere osnovne slike (kot je Node Alpine Linux) ustvarjene s ciljem, da so čim bolj kompaktne. Posledično morda nimajo nekaterih programov, ki jih pričakujete.

▍Gradnja, označevanje in vodenje vsebnika

Lokalna montaža in zagon zabojnika je po tem, ko imamo Dockerfile, naloge so čisto preproste. Preden potisnete sliko v Docker Hub, jo morate preizkusiti lokalno.

▍Sestavljanje

Najprej morate zbrati sliko, ki določa ime in po želji oznako (če oznaka ni podana, bo sistem samodejno dodelil oznako sliki latest).

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

Ko zaženete ta ukaz, lahko opazujete, kako Docker gradi sliko.

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

Gradnja lahko traja nekaj minut - vse je odvisno od tega, koliko odvisnosti imate. Ko je gradnja končana, lahko zaženete ukaz docker images in si oglejte opis svoje nove slike.

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

▍Zagon

Slika je ustvarjena. To pomeni, da lahko na njegovi podlagi zaženete vsebnik. Ker želim imeti dostop do aplikacije, ki se izvaja v vsebniku na localhost:5000, jaz, na levi strani para 5000:5000 v naslednjem nameščenem ukazu 5000. Na desni strani je odprtina za kontejner.

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

Zdaj, ko je vsebnik ustvarjen in se izvaja, lahko uporabite ukaz docker ps da si ogledate informacije o tem vsebniku (ali pa uporabite ukaz docker ps -a, ki prikazuje informacije o vseh vsebnikih, ne samo o delujočih).

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

Če zdaj greš na naslov localhost:5000 — vidite lahko stran delujoče aplikacije, ki je videti popolnoma enako kot stran aplikacije, ki se izvaja v produkcijskem okolju.

▍Označevanje in objava

Če želimo uporabiti eno od ustvarjenih slik na produkcijskem strežniku, moramo imeti možnost prenesti to sliko iz Docker Huba. To pomeni, da morate najprej ustvariti repozitorij za projekt v Docker Hubu. Po tem bomo imeli prostor, kamor lahko pošljemo sliko. Sliko je treba preimenovati tako, da se njeno ime začne z našim uporabniškim imenom Docker Hub. Temu mora slediti ime repozitorija. Na koncu imena lahko postavite katero koli oznako. Spodaj je primer poimenovanja slik s to shemo.

Zdaj lahko zgradite sliko z novim imenom in zaženete ukaz docker push da ga potisnete v repozitorij 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

Če bo šlo vse v redu, bo slika na voljo v Docker Hubu in jo bo mogoče preprosto naložiti na strežnik ali prenesti drugim razvijalcem.

Naslednji koraki

Do zdaj smo preverili, ali aplikacija v obliki vsebnika Docker deluje lokalno. Vsebnik smo naložili v Docker Hub. Vse to pomeni, da smo že zelo dobro napredovali proti našemu cilju. Zdaj moramo rešiti še dve vprašanji:

• Nastavitev orodja CI za testiranje in uvajanje kode.
• Nastavitev produkcijskega strežnika, da lahko prenese in izvaja našo kodo.

V našem primeru uporabljamo Travis CI. Kot strežnik - DitigalOcean.

Treba je opozoriti, da tukaj lahko uporabite drugo kombinacijo storitev. Na primer, namesto Travis CI lahko uporabite CircleCI ali Github Actions. In namesto DigitalOcean - AWS ali Linode.

Odločili smo se za sodelovanje s Travis CI in že imam nekaj konfiguriranega v tej storitvi. Zato bom zdaj na kratko govoril o tem, kako ga pripraviti na delo.

Travis CI

Travis CI je orodje za testiranje in uvajanje kode. Ne bi se rad spuščal v zapletenost postavitve Travis CI, saj je vsak projekt edinstven in to ne bo prineslo veliko koristi. Če se odločite za uporabo Travis CI, vam bom za lažji začetek predstavil osnove. Ne glede na to, ali izberete Travis CI, CircleCI, Jenkins ali kaj drugega, bodo podobne konfiguracijske metode uporabljene povsod.

Če želite začeti uporabljati Travis CI, pojdite na spletno mesto projekta in ustvarite račun. Nato integrirajte Travis CI s svojim računom GitHub. Pri nastavitvi sistema boste morali določiti repozitorij, s katerim želite avtomatizirati delo in omogočiti dostop do njega. (Uporabljam GitHub, vendar sem prepričan, da se lahko Travis CI integrira z BitBucket, GitLab in drugimi podobnimi storitvami).

Ob vsakem zagonu Travis CI se zažene strežnik, ki izvaja ukaze, podane v konfiguracijski datoteki, vključno z razmestitvijo ustreznih vej repozitorija.

▍Življenjski cikel zaposlitve

Poklicana konfiguracijska datoteka Travis CI .travis.yml in shranjen v korenskem imeniku projekta, podpira koncept dogodkov življenski krog naloge. Ti dogodki so navedeni v vrstnem redu, v katerem se zgodijo:

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

▍Testiranje

V konfiguracijski datoteki bom konfiguriral lokalni strežnik Travis CI. Za jezik sem izbral Node 12 in sistemu naročil, naj namesti odvisnosti, potrebne za uporabo Dockerja.

Vse, kar je navedeno v .travis.yml, bo izvedeno, ko bodo vse vlečne zahteve poslane vsem vejam skladišča, razen če ni določeno drugače. To je uporabna funkcija, ker pomeni, da lahko preizkusimo vso kodo, ki pride v skladišče. To vam pove, ali je koda pripravljena za pisanje v podružnico. master, in ali bo prekinil proces gradnje projekta. V tej globalni konfiguraciji vse namestim lokalno, zaženem razvijalski strežnik Webpack v ozadju (to je značilnost mojega delovnega toka) in izvedem teste.

Če želite, da vaše skladišče prikazuje značke, ki označujejo pokritost testa, tukaj Najdete kratka navodila za uporabo Jest, Travis CI in Coveralls za zbiranje in prikaz teh informacij.

Tukaj je torej vsebina datoteke .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

Tu se končajo dejanja, ki se izvajajo za vse veje skladišča in za zahteve po vleku.

▍Uvajanje

Na podlagi predpostavke, da so vsi avtomatizirani testi uspešno zaključeni, lahko kodo, kar ni obvezno, uvedemo v produkcijski strežnik. Ker želimo to narediti samo za kodo iz veje master, damo sistemu ustrezna navodila v nastavitvah uvajanja. Preden poskusite uporabiti kodo, ki si jo bomo naslednjič ogledali v vašem projektu, vas želim opozoriti, da morate imeti dejanski skript, poklican za uvajanje.

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

Skript za uvajanje rešuje dve težavi:

• Zgradite, označite in pošljite sliko v Docker Hub z orodjem CI (v našem primeru Travis CI).
• Nalaganje slike na strežnik, zaustavitev starega vsebnika in zagon novega (v našem primeru strežnik deluje na platformi DigitalOcean).

Najprej morate nastaviti samodejni postopek za gradnjo, označevanje in potiskanje slike v Docker Hub. Vse to je zelo podobno tistemu, kar smo že naredili ročno, le da potrebujemo strategijo za dodeljevanje edinstvenih oznak slikam in avtomatizacijo prijav. Imel sem težave z nekaterimi podrobnostmi skripta za uvajanje, kot so strategija označevanja, prijava, kodiranje ključa SSH, vzpostavitev povezave SSH. Ampak na srečo je moj fant zelo dober z bashom, kot z mnogimi drugimi stvarmi. Pomagal mi je napisati ta scenarij.

Torej, prvi del skripta je nalaganje slike v Docker Hub. To je zelo enostavno narediti. Shema označevanja, ki sem jo uporabil, vključuje kombinacijo zgoščene vrednosti git in oznake git, če ta obstaja. To zagotavlja, da je oznaka edinstvena in omogoča lažjo identifikacijo sklopa, na katerem temelji. DOCKER_USERNAME и DOCKER_PASSWORD so spremenljivke uporabniškega okolja, ki jih je mogoče nastaviti z vmesnikom Travis CI. Travis CI bo samodejno obdelal občutljive podatke, da ne bi prišli v napačne roke.

Tukaj je prvi del scenarija 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}

Kakšen bo drugi del skripte, je v celoti odvisno od tega, kateri gostitelj uporabljate in kako je organizirana povezava z njim. V mojem primeru, ker uporabljam Digital Ocean, uporabljam ukaze za povezavo s strežnikom doktl. Pri delu z AWS bo uporabljen pripomoček aws, in tako naprej.

Nastavitev strežnika ni bila posebej težka. Torej sem nastavil kapljico na podlagi osnovne slike. Upoštevati je treba, da sistem, ki sem ga izbral, zahteva enkratno ročno namestitev Dockerja in enkraten ročni zagon Dockerja. Za namestitev Dockerja sem uporabil Ubuntu 18.04, tako da, če tudi vi uporabljate Ubuntu za isto, lahko sledite to preprost vodnik.

Tu ne govorim o posebnih ukazih za storitev, saj se lahko ta vidik v različnih primerih zelo razlikuje. Podal bom le splošen načrt ukrepov, ki jih je treba izvesti po povezavi prek SSH s strežnikom, na katerem bo projekt nameščen:

• Najti moramo vsebnik, ki trenutno teče, in ga ustaviti.
• Nato morate zagnati nov vsebnik v ozadju.
• Lokalna vrata strežnika boste morali nastaviti na 80 - to vam bo omogočilo vstop na spletno mesto na naslovu, kot je example.com, ne da bi navedli vrata, namesto da bi uporabili naslov, kot je example.com:5000.
• Nazadnje morate izbrisati vse stare vsebnike in slike.

Tukaj je nadaljevanje scenarija.

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

Nekaj ​​stvari, na katere je treba biti pozoren

Možno je, da se vam ob povezavi s strežnikom prek SSH iz Travis CI prikaže opozorilo, ki vam bo preprečilo nadaljevanje namestitve, saj bo sistem čakal na odziv uporabnika.

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

Naučil sem se, da je mogoče ključ niza kodirati v base64, da ga shranim v obliki, v kateri je mogoče z njim priročno in zanesljivo delati. V fazi namestitve lahko dekodirate javni ključ in ga zapišete v datoteko known_hosts da se znebite zgornje napake.

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

V praksi lahko ta ukaz izgleda takole:

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

In to je tisto, kar ustvari - base64 kodiran niz:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Tukaj je zgoraj omenjeni ukaz

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

Enak pristop lahko uporabite z zasebnim ključem pri vzpostavljanju povezave, saj boste morda potrebovali zasebni ključ za dostop do strežnika. Ko delate s ključem, morate le zagotoviti, da je varno shranjen v spremenljivki okolja Travis CI in da ni nikjer prikazan.

Druga stvar, ki jo morate upoštevati, je, da boste morda morali zagnati celoten skript za uvajanje kot eno vrstico, na primer - z doctl. To lahko zahteva nekaj dodatnega truda.

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

TLS/SSL in uravnoteženje obremenitve

Ko sem naredil vse zgoraj omenjeno, je bila zadnja težava, na katero sem naletel, da strežnik ni imel SSL. Ker uporabljam strežnik Node.js, da prisilim za delo obratni proxy Nginx in Let's Encrypt, morate veliko delati.

Vse te konfiguracije SSL res nisem želel izvesti ročno, zato sem samo ustvaril izravnalnik obremenitve in njegove podrobnosti zabeležil v DNS. V primeru DigitalOcean je na primer ustvarjanje samopodpisanega potrdila s samodejnim obnavljanjem na izravnalniku obremenitve preprost, brezplačen in hiter postopek. Ta pristop ima dodatno prednost, saj omogoča zelo preprosto nastavitev SSL na več strežnikih, ki se izvajajo za izravnalnikom obremenitve, če je to potrebno. To omogoča strežnikom, da sploh ne "razmišljajo" o SSL, hkrati pa uporabljajo vrata kot običajno 80. Tako je nastavitev SSL na izravnalniku obremenitve veliko enostavnejša in priročnejša od alternativnih metod nastavitve SSL.

Zdaj lahko zaprete vsa vrata na strežniku, ki sprejemajo dohodne povezave - razen vrat 80, ki se uporablja za komunikacijo z izravnalnikom obremenitve, in vrati 22 za SSH. Posledično bo poskus neposrednega dostopa do strežnika na vseh vratih, razen na teh dveh, neuspešen.

Rezultati

Ko sem naredil vse, o čemer sem govoril v tem gradivu, me niti platforma Docker niti koncepti avtomatiziranih verig CI/CD niso več prestrašili. Uspelo mi je vzpostaviti neprekinjeno integracijsko verigo, med katero se koda testira, preden gre v produkcijo, koda pa se samodejno namesti na strežnik. Vse to je zame še relativno novo in prepričan sem, da obstajajo načini, kako izboljšati svoj avtomatizirani potek dela in ga narediti učinkovitejšega. Torej, če imate kakršne koli ideje o tej zadevi, mi prosim sporočite. me vedeti. Upam, da vam je ta članek pomagal pri vaših prizadevanjih. Želim verjeti, da ste se po branju naučili toliko, kot sem se jaz naučil, ko sem ugotovil vse, o čemer sem govoril v njem.

PS V našem tržnica obstaja slika Lučki delavec, ki se namesti z enim klikom. Delovanje zabojnikov lahko preverite na VPS. Vse nove stranke dobijo 3 dni brezplačnega testiranja.

Drage bralke in bralci! Ali pri svojih projektih uporabljate tehnologije CI/CD?

Vir: www.habr.com