Oprettelse af en CI/CD-kæde og automatisering af arbejde med Docker

Jeg skrev mine første hjemmesider i slutningen af ​​90'erne. Så var det meget nemt at bringe dem i funktionsdygtig stand. Der var en Apache-server på en delt hosting, denne server kunne tilgås via FTP ved at skrive i browserlinjen noget som ftp://ftp.example.com. Så var det nødvendigt at indtaste et navn og en adgangskode og uploade filerne til serveren. Der var andre tidspunkter, alt var enklere dengang, end det er nu.

Tingene har ændret sig meget i de sidste to årtier. Sites er blevet mere komplekse, de skal samles, før de sættes i produktion. En enkelt server er blevet til mange servere, der kører bag load balancers, brugen af ​​versionskontrolsystemer er blevet almindelig.

Til mit personlige projekt havde jeg en speciel konfiguration. Og jeg vidste, at jeg havde brug for evnen til at implementere et websted i produktionen ved kun at udføre én handling: at skrive kode til en filial master på GitHub. Jeg vidste også, at jeg ikke ville administrere en enorm Kubernetes-klynge eller bruge Docker Swarm-teknologi eller vedligeholde en serverpark med pods, agenter og alle mulige andre kompleksiteter til at køre min lille webapplikation. For at nå målet om at gøre arbejdet så nemt som muligt, var jeg nødt til at stifte bekendtskab med CI/CD.

Hvis du har et lille projekt (i vores tilfælde et Node.js-projekt) og gerne vil lære at automatisere implementeringen af ​​dette projekt, samtidig med at du sikrer dig, at det, der er gemt i repository, nøjagtigt matcher det, der fungerer i produktionen, tror jeg du kan være interesseret i denne artikel.

Forudsætninger

Læseren af ​​denne artikel forventes at have grundlæggende kommandolinje og Bash scripting viden. Derudover skal han bruge regnskaber Travis CI и Docker-hub.

mål

Jeg vil ikke sige, at denne artikel ubetinget kan kaldes en "træningsvejledning". Dette er mere et dokument, hvor jeg taler om, hvad jeg har lært, og beskriver den proces, der passer mig til at teste og implementere kode til produktion, udført i én automatiseret gennemgang.

Her er, hvordan mit workflow endte med at se ud.

For kode, der er skubbet til enhver anden gren af ​​depotet end master, udføres følgende handlinger:

• Projektbyggeri på Travis CI starter.
• Alle enheds-, integrations- og end-to-end tests udføres.

Kun for kode, der ender i master, gøres følgende:

• Alt ovenstående plus...
• Opbygning af et Docker-billede baseret på den aktuelle kode, indstillinger og miljø.
• Hosting af billedet på Docker Hub.
• Tilslutning til produktionsserveren.
• Uploader et billede fra Docker Hub til serveren.
• Stop den aktuelle container og start en ny baseret på det nye billede.

Hvis du absolut intet ved om Docker, billeder og containere, så fortvivl ikke. Jeg vil fortælle dig alt om det.

Hvad er CI/CD?

Forkortelsen CI / CD står for "continuous integration / continuous deployment" - "continuous integration / continuous deployment".

▍Kontinuerlig integration

Kontinuerlig integration er den proces, hvorved udviklere forpligter sig til et projekts primære kildekodelager (normalt en filial) master). Samtidig sikres kodens kvalitet gennem automatiseret test.

▍Kontinuerlig implementering

Kontinuerlig implementering er den hyppige automatiserede implementering af kode til produktion. Den anden del af forkortelsen CI/CD afsløres nogle gange som "kontinuerlig levering" ("kontinuerlig levering"). Dette er grundlæggende det samme som "kontinuerlig implementering", men "kontinuerlig levering" indebærer, at ændringer skal bekræftes manuelt, før projektimplementeringsprocessen påbegyndes.

Kom godt i gang

Den applikation, som jeg mestrede alt dette på, hedder Tage til efterretning. Dette er et webprojekt, jeg arbejder på for at tage noter. Først prøvede jeg at gøre JAMStack-projekt, eller bare en frontend-applikation uden en server, for at drage fordel af de standard hosting- og projektimplementeringsmuligheder, som det tilbyder netify. Efterhånden som kompleksiteten af ​​applikationen voksede, var jeg nødt til at skabe dens back-end, hvilket betød, at jeg skulle danne min egen strategi for automatiseret integration og automatiseret udrulning af projektet.

