Кіраўніцтва па Kubernetes, частка 1: прыкладанні, мікрасэрвісы і кантэйнеры

Па нашай просьбе Хабр стварыў хаб Kubernetes і нам прыемна размясціць першую публікацыю ў ім. Падпісвайцеся!

Kubernetes - гэта проста. Чаму ж банкі плацяць мне за працу ў гэтай сферы вялікія грошы, у той час як любы можа асвоіць гэтую тэхналогію літаральна за некалькі гадзін?

Калі вы сумняваецеся ў тым, што Kubernetes можна вывучыць так хутка - прапаную вам паспрабаваць зрабіць гэта самім. А менавіта, асвоіўшы гэты матэрыял, вы зможаце запусціць прыкладанне, заснаванае на мікрасэрвісах, у кластары Kubernetes. Я магу гэта гарантаваць, бо менавіта па такой методыцы, якая выкарыстана тут, я навучаю працы з Kubernetes нашых кліентаў. Што адрознівае гэтае кіраўніцтва ад іншых? Насамрэч - шмат усяго. Так, большасць падобных матэрыялаў пачынаецца з тлумачэння простых рэчаў - канцэпцый Kubernetes і асаблівасцяў каманды kubectl. Аўтары гэтых матэрыялаў мяркуюць, што іх чытач знаёмы з распрацоўкай прыкладанняў, з мікрасэрвісамі і з кантэйнерамі Docker. Мы ж пойдзем іншым шляхам. Спачатку раскажам аб тым, як запусціць на кампутары прыкладанне, заснаванае на мікрасэрвісах. Потым разгледзім зборку выяў кантэйнераў для кожнага мікрасэрвісу. А ўжо пасля гэтага пазнаёмімся з Kubernetes і разбяром разгортванне прыкладання, заснаванага на мікрасэрвісах, у кластары, які кіруецца Kubernetes.

Такі падыход, з паступовым набліжэннем да Kubernetes, дасць глыбіню разумення таго, што адбываецца, неабходную звычайнаму чалавеку для таго, каб зразумець тое, як проста ўсё ўладкована ў Kubernetes. Kubernetes - гэта, безумоўна, простая тэхналогія, пры ўмове, што таму, хто хоча яе асвоіць, вядома, дзе і як яна выкарыстоўваецца.

Цяпер, без лішніх слоў, прыступім да працы і пагаворым аб дадатку, з якім мы будзем працаваць.

Эксперыментальнае дадатак

Наша дадатак будзе выконваць толькі адну функцыю. Яно прымае, у якасці ўваходных дадзеных, адна прапанова, пасля чаго, выкарыстаючы сродкі аналізу тэкстаў, вырабляе аналіз танальнасці (sentiment analysis) гэтай прапановы, атрымліваючы адзнаку эмацыйнага стаўлення аўтара прапановы да нейкага аб'екта.

Вось як выглядае галоўнае акно гэтага прыкладання.

Вэб-дадатак для аналізу танальнасці тэкстаў

З тэхнічнага пункту гледжання прыкладанне складаецца з трох мікрасэрвісаў, кожны з якіх вырашае пэўны набор задач:

• SA-Frontend – вэб-сервер Nginx, які абслугоўвае статычныя файлы React.
• SA-WebApp — вэб-дадатак, напісаны на Java, які апрацоўвае запыты ад франтэнда.
• SA-Logic - Python-дадатак, якое выконвае аналіз танальнасці тэксту.

Мікрасэрвісы існуюць не ў ізаляцыі. Яны рэалізуюць ідэю "падзелу абавязкаў", але ім, пры гэтым, неабходна ўзаемадзейнічаць адзін з адным.

Патокі дадзеных у дадатку

На вышэйпрыведзенай схеме можна бачыць пранумараваныя этапы працы сістэмы, якія ілюструюць патокі даных у дадатку. Разбяром іх:

1. Браўзэр запытвае ў сервера файл index.html (які, у сваю чаргу, вырабляе загрузку пакета React-прыкладанні).
2. Карыстальнік ўзаемадзейнічае з дадаткам, гэта выклікае зварот да вэб-дадатку, заснаванаму на Spring.
3. Вэб-дадатак перанакіроўвае запыт на выкананне аналізу тэксту Python-дадатку.
4. Python-дадатак праводзіць аналіз танальнасці тэксту і вяртае вынік у выглядзе адказу на запыт.
5. Spring-дадатак адпраўляе адказ React-дадатку (а яно, у сваю чаргу, паказвае вынік аналізу тэксту карыстачу).

