Kreiranje CI/CD lanca i automatizacija rada sa Dockerom

Svoje prve web stranice napisao sam kasnih 90-ih. Tada ih je bilo vrlo lako dovesti u radno stanje. Postojao je Apache server na nekom deljenom hostingu, ovom serveru se moglo pristupiti preko FTP-a tako što bi se u liniju pretraživača upisalo nešto poput ftp://ftp.example.com. Zatim je bilo potrebno unijeti ime i lozinku i postaviti fajlove na server. Bilo je i drugih vremena, tada je sve bilo jednostavnije nego sada.

Stvari su se dosta promijenile u protekle dvije decenije. Lokacije su postale složenije, moraju se sklopiti prije puštanja u proizvodnju. Jedan pojedinačni server je postao mnogo servera koji rade iza balansera opterećenja, upotreba sistema kontrole verzija je postala uobičajena.

Za svoj lični projekat imao sam posebnu konfiguraciju. I znao sam da mi je potrebna mogućnost da postavim lokaciju u produkciju, izvodeći samo jednu radnju: pisanje koda u granu master na GitHubu. Također sam znao da ne želim upravljati ogromnim Kubernetes klasterom, ili koristiti Docker Swarm tehnologiju, ili održavati serverski park sa podovima, agentima i svim vrstama drugih složenosti, kako bih pokrenuo svoju malu web aplikaciju. Da bih postigao cilj da što lakše olakšam rad, trebalo je da se upoznam sa CI/CD.

Ako imate mali projekat (u našem slučaju, Node.js projekat) i želite da naučite kako da automatizujete implementaciju ovog projekta, a da pritom budete sigurni da ono što je pohranjeno u spremištu tačno odgovara onome što radi u proizvodnji, mislim da možda će vas zanimati ovaj članak.

Preduslovi

Od čitaoca ovog članka se očekuje da ima osnovno znanje komandne linije i Bash skriptiranja. Osim toga, trebat će mu računi Travis C.I. и Docker čvorište.

Ciljevi

Neću reći da se ovaj članak bezuslovno može nazvati "vodičem za obuku". 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, obavljen u jednom automatiziranom prolazu.

Evo kako je izgledao moj radni tok.

Za kod gurnut u bilo koju granu spremišta osim master, izvode se sljedeće radnje:

• Počinje izgradnja projekta na Travis CI.
• Izvode se svi testovi jedinice, integracije i end-to-end.

Samo za kod koji završi master, radi se sljedeće:

• Sve gore navedeno, plus...
• Izrada Docker slike na osnovu trenutnog koda, postavki i okruženja.
• Hostovanje slike na Docker Hub-u.
• Povezivanje sa proizvodnim serverom.
• Prijenos slike iz Docker Hub-a na server.
• Zaustavite trenutni kontejner i pokrenite novi na osnovu nove slike.

Ako ne znate apsolutno ništa o Dockeru, slikama i kontejnerima, ne brinite. Reći ću ti sve o tome.

Šta je CI/CD?

Skraćenica CI / CD je skraćenica za "kontinuirana integracija / kontinuirana implementacija" - "kontinuirana integracija / kontinuirana implementacija".

▍Kontinuirana integracija

Kontinuirana integracija je proces kojim se programeri obavezuju na glavno spremište izvornog koda projekta (obično granu master). U isto vrijeme, kvalitet koda je osiguran automatiziranim testiranjem.

▍Neprekidna implementacija

Kontinuirana implementacija je česta automatska implementacija koda u proizvodnju. Drugi dio skraćenice CI/CD ponekad se otkriva kao "kontinuirana isporuka" ("kontinuirana isporuka"). Ovo je u osnovi isto što i "kontinuirana implementacija", ali "kontinuirana isporuka" podrazumijeva da promjene moraju biti ručno potvrđene prije početka procesa implementacije projekta.

Prvi koraci

