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

Моите први веб-страници ги напишав кон крајот на 90-тите. Тогаш беше многу лесно да се доведат во работна состојба. Имаше Apache-сервер на некој заеднички хостинг, до овој сервер можеше да се пристапи преку FTP со пишување во линијата на прелистувачот нешто како ftp://ftp.example.com. Потоа требаше да внесете име и лозинка и да ги поставите датотеките на серверот. Имаше и други времиња, тогаш се беше поедноставно отколку сега.

Работите многу се променија во последните две децении. Локациите станаа посложени, тие мора да се соберат пред да бидат пуштени во производство. Еден единствен сервер стана многу сервери кои работат зад балансери на оптоварување, употребата на системи за контрола на верзии стана вообичаена.

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

Ако имате мал проект (во нашиот случај, проект Node.js) и би сакале да научите како да го автоматизирате распоредувањето на овој проект, додека бидете сигурни дека она што е зачувано во складиштето точно се совпаѓа со она што функционира во производството, мислам можеби ќе ве интересира овој напис.

Предуслови

Од читателот на оваа статија се очекува да има основна командна линија и знаење за скриптирање Bash. Покрај тоа, ќе му требаат сметки Тревис ЦИ и Докер центар.

Цели

Нема да кажам дека овој напис може безусловно да се нарече „водич за обука“. Ова е повеќе документ во кој зборувам за она што го научив и го опишувам процесот што ми одговара за тестирање и распоредување на кодот до производство, изведен во едно автоматизирано поминување.

Еве како на крајот изгледаше мојот работен тек.

За кодот турнат до која било гранка на складиштето освен master, се вршат следните дејства:

• Започнува изградбата на проектот на Travis CI.
• Сите тестови на единицата, интеграцијата и од крај до крај се вршат.

Само за код кој завршува во master, се прави следново:

• Сето горенаведено, плус...
• Изградба на слика на Docker врз основа на тековниот код, поставки и околина.
• Хостирање на сликата на Docker Hub.
• Поврзување со производниот сервер.
• Поставување слика од Docker Hub на серверот.
• Запрете го тековниот контејнер и започнете нов врз основа на новата слика.

Ако не знаете апсолутно ништо за Docker, сликите и контејнерите, не грижете се. Ќе ти кажам сè за тоа.

Што е CI/CD?

Кратенката CI / CD значи „континуирана интеграција / континуирано распоредување“ - „континуирана интеграција / континуирано распоредување“.

▍Континуирана интеграција

Континуирана интеграција е процес со кој програмерите се обврзуваат на главното складиште на изворниот код на проектот (обично филијала master). Во исто време, квалитетот на кодот е обезбеден преку автоматско тестирање.

▍Континуирано распоредување

Континуираното распоредување е честото автоматизирано распоредување на кодот во производството. Вториот дел од кратенката CI / CD понекогаш се открива како „континуирано доставување“ („континуирано доставување“). Ова во основа е исто како „континуирано распоредување“, но „континуирана испорака“ подразбира дека промените мора рачно да се потврдат пред да започне процесот на распоредување на проектот.

Getting Started

Апликацијата на која го совладав сето ова се вика имајте предвид. Ова е веб-проект на кој работам за правење белешки. Прво се обидов да направам JAMStack-проект или само предна апликација без сервер, со цел да се искористат предностите на стандардните опции за хостирање и распоредување на проекти што ги нуди нетолизираат. Како што растеше сложеноста на апликацијата, требаше да го креирам нејзиниот заден дел, што значеше дека ќе треба да формирам своја стратегија за автоматска интеграција и автоматско распоредување на проектот.

Во мојот случај, апликацијата е 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, треба да направите две работи:

• Намести Докер работна површина.
• Регистрирајте се за Докер центар.

После тоа, можете да проверите дали 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

докер ознака

Слика

Означување на слики

слики од докер

Слика

Прикажување листа на слики

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

Контејнер

Водење контејнер базиран на слики

докер туркање

Слика

