Kubernetes-handbok, del 1: applikationer, mikrotjänster och containrar

På vår begäran skapade Habr en hub Kubernetes och vi är glada att publicera det första inlägget där. Prenumerera!

Kubernetes är enkelt. Varför betalar banker mig då stora summor för att arbeta inom detta område, när vem som helst kan lära sig denna teknik på bara några timmar?

Om du tvivlar på att Kubernetes kan läras så snabbt — försök att göra det själv. Genom att bemästra detta material kan du starta en applikation som bygger på mikrotjänster i en Kubernetes-kluster. Jag kan garantera detta, eftersom det är just den metodik som används här som jag utbildar våra kunder i Kubernetes. Vad skiljer denna handbok från andra? Faktum är att det är mycket. De flesta liknande material börjar med att förklara enkla saker — koncepten i Kubernetes och funktionerna i kommandot kubectl. Författarna till dessa material anser att deras läsare är bekanta med applikationsutveckling, mikrotjänster och Docker-containrar. Vi kommer att ta en annan väg. Först kommer vi att berätta hur man startar en applikation som bygger på mikrotjänster på datorn. Sedan kommer vi att se på byggandet av containerbilder för varje mikrotjänst. Och först därefter ska vi lära oss om Kubernetes och granska utrullningen av en applikation som bygger på mikrotjänster i en Kubernetes-styrd kluster.

Denna metod, med en gradvis närmanden till Kubernetes, ger en djup förståelse för vad som händer, vilket är nödvändigt för en vanlig person för att förstå hur enkelt allt är strukturerat i Kubernetes. Kubernetes är utan tvekan en enkel teknologi, förutsatt att den som vill bemästra den vet var och hur den används.

Nu, utan fler ord, låt oss börja arbetet och tala om applikationen vi kommer att arbeta med.

Experimentell applikation

Vår applikation kommer att utföra en enda funktion. Den tar som indata en mening, och efter det, med hjälp av textanalysverktyg, genomför den en analys av känslomässig ton (sentiment analysis) av den meningen, vilket ger en bedömning av författarens känslomässiga förhållande till ett visst objekt.

Så här ser huvudfönstret för denna applikation ut.

Webbapplikation för analys av texters känslomässig ton

Ur teknisk synvinkel består applikationen av tre mikrotjänster, var och en löser ett specifikt uppsättning av uppgifter:

• SA-Frontend — en Nginx-webbserver som hanterar statiska React-filer.
• SA-WebApp — ett webbprogram skrivet i Java som hanterar förfrågningar från frontend.
• SA-Logic — en Python-applikation som utför textanalys.

Det är viktigt att notera att mikrotjänsterna inte existerar isolerat. De realiserar idén om "arbetsdelning", men behöver också interagera med varandra.

Datastreamar i applikationen

I diagrammet ovan kan man se de numrerade stegen i systemets arbete, som illustrerar datastreamarna i applikationen. Låt oss gå igenom dem:

1. Webbläsaren begär en fil från servern index.html (som i sin tur laddar React-applikationspaketet).
2. Användaren interagerar med applikationen, vilket orsakar en begäran till webbapplikationen, baserad på Spring.
3. Webbapplikationen vidarebefordrar begäran för textanalys till Python-applikationen.
4. Python-applikationen utför textanalysen och returnerar resultatet som svar på begäran.
5. Spring-applikationen skickar svaret till React-applikationen (som i sin tur visar textanalysens resultat för användaren).

Koden för alla dessa applikationer kan hittas här. Jag rekommenderar att du omedelbart kopierar detta repository till dig, eftersom vi har många intressanta experiment framför oss.

Kör applikationen, baserad på mikrotjänster, på din lokala dator

För att applikationen ska fungera behöver vi starta alla tre mikrotjänster. Låt oss börja med den mest attraktiva av dem — frontend-applikationen.

▍Konfigurera React för lokal utveckling

För att köra React-applikationen behöver du installera Node.js och NPM på din dator. När du har installerat allt detta, gå in i projektmappen med hjälp av terminalen sa-frontend och kör följande kommando:

npm install

