🥇Ghid pentru Kubernetes, partea 1: aplicații, microservicii și containere

La cererea noastră, Habr a creat un hub Kubernetes și ne bucurăm să publicăm prima noastră postare în el. Abonați-vă!

Kubernetes este simplu. De ce îmi plătesc băncile sume mari pentru a lucra în acest domeniu, în condițiile în care oricine poate învăța această tehnologie în câteva ore?

Dacă aveți îndoieli că Kubernetes poate fi învățat atât de repede, vă propun să încercați chiar voi. Asta înseamnă că, stăpânind acest material, veți putea lansa o aplicație bazată pe microservicii într-un cluster Kubernetes. Pot garanta asta, deoarece exact pe această metodă, pe care o vom folosi aici, îmi instruiesc clienții în utilizarea Kubernetes. Ce face acest ghid diferit de altele? De fapt, foarte multe. Așa că, cele mai multe dintre aceste materiale încep cu explicarea lucrurilor simple – concepte Kubernetes și particularitățile comenzii kubectl. Autorii acestor materiale consideră că cititorul lor este familiarizat cu dezvoltarea aplicațiilor, microserviciile și containerele Docker. Noi vom urma o altă cale. Mai întâi, vom vorbi despre cum să lansăm o aplicație bazată pe microservicii pe computerul personal. Apoi vom aborda construirea imaginilor containerelor pentru fiecare microserviciu. Și abia după aceea ne vom familiariza cu Kubernetes și vom discuta despre desfășurarea aplicației bazate pe microservicii într-un cluster gestionat de Kubernetes.

Această abordare, cu o apropiere graduală de Kubernetes, va oferi o profunzime a înțelegerii necesară unei persoane obișnuite pentru a înțelege cât de simplu este totul în Kubernetes. Kubernetes este, fără îndoială, o tehnologie simplă, cu condiția ca cel care dorește să o învețe să știe unde și cum se folosește.

Acum, fără alte vorbă, să trecem la lucru și să discutăm despre aplicația cu care vom lucra.

Aplicația experimentală

Aplicația noastră va îndeplini doar o funcție. Aceasta primește ca date de intrare o frază, după care, folosind instrumentele de analiză a textului, efectuează analiza sentimentului (sentiment analysis) acestei fraze, obținând o evaluare a emoțiilor autorului frazei față de un anumit obiect.

Iată cum arată fereastra principală a acestei aplicații.

Aplicație web pentru analiza tonului textelor

Din punct de vedere tehnic, aplicația constă din trei microservicii, fiecare dintre ele având un set specific de sarcini:

SA-Frontend — server web Nginx, care servește fișiere statice React.
SA-WebApp — aplicație web scrisă în Java, care procesează cereri din partea front-end-ului.
SA-Logic — aplicație Python, care efectuează analiza sentimentului textului.

Este important de menționat că microserviciile nu există în izolare. Ele implementează ideea de „separare a responsabilităților”, dar trebuie să interacționeze între ele.

Fluxurile de date în aplicație

În schema de mai sus, se pot observa etapele numerotate ale funcționării sistemului, ilustrând fluxurile de date în aplicație. Să le analizăm:

Browserul cere de la server un fișier index.html (care, la rândul său, efectuează încărcarea pachetului aplicației React).
Utilizatorul interacționează cu aplicația, ceea ce determină o apelare la aplicația web bazată pe Spring.
Aplicația web redirecționează cererea către aplicația Python pentru analiza textului.
Aplicația Python analizează sentimentul textului și returnează rezultatul ca răspuns la cerere.
Aplicația Spring trimite răspunsul aplicației React (care, la rândul său, afișează rezultatul analizei textului utilizatorului).

Codul pentru toate aceste aplicații poate fi găsit aici. Îți recomand să copiezi acest repository acum, deoarece ne așteaptă multe experimente interesante cu el.

Rularea aplicației bazate pe microservicii pe computerul local

Pentru ca aplicația să funcționeze, trebuie să lansăm toate cele trei microservicii. Să începem cu cel mai atractiv dintre ele — aplicația front-end.

▍Configurarea React pentru dezvoltare locală

Pentru a rula aplicația React, trebuie să instalezi pe computerul tău platforma Node.js și NPM. După ce ai instalat totul, deschide terminalul și navighează în folderul proiectului sa-frontend și executați următoarea comandă:

npm install