Aplikacija na kojoj sam sve ovo savladao zove se Uzeti u obzir. Ovo je web projekat na kojem radim za vođenje bilješki. Prvo sam pokušao JAMStack-projekt, ili samo front-end aplikacija bez servera, kako bi se iskoristile prednosti standardnog hostinga i opcija implementacije projekta koje nudi netlify. Kako je složenost aplikacije rasla, morao sam da kreiram njen back-end, što je značilo da ću morati da formiram sopstvenu strategiju za automatizovanu integraciju i automatizovanu implementaciju projekta.

U mom slučaju, aplikacija je Express server koji radi u okruženju Node.js, koji opslužuje React aplikaciju na jednoj stranici i podržava siguran API na strani servera. Ova arhitektura prati strategiju koja se može naći u ovo vodič za autentifikaciju cijelog steka.

Konsultovao sam se sa prijatelju, koji je stručnjak za automatizaciju, i pitao ga šta trebam učiniti da sve funkcionira kako želim. Dao mi je ideju kako bi trebao izgledati automatizirani tok rada naveden u odjeljku Ciljevi ovog članka. Postavljanje ovakvih ciljeva značilo je da moram shvatiti kako koristiti Docker.

doker

Docker je alat koji, zahvaljujući tehnologiji kontejnerizacije, olakšava distribuciju aplikacija, kao i njihovo postavljanje i pokretanje u istom okruženju, čak i ako sama Docker platforma radi u različitim okruženjima. Prvo, morao sam se dočepati Docker alata komandne linije (CLI). Instrukcije Vodič za instalaciju za Docker nije baš jasan, ali iz njega možete naučiti da morate preuzeti Docker Desktop (za Mac ili Windows) da biste poduzeli prvi korak instalacije.

Docker Hub je otprilike isti kao GitHub za git spremišta ili registar npm za JavaScript pakete. Ovo je online spremište za Docker slike. Ovo je mjesto gdje se Docker Desktop povezuje.

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

• Ustanovite DockerDesktop.
• Registrujte se na Docker čvorište.

Nakon toga, možete provjeriti radi li Docker CLI tako što ćete pokrenuti sljedeću naredbu da provjerite verziju Dockera:

docker -v

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

docker login

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

▍Slike

Slika je vrsta nacrta koji sadrži upute za izgradnju kontejnera. Ovo je nepromjenjivi snimak sistema datoteka i postavki aplikacije. Programeri mogu lako dijeliti slike.

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

Ova komanda će ispisati tabelu sa sljedećim naslovom:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

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

▍Kontejneri

Kontejner 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 i u istom okruženju. Govorimo o tome da se instance iste slike lansiraju u različitim okruženjima.

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

▍Tags

Oznaka je indikacija određene verzije slike.

▍Brza referenca za Docker komande

Evo pregleda nekih najčešće korištenih Docker komandi.

tim

Kontekst

efekt

docker build

Slika

Izrada slike iz Dockerfile-a

docker tag

Slika

Označavanje slika

docker slike

Slika

Prikaz liste slika

docker run

Kontejner

Pokretanje kontejnera zasnovanog na slikama

docker push

Slika

Slanje slike u registar

docker-pull

Slika

Učitavanje slike iz registra

docker ps

Kontejner

Popis kontejnera

docker sistem prune

Slika/kontejner

Uklanjanje nekorištenih kontejnera i slika

▍Dockerfile

Znam kako pokrenuti proizvodnu aplikaciju lokalno. Imam webpack konfiguraciju za izradu gotove React aplikacije. Zatim, imam komandu koja pokreće server baziran 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, za eksperimente, bilo koja jednostavna Node aplikacija će poslužiti.

Da biste koristili kontejner, morat ćete dati upute Dockeru. To se radi putem datoteke pod nazivom Dockerfilenalazi se u korijenskom direktoriju projekta. Ovaj fajl, u početku, deluje prilično nerazumljivo.

Ali ono što sadrži samo opisuje, u posebnim naredbama, nešto poput postavljanja radnog okruženja. Evo nekih od tih naredbi:

• OD — Ova komanda pokreće datoteku. Određuje osnovnu sliku od koje je kontejner izgrađen.
• COPY - Kopiranje datoteka iz lokalnog izvora u kontejner.
• WORKDIR - Postavljanje radnog direktorija za sljedeće naredbe.
• RUN - Pokreni komande.
• EXPOSE — Podešavanje porta.
• ENTRYPOINT — Indikacija naredbe koju treba izvršiti.

Dockerfile može izgledati otprilike 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) dizajnirane da budu što je moguće kompaktnije. Kao rezultat toga, možda neće uključivati ​​neke od programa koje očekujete.

▍Izgradnja, označavanje i pokretanje kontejnera

Lokalna montaža i lansiranje kontejnera je, nakon što imamo Dockerfilezadaci su prilično jednostavni. Prije guranja slike u Docker Hub, potrebno je lokalno testirati.

▍Sastavljanje

Prvo morate prikupiti slika, navodeći ime i, opciono, oznaku (ako nije navedena oznaka, sistem će automatski dodijeliti oznaku slici latest).

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

Nakon što pokrenete ovu naredbu, 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. Nakon što je gradnja završena, možete pokrenuti naredbu docker images i pogledajte opis vaše nove slike.

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

▍Pokreni

Slika je kreirana. A to znači da na njegovoj osnovi možete pokrenuti kontejner. Pošto želim da mogu pristupiti aplikaciji koja radi u kontejneru na localhost:5000, i, na lijevoj strani para 5000:5000 u sljedećem skupu komandi 5000. Na desnoj strani je kontejnerski priključak.

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

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

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 localhost:5000 - možete vidjeti stranicu pokrenute aplikacije, koja izgleda potpuno isto kao stranica aplikacije koja radi u proizvodnom okruženju.

▍Dodjela oznaka i objavljivanje

Da bismo koristili jednu od kreiranih slika na proizvodnom serveru, moramo moći da preuzmemo ovu sliku sa Docker Hub-a. To znači da prvo trebate kreirati spremište za projekat na Docker Hubu. Nakon toga ćemo imati mjesto gdje možemo poslati sliku. Sliku je potrebno preimenovati tako da njeno ime počinje našim Docker Hub korisničkim imenom. Ovo bi trebalo biti praćeno imenom spremišta. Bilo koja oznaka može se staviti na kraj imena. Ispod je primjer imenovanja slika prema ovoj shemi.

Sada možete napraviti sliku s novim imenom koja joj je dodijeljena i pokrenuti naredbu docker push da ga gurnete u Docker Hub spremište.

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 prođe kako treba, slika će biti dostupna na Docker Hub-u i lako se može prenijeti na server ili podijeliti s drugim programerima.

Sljedeći koraci

Do sada smo potvrdili da aplikacija, u obliku Docker kontejnera, radi lokalno. Prebacili smo kontejner na Docker Hub. Sve to znači da smo već jako dobro napredovali ka našem cilju. Sada moramo da rešimo još dva pitanja:

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

U našem slučaju, kao CI/CD rješenje koristimo Travis C.I.. Kao server - DigitalOcean.

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 da radimo sa Travis CI, a ja već imam nešto postavljeno u ovom servisu. 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 želim da ulazim u detalje postavljanja Travis CI, jer je svaki projekat jedinstven i neće doneti mnogo koristi. Ali ja ću pokriti osnove da biste započeli ako odlučite koristiti Travis CI. Šta god da odaberete - Travis CI, CircleCI, Jenkins ili nešto drugo, slične metode konfiguracije će se primjenjivati ​​svuda.

Da biste započeli s Travis CI, idite na web stranica projekta i kreirajte nalog. Zatim integrirajte Travis CI sa svojim GitHub nalogom. Kada postavljate sistem, moraćete da navedete spremište koje želite da automatizujete i omogućite pristup njemu. (Koristim GitHub, ali sam siguran da se Travis CI može integrirati sa BitBucket, GitLab i drugim sličnim servisima).

Svaki put kada se pokrene Travis CI, pokreće se server koji izvršava naredbe navedene u konfiguracijskoj datoteci, uključujući postavljanje odgovarajućih grana spremišta.

