Crearea unui lanț CI/CD și automatizarea muncii cu Docker

Primele mele site-uri le-am scris la sfârșitul anilor 90. Pe atunci era foarte ușor să le puneți în stare de funcționare. A existat un server Apache pe unele găzduire partajată, te puteai conecta la acest server prin FTP scriind ceva de genul ftp://ftp.example.com. Apoi a trebuit să vă introduceți numele și parola și să încărcați fișierele pe server. Au fost vremuri diferite, totul era mai simplu atunci decât acum.

În cele două decenii de atunci, totul s-a schimbat foarte mult. Site-urile web au devenit mai complexe; ele trebuie asamblate înainte de a fi lansate în producție. Un singur server a devenit mai multe servere care rulau în spatele echilibratorilor de încărcare, iar utilizarea sistemelor de control al versiunilor a devenit obișnuită.

Pentru proiectul meu personal am avut o configurație specială. Și știam că aveam nevoie de capacitatea de a implementa site-ul în producție efectuând o singură acțiune: scrierea codului într-o sucursală master pe GitHub. În plus, știam că, pentru a asigura funcționarea micii mele aplicații web, nu am vrut să gestionez un cluster Kubernetes uriaș, sau să folosesc tehnologia Docker Swarm sau să mențin o flotă de servere cu pod-uri, agenți și tot felul de altele. complexități. Pentru a atinge obiectivul de a face munca cât mai ușoară posibil, trebuia să mă familiarizez cu CI/CD.

Dacă aveți un proiect mic (în acest caz, un proiect Node.js) și doriți să știți cum să automatizați implementarea acestui proiect, asigurându-vă în același timp că ceea ce este stocat în depozit se potrivește exact cu ceea ce funcționează în producție, atunci eu cred că ai putea fi interesat de acest articol.

Condiții prealabile

Se așteaptă ca cititorul acestui articol să aibă o înțelegere de bază a liniei de comandă și să scrie scripturi Bash. În plus, va avea nevoie de conturi Travis C.I. и Hub Docker.

goluri

Nu voi spune că acest articol poate fi numit necondiționat „tutorial”. Acesta este mai mult un document în care vorbesc despre ceea ce am învățat și descriu procesul care mi se potrivește pentru testarea și implementarea codului în producție, realizat într-o singură trecere automată.

Acesta este ceea ce a ajuns să fie fluxul meu de lucru.

Pentru codul postat în orice ramură a depozitului, cu excepția master, se efectuează următoarele acțiuni:

• Începe proiectul construit pe Travis CI.
• Toate testele unitare, de integrare și end-to-end sunt efectuate.

Doar pentru codul în care se încadrează master, se efectuează următoarele:

• Tot ce s-a menționat mai sus, plus...
• Construirea unei imagini Docker pe baza codului, setărilor și mediului actual.
• Implementarea imaginii în Docker Hub.
• Conexiune la serverul de producție.
• Încărcarea unei imagini din Docker Hub pe server.
• Oprirea containerului curent și pornirea unuia nou bazat pe noua imagine.

Dacă nu știți absolut nimic despre Docker, imagini și containere, nu vă faceți griji. Îți voi spune totul despre asta.

Ce este CI/CD?

Abrevierea CI/CD înseamnă „integrare continuă/implementare continuă”.

▍Integrare continuă

Integrarea continuă este un proces în care dezvoltatorii se angajează în depozitul principal de cod sursă al proiectului (de obicei, o ramură master). În același timp, calitatea codului este asigurată prin testare automată.

▍Implementare continuă

Implementarea continuă este implementarea frecventă și automată a codului în producție. A doua parte a acronimului CI/CD este uneori scrisă ca „livrare continuă”. Acest lucru este practic același cu „implementarea continuă”, dar „livrarea continuă” implică necesitatea de a confirma manual modificările înainte de a începe procesul de implementare a proiectului.

Noțiuni de bază

Aplicația pe care am folosit-o pentru a învăța toate acestea se numește Ia-ti notite. Acesta este un proiect web la care lucrez, conceput pentru a lua notițe. La început am încercat să fac JAMStack-proiect sau doar o aplicație front-end fără server, pentru a profita de capacitățile standard de găzduire și de implementare a proiectelor pe care le oferă Netlify. Pe măsură ce complexitatea aplicației creștea, trebuia să-i creez partea de server, ceea ce însemna că trebuia să-mi formulez propria strategie pentru integrarea automată și implementarea automată a proiectului.

