Opprette en CI/CD-kjede og automatisere arbeid med Docker

Jeg skrev mine første nettsider på slutten av 90-tallet. Den gang var det veldig enkelt å sette dem i stand. Det var en Apache-server på en delt hosting, du kan logge på denne serveren via FTP ved å skrive noe sånt som ftp://ftp.example.com. Deretter måtte du skrive inn navn og passord og laste opp filene til serveren. Det var andre tider, alt var enklere da enn nå.

I løpet av de to tiårene siden den gang har alt endret seg mye. Nettsteder har blitt mer komplekse, de må settes sammen før de slippes ut i produksjon. En enkelt server ble til mange servere som kjørte bak lastbalansere, og bruken av versjonskontrollsystemer ble vanlig.

For mitt personlige prosjekt hadde jeg en spesiell konfigurasjon. Og jeg visste at jeg trengte muligheten til å distribuere nettstedet i produksjon ved å utføre bare én handling: å skrive kode til en gren master på GitHub. I tillegg visste jeg at for å sikre driften av min lille nettapplikasjon, ønsket jeg ikke å administrere en enorm Kubernetes-klynge, eller bruke Docker Swarm-teknologi, eller vedlikeholde en flåte av servere med pods, agenter og alt mulig annet kompleksiteter. For å nå målet om å gjøre arbeidet så enkelt som mulig, trengte jeg å bli kjent med CI/CD.

Hvis du har et lite prosjekt (i dette tilfellet et Node.js-prosjekt) og du vil vite hvordan du automatiserer distribusjonen av dette prosjektet, samtidig som du sikrer at det som er lagret i depotet stemmer nøyaktig med det som fungerer i produksjonen, så tror du kan være interessert i denne artikkelen.

Forutsetninger

Leseren av denne artikkelen forventes å ha en grunnleggende forståelse av kommandolinjen og skrive Bash-skript. I tillegg vil han trenge kontoer Travis C.I. и Docker hub.

mål

Jeg vil ikke si at denne artikkelen ubetinget kan kalles en "opplæring". Dette er mer et dokument der jeg snakker om det jeg har lært og beskriver prosessen som passer meg for å teste og distribuere kode til produksjon, utført i ett automatisert pass.

Dette er hva arbeidsflyten min endte opp med å bli.

For kode som er postet til en hvilken som helst depotgren unntatt master, utføres følgende handlinger:

• Prosjektet bygget på Travis CI starter.
• Alle enhets-, integrasjons- og ende-til-ende-tester utføres.

Bare for kode som faller inn master, utføres følgende:

• Alt nevnt ovenfor, pluss...
• Bygge et Docker-bilde basert på gjeldende kode, innstillinger og miljø.
• Distribuerer bildet til Docker Hub.
• Tilkobling til produksjonsserveren.
• Laster opp et bilde fra Docker Hub til serveren.
• Stoppe den gjeldende beholderen og starte en ny basert på det nye bildet.

Hvis du ikke vet absolutt ingenting om Docker, bilder og containere, ikke bekymre deg. Jeg skal fortelle deg alt om det.

Hva er CI/CD?

Forkortelsen CI/CD står for "kontinuerlig integrasjon/kontinuerlig distribusjon."

▍Kontinuerlig integrasjon

Kontinuerlig integrasjon er en prosess der utviklere forplikter seg til prosjektets hovedkildekodelager (vanligvis en gren master). Samtidig sikres kvaliteten på koden gjennom automatisert testing.

▍Kontinuerlig distribusjon

Kontinuerlig distribusjon er hyppig, automatisert distribusjon av kode i produksjon. Den andre delen av CI/CD-akronymet er noen ganger stavet ut som "kontinuerlig levering." Dette er i utgangspunktet det samme som "kontinuerlig distribusjon", men "kontinuerlig levering" innebærer behovet for å bekrefte endringer manuelt før du starter prosjektdistribusjonsprosessen.

Komme i gang

Appen jeg brukte for å lære alt dette heter Ta notat. Dette er et nettprosjekt jeg jobber med, designet for å ta notater. Først prøvde jeg å gjøre JAMStack-prosjekt, eller bare en front-end-applikasjon uten server, for å dra nytte av standard hosting- og prosjektdistribusjonsfunksjoner som den tilbyr Netlify. Etter hvert som kompleksiteten til applikasjonen vokste, trengte jeg å lage serverdelen, noe som betydde at jeg måtte formulere min egen strategi for automatisert integrasjon og automatisert distribusjon av prosjektet.