I mit tilfælde er applikationen en Express-server, der kører i et Node.js-miljø, der betjener en enkeltsidet React-applikation og understøtter en sikker server-side API. Denne arkitektur følger en strategi, der kan findes i givet fuld stack-godkendelsesvejledning.

jeg rådførte mig med ven, som er automationsekspert, og spurgte ham, hvad jeg skal gøre for at få det hele til at fungere, som jeg ønsker. Han gav mig en idé om, hvordan den automatiserede arbejdsgang, der er skitseret i afsnittet Mål i denne artikel, skulle se ud. At sætte mål som dette betød, at jeg skulle finde ud af, hvordan jeg skulle bruge Docker.

Docker

Docker er et værktøj, der takket være containeriseringsteknologi gør det nemt at distribuere applikationer, samt implementere og køre dem i det samme miljø, selvom selve Docker-platformen kører i forskellige miljøer. Først skulle jeg have fat i Docker-kommandolinjeværktøjerne (CLI). instruktion Installationsvejledningen til Docker er ikke særlig klar, men du kan lære af den, at for at tage det første trin af installationen, skal du downloade Docker Desktop (til Mac eller Windows).

Docker Hub er omtrent det samme som GitHub for git repositories eller registreringsdatabasen NPM til JavaScript-pakker. Dette er et online lager for Docker-billeder. Det er her Docker Desktop opretter forbindelse til.

Så for at komme i gang med Docker skal du gøre to ting:

• Indstil DockerDesktop.
• Tilmeld dig Docker-hub.

Derefter kan du kontrollere, om Docker CLI fungerer ved at køre følgende kommando for at kontrollere Docker-versionen:

docker -v

Log derefter på Docker Hub ved at indtaste dit brugernavn og din adgangskode, når du bliver bedt om det:

docker login

For at bruge Docker skal du forstå begreberne billeder og containere.

▍Billeder

Et billede er en slags blueprint, der indeholder instruktioner til at bygge en container. Dette er et uforanderligt øjebliksbillede af filsystemet og applikationsindstillingerne. Udviklere kan nemt dele billeder.

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

Denne kommando udsender en tabel med følgende titel:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

Dernæst vil vi overveje nogle eksempler på kommandoer i samme format - først er der en kommando med en kommentar, og derefter et eksempel på, hvad den kan udlæse.

▍Containere

En container er en eksekverbar pakke, der indeholder alt det nødvendige for at køre en applikation. En applikation med denne tilgang vil altid fungere ens, uanset infrastrukturen: i et isoleret miljø og i det samme miljø. Vi taler om det faktum, at forekomster af det samme billede lanceres i forskellige miljøer.

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

▍Tags

Et tag er en indikation af en bestemt version af et billede.

▍Hurtig reference til Docker-kommandoer

Her er en oversigt over nogle almindeligt anvendte Docker-kommandoer.

Team

kontekst

effekt

docker bygning

billede

Opbygning af et billede fra en Dockerfile

docker tag

billede

Billedmærkning

docker billeder

billede

Viser en liste over billeder

docker løb

container

Kørsel af en billedbaseret container

docker push

billede

Sende et billede til registreringsdatabasen

docker-pull

billede

Indlæsning af et billede fra registreringsdatabasen

docker ps

container

Liste containere

docker system beskære

Billede/beholder

Fjernelse af ubrugte beholdere og billeder

▍Dockerfil

Jeg ved, hvordan man kører en produktionsapplikation lokalt. Jeg har en webpack-konfiguration til at bygge en færdig React-app. Dernæst har jeg en kommando, der starter en Node.js-baseret server på porten 5000. Det ser sådan ud:

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

Det skal bemærkes, at jeg ikke har et eksempel på ansøgning om dette materiale. Men her, for eksperimenter, vil enhver simpel Node-applikation duge.

For at bruge containeren skal du give instruktioner til Docker. Dette gøres gennem en fil kaldet Dockerfileplaceret i projektets rodmappe. Denne fil virker i første omgang ret uforståelig.

Men det, den indeholder, beskriver kun, i specielle kommandoer, noget som at oprette et arbejdsmiljø. Her er nogle af disse kommandoer:

• FRA — Denne kommando starter en fil. Det angiver det basisbillede, som containeren er bygget ud fra.
• COPY - Kopiering af filer fra en lokal kilde til en container.
• WORKDIR - Indstilling af arbejdsbiblioteket for følgende kommandoer.
• LØB - Kør kommandoer.
• UDSÆTTE - Port indstilling.
• INDGANG — En indikation af den kommando, der skal udføres.

