Създаване на CI / CD верига и автоматизиране на работата с Docker

Написах първите си уебсайтове в края на 90-те. Тогава беше много лесно да ги приведете в работно състояние. Имаше Apache сървър на някакъв споделен хостинг, този сървър можеше да бъде достъпен чрез FTP, като напишете в реда на браузъра нещо като ftp://ftp.example.com. След това беше необходимо да въведете име и парола и да качите файловете на сървъра. Бяха други времена, тогава всичко беше по-просто от сега.

Нещата се промениха много през последните две десетилетия. Сайтовете станаха по-сложни, те трябва да бъдат сглобени, преди да бъдат пуснати в производство. Един единствен сървър се превърна в много сървъри, работещи зад балансиращи устройства, използването на системи за контрол на версиите стана обичайно.

За моя личен проект имах специална конфигурация. И знаех, че имам нужда от способността да разположа сайт в производствена среда, като извърша само едно действие: писане на код в клон master на GitHub. Знаех също, че не искам да управлявам огромен клъстер на Kubernetes или да използвам технологията Docker Swarm, или да поддържам сървърен парк с подове, агенти и всякакви други сложности, за да изпълнявам малкото си уеб приложение. За да постигна целта да улесня максимално работата, трябваше да се запозная с CI / CD.

Ако имате малък проект (в нашия случай проект Node.js) и искате да научите как да автоматизирате внедряването на този проект, като същевременно се уверите, че това, което се съхранява в хранилището, съвпада точно с това, което работи в производството, мисля може да се интересувате от тази статия.

Предпоставки

От читателя на тази статия се очаква да има основни познания за команден ред и Bash скриптове. Освен това ще му трябват сметки Травис CI и Докер център.

цели

Няма да кажа, че тази статия може безусловно да се нарече "ръководство за обучение". Това е по-скоро документ, в който говоря за това, което научих, и описвам процеса, който ми подхожда за тестване и внедряване на код в производство, извършен с едно автоматизирано преминаване.

Ето как в крайна сметка изглежда моят работен процес.

За код, насочен към всеки клон на хранилището, различен от master, се извършват следните действия:

• Започва изграждането на проекта върху Travis CI.
• Извършват се всички модулни, интеграционни и крайни тестове.

Само за код, който завършва в master, се прави следното:

• Всичко по-горе, плюс...
• Изграждане на изображение на Docker въз основа на текущия код, настройки и среда.
• Хостинг на изображението в Docker Hub.
• Връзка към производствения сървър.
• Качване на изображение от Docker Hub на сървъра.
• Спрете текущия контейнер и започнете нов въз основа на новото изображение.

Ако не знаете абсолютно нищо за Docker, изображения и контейнери, не се притеснявайте. Ще ти разкажа всичко.

Какво е CI/CD?

Съкращението CI / CD означава "continuous integration / continuous deployment" - "непрекъсната интеграция / непрекъснато внедряване".

▍Непрекъсната интеграция

Непрекъснатата интеграция е процесът, чрез който разработчиците се ангажират с основното хранилище на изходния код на проекта (обикновено клон master). В същото време качеството на кода се гарантира чрез автоматизирано тестване.

▍Непрекъснато внедряване

Непрекъснатото внедряване е честото автоматизирано внедряване на код в производството. Втората част от съкращението CI / CD понякога се разкрива като "непрекъсната доставка" ("непрекъсната доставка"). Това по принцип е същото като „непрекъснато внедряване“, но „непрекъснато доставяне“ предполага необходимостта от ръчно извършване на промени, преди да започне процесът на внедряване на проекта.

Първи стъпки

Приложението, на което усвоих всичко това се казва Да вземат под внимание. Това е уеб проект, върху който работя за водене на бележки. Първо се опитах да направя JAMStack-проект или просто приложение от предния край без сървър, за да се възползвате от стандартните опции за хостинг и разгръщане на проекти, които предлага netlify. Тъй като сложността на приложението нарастваше, трябваше да създам неговия бек-енд, което означаваше, че ще трябва да формирам собствена стратегия за автоматизирана интеграция и автоматизирано внедряване на проекта.