I mitt tilfelle er applikasjonen en Express-server som kjører i Node.js-miljøet, som betjener en enkeltsides React-applikasjon og støtter en sikker server-side API. Denne arkitekturen følger strategien som finnes i dette Full stack autentiseringsguide.

jeg rådførte meg med venn, som er en automasjonsekspert, og spurte ham hva jeg måtte gjøre for å få det til å fungere slik jeg ønsket. Han ga meg ideen om hvordan en automatisert arbeidsflyt skal se ut, skissert i Mål-delen av denne artikkelen. Å ha disse målene betydde at jeg måtte finne ut hvordan jeg skulle bruke Docker.

Docker

Docker er et verktøy som takket være containeriseringsteknologi gjør at applikasjoner enkelt kan distribueres, distribueres og kjøres i samme miljø, selv om selve Docker-plattformen kjører i forskjellige miljøer. Først trengte jeg å få tak i Docker kommandolinjeverktøy (CLI). instruksjon Installasjonsveiledningen for Docker kan ikke kalles veldig tydelig og forståelig, men fra den kan du lære at for å ta det første installasjonstrinnet, må du laste ned Docker Desktop (for Mac eller Windows).

Docker Hub er omtrent det samme som GitHub for git-repositories eller register NPM for JavaScript-pakker. Dette er et online depot for Docker-bilder. Dette er hva Docker Desktop kobler til.

Så for å komme i gang med Docker, må du gjøre to ting:

• Satt DockerDesktop.
• Registrer for Docker hub.

Etter dette kan du sjekke om Docker CLI fungerer ved å kjøre følgende kommando for å sjekke Docker-versjonen:

docker -v

Logg deretter på Docker Hub ved å skrive inn brukernavnet og passordet ditt når du blir spurt:

docker login

For å bruke Docker må du forstå begrepene bilder og beholdere.

▍Bilder

Et bilde er noe som en blåkopi som inneholder instruksjoner for montering av beholderen. Dette er et uforanderlig øyeblikksbilde av programmets filsystem og innstillinger. Utviklere kan enkelt dele bilder.

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

Denne kommandoen vil sende ut en tabell med følgende overskrift:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

Deretter skal vi se på noen eksempler på kommandoer i samme format - først er det en kommando med en kommentar, og deretter et eksempel på hva den kan sende ut.

▍Beholdere

En container er en kjørbar pakke som inneholder alt som trengs for å kjøre en applikasjon. En applikasjon med denne tilnærmingen vil alltid fungere likt, uavhengig av infrastrukturen: i et isolert miljø og i samme miljø. Poenget er at forekomster av det samme bildet lanseres i forskjellige miljøer.

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

▍Tagger

En tag er en indikasjon på en spesifikk versjon av et bilde.

▍En rask referanse til Docker-kommandoer

Her er en oversikt over noen vanlige Docker-kommandoer.

Lag

Kontekst

effekt

dockerbygg

bilde

Bygge et bilde fra en Dockerfile

docker tag

bilde

Bildemerking

docker bilder

bilde

Oppføringsbilder

docker kjøre

container

Kjøre en beholder basert på et bilde

docker push

bilde

Laster opp et bilde til registeret

docker pull

bilde

Laster et bilde fra registeret

docker ps

container

Oppføring av containere

docker system sviske

Bilde/beholder

Fjerning av ubrukte beholdere og bilder

▍Dockerfil

Jeg vet hvordan jeg kjører en produksjonsapplikasjon lokalt. Jeg har en Webpack-konfigurasjon designet for å bygge en ferdig React-applikasjon. Deretter har jeg en kommando som starter en Node.js-basert server på porten 5000. Det ser slik ut:

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

Det skal bemerkes at jeg ikke har en eksempelapplikasjon for dette materialet. Men her, for eksperimenter, vil enhver enkel Node-applikasjon gjøre det.

For å bruke beholderen, må du gi instruksjoner til Docker. Dette gjøres gjennom en fil som heter Dockerfile, som ligger i rotkatalogen til prosjektet. Denne filen virker til å begynne med ganske uforståelig.

Men det den inneholder beskriver bare, med spesielle kommandoer, noe som ligner på å sette opp et arbeidsmiljø. Her er noen av disse kommandoene:

• FRA — Denne kommandoen starter en fil. Den spesifiserer basisbildet som beholderen er bygget på.
• KOPI — Kopiering av filer fra en lokal kilde til en beholder.
• WORKDIR — Stille inn arbeidskatalogen for følgende kommandoer.
• LØPE - Kjør kommandoer.
• AVDEKKE — Portinnstillinger.
• INNGANGSPUNKT — Indikasjon på kommandoen som skal utføres.