Genom att köra detta kommando kommer beroenden för React-applikationen att laddas ner i mappen node_modules , vars poster finns i filen package.json. Efter att beroendena har laddats ner, kör följande kommando i samma mapp:

npm start

Det är allt. Nu har React-applikationen startats och kan nås genom att gå till följande adress i webbläsaren localhost:3000. Du kan ändra något i dess kod. Effekten av dessa ändringar kommer du att se direkt i webbläsaren. Detta är möjligt tack vare den så kallade "heta" modulbytet. Med detta gör frontendutveckling till en enkel och trevlig upplevelse.

▍Förbereda React-applikationen för produktion

För verkligt användande av React-applikationen behöver vi omvandla den till en uppsättning statiska filer och leverera dem till kunderna via en webbserver.

För att bygga React-applikationen, återigen använda terminalen, gå till mappen sa-frontend och kör följande kommando:

npm run build

Detta kommer att skapa en mapp i projektmappen build. Denna mapp kommer att innehålla alla statiska filer som behövs för att React-applikationen ska fungera.

▍Underhålla statiska filer med Nginx

Först måste du installera och starta webbservern Nginx. Här du kan ladda ner den och hitta installations- och startinstruktioner. Därefter måste du kopiera innehållet i mappen sa-frontend/build till mappen [your_nginx_installation_dir]/html.

Med detta tillvägagångssätt kommer filen som genereras under byggprocessen av React-applikationen index.html att vara tillgänglig på adressen [your_nginx_installation_dir]/html/index.html. Detta är den fil som Nginx-servern som standard returnerar när den anropas. Servern är konfigurerad att lyssna på port 80, men den kan konfigureras så som du vill genom att redigera filen [your_nginx_installation_dir]/conf/nginx.conf.

Nu öppnar du webbläsaren och går till adressen localhost:80. Du kommer att se sidan av React-applikationen.

React-applikation som hanteras av Nginx-servern

Om du nu skriver något i fältet Type your sentence och trycker på knappen Send — kommer inget att hända. Men om du kollar i konsolen kan du se felmeddelanden. För att förstå var dessa fel inträffar, ska vi analysera kodens struktur.

▍Analys av frontendapplikationens kod

Genom att titta på koden i filen App.js, kan vi se att ett tryck på knappen Send anropar metoden analyzeSentence(). Koden för denna metod ges nedan. Observera att varje rad som har en kommentar av typen # Номер, har en förklaring som följer efter koden. På liknande sätt kommer vi att analysera andra kodfragment.

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: den adress som POST-förfrågan skickas till. Det antas att det finns en applikation på den här adressen som väntar på sådana förfrågningar.

2.Kroppen av förfrågan som skickas till applikationen. Här är ett exempel på kropp:

{
    sentence: "I like yogobella!"
}

3.När svaret på förfrågan tas emot uppdateras komponentens tillstånd. Detta orsakar en omrendering av komponenten. Om vi får data (det vill säga en JSON-objekt som innehåller inmatade data och det beräknade textvärdet), visar vi komponenten Polarity, eftersom lämpliga villkor kommer att uppfyllas. Här är hur vi beskriver komponenten:

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

Koden verkar vara fullt fungerande. Vad är det som är fel här då? Om du antar att det inte finns något på den adress där applikationen försöker skicka POST-förfrågan som kan ta emot och behandla denna förfrågan, så har du helt rätt. Specifikt, för att hantera förfrågningar som kommer till adressen http://localhost:8080/sentiment, behöver vi köra en webbapplikation baserad på Spring.

Vi behöver en Spring-applikation som kan ta emot POST-förfrågningar.

▍Inställning av webapplikationen baserad på Spring

För att distribuera en Spring-applikation behöver du JDK8 och Maven samt korrekt inställda miljövariabler. När du har installerat allt detta kan du fortsätta arbeta med vårt projekt.

▍Paketera applikationen i en jar-fil

Använd terminalen för att gå till mappen sa-webapp och skriv in följande kommando:

mvn install