Dockerfile kan se sådan ud:

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

Afhængigt af det basisbillede, du vælger, skal du muligvis installere yderligere afhængigheder. Faktum er, at nogle basisbilleder (som Node Alpine Linux) er designet til at være så kompakte som muligt. Som følge heraf inkluderer de muligvis ikke nogle af de programmer, du forventer.

▍Bygge, tagge og drive en container

Lokal montering og søsætning af containeren er, efter vi har Dockerfileopgaverne er ret simple. Før du skubber et billede til Docker Hub, skal det testes lokalt.

▍Samling

Først skal du samle billede, angivelse af et navn og eventuelt et mærke (hvis der ikke er angivet et mærke, vil systemet automatisk tildele et mærke til billedet latest).

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

Efter at have kørt denne kommando, kan du se Docker bygge billedet.

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

Opbygningen kan tage et par minutter - det hele afhænger af, hvor mange afhængigheder du har. Når opbygningen er færdig, kan du køre kommandoen docker images og tag et kig på beskrivelsen af ​​dit nye billede.

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

▍Start

Billedet er blevet oprettet. Og det betyder, at du på dets grundlag kan køre en container. Da jeg gerne vil have adgang til den applikation, der kører i containeren kl localhost:5000, i, på venstre side af parret 5000:5000 i følgende kommandosæt 5000. På højre side er containerhavnen.

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