Dockerfile kan se noe slikt ut:

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

Avhengig av basisbildet du velger, må du kanskje installere flere avhengigheter. Faktum er at noen basisbilder (som Node Alpine Linux) er laget med mål om å gjøre dem så kompakte som mulig. Som et resultat kan det hende at de ikke har noen av programmene du forventer.

▍Bygge, merke og kjøre containeren

Lokal montering og lansering av container er etter vi har Dockerfile, oppgavene er ganske enkle. Før du skyver bildet til Docker Hub, må du teste det lokalt.

▍Montering

Først må du samle et bilde, spesifisere et navn og eventuelt en tag (hvis en tag ikke er spesifisert, vil systemet automatisk tilordne en tag til bildet latest).

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

Etter å ha kjørt denne kommandoen, kan du se Docker bygge bildet.

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

Byggingen kan ta et par minutter - alt avhenger av hvor mange avhengigheter du har. Når byggingen er fullført, kan du kjøre kommandoen docker images og se på beskrivelsen av det nye bildet ditt.

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

▍Start

Bildet er laget. Dette betyr at du kan kjøre en container basert på den. Fordi jeg vil ha tilgang til applikasjonen som kjører i containeren på localhost:5000, meg, på venstre side av paret 5000:5000 i den neste installerte kommandoen 5000. På høyre side er containerporten.

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

Nå som beholderen er opprettet og kjører, kan du bruke kommandoen docker ps for å se på informasjon om denne beholderen (eller du kan bruke kommandoen docker ps -a, som viser informasjon om alle beholdere, ikke bare kjørende).

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

Hvis du nå går til adressen localhost:5000 — du kan se en side i et kjørende program som ser nøyaktig ut som siden til et program som kjører i et produksjonsmiljø.

▍Tagging og publisering

For å bruke et av de opprettede bildene på produksjonsserveren, må vi kunne laste ned dette bildet fra Docker Hub. Dette betyr at du først må opprette et depot for prosjektet på Docker Hub. Etter dette vil vi ha et sted vi kan sende bildet. Bildet må gis nytt navn slik at navnet starter med Docker Hub-brukernavnet vårt. Dette skal følges av navnet på depotet. Enhver merkelapp kan plasseres på slutten av navnet. Nedenfor er et eksempel på navngivning av bilder ved hjelp av dette opplegget.

Nå kan du bygge bildet med et nytt navn og kjøre kommandoen docker push for å skyve den til Docker Hub-depotet.

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

Hvis alt går bra, vil bildet være tilgjengelig på Docker Hub og kan enkelt lastes opp til serveren eller overføres til andre utviklere.

De neste trinnene

Nå har vi bekreftet at applikasjonen, i form av en Docker-beholder, kjører lokalt. Vi har lastet opp beholderen til Docker Hub. Alt dette betyr at vi allerede har gjort veldig gode fremskritt mot målet vårt. Nå må vi løse to spørsmål til:

• Sette opp et CI-verktøy for testing og distribusjon av kode.
• Sette opp produksjonsserveren slik at den kan laste ned og kjøre koden vår.

I vårt tilfelle bruker vi Travis C.I.. Som server - DitigalOcean.

Det skal bemerkes at her kan du bruke en annen kombinasjon av tjenester. For eksempel, i stedet for Travis CI, kan du bruke CircleCI eller Github Actions. Og i stedet for DigitalOcean - AWS eller Linode.

Vi bestemte oss for å jobbe med Travis CI, og jeg har allerede noe konfigurert i denne tjenesten. Derfor vil jeg nå kort snakke om hvordan du forbereder den til arbeid.

Travis C.I.

Travis CI er et verktøy for å teste og distribuere kode. Jeg vil ikke gå inn på vanskelighetene med å sette opp Travis CI, siden hvert prosjekt er unikt, og dette vil ikke gi mye nytte. Men jeg skal dekke det grunnleggende for å komme i gang hvis du bestemmer deg for å bruke Travis CI. Enten du velger Travis CI, CircleCI, Jenkins eller noe annet, vil lignende konfigurasjonsmetoder bli brukt overalt.