Efter att detta kommando har körts kommer en katalog att skapas i mappen sa-webapp . Här kommer Java-applikationen, paketenerad i en jar-fil, att ligga, representerad av filen targetsentiment-analysis-web-0.0.1-SNAPSHOT.jar ▍Kör Java-applikationen.

Gå till mappen

och starta applikationen med följande kommando: target java -jar sentiment-analysis-web-0.0.1-SNAPSHOT.jar

Under körningen av detta kommando kommer ett fel att uppstå. För att börja åtgärda det kan vi analysera undantagsinformationen i stackspårningsdata:

När denna kommandon körs kommer ett fel att inträffa. För att börja åtgärda detta kan vi analysera informationen om undantaget i stackspåren:

Ett fel vid skapandet av bean med namnet 'sentimentController': Injektion av autowired beroenden misslyckades; nästlad undantag är java.lang.IllegalArgumentException: Kunde inte lösa platshållaren 'sa.logic.api.url' i värdet "${sa.logic.api.url}"

För oss är det viktigaste här nämnandet av oförmågan att fastställa värdet sa.logic.api.url. Vi analyserar koden där felet inträffar.

▍Analys av Java-applikationens kod

Här är en kodsnutt där felet inträffar.

@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. I SentimentController finns ett fält saLogicApiUrl. Dess värde sätts av egenskapen sa.logic.api.url.
2. Sträng saLogicApiUrl konkateneras med värdet /analyse/sentiment. Tillsammans bildar de adressen för att utföra anropet till mikrotjänsten som utför textanalys.

▍Sätta värdet av egenskapen

I Spring är den standardkälla för egenskapsvärden en fil application.properties, som kan hittas på platsen sa-webapp/src/main/resources. Men dess användning är inte det enda sättet att ange egenskapsvärden. Det kan också göras med hjälp av ett kommando av följande typ:

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

Värdet på denna egenskap måste peka på adressen till vår Python-applikation.

Genom att konfigurera det informerar vi Spring-webbapplikationen om vart den ska vända sig för att utföra textanalysanrop.

För att underlätta för oss själva bestämmer vi att Python-applikationen kommer att vara tillgänglig på adressen localhost:5000 och vi ska försöka komma ihåg det. Som ett resultat kommer kommandot för att starta Spring-applikationen att se ut så här:

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

I vårt system saknas Python-applikationen.

Nu återstår det bara att starta Python-applikationen så att systemet fungerar som förväntat.

▍Konfiguration av Python-applikationen

För att starta Python-applikationen måste du ha Python 3 och Pip installerat, och relevanta miljövariabler måste vara korrekt konfigurerade.

▍Installation av beroenden

Gå till projektmappen sa-logic/sa och kör följande kommandon:

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

▍Starta applikationen

Efter installation av beroenden är vi redo att köra applikationen:

python sentiment_analysis.py

Efter att ha kört detta kommando får vi följande meddelande:

* Kör på http://0.0.0.0:5000/ (Tryck CTRL+C för att avsluta)

Detta innebär att applikationen är igång och väntar på förfrågningar på adressen localhost:5000/

▍Kodstudie

Låt oss titta på koden för Python-applikationen för att förstå hur den reagerar på förfrågningar:

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. Initiering av objekt Flask.
2. Angivelse av adressen för att utföra POST-förfrågningar till det.
3. Utdrag av egenskap sentence från förfrågningskroppen.
4. Initiering av anonymt objekt TextBlob och hämta värdet polarity för den första meningen som kom in i förfrågningskroppen (i vårt fall är det en enda mening som skickas för analys).
5. Återlämning av ett svar vars kropp innehåller texten i meningen och det beräknade värdet för den polarity.
6. Starta Flask-applikationen som kommer att vara tillgänglig på adressen 0.0.0.0:5000 (den kan nås med en struktur av typen localhost:5000).

Nu har mikrotjänsterna som applikationen består av startats. De är inställda för att interagera med varandra. Så här ser applikationens schema ut vid detta arbetsskedet.

Alla mikrotjänster som applikationen består av har satts i drift

