Stvaranje CI/CD lanca i automatizacija rada s Dockerom

Napisao sam svoje prve web stranice u kasnim 90-ima. Tada ih je bilo vrlo lako staviti u radno stanje. Postojao je Apache poslužitelj na nekom dijeljenom hostingu, mogli ste se prijaviti na ovaj poslužitelj putem FTP-a tako da napišete nešto poput ftp://ftp.example.com. Zatim ste morali unijeti svoje ime i lozinku i učitati datoteke na poslužitelj. Bila su druga vremena, tada je sve bilo jednostavnije nego sada.

U dva desetljeća od tada sve se jako promijenilo. Web stranice su postale složenije; moraju se sastaviti prije puštanja u proizvodnju. Od jednog poslužitelja postali su mnogi poslužitelji koji rade iza balansera opterećenja, a korištenje sustava za kontrolu verzija postalo je uobičajeno.

Za svoj osobni projekt imao sam posebnu konfiguraciju. I znao sam da trebam mogućnost implementacije stranice u produkciju izvođenjem samo jedne radnje: pisanje koda u granu master na GitHubu. Osim toga, znao sam da, kako bih osigurao rad svoje male web aplikacije, ne želim upravljati ogromnim Kubernetes klasterom, niti koristiti Docker Swarm tehnologiju, niti održavati flotu poslužitelja s podovima, agentima i svim drugim vrstama složenosti. Kako bih ostvario cilj što lakšeg rada, morao sam upoznati CI/CD.

Ako imate mali projekt (u ovom slučaju Node.js projekt) i željeli biste znati kako automatizirati implementaciju ovog projekta, istovremeno osiguravajući da ono što je pohranjeno u repozitoriju točno odgovara onome što radi u proizvodnji, onda ja mislim da bi vas ovaj članak mogao zanimati.

Preduvjeti

Od čitatelja ovog članka očekuje se osnovno razumijevanje naredbenog retka i pisanja Bash skripti. Osim toga, trebat će mu račune Travis C.I. и Docker čvorište.

ciljevi

Neću reći da se ovaj članak bezuvjetno može nazvati "tutorijalom". Ovo je više dokument u kojem govorim o onome što sam naučio i opisujem proces koji mi odgovara za testiranje i implementaciju koda u proizvodnju, koji se izvodi u jednom automatiziranom prolazu.

Ovako je završio moj tijek rada.

Za kod objavljen u bilo kojoj grani repozitorija osim master, izvode se sljedeće radnje:

• Započinje izgradnja projekta na Travis CI.
• Izvode se svi jedinični, integracijski i end-to-end testovi.

Samo za kod koji spada u master, izvodi se sljedeće:

• Sve gore navedeno, plus...
• Izrada Docker slike na temelju trenutnog koda, postavki i okruženja.
• Postavljanje slike u Docker Hub.
• Veza s proizvodnim poslužiteljem.
• Prijenos slike iz Docker Huba na poslužitelj.
• Zaustavljanje trenutnog spremnika i pokretanje novog na temelju nove slike.

Ako ne znate apsolutno ništa o Dockeru, slikama i spremnicima, ne brinite. Ispričat ću ti sve o tome.

Što je CI/CD?

Kratica CI/CD označava "stalnu integraciju/kontinuiranu implementaciju".

▍Kontinuirana integracija

Kontinuirana integracija je proces u kojem se programeri obvezuju na glavni repozitorij izvornog koda projekta (obično ogranak master). U isto vrijeme, kvaliteta koda je osigurana kroz automatizirano testiranje.

▍Kontinuirana implementacija

Kontinuirana implementacija je česta, automatizirana implementacija koda u proizvodnju. Drugi dio CI/CD akronima ponekad se piše kao "kontinuirana isporuka". To je u osnovi isto što i "kontinuirana implementacija", ali "kontinuirana isporuka" podrazumijeva potrebu za ručnom potvrdom promjena prije pokretanja procesa implementacije projekta.

