🥇Kubernetes ուղեցույց Մաս 1. Ծրագրեր, միկրոծառայություններ և կոնտեյներներ

Մեր խնդրանքով Հաբրը ստեղծեց կենտրոն Կուբերնետես և մենք ուրախ ենք դրանում տեղադրել առաջին հրապարակումը: Բաժանորդագրվեք

Kubernetes-ը հեշտ է: Ինչո՞ւ են բանկերն ինձ մեծ գումարներ վճարում՝ այս ոլորտում աշխատելու համար, մինչդեռ յուրաքանչյուրը կարող է տիրապետել այս տեխնոլոգիային ընդամենը մի քանի ժամում:

Եթե կասկածում եք, որ Kubernetes-ը կարելի է այդքան արագ սովորել, առաջարկում եմ ինքներդ փորձել։ Մասնավորապես, տիրապետելով այս նյութին, դուք կկարողանաք գործել Kubernetes կլաստերի միկրոծառայությունների վրա հիմնված հավելված: Ես կարող եմ դա երաշխավորել, քանի որ այստեղ կիրառվող նույն մեթոդաբանությունն է, որ ես սովորեցնում եմ մեր հաճախորդներին աշխատել Kubernetes-ի հետ: Ինչո՞վ է այս ուղեցույցը տարբերվում մյուսներից: Իրականում շատ բաներ կան։ Այսպիսով, այս նյութերի մեծ մասը սկսվում է պարզ բաների բացատրությամբ՝ Kubernetes հասկացությունները և kubectl հրամանի առանձնահատկությունները: Այս նյութերի հեղինակները ենթադրում են, որ իրենց ընթերցողները ծանոթ են հավելվածների մշակմանը, միկրոսերվիսներին և Docker կոնտեյներներին։ Մենք կգնանք այլ ճանապարհով: Նախ, մենք կխոսենք այն մասին, թե ինչպես կարելի է համակարգչի վրա միկրոծառայությունների վրա հիմնված հավելված գործարկել: Այնուհետև մենք կանդրադառնանք յուրաքանչյուր միկրոծառայության համար նախատեսված կոնտեյների պատկերների կառուցմանը: Եվ դրանից հետո մենք կծանոթանանք Kubernetes-ին և կդիտարկենք միկրոծառայությունների վրա հիմնված հավելվածի տեղակայումը Kubernetes-ի կողմից կառավարվող կլաստերում:

Այս մոտեցումը, աստիճանական մոտեցմամբ Kubernetes-ին, կտրամադրի տեղի ունեցածի ըմբռնման խորությունը, որն անհրաժեշտ է սովորական մարդուն՝ հասկանալու համար, թե որքան պարզ է ամեն ինչ աշխատում Kubernetes-ում: Kubernetes-ը, անշուշտ, պարզ տեխնոլոգիա է, պայմանով, որ նրանք, ովքեր ցանկանում են սովորել այն, իմանան, թե որտեղ և ինչպես է այն օգտագործվում:

Այժմ, առանց ավելորդ անհանգստության, եկեք սկսենք և խոսենք այն հավելվածի մասին, որի հետ մենք աշխատելու ենք:

Փորձարարական կիրառություն

Մեր հավելվածը կկատարի միայն մեկ գործառույթ. Որպես մուտքագրում վերցնում է մեկ նախադասություն, որից հետո, օգտագործելով տեքստի վերլուծության գործիքները, կատարում է այս նախադասության զգացմունքային վերլուծություն՝ ստանալով որոշակի առարկայի նկատմամբ նախադասության հեղինակի հուզական վերաբերմունքի գնահատականը:

Ահա թե ինչ տեսք ունի այս հավելվածի հիմնական պատուհանը։

Վեբ հավելված տեքստերի զգացմունքների վերլուծության համար

Տեխնիկական տեսանկյունից հավելվածը բաղկացած է երեք միկրոծառայություններից, որոնցից յուրաքանչյուրը լուծում է առաջադրանքների որոշակի շարք.

