Креирање ЦИ/ЦД ланца и аутоматизација рада са Доцкер-ом

Своје прве веб странице написао сам касних 90-их. Тада их је било врло лако довести у радно стање. Постојао је Апацхе сервер на неком дељеном хостингу, можете се пријавити на овај сервер преко ФТП-а тако што ћете написати нешто попут ftp://ftp.example.com. Затим сте морали да унесете своје име и лозинку и отпремите датотеке на сервер. Била су другачија времена, тада је све било једноставније него сада.

За две деценије од тада све се много променило. Веб локације су постале сложеније; морају се склопити пре пуштања у производњу. Један сервер је постао много сервера који раде иза балансера оптерећења, а употреба система за контролу верзија постала је уобичајена.

За свој лични пројекат имао сам посебну конфигурацију. И знао сам да ми је потребна могућност да инсталирам локацију у продукцији изводећи само једну радњу: писање кода у грану master на ГитХуб-у. Осим тога, знао сам да, како бих осигурао рад своје мале веб апликације, не желим да управљам огромним Кубернетес кластером, нити да користим Доцкер Сварм технологију, нити да одржавам флоту сервера са подовима, агентима и свим врстама других сложености. Да бих постигао циљ да што лакше олакшам рад, морао сам да се упознам са ЦИ/ЦД.

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

Предуслови

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

Мете

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

Овако је завршио мој радни ток.

За код постављен у било коју грану спремишта осим master, извршавају се следеће радње:

• Почиње пројекат изграђен на Травис ЦИ.
• Сви тестови јединице, интеграције и енд-то-енд тестови се изводе.

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

• Све горе поменуто, плус...
• Прављење Доцкер слике на основу тренутног кода, подешавања и окружења.
• Постављање слике у Доцкер Хуб.
• Веза са производним сервером.
• Отпремање слике са Доцкер Хуб-а на сервер.
• Заустављање тренутног контејнера и покретање новог на основу нове слике.

Ако не знате апсолутно ништа о Доцкер-у, сликама и контејнерима, не брините. Рећи ћу ти све о томе.

Шта је ЦИ/ЦД?

Скраћеница ЦИ/ЦД значи „континуирана интеграција/непрекидна примена“.

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

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

▍Непрекидна примена

Континуирана примена је често, аутоматизовано увођење кода у производњу. Други део акронима ЦИ/ЦД понекад се наводи као „континуирана испорука“. Ово је у основи исто што и „континуирана примена“, али „континуирана испорука“ подразумева потребу да се промене ручно потврде пре почетка процеса имплементације пројекта.

Први кораци

Апликација коју сам користио да научим све ово се зове Узети на знање. Ово је веб пројекат на којем радим, дизајниран за вођење белешки. У почетку сам покушао да урадим ЈАМСтацк-пројекат, или само фронт-енд апликација без сервера, како би се искористиле предности стандардног хостинга и могућности имплементације пројекта које нуди Нетлифи. Како је комплексност апликације расла, морао сам да креирам њен серверски део, што је значило да ћу морати да формулишем сопствену стратегију за аутоматизовану интеграцију и аутоматизовано постављање пројекта.

У мом случају, апликација је Екпресс сервер који ради у окружењу Ноде.јс, који опслужује Реацт апликацију на једној страници и подржава безбедни АПИ на страни сервера. Ова архитектура прати стратегију која се може наћи у ово Водич за аутентификацију пуног стека.

консултовао сам се са пријатељу, који је стручњак за аутоматизацију, и питао га шта треба да урадим да би све функционисало како сам желео. Дао ми је идеју како би аутоматизовани ток посла требао изгледати, наведено у одељку Циљеви овог чланка. Имати ове циљеве значило је да морам да схватим како да користим Доцкер.

лучки радник

