Skapa en CI/CD-kedja och automatisera arbetet med Docker

Jag skrev mina första hemsidor i slutet av 90-talet. Då var det väldigt lätt att få dem att fungera. Det fanns en Apache-server på någon delad hosting, du kunde logga in på den här servern via FTP genom att skriva något liknande ftp://ftp.example.com. Sedan var du tvungen att ange ditt namn och lösenord och ladda upp filerna till servern. Det fanns andra tider, allt var enklare då än nu.

Under de två decennierna sedan dess har allt förändrats mycket. Webbplatser har blivit mer komplexa, de måste sättas ihop innan de släpps i produktion. En enda server blev många servrar som körde bakom lastbalanserare, och användningen av versionskontrollsystem blev vanligt.

För mitt personliga projekt hade jag en speciell konfiguration. Och jag visste att jag behövde möjligheten att distribuera webbplatsen i produktionen genom att bara utföra en åtgärd: att skriva kod till en filial master på GitHub. Dessutom visste jag att för att säkerställa driften av min lilla webbapplikation, ville jag inte hantera ett enormt Kubernetes-kluster, eller använda Docker Swarm-teknik, eller underhålla en flotta av servrar med pods, agenter och alla möjliga andra komplexitet. För att nå målet att göra arbetet så enkelt som möjligt behövde jag bli bekant med CI/CD.

Om du har ett litet projekt (i det här fallet ett Node.js-projekt) och du vill veta hur du automatiserar distributionen av detta projekt, samtidigt som du säkerställer att det som lagras i förvaret exakt matchar det som fungerar i produktionen, då tror att du kan vara intresserad av den här artikeln.

Förutsättningar

Läsaren av den här artikeln förväntas ha en grundläggande förståelse för kommandoraden och att skriva Bash-skript. Dessutom kommer han att behöva konton Travis CI и Docker-nav.

mål

Jag kommer inte att säga att den här artikeln ovillkorligen kan kallas en "handledning". Det här är mer ett dokument där jag berättar om vad jag har lärt mig och beskriver den process som passar mig för att testa och distribuera kod till produktion, utförd i ett automatiserat pass.

Detta är vad mitt arbetsflöde blev.

För kod som skickas till alla förvarsgrenar förutom master, utförs följande åtgärder:

• Projektet som bygger på Travis CI startar.
• Alla enhets-, integrations- och end-to-end-tester utförs.

Endast för kod som faller in master, utförs följande:

• Allt som nämns ovan, plus...
• Bygga en Docker-bild baserat på aktuell kod, inställningar och miljö.
• Distribuerar bilden till Docker Hub.
• Anslutning till produktionsservern.
• Ladda upp en bild från Docker Hub till servern.
• Stoppa den aktuella behållaren och starta en ny baserat på den nya bilden.

Om du inte vet absolut ingenting om Docker, bilder och behållare, oroa dig inte. Jag ska berätta allt om det.

Vad är CI/CD?

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

▍Kontinuerlig integration

Kontinuerlig integration är en process där utvecklare förbinder sig till projektets huvudsakliga källkodsförråd (vanligtvis en gren master). Samtidigt säkerställs kodens kvalitet genom automatiserad testning.

▍Kontinuerlig distribution

Kontinuerlig distribution är den frekventa, automatiserade distributionen av kod i produktionen. Den andra delen av CI/CD-akronymen stavas ibland som "kontinuerlig leverans." Detta är i grunden samma sak som "kontinuerlig driftsättning", men "kontinuerlig leverans" innebär att man måste bekräfta ändringar manuellt innan man startar projektinstallationsprocessen.

Komma igång

Appen jag använde för att lära mig allt detta heter Notera. Det här är ett webbprojekt jag håller på med, designat för att göra anteckningar. Först försökte jag göra JAMStack-projekt, eller bara en front-end-applikation utan server, för att dra fördel av standardvärden och projektdistributionsmöjligheter som den erbjuder nätifiera. Allt eftersom komplexiteten i applikationen växte behövde jag skapa dess serverdel, vilket innebar att jag skulle behöva formulera min egen strategi för automatiserad integration och automatiserad implementering av projektet.