Код для ўсіх гэтых прыкладанняў можна знайсці тут. Рэкамендую вам прама зараз скапіяваць сабе гэты рэпазітар, бо наперадзе нас чакае шмат цікавых эксперыментаў з ім.

Запуск прыкладання, заснаванага на мікрасэрвісах, на лакальным кампутары

Для таго каб прыкладанне зарабіла, нам трэба запусціць усе тры мікрасэрвісу. Пачнем з самага сімпатычнага з іх - з фронтэнд-прыкладанні.

▍Настройка React для лакальнай распрацоўкі

Для таго каб запусціць React-дадатак, вам трэба ўсталяваць на сваім кампутары платформу Node.js і NPM. Пасля таго, як вы ўсё гэта ўсталюеце, перайдзіце, выкарыстоўваючы тэрмінал, у тэчку праекту sa-frontend і выканайце наступную каманду:

npm install

Дзякуючы выкананню гэтай каманды ў тэчку node_modules будуць загружаныя залежнасці React-прыкладанні, запісы аб якіх маюцца ў файле package.json. Пасля завяршэння загрузкі залежнасцяў у той жа тэчцы выканайце такую ​​каманду:

npm start

Вось і ўсё. Цяпер React-дадатак запушчана, доступ да яго можна атрымаць, перайшоўшы ў браўзэры па адрасе localhost:3000. Можаце што-небудзь памяняць у яго кодзе. Эфект ад гэтых змен вы тут жа ўбачыце ў браўзэры. Гэта магчыма дзякуючы так званай "гарачай" замене модуляў. Дзякуючы гэтаму фронтэнд-распрацоўка ператвараецца ў просты і прыемны занятак.

▍Падрыхтоўка React-прыкладанні да высновы ў прадакшн

Для мэт рэальнага выкарыстання React-прыкладанні нам трэба пераўтварыць яго ў набор статычных файлаў і аддаваць іх кліентам, выкарыстоўваючы вэб-сервер.

Для зборкі React-прыкладанні, зноў, выкарыстоўваючы тэрмінал, перайдзіце ў тэчку sa-frontend і выканайце наступную каманду:

npm run build

Гэта прывядзе да стварэння ў тэчцы праекта дырэкторыі build. У ёй будуць змяшчацца ўсе статычныя файлы, неабходныя для працы React-прыкладанні.

▍Абслугоўванне статычных файлаў сродкамі Nginx

Для пачатку трэба ўсталяваць і запусціць вэб-сервер Nginx. Тут можна яго загрузіць і знайсці інструкцыі па ўсталёўцы і запуску. Затым трэба скапіяваць змесціва тэчкі sa-frontend/build у тэчку [your_nginx_installation_dir]/html.

Пры такім падыходзе згенераваны падчас зборкі React-прыкладанні файл index.html будзе даступны па адрасе [your_nginx_installation_dir]/html/index.html. Гэта - файл, які, па змаўчанні, Nginx-сервер выдае пры звароце да яго. Сервер настроены на праслухоўванне порта 80, але яго можна наладзіць так, як вам трэба, адрэдагаваўшы файл [your_nginx_installation_dir]/conf/nginx.conf.

Цяпер адкрыйце браўзэр і перайдзіце па адрасе localhost:80. Вы ўбачыце старонку React-прыкладанні.

React-дадатак, якое абслугоўваецца серверам Nginx

Калі вы зараз што-небудзь уведзяце ў поле Type your sentence і націсніце на кнопку Send - нічога не адбудзецца. Але, калі зазірнуць у кансоль, тамака можна ўбачыць паведамленні пра памылкі. Для таго каб зразумець, дзе менавіта адбываюцца гэтыя памылкі, разбяром код прыкладання.

▍Аналіз кода фронтэнд-прыкладанні