В моя случай приложението е Express сървър, работещ в Node.js среда, обслужващ React приложение с една страница и поддържащ защитен API от страна на сървъра. Тази архитектура следва стратегия, която може да се намери в това пълно ръководство за удостоверяване на стека.

Консултирах се с друг, който е експерт по автоматизация, и го попитах какво трябва да направя, за да работи всичко както искам. Той ми даде представа как трябва да изглежда автоматизираният работен процес, очертан в раздела за целите на тази статия. Поставянето на цели като тази означаваше, че трябва да разбера как да използвам Docker.

докер

Docker е инструмент, който благодарение на технологията за контейнеризация улеснява разпространението на приложения, както и разполагането и стартирането им в една и съща среда, дори ако самата платформа Docker работи в различни среди. Първо трябваше да се сдобия с инструментите за команден ред на Docker (CLI). инструкция Ръководството за инсталиране на Docker не е много ясно, но можете да научите от него, че за да направите първата стъпка от инсталацията, трябва да изтеглите Docker Desktop (за Mac или Windows).

Docker Hub е приблизително същият като GitHub за git хранилища или регистър NPM за JavaScript пакети. Това е онлайн хранилище за Docker изображения. Това е мястото, където се свързва Docker Desktop.

И така, за да започнете с Docker, трябва да направите две неща:

• Определен DockerDesktop.
• Зарегистрирайте се на Докер център.

След това можете да проверите дали Docker CLI работи, като изпълните следната команда, за да проверите версията на Docker:

docker -v

След това влезте в Docker Hub, като въведете вашето потребителско име и парола, когато бъдете попитани:

docker login

За да използвате Docker, трябва да разбирате концепциите за изображения и контейнери.

▍Изображения

Изображението е вид план, съдържащ инструкции за изграждане на контейнер. Това е неизменна моментна снимка на файловата система и настройките на приложението. Разработчиците могат лесно да споделят изображения.

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

Тази команда ще изведе таблица със следното заглавие:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

След това ще разгледаме някои примери за команди в същия формат - първо има команда с коментар, а след това пример за това, което може да изведе.

▍Контейнери

Контейнерът е изпълним пакет, който съдържа всичко необходимо за стартиране на приложение. Приложение с този подход винаги ще работи по същия начин, независимо от инфраструктурата: в изолирана среда и в същата среда. Говорим за факта, че копия на едно и също изображение се стартират в различни среди.

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

▍Етикети

Етикетът е индикация за конкретна версия на изображение.

▍Бърза справка за Docker команди

Ето преглед на някои често използвани Docker команди.

Отбор

контекст

Действие

изграждане на докер

изображение

Изграждане на изображение от Dockerfile

докер етикет

изображение

Маркиране на изображения

снимки на докер

изображение

Показване на списък с изображения

докер

контейнер

Изпълнение на контейнер, базиран на изображения

докер натискане

изображение

Изпращане на изображение в регистъра

докер издърпване

изображение

Зареждане на изображение от системния регистър

докер ps

контейнер

Контейнери за списък

подрязване на докер система

Изображение/контейнер

Премахване на неизползвани контейнери и изображения

▍Docker файл

Знам как да стартирам производствено приложение локално. Имам конфигурация на webpack за създаване на готово приложение React. След това имам команда, която стартира базиран на Node.js сървър на порта 5000. Изглежда така:

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

Трябва да се отбележи, че нямам примерно приложение за този материал. Но тук, за експерименти, всяко просто приложение на Node ще свърши работа.

За да използвате контейнера, ще трябва да дадете инструкции на Docker. Това става чрез файл, наречен Dockerfileразположен в главната директория на проекта. Първоначално този файл изглежда доста неразбираем.

Но това, което съдържа, само описва, в специални команди, нещо като настройка на работна среда. Ето някои от тези команди:

• ОТ — Тази команда стартира файл. Той определя базовото изображение, от което е изграден контейнерът.
• COPY - Копиране на файлове от локален източник в контейнер.
• РАБОТЕН ДИРЕКТОР - Задаване на работната директория за следните команди.
• RUN - Изпълнение на команди.
• ЕКСПОЗИЦИЯ — Настройка на порт.
• ВХОДНА ТОЧКА — Индикация за командата, която трябва да бъде изпълнена.

Dockerfile може да изглежда нещо подобно:

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