În cazul meu, aplicația este un server Express care rulează în mediul Node.js, deservește o aplicație React cu o singură pagină și acceptă un API securizat pe server. Această arhitectură urmează strategia care poate fi găsită în acest Ghid complet de autentificare.

m-am consultat cu prietene, care este un expert în automatizare, și l-a întrebat ce trebuie să fac pentru ca totul să funcționeze așa cum mi-am dorit. Mi-a dat ideea cum ar trebui să arate un flux de lucru automat, prezentată în secțiunea Obiective a acestui articol. Având aceste obiective însemna că trebuia să-mi dau seama cum să folosesc Docker.

Docher

Docker este un instrument care, datorită tehnologiei de containerizare, permite aplicațiilor să fie ușor distribuite, implementate și rulate în același mediu, chiar dacă platforma Docker în sine rulează în medii diferite. În primul rând, trebuia să pun mâna pe instrumentele de linie de comandă Docker (CLI). instrucție Ghidul de instalare Docker nu poate fi numit foarte clar și ușor de înțeles, dar din acesta puteți afla că pentru a face primul pas de instalare, trebuie să descărcați Docker Desktop (pentru Mac sau Windows).

Docker Hub este aproximativ același lucru cu GitHub pentru depozitele git sau registry NPM pentru pachetele JavaScript. Acesta este un depozit online pentru imaginile Docker. La asta se conectează Docker Desktop.

Deci, pentru a începe cu Docker, trebuie să faceți două lucruri:

• Set DockerDesktop.
• Înregistrează-te pentru Hub Docker.

După aceasta, puteți verifica dacă Docker CLI funcționează rulând următoarea comandă pentru a verifica versiunea Docker:

docker -v

Apoi, conectați-vă la Docker Hub introducând numele de utilizator și parola când vi se solicită:

docker login

Pentru a utiliza Docker, trebuie să înțelegeți conceptele de imagini și containere.

▍Imagini

O imagine este ceva ca un plan care conține instrucțiuni pentru asamblarea containerului. Acesta este un instantaneu imuabil al sistemului de fișiere și setărilor aplicației. Dezvoltatorii pot partaja cu ușurință imagini.

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

Această comandă va scoate un tabel cu următorul antet:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

În continuare ne vom uita la câteva exemple de comenzi în același format - mai întâi există o comandă cu un comentariu, apoi un exemplu despre ceea ce poate scoate.

▍Containere

Un container este un pachet executabil care conține tot ce este necesar pentru a rula o aplicație. O aplicație cu această abordare va funcționa întotdeauna la fel, indiferent de infrastructură: într-un mediu izolat și în același mediu. Ideea este că instanțele aceleiași imagini sunt lansate în medii diferite.

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

▍Etichete

O etichetă este o indicație a unei versiuni specifice a unei imagini.

▍O referire rapidă la comenzile Docker

Iată o prezentare generală a unor comenzi Docker utilizate în mod obișnuit.

Echipă

context

efect

docker build

imagine

Construirea unei imagini dintr-un fișier Docker

eticheta docker

imagine

Etichetarea imaginilor

portocale imagini

imagine

Listarea imaginilor

docker alerga

Recipient

Rularea unui container pe baza unei imagini

docker push

imagine

Încărcarea unei imagini în registru

docker pull

imagine

Se încarcă o imagine din registru

docker ps

Recipient

Listarea containerelor

taierea sistemului docker

Imagine/Container

Îndepărtarea containerelor și imaginilor neutilizate

▍Dockerfile

Știu cum să rulez o aplicație de producție local. Am o configurație Webpack concepută pentru a construi o aplicație React gata făcută. În continuare, am o comandă care pornește un server bazat pe Node.js pe port 5000. Arata cam asa:

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

De menționat că nu am un exemplu de aplicație pentru acest material. Dar aici, pentru experimente, orice aplicație simplă Node va funcționa.

Pentru a utiliza containerul, va trebui să îi oferiți instrucțiuni lui Docker. Acest lucru se face printr-un fișier numit Dockerfile, situat în directorul rădăcină al proiectului. Acest fișier, la început, pare destul de de neînțeles.

Dar ceea ce conține doar descrie, cu comenzi speciale, ceva asemănător cu configurarea unui mediu de lucru. Iată câteva dintre aceste comenzi:

• DIN — Această comandă pornește un fișier. Specifică imaginea de bază pe care este construit containerul.
• COPIE — Copierea fișierelor dintr-o sursă locală într-un container.
• WORKDIR — Setarea directorului de lucru pentru următoarele comenzi.
• ALERGA - Rulați comenzi.
• EXPUNE — Setări porturi.
• PUNCT DE INTRARE — Indicarea comenzii de executat.