Innan vi fortsätter, öppna React-applikationen i webbläsaren och försök att analysera en mening med den. Om allt görs rätt — efter att ha tryckt på knappen Send ser du analysresultaten under textfältet.

I nästa avsnitt ska vi prata om hur man kör våra mikrotjänster i Docker-containrar. Detta är nödvändigt för att förbereda applikationen för körning i en Kubernetes-kluster.

Docker-containrar

Kubernetes är ett system för automatisering av distribution, skalning och hantering av containeriserade applikationer. Det kallas även "containerorkestrator" (container orchestrator). Om Kubernetes arbetar med containrar, behöver vi först skaffa oss dessa containrar innan vi kan använda systemet. Men låt oss först prata om vad containrar är. Kanske det bästa svaret på frågan om vad det är, finns i dokumentationen Docker:

En containerbild är ett lättviktigt, autonomt, exekverbart paket som innehåller en applikation och allt som behövs för att köra den: applikationskoden, körmiljön, systemverktyg och bibliotek, konfigurationer. Containeriserade program kan användas i Linux- och Windows-miljöer, och de kommer alltid att fungera på samma sätt oavsett infrastruktur.

Det innebär att containrar kan köras på alla datorer, inklusive produktionsservrar, och i alla miljöer kommer de applikationer som de innehåller att fungera på samma sätt.

För att utforska egenskaperna hos containrar och jämföra dem med andra sätt att köra applikationer, ska vi titta på ett exempel där vi underhåller en React-applikation med hjälp av en virtuell maskin och en container.

▍Underhåll av statiska filer i en React-applikation med hjälp av en virtuell maskin

När vi försöker organisera underhållet av statiska filer med hjälp av virtuella maskiner, kommer vi att stöta på följande nackdelar:

1. Ineffektiv resursanvändning, eftersom varje virtuell maskin representerar ett fullständigt operativsystem.
2. Plattformsberoende. Det som fungerar på en viss lokal dator kanske inte fungerar på en produktionsserver.
3. Långsam och resurskrävande skalning av en lösning baserad på virtuella maskiner.

Webbservern Nginx som tjänar statiska filer, körs på en virtuell maskin

Om vi däremot använder containrar för att lösa samma uppgift, kan vi, jämfört med virtuella maskiner, notera följande styrkor:

1. Effektiv resursanvändning: arbete med operativsystemet med hjälp av Docker.
2. Oberoende av plattform. En container som utvecklaren kan köra på sin dator kommer att fungera var som helst.
3. Lättviktig distribution genom användning av bildlager.

Webbservern Nginx, som serverar statiska filer, körs i en container.

Vi har jämfört virtuella maskiner och containrar utifrån bara några punkter, men även det är tillräckligt för att känna av containrarnas styrkor. Här Du kan hitta detaljinformation om Docker-containrar.

▍Bygga en containerbild för ett React-program

Den grundläggande byggstenen för Docker-containern är en fil Dockerfile. I början av denna fil anges basbilden för containern, följt av en sekvens av instruktioner som anger i vilken ordning containern ska byggas för att passa behovet hos en viss applikation.

Innan vi går vidare med att arbeta med filen Dockerfile, låt oss påminna oss om vad vi gjorde för att förbereda filerna för React-applikationen för att distribueras på Nginx-servern:

1. Bygga paketet för React-applikationen (npm run build).
2. Köra Nginx-servern.
3. Kopiera innehållet i katalogen build från projektmappen sa-frontend till serverkatalogen nginx/html.

Nedan kan du se paralleller mellan skapandet av en container och de ovan nämnda åtgärder som utförs på den lokala datorn.

▍Förbereda Dockerfile för SA-Frontend-applikationen

Instruktionerna som kommer att finnas i Dockerfile för applikationen SA-Frontend, består endast av två kommandon. Anledningen är att en grupp utvecklare från Nginx har förberett en grundläggande bild för Nginx, som vi kommer att använda för att skapa vår bild. Här är de två stegen som vi behöver beskriva:

1. Basbilden ska vara Nginx-bilden.
2. Innehållet i mappen sa-frontend/build ska kopieras till bildmappen nginx/html.