Prin executarea acestei comenzi, în folderul node_modules vor fi descărcate dependențele aplicației React, înregistrările cărora se află în fișierul package.json. După finalizarea descărcării dependențelor, în același folder, execută următoarea comandă:

npm start

Și gata. Acum aplicația React este pornită, accesând-o poți intra în browser la adresa localhost:3000. Puteți schimba ceva în codul său. Efectul acestor modificări îl veți vedea imediat în browser. Acest lucru este posibil datorită așa-numitei înlocuiri „fierbinți” a modulelor. Datorită acestui fapt, dezvoltarea frontend devine o activitate simplă și plăcută.

▍Pregătirea aplicației React pentru producție

Pentru utilizarea reală a aplicației React, trebuie să o transformăm într-un set de fișiere statice și să le livrăm clienților, folosind un server web.

Pentru a construi aplicația React, din nou, folosind terminalul, accesați folderul sa-frontend și executați următoarea comandă:

npm run build

Acest lucru va crea în folderul proiectului un director build. Acesta va conține toate fișierele statice necesare pentru funcționarea aplicației React.

▍Servirea fișierelor statice cu Nginx

Mai întâi, trebuie să instalați și să porniți serverul web Nginx. Aici îl puteți descărca și găsi instrucțiuni de instalare și pornire. Apoi, trebuie să copiați conținutul folderului sa-frontend/build în folderul [your_nginx_installation_dir]/html.

Cu această abordare, fișierul generat în timpul construcției aplicației React index.html va fi disponibil la adresa [your_nginx_installation_dir]/html/index.html. Acesta este fișierul pe care serverul Nginx îl returnează în mod implicit la accesarea sa. Serverul este configurat să asculte pe portul 80, dar poate fi configurat așa cum aveți nevoie, editând fișierul [your_nginx_installation_dir]/conf/nginx.conf.

Acum deschideți browserul și mergeți la adresa localhost:80. Veți vedea pagina aplicației React.

Aplicația React, servită de serverul Nginx

Dacă acum introduceți ceva în câmpul Type your sentence și apăsați butonul Send — nu se va întâmpla nimic. Dar, dacă verificați consola, puteți vedea mesaje de eroare. Pentru a înțelege unde apar aceste erori, să analizăm codul aplicației.

▍Analiza codului aplicației frontend

Privind codul fișierului App.js, putem vedea că apăsarea butonului Send apelează metoda analyzeSentence(). Codul acestei metode este prezentat mai jos. În același timp, rețineți că fiecare linie, care are un comentariu de tip # Номер, are o explicație prezentată mai jos de cod. La fel vom analiza și alte fragmente de cod.

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-ul la care se efectuează cererea POST. Se presupune că la această adresă se află o aplicație care așteaptă astfel de cereri.

2.Corpul cererii trimise aplicației. Iată un exemplu de corp al cererii:

{
    sentence: "I like yogobella!"
}

3.La primirea răspunsului la cerere, starea componentei este actualizată. Aceasta determină o re-randare a componentei. Dacă primim date (adică un obiect JSON care conține datele introduse și evaluarea calculată a textului), vom ieși cu componenta Polarity, deoarece vor fi respectate condițiile corespunzătoare. Iată cum descriem componenta:

const polarityComponent = this.state.polarity !== undefined ?
     :
    null;

Codul, pare, că arată funcțional. Ce ar putea fi, totuși, în neregulă? Dacă presupuiți că la adresa la care aplicația încearcă să trimită cererea POST nu este încă nimic care să primească și să proceseze această cerere, aveți dreptate. Anume, pentru a procesa cererile care vin la adresa http://localhost:8080/sentiment, trebuie să rulăm o aplicație web bazată pe Spring.

Avem nevoie de o aplicație Spring capabilă să primească cereri POST

▍Configurarea aplicației web bazate pe Spring

Pentru a desfășura aplicația Spring, aveți nevoie de JDK8 și Maven și variabile de mediu corect configurate. După ce le instalați, puteți continua lucrul la proiectul nostru.

▍Ambalarea aplicației într-un fișier jar

Accesați, folosind terminalul, folderul sa-webapp și introduceți următoarea comandă:

mvn install

După ce această comandă a fost executată, în folderul sa-webapp va fi creat un director destinația. Aici se va găsi aplicația Java ambalată într-un fișier jar, reprezentată de fișierul sentiment-analysis-web-0.0.1-SNAPSHOT.jar.