Početak

Aplikacija koju sam koristio da naučim sve ovo zove se Uzeti na znanje. Ovo je web projekt na kojem radim, dizajniran za bilježenje. Isprva sam pokušao učiniti JAMStack-projekt ili samo front-end aplikacija bez poslužitelja, kako bi se iskoristile prednosti standardnog hostinga i mogućnosti implementacije projekta koje nudi Netlify. Kako je kompleksnost aplikacije rasla, trebao sam izraditi njezin serverski dio, što je značilo da sam trebao formulirati vlastitu strategiju za automatsku integraciju i automatiziranu implementaciju projekta.

U mom slučaju, aplikacija je Express poslužitelj koji radi u okruženju Node.js, poslužuje React aplikaciju na jednoj stranici i podržava sigurni API na strani poslužitelja. Ova arhitektura slijedi strategiju koja se može pronaći u ovo Vodič za autentifikaciju punog niza.

Konzultirao sam se sa prijatelju, koji je stručnjak za automatizaciju, i pitao ga što trebam učiniti da sve funkcionira kako želim. Dao mi je ideju kako bi automatizirani tijek rada trebao izgledati, što je opisano u odjeljku Ciljevi ovog članka. Postojanje tih ciljeva značilo je da sam trebao shvatiti kako koristiti Docker.

Lučki radnik

Docker je alat koji, zahvaljujući tehnologiji kontejnerizacije, omogućuje jednostavnu distribuciju, implementaciju i rad aplikacija u istom okruženju, čak i ako sama Docker platforma radi u različitim okruženjima. Prvo sam se trebao dočepati Dockerovih alata za naredbeni redak (CLI). uputa Vodič za instalaciju Dockera ne može se nazvati vrlo jasnim i razumljivim, ali iz njega možete naučiti da za prvi korak instalacije morate preuzeti Docker Desktop (za Mac ili Windows).

Docker Hub je otprilike ista stvar kao GitHub za git spremišta ili registar NPM za JavaScript pakete. Ovo je online repozitorij za Docker slike. To je ono na što se povezuje Docker Desktop.

Dakle, da biste započeli s Dockerom, trebate učiniti dvije stvari:

• Postaviti Docker radna površina.
• Registrirajte se za Docker čvorište.

Nakon toga možete provjeriti radi li Docker CLI pokretanjem sljedeće naredbe za provjeru verzije Dockera:

docker -v

Zatim se prijavite na Docker Hub unosom korisničkog imena i lozinke kada se to od vas zatraži:

docker login

Da biste koristili Docker, morate razumjeti koncepte slika i spremnika.

▍Slike

Slika je nešto poput nacrta koji sadrži upute za sastavljanje spremnika. Ovo je nepromjenjiva snimka datotečnog sustava i postavki aplikacije. Programeri mogu jednostavno dijeliti slike.

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

Ova naredba će ispisati tablicu sa sljedećim zaglavljem:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

Zatim ćemo pogledati neke primjere naredbi u istom formatu - prvo je naredba s komentarom, a zatim primjer onoga što može ispisati.

▍Kontejneri

Spremnik je izvršni paket koji sadrži sve što je potrebno za pokretanje aplikacije. Aplikacija s ovim pristupom uvijek će raditi isto, bez obzira na infrastrukturu: u izoliranom okruženju iu istom okruženju. Poanta je da se instance iste slike pokreću u različitim okruženjima.

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

▍Oznake

Oznaka je pokazatelj određene verzije slike.

▍Brza referenca Docker naredbi

Evo pregleda nekih često korištenih Docker naredbi.

Momčad

Kontekst

posljedica

docker build

slika

Izrada slike iz Dockerfilea

docker oznaka

slika

Označavanje slike

slike dockera

slika

Popis slika

vožnja dvoranom

kontejner

Pokretanje spremnika na temelju slike