I mitt fall är applikationen en Express-server som körs i Node.js-miljön, som betjänar en ensidig React-applikation och stöder ett säkert server-API. Denna arkitektur följer den strategi som finns i given Full stack-autentiseringsguide.

jag rådfrågade med andra, som är en automationsexpert, och frågade honom vad jag behövde göra för att få det hela att fungera som jag ville. Han gav mig idén om hur ett automatiserat arbetsflöde ska se ut, som beskrivs i avsnittet Mål i den här artikeln. Att ha dessa mål innebar att jag behövde ta reda på hur jag skulle använda Docker.

Hamnarbetare

Docker är ett verktyg som tack vare containeriseringsteknik gör att applikationer enkelt kan distribueras, distribueras och köras i samma miljö, även om själva Docker-plattformen körs i olika miljöer. Först behövde jag lägga vantarna på Dockers kommandoradsverktyg (CLI). instruktion Docker installationsguide kan inte kallas särskilt tydlig och förståelig, men från den kan du lära dig att för att ta det första installationssteget måste du ladda ner Docker Desktop (för Mac eller Windows).

Docker Hub är ungefär samma sak som GitHub för git repositories eller register npm för JavaScript-paket. Detta är ett onlineförråd för Docker-bilder. Detta är vad Docker Desktop ansluter till.

Så för att komma igång med Docker måste du göra två saker:

• Ställ DockerDesktop.
• Registrera för Docker-nav.

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

docker -v

Logga sedan in på Docker Hub genom att ange ditt användarnamn och lösenord när du tillfrågas:

docker login

För att använda Docker måste du förstå begreppen bilder och behållare.

▍Bilder

En bild är ungefär som en ritning som innehåller instruktioner för montering av behållaren. Detta är en oföränderlig ögonblicksbild av programmets filsystem och inställningar. Utvecklare kan enkelt dela bilder.

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

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

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

Därefter kommer vi att titta på några exempel på kommandon i samma format - först finns det ett kommando med en kommentar och sedan ett exempel på vad det kan mata ut.

▍Behållare

En container är ett körbart paket som innehåller allt som behövs för att köra en applikation. En applikation med detta tillvägagångssätt kommer alltid att fungera likadant, oavsett infrastruktur: i en isolerad miljö och i samma miljö. Poängen är att instanser av samma bild lanseras 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.

▍En snabb referens till Docker-kommandon

Här är en översikt över några vanliga Docker-kommandon.

Team

sammanhang

effekt

hamnarbyggare

bild

Bygga en bild från en Dockerfile

docker tag

bild

Bildtaggning

dockerbilder

bild

Lista bilder

docker körning

behållare

Köra en behållare baserat på en bild

hamnarbetare

bild

Ladda upp en bild till registret

hamnare dra

bild

Laddar en bild från registret

docker ps

behållare

Lista containrar

docker system beskära

Bild/behållare

Ta bort oanvända behållare och bilder

▍Dockerfil

Jag vet hur man kör en produktionsapplikation lokalt. Jag har en Webpack-konfiguration utformad för att bygga en färdig React-applikation. Därefter har jag ett kommando som startar en Node.js-baserad server på porten 5000. Det ser ut så här:

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

Det bör noteras att jag inte har en exempelapplikation för detta material. Men här, för experiment, duger vilken enkel Node-applikation som helst.

För att kunna använda behållaren måste du ge instruktioner till Docker. Detta görs genom en fil som heter Dockerfile, som finns i projektets rotkatalog. Den här filen verkar till en början ganska obegriplig.

Men vad den innehåller beskriver bara, med speciella kommandon, något som liknar att sätta upp en arbetsmiljö. Här är några av dessa kommandon:

• FRÅN — Det här kommandot startar en fil. Den anger basbilden som behållaren är byggd på.
• KOPIA — Kopiera filer från en lokal källa till en behållare.
• WORKDIR — Ställa in arbetskatalogen för följande kommandon.
• SPRINGA - Kör kommandon.
• ÖVERSIKT — Portinställningar.
• INKÖRSPORT — Indikation av kommandot som ska utfö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 basbild du väljer kan du behöva installera ytterligare beroenden. Faktum är att vissa basbilder (som Node Alpine Linux) skapas med målet att göra dem så kompakta som möjligt. Som ett resultat av detta kanske de inte har några av de program du förväntar dig.

▍Bygga, tagga och driva behållaren

Lokal montering och sjösättning av containern är efter vi har Dockerfile, uppgifterna är ganska enkla. Innan du skickar bilden till Docker Hub måste du testa den lokalt.

▍Montering

Först måste du samla bild, ange ett namn och, valfritt, en tagg (om en tagg inte anges, kommer systemet automatiskt att tilldela en tagg till bilden latest).

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

Efter att ha kört det här kommandot kan du se Docker bygga bilden.

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

Bygget kan ta ett par minuter - allt beror på hur många beroenden du har. När bygget ä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        About a minute ago   x.xxGB

▍Starta

Bilden har skapats. Det betyder att du kan köra en container baserat på den. Eftersom jag vill kunna komma åt applikationen som körs i behållaren på localhost:5000, jag, på vänstra sidan av paret 5000:5000 i nästa installerade kommando 5000. På höger sida finns containerporten.

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

Nu när behållaren har skapats och körs kan du använda kommandot docker ps för att titta på information om den här behållaren (eller så kan du använda kommandot docker ps -a, som visar information om alla behållare, inte bara de som körs).

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

Om du nu går till adressen localhost:5000 — du kan se en sida i ett körande program som ser exakt likadant ut som sidan i ett program som körs i en produktionsmiljö.

▍Taggning och publicering

För att kunna använda en av de skapade bilderna på produktionsservern måste vi kunna ladda ner den här bilden från Docker Hub. Det betyder att du först måste skapa ett arkiv för projektet på Docker Hub. Efter detta kommer vi att ha en plats dit vi kan skicka bilden. Bilden måste bytas om så att dess namn börjar med vårt Docker Hub-användarnamn. Detta bör följas av namnet på förvaret. Vilken tagg som helst kan placeras i slutet av namnet. Nedan är ett exempel på namngivning av bilder med detta schema.

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

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

Om allt går bra kommer bilden att finnas tillgänglig på Docker Hub och kan enkelt laddas upp till servern eller överföras till andra utvecklare.

Nästa steg

Vid det här laget har vi verifierat att applikationen, i form av en Docker-behållare, körs lokalt. Vi har laddat upp behållaren till Docker Hub. Allt detta betyder att vi redan har gjort mycket goda framsteg mot vårt mål. Nu måste vi lösa ytterligare två frågor:

• Konfigurera ett CI-verktyg för att testa och distribuera kod.
• Konfigurera produktionsservern så att den kan ladda ner och köra vår kod.

I vårt fall använder vi Travis CI. Som server - DitigalOcean.

Det bör noteras att här kan du använda en annan kombination av tjänster. Till exempel, istället för Travis CI, kan du använda CircleCI eller Github Actions. Och istället för DigitalOcean - AWS eller Linode.

Vi bestämde oss för 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 prata om hur man förbereder det för arbete.

Travis CI

Travis CI är ett verktyg för att testa och distribuera kod. Jag skulle inte vilja gå in på krångligheterna med att sätta upp Travis CI, eftersom varje projekt är unikt, och detta kommer inte att ge mycket nytta. Men jag ska täcka grunderna för att komma igång om du bestämmer dig för att använda Travis CI. Oavsett om du väljer Travis CI, CircleCI, Jenkins eller något annat, kommer liknande konfigurationsmetoder att användas överallt.

För att komma igång med Travis CI, gå till projektplats och skapa ett konto. Integrera sedan Travis CI med ditt GitHub-konto. När du ställer in systemet måste du ange med vilket arkiv du vill automatisera arbetet och aktivera åtkomst till det. (Jag använder GitHub, men jag är säker på att Travis CI kan integreras med BitBucket och GitLab och andra liknande tjänster).