▍Rularea aplicației Java

Accesați folderul destinația și porniți aplicația cu următoarea comandă:

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

În timpul executării acestei comenzi, va apărea o eroare. Pentru a începe să o corectăm, putem analiza informațiile despre excepție din datele traseului de stivă:

Eroare la crearea bean-ului cu numele 'sentimentController': Injectarea dependențelor autowired a eșuat; excepția înrădăcinată este java.lang.IllegalArgumentException: Nu s-a putut rezolva placeholder-ul 'sa.logic.api.url' în valoarea "${sa.logic.api.url}"

Ceea ce este cel mai important pentru noi aici este menționarea imposibilității de a determina valoarea sa.logic.api.url. Vom analiza codul în care apare eroarea.

▍Analiza codului aplicației Java

Iată un fragment de cod în care apare eroarea.

@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();
    }
}

În SentimentController există un câmp saLogicApiUrl. Valoarea sa este setată prin proprietate sa.logic.api.url.
Șirul saLogicApiUrl concatenată cu valoarea /analyse/sentiment. Împreună formează adresa pentru efectuarea apelului către microserviciul care efectuează analiza textului.

▍Setarea valorii proprietății

În Spring, sursa standard a valorilor proprietăților este fișierul application.properties, care se poate găsi la adresa sa-webapp/src/main/resources. Dar utilizarea sa nu este singura metodă de a seta valorile proprietăților. Acest lucru se poate face și folosind comanda de următor tip:

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

Valoarea acestei proprietăți trebuie să indice adresa aplicației noastre Python.

Configurând-o, informăm aplicația web Spring despre unde trebuie să facă apeluri pentru a efectua cereri de analiză a textului.

Pentru a ne ușura viața, să stabilim că aplicația Python va fi disponibilă la adresa localhost:5000 și să ne amintim de acest lucru. Drept rezultat, comanda pentru a lansa aplicația Spring va arăta astfel:

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

În sistemul nostru lipsește aplicația Python

Acum rămâne doar să lansezi aplicația Python și sistemul va funcționa așa cum este de așteptat.

▍Configurarea aplicației Python

Pentru a lansa aplicația Python, trebuie să ai instalat Python 3 și Pip, și trebuie să fie setate corect variabilele de mediu corespunzătoare.

▍Instalarea dependențelor

Accesați folderul proiectului sa-logic/sa și rulați următoarele comenzi:

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

▍Lansarea aplicației

După instalarea dependențelor, suntem pregătiți să lansăm aplicația:

python sentiment_analysis.py

După executarea acestui comandament, ne va fi raportat următoarea informație:

* Se rulează pe http://0.0.0.0:5000/ (Apăsați CTRL+C pentru a opri)

Aceasta înseamnă că aplicația este pornită și așteaptă cereri la adresa localhost:5000/

▍Examinarea codului

Să analizăm codul aplicației Python pentru a înțelege cum reacționează la cereri:

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

Inițializarea obiectului Flask.
Setarea adresei pentru a executa cereri POST către acesta.
Extrage proprietatea sentence din corpul cererii.
Inițializarea unui obiect anonim TextBlob și obținerea valorii polarity pentru prima propoziție primită în corpul cererii (în cazul nostru, este o singură propoziție transmisă pentru analiză).
Returnarea răspunsului, în corpul căruia se află textul propoziției și indicatorul calculat pentru aceasta polarity.
Pornirea aplicației Flask, care va fi disponibilă la adresa 0.0.0.0:5000 (poate fi accesată și utilizând o construcție de tipul localhost:5000).

Acum, microservicii, din care constă aplicația, sunt pornite. Acestea sunt configurate pentru a interacționa între ele. Iată cum arată schema aplicației în această etapă de lucru.

Toate microserviciile, din care constă aplicația, au fost aduse într-o stare funcțională

Acum, înainte de a continua, deschideți aplicația React în browser și încercați să analizați vre-o propoziție cu ajutorul ei. Dacă totul a fost făcut corect - după apăsarea butonului Send veți vedea rezultatele analizei sub câmpul de text.

În secțiunea următoare, vom discuta despre cum să lansăm microserviciile noastre în containere Docker. Acest lucru este necesar pentru a pregăti aplicația pentru lansare într-un cluster Kubernetes.