docker push

slika

Učitavanje slike u registar

doker povući

slika

Učitavanje slike iz registra

dock ps

kontejner

Ispis spremnika

docker sustav orezati

Slika/spremnik

Uklanjanje neiskorištenih spremnika i slika

▍Dockerfile

Znam kako pokrenuti proizvodnu aplikaciju lokalno. Imam Webpack konfiguraciju dizajniranu za izradu gotove React aplikacije. Zatim, imam naredbu koja pokreće poslužitelj temeljen na Node.js na portu 5000... izgleda ovako:

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

Treba napomenuti da nemam primjer aplikacije za ovaj materijal. Ali ovdje će za eksperimente poslužiti bilo koja jednostavna Node aplikacija.

Kako biste koristili spremnik, morat ćete dati upute Dockeru. To se radi putem datoteke tzv Dockerfile, koji se nalazi u korijenskom direktoriju projekta. Ova se datoteka na prvu čini prilično nerazumljivom.

Ali ono što sadrži samo opisuje, s posebnim naredbama, nešto slično postavljanju radnog okruženja. Evo nekih od ovih naredbi:

• IZ — Ova naredba pokreće datoteku. Određuje osnovnu sliku na kojoj je izgrađen spremnik.
• KOPIRATI — Kopiranje datoteka iz lokalnog izvora u spremnik.
• RADNI DIR — Postavljanje radnog direktorija za sljedeće naredbe.
• TRČANJE - Pokretanje naredbi.
• IZLOŽITI — Postavke priključka.
• ULAZNA TOČKA — Indikacija naredbe koju treba izvršiti.

Dockerfile može izgledati ovako:

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

Ovisno o osnovnoj slici koju odaberete, možda ćete morati instalirati dodatne ovisnosti. Činjenica je da su neke osnovne slike (kao što je Node Alpine Linux) stvorene s ciljem da budu što kompaktnije. Kao rezultat toga, možda neće imati neke od programa koje očekujete.

▍Izrada, označavanje i pokretanje spremnika

Lokalna montaža i lansiranje kontejnera je nakon što imamo Dockerfile, zadaci su vrlo jednostavni. Prije nego što gurnete sliku u Docker Hub, trebate je testirati lokalno.

▍Sastavljanje

Prvo morate prikupiti sliku, navodeći naziv i, izborno, oznaku (ako oznaka nije navedena, sustav će automatski dodijeliti oznaku slici latest).

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

Nakon pokretanja ove naredbe, možete gledati kako Docker gradi sliku.

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

Izgradnja može potrajati nekoliko minuta - sve ovisi o tome koliko ovisnosti imate. Kada je izgradnja dovršena, možete pokrenuti naredbu docker images i pogledajte opis svoje nove slike.

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

▍Pokreni

Slika je stvorena. To znači da možete pokrenuti spremnik na temelju njega. Zato što želim imati pristup aplikaciji koja se izvodi u spremniku na adresi localhost:5000, ja, s lijeve strane para 5000:5000 u sljedećoj instaliranoj naredbi 5000. S desne strane je otvor za kontejnere.

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

Sada kada je spremnik kreiran i pokrenut, možete koristiti naredbu docker ps da pogledate informacije o ovom spremniku (ili možete koristiti naredbu docker ps -a, koji prikazuje informacije o svim spremnicima, a ne samo o onima koji rade).

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

Ako sada odete na adresu localhost:5000 — možete vidjeti stranicu pokrenute aplikacije koja izgleda potpuno isto kao stranica aplikacije koja se izvodi u produkcijskom okruženju.

▍Označavanje i objavljivanje