Varje gång Travis CI startas startas en server som exekverar de kommandon som anges i konfigurationsfilen, inklusive distribution av motsvarande förvarsgrenar.

▍Jobbens livscykel

Travis CI konfigurationsfil anropad .travis.yml och lagras i projektets rotkatalog, stödjer konceptet med händelser livscykel uppgifter. Dessa händelser listas i den ordning de inträffar:

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

▍Tester

I konfigurationsfilen ska jag konfigurera den lokala Travis CI-servern. Jag valde Node 12 som språk och sa åt systemet att installera de beroenden som krävs för att använda Docker.

Allt som är listat i .travis.yml, kommer att köras när alla pull-begäranden görs till alla grenar av förvaret, om inte annat anges. Detta är en användbar funktion eftersom det betyder att vi kan testa all kod som kommer in i förvaret. Detta låter dig veta om koden är redo att skrivas till filialen. master, och om det kommer att bryta projektets byggprocess. I den här globala konfigurationen installerar jag allt lokalt, kör Webpack-devservern i bakgrunden (detta är en funktion i mitt arbetsflöde) och kör tester.

Om du vill att ditt förråd ska visa märken som indikerar testtäckning, här Du kan hitta korta instruktioner om hur du använder Jest, Travis CI och overaller för att samla in och visa denna information.

Så här är innehållet 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 är här de åtgärder som utförs för alla grenar av förvaret och för pull-förfrågningar slutar.

▍Isättning

Baserat på antagandet att alla automatiserade tester slutfördes framgångsrikt kan vi, vilket är valfritt, distribuera koden till produktionsservern. Eftersom vi bara vill göra detta för kod från grenen masterger vi systemet lämpliga instruktioner i distributionsinställningarna. Innan du försöker använda koden som vi kommer att titta på härnäst i ditt projekt, vill jag varna dig för att du måste ha ett verkligt skript som kallas för distribution.

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

Implementeringsskriptet löser två problem:

• Bygg, tagga och skicka bilden till Docker Hub med ett CI-verktyg (i vårt fall Travis CI).
• Laddar bilden på servern, stoppar den gamla behållaren och startar en ny (i vårt fall körs servern på DigitalOcean-plattformen).

Först måste du ställa in en automatisk process för att bygga, tagga och skicka bilden till Docker Hub. Allt detta är väldigt likt det vi redan har gjort manuellt, förutom att vi behöver en strategi för att tilldela unika taggar till bilder och automatisera inloggningar. Jag hade svårt med vissa detaljer i distributionsskriptet, såsom taggningsstrategi, inloggning, SSH-nyckelkodning, SSH-anslutningsetablering. Men som tur är är min pojkvän väldigt bra med bash, som med många andra saker. Han hjälpte mig att skriva det här manuset.

Så, den första delen av skriptet är att ladda upp bilden till Docker Hub. Detta är ganska lätt att göra. Taggningsschemat jag använde innebär att kombinera en git-hash och en git-tagg, om en sådan finns. Detta säkerställer att taggen är unik och gör det lättare att identifiera den sammansättning som den är baserad på. DOCKER_USERNAME и DOCKER_PASSWORD är användarmiljövariabler som kan ställas in med Travis CI-gränssnittet. Travis CI kommer automatiskt att behandla känsliga uppgifter så att de inte hamnar i fel händer.

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

Vad den andra delen av skriptet kommer att vara beror helt på vilken värd du använder och hur kopplingen till den är organiserad. I mitt fall, eftersom jag använder Digital Ocean, använder jag kommandona för att ansluta till servern doctl. När du arbetar med AWS kommer verktyget att användas aws, och så vidare.

Att ställa in servern var inte särskilt svårt. Så jag satte upp en droppe baserat på basbilden. Det bör noteras att systemet jag valde kräver en manuell installation av Docker en gång och en manuell lansering av Docker. Jag använde Ubuntu 18.04 för att installera Docker, så om du också använder Ubuntu för att göra detsamma kan du bara följa detta enkel guide.