Containere Docker

Kubernetes — este un sistem pentru automatizarea desfășurării, scalării și gestionării aplicațiilor containerizate. Este cunoscut și sub numele de „orchestrator de containere” (container orchestrator). Dacă Kubernetes lucrează cu containere, atunci, înainte de a utiliza acest sistem, trebuie mai întâi să ne asigurăm de aceste containere. Dar mai întâi să discutăm despre ce sunt containerele. Poate că cel mai bun răspuns la întrebarea despre ceea ce sunt poate fi găsit în documentation Docker:

Imaginea de container este un pachet autonom, executabil și ușor, care conține o aplicație și include tot ce este necesar pentru a o rula: codul aplicației, mediul de execuție, instrumentele și bibliotecile de sistem, configurările. Aplicațiile containerizate pot fi utilizate în medii Linux și Windows, funcționând tot timpul la fel, indiferent de infrastructură.

Aceasta înseamnă că containerele pot fi rulate pe orice computer, inclusiv pe servere de producție, iar aplicațiile închise în ele vor funcționa la fel în orice mediu.

Pentru a explora caracteristicile containerelor și a le compara cu alte moduri de desfășurare a aplicațiilor, vom examina un exemplu de gestionare a unei aplicații React folosind o mașină virtuală și un container.

▍Gestionarea fișierelor statice ale aplicației React folosind o mașină virtuală

Încercând să organizăm gestionarea fișierelor statice cu ajutorul mașinilor virtuale, ne vom confrunta cu următoarele dezavantaje:

Utilizarea ineficientă a resurselor, deoarece fiecare mașină virtuală reprezintă un sistem de operare complet.
Dependenta de platformă. Ceea ce funcționează pe un anumit computer local poate să nu funcționeze pe un server de producție.
Scalarea lentă și consumatoare de resurse a unei soluții bazate pe mașini virtuale.

Serverul web Nginx, care servește fișiere statice, rulat pe o mașină virtuală

Dacă, totuși, pentru a rezolva o problemă similară se aplică containere, atunci, comparativ cu mașinile virtuale, se pot observa următoarele avantaje ale acestora:

Utilizarea eficientă a resurselor: lucrul cu sistemul de operare prin intermediul Docker.
Independență față de platformă. Un container pe care dezvoltatorul îl poate rula pe propriul computer va funcționa oriunde.
Dezvoltare ușoară prin utilizarea straturilor imaginii.

Serverul web Nginx, care servește fișiere statice, rulat într-un container.

Am comparat mașinile virtuale și containerele doar în câteva puncte, dar chiar și asta este suficient pentru a simți avantajele clare ale containerelor. Aici puteți găsi detalii despre containerele Docker.

▍Construirea imaginii containerului pentru aplicația React

Blocul de bază al unui container Docker este un fișier Dockerfile. La începutul acestui fișier se face o înregistrare despre imaginea de bază a containerului, apoi se include o secvență de instrucțiuni care indică ordinea creării containerului, care va corespunde nevoilor unei aplicații.

Înainte de a începe lucrul cu fișierul Dockerfile, să ne amintim ce am făcut pentru a pregăti fișierele aplicației React pentru implementarea pe serverul Nginx:

Construirea pachetului aplicației React (npm run build).
Pornirea serverului Nginx.
Copierea conținutului directorului build din folderul proiectului sa-frontend în folderul serverului nginx/html.

Mai jos puteți vedea paralele între crearea unui container și acțiunile descrise mai sus, efectuate pe computerul local.

▍Pregătirea fișierului Dockerfile pentru aplicația SA-Frontend

Instrucțiunile care vor fi incluse în Dockerfile pentru aplicația SA-Frontend, constau din doar două comenzi. Motivul este că un grup de dezvoltatori Nginx a pregătit o bază imagine pentru Nginx, pe care o vom folosi pentru a crea imaginea noastră. Iată cele două pași pe care trebuie să îi descriem:

Imaginea de bază trebuie să fie imaginea Nginx.
Conținutul folderului sa-frontend/build trebuie copiat în folderul imaginii nginx/html.

Dacă trecem de la această descriere la fișierul Dockerfile, va arăta astfel:

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

După cum vedeți, totul este foarte simplu, iar conținutul fișierului este de fapt destul de lizibil și clar. Acest fișier le spune sistemului să ia imaginea nginx cu tot ceea ce conține deja și să copieze conținutul directorului build în directorul nginx/html.