Dockerfile ar putea arata cam asa:

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

În funcție de imaginea de bază pe care o alegeți, poate fi necesar să instalați dependențe suplimentare. Cert este că unele imagini de bază (cum ar fi Node Alpine Linux) sunt create cu scopul de a le face cât mai compacte. Ca urmare, este posibil să nu aibă unele dintre programele pe care le așteptați.

▍Construirea, etichetarea și rularea containerului

Asamblarea locală și lansarea containerului este după ce avem Dockerfile, sarcinile sunt destul de simple. Înainte de a împinge imaginea în Docker Hub, trebuie să o testați local.

▍Asamblare

Mai întâi trebuie să colectezi imagine, specificând un nume și, opțional, o etichetă (dacă nu este specificată o etichetă, sistemul va atribui automat o etichetă imaginii latest).

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

După ce rulați această comandă, puteți urmări cum Docker construiește imaginea.

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

Construirea poate dura câteva minute - totul depinde de câte dependențe aveți. Odată ce construirea este completă, puteți rula comanda docker images și uită-te la descrierea noii imagini.

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

▍ Lansați

Imaginea a fost creată. Aceasta înseamnă că puteți rula un container pe baza acestuia. Pentru că vreau să pot accesa aplicația care rulează în container la localhost:5000, eu, pe partea stângă a perechii 5000:5000 în următoarea comandă instalată 5000. În partea dreaptă este portul containerului.

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

Acum că containerul este creat și rulează, puteți utiliza comanda docker ps pentru a căuta informații despre acest container (sau puteți utiliza comanda docker ps -a, care afișează informații despre toate containerele, nu doar despre cele care rulează).

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

Daca te duci acum la adresa localhost:5000 — puteți vedea o pagină a unei aplicații care rulează care arată exact la fel ca pagina unei aplicații care rulează într-un mediu de producție.

▍Etichetarea și publicarea

Pentru a folosi una dintre imaginile create pe serverul de producție, trebuie să putem descărca această imagine din Docker Hub. Aceasta înseamnă că mai întâi trebuie să creați un depozit pentru proiect pe Docker Hub. După aceasta, vom avea un loc unde putem trimite imaginea. Imaginea trebuie redenumită astfel încât numele ei să înceapă cu numele de utilizator Docker Hub. Acesta ar trebui să fie urmat de numele depozitului. Orice etichetă poate fi plasată la sfârșitul numelui. Mai jos este un exemplu de denumire a imaginilor folosind această schemă.

Acum puteți construi imaginea cu un nume nou și puteți rula comanda docker push pentru a-l împinge în depozitul 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

Dacă totul merge bine, imaginea va fi disponibilă pe Docker Hub și poate fi încărcată cu ușurință pe server sau transferată altor dezvoltatori.

Pașii următori

Până acum am verificat că aplicația, sub forma unui container Docker, rulează local. Am încărcat containerul în Docker Hub. Toate acestea înseamnă că am făcut deja progrese foarte bune către obiectivul nostru. Acum trebuie să rezolvăm încă două întrebări:

• Configurarea unui instrument CI pentru testarea și implementarea codului.
• Configurarea serverului de producție astfel încât să poată descărca și rula codul nostru.

În cazul nostru, folosim Travis C.I.. Ca server - DitigalOcean.

Trebuie menționat că aici puteți utiliza o altă combinație de servicii. De exemplu, în loc de Travis CI, puteți utiliza CircleCI sau Github Actions. Și în loc de DigitalOcean - AWS sau Linode.

Am decis să lucrăm cu Travis CI și am deja ceva configurat în acest serviciu. Prin urmare, acum voi vorbi pe scurt despre cum să-l pregătesc pentru muncă.

Travis C.I.

Travis CI este un instrument pentru testarea și implementarea codului. Nu aș dori să intru în complexitatea înființării Travis CI, deoarece fiecare proiect este unic și acest lucru nu va aduce prea multe beneficii. Dar voi acoperi elementele de bază pentru a începe dacă decideți să utilizați Travis CI. Indiferent dacă alegeți Travis CI, CircleCI, Jenkins sau altceva, metode de configurare similare vor fi folosite peste tot.

Pentru a începe cu Travis CI, accesați site-ul proiectului și creează un cont. Apoi, integrează Travis CI cu contul tău GitHub. Când configurați sistemul, va trebui să specificați depozitul cu care doriți să automatizați munca și să activați accesul la acesta. (Folosesc GitHub, dar sunt sigur că Travis CI se poate integra cu BitBucket, GitLab și alte servicii similare).

