Skapande av CI/CD-kedja och automatisering av arbete med Docker

Jag skrev mina första webbplatser i slutet av 90-talet. Då var det mycket enkelt att få dem att fungera. Det fanns en Apache-server på någon typ av delad hosting, och du kunde logga in på den servern via FTP, genom att skriva något i webbläsarens adressfält som ftp://ftp.example.com. Sedan behövde man ange namn och lösenord och ladda upp filer till servern. Det var andra tider, allt var enklare då än nu.

Under de senaste två decennierna har mycket förändrats. Webbplatser har blivit mer komplexa och innan de släpps i produktion måste de byggas. En enda server har blivit många servrar som arbetar bakom lastbalanserare, och användningen av versionshanteringssystem har blivit vanligt.

För mitt personliga projekt hade jag en speciell konfiguration. Och jag visste att jag behövde möjlighet att distribuera webbplatsen i produktion med endast en åtgärd: att skriva koden till grenen master på GitHub. Dessutom visste jag att jag inte ville hantera en stor Kubernetes-kluster, eller använda Docker Swarm, eller underhålla en park av servrar med poddar, agenter och andra komplexiteter för att få mitt lilla webbtillämpning att fungera. För att uppnå målet att förenkla arbetet mest möjligt behövde jag bekanta mig med CI/CD.

Om du har ett litet projekt (i vårt fall handlar det om ett Node.js-projekt) och vill veta hur man automatiserar distributionen av detta projekt, så att det som lagras i förvaret exakt motsvarar det som fungerar i produktion, så kan denna artikel intressera dig.

Förkrav

Det förväntas att läsaren av denna artikel har grundläggande kunskaper om att arbeta med kommandoraden och skriva Bash-skript. Dessutom kommer du att behöva konton Travis CI och Docker Hub.

Målsättningar

Jag kan inte säga att denna artikel utan tvekan kan kallas en "handledning". Detta är snarare ett dokument där jag berättar vad jag har lärt mig och beskriver den process för testning och distribution av kod i produktion som jag är nöjd med, genomförd i ett automatiserat steg.

Så här blev min arbetsprocess till slut.

För koden som skickas till någon gren av förvaret, förutom master, utförs följande åtgärder:

• Projektbyggnaden startas på Travis CI.
• Alla enhetstest, integrationstester och end-to-end-tester körs.

Endast för koden som träffar master, utförs följande:

• Allt det som nämns ovan, plus…
• Byggande av en Docker-image baserat på den aktuella koden, inställningarna och miljön.
• Publicering av imagen på Docker Hub.
• Anslutning till produktionsservern.
• Nedladdning av imagen från Docker Hub till servern.
• Stoppa den aktuella containern och starta en ny baserat på den nya imagen.

Om du inte vet någonting om Docker, images och containrar, oroa dig inte. Jag kommer att berätta allt om det.

Vad är CI/CD?

Förkortningen CI/CD står för "continuous integration/continuous deployment" — "kontinuerlig integration/kontinuerlig distribution".

▍Kontinuerlig integration

Kontinuerlig integration är en process där utvecklare gör commits till det huvudsakliga källkodsförrådet för projektet (vanligtvis till grenen master). Kvaliteten på koden säkerställs genom att automatiserade tester utförs.

▍Kontinuerlig distribution

Kontinuerlig distribution är en frekvent automatiserad distribution av kod till produktion. Den andra delen av förkortningen CI/CD ibland förklaras som "continuous delivery" ("kontinuerlig leverans"). Detta är i allmänhet detsamma som "kontinuerlig distribution", men "kontinuerlig leverans" innebär behovet av manuell bekräftelse av förändringar innan distributionsprocessen för projektet inleds.

Komma igång

Applikationen som jag har lärt mig detta på heter TakeNote. Detta är ett webbprojekt som jag jobbar med, avsett för att ta anteckningar. Först försökte jag göra ett JAMStack-projekt, eller bara en frontend-applikation utan server, för att utnyttja standardfunktionerna för hosting och distribution av projekt som erbjuds av Netlify. I takt med att komplexiteten i applikationen växte, behövde jag skapa dess serverdel, vilket betydde att jag skulle behöva formulera min egen strategi för automatiserad integration och automatiserad distribution av projektet.

I mitt fall representerar applikationen en Express-server som körs i Node.js-miljö, som betjänar en en-sides React-applikation och stödjer ett skyddat server-API. Denna arkitektur följer en strategi som man kan hitta i denna guide för fullstack-autentisering.