SA-Frontend-ը Nginx վեբ սերվեր է, որը սպասարկում է ստատիկ React ֆայլեր:
SA-WebApp-ը Java-ով գրված վեբ-հավելված է, որը մշակում է ճակատային մասի հարցումները:
SA-Logic-ը Python հավելված է, որն իրականացնում է զգացմունքների վերլուծություն տեքստի վրա:

Կարևոր է նշել, որ միկրոծառայությունները առանձին-առանձին գոյություն չունեն: Նրանք իրականացնում են «պարտականությունների տարանջատման» գաղափարը, բայց միևնույն ժամանակ պետք է շփվեն միմյանց հետ։

Տվյալների հոսքը հավելվածում

Վերևի գծապատկերում դուք կարող եք տեսնել համակարգի համարակալված փուլերը, որոնք ցույց են տալիս հավելվածում տվյալների հոսքերը: Եկեք նայենք նրանց.

Բրաուզերը ֆայլ է պահանջում սերվերից index.html (որն իր հերթին ներբեռնում է React հավելվածի փաթեթը)։
Օգտագործողը շփվում է հավելվածի հետ, դա առաջացնում է զանգ Spring-ի վրա հիմնված վեբ հավելված:
Վեբ հավելվածը տեքստի վերլուծություն կատարելու հարցումը փոխանցում է Python հավելվածին։
Python հավելվածը կատարում է տեքստի տրամադրության վերլուծություն և արդյունքը վերադարձնում է որպես հարցման պատասխան:
Spring հավելվածը պատասխան է ուղարկում React հավելվածին (որն իր հերթին օգտատիրոջը ցույց է տալիս տեքստի վերլուծության արդյունքը)։

Այս բոլոր հավելվածների կոդը կարելի է գտնել այստեղ. Խորհուրդ եմ տալիս հենց հիմա պատճենել այս շտեմարանը ձեզ համար, քանի որ դրա հետ կապված շատ հետաքրքիր փորձեր կան առջևում:

Ձեր տեղական մեքենայի վրա միկրոծառայությունների վրա հիմնված հավելվածի գործարկում

Որպեսզի հավելվածն աշխատի, մենք պետք է գործարկենք բոլոր երեք միկրոսերվիսները։ Սկսենք դրանցից ամենագեղեցիկից՝ front-end հավելվածից:

▍ Ստեղծեք React-ը տեղական զարգացման համար

React հավելվածը գործարկելու համար հարկավոր է համակարգչում տեղադրել Node.js հարթակը և NPM-ը: Այս ամենը տեղադրելուց հետո օգտագործեք տերմինալը՝ ձեր նախագծի թղթապանակը նավարկելու համար sa-frontend և գործարկել հետևյալ հրամանը.

npm install

Գործարկելով այս հրամանը թղթապանակում node_modules React հավելվածի կախվածությունները կբեռնվեն, որոնց գրառումները գտնվում են ֆայլում package.json. Երբ կախվածությունները ներբեռնվեն նույն թղթապանակում, գործարկեք հետևյալ հրամանը.

npm start

Այսքանը: Այժմ React հավելվածն աշխատում է, այն կարող եք մուտք գործել՝ ձեր բրաուզերում անցնելով հետևյալ հասցեով. localhost:3000. Դուք կարող եք ինչ-որ բան փոխել իր ծածկագրում: Դուք անմիջապես կտեսնեք այս փոփոխությունների ազդեցությունը բրաուզերում: Դա հնարավոր է մոդուլների, այսպես կոչված, «տաք» փոխարինման շնորհիվ: Սա դարձնում է front-end մշակումը պարզ և հաճելի փորձ:

▍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-ի վրա։

Մեզ պետք է գարնանային հավելված, որը կարող է ընդունել POST հարցումը

▍Գարնան վրա հիմնված վեբ հավելվածի տեղադրում

Spring հավելվածը տեղակայելու համար ձեզ հարկավոր են JDK8 և Maven և պատշաճ կազմաձևված միջավայրի փոփոխականներ: Այս ամենը տեղադրելուց հետո կարող եք շարունակել աշխատել մեր նախագծի վրա:

▍Հավելվածի փաթեթավորում բանկա ֆայլի մեջ

Թղթապանակի միջոցով նավարկեք տերմինալի միջոցով 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

Այս հրամանը կատարելիս սխալ կառաջանա: Այն շտկելու համար մենք կարող ենք վերլուծել բացառության մանրամասները stack trace տվյալների մեջ.

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

ՍentimentController կա դաշտ saLogicApiUrl. Դրա արժեքը նշված է գույքով sa.logic.api.url.
Լարային saLogicApiUrl միանում է արժեքին /analyse/sentiment. Նրանք միասին կազմում են տեքստի վերլուծություն իրականացնող միկրոսերվիս զանգահարելու հասցեն։

▍ Սահմանել սեփականության արժեքը

Գարնանը գույքի արժեքների ստանդարտ աղբյուրը ֆայլն է 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

Օբյեկտի սկզբնավորում Flask.
Հասցե նշելով նրան POST հարցումներ կատարելու համար:
Գույքի առբերում sentence հարցման մարմնից։
Անանուն օբյեկտի սկզբնավորում TextBlob և ստանալ արժեքը polarity հարցումի մարմնում ստացված առաջին նախադասության համար (մեր դեպքում սա վերլուծության ուղարկված միակ նախադասությունն է)։
Վերադարձնել պատասխանը, որի մարմինը պարունակում է նախադասության տեքստը և դրա համար հաշվարկված ցուցանիշը polarity.
Գործարկեք Flask հավելվածը, որը հասանելի կլինի այստեղ 0.0.0.0:5000 (Դուք կարող եք նաև մուտք գործել այն՝ օգտագործելով ձևի կառուցվածքը localhost:5000).

Հավելվածը կազմող միկրոծառայություններն այժմ աշխատում են: Նրանք հարմարեցված են միմյանց հետ շփվելու համար: Ահա թե ինչ տեսք ունի կիրառման դիագրամը աշխատանքի այս փուլում:

Հավելվածը կազմող բոլոր միկրոսերվիսները բերված են աշխատանքային վիճակում

Այժմ, նախքան շարունակելը, բացեք ձեր React հավելվածը զննարկիչում և փորձեք դրա հետ վերլուծել որոշ նախադասություն: Եթե ամեն ինչ ճիշտ է արված, կոճակը սեղմելուց հետո Send տեքստային դաշտի տակ կտեսնեք վերլուծության արդյունքները:

Հաջորդ բաժնում մենք կխոսենք այն մասին, թե ինչպես գործարկել մեր միկրոծառայությունները Docker կոնտեյներներում: Սա անհրաժեշտ է Kubernetes կլաստերի վրա հավելվածը գործարկելու համար պատրաստելու համար:

Docker կոնտեյներներ

Կուբերնետես բեռնարկղային հավելվածների տեղակայման, մասշտաբավորման և կառավարման ավտոմատացման համակարգ է: Այն նաև կոչվում է «կոնտեյներային նվագախումբ»: Եթե Kubernetes-ը աշխատում է կոնտեյներներով, ապա այս համակարգը օգտագործելուց առաջ մենք նախ պետք է ձեռք բերենք այդ կոնտեյներները։ Բայց նախ, եկեք խոսենք այն մասին, թե ինչ են բեռնարկղերը: Թերևս լավագույն պատասխանը այն հարցին, թե ինչ է դա, կարելի է գտնել փաստաթղթավորում Docker-ին.

Կոնտեյների պատկերը թեթև, ինքնուրույն, կատարվող փաթեթ է, որը պարունակում է ծրագիր, որը ներառում է այն գործարկելու համար անհրաժեշտ ամեն ինչ՝ ծրագրի կոդ, աշխատանքային միջավայր, համակարգային գործիքներ և գրադարաններ, ինչպես նաև կարգավորումներ: Կոնտեյներացված ծրագրերը կարող են օգտագործվել միջավայրերում: Linux и Windows, և դրանք միշտ կաշխատեն նույն կերպ՝ անկախ ենթակառուցվածքից։