For å komme i gang med Travis CI, gå til prosjektets nettside og opprette en konto. Integrer deretter Travis CI med GitHub-kontoen din. Når du setter opp systemet, må du spesifisere depotet du vil automatisere arbeidet med og aktivere tilgang til det. (Jeg bruker GitHub, men jeg er sikker på at Travis CI kan integreres med BitBucket og GitLab og andre lignende tjenester).

Hver gang Travis CI startes, startes serveren, og utfører kommandoene som er spesifisert i konfigurasjonsfilen, inkludert distribusjon av de tilsvarende arkivgrenene.

▍Jobbens livssyklus

Travis CI konfigurasjonsfil kalt .travis.yml og lagret i prosjektets rotkatalog, støtter konseptet med hendelser Livssyklus oppgaver. Disse hendelsene er oppført i den rekkefølgen de oppstår:

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

▍Testing

I konfigurasjonsfilen skal jeg konfigurere den lokale Travis CI-serveren. Jeg valgte Node 12 som språk og ba systemet installere avhengighetene som kreves for å bruke Docker.

Alt som er oppført i .travis.yml, vil bli utført når alle pull-forespørsler er sendt til alle grener av depotet, med mindre annet er spesifisert. Dette er en nyttig funksjon fordi det betyr at vi kan teste all kode som kommer inn i depotet. Dette lar deg vite om koden er klar til å skrives til filialen. master, og om det vil bryte prosjektbyggingsprosessen. I denne globale konfigurasjonen installerer jeg alt lokalt, kjører Webpack-utviklerserveren i bakgrunnen (dette er en funksjon i arbeidsflyten min), og kjører tester.

Hvis du vil at depotet ditt skal vise merker som indikerer testdekning, her Du kan finne korte instruksjoner om hvordan du bruker Jest, Travis CI og kjeledress for å samle inn og vise denne informasjonen.

Så her er innholdet i filen .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

Det er her handlingene som utføres for alle grener av depotet og for pull-forespørsler slutter.

▍Distribusjon

Basert på antakelsen om at alle automatiserte tester ble fullført, kan vi, som er valgfritt, distribuere koden til produksjonsserveren. Siden vi ønsker å gjøre dette kun for kode fra grenen master, gir vi systemet passende instruksjoner i distribusjonsinnstillingene. Før du prøver å bruke koden som vi skal se på neste gang i prosjektet ditt, vil jeg advare deg om at du må ha et faktisk skript kalt for distribusjon.

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

Implementeringsskriptet løser to problemer:

• Bygg, merk og send bildet til Docker Hub ved hjelp av et CI-verktøy (i vårt tilfelle, Travis CI).
• Laster bildet på serveren, stopper den gamle beholderen og starter en ny (i vårt tilfelle kjører serveren på DigitalOcean-plattformen).

Først må du sette opp en automatisk prosess for å bygge, merke og skyve bildet til Docker Hub. Alt dette er veldig likt det vi allerede har gjort manuelt, bortsett fra at vi trenger en strategi for å tildele unike tagger til bilder og automatisere pålogginger. Jeg hadde problemer med noen detaljer om distribusjonsskriptet, for eksempel taggestrategi, pålogging, SSH-nøkkelkoding, SSH-tilkoblingsetablering. Men heldigvis er kjæresten min veldig flink med bash, som med mange andre ting. Han hjalp meg med å skrive dette manuset.

Så den første delen av skriptet er å laste opp bildet til Docker Hub. Dette er ganske enkelt å gjøre. Taggeskjemaet jeg brukte innebærer å kombinere en git-hash og en git-tag, hvis en finnes. Dette sikrer at taggen er unik og gjør det lettere å identifisere sammenstillingen den er basert på. DOCKER_USERNAME и DOCKER_PASSWORD er brukermiljøvariabler som kan stilles inn ved hjelp av Travis CI-grensesnittet. Travis CI vil automatisk behandle sensitive data slik at de ikke faller i feil hender.

Her er første del av manuset 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}

Hva den andre delen av skriptet blir, avhenger helt av hvilken vert du bruker og hvordan forbindelsen til den er organisert. I mitt tilfelle, siden jeg bruker Digital Ocean, bruker jeg kommandoene for å koble til serveren doctl. Når du arbeider med AWS, vil verktøyet bli brukt aws, og så videre.

Det var ikke spesielt vanskelig å sette opp serveren. Så jeg satte opp en dråpe basert på basisbildet. Det skal bemerkes at systemet jeg valgte krever en engangs manuell installasjon av Docker og en engangs manuell lansering av Docker. Jeg brukte Ubuntu 18.04 for å installere Docker, så hvis du også bruker Ubuntu til å gjøre det samme, kan du bare følge med dette enkel guide.