Jag rådfrågade med annan, som är expert på automation, och jag frågade honom vad jag behövde göra för att allt skulle fungera som jag ville. Han gav mig en idé om hur den automatiserade arbetsprocessen skulle se ut, beskriven i avsnittet "Mål" i den här artikeln. Att jag hade satt sådana mål betydde att jag behövde förstå hur man använder Docker.

Docker

Docker är ett verktyg som, tack vare containerteknologi, gör det enkelt att distribuera applikationer, samt att utföra deras distribution och körning i samma miljö även om själva Docker-plattformen fungerar i olika miljöer. För att börja behövde jag få tillgång till Docker Command Line Interface (CLI) verktyg. Instruktionen för att installera Docker kan inte kallas särskilt tydlig och lättförståelig, men den ger information om att för att göra det första steget i installationen måste man ladda ner Docker Desktop (för Mac eller Windows).

Docker Hub är ungefär detsamma som GitHub för git-repositorier, eller ett register npm för JavaScript-paket. Det är ett online-repositorium för Docker-bilder. Det är just till detta som Docker Desktop ansluter.

Så, för att börja arbeta med Docker, måste du göra två saker:

• Installera användning av.
• Registrera dig på Docker Hub.

Efter det kan du kontrollera att Docker CLI fungerar genom att köra följande kommando för att kontrollera Docker-versionen:

docker -v

Därefter, logga in på Docker Hub genom att ange ditt användarnamn och lösenord när du blir tillfrågad:

docker login

För att använda Docker måste du förstå koncepten av bilder och containrar.

▍Bilder

En bild är som en plan som innehåller instruktioner för att bygga en container. Det är en oförändrad avbildning av filsystemet och applikationsinställningarna. Utvecklare kan enkelt dela bilder.

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

Detta kommando kommer att visa en tabell med följande rubrik:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

Därefter kommer vi att gå igenom några exempel på kommandon i samma format — först kommer kommandot med en kommentar, och sedan ett exempel på vad det kan ge som utdata.

▍Containrar

En container är ett exekverbart paket som innehåller allt som behövs för att köra en applikation. Med denna metod kommer applikationen alltid att fungera på samma sätt oavsett infrastruktur: i en isolerad miljö och i samma typ av miljö. Detta handlar om att instanser av samma bild startas i olika miljöer.

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

▍Taggar

En tagg är en indikation på en specifik version av en bild.

▍Kort guide för Docker-kommandon

Här är en översikt över några av de oftast använda Docker-kommandona.

Team

Kontext

för konsolen nu:

docker build

Typ

Bygga en bild från Dockerfile

docker tag

Typ

Tagga en bild

docker images

Typ

Visa listan över bilder

docker run

Container

Köra en container baserad på en bild

docker push

Typ

Skicka en bild till registret

docker pull

Typ

Ladda ner en bild från registret

docker ps

Container

Visa listan över containrar

docker system prune

Bild/Container

Ta bort oanvända containrar och bilder

▍Dockerfile

Jag vet hur man lokalt startar en applikation för produktion. Jag har en Webpack-konfiguration som är avsedd för att bygga en färdig React-applikation. Dessutom har jag ett kommando som kör en server baserad på Node.js på porten 5000. Så här ser det ut:

npm i          # installera beroenden
npm run build  # bygga React-applikationen
npm run start  # starta Node-servern

Det är värt att notera att jag inte har något exempelapplikation för detta material. Men här, för experiment, passar vilken enkel Node-applikation som helst.

För att använda containern behöver du ge instruktioner till Docker. Detta görs genom en fil som kallas Dockerfile, som finns i projektets rotmapp. Denna fil verkar i början ganska svår att förstå.

Men innehållet i den beskriver i själva verket, med speciella kommandon, något som liknar inställning av arbetsmiljön. Här är några av dessa kommandon:

• FRÅN — Detta kommando startar filen. Det anger den grundbild som containern bygger på.
• COPY — Kopiera filer från en lokal källa till containern.
• WORKDIR — Ange arbetskatalogen för följande kommandon.
• RUN — Köra kommandon.
• EXPOSE — Ställa in porten.
• ENTRYPOINT — Ange kommandot som ska köras.

Dockerfile kan se ut ungefär så här:

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

Beroende på vilken grundbild du väljer kan det hända att du behöver installera extra beroenden. Vissa grundbilder (till exempel Node Alpine Linux) har skapats för att vara så kompakta som möjligt. Därför kan det hända att vissa program som du förlitar dig på saknas.

▍Byggande, taggning och körning av container