Սա նշանակում է, որ կոնտեյներները կարող են գործարկվել ցանկացած համակարգչի վրա, ներառյալ արտադրական սերվերները, և դրանցում պարունակվող հավելվածները նույն կերպ կաշխատեն ցանկացած միջավայրում:

Կոնտեյներների առանձնահատկությունները ուսումնասիրելու և հավելվածները գործարկելու այլ եղանակների հետ համեմատելու համար եկեք նայենք React հավելվածի սպասարկման օրինակին՝ օգտագործելով վիրտուալ մեքենա և կոնտեյներ:

▍Վիրտուալ մեքենայի միջոցով React հավելվածի ստատիկ ֆայլերի սպասարկում

Փորձելով կազմակերպել ստատիկ ֆայլերի ծառայությունը վիրտուալ մեքենաների միջոցով, մենք կհանդիպենք հետևյալ թերություններին.

Ռեսուրսների անարդյունավետ օգտագործում, քանի որ յուրաքանչյուր վիրտուալ մեքենա լիարժեք օպերացիոն համակարգ է:
Պլատֆորմի կախվածություն. Այն, ինչ աշխատում է տեղական համակարգչում, կարող է չաշխատել արտադրական սերվերի վրա:
Վիրտուալ մեքենայի վրա հիմնված լուծման դանդաղ և ռեսուրսային ինտենսիվ մասշտաբավորում:

Nginx վեբ սերվեր, որը սպասարկում է վիրտուալ մեքենայի վրա աշխատող ստատիկ ֆայլեր

Եթե կոնտեյներները օգտագործվում են նմանատիպ խնդիր լուծելու համար, ապա վիրտուալ մեքենաների համեմատությամբ կարելի է նշել հետևյալ ուժեղ կողմերը.

Ռեսուրսների արդյունավետ օգտագործում. Docker-ի միջոցով օպերացիոն համակարգի հետ աշխատելը:
Պլատֆորմ անկախ: Կոնտեյներ, որը մշակողը կարող է գործարկել իր համակարգչով, կաշխատի ցանկացած վայրում:
Թեթև տեղակայում պատկերի շերտերի օգտագործման միջոցով:

Nginx վեբ սերվերը սպասարկում է ստատիկ ֆայլեր, որոնք աշխատում են կոնտեյներով

Մենք համեմատեցինք վիրտուալ մեքենաներն ու բեռնարկղերը միայն մի քանի կետերով, բայց նույնիսկ սա բավական է բեռնարկղերի ուժեղ կողմերը զգալու համար: Այստեղ Դուք կարող եք գտնել մանրամասներ Docker կոնտեյներների մասին:

▍React հավելվածի համար կոնտեյների պատկերի ստեղծում

Docker կոնտեյների հիմնական շինանյութը ֆայլն է Dockerfile. Այս ֆայլի սկզբում գրառում է արվում կոնտեյների բազային պատկերի մասին, այնուհետև կա հրահանգների հաջորդականություն, որը ցույց է տալիս, թե ինչպես ստեղծել կոնտեյներ, որը կբավարարի որոշակի հավելվածի կարիքները:

Նախքան ֆայլի հետ աշխատելը Dockerfile, եկեք հիշենք, թե ինչ ենք արել React հավելվածի ֆայլերը Nginx սերվերում վերբեռնելու համար պատրաստելու համար.

React հավելվածի փաթեթի կառուցում (npm run build).
Nginx սերվերի գործարկում:
Գրացուցակի բովանդակության պատճենում build նախագծի թղթապանակից sa-frontend դեպի սերվերի թղթապանակ nginx/html.

Ստորև կարող եք տեսնել զուգահեռները կոնտեյներ ստեղծելու և ձեր տեղական համակարգչում կատարված վերը նշված քայլերի միջև:

▍Dockerfile-ի պատրաստում SA-Frontend հավելվածի համար