Om vi går från denna beskrivning till filen Dockerfile, kommer den att se ut så här:

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

Som du ser är allt här väldigt enkelt och innehållet i filen är faktiskt ganska läsbart och begripligt. Den här filen säger till systemet att den ska ta bilden nginx med allt som redan finns i den och kopiera innehållet i katalogen build till katalogen nginx/html.

Här kan du ställa dig frågan om hur jag vet var filerna från mappen build, alltså var sökvägen /usr/share/nginx/html, kommer ifrån. Egentligen är det inget svårt med det. Det finns relevant information i beskrivningen av bilden.

▍Bygg en bild och ladda upp den till ett repository

Innan vi kan arbeta med den färdiga bilden måste vi skicka den till ett bildrepository. För detta kommer vi att använda den kostnadsfria molnplattformen för att hosta bilder, Docker Hub. Vid den här tidpunkten behöver du göra följande:

1. Installera Docker.
2. Registrera dig på Docker Hub.
3. Logga in på ditt konto genom att köra följande kommando i terminalen:

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

Nu måste du, med hjälp av terminalen, navigera till katalogen sa-frontend och köra där kommandot av följande typ:

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

Här och framöver i liknande kommandon $DOCKER_USER_ID måste bytas ut mot ditt användarnamn på Docker Hub. Till exempel kan denna del av kommandot se ut så här: rinormaloku/sentiment-analysis-frontend.

Detta kommando kan också förkortas genom att ta bort -f Dockerfile, eftersom denna fil redan finns i mappen där vi kör detta kommando.

För att skicka den färdiga bilden till repositoryt kommer vi att behöva följande kommando:

docker push $DOCKER_USER_ID/sentiment-analysis-frontend

Efter att ha kört detta, kontrollera listan över dina repositories på Docker Hub för att se om bilden har skickats till det molnbaserade lagret framgångsrikt.

▍Köra en container

Nu kan vem som helst ladda ner och köra bilden som är känd som $DOCKER_USER_ID/sentiment-analysis-frontend. För att göra detta behöver du köra följande sekvens av kommandon:

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

Nu är containern igång och vi kan fortsätta vårt arbete med att skapa andra nödvändiga bilder. Men innan vi fortsätter, låt oss gå igenom konstruktionen 80:80, som förekommer i kommandot för att starta bilden och kan verka förvirrande.

• Det första numret 80 är portnumret för värden (dvs. den lokala datorn).
• Det andra numret 80 är porten för containern som förfrågan ska omdirigeras till.

Låt oss titta på följande illustration.

Omdirigering av portar

Systemet omdirigerar förfrågningar från port <hostPort> till port <containerPort>. Det vill säga, en förfrågan till porten 80 på datorn omdirigeras till porten 80 för containern.

Eftersom porten 80 är öppen på den lokala datorn, kan applikationen nås från denna dator på adressen localhost:80. Om ditt system inte stöder Docker kan du starta applikationen på en Docker-virtuell maskin, vars IP-adress kommer att synas som :80. För att ta reda på IP-adressen för den virtuella Docker-maskinen kan du använda kommandot docker-machine ip.

Vid detta steg, efter att container för frontend-applikationen framgångsrikt har startats, bör du kunna öppna dess sida i webbläsaren.

▍Fil .dockerignore

När vi bygger applikationsbilden SA-Frontend, märkte vi att processen kan vara ganska långsam. Detta beror på att Docker-demonen måste ta emot byggkontexten. Katalogen som representerar byggkontexten anges som det sista argumentet i kommandot docker build. I vårt fall står det en punkt i slutet av detta kommando. Detta gör att följande struktur inkluderas i byggkontexten:

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

Men vi behöver endast mappen build. Att ladda något annat är bara slöseri med tid. Bygget kan påskyndas genom att ange för Docker vilka kataloger som kan ignoreras. Det är just därför vi behöver filen .dockerignore. Om du är bekant med filen .gitignore, kommer strukturen i denna fil säkert att verka bekant. Den listar kataloger som byggsystemet kan ignorera. Innehållet i denna fil ser i vår situation ut så här:

node_modules
src
public