В зависимост от базовото изображение, което изберете, може да се наложи да инсталирате допълнителни зависимости. Факт е, че някои базови изображения (като Node Alpine Linux) са проектирани да бъдат възможно най-компактни. В резултат на това те може да не включват някои от програмите, които очаквате.

▍Изграждане, маркиране и управление на контейнер

Локално сглобяване и стартиране на контейнера е, след като имаме Dockerfileзадачите са съвсем прости. Преди да изпратите изображение в Docker Hub, то трябва да се тества локално.

▍Сглобяване

Първо трябва да съберете изображение, като посочите име и, по избор, етикет (ако не е посочен етикет, системата автоматично ще присвои етикет на изображението latest).

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

След като изпълните тази команда, можете да гледате как Docker изгражда изображението.

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

Изграждането може да отнеме няколко минути - всичко зависи от това колко зависимости имате. След като изграждането приключи, можете да изпълните командата docker images и разгледайте описанието на вашето ново изображение.

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

▍Стартиране

Изображението е създадено. А това означава, че на негова основа можете да стартирате контейнер. Тъй като искам да имам достъп до приложението, работещо в контейнера на localhost:5000, i, от лявата страна на двойката 5000:5000 в следния набор от команди 5000. От дясната страна е портът на контейнера.

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

Сега, когато контейнерът е създаден и работи, можете да използвате командата docker ps за да видите информация за този контейнер (или можете да използвате командата docker ps -a, който показва информация за всички контейнери, а не само за работещите).

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

Ако сега отидете на localhost:5000 - можете да видите страницата на работещото приложение, която изглежда точно както страницата на приложението, работещо в производствената среда.

▍Присвояване и публикуване на етикети

За да използваме едно от създадените изображения на производствения сървър, трябва да можем да изтеглим това изображение от Docker Hub. Това означава, че първо трябва да създадете хранилище за проекта в Docker Hub. След това ще имаме място, където можем да изпратим изображението. Изображението трябва да бъде преименувано, така че името му да започва с нашето потребителско име на Docker Hub. Това трябва да бъде последвано от името на хранилището. Всеки таг може да бъде поставен в края на името. По-долу е даден пример за именуване на изображения според тази схема.

Сега можете да изградите изображението с ново име, присвоено му, и да изпълните командата docker push за да го изпратите в хранилището на Docker Hub.

docker build -t <username>/<repository>:<tag> .
docker tag <username>/<repository>:<tag> <username>/<repository>:latest
docker push <username>/<repository>:<tag>

# На практике это может выглядеть, например, так:
docker build -t user/app:v1.0.0 .
docker tag user/app:v1.0.0 user/app:latest
docker push user/app:v1.0.0

Ако всичко върви добре, изображението ще бъде достъпно в Docker Hub и може лесно да бъде качено на сървъра или споделено с други разработчици.

Следващи шаги

Досега сме проверили, че приложението, под формата на Docker контейнер, работи локално. Качихме контейнера в Docker Hub. Всичко това означава, че вече сме постигнали много добър напредък към нашата цел. Сега трябва да решим още два въпроса:

• Настройване на CI инструмент за тестване и внедряване на код.
• Настройване на производствения сървър, така че да може да изтегля и изпълнява нашия код.

В нашия случай, като CI / CD решение, ние използваме Травис CI. Като сървър - DigitalOcean.

Трябва да се отбележи, че тук можете да използвате друга комбинация от услуги. Например, вместо Travis CI, можете да използвате CircleCI или Github Actions. И вместо DigitalOcean - AWS или Linode.

Решихме да работим с Travis CI и вече имам нещо настроено в тази услуга. Затова сега ще говоря накратко за това как да го подготвя за работа.

Травис CI

Travis CI е инструмент за тестване и внедряване на код. Не искам да навлизам в подробности за настройката на Travis CI, тъй като всеки проект е уникален и няма да доведе до голяма полза. Но аз ще покрия основите, за да започнете, ако решите да използвате Travis CI. Каквото и да изберете - Travis CI, CircleCI, Jenkins или нещо друго, подобни методи за конфигуриране ще се прилагат навсякъде.