Jag pratar inte här om specifika kommandon för tjänsten, eftersom denna aspekt kan variera mycket i olika fall. Jag kommer bara att ge en allmän handlingsplan som ska utföras efter anslutning via SSH till servern där projektet kommer att distribueras:

• Vi måste hitta behållaren som är igång och stoppa den.
• Sedan måste du starta en ny behållare i bakgrunden.
• Du måste ställa in serverns lokala port till 80 - detta gör att du kan komma in på webbplatsen på en adress som example.com, utan att ange porten, istället för att använda en adress som example.com:5000.
• Slutligen måste du ta bort alla gamla behållare och bilder.

Här är fortsättningen på 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

Några saker att uppmärksamma

Det är möjligt att när du ansluter till servern via SSH från Travis CI kommer du att se en varning som hindrar dig från att fortsätta med installationen eftersom systemet väntar på användarens 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)?

Jag lärde mig att en strängnyckel kan kodas i base64 för att spara den i en form där den enkelt och tillförlitligt kan arbetas med. I installationsstadiet kan du avkoda den publika nyckeln och skriva den till en fil known_hosts för att bli av med ovanstående fel.

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

I praktiken kan det här kommandot 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== [email protected]" | base64

Och här är vad den producerar - en base64-kodad sträng:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Här är kommandot som nämns ovan

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

Samma tillvägagångssätt kan användas med en privat nyckel när du upprättar en anslutning, eftersom du mycket väl kan behöva en privat nyckel för att komma åt servern. När du arbetar med nyckeln behöver du bara se till att den lagras säkert i en Travis CI-miljövariabel och att den inte visas någonstans.

En annan sak att notera är att du kan behöva köra hela distributionsskriptet som en rad, till exempel - med doctl. Detta kan kräva lite extra ansträngning.

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

TLS/SSL och lastbalansering

Efter att jag gjort allt som nämns ovan var det sista problemet jag stötte på att servern inte hade SSL. Eftersom jag använder en Node.js-server, för att tvinga arbete omvänd proxy Nginx och Let's Encrypt, du behöver mixtra mycket.

Jag ville verkligen inte göra all denna SSL-konfiguration manuellt, så jag skapade bara en lastbalanserare och registrerade dess detaljer i DNS. När det gäller DigitalOcean, till exempel, är det en enkel, gratis och snabb procedur att skapa ett självsignerat certifikat för automatisk förnyelse på lastbalanseraren. Detta tillvägagångssätt har den extra fördelen att det gör det mycket enkelt att ställa in SSL på flera servrar som körs bakom en lastbalanserare om det behövs. Detta gör att servrarna själva inte kan "tänka" på SSL alls, utan samtidigt använda porten som vanligt 80. Så att ställa in SSL på en lastbalanserare är mycket enklare och bekvämare än alternativa metoder för att ställa in SSL.

Nu kan du stänga alla portar på servern som accepterar inkommande anslutningar - förutom porten 80, används för att kommunicera med lastbalanseraren och porten 22 för SSH. Som ett resultat kommer ett försök att direkt komma åt servern på andra portar än dessa två misslyckas.

Resultat av

Efter att jag gjort allt jag pratade om i det här materialet skrämde varken Docker-plattformen eller koncepten med automatiserade CI/CD-kedjor mig längre. Jag kunde sätta upp en kontinuerlig integrationskedja, under vilken koden testas innan den går i produktion och koden distribueras automatiskt på servern. Allt detta är fortfarande relativt nytt för mig, och jag är säker på att det finns sätt att förbättra mitt automatiserade arbetsflöde och göra det mer effektivt. Så om du har några idéer i denna fråga, vänligen meddela mig. mig känna till. Jag hoppas att den här artikeln har hjälpt dig i dina ansträngningar. Jag vill tro att du efter att ha läst den lärde dig lika mycket som jag lärde dig samtidigt som du kom på allt jag pratade om i den.

PS I vår marknad det finns en bild Hamnarbetare, som kan installeras med ett klick. Du kan kontrollera hanteringen av containrar på VPS. Alla nya kunder får 3 dagars testning utan kostnad.

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

Källa: will.com