Aici s-ar putea să vă vină o întrebare legată de unde știu unde trebuie copiate fișierele din folderul build, adică — de unde provine calea /usr/share/nginx/html. De fapt, și aici nu este nimic complicat. Este vorba că informațiile corespunzătoare pot fi găsite în descriere imagine.

▍Crearea imaginii și încărcarea acesteia în depozit

Înainte de a putea lucra cu imaginea gata, trebuie să o trimitem în depozitul de imagini. Pentru aceasta, vom folosi platforma gratuită de cloud pentru găzduirea imaginilor Docker Hub. În această etapă a procesului, trebuie să faceți următoarele:

Instalează Docker.
Să vă înregistrați pe site-ul Docker Hub.
Conectați-vă la cont, executând în terminal comanda de tip:
```
docker login -u="$DOCKER_USERNAME" -p="$DOCKER_PASSWORD"
```

Acum trebuie, folosind terminalul, să navigați în directorul sa-frontend și să executați acolo comanda de tip:

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

Aici și în continuare în comenzi similare $DOCKER_USER_ID trebuie înlocuit cu numele dumneavoastră de utilizator pe Docker Hub. De exemplu, această parte a comenzii ar putea arăta astfel: rinormaloku/sentiment-analysis-frontend.

De asemenea, această comandă poate fi scurtată, eliminând din ea -f Dockerfile, deoarece în folderul în care executăm această comandă, acest fișier este deja prezent.

Pentru a trimite imaginea gata în depozit, avem nevoie de următoarea comandă:

docker push $DOCKER_USER_ID/sentiment-analysis-frontend

După ce ați executat-o, verificați lista depozitelor dumneavoastră pe Docker Hub pentru a vedea dacă trimiterea imaginii în stocarea cloud a fost reușită.

▍Lansarea containerului

Acum oricine poate descărca și lansa imaginea cunoscută sub numele de $DOCKER_USER_ID/sentiment-analysis-frontend. Pentru a face acest lucru, trebuie să executați următoarea secvență de comenzi:

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

Acum containerul este lansat și putem continua munca, creând alte imagini de care avem nevoie. Dar, înainte de a continua, să analizăm structura 80:80, care apare în comanda de lansare a imaginii și ar putea părea neclară.

Primul număr 80 este numărul portului gazdei (adică - al computerului local).
Al doilea număr 80 este portul containerului pe care trebuie redirecționat cererea.

Să luăm în considerare următoarea ilustrație.

Redirecționarea porturilor

Sistemul redirecționează cererile de la portul <hostPort> la portul <containerPort>. Adică, o solicitare către portul 80 computerului este redirecționată către portul 80 containerului.

Deoarece portul 80 este deschis pe computerul local, puteți accesa aplicația de pe acest computer la adresa localhost:80. Dacă sistemul dumneavoastră nu suportă Docker, aplicația poate fi rulată pe o mașină virtuală Docker, a cărei adresă va arăta ca :80. Pentru a stabili adresa IP a mașinii virtuale Docker, puteți utiliza comanda docker-machine ip.

În această etapă, după ce containerul aplicației frontend s-a lansat cu succes, ar trebui să aveți posibilitatea de a deschide pagina sa în browser.

▍Fișierul .dockerignore

Când construim imaginea aplicației SA-Frontend, am putea observa că acest proces devine extrem de lent. Acest lucru se întâmplă deoarece demontajului Docker i se trimite contextul de construire a imaginii. Directorul, care reprezintă contextul de construire, este specificat ca ultimul argument al comenzii docker build. În cazul nostru, la sfârșitul acestei comenzi se află un punct. Aceasta face ca următoarea structură să fie inclusă în contextul de construire:

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

Dar din toate folderele prezente aici, avem nevoie doar de folderul build. Încărcarea oricărui altceva este o pierdere de timp. Putem accelera construcția indicând Docker ce directoare pot fi ignorate. Din acest motiv, avem nevoie de fișierul .dockerignore. Dacă sunteți familiarizat cu fișierul .gitignore, structura acestuia vă va părea familiară. Acesta enumeră directoarele pe care sistemul de construire a imaginii le poate ignora. În cazul nostru, conținutul acestui fișier arată astfel:

node_modules
src
public