Испраќање слика во регистарот

докер повлекување

Слика

Вчитување слика од регистарот

докер пс

Контејнер

Контејнери за наведување

докер систем кастрење

Слика/Контејнер

Отстранување на неискористени контејнери и слики

▍Dockerfile

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

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

Треба да се напомене дека немам пример апликација за овој материјал. Но, овде, за експерименти, секоја едноставна апликација Node ќе направи.

За да го користите контејнерот, ќе треба да му дадете упатства на Docker. Ова се прави преку датотека наречена Dockerfileлоциран во root директориумот на проектот. Оваа датотека, на почетокот, изгледа прилично неразбирлива.

Но, она што го содржи само опишува, во специјални команди, нешто како поставување на работна средина. Еве некои од тие команди:

• ОД — Оваа команда започнува датотека. Ја одредува основната слика од која е изграден контејнерот.
• КОПИРАЈ - Копирање датотеки од локален извор во контејнер.
• РАБОТЕН ДИРЕКТ - Поставување на работниот директориум за следните команди.
• 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> .

Откако ќе ја извршите оваа команда, можете да гледате како Докер ја гради сликата.

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, јас, на левата страна на парот 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 решение, ние користиме Тревис ЦИ. Како сервер - DigitalOcean.

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

Решивме да работиме со Travis 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 и складирани во root директориумот на проектот, го поддржува концептот на настани животен циклус задачи. Еве ги настаните, наведени по редоследот по кој се случуваат:

• 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 во позадина (ова е карактеристика на мојот работен тек) и ги извршувам тестовите.

Ако сакате вашето складиште да прикажува икони за покривање на кодови, тука можете да најдете брз туторијал за тоа како да ги користите Jest, Travis CI и комбинезони за собирање и прикажување на овие информации.

Значи, тука е содржината на датотеката .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 hash и git tag доколку постои. Ова осигурува дека ознаката е единствена и го олеснува идентификувањето на склопот на кој се базира. 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, командите се користат за поврзување со серверот doctl. Кога работите со 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 и Ајде да шифрираме, треба многу да чепкаш.

Навистина не сакав да ги правам сите овие поставки за SSL рачно, па само создадов load balancer и снимив информации за тоа во DNS. Во случајот со DigitalOcean, на пример, создавањето автоматско обновувачки самопотпишан сертификат на балансерот на оптоварување е едноставна, бесплатна и брза процедура. Овој пристап има дополнителна придобивка што го прави многу лесно поставувањето SSL на повеќе сервери кои работат зад балансерот на оптоварување доколку е потребно. Ова им овозможува на самите сервери воопшто да не „размислуваат“ за SSL, но во исто време да ја користат, како и обично, портот 80. Така, конфигурирањето на SSL на балансерот на оптоварување е многу полесно и поудобно од алтернативните методи за конфигурација на SSL.

Сега можете да ги затворите сите порти на серверот што прифаќаат дојдовни врски - освен пристаништето 80, што се користи за комуникација со балансерот на оптоварување и портата 22 за SSH. Како резултат на тоа, обидот за директно контактирање на серверот на која било друга порта освен овие две ќе пропадне.

Резултатите од

Откако направив сè за што зборував во оваа статија, ниту платформата Docker ниту концептот на автоматизирани синџири CI / CD повеќе не ме плашеа. Успеав да поставам континуиран синџир на интеграција, при што кодот се тестира пред да влезе во производство и кодот автоматски се распоредува на серверот. Сето ова е сè уште релативно ново за мене, и сигурен сум дека има начини да го подобрам мојот автоматизиран работен тек и да го направам поефикасен. Значи, ако имате какви било идеи за ова - дајте ме знае. Се надевам дека оваа статија ви помогна во вашите напори. Сакам да верувам дека читајќи го, научивте исто колку што научив јас додека се занимавав со сето она за што раскажував во него.

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

Почитувани читатели! Дали користите CI/CD технологии во вашите проекти?

Извор: www.habr.com