Зірнуўшы на код файла App.js, мы можам убачыць, што націск на кнопку Send выклікае метад analyzeSentence(). Код гэтага метаду прыведзены ніжэй. Пры гэтым звернеце ўвагу на тое, што да кожнага радка, да якога маецца каментар выгляду # Номер, ёсць тлумачэнне, прыведзенае ніжэй кода. Такім жа чынам мы будзем разбіраць і іншыя фрагменты кода.

analyzeSentence() {
    fetch('http://localhost:8080/sentiment', {  // #1
        method: 'POST',
        headers: {
            'Content-Type': 'application/json'
        },
        body: JSON.stringify({
                       sentence: this.textField.getValue()})// #2
    })
        .then(response => response.json())
        .then(data => this.setState(data));  // #3
}

1. URL, па якім выконваецца POST-запыт. Мяркуецца, што па гэтым адрасе знаходзіцца дадатак, якое чакае падобныя запыты.

2.Цела запыту, якое адпраўляецца з дадаткам. Вось прыклад цела запыту:

{
    sentence: "I like yogobella!"
}

3.Пры атрыманні адказу на запыт ажыццяўляецца абнаўленне стану кампанента. Гэта выклікае паўторны рэндэрынгу кампанента. Калі мы атрымліваем дадзеныя (гэта значыць – JSON-аб'ект, які змяшчае ўведзеныя дадзеныя і вылічаную адзнаку тэксту), мы вывядзем кампанент Polarity, бо будуць выкананы адпаведныя ўмовы. Вось як мы апісваем кампанент:

const polarityComponent = this.state.polarity !== undefined ?
    <Polarity sentence={this.state.sentence} 
              polarity={this.state.polarity}/> :
    null;

Код, як здаецца, выглядае суцэль працаздольным. Што ж тут, усё ж, не так? Калі вы мяркуеце, што па тым адрасе, па якім прыкладанне спрабуе адправіць POST-запыт, няма пакуль нічога, што можа гэты запыт прыняць і апрацаваць, то вы будзеце абсалютна правы. У прыватнасці, для апрацоўкі запытаў, якія паступаюць па адрасе http://localhost:8080/sentiment, нам трэба запусціць вэб-дадатак, заснаваны на Spring.

Нам трэба Spring-дадатак, здольны прыняць POST-запыт

▍Настройка вэб-прыкладанні, заснаванага на Spring

Для таго каб разгарнуць Spring-дадатак, вам спатрэбіцца JDK8 і Maven і правільна настроеныя зменныя асяроддзі. Пасля таго, як вы ўсё гэта ўсталюеце, вы можаце працягваць працу над нашым праектам.

▍Упакоўка прыкладання ў jar-файл

Перайдзіце, з дапамогай тэрмінала, у тэчку sa-webapp і ўвядзіце наступную каманду:

mvn install

Пасля выканання гэтай каманды ў тэчцы sa-webapp будзе створана дырэкторыя target. Тут будзе знаходзіцца Java-дадатак, упакаваны ў jar-файл, прадстаўлены файлам. sentiment-analysis-web-0.0.1-SNAPSHOT.jar.

▍Запуск Java-прыкладанні

Перайдзіце ў тэчку target і запусціце прыкладанне наступнай камандай:

java -jar sentiment-analysis-web-0.0.1-SNAPSHOT.jar

У ходзе выканання гэтай каманды адбудзецца памылка. Для таго каб прыступіць да яе выпраўлення, мы можам прааналізаваць звесткі аб выключэнні ў дадзеных трасіроўкі стэка:

Error creating bean with name 'sentimentController': Injection of autowired dependencies failed; nested exception is java.lang.IllegalArgumentException: Could not resolve placeholder 'sa.logic.api.url' in value "${sa.logic.api.url}"

Для нас тут самае важнае - згадка аб немагчымасці высвятлення значэння sa.logic.api.url. Прааналізуем код, у якім адбываецца памылка.

▍Аналіз кода Java-прыкладанні

Вось фрагмент кода, у якім адбываецца памылка.

@CrossOrigin(origins = "*")
@RestController
public class SentimentController {
    @Value("${sa.logic.api.url}")    // #1
    private String saLogicApiUrl;
    @PostMapping("/sentiment")
    public SentimentDto sentimentAnalysis(
        @RequestBody SentenceDto sentenceDto) 
    {
        RestTemplate restTemplate = new RestTemplate();
        return restTemplate.postForEntity(
                saLogicApiUrl + "/analyse/sentiment",    // #2
                sentenceDto, SentimentDto.class)
                .getBody();
    }
}

1. У SentimentController ёсць поле saLogicApiUrl. Яго значэнне задаецца ўласцівасцю sa.logic.api.url.
2. радок saLogicApiUrl канкатэнуецца са значэннем /analyse/sentiment. Разам яны фарміруюць адрас для выканання звароту да мікрасэрвісу, які выконвае аналіз тэксту.

▍Заданне значэння ўласцівасці

У Spring стандартнай крыніцай значэнняў уласцівасцяў з'яўляецца файл application.properties, які можна знайсці па адрасе sa-webapp/src/main/resources. Але яго выкарыстанне - гэта не адзіны спосаб задання значэнняў уласцівасцяў. Зрабіць гэта можна і з дапамогай каманды наступнага выгляду:

java -jar sentiment-analysis-web-0.0.1-SNAPSHOT.jar --sa.logic.api.url=WHAT.IS.THE.SA.LOGIC.API.URL

Значэнне гэтай уласцівасці павінна паказваць на адрас нашага Python-прыкладанні.

Наладжваючы яго, мы паведамляем вэб-дадатку Spring аб тым, куды яму трэба звяртацца для выканання запытаў на аналіз тэксту.

Для таго каб не ўскладняць сабе жыццё, вырашым, што Python-дадатак будзе даступны па адрасе. localhost:5000 і пастараемся пра гэта не забыцца. У выніку каманда для запуску Spring-прыкладанні будзе выглядаць так:

java -jar sentiment-analysis-web-0.0.1-SNAPSHOT.jar --sa.logic.api.url=http://localhost:5000

У нашай сістэме не хапае Python-дадаткі

Цяпер нам засталося толькі запусціць Python-дадатак і сістэма запрацуе так, як чакаецца.

▍Настройка Python-дадаткі

Для таго каб запусціць Python-дадатак, у вас павінны быць устаноўлены Python 3 і Pip, і трэба, каб былі правільна настроены адпаведныя зменныя асяроддзі.

▍Устаноўка залежнасцяў

Перайдзіце ў тэчку праекта sa-logic/sa і выканайце наступныя каманды:

python -m pip install -r requirements.txt
python -m textblob.download_corpora

▍Запуск прыкладання

Пасля ўстаноўкі залежнасцяў мы гатовы да таго, каб запусціць прыкладанне:

python sentiment_analysis.py

Пасля выканання гэтай каманды нам паведамяць наступнае:

* Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)