Доцкер је алатка која, захваљујући технологији контејнеризације, омогућава лаку дистрибуцију, примену и покретање апликација у истом окружењу, чак и ако сама Доцкер платформа ради у различитим окружењима. Прво, морао сам да се дочепам Доцкер алата командне линије (ЦЛИ). упутство Водич за инсталацију Доцкер-а се не може назвати врло јасним и разумљивим, али из њега можете научити да да бисте предузели први корак инсталације, морате преузети Доцкер Десктоп (за Мац или Виндовс).

Доцкер Хуб је отприлике иста ствар као ГитХуб за гит спремишта или регистар нпм за ЈаваСцрипт пакете. Ово је онлајн спремиште за Доцкер слике. Ово је оно на шта се Доцкер Десктоп повезује.

Дакле, да бисте започели са Доцкер-ом, морате да урадите две ствари:

• Сет Доцкер Десктоп.
• Регистрацију за Доцкер Хуб.

Након овога, можете проверити да ли Доцкер ЦЛИ ради тако што ћете покренути следећу команду да бисте проверили верзију Доцкер-а:

docker -v

Затим се пријавите на Доцкер Хуб тако што ћете унети своје корисничко име и лозинку када се то од вас затражи:

docker login

Да бисте користили Доцкер, морате разумети концепте слика и контејнера.

▍Слике

Слика је нешто попут нацрта који садржи упутства за састављање контејнера. Ово је непроменљиви снимак система датотека и подешавања апликације. Програмери могу лако да деле слике.

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

Ова команда ће дати табелу са следећим заглављем:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

Затим ћемо погледати неке примере команди у истом формату – прво постоји команда са коментаром, а затим пример онога што може да избаци.

▍контејнери

Контејнер је извршни пакет који садржи све што је потребно за покретање апликације. Апликација са овим приступом ће увек радити исто, без обзира на инфраструктуру: у изолованом окружењу и у истом окружењу. Поента је да се инстанце исте слике покрећу у различитим окружењима.

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

▍Тагс

Ознака је индикација одређене верзије слике.

▍Брзо упућивање на Доцкер команде

Ево прегледа неких најчешће коришћених Доцкер команди.

Тим

Контекст

дејство

доцкер буилд

Имаге

Прављење слике из Доцкерфиле-а

доцкер таг

Имаге

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

доцкер слике

Имаге

Листинг имагес

доцкер рун

Контејнер

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

доцкер пусх

Имаге

Учитавање слике у регистар

доцкер пулл

Имаге

Учитавање слике из регистра

доцкер пс

Контејнер

Листинг контејнера

доцкер систем пруне

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

Уклањање неискоришћених контејнера и слика

▍Доцкерфиле

Знам како да покренем производну апликацију локално. Имам конфигурацију Вебпацк-а дизајнирану да направи готову Реацт апликацију. Затим, имам команду која покреће сервер заснован на Ноде.јс на порту 5000. изгледа овако:

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

Треба напоменути да немам пример апликације за овај материјал. Али овде, за експерименте, било која једноставна Ноде апликација ће послужити.

Да бисте користили контејнер, мораћете да дате упутства Доцкер-у. Ово се ради преко датотеке под називом Dockerfile, који се налази у основном директоријуму пројекта. Ова датотека, на први поглед, изгледа прилично неразумљива.

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

• ИЗ — Ова команда покреће датотеку. Он одређује основну слику на којој је контејнер изграђен.
• КОПИЈА — Копирање датотека из локалног извора у контејнер.
• ВОРКДИР — Подешавање радног именика за следеће команде.
• ТРЧАЊЕ - Покрени команде.
• ЕКСПОСЕ — Подешавања порта.
• УЛАЗНА ТАЧКА — Индикација команде која треба да се изврши.

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

У зависности од основне слике коју одаберете, можда ћете морати да инсталирате додатне зависности. Чињеница је да су неке основне слике (као што је Ноде Алпине Линук) креиране са циљем да буду што компактније. Као резултат тога, можда неће имати неке од програма које очекујете.

▍Изградња, означавање и покретање контејнера

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

▍Састављање