Հրահանգները, որոնք կներառվեն Dockerfile կիրառման համար SA-Frontend, բաղկացած է ընդամենը երկու թիմից։ Փաստն այն է, որ Nginx-ի մշակման թիմը պատրաստել է հիմնական նկարը Nginx-ի համար, որը մենք կօգտագործենք մեր պատկերը ստեղծելու համար: Սրանք այն երկու քայլերն են, որոնք մենք պետք է նկարագրենք.

Պատկերի հիմքը պետք է լինի Nginx պատկերը։
Թղթապանակի բովանդակություն 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 հարթակը: Աշխատանքի այս փուլում դուք պետք է կատարեք հետևյալը.

Տեղադրելու համար դոկեր.
Գրանցվեք Docker Hub կայքում:
Մուտք գործեք ձեր հաշիվ՝ գործարկելով հետևյալ հրամանը տերմինալում.
```
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 կոնտեյների նավահանգիստն է, որին պետք է ուղարկվի հարցումը:

Նկատի առնենք հետևյալ օրինակը։

Port Forwarding

Համակարգը վերահղում է հարցումները նավահանգստից <hostPort> մեկ նավահանգստի համար <containerPort>. Այսինքն՝ մուտք դեպի նավահանգիստ 80 համակարգիչը վերահղված է դեպի նավահանգիստ 80 կոնտեյներ.

Քանի որ նավահանգստի 80 բացվել է տեղական համակարգչում, այնուհետև կարող եք մուտք գործել հավելված այս համակարգչից localhost:80. Եթե ձեր համակարգը չի աջակցում Docker-ին, ապա հավելվածը կարող է գործարկվել Docker վիրտուալ մեքենայի վրա, որի հասցեն նման կլինի. <docker-machine ip>:80. Docker վիրտուալ մեքենայի IP հասցեն պարզելու համար կարող եք օգտագործել հրամանը docker-machine ip.

Այս պահին, ճակատային հավելվածի կոնտեյները հաջողությամբ գործարկելուց հետո, դուք պետք է կարողանաք բացել դրա էջը բրաուզերում:

▍.dockerignore ֆայլը

Հավելվածի պատկերի հավաքում SA-Frontend, կարող էինք նկատել, որ այս գործընթացը չափազանց դանդաղ է ստացվում։ Դա տեղի է ունենում, քանի որ պատկերի կառուցման համատեքստը պետք է ուղարկվի Docker daemon-ին: Կառուցման համատեքստը ներկայացնող գրացուցակը նշվում է որպես հրամանի վերջին արգումենտ 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.

▍Պիթոնի հավելվածի համար կոնտեյների պատկերի ստեղծում

Եթե նայեք ֆայլի բովանդակությանը Dockerfile թղթապանակում sa-logic, ապա այնտեղ ձեզ համար նոր բան չեք գտնի։ Պատկերը կառուցելու և այն պահեստ ուղարկելու հրամանները նույնպես պետք է ձեզ արդեն ծանոթ լինեն, բայց, ինչպես մեր մյուս հավելվածների դեպքում, դրանք կարելի է գտնել ֆայլում։ README.md թղթապանակում sa-logic.

▍Կոնտեյներային հավելվածների փորձարկում

Կարո՞ղ եք վստահել մի բանի, որը չեք փորձարկել: Ես էլ չեմ կարող։ Եկեք փորձարկենք մեր տարաները:

Եկեք գործարկենք հավելվածի կոնտեյները sa-logic և կարգավորեք այն, որպեսզի լսեք նավահանգստում 5050:
```
docker run -d -p 5050:5000 $DOCKER_USER_ID/sentiment-analysis-logic
```
Եկեք գործարկենք հավելվածի կոնտեյները 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
```

Սովորելու համար, թե ինչպես պարզել Docker կոնտեյների կամ վիրտուալ մեքենայի IP հասցեն, տես ֆայլը առաջնային.

Եկեք գործարկենք հավելվածի կոնտեյները 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 կլինի ահռելի ծանրաբեռնվածության տակ. Ինչպե՞ս մեծացնել միկրոսերվիսներով աշխատող կոնտեյներները:

Source: www.habr.com