Гэта азначае, што дадатак запушчана і чакае запыты па адрасе localhost:5000/

▍Даследаванне кода

Разгледзім код Python-прыкладанні для таго, каб зразумець тое, як яно рэагуе на запыты:

from textblob import TextBlob
from flask import Flask, request, jsonify
app = Flask(__name__)                                   #1
@app.route("/analyse/sentiment", methods=['POST'])      #2
def analyse_sentiment():
    sentence = request.get_json()['sentence']           #3
    polarity = TextBlob(sentence).sentences[0].polarity #4
    return jsonify(                                     #5
        sentence=sentence,
        polarity=polarity
    )
if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)                #6

1. Ініцыялізацыя аб'екта Flask.
2. Заданне адраса для выканання да яго POST-запытаў.
3. Выманне ўласцівасці sentence з цела запыту.
4. Ініцыялізацыя ананімнага аб'екта TextBlob і атрыманне значэння polarity для першага паступіўшага ў целе запыту прапановы (у нашым выпадку гэта - адзіная прапанова, якая перадаецца на аналіз).
5. Вяртанне адказу, у целе якога змяшчаецца тэкст прапановы і вылічаны для яго паказчык polarity.
6. Запуск Flask-прыкладанні, якое будзе даступна па адрасе 0.0.0.0:5000 (звярнуцца да яго можна і выкарыстоўваючы канструкцыю выгляду localhost:5000).

Цяпер мікрасэрвісы, з якіх складаецца дадатак, запушчаны. Яны настроены на ўзаемадзеянне адзін з адным. Вось як выглядае схема дадатку на дадзеным этапе працы.

Усе мікрасэрвісы, з якіх складаецца дадатак, прыведзены ў працаздольны стан