Nu hvor beholderen er oprettet og kører, kan du bruge kommandoen docker ps for at se oplysninger om denne beholder (eller du kan bruge kommandoen docker ps -a, som viser information om alle containere, ikke kun kø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 nu går til localhost:5000 - du kan se siden for den kørende applikation, som ser nøjagtig ud som den side af applikationen, der kører i produktionsmiljøet.

▍Tag-tildeling og udgivelse

For at kunne bruge et af de oprettede billeder på produktionsserveren, skal vi kunne downloade dette billede fra Docker Hub. Det betyder, at du først skal oprette et lager for projektet på Docker Hub. Derefter har vi et sted, hvor vi kan sende billedet. Billedet skal omdøbes, så dets navn starter med vores Docker Hub-brugernavn. Dette skal efterfølges af navnet på depotet. Ethvert mærke kan placeres i slutningen af ​​navnet. Nedenfor er et eksempel på navngivning af billeder i henhold til dette skema.

Nu kan du bygge billedet med et nyt navn tildelt det og køre kommandoen docker push for at skubbe den til Docker Hub-lageret.

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 godt, vil billedet være tilgængeligt på Docker Hub og kan nemt uploades til serveren eller deles med andre udviklere.

Næste trin

På nuværende tidspunkt har vi bekræftet, at applikationen, i form af en Docker-container, kører lokalt. Vi har uploadet containeren til Docker Hub. Alt dette betyder, at vi allerede har gjort meget gode fremskridt mod vores mål. Nu skal vi løse to spørgsmål mere:

• Opsætning af et CI-værktøj til test og implementering af kode.
• Opsætning af produktionsserveren, så den kan downloade og køre vores kode.

I vores tilfælde bruger vi som en CI/CD løsning Travis CI. Som server - DigitalOcean.

Det skal bemærkes, at her kan du bruge en anden kombination af tjenester. For eksempel, i stedet for Travis CI, kan du bruge CircleCI eller Github Actions. Og i stedet for DigitalOcean - AWS eller Linode.

Vi besluttede at arbejde med Travis CI, og jeg har allerede sat noget op i denne tjeneste. Derfor vil jeg nu kort fortælle om, hvordan man forbereder det til arbejde.

Travis CI

Travis CI er et værktøj til at teste og implementere kode. Jeg ønsker ikke at gå ind i detaljerne omkring opsætning af Travis CI, da hvert projekt er unikt, og det vil ikke gøre meget godt. Men jeg vil dække det grundlæggende for at komme i gang, hvis du beslutter dig for at bruge Travis CI. Uanset hvad du vælger - Travis CI, CircleCI, Jenkins eller noget andet, vil lignende konfigurationsmetoder gælde overalt.

For at komme i gang med Travis CI, gå til projektets hjemmeside og opret en konto. Integrer derefter Travis CI med din GitHub-konto. Når du opsætter systemet, skal du angive det lager, du vil automatisere, og aktivere adgang til det. (Jeg bruger GitHub, men jeg er sikker på, at Travis CI kan integreres med BitBucket, GitLab og andre lignende tjenester).

Hver gang Travis CI startes, startes en server, der udfører de kommandoer, der er angivet i konfigurationsfilen, inklusive implementering af de relevante grene af lageret.

▍Joblivscyklus

Travis CI konfigurationsfil kaldet .travis.yml og gemt i projektets rodmappe, understøtter begrebet begivenheder livscyklus opgaver. Her er begivenhederne, anført i den rækkefølge, de finder sted:

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

▍Test

I konfigurationsfilen skal jeg opsætte en lokal Travis CI-server. Jeg valgte Node 12 som sprog og fortalte systemet at installere de afhængigheder, der er nødvendige for at bruge Docker.

Alt opført i .travis.yml, vil blive udført på alle pull-anmodninger til alle grene af repository, medmindre andet er angivet. Dette er en nyttig funktion, da det betyder, at vi kan teste al den kode, der går ind i depotet. Dette giver dig mulighed for at vide, om koden er klar til at blive skrevet til filialen. master, og om det vil bryde byggeprocessen for projektet. I denne globale konfiguration installerer jeg alt lokalt, kører Webpack-dev-serveren i baggrunden (dette er en funktion af min arbejdsgang) og kører testene.

Hvis du ønsker, at dit lager skal vise kodedækningsikoner, her du kan finde en hurtig vejledning om, hvordan du bruger Jest, Travis CI og overtræksdragter til at indsamle og vise disse oplysninger.

Så her er indholdet af 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, de handlinger, der udføres for alle grene af lageret og for pull-anmodninger, slutter.

▍Implementering

Baseret på den antagelse, at alle automatiserede test er gennemført med succes, kan vi valgfrit implementere koden til produktionsserveren. Da vi kun ønsker at gøre dette for filialkode master, giver vi systemet de relevante instruktioner i installationsindstillingerne. Inden du forsøger at bruge koden, som vi skal se på næste gang i dit projekt, vil jeg gerne advare dig om, at du skal have et egentligt script, der kaldes til implementering.

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

Implementeringsscriptet gør to ting:

• Opbygning, tagging og afsendelse af billedet til Docker Hub ved hjælp af et CI-værktøj (i vores tilfælde er det Travis CI).
• Indlæsning af billedet på serveren, stop af den gamle container og start af en ny (i vores tilfælde kører serveren på DigitalOcean-platformen).

Først skal du konfigurere en automatisk proces til at bygge, tagge og skubbe billedet til Docker Hub. Alt dette er meget lig det, vi allerede har gjort manuelt, bortset fra at her har vi brug for en strategi for at tildele unikke tags til billeder og automatisere login. Jeg havde problemer med nogle detaljer i implementeringsscriptet, såsom tagging-strategi, login, kodning af SSH-nøgler, etablering af en SSH-forbindelse. Men heldigvis er min kæreste meget god til bash, såvel som til mange andre ting. Han hjalp mig med at skrive dette manuskript.

Så den første del af scriptet sender billedet til Docker Hub. At gøre dette er ret simpelt. Det tagging-skema, jeg har brugt, involverer at kombinere git-hashen og git-tagget, hvis det findes. Dette sikrer, at tagget er unikt og gør det nemmere at identificere den samling, den er baseret på. DOCKER_USERNAME и DOCKER_PASSWORD er brugerdefinerede miljøvariabler, der kan indstilles ved hjælp af Travis CI-grænsefladen. Travis CI vil automatisk behandle følsomme data, så de ikke falder i de forkerte hænder.

Her er første del af manuskriptet 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}

Hvad den anden del af scriptet bliver, afhænger helt af, hvilken vært du bruger, og hvordan forbindelsen til den er organiseret. I mit tilfælde, da jeg bruger Digital Ocean, bruges kommandoerne til at oprette forbindelse til serveren doctl. Når du arbejder med Aws, vil hjælpeprogrammet blive brugt aws, og så videre.

Opsætning af serveren var ikke særlig vanskelig. Så jeg oprettede en dråbe baseret på basisbilledet. Det skal bemærkes, at det system, jeg har valgt, kræver en engangsmanuel installation af Docker og en engangsmanuel start af Docker. Jeg brugte Ubuntu 18.04 til at installere Docker, så hvis du også bruger Ubuntu kan du bare følge med dette enkel vejledning.