Jeg snakker ikke her om spesifikke kommandoer for tjenesten, siden dette aspektet kan variere sterkt i forskjellige tilfeller. Jeg vil bare gi en generell handlingsplan som skal utføres etter tilkobling via SSH til serveren som prosjektet skal distribueres på:

• Vi må finne beholderen som kjører og stoppe den.
• Deretter må du starte en ny beholder i bakgrunnen.
• Du må sette serverens lokale port til 80 - Dette vil tillate deg å gå inn på siden på en adresse som example.com, uten å spesifisere porten, i stedet for å bruke en adresse som example.com:5000.
• Til slutt må du slette alle gamle beholdere og bilder.

Her er fortsettelsen av manuset.

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

Noen ting å være oppmerksom på

Det er mulig at når du kobler til serveren via SSH fra Travis CI, vil du se en advarsel som vil hindre deg i å fortsette med installasjonen da systemet vil vente på brukerens svar.

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

Jeg lærte at en strengnøkkel kan kodes i base64 for å lagre den i en form der den enkelt og pålitelig kan arbeides med. På installasjonsstadiet kan du dekode den offentlige nøkkelen og skrive den til en fil known_hosts for å bli kvitt feilen ovenfor.

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

I praksis kan denne kommandoen se slik ut:

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

Og her er hva den produserer - en base64-kodet streng:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Her er kommandoen nevnt ovenfor

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

Den samme tilnærmingen kan brukes med en privat nøkkel når du oppretter en tilkobling, siden du godt kan trenge en privat nøkkel for å få tilgang til serveren. Når du arbeider med nøkkelen, trenger du bare å sørge for at den er lagret sikkert i en Travis CI-miljøvariabel og at den ikke vises noe sted.

En annen ting å merke seg er at du kanskje må kjøre hele distribusjonsskriptet som én linje, for eksempel - med doctl. Dette kan kreve litt ekstra innsats.

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

TLS/SSL og lastbalansering

Etter at jeg gjorde alt nevnt ovenfor, var det siste problemet jeg møtte at serveren ikke hadde SSL. Siden jeg bruker en Node.js server, for å tvinge работать omvendt proxy Nginx og Let's Encrypt, du må tukle mye.

Jeg ville virkelig ikke gjøre all denne SSL-konfigurasjonen manuelt, så jeg opprettet bare en lastbalanser og registrerte detaljene i DNS. Når det gjelder DigitalOcean, for eksempel, er det en enkel, gratis og rask prosedyre å opprette et selvsignert sertifikat for automatisk fornyelse på lastbalanseren. Denne tilnærmingen har den ekstra fordelen at den gjør det veldig enkelt å sette opp SSL på flere servere som kjører bak en lastbalanser om nødvendig. Dette gjør at serverne selv ikke kan "tenke" på SSL i det hele tatt, men samtidig bruke porten som vanlig 80. Så å sette opp SSL på en lastbalanser er mye enklere og mer praktisk enn alternative metoder for å sette opp SSL.

Nå kan du lukke alle porter på serveren som aksepterer innkommende tilkoblinger – bortsett fra porten 80, brukes til å kommunisere med lastbalanseren og porten 22 for SSH. Som et resultat vil et forsøk på å få direkte tilgang til serveren på andre porter enn disse to mislykkes.

Resultater av

Etter at jeg gjorde alt jeg snakket om i dette materialet, skremte verken Docker-plattformen eller konseptene med automatiserte CI/CD-kjeder meg lenger. Jeg var i stand til å sette opp en kontinuerlig integrasjonskjede, hvor koden testes før den går i produksjon og koden blir automatisk distribuert på serveren. Dette er fortsatt relativt nytt for meg, og jeg er sikker på at det finnes måter å forbedre min automatiserte arbeidsflyt og gjøre den mer effektiv på. Så hvis du har noen ideer om denne saken, vennligst gi meg beskjed. meg vet. Jeg håper denne artikkelen har hjulpet deg i dine bestrebelser. Jeg vil tro at etter å ha lest den, lærte du like mye som jeg lærte mens du fant ut alt jeg snakket om i den.

PS I vår markedsplass det er et bilde Docker, som kan installeres med ett klikk. Du kan sjekke driften av containere på VPS. Alle nye kunder får 3 dagers testing gratis.

Kjære lesere! Bruker du CI/CD-teknologi i prosjektene dine?

Kilde: www.habr.com