Цяпер, перш чым працягваць, адкрыйце React-дадатак у браўзэры і паспрабуйце прааналізаваць з яго дапамогай якую-небудзь прапанову. Калі ўсё зроблена правільна - пасля націску на кнопку Send вы ўбачыце пад тэкставым полем вынікі аналізу.

У наступным раздзеле мы пагаворым аб тым, як запусціць нашы мікрасэрвісы ў кантэйнерах Docker. Гэта трэба для таго, каб падрыхтаваць прыкладанне для запуску ў кластары Kubernetes.

Кантэйнеры Docker

Kubernetes - Гэта сістэма для аўтаматызацыі разгортвання, маштабавання і кіравання кантэйнерызаваны прыкладаннямі. Яе яшчэ называюць «аркестратарам кантэйнераў» (container orchestrator). Калі Kubernetes працуе з кантэйнерамі, то нам, перш чым гэтай сістэмай карыстацца, трэба спачатку гэтымі кантэйнерамі абзавесціся. Але спачатку давайце пагаворым аб тым, што такое кантэйнеры. Мабыць, лепшы адказ на пытанне аб тым, што гэта такое, можна знайсці ў дакументацыі да Docker:

Выява кантэйнера - гэта легкаважны, аўтаномны, выкананы пакет, які змяшчае нейкае прыкладанне, які складаецца з усё неабходнае для яго запуску: код прыкладання, асяроддзе выканання, сістэмныя сродкі і бібліятэкі, налады. Кантэйнерызаванымі праграмамі можна карыстацца ў асяроддзях Linux і Windows, пры гэтым яны заўсёды будуць працаваць аднолькава незалежна ад інфраструктуры.

Гэта азначае, што кантэйнеры можна запускаць на любых кампутарах, у тым ліку, на прадакшн-серверах, і ў любых асяроддзях зняволеныя ў іх прыкладанні будуць працаваць аднолькава.

Для таго каб даследаваць асаблівасці кантэйнераў і супаставіць іх з іншымі спосабамі запуску прыкладанняў, разгледзім прыклад абслугоўвання React-прыкладанні з выкарыстаннем віртуальнай машыны і кантэйнера.

▍Абслугоўванне статычных файлаў React-прыкладанні сродкамі віртуальнай машыны

Спрабуючы арганізаваць абслугоўванне статычных файлаў сродкамі віртуальных машын, мы сутыкнемся з наступнымі недахопамі:

1. Неэфектыўнае выкарыстанне рэсурсаў, бо кожная віртуальная машына ўяўляе сабой паўнавартасную аперацыйную сістэму.
2. Залежнасць ад платформы. Тое, што працуе на нейкім лакальным кампутары, цалкам можа не зарабіць на прадакшн-сэрвэры.
3. Павольнае і патрабавальнае да рэсурсаў маштабаванне рашэння, заснаванага на віртуальных машынах.

Вэб-сервер Nginx, які абслугоўвае статычныя файлы, запушчаны на віртуальнай машыне

Калі ж для рашэння аналагічнай задачы прымяніць кантэйнеры, то, у параўнанні з віртуальнымі машынамі, можна будзе адзначыць наступныя іх моцныя бакі:

1. Эфектыўнае выкарыстанне рэсурсаў: праца з аперацыйнай сістэмай з дапамогай Docker.
2. Незалежнасць ад платформы. Кантэйнер, які распрацоўшчык зможа запусціць на сваім кампутары, будзе працаваць дзе заўгодна.
3. Лёгкавагавае разгортванне за рахунак выкарыстання пластоў выяў.

Вэб-сервер Nginx, які абслугоўвае статычныя файлы, запушчаны ў кантэйнеры

Мы супаставілі віртуальныя машыны і кантэйнеры толькі па некалькіх пунктах, але нават гэтага дастаткова для таго, каб адчуць моцныя бакі кантэйнераў. Тут можна знайсці падрабязнасці аб кантэйнерах Docker.

▍Зборка выявы кантэйнера для React-прыкладанні

Асноўным будаўнічым блокам кантэйнера Docker з'яўляецца файл Dockerfile. У пачатку гэтага файла робяць запіс аб базавай выяве кантэйнера, затым туды ўключаюць паслядоўнасць інструкцый, якая паказвае на парадак стварэння кантэйнера, які будзе адпавядаць патрэбам нейкага прыкладання.