Lokal byggnation och körning av container är efter att vi har Dockerfile, ganska enkla uppgifter. Innan du skickar bilden till Docker Hub måste den testas lokalt.

▍Byggnation

Först måste vi bygga bild, ange ett namn och eventuellt en tagg (om ingen tagg specificeras, kommer systemet automatiskt att tilldela bilden en tagg latest).

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

När detta kommando har körts kan du se hur Docker bygger bilden.

Sending build context to Docker daemon   2.88MB
Step 1/9 : FROM node:12-alpine
 ---> ...utför byggstegen...
Successfully built 123456789123
Successfully tagged <image>:<tag>

Byggprocessen kan ta ett par minuter – beroende på hur många beroenden du har. Efter att byggandet är klart kan du köra kommandot docker images och titta på beskrivningen av din nya bild.

REPOSITORY          TAG               IMAGE ID            CREATED              SIZE
<image>             latest            123456789123        För ungefär en minut sedan   x.xxGB

▍Körning

Bild skapad. Det betyder att vi kan starta en container baserad på den. Eftersom jag vill ha möjlighet att nå applikationen som körs i containern via adressen localhost:5000, har jag i den vänstra delen av paret 5000:5000 i nästa kommando angivit 5000. I den högra delen finns porten för containern.

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

Nu när containern har skapats och körs kan du använda kommandot docker ps för att få information om denna container (eller så kan du använda kommandot docker ps -a, som visar information om alla containrar, inte bara de som körs).

CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS                      PORTS                    NAMES
987654321234        <image>             "/bin/sh -c 'npm run…"   6 sekunder sedan        Up 6 sekunder                0.0.0.0:5000->5000/tcp   stoic_darwin

Om du nu går till adressen localhost:5000 – kan du se sidan för den körande applikationen, som ser exakt ut som sidan för applikationen som körs i produktionsmiljö.

▍Tilldelning av tagg och publicering

För att använda ett av de skapade bilderna på produktionsservern behöver vi kunna ladda ner denna bild från Docker Hub. Det innebär att vi först måste skapa ett lager på Docker Hub för projektet. Därefter får vi en plats där vi kan skicka bilden. Bilden måste döpas så att dess namn börjar med vårt användarnamn på Docker Hub. Efter det ska namn på lagret följa. I slutet av namnet kan en valfri tagg placeras. Nedan visas ett exempel på namngivning av bilder enligt detta schema.

Nu kan vi bygga bilden och ge den ett nytt namn och köra kommandot docker push för att skicka den till Docker Hub-lagret.

docker build -t /: .
docker tag /: /:latest
docker push /:

# I praktiken kan det se ut så här:
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

Om allt går som det ska, kommer bilden att vara tillgänglig på Docker Hub och lätt kunna laddas ner till servern eller överföras till andra utvecklare.

Följande steg

Vid detta stadium har vi verifierat att applikationen, som en Docker-container, fungerar lokalt. Vi har laddat containern på Docker Hub. Allt detta innebär att vi redan har kommit långt mot vårt mål. Nu behöver vi lösa ytterligare två frågor:

• Inställning av CI-verktyg för testning och distribution av kod.
• Inställning av produktionsservern så att den kan ladda ner och köra vår kod.

I vårt fall används som CI/CD-lösning Travis CI. Som server — DigitalOcean.

Det är värt att notera att det här kan användas en annan kombination av tjänster. Till exempel kan CircleCI eller Github Actions användas istället för Travis CI. Och istället för DigitalOcean — AWS eller Linode.

Vi har beslutat att arbeta med Travis CI, och jag har redan något konfigurerat i den här tjänsten. Därför kommer jag nu kort att berätta hur man förbereder det för arbete.

Travis CI

Travis CI är ett verktyg för testning och distribution av kod. Jag skulle inte vilja gå in på detaljer om hur man konfigurerar Travis CI, eftersom varje projekt är unikt och det inte skulle vara särskilt användbart. Men jag kommer att berätta om grunderna som gör det möjligt för dig att börja arbeta om du väljer att använda Travis CI. Oavsett vad du väljer — Travis CI, CircleCI, Jenkins eller något annat — kommer liknande metoder att tillämpas.

För att börja arbeta med Travis CI, gå till projektets webbplats och skapa ett konto. Integrera sedan Travis CI med ditt GitHub-konto. Under systeminställningarna kommer du att behöva ange det förråd som du vill automatisera, och ge åtkomst till det. (Jag använder GitHub, men jag är säker på att Travis CI kan integreras med BitBucket, GitLab och andra liknande tjänster).