▍Životni ciklus posla

Travis CI konfiguracijski fajl pozvan .travis.yml i pohranjen u korijenskom direktoriju projekta, podržava koncept događaja životni ciklus zadataka. Evo događaja, navedenih redoslijedom kojim se događaju:

• 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 konfiguracionoj datoteci ću postaviti lokalni Travis CI server. Odabrao sam Node 12 kao jezik i rekao sistemu da instalira zavisnosti potrebne za korištenje Dockera.

Sve navedeno u .travis.yml, će se izvršiti na svim zahtjevima za povlačenjem za sve grane spremišta, osim ako nije drugačije navedeno. Ovo je korisna funkcija jer znači da možemo testirati sav kod koji ide u spremište. Ovo vam omogućava da znate da li je kod spreman za pisanje u granu. masteri da li će to prekinuti proces izgradnje projekta. U ovoj globalnoj konfiguraciji, sve instaliram lokalno, pokrećem Webpack dev server u pozadini (ovo je karakteristika mog toka rada) i pokrećem testove.

Ako želite da vaše spremište prikazuje ikone pokrivenosti koda, ovdje možete pronaći brzi vodič o tome kako koristiti Jest, Travis CI i kombinezon za prikupljanje i prikazivanje ovih informacija.

Dakle, evo sadržaja 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 se završavaju radnje koje se izvode za sve grane spremišta i za zahtjeve za povlačenjem.

▍Razmještanje

Na osnovu pretpostavke da su svi automatizovani testovi uspešno završeni, možemo opciono primeniti kod na proizvodni server. Pošto želimo ovo samo za kod grane master, dajemo sistemu odgovarajuća uputstva u postavkama implementacije. Prije nego što pokušate upotrijebiti kod 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 radi dvije stvari:

• Izrada, označavanje i slanje slike u Docker Hub pomoću CI alata (u našem slučaju to je Travis CI).
• Učitavanje slike na server, zaustavljanje starog kontejnera i pokretanje novog (u našem slučaju server radi na platformi DigitalOcean).

Prvo, morate postaviti automatski proces za pravljenje, označavanje i guranje slike u Docker Hub. Sve je to vrlo slično onome što smo već radili ručno, osim što nam je ovdje potrebna strategija za dodjeljivanje jedinstvenih oznaka slikama i automatizaciju prijave. Imao sam poteškoća s nekim detaljima skripte za implementaciju, kao što su strategija označavanja, prijavljivanje, kodiranje SSH ključeva, uspostavljanje SSH veze. Ali, srećom, moj dečko je jako dobar sa bash-om, kao i sa mnogim drugim stvarima. Pomogao mi je da napišem ovaj scenario.

Dakle, prvi dio skripte je slanje slike u Docker Hub. To je prilično jednostavno. Šema označavanja koju sam koristio uključuje kombinovanje git heša i git oznake ako postoji. Ovo osigurava da je oznaka jedinstvena i olakšava identifikaciju sklopa na kojem se zasniva. DOCKER_USERNAME и DOCKER_PASSWORD su korisnički definirane varijable okruženja koje se mogu postaviti pomoću Travis CI sučelja. Travis CI će automatski 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 tome koji host koristite i kako je veza s njim organizirana. U mom slučaju, pošto koristim Digital Ocean, komande se koriste za povezivanje sa serverom doctl. Kada radite sa Awsom, koristit će se uslužni program aws, i tako dalje.

Postavljanje servera nije bilo posebno teško. Dakle, postavio sam kapljicu na osnovu osnovne slike. Treba napomenuti da sistem koji sam izabrao zahtijeva jednokratnu ručnu instalaciju Dockera i jednokratno ručno pokretanje Dockera. Koristio sam Ubuntu 18.04 da instaliram Docker, tako da ako i vi koristite Ubuntu možete jednostavno pratiti ovo jednostavno vođenje.