Перш чым мы зоймемся працай з файлам Dockerfile, успомнім пра тое, што мы рабілі для таго, каб падрыхтаваць файлы React-прыкладанні для выкладкі на Nginx-сервер:

1. Зборка пакета React-прыкладанні (npm run build).
2. Запуск Nginx-сервера.
3. Капіраванне змесціва дырэкторыі build з папкі праекта sa-frontend у тэчку сервера nginx/html.

Ніжэй вы зможаце ўбачыць паралелі паміж стварэннем кантэйнера і вышэйапісанымі дзеяннямі, якія выконваюцца на лакальным кампутары.

▍Падрыхтоўка файла Dockerfile для прыкладання SA-Frontend

Інструкцыі, якія будуць змяшчацца ў Dockerfile для прыкладання SA-Frontend, складаюцца ўсяго з двух каманд. Справа ў тым, што група распрацоўшчыкаў Nginx падрыхтавала базавы. вобраз для Nginx, які мы будзем выкарыстоўваць для стварэння нашага ладу. Вось тыя два крокі, якія нам трэба апісаць:

1. Асновай выявы трэба зрабіць выяву Nginx.
2. Змесціва папкі sa-frontend/build трэба скапіяваць у тэчку выявы nginx/html.

Калі перайсці ад гэтага апісання да файла Dockerfile, то выглядаць ён будзе так:

FROM nginx
COPY build /usr/share/nginx/html

Як бачыце, усё тут вельмі проста, пры гэтым змесціва файла нават апыняецца суцэль чытэльным і зразумелым. Гэты файл кажа сістэме аб тым, што трэба ўзяць выяву nginx з усім тым, што ў ім ужо маецца, і скапіяваць змесціва дырэкторыі build у дырэкторыю nginx/html.

Тут у вас можа ўзнікнуць пытанне, якое тычыцца таго, адкуль я ведаю пра тое, куды менавіта трэба капіяваць файлы з тэчкі. build, гэта значыць - адкуль узяўся шлях /usr/share/nginx/html. Насамрэч, і тут няма нічога складанага. Справа ў тым, што адпаведныя звесткі можна знайсці ў апісанні ладу.

▍Зборка выявы і загрузка яго ў рэпазітар

Перш чым мы зможам працаваць з гатовай выявай, нам трэба адправіць яго ў рэпазітар вобразаў. Для гэтага мы скарыстаемся бясплатнай хмарнай платформай для хостынгу вобразаў Docker Hub. На дадзеным этапе працы вам трэба зрабіць наступнае:

1. ўсталяваць Докер.
2. Зарэгістравацца на сайце Docker Hub.
3. Увайсці ва ўліковы запіс, выканаўшы ў тэрмінале каманду наступнага віду:

   docker login -u="$DOCKER_USERNAME" -p="$DOCKER_PASSWORD"

Цяпер трэба, з дапамогай тэрмінала, перайсці ў дырэкторыю sa-frontend і выканаць там каманду наступнага выгляду:

docker build -f Dockerfile -t $DOCKER_USER_ID/sentiment-analysis-frontend .

Тут і далей у падобных камандах $DOCKER_USER_ID трэба замяніць на ваша імя карыстальніка на Docker Hub. Напрыклад, гэтая частка каманды можа выглядаць так: rinormaloku/sentiment-analysis-frontend.

Пры гэтым дадзеную каманду можна скараціць, прыбраўшы з яе. -f Dockerfile, бо ў тэчцы, у якой мы выконваем дадзеную каманду, гэты файл ужо ёсць.

Для таго каб адправіць гатовую выяву ў рэпазітар нам спатрэбіцца такая каманда:

docker push $DOCKER_USER_ID/sentiment-analysis-frontend

Пасля яе выканання праверце спіс сваіх рэпазітароў на Docker Hub для таго, каб зразумець, ці ўдала мінула адпраўка выявы ў хмарнае сховішча.

▍Запуск кантэйнера

Цяпер хто заўгодна можа загрузіць і запусціць вобраз, вядомы як $DOCKER_USER_ID/sentiment-analysis-frontend. Для таго каб гэта зрабіць, трэба выканаць наступную паслядоўнасць каманд:

docker pull $DOCKER_USER_ID/sentiment-analysis-frontend
docker run -d -p 80:80 $DOCKER_USER_ID/sentiment-analysis-frontend

Цяпер кантэйнер запушчаны, і мы можам працягваць працу, стварыўшы іншыя патрэбныя нам выявы. Але, перш чым працягваць, давайце разбяромся з канструкцыяй 80:80, якая сустракаецца ў камандзе запуску выявы і можа здацца незразумелай.

• Першы лік 80 - Гэта нумар порта хаста (гэта значыць – лакальнага кампутара).
• Другая лічба 80 - Гэта порт кантэйнера, на які павінен быць перанакіраваны запыт.

Разгледзім наступную ілюстрацыю.

Перанакіраванне партоў

Сістэма ажыццяўляе перанакіраванне запытаў з порта <hostPort> на порт <containerPort>. Гэта значыць зварот да порта 80 кампутара перанакіроўваецца на порт 80 кантэйнера.

Бо порт 80 адкрыты на лакальным кампутары, то звярнуцца да дадатку з гэтага кампутара можна па адрасе localhost:80. Калі ж ваша сістэма не падтрымлівае Docker, прыкладанне можна запусціць на віртуальнай машыне Docker, адрас якой будзе выглядаць як <docker-machine ip>:80. Для таго каб высветліць IP-адрас віртуальнай машыны Docker, можна скарыстацца камандай docker-machine ip.

На дадзеным этапе, пасля паспяховага запуску кантэйнера фронтэнд-прыкладанні, у вас павінна быць магчымасць адкрыць яго старонку ў браўзэры.

▍Файл .dockerignore

Збіраючы вобраз прыкладання SA-Frontend, мы маглі заўважыць, што гэты працэс аказваецца вельмі павольным. Адбываецца так з-за таго, што дэману Docker павінен быць адпраўлены кантэкст зборкі выявы. Дырэкторыя, якая прадстаўляе сабой кантэкст зборкі, задаецца апошнім аргументам каманды docker build. У нашым выпадку ў канцы гэтай каманды стаіць кропка. Гэта прыводзіць да таго, што ў кантэкст зборкі ўключаецца наступная структура:

sa-frontend:
|   .dockerignore
|   Dockerfile
|   package.json
|   README.md
+---build
+---node_modules
+---public
---src

Але нам з усіх прысутных тут тэчак патрэбна толькі тэчка build. Загрузка чаго заўгодна іншага - гэта пустая трата часу. Зборку можна паскорыць, паказаўшы Docker на тое, якія дырэкторыі можна праігнараваць. Менавіта для таго, каб гэта зрабіць, нам і патрэбен файл. .dockerignore. Вам, калі вы знаёмы з файлам .gitignore, структура гэтага файла, напэўна, здасца знаёмай. У ім пералічваюцца дырэкторыі, якія сістэма зборкі выявы можа праігнараваць. У нашым выпадку змесціва гэтага файла выглядае так:

node_modules
src
public

файл .dockerignore павінен знаходзіцца ў той жа тэчцы, што і файл Dockerfile. Цяпер зборка выявы будзе займаць лічаныя секунды.

Зоймемся зараз выявай для Java-прыкладанні.

▍Зборка выявы кантэйнера для Java-прыкладанні

Ведаеце што, хоць вы ўжо вывучылі ўсё неабходнае для стварэння вобразаў кантэйнераў. Менавіта таму дадзеная частка будзе вельмі кароткім.

Адкрыйце файл Dockerfile, які знаходзіцца ў тэчцы праекта sa-webapp. Калі вы прачытаеце тэкст гэтага файла, то ў ім вам сустрэнуцца ўсяго дзве новыя канструкцыі, якія пачынаюцца з ключавых слоў ENV и EXPOSE:

ENV SA_LOGIC_API_URL http://localhost:5000
…
EXPOSE 8080

ключавое слова ENV дазваляе аб'яўляць зменныя асяроддзі ўсярэдзіне кантэйнераў Docker. У прыватнасці, у нашым выпадку яно дазваляе задаць URL для доступу да API прыкладання, які выконвае аналіз тэксту.