Fișier .dockerignore trebuie să se afle în același director cu fișierul Dockerfile. Acum construirea imaginii va dura câteva secunde.

Acum să ne ocupăm de imaginea pentru aplicația Java.

▍Construirea imaginii containerului pentru aplicația Java

Știți ce, deja ați studiat tot ce este necesar pentru a crea imagini pentru containere. De aceea, această secțiune va fi destul de scurtă.

Deschideți fișierul Dockerfile, care se află în directorul proiectului sa-webapp. Dacă citiți textul acestui fișier, veți întâlni doar două construcții noi, care încep cu cuvintele cheie ENV și EXPOSE:

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

Cuvântul cheie ENV permite declararea variabilelor de mediu în interiorul containerelor Docker. În special, în cazul nostru, acesta permite stabilirea URL-ului pentru accesarea API-ului aplicației care efectuează analiza textului.

Cuvântul cheie EXPOSE permite instructarea Docker-ului că portul trebuie deschis. Vom folosi acest port pe durata lucrului cu aplicația. Aici se poate observa că Dockerfile pentru aplicația SA-Frontend această comandă nu există. Este necesară doar în scopuri de documentare, cu alte cuvinte, această structură este destinată celor care vor citi Dockerfile.

Construirea imaginii și trimiterea acesteia în depozit arată exact ca în exemplul anterior. Dacă nu sunteți foarte sigur de abilitățile dumneavoastră, se pot găsi comenzile corespunzătoare în fișierul README.md din folderul sa-webapp.

▍Construirea imaginii containerului pentru aplicația Python

Dacă priviți conținutul fișierului Dockerfile din folderul sa-logic, nu veți găsi nimic nou. Comenzile pentru construirea imaginii și trimiterea ei în depot ar trebui să vă fie deja cunoscute, dar, la fel ca și în cazul altor aplicații ale noastre, le puteți găsi în fișierul README.md din folderul sa-logic.

▍Testarea aplicațiilor containerizate

Puteți avea încredere într-un lucru pe care nu l-ați testat? Nici eu nu pot. Să testăm containerele noastre.

Să pornim containerul aplicației sa-logic și să-l configurăm să asculte pe portul 5050:
```
docker run -d -p 5050:5000 $DOCKER_USER_ID/sentiment-analysis-logic
```
Să pornim containerul aplicației sa-webapp și să-l configurăm să asculte pe portul 8080. În plus, trebuie să configurăm portul pe care aplicația Python va aștepta cererile de la aplicația Java, redefinind variabila de mediu SA_LOGIC_API_URL:
```
$ docker run -d -p 8080:8080 -e SA_LOGIC_API_URL='http://:5000' $DOCKER_USER_ID/sentiment-analysis-web-app
```

Pentru a afla cum să determinați adresa IP a containerului sau a mașinii virtuale Docker, consultați fișierul README.

Să pornim containerul aplicației sa-frontend:

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

Acum totul este pregătit pentru a accesa aplicația în browser la adresa localhost:80 și a testa aplicația.

Vă rugăm să rețineți că, dacă ați schimbat portul pentru sa-webapp, sau dacă lucrați cu o mașină virtuală Docker, va trebui să editați fișierul App.js din folder sa-frontend, modificând adresa IP sau numărul portului în metoda analyzeSentence(), înlocuind datele învechite cu informații actuale. După aceea, va trebui să reconstruiți imaginea și să o utilizați.

Iată cum arată acum schema aplicației noastre.

Microserviciile rulează în containere

Concluzii: de ce avem nevoie de un cluster Kubernetes?

Tocmai am studiat fișierele Dockerfile, am discutat despre cum să construim imagini și să le trimitem în depozitul Docker. În plus, am învățat să accelerăm construirea imaginilor folosind fișierul .dockerignore. În cele din urmă, microserviciile noastre sunt acum implementate în containere Docker. Aici poate apărea o întrebare validă despre ce ne trebuie Kubernetes. Răspunsul la această întrebare va fi dedicat părții a doua a acestui material. Între timp, gândiți-vă la următoarea întrebare:
Să presupunem că aplicația noastră web pentru analiza de texte a devenit extrem de populară. În fiecare minut, primește milioane de solicitări. Aceasta înseamnă că microserviciile sa-webapp și sa-logic vor fi supuse unei încărcări uriașe. Cum putem scala containerele în care sunt rulate microserviciile?

Sursa: habr.com