Прво треба да сакупите имаге, наводећи име и, опционо, ознаку (ако ознака није наведена, систем ће аутоматски доделити ознаку слици 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 push да га гурнете у Доцкер Хуб спремиште.

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

Ако све прође како треба, слика ће бити доступна на Доцкер Хуб-у и лако се може отпремити на сервер или пренети другим програмерима.

Следећи кораци

До сада смо потврдили да апликација, у облику Доцкер контејнера, ради локално. Пребацили смо контејнер у Доцкер Хуб. Све то значи да смо већ веома добро напредовали ка нашем циљу. Сада треба да решимо још два питања:

• Подешавање ЦИ алата за тестирање и примену кода.
• Подешавање производног сервера тако да може да преузме и покрене наш код.

У нашем случају користимо Травис ЦИ. Као сервер - ДитигалОцеан.

Треба напоменути да овде можете користити другу комбинацију услуга. На пример, уместо Травис ЦИ, можете користити ЦирцлеЦИ или Гитхуб Ацтионс. И уместо ДигиталОцеана - АВС или Линоде.

Одлучили смо да радимо са Травис ЦИ, а ја већ имам нешто конфигурисано у овој услузи. Стога ћу сада укратко говорити о томе како га припремити за рад.

Травис ЦИ

Травис ЦИ је алат за тестирање и примену кода. Не бих желео да улазим у замршености подешавања Травис ЦИ, пошто је сваки пројекат јединствен и то неће донети много користи. Али ја ћу покрити основе да бисте започели ако одлучите да користите Травис ЦИ. Било да изаберете Травис ЦИ, ЦирцлеЦИ, Јенкинс или нешто друго, сличне методе конфигурисања ће се користити свуда.

Да бисте започели са Травис ЦИ, идите на сајт проекта и направите налог. Затим интегришите Травис ЦИ са својим ГитХуб налогом. Приликом подешавања система, мораћете да наведете спремиште са којим желите да аутоматизујете рад и омогућите приступ њему. (Користим ГитХуб, али сам сигуран да Травис ЦИ може да се интегрише са БитБуцкет-ом, ГитЛаб-ом и другим сличним сервисима).

Сваки пут када се Травис ЦИ покрене, сервер се покреће, извршавајући команде наведене у конфигурационој датотеци, укључујући постављање одговарајућих грана спремишта.

▍Животни циклус посла

Травис ЦИ конфигурациона датотека зове се .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

▍Тестирање

У конфигурационој датотеци ћу конфигурисати локални Травис ЦИ сервер. Изабрао сам Ноде 12 као језик и рекао систему да инсталира зависности потребне за коришћење Доцкер-а.

Све што је наведено у .travis.yml, биће извршено када су сви захтеви за повлачење упућени свим гранама спремишта, осим ако није другачије назначено. Ово је корисна функција јер значи да можемо тестирати сав код који долази у спремиште. Ово вам даје до знања да ли је код спреман за писање у грану. master, и да ли ће то прекинути процес изградње пројекта. У овој глобалној конфигурацији, све инсталирам локално, покрећем Вебпацк дев сервер у позадини (ово је карактеристика мог тока посла) и покрећем тестове.

Ако желите да ваше спремиште приказује значке које указују на покривеност тестом, овде Можете пронаћи кратка упутства о коришћењу Јест, Травис ЦИ и комбинезона за прикупљање и приказивање ових информација.

Дакле, ево садржаја датотеке .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_USERNAME и DOCKER_PASSWORD су променљиве корисничког окружења које се могу подесити помоћу Травис ЦИ интерфејса. Травис ЦИ ће аутоматски обрадити осетљиве податке како не би доспели у погрешне руке.

Ево првог дела сценарија 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}

Какав ће бити други део скрипте зависи у потпуности од тога који хост користите и како је веза са њим организована. У мом случају, пошто користим Дигитал Оцеан, користим команде за повезивање са сервером доцтл. Када радите са АВС-ом, користиће се услужни програм aws, и тако даље.