Kako bismo koristili jednu od stvorenih slika na produkcijskom poslužitelju, moramo moći preuzeti ovu sliku s Docker Huba. To znači da prvo trebate stvoriti spremište za projekt na Docker Hubu. Nakon toga, imat ćemo mjesto na koje možemo poslati sliku. Sliku je potrebno preimenovati tako da njezino ime počinje našim korisničkim imenom Docker Huba. Nakon toga treba slijediti naziv repozitorija. Bilo koja oznaka može se staviti na kraj imena. Ispod je primjer imenovanja slika pomoću ove sheme.

Sada možete izgraditi sliku s novim imenom i pokrenuti naredbu docker push da ga gurnete u repozitorij Docker Huba.

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

Ako sve bude u redu, slika će biti dostupna na Docker Hubu i lako se može učitati na poslužitelj ili prenijeti drugim programerima.

Sljedeći koraci

Do sada smo potvrdili da aplikacija, u obliku Docker spremnika, radi lokalno. Prenijeli smo spremnik u Docker Hub. Sve to znači da smo već jako dobro napredovali prema našem cilju. Sada moramo riješiti još dva pitanja:

• Postavljanje CI alata za testiranje i implementaciju koda.
• Postavljanje proizvodnog poslužitelja tako da može preuzeti i pokrenuti naš kod.

U našem slučaju koristimo Travis C.I.. Kao poslužitelj - DitigalOcean.

Treba napomenuti da ovdje možete koristiti drugu kombinaciju usluga. Na primjer, umjesto Travis CI, možete koristiti CircleCI ili Github Actions. I umjesto DigitalOceana - AWS ili Linode.

Odlučili smo raditi s Travis CI, a ja već imam nešto konfigurirano u ovoj usluzi. Stoga ću sada ukratko govoriti o tome kako ga pripremiti za rad.

Travis C.I.

Travis CI je alat za testiranje i implementaciju koda. Ne bih želio ulaziti u zamršenosti postavljanja Travis CI-ja, jer je svaki projekt jedinstven, a to neće donijeti mnogo koristi. Ali objasnit ću vam osnove da biste započeli ako odlučite koristiti Travis CI. Bilo da odaberete Travis CI, CircleCI, Jenkins ili nešto drugo, slične metode konfiguracije koristit će se posvuda.

Da biste započeli s Travis CI, idite na stranica projekta i kreirajte račun. Zatim integrirajte Travis CI sa svojim GitHub računom. Prilikom postavljanja sustava morat ćete navesti repozitorij s kojim želite automatizirati rad i omogućiti mu pristup. (Koristim GitHub, ali siguran sam da se Travis CI može integrirati s BitBucketom, GitLabom i drugim sličnim servisima).

Svaki put kada se pokrene Travis CI, pokreće se poslužitelj, izvršavajući naredbe navedene u konfiguracijskoj datoteci, uključujući postavljanje odgovarajućih grana repozitorija.

▍Životni ciklus posla

Pozvana je konfiguracijska datoteka Travis CI .travis.yml i pohranjen u korijenskom direktoriju projekta, podržava koncept događaja životni ciklus zadaci. Ti su događaji navedeni redoslijedom kojim su se dogodili:

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

▍Testiranje

U konfiguracijskoj datoteci konfigurirat ću lokalni Travis CI poslužitelj. Odabrao sam Node 12 kao jezik i rekao sustavu da instalira ovisnosti potrebne za korištenje Dockera.

Sve što je navedeno u .travis.yml, izvršit će se kada su svi zahtjevi za povlačenjem upućeni svim granama repozitorija, osim ako nije drugačije navedeno. Ovo je korisna značajka jer znači da možemo testirati sav kod koji dolazi u spremište. Ovo vam daje do znanja je li kod spreman za pisanje u ogranak. masteri hoće li prekinuti proces izgradnje projekta. U ovoj globalnoj konfiguraciji sve instaliram lokalno, pokrećem Webpack dev server u pozadini (ovo je značajka mog tijeka rada) i izvodim testove.

Ako želite da vaše spremište prikazuje značke koje označavaju pokrivenost testom, ovdje Možete pronaći kratke upute o korištenju Jest, Travis CI i Coveralls za prikupljanje i prikaz ovih informacija.