De fiecare dată când Travis CI este pornit, serverul este lansat, executând comenzile specificate în fișierul de configurare, inclusiv implementarea ramurilor de depozit corespunzătoare.

▍Ciclul de viață al locului de muncă

Fișierul de configurare Travis CI a fost apelat .travis.yml și stocat în directorul rădăcină al proiectului, acceptă conceptul de evenimente ciclu de viață sarcini. Aceste evenimente sunt enumerate în ordinea în care au loc:

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

▍Testări

În fișierul de configurare voi configura serverul local Travis CI. Am selectat Nodul 12 ca limbă și am spus sistemului să instaleze dependențele necesare pentru a utiliza Docker.

Tot ce este enumerat în .travis.yml, va fi executat atunci când toate cererile de extragere sunt făcute către toate ramurile depozitului, dacă nu se specifică altfel. Aceasta este o caracteristică utilă, deoarece înseamnă că putem testa tot codul care vine în depozit. Acest lucru vă permite să știți dacă codul este gata pentru a fi scris în ramură. master, și dacă va întrerupe procesul de construire a proiectului. În această configurație globală, instalez totul local, rulez serverul de dezvoltare Webpack în fundal (aceasta este o caracteristică a fluxului meu de lucru) și rulez teste.

Dacă doriți ca depozitul dvs. să afișeze pictograme de acoperire a testului, aici Puteți găsi instrucțiuni scurte despre utilizarea Jest, Travis CI și combinezoane pentru a colecta și afișa aceste informații.

Deci, aici este conținutul fișierului .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

Aici se termină acțiunile care sunt efectuate pentru toate ramurile depozitului și pentru cererile de extragere.

▍Implementare

Pe baza presupunerii că toate testele automate au fost finalizate cu succes, putem, ceea ce este opțional, să implementăm codul pe serverul de producție. Deoarece vrem să facem acest lucru numai pentru codul din ramură master, oferim sistemului instrucțiuni adecvate în setările de implementare. Înainte de a încerca să utilizați codul pe care îl vom analiza în continuare în proiectul dvs., aș dori să vă avertizez că trebuie să aveți un script propriu numit pentru implementare.

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

Scriptul de implementare rezolvă două probleme:

• Creați, etichetați și trimiteți imaginea către Docker Hub folosind un instrument CI (în cazul nostru, Travis CI).
• Încărcarea imaginii pe server, oprirea vechiului container și pornirea unuia nou (în cazul nostru, serverul rulează pe platforma DigitalOcean).

Mai întâi, trebuie să configurați un proces automat pentru construirea, etichetarea și împingerea imaginii către Docker Hub. Toate acestea sunt foarte asemănătoare cu ceea ce am făcut deja manual, cu excepția faptului că avem nevoie de o strategie pentru atribuirea etichetelor unice imaginilor și automatizarea autentificărilor. Am avut dificultăți cu unele detalii ale scriptului de implementare, cum ar fi strategia de etichetare, autentificare, codificarea cheii SSH, stabilirea conexiunii SSH. Dar, din fericire, iubitul meu este foarte bun cu bash, ca și cu multe alte lucruri. M-a ajutat să scriu acest scenariu.

Deci, prima parte a scriptului este încărcarea imaginii în Docker Hub. Acest lucru este destul de ușor de făcut. Schema de etichetare pe care am folosit-o implică combinarea unui hash git și a unei etichete git, dacă există. Acest lucru asigură că eticheta este unică și facilitează identificarea ansamblului pe care se bazează. DOCKER_USERNAME и DOCKER_PASSWORD sunt variabile de mediu ale utilizatorului care pot fi setate utilizând interfața Travis CI. Travis CI va procesa automat datele sensibile, astfel încât acestea să nu cadă în mâini greșite.

Iată prima parte a scenariului 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}

Care va fi a doua parte a scriptului depinde în întregime de ce gazdă utilizați și de modul în care este organizată conexiunea la aceasta. În cazul meu, deoarece folosesc Digital Ocean, folosesc comenzile pentru a mă conecta la server doctl. Când lucrați cu AWS, utilitarul va fi utilizat aws, si asa mai departe.

Configurarea serverului nu a fost deosebit de dificilă. Deci, am configurat o picătură pe baza imaginii de bază. Trebuie remarcat faptul că sistemul pe care l-am ales necesită o instalare manuală unică a Docker și o lansare manuală unică a Docker. Am folosit Ubuntu 18.04 pentru a instala Docker, așa că dacă utilizați și Ubuntu pentru a face același lucru, puteți doar să urmați acest ghid simplu.