Ovdje ne govorim o konkretnim naredbama za uslugu, jer se ovaj aspekt može jako razlikovati u različitim slučajevima. Daću samo opšti plan akcije koje treba izvršiti nakon povezivanja preko SSH-a na server na kojem će projekat biti raspoređen:

• Morate pronaći kontejner koji je trenutno pokrenut i zaustaviti ga.
• Zatim morate pokrenuti novi kontejner u pozadini.
• Morat ćete postaviti lokalni port servera na 80 - ovo će vam omogućiti da uđete na stranicu na adresu obrasca example.com, bez navođenja porta, umjesto da koristite adresu kao što je example.com:5000.
• I na kraju, morate ukloniti sve stare kontejnere 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 paziti

Moguće je da kada se povežete sa serverom preko SSH-a sa Travis CI-ja, vidite upozorenje koje vam neće dozvoliti da nastavite sa instalacijom, jer će sistem čekati na 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 string ključ može kodirati u base64 kako bi se pohranio u obliku u kojem se može lako i pouzdano raditi. U fazi instalacije možete dekodirati javni ključ i zapisati ga u datoteku known_hosts kako biste se riješili gornje greške.

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

U praksi, ova naredba može 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

A evo šta daje - base64 kodirani niz:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Evo gore pomenute naredbe

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

Isti pristup se može koristiti sa privatnim ključem prilikom uspostavljanja veze, jer će vam možda trebati privatni ključ za pristup serveru. Kada radite s ključem, trebate samo osigurati da je sigurno pohranjen u varijablu Travis CI 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 jednu liniju, na primjer sa doctl. Ovo može zahtijevati dodatni napor.

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

TLS/SSL i balansiranje opterećenja

Nakon što sam uradio sve gore navedeno, poslednji problem koji sam imao bio je taj što server nije imao SSL. S obzirom da koristim Node.js server, radi prisile na posao obrnuti proxy Nginx i Let's Encrypt, potrebno je puno petljati.

Zaista nisam želio sve ove SSL postavke raditi ručno, pa sam samo napravio balansator opterećenja i snimio informacije o tome u DNS. U slučaju DigitalOceana, na primjer, kreiranje samopotpisanog certifikata koji se automatski obnavlja na balanseru opterećenja je jednostavna, besplatna i brza procedura. Ovaj pristup ima dodatnu prednost jer olakšava postavljanje SSL-a na više servera koji rade iza balansera opterećenja ako je potrebno. To omogućava samim serverima da uopće ne "razmišljaju" o SSL-u, ali da istovremeno koriste, kao i obično, port 80. Dakle, konfiguriranje SSL-a na balanseru opterećenja je mnogo lakše i praktičnije od alternativnih metoda konfiguracije SSL-a.

Sada možete zatvoriti sve portove na serveru koji prihvataju dolazne veze - osim porta 80, koji se koristi za komunikaciju sa balansatorom opterećenja i portom 22 za SSH. Kao rezultat toga, pokušaj da se direktno kontaktira server na bilo kom drugom portu osim ova dva neće uspjeti.

Ishodi

Nakon što sam uradio sve o čemu sam govorio u ovom članku, više me nisu plašili ni Docker platforma ni koncept automatizovanih CI/CD lanaca. Uspio sam postaviti kontinuirani lanac integracije, tokom kojeg se kod testira prije nego što krene u proizvodnju i kod se automatski postavlja na server. Sve je ovo za mene još uvijek relativno novo i siguran sam da postoje načini da poboljšam svoj automatizirani radni tok i učinim ga efikasnijim. Pa ako imate neku ideju o ovome - dajte ja znam. Nadam se da vam je ovaj članak pomogao u vašim nastojanjima. Želim vjerovati da ste čitajući je naučili onoliko koliko sam ja naučio dok sam se bavio svime o čemu sam u njoj pričao.

PS U našem marketplace postoji slika doker, koji se instalira jednim klikom. Možete provjeriti kako kontejneri rade VPS. Svim novim kupcima je omogućeno 3 dana testiranja besplatno.

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

izvor: www.habr.com