Dakle, ovdje je sadržaj 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

Ovdje završavaju akcije koje se izvode za sve grane repozitorija i za zahtjeve za povlačenjem.

▍Raspoređivanje

Na temelju pretpostavke da su svi automatizirani testovi uspješno završeni, možemo, što nije obavezno, implementirati kod na produkcijski poslužitelj. Budući da ovo želimo učiniti samo za kod iz grane master, sustavu dajemo odgovarajuće upute u postavkama implementacije. Prije nego što pokušate upotrijebiti kôd koji ćemo sljedeće pogledati u vašem projektu, želio bih vas upozoriti da morate imati stvarnu skriptu koja se poziva za implementaciju.

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

Skripta za implementaciju rješava dva problema:

• Izgradite, označite i pošaljite sliku u Docker Hub pomoću CI alata (u našem slučaju, Travis CI).
• Učitavanje slike na poslužitelj, zaustavljanje starog spremnika i pokretanje novog (u našem slučaju poslužitelj radi na platformi DigitalOcean).

Prvo morate postaviti automatski postupak za izradu, označavanje i slanje slike u Docker Hub. Sve je to vrlo slično onome što smo već radili ručno, osim što nam je potrebna strategija za dodjeljivanje jedinstvenih oznaka slikama i automatiziranje prijava. Imao sam poteškoća s nekim detaljima skripte za implementaciju, kao što su strategija označavanja, prijava, kodiranje SSH ključa, uspostavljanje SSH veze. Ali srećom, moj dečko je jako dobar s bashom, kao i s mnogim drugim stvarima. On mi je pomogao napisati ovaj scenarij.

Dakle, prvi dio skripte je učitavanje slike u Docker Hub. Ovo je vrlo lako učiniti. Shema označavanja koju sam koristio uključuje kombiniranje git hasha i git oznake, ako postoji. To osigurava da je oznaka jedinstvena i olakšava prepoznavanje sklopa na kojem se temelji. DOCKER_USERNAME и DOCKER_PASSWORD su varijable korisničkog okruženja koje se mogu postaviti pomoću Travis CI sučelja. Travis CI automatski će obraditi osjetljive podatke kako ne bi dospjeli u pogrešne ruke.

Evo prvog dijela 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}

Kakav će biti drugi dio skripte u potpunosti ovisi o hostu koji koristite i kako je organizirana veza s njim. U mom slučaju, budući da koristim Digital Ocean, koristim naredbe za spajanje na poslužitelj doktl. Kada radite s AWS-om, koristit će se uslužni program aws, i tako dalje.

Postavljanje poslužitelja nije bilo osobito teško. Dakle, postavio sam kapljicu na temelju osnovne slike. Treba napomenuti da sustav koji sam odabrao zahtijeva jednokratnu ručnu instalaciju Dockera i jednokratno ručno pokretanje Dockera. Koristio sam Ubuntu 18.04 za instalaciju Dockera, pa ako i vi koristite Ubuntu da učinite isto, možete jednostavno slijediti ovo jednostavan vodič.

Ovdje ne govorim o specifičnim naredbama za uslugu, jer ovaj aspekt može uvelike varirati u različitim slučajevima. Dat ću samo opći plan radnji koje treba izvršiti nakon spajanja putem SSH-a na poslužitelj na kojem će se projekt implementirati:

• Moramo pronaći spremnik koji trenutno radi i zaustaviti ga.
• Zatim trebate pokrenuti novi spremnik u pozadini.
• Morat ćete postaviti lokalni port poslužitelja na 80 - ovo će vam omogućiti da uđete na stranicu na adresi poput example.com, bez navođenja porta, umjesto korištenja adrese poput example.com:5000.
• Na kraju, trebate izbrisati sve stare spremnike i slike.

Evo nastavka 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

Neke stvari na koje treba obratiti pozornost