Nu vorbesc aici despre comenzi specifice pentru serviciu, deoarece acest aspect poate varia foarte mult în diferite cazuri. Voi oferi doar un plan general de acțiune care trebuie efectuat după conectarea prin SSH la serverul pe care va fi implementat proiectul:

• Trebuie să găsim containerul care rulează în prezent și să-l oprim.
• Apoi trebuie să lansați un nou container în fundal.
• Va trebui să setați portul local al serverului la 80 - acest lucru vă va permite să intrați pe site la o adresă ca example.com, fără a specifica portul, în loc să folosiți o adresă ca example.com:5000.
• În cele din urmă, trebuie să ștergeți toate containerele și imaginile vechi.

Iată continuarea scenariului.

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

Câteva lucruri la care să fii atent

Este posibil ca atunci când vă conectați la server prin SSH de la Travis CI, să vedeți un avertisment care vă va împiedica să continuați cu instalarea deoarece sistemul va aștepta răspunsul utilizatorului.

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

Am învățat că o cheie șir poate fi codificată în base64 pentru a o salva într-o formă în care să poată fi lucrată convenabil și fiabil. În etapa de instalare, puteți decoda cheia publică și o puteți scrie într-un fișier known_hosts pentru a scăpa de eroarea de mai sus.

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

În practică, această comandă ar putea arăta astfel:

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 iată ce produce - un șir codificat în bază64:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Iată comanda menționată mai sus

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

Aceeași abordare poate fi folosită cu o cheie privată atunci când stabiliți o conexiune, deoarece este posibil să aveți nevoie de o cheie privată pentru a accesa serverul. Când lucrați cu cheia, trebuie doar să vă asigurați că aceasta este stocată în siguranță într-o variabilă de mediu Travis CI și că nu este afișată nicăieri.

Un alt lucru de reținut este că poate fi necesar să rulați întregul script de implementare ca o singură linie, de exemplu - cu doctl. Acest lucru poate necesita un efort suplimentar.

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

TLS/SSL și echilibrarea sarcinii

După ce am făcut tot ce s-a menționat mai sus, ultima problemă pe care am întâlnit-o a fost că serverul nu avea SSL. Din moment ce folosesc un server Node.js, pentru a forța работать proxy invers Nginx și Let's Encrypt, trebuie să schimbați mult.

Chiar nu am vrut să fac manual toată această configurație SSL, așa că am creat doar un echilibrator de încărcare și i-am înregistrat detaliile în DNS. În cazul DigitalOcean, de exemplu, crearea unui certificat de reînnoire automată autosemnată pe echilibrator de încărcare este o procedură simplă, gratuită și rapidă. Această abordare are avantajul suplimentar că face foarte ușoară configurarea SSL pe mai multe servere care rulează în spatele unui echilibrator de încărcare, dacă este necesar. Acest lucru permite serverelor în sine să nu „se gândească” deloc la SSL, dar în același timp să folosească portul ca de obicei 80. Deci, configurarea SSL pe un echilibrator de încărcare este mult mai ușoară și mai convenabilă decât metodele alternative de configurare SSL.

Acum puteți închide toate porturile de pe server care acceptă conexiuni de intrare - cu excepția portului 80, folosit pentru a comunica cu echilibratorul de încărcare și cu portul 22 pentru SSH. Ca urmare, o încercare de a accesa direct serverul pe orice alte porturi decât cele două va eșua.

Rezultatele

După ce am făcut tot ce am vorbit în acest material, nici platforma Docker și nici conceptele de lanțuri automate CI/CD nu m-au mai speriat. Am reușit să configurez un lanț de integrare continuă, în timpul căruia codul este testat înainte de a intra în producție și codul este implementat automat pe server. Toate acestea sunt încă relativ noi pentru mine și sunt sigur că există modalități de a-mi îmbunătăți fluxul de lucru automat și de a-l face mai eficient. Deci, dacă aveți idei despre această chestiune, vă rog să-mi spuneți. mă stiu. Sper că acest articol te-a ajutat în demersurile tale. Vreau să cred că, după ce l-ai citit, ai învățat la fel de mult pe cât am învățat și eu, în timp ce descoperi tot ce am vorbit în ea.

PS În nostru piata de desfacere exista o imagine Docher, care poate fi instalat cu un singur clic. Puteți verifica funcționarea containerelor la VPS. Toți clienții noi li se oferă 3 zile de testare gratuit.

Dragi cititori! Utilizați tehnologii CI/CD în proiectele dvs.?

Sursa: www.habr.com