Fil .dockerignore måste finnas i samma mapp som filen Dockerfile. Nu kommer byggandet av bilden att ta några sekunder.

Låt oss nu gå vidare till bilden för Java-applikationen.

▍Bygg av containern för Java-applikationen

Vet du vad, du har faktiskt redan lärt dig allt som behövs för att skapa containerbilder. Därför kommer detta avsnitt att bli ganska kort.

Öppna filen Dockerfile, som finns i projektkatalogen sa-webapp. Om du läser texten i denna fil kommer du att stöta på endast två nya konstruktioner som börjar med nyckelorden ENV och EXPOSE:

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

Nyckelordet ENV tillåter att deklarera miljövariabler inom Docker-containrar. I synnerhet tillåter det i vårt fall att ange URL:en för att få tillgång till API:t för textanalysapplikationen.

Nyckelordet EXPOSE låter Docker veta att porten behöver öppnas. Vi kommer att använda denna port under arbetet med applikationen. Här kan man märka att i Dockerfile för applikationen SA-Frontend sådan kommandon inte finns. Detta är endast för dokumentationsändamål, med andra ord, denna konstruktion är avsedd för den som kommer att läsa Dockerfile.

Byggandet av en bild och sändning av den till ett repository ser exakt ut som i föregående exempel. Om du fortfarande inte är helt säker på dina förmågor – motsvarande kommandon kan hittas i filen README.md i mappen sa-webapp.

▍Byggnad av en containerbild för Python-applikation

Om du tittar på innehållet i filen Dockerfile i mappen sa-logic, så hittar du inget nytt där. Kommandon för att bygga en bild och skicka den till repositoryt bör också vara bekanta för dig, men deras, precis som i fallet med våra andra applikationer, kan hittas i filen README.md i mappen sa-logic.

▍Testning av containeriserade applikationer

Kan du lita på något som du inte har testat? Jag kan inte heller. Låt oss testa våra containrar.

1. Låt oss köra applikationens container sa-logic och ställa in den för att lyssna på porten 5050:

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

2. Låt oss köra applikationens container sa-webapp och ställa in den för att lyssna på porten 8080. Dessutom måste vi ställa in den port där Python-applikationen kommer att vänta på förfrågningar från Java-applikationen genom att omdefiniera miljövariabeln SA_LOGIC_API_URL:

   $ docker run -d -p 8080:8080 -e SA_LOGIC_API_URL='http://:5000' $DOCKER_USER_ID/sentiment-analysis-web-app

För att ta reda på hur man tar reda på IP-adressen för containern eller Docker-virtuella maskinen – se filen README.

Låt oss köra applikationens container sa-frontend:

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

Nu är allt klart för att gå till webbläsaren på adressen localhost:80 och testa applikationen.

Observera att om du har ändrat porten för sa-webapp, eller om du arbetar med en Docker-virtuell maskin, behöver du redigera filen App.js från mappen sa-frontend, genom att byta IP-adress eller portnummer i metoden analyzeSentence(), genom att sätta in aktuella uppgifter istället för de föråldrade. Efter detta måste du bygga om bilden och använda den.

Så här ser schemat för vår applikation ut nu.

Mikrotjänster körs i containrar

Sammanfattning: varför behöver vi en Kubernetes-kluster?

Nyss har vi studerat filerna Dockerfile, pratat om hur man bygger bilder och skickar dem till Docker-repository. Dessutom har vi lärt oss att påskynda byggandet av bilder med hjälp av filen .dockerignore. Som ett resultat körs våra mikrotjänster nu i Docker-containrar. Här kan du rimligtvis fråga dig varför vi behöver Kubernetes. Svaret på denna fråga kommer att behandlas i den andra delen av detta material. Under tiden, tänk på följande fråga:
Låt oss anta att vår webbapplikation för textanalys har blivit världsomspännande populär. Varje minut kommer miljoner förfrågningar till den. Det betyder att mikrotjänsterna sa-webapp och sa-logic kommer att utsättas för enorm belastning. Hur skalas containrarna där mikrotjänsterna körs?

Källa: habr.com