ключавое слова EXPOSE дазваляе паказаць Docker на тое, што порт трэба адчыніць. Мы збіраемся карыстацца гэтым портам у ходзе працы з дадаткам. Тут можна заўважыць, што ў Dockerfile для прыкладання SA-Frontend такой каманды няма. Гэта трэба толькі для мэт дакументавання, іншымі словамі, гэтая канструкцыя прызначана для таго, хто будзе чытаць Dockerfile.

Зборка выявы і адпраўка яго ў рэпазітар выглядае сапраўды гэтак жа, як у папярэднім прыкладзе. Калі ж вы пакуль не вельмі ўпэўненыя ў сваіх сілах - адпаведныя каманды можна знайсці ў файле README.md у тэчцы sa-webapp.

▍Зборка выявы кантэйнера для Python-дадатку

Калі вы зірнеце на змесціва файла Dockerfile у тэчцы sa-logic, то нічога новага для сябе вы там не знойдзеце. Каманды для зборкі выявы і адпраўкі яго ў рэпазітар таксама павінны быць ужо вам знаёмыя, але іх, як і ў выпадку з іншымі нашымі прыкладаннямі, можна знайсці ў файле README.md у тэчцы sa-logic.

▍Тэставанне кантэйнерызаваных прыкладанняў

Ці можаце вы давяраць нечаму такому, што вы не пратэставалі? Я таксама не магу. Выпрабуем нашы кантэйнеры.

1. Запусцім кантэйнер прыкладання sa-logic і наладзім яго на праслухоўванне порта 5050:

   docker run -d -p 5050:5000 $DOCKER_USER_ID/sentiment-analysis-logic

2. Запусцім кантэйнер прыкладання sa-webapp і наладзім яго на праслухоўванне порта 8080. Акрамя таго, нам трэба наладзіць порт, на якім Python-дадатак будзе чакаць запыты ад Java-прыкладанні, перапрызначыўшы зменную асяроддзі. SA_LOGIC_API_URL:

   $ docker run -d -p 8080:8080 -e SA_LOGIC_API_URL='http://<container_ip or docker machine ip>:5000' $DOCKER_USER_ID/sentiment-analysis-web-app

Для таго каб даведацца пра тое, як высветліць IP-адрас кантэйнера ці віртуальнай машыны Docker — звернецеся да файла README.

Запусцім кантэйнер прыкладання sa-frontend:

docker run -d -p 80:80 $DOCKER_USER_ID/sentiment-analysis-frontend

Цяпер усё гатова да таго, каб перайсці ў браўзэры па адрасе localhost:80 і выпрабаваць дадатак.

Звярніце ўвагу на тое, што калі вы мянялі порт для sa-webapp, або калі вы працуеце з віртуальнай машынай Docker, вам спатрэбіцца адрэдагаваць файл App.js з тэчкі sa-frontend, памяняўшы IP-адрас або нумар порта ў метадзе analyzeSentence(), падставіўшы замест састарэлых дадзеных актуальныя звесткі. Пасля гэтага трэба зноў сабраць выяву і скарыстацца ім.

Вось як выглядае схема нашага прыкладання зараз.

Мікрасэрвісы выконваюцца ў кантэйнерах

Вынікі: навошта нам кластар Kubernetes?

Толькі што мы вывучылі файлы Dockerfile, пагаварылі аб тым, як збіраць вобразы і адпраўляць іх у рэпазітар Docker. Акрамя таго, мы навучыліся паскараць зборку выяў, карыстаючыся файлам. .dockerignore. У выніку нашы мікрасэрвісы зараз выконваюцца ў кантэйнерах Docker. Тут у вас можа паўстаць суцэль апраўданае пытанне аб тым, навошта нам Kubernetes. Адказу на гэтае пытанне будзе прысвечана другая частка гэтага матэрыялу. А пакуль падумайце над наступным пытаннем:
Выкажам здагадку, што наша вэб-прыкладанне для аналізу тэкстаў стала сусветна папулярным. Кожную хвіліну да яго прыходзяць мільёны запытаў. Гэта значыць, што мікрасэрвісы sa-webapp и sa-logic будуць знаходзіцца пад вялізнай нагрузкай. Як маштабаваць кантэйнеры, у якіх выконваюцца мікрасэрвісы?

Крыніца: habr.com