За да започнете с Travis CI, отидете на уебсайт на проекта и създайте акаунт. След това интегрирайте Travis CI с вашия акаунт в GitHub. Когато настройвате системата, ще трябва да посочите хранилището, което искате да автоматизирате, и да разрешите достъп до него. (Използвам GitHub, но съм сигурен, че Travis CI може да се интегрира с BitBucket, GitLab и други подобни услуги).

Всеки път, когато се стартира Travis CI, се стартира сървър, който изпълнява командите, посочени в конфигурационния файл, включително разполагане на подходящите клонове на хранилището.

▍Жизнен цикъл на работата

Конфигурационният файл на Travis CI се извиква .travis.yml и се съхранява в основната директория на проекта, поддържа концепцията за събития жизнен цикъл задачи. Ето събитията, изброени в реда, в който се случват:

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

▍Тестване

В конфигурационния файл ще настроя локален Travis CI сървър. Избрах Node 12 като език и казах на системата да инсталира зависимостите, необходими за използване на Docker.

Всичко изброено в .travis.yml, ще се изпълни на всички заявки за изтегляне към всички клонове на хранилището, освен ако не е посочено друго. Това е полезна функция, тъй като означава, че можем да тестваме целия код, който влиза в хранилището. Това ви позволява да знаете дали кодът е готов да бъде написан в клона. masterи дали ще наруши процеса на изграждане на проекта. В тази глобална конфигурация инсталирам всичко локално, стартирам Webpack dev сървъра във фонов режим (това е функция на моя работен процес) и изпълнявам тестовете.

Ако искате вашето хранилище да показва икони за покритие на кода, тук можете да намерите бърз урок за това как да използвате Jest, Travis CI и Coveralls за събиране и показване на тази информация.

И така, ето съдържанието на файла .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

Тук приключват действията, които се извършват за всички клонове на хранилището и за заявки за изтегляне.

▍Внедряване

Въз основа на предположението, че всички автоматизирани тестове са завършили успешно, можем по избор да внедрим кода на производствения сървър. Тъй като искаме да направим това само за код на клон master, ние даваме на системата съответните инструкции в настройките за разполагане. Преди да опитате да използвате кода, който ще разгледаме по-нататък във вашия проект, бих искал да ви предупредя, че трябва да имате действителен скрипт, който се извиква за внедряване.

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

Скриптът за внедряване прави две неща:

• Изграждане, маркиране и изпращане на изображението до Docker Hub с помощта на CI инструмент (в нашия случай това е Travis CI).
• Зареждане на изображението на сървъра, спиране на стария контейнер и стартиране на нов (в нашия случай сървърът работи на платформата DigitalOcean).

Първо, трябва да настроите автоматичен процес за изграждане, маркиране и изпращане на изображението към Docker Hub. Всичко това е много подобно на това, което вече направихме ръчно, с изключение на това, че тук се нуждаем от стратегия за присвояване на уникални тагове на изображения и автоматизиране на влизането. Имах затруднения с някои подробности от скрипта за внедряване, като стратегия за маркиране, влизане, кодиране на SSH ключове, установяване на SSH връзка. Но за щастие приятелят ми е много добър с баша, както и с много други неща. Той ми помогна да напиша този сценарий.

И така, първата част от скрипта изпраща изображението до Docker Hub. За да направите това е съвсем просто. Схемата за маркиране, която използвах, включва комбиниране на git хеша и git тага, ако съществува. Това гарантира, че етикетът е уникален и улеснява идентифицирането на сглобката, на която се основава. DOCKER_USERNAME и DOCKER_PASSWORD са дефинирани от потребителя променливи на средата, които могат да бъдат зададени с помощта на интерфейса Travis CI. Travis CI автоматично ще обработва чувствителни данни, така че да не попаднат в неподходящи ръце.

Ето първата част от сценария 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}

Каква ще бъде втората част от скрипта зависи изцяло от това кой хост използвате и как е организирана връзката към него. В моя случай, тъй като използвам Digital Ocean, командите се използват за свързване със сървъра доктл. Когато работите с Aws, ще се използва помощната програма awsи т.н.

Настройването на сървъра не беше особено трудно. И така, създадох капчица въз основа на основното изображение. Трябва да се отбележи, че системата, която избрах, изисква еднократно ръчно инсталиране на Docker и еднократно ръчно стартиране на Docker. Използвах Ubuntu 18.04, за да инсталирам Docker, така че ако използвате и Ubuntu, можете просто да следвате това просто ръководство.