Подешавање сервера није било посебно тешко. Дакле, поставио сам капљицу на основу основне слике. Треба напоменути да систем који сам изабрао захтева једнократну ручну инсталацију Доцкер-а и једнократно ручно покретање Доцкер-а. Користио сам Убунту 18.04 да инсталирам Доцкер, тако да ако и ви користите Убунту да урадите исто, можете само да пратите ово једноставан водич.

Овде не говорим о специфичним командама за услугу, пошто овај аспект може значајно да варира у различитим случајевима. Даћу само општи план акције које треба извршити након повезивања преко ССХ-а на сервер на коме ће пројекат бити распоређен:

• Морамо пронаћи контејнер који тренутно ради и зауставити га.
• Затим морате покренути нови контејнер у позадини.
• Мораћете да подесите локални порт сервера на 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

Неке ствари на које треба обратити пажњу

Могуће је да када се повежете са сервером преко ССХ-а са Травис ЦИ-а, видећете упозорење које ће вас спречити да наставите са инсталацијом јер ће систем чекати на одговор корисника.

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

Научио сам да се стринг кључ може кодирати у басе64 како би се сачувао у облику у којем се може лако и поуздано радити. У фази инсталације, можете декодирати јавни кључ и записати га у датотеку 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

А ево шта производи - басе64 кодирани стринг:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Ево горе поменуте команде

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

Исти приступ се може користити са приватним кључем приликом успостављања везе, пошто ће вам можда требати приватни кључ за приступ серверу. Када радите са кључем, само треба да се уверите да је он безбедно ускладиштен у Травис ЦИ променљивој окружења и да се нигде не приказује.

Још једна ствар коју треба напоменути је да ћете можда морати да покренете целу скрипту за примену као једну линију, на пример - са doctl. Ово може захтевати додатни напор.

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

ТЛС/ССЛ и балансирање оптерећења

Након што сам урадио све горе наведено, последњи проблем на који сам наишао је тај што сервер није имао ССЛ. Пошто користим Ноде.јс сервер, да бих форсирао на посао обрнути прокси Нгинк и Лет'с Енцрипт, морате много да петљате.

Заиста нисам желео да све ову ССЛ конфигурацију радим ручно, па сам само направио балансатор оптерећења и снимио његове детаље у ДНС. У случају ДигиталОцеан-а, на пример, креирање самопотписаног сертификата који се аутоматски обнавља на балансеру оптерећења је једноставна, бесплатна и брза процедура. Овај приступ има додатну предност што олакшава постављање ССЛ-а на више сервера који раде иза балансера оптерећења ако је потребно. Ово омогућава самим серверима да уопште не „размишљају“ о ССЛ-у, али да истовремено користе порт као и обично 80. Дакле, подешавање ССЛ-а на балансеру оптерећења је много лакше и практичније од алтернативних метода подешавања ССЛ-а.

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

Резултати

Након што сам урадио све о чему сам говорио у овом материјалу, више ме нису плашили ни Доцкер платформа ни концепти аутоматизованих ЦИ/ЦД ланаца. Успео сам да поставим континуирани ланац интеграције, током којег се код тестира пре него што крене у производњу и код се аутоматски поставља на сервер. Све ово је за мене још увек релативно ново и сигуран сам да постоје начини да побољшам свој аутоматизовани ток посла и учиним га ефикаснијим. Дакле, ако имате било какву идеју о овом питању, јавите ми. мене знам. Надам се да вам је овај чланак помогао у вашим настојањима. Желим да верујем да сте након читања научили онолико колико сам ја научио док сам схватио све о чему сам у њему говорио.

ПС У нашем маркетплаце постоји слика лучки радник, који се може инсталирати једним кликом. Можете проверити рад контејнера на ВПС. Свим новим клијентима се даје 3 дана тестирања бесплатно.

Драги читаоци! Да ли користите ЦИ/ЦД технологије у својим пројектима?

Извор: ввв.хабр.цом