Jeg taler ikke om specifikke kommandoer til tjenesten her, da dette aspekt kan variere meget i forskellige tilfælde. Jeg vil blot give en generel handlingsplan, der skal udføres efter tilslutning via SSH til serveren, hvor projektet vil blive implementeret:

• Du skal finde den container, der kører i øjeblikket, og stoppe den.
• Så skal du starte en ny beholder i baggrunden.
• Du skal indstille serverens lokale port til 80 - dette giver dig mulighed for at indtaste webstedet på formularens adresse example.com, uden at angive en port, i stedet for at bruge en adresse som example.com:5000.
• Og endelig skal du fjerne alle gamle beholdere og billeder.

Her er fortsættelsen af ​​manuskriptet.

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

Nogle ting at passe på

Det er muligt, at når du opretter forbindelse til serveren via SSH fra Travis CI, vil du se en advarsel, der ikke vil tillade dig at fortsætte med installationen, da systemet vil vente på brugerens 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øgle kan kodes i base64 for at gemme den i en form, hvor den nemt og pålideligt kan arbejdes med. På installationsstadiet kan du afkode den offentlige nøgle og skrive den til en fil known_hosts for at slippe af med ovenstående fejl.

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

I praksis kan denne kommando se sådan ud:

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, hvad den giver ud - en base64-kodet streng:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Her er kommandoen nævnt ovenfor

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

Den samme tilgang kan bruges med en privat nøgle, når du etablerer en forbindelse, da du godt kan have brug for en privat nøgle for at få adgang til serveren. Når du arbejder med en nøgle, skal du kun sikre dig, at den er sikkert gemt i en Travis CI-miljøvariabel, og at den ikke vises nogen steder.

En anden ting at bemærke er, at du muligvis skal køre hele implementeringsscriptet som en enkelt linje, for eksempel med doctl. Dette kan kræve en ekstra indsats.

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

TLS/SSL og belastningsbalancering

Efter at jeg havde gjort alt ovenstående, var det sidste problem, jeg havde, at serveren ikke havde SSL. Da jeg bruger en Node.js server, for at tvinge at arbejde omvendt proxy Nginx og Let's Encrypt, du skal pille meget.

Jeg ville virkelig ikke lave alle disse SSL-indstillinger manuelt, så jeg oprettede bare en load balancer og registrerede information om det i DNS. I tilfældet med DigitalOcean er det for eksempel en enkel, gratis og hurtig procedure at oprette et selvsigneret certifikat for automatisk fornyelse på load balanceren. Denne tilgang har den ekstra fordel, at den gør det meget nemt at konfigurere SSL på flere servere, der kører bag en load balancer, hvis det er nødvendigt. Dette gør det muligt for serverne selv slet ikke at "tænke" på SSL, men samtidig som sædvanligt bruge porten 80. Så at konfigurere SSL på en load balancer er meget nemmere og mere bekvemt end alternative SSL-konfigurationsmetoder.

Nu kan du lukke alle porte på serveren, der accepterer indgående forbindelser – undtagen porten 80, bruges til at kommunikere med belastningsbalanceren og porten 22 for SSH. Som et resultat vil et forsøg på at kontakte serveren direkte på andre porte end disse to mislykkes.

Resultaterne af

Efter at jeg gjorde alt, hvad jeg talte om i denne artikel, skræmte hverken Docker-platformen eller konceptet med automatiserede CI/CD-kæder mig længere. Jeg var i stand til at opsætte en kontinuerlig integrationskæde, hvor koden testes, inden den går i produktion, og koden automatisk implementeres på serveren. Alt dette er stadig relativt nyt for mig, og jeg er sikker på, at der er måder at forbedre min automatiserede arbejdsgang på og gøre den mere effektiv. Så hvis du har nogle ideer om dette - giv mig ved godt. Jeg håber, at denne artikel har hjulpet dig i dine bestræbelser. Jeg vil tro, at ved at læse den, lærte du lige så meget, som jeg lærte, mens jeg beskæftigede mig med alt, hvad jeg fortalte om i den.

PS I vores markedsplads der er et billede Docker, som installeres med et enkelt klik. Du kan kontrollere, at beholderne fungerer på VPS. Alle nye kunder får 3 dages test gratis.

Kære læsere! Bruger du CI/CD-teknologier i dine projekter?

Kilde: www.habr.com