Тук не говоря за конкретни команди за услугата, тъй като този аспект може да варира значително в различните случаи. Просто ще дам общ план за действие, който трябва да се изпълни след свързване чрез SSH към сървъра, където ще бъде внедрен проектът:

• Трябва да намерите контейнера, който работи в момента, и да го спрете.
• След това трябва да стартирате нов контейнер във фонов режим.
• Ще трябва да настроите локалния порт на сървъра на 80 - това ще ви позволи да влезете в сайта на адреса на формата example.com, без да посочвате порт, вместо да използвате адрес като example.com:5000.
• И накрая, трябва да премахнете всички стари контейнери и изображения.

Ето и продължението на сценария.

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

Някои неща, за които трябва да внимавате

Възможно е, когато се свържете към сървъра чрез SSH от Travis CI, да видите предупреждение, което няма да ви позволи да продължите с инсталацията, тъй като системата ще изчака отговора на потребителя.

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

Научих, че низ ключ може да бъде кодиран в base64, за да се съхранява във форма, в която може да се работи удобно и надеждно. На етапа на инсталиране можете да декодирате публичния ключ и да го запишете във файл known_hosts за да се отървете от горната грешка.

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

На практика тази команда може да изглежда така:

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

И ето какво издава - base64 кодиран низ:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Ето командата, спомената по-горе

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

Същият подход може да се използва с личен ключ при установяване на връзка, тъй като може да се нуждаете от личен ключ за достъп до сървъра. Когато работите с ключ, трябва само да се уверите, че той е надеждно съхранен в променливата на средата на Travis CI и че не се показва никъде.

Друго нещо, което трябва да отбележите е, че може да се наложи да стартирате целия скрипт за внедряване като един ред, например с doctl. Това може да изисква допълнителни усилия.

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

TLS/SSL и балансиране на натоварването

След като направих всичко по-горе, последният проблем, който имах, беше, че сървърът нямаше SSL. Тъй като използвам сървър Node.js, за да принудя да работи обратен прокси Nginx и Let's Encrypt, трябва да бърникате много.

Наистина не исках да правя всички тези SSL настройки ръчно, така че просто създадох балансьор на натоварването и записах информация за него в DNS. В случая на DigitalOcean, например, създаването на автоматично подновяващ се самоподписан сертификат на балансиращото натоварване е проста, безплатна и бърза процедура. Този подход има допълнителното предимство, че прави много лесно настройването на SSL на множество сървъри, работещи зад балансиращо натоварване, ако е необходимо. Това позволява на самите сървъри изобщо да не "мислят" за SSL, но в същото време да използват, както обикновено, порта 80. Така че конфигурирането на SSL на балансиращо натоварване е много по-лесно и удобно от алтернативните методи за конфигуриране на SSL.

Сега можете да затворите всички портове на сървъра, които приемат входящи връзки - с изключение на порта 80, използван за комуникация с балансиращото натоварване и порта 22 за SSH. В резултат на това опитът за директен контакт със сървъра на всеки порт, различен от тези два, ще бъде неуспешен.

Резултати от

След като направих всичко, за което говорих в тази статия, нито платформата Docker, нито концепцията за автоматизирани CI / CD вериги вече ме плашеха. Успях да настроя непрекъсната интеграционна верига, по време на която кодът се тества, преди да влезе в производство, и кодът автоматично се внедрява на сървъра. Всичко това все още е сравнително ново за мен и съм сигурен, че има начини да подобря своя автоматизиран работен процес и да го направя по-ефективен. Така че, ако имате някакви идеи по въпроса - дайте ми зная. Надявам се, че тази статия ви е помогнала във вашите начинания. Иска ми се да вярвам, че като го прочетохте, вие научихте толкова, колкото аз научих, докато се занимавах с всичко, за което разказах в него.

PS В нашата пазар има изображение докер, който се инсталира с едно кликване. Можете да проверите работата на контейнерите VPS. Всички нови клиенти получават 3 дни безплатно тестване.

Уважаеми читатели! Използвате ли CI/CD технологии във вашите проекти?

Източник: www.habr.com