Varje gång Travis CI startar ett arbete, startas en server som kör de kommandon som anges i konfigurationsfilen, inklusive distribution av aktuella grenar av förrådet.

▍Uppgifts livscykel

Konfigurationsfilen för Travis CI, som kallas .travis.yml och som lagras i projektets rotkatalog, stöder konceptet av händelser för RHEL 6 och 7-distributioner, och för RHEL 8 kommer det att publiceras paketuppdateringar i Application Stream fram till juni 2024. för uppgiften. Här är dessa händelser, i den ordning de inträffar:

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

▍Testning

I konfigurationsfilen kommer jag att ställa in en lokal server för Travis CI. Som språk har jag valt Node version 12 och instruerat systemet att installera de beroenden som behövs för att använda Docker.

Allt som anges i .travis.yml, kommer att köras vid alla pull-förfrågningar till alla grenar av förrådet, såvida inte annat anges. Detta är en användbar funktion, eftersom det innebär att vi kan testa all kod som kommer in i förrådet. Det gör att vi kan veta om koden är redo att skrivas till grenen master, och om den inte kommer att störa byggprocessen av projektet. I denna globala konfiguration installerar jag allt lokalt, kör Webpack utvecklarserver i bakgrunden (detta är en funktion av min arbetsprocess) och kör tester.

Om du vill att det i ditt förråd ska visas märken med information om testtäckning av koden, ). Ett typiskt exempel på användning: kan du hitta en kort vägledning om användning av Jest, Travis CI och Coveralls för att samla in och visa dessa uppgifter.

Så här ser innehållet i filen ut .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

Här slutar de åtgärder som utförs för alla grenar av förrådet och för pull-förfrågningar.

▍Distribution

Med tanke på att alla automatiserade tester har avslutats framgångsrikt, kan vi, vilket inte är obligatoriskt, distribuera koden till produktionsservern. Eftersom vi bara vill göra detta för koden från grenen master, vi ger systemet lämpliga instruktioner i distributionsinställningarna. Innan du försöker använda koden som vi kommer att gå igenom senare i ditt projekt, vill jag varna dig för att du måste ha ett verkligt skript som anropas för distribution.

deploy:
  # Bygg Docker-kontainern och skicka den till Docker Hub
  provider: script
  script: bash deploy.sh
  on:
    branch: master

Distributionsskriptet löser två uppgifter:

• Bygga, tagga och skicka bilden till Docker Hub med CI-verktyget (i vårt fall är det Travis CI).
• Ladda upp bilden på servern, stoppa den gamla kontainern och starta den nya (i vårt fall kör servern på plattformen DigitalOcean).

Först måste du ställa in den automatiska byggprocessen, taggning och uppladdning av bilden till Docker Hub. Allt detta liknar det vi redan har gjort manuellt, förutom att vi behöver en strategi för att tilldela bilder unika taggar och automatisera inloggningen. Jag hade problem med vissa detaljer i distributionsskriptet, såsom taggningsstrategin, inloggningen, SSH-nyckelkodningen och etableringen av SSH-anslutningen. Men lyckligtvis är min pojkvän mycket bra på bash, precis som på många andra saker. Han hjälpte mig att skriva detta skript.

Så, den första delen av skriptet är att skicka bilden till Docker Hub. Det är ganska enkelt. Den taggstruktur jag använde innebär en kombination av git-hash och git-tag, om den existerar. Detta säkerställer att en unik tagg skapas och underlättar identifieringen av bygget som den baserades på. DOCKER_USERNAME och DOCKER_PASSWORD — är användarspecifika miljövariabler som kan ställas in med hjälp av gränssnittet för Travis CI. Travis CI kommer automatiskt att hantera känsliga uppgifter så att de inte hamnar i fel händer.

Här är den första delen av skriptet 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}

Hur den andra delen av skriptet kommer att se ut beror helt på vilken värd du använder och hur anslutningen är organiserad. I mitt fall, eftersom jag använder Digital Ocean, används kommandon för att ansluta till servern doctl. Vid arbete med AWS kommer verktyget aws, och så vidare.

Att konfigurera serverns drift var inte särskilt svårt. Så, jag konfigurerade en droplet baserad på en grundbild. Det är värt att nämna att det system jag valde kräver en engångshandinstallation av Docker och en engångshandstart av Docker. För att installera Docker använde jag Ubuntu 18.04, så om ni också använder Ubuntu för att göra detsamma kan ni bara följa detta den enkla guiden.

Jag pratar inte här om specifika kommandon för tjänsten, eftersom detta kan variera kraftigt i olika fall. Jag kommer bara att ge en allmän handlingsplan som genomförs efter att man kopplat upp sig via SSH till servern där projektet ska distribueras:

• Du behöver hitta den container som för närvarande körs och stoppa den.
• Sedan måste du i bakgrunden starta en ny container.
• Du kommer att behöva ställa in den lokala serverporten till värdet 80 — detta kommer att göra att du kan komma åt webbplatsen på en adress av typen example.com, utan att ange port, istället för att använda en adress som liknar example.com:5000.
• Och slutligen måste du ta bort alla gamla containrar och bilder.

Här är fortsättningen på skriptet.

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

Några saker att vara medveten om

Kanske, när du kopplar upp dig på servern via SSH från Travis CI, kommer du att se en varning som hindrar installationen från att fortsätta, eftersom systemet kommer att vänta på användarens respons.

Autenticiteten av värden '<hostname> (<IP address>)' kan inte fastställas.
RSA nyckelfingeravtryck är <key fingerprint>.
Är du säker på att du vill fortsätta ansluta (ja/nej)?

Jag fick veta att strängnyckeln kan kodas i base64 för att bevara den i ett format som är enklare och säkrare att arbeta med. Vid installationsstadiet kan den offentliga nyckeln dekodas och skrivas till filen known_hosts för att bli av med det tidigare beskrivna felet.

echo <public key> | base64 # utdata <offentlig nyckel, kodad i base64>

I praktiken kan detta kommando se ut så här:

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== you@example.com" | base64

Och här är hur den ser ut — en sträng i base64-kodning:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Här är kommandot som nämndes ovan

install:
  - echo  | base64 -d >> $HOME/.ssh/known_hosts

Samma metod kan användas med den privata nyckeln vid anslutning, eftersom du kanske behöver den privata nyckeln för att få åtkomst till servern. När du arbetar med nyckeln behöver du bara se till att den lagras säkert i en miljövariabel för Travis CI, och att den inte skrivs ut någonstans.

En annan sak att tänka på är att du kan behöva köra hela distributionsskriptet som en enda rad, till exempel — med hjälp av doctl. Detta kan kräva en del extra ansträngningar.

doctl compute ssh  --ssh-command "alla kommandon kommer att vara här && här"

TLS/SSL och lastbalansering

Efter att jag gjort allt som nämndes ovan, blev den sista frågan jag ställde mig att servern inte hade SSL. Eftersom jag använder en Node.js-server, för att få detta att fungera fungera behövs en Nginx backproxy och Let’s Encrypt, vilket kräver en del arbete.

Jag ville verkligen inte göra all denna SSL-konfiguration manuellt, så jag skapade helt enkelt en lastbalanserare och registrerade dess information i DNS. I fallet med DigitalOcean, till exempel, är det en enkel, gratis och snabb procedur att skapa ett självsignerat certifikat som uppdateras automatiskt på lastbalanseraren. Denna metod har också den extra fördelen att det enkelt tillåter att ställa in SSL på flera servrar som arbetar bakom lastbalanseraren. Det innebär att servrarna själva inte behöver "tänka" på SSL, men kan använda porten som vanligt. 80Så att konfigurera SSL på lastbalanseraren är mycket enklare och bekvämare än alternativa metoder för att ställa in SSL.

Nu kan vi stänga alla portar på servern som accepterar inkommande anslutningar — förutom porten 80, som används för kommunikation med lastbalanseraren, och porten 22 för SSH. Som ett resultat kommer ett direktförsök att kontakta servern via andra portar än dessa två att misslyckas.

Sammanfattning

Efter att jag gjorde allt som jag nämner i detta material var jag inte längre rädd för plattformen Docker eller koncepten kring automatiserade CI/CD-processer. Jag lyckades ställa in en kontinuerlig integrationskedja där kodtestning sker innan den når produktion och kod automatiskt distribueras på servern. Allt detta är fortfarande ganska nytt för mig, och jag är säker på att det finns sätt att förbättra min automatiserade arbetsprocess och göra den effektivare. Så om du har några idéer i det avseendet — låt mig veta. jag Jag hoppas att denna artikel har hjälpt dig i dina sysslor. Jag vill tro att genom att läsa den har du lärt dig lika mycket som jag gjorde medan jag utforskade allt som jag talade om här.

P.S. I vår marknadsplats finns en bild Docker, som installeras med ett klick. Du kan kontrollera hur containrarna fungerar på VPS. Alla nya kunder får 3 dagar gratis för testning.

Kära läsare! Använder du CI/CD-teknologier i dina projekt?

Källa: habr.com