Moguće je da ćete, kada se povežete na poslužitelj putem SSH-a od Travis CI-ja, vidjeti upozorenje koje će vas spriječiti da nastavite s instalacijom jer će sustav čekati odgovor korisnika.

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čio sam da se ključ niza može kodirati u base64 kako bi se spremio u obliku u kojem se s njim može jednostavno i pouzdano raditi. U fazi instalacije možete dekodirati javni ključ i zapisati ga u datoteku known_hosts kako biste se riješili gornje pogreške.

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

U praksi bi ova naredba mogla izgledati ovako:

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

I evo što proizvodi - base64 kodirani niz:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Ovdje je gore navedena naredba

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

Isti pristup može se koristiti s privatnim ključem prilikom uspostavljanja veze, budući da ćete možda trebati privatni ključ za pristup poslužitelju. Kada radite s ključem, samo trebate osigurati da je sigurno pohranjen u Travis CI varijabli okruženja i da se nigdje ne prikazuje.

Još jedna stvar koju treba napomenuti je da ćete možda morati pokrenuti cijelu skriptu za implementaciju kao jedan redak, na primjer - s doctl. Ovo može zahtijevati dodatni napor.

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

TLS/SSL i balansiranje opterećenja

Nakon što sam napravio sve gore navedeno, posljednji problem na koji sam naišao je da poslužitelj nema SSL. Budući da koristim Node.js poslužitelj, kako bih prisilio raditi obrnuti proxy Nginx i Let's Encrypt, morate puno petljati.

Zaista nisam želio ručno raditi svu ovu konfiguraciju SSL-a, pa sam samo stvorio balanser opterećenja i zabilježio njegove detalje u DNS-u. U slučaju DigitalOceana, na primjer, stvaranje samopotpisanog certifikata s automatskim obnavljanjem na balanseru opterećenja jednostavan je, besplatan i brz postupak. Ovaj pristup ima dodatnu prednost jer vrlo jednostavno postavlja SSL na više poslužitelja koji rade iza balansera opterećenja ako je potrebno. To omogućuje samim poslužiteljima da uopće ne "razmišljaju" o SSL-u, ali u isto vrijeme koriste port kao i obično 80. Stoga je postavljanje SSL-a na balanseru opterećenja puno lakše i praktičnije od alternativnih metoda postavljanja SSL-a.

Sada možete zatvoriti sve portove na poslužitelju koji prihvaćaju dolazne veze - osim porta 80, koji se koristi za komunikaciju s balanserom opterećenja i priključkom 22 za SSH. Kao rezultat toga, pokušaj izravnog pristupa poslužitelju na bilo kojem portu osim ova dva neće uspjeti.

Rezultati

Nakon što sam napravio sve o čemu sam govorio u ovom materijalu, ni Docker platforma ni koncepti automatiziranih CI/CD lanaca više me nisu plašili. Uspio sam postaviti kontinuirani integracijski lanac, tijekom kojeg se kôd testira prije nego što krene u proizvodnju i kôd se automatski postavlja na poslužitelj. Sve mi je to još uvijek relativno novo i siguran sam da postoje načini da poboljšam svoj automatizirani tijek rada i učinim ga učinkovitijim. Dakle, ako imate bilo kakvih ideja o ovom pitanju, molim vas da mi kažete. mene znati. Nadam se da vam je ovaj članak pomogao u vašim nastojanjima. Želim vjerovati da ste nakon čitanja naučili onoliko koliko sam ja naučio dok sam shvaćao sve o čemu sam u njoj govorio.

PS U našem tržnica postoji slika Lučki radnik, koji se može instalirati jednim klikom. Rad kontejnera možete provjeriti na VPS. Svi novi klijenti dobivaju 3 dana besplatnog testiranja.

Dragi čitatelji! Koristite li CI/CD tehnologije u svojim projektima?

Izvor: www.habr.com