Հեշտությամբ կառավարեք միկրոսպասարկման կոնֆիգուրացիաները microconfig.io-ի միջոցով

Միկրոծառայությունների մշակման և հետագա գործունեության հիմնական խնդիրներից մեկը դրանց ատյանների իրավասու և ճշգրիտ կազմաձևումն է: Իմ կարծիքով, նոր շրջանակը կարող է օգնել դրան microconfig.io. Այն թույլ է տալիս բավականին էլեգանտ լուծել հավելվածների կազմաձևման որոշ առաջադրանքներ:

Եթե ​​դուք ունեք բազմաթիվ միկրոծառայություններ, և դրանցից յուրաքանչյուրը գալիս է իր կոնֆիգուրացիայի ֆայլով/ֆայլերով, ապա դրանցից մեկում սխալ թույլ տալու մեծ հավանականություն կա, որը կարող է շատ դժվար լինել բռնել առանց համապատասխան հմտության և գրանցման համակարգի: Հիմնական խնդիրն է, որ շրջանակը դնում է իր համար, կրկնակի օրինակների կազմաձևման պարամետրերը նվազագույնի հասցնելն է՝ դրանով իսկ նվազեցնելով սխալի ավելացման հավանականությունը:

Դիտարկենք մի օրինակ։ Ենթադրենք, մենք ունենք մի պարզ հավելված՝ կազմաձևման ֆայլով յամլ. Սա կարող է լինել ցանկացած միկրոսերվիս ցանկացած լեզվով: Տեսնենք, թե ինչպես կարելի է շրջանակը կիրառել այս ծառայության համար:

Բայց նախ, ավելի մեծ հարմարության համար, եկեք ստեղծենք դատարկ նախագիծ Idea IDE-ում՝ դրա մեջ microconfig.io հավելվածը տեղադրելուց հետո.

Մենք ստեղծեցինք plugin-ի գործարկման կոնֆիգուրացիան, դուք կարող եք օգտագործել լռելյայն կազմաձևը, ինչպես վերը նշված սքրինշոթում:

Մեր ծառայությունը կոչվում է պատվեր, ապա նոր նախագծում մենք կստեղծենք նմանատիպ կառուցվածք.

Տեղադրեք կազմաձևման ֆայլը ծառայության անունով թղթապանակում - դիմում.yaml. Բոլոր միկրոսերվիսները գործարկվում են ինչ-որ միջավայրում, հետևաբար, ծառայության համար կոնֆիգուրացիա ստեղծելուց բացի, անհրաժեշտ է նկարագրել հենց միջավայրը. դրա համար մենք կստեղծենք թղթապանակ: նախանձ և դրան ավելացնել ֆայլ մեր աշխատանքային միջավայրի անունով: Այսպիսով, շրջանակը կստեղծի կոնֆիգուրացիայի ֆայլեր շրջակա միջավայրի ծառայությունների համար դավ, քանի որ այս պարամետրը սահմանված է plugin-ի կարգավորումներում:

Ֆայլի կառուցվածքը dev.yaml դա բավականին պարզ կլինի.

mainorder:
    components:
         - order

Շրջանակն աշխատում է միասին խմբավորված կոնֆիգուրացիաների հետ: Մեր ծառայության համար ընտրեք խմբի անունը հիմնական պատվեր. Framework-ը գտնում է հավելվածների յուրաքանչյուր այդպիսի խումբ շրջակա միջավայրի ֆայլում և ստեղծում դրանց բոլորի համար կոնֆիգուրացիաներ, որոնք գտնում է համապատասխան թղթապանակներում:

Ծառայության կարգավորումների ֆայլում ինքնին կարգը Առայժմ նշենք միայն մեկ պարամետր.

spring.application.name: order

Այժմ եկեք գործարկենք plugin-ը, և այն կստեղծի մեր ծառայության համար անհրաժեշտ կոնֆիգուրացիան՝ ըստ հատկությունների մեջ նշված ուղու.

կարող է գնացեք և առանց plugin տեղադրելու, պարզապես ներբեռնելով շրջանակի բաշխումը և գործարկել այն հրամանի տողից:
Այս լուծումը հարմար է build սերվերի վրա օգտագործելու համար:

Հարկ է նշել, որ շրջանակը հիանալի հասկանում է սեփականություն շարահյուսություն, այսինքն՝ սովորական սեփականության ֆայլեր, որոնք կարող են օգտագործվել միասին յամլ կոնֆիգուրացիաներ.

Ավելացնենք ևս մեկ ծառայություն վճարում ու բարդացնել եղածը։
В կարգը:

eureka:
 instance.preferIpAddress: true
 client:
   serviceUrl:
     defaultZone: http://192.89.89.111:6782/eureka/
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100

В վճարում:

eureka:
 instance.preferIpAddress: true
 client:
   serviceUrl:
     defaultZone: http://192.89.89.111:6782/eureka/
server.port: 9998
spring.application.name: payments
db.url: 192.168.0.100

Այս կոնֆիգուրացիաների հիմնական խնդիրը ծառայության կարգավորումներում մեծ քանակությամբ copy-paste-ի առկայությունն է: Տեսնենք, թե ինչպես է շրջանակը կօգնի ազատվել դրանից: Սկսենք ամենաակնհայտից՝ կոնֆիգուրացիայի առկայությունից EUREKA յուրաքանչյուր միկրոծառայության նկարագրության մեջ: Եկեք կարգավորումների ֆայլով ստեղծենք նոր գրացուցակ և դրան ավելացնենք նոր կոնֆիգուրացիա.

Եվ հիմա եկեք ավելացնենք մեր յուրաքանչյուր նախագծի գիծը #ներառել էվրիկա.

Շրջանակը ավտոմատ կերպով կգտնի eureka կոնֆիգուրացիան և պատճենի այն ծառայության կազմաձևման ֆայլերում, մինչդեռ առանձին eureka կոնֆիգուրացիա չի ստեղծվի, քանի որ մենք այն չենք նշի շրջակա միջավայրի ֆայլում: dev.yaml. Ծառայություն կարգը:

#include eureka
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100

Մենք կարող ենք նաև տվյալների բազայի կարգավորումները տեղափոխել առանձին կոնֆիգուրացիա՝ փոխելով ներմուծման գիծը #ներառել էվրիկա, օրակուլ.

Հարկ է նշել, որ շրջանակը հետևում է յուրաքանչյուր փոփոխությանը, երբ վերականգնում է կազմաձևման ֆայլերը և տեղադրում այն ​​հատուկ ֆայլում՝ հիմնական կազմաձևման ֆայլի կողքին: Դրա գրանցամատյանի գրառումն ունի հետևյալ տեսքը. «Պահված 1 հատկություն փոխվում է order/diff-application.yaml« Սա թույլ է տալիս արագ հայտնաբերել մեծ կազմաձևման ֆայլերի փոփոխությունները:

Կազմաձևի ընդհանուր մասերի հեռացումը թույլ է տալիս ազատվել շատ ավելորդ copy-paste-ից, բայց թույլ չի տալիս ճկուն կերպով ստեղծել կոնֆիգուրացիա տարբեր միջավայրերի համար. մեր ծառայությունների վերջնակետերը եզակի են և կոշտ կոդավորված, սա վատ է: Փորձենք հեռացնել սա:

Լավ լուծում կլինի բոլոր վերջնական կետերը պահել մեկ կոնֆիգուրացիայի մեջ, որին կարող են հղում կատարել մյուսները: Այդ նպատակով շրջանակում ներդրվել է տեղապահների աջակցությունը: Այսպես կփոխվի կազմաձևման ֆայլը EUREKA:

 client:
   serviceUrl:
     defaultZone: http://${endpoints@eurekaip}:6782/eureka/

Այժմ տեսնենք, թե ինչպես է աշխատում այս տեղապահը: Համակարգը գտնում է մի բաղադրիչ անունով endpoints և իմաստ է փնտրում դրա մեջ eurekaip, և այնուհետև այն փոխարինում է մեր կազմաձևում: Բայց ինչ վերաբերում է տարբեր միջավայրերին: Դա անելու համար ստեղծեք կարգավորումների ֆայլ endpoints հետեւյալ տեսակը application.dev.yaml. Շրջանակն ինքնուրույն, հիմնվելով ֆայլի ընդլայնման վրա, որոշում է, թե որ միջավայրին է պատկանում այս կոնֆիգուրացիան և բեռնում է այն.

Dev ֆայլի բովանդակությունը.

eurekaip: 192.89.89.111
dbip: 192.168.0.100

Մենք կարող ենք ստեղծել նույն կոնֆիգուրացիան մեր ծառայությունների նավահանգիստների համար.

server.port: ${ports@order}.

Բոլոր կարևոր կարգավորումները մեկ տեղում են՝ դրանով իսկ նվազեցնելով կազմաձևման ֆայլերում ցրված պարամետրերի պատճառով սխալների հավանականությունը:

Շրջանակը տրամադրում է բազմաթիվ պատրաստի տեղապահներ, օրինակ՝ կարող եք ստանալ այն գրացուցակի անունը, որում գտնվում է կազմաձևման ֆայլը և նշանակել այն.

#include eureka, oracle
server.port: ${ports@order}
spring.application.name: ${this@name}

Դրա շնորհիվ կարիք չկա լրացուցիչ նշել հավելվածի անունը կոնֆիգուրացիայի մեջ, և այն կարող է տեղադրվել նաև ընդհանուր մոդուլում, օրինակ, նույն eureka-ում.

client:
   serviceUrl:
     defaultZone: http://${endpoints@eurekaip}:6782/eureka/
 spring.application.name: ${this@name}

Կազմաձևման ֆայլը կարգը կկրճատվի մեկ տողի.

#include eureka, oracle
server.port: ${ports@order}

Եթե ​​ծնողի կոնֆիգուրացիայից որևէ կարգավորում պետք չէ, մենք կարող ենք այն նշել մեր կազմաձևում և այն կկիրառվի գեներացման ընթացքում: Այսինքն, եթե ինչ-ինչ պատճառներով մեզ անհրաժեշտ է եզակի անուն պատվերի ծառայության համար, մենք պարզապես կթողնենք պարամետրը spring.application.name.

Ենթադրենք, դուք պետք է ծառայությանը ավելացնեք հատուկ գրանցման կարգավորումներ, որոնք պահվում են առանձին ֆայլում, օրինակ. logback.xml. Եկեք դրա համար ստեղծենք պարամետրերի առանձին խումբ.

Հիմնական կազմաձևում մենք կպատմենք շրջանակին, թե որտեղ պետք է տեղադրենք գրանցման կարգավորումների ֆայլը՝ օգտագործելով տեղապահ @ConfigDir:

microconfig.template.logback.fromFile: ${logback@configDir}/logback.xml

Ֆայլում logback.xml մենք կարգավորում ենք ստանդարտ հավելվածներ, որոնք իրենց հերթին կարող են նաև պարունակել տեղապահներ, որոնք շրջանակը կփոխվի կոնֆիգուրացիաների ստեղծման ընթացքում, օրինակ՝

<file>logs/${this@name}.log</file>

Ներմուծում ավելացնելով ծառայության կոնֆիգուրացիաներին հետգնում, մենք ավտոմատ կերպով ստանում ենք կազմաձևված գրանցումներ յուրաքանչյուր ծառայության համար.

#include eureka, oracle, logback
server.port: ${ports@order}

Ժամանակն է ավելի մանրամասն ծանոթանալ շրջանակի բոլոր հասանելի տեղապահների հետ.

${this@env} - վերադարձնում է ընթացիկ միջավայրի անունը:
${…@name} — վերադարձնում է բաղադրիչի անունը:
${…@configDir} — վերադարձնում է բաղադրիչի կազմաձևման գրացուցակի ամբողջական ուղին:
${…@resultDir} — վերադարձնում է բաղադրիչի նպատակակետ գրացուցակի ամբողջական ուղին (արդյունքում ստացված ֆայլերը կտեղադրվեն այս գրացուցակում):
${this@configRoot} — վերադարձնում է ամբողջական ուղին դեպի կազմաձևման պահեստի արմատային գրացուցակը:

Համակարգը նաև թույլ է տալիս ստանալ շրջակա միջավայրի փոփոխականներ, օրինակ՝ Java-ի ուղին.
${env@JAVA_HOME}
Կամ, քանի որ շրջանակը գրված է JAVA, մենք կարող ենք ստանալ համակարգի փոփոխականներ, որոնք նման են զանգին Համակարգ՝:getProperty օգտագործելով այսպիսի կառուցվածք.
${[էլեկտրոնային փոստով պաշտպանված]}
Հարկ է նշել ընդլայնման լեզվի աջակցությունը Գարնանային ԵԼ. Կազմաձևում կիրառելի են հետևյալ արտահայտությունները.

connection.timeoutInMs: #{5 * 60 * 1000}
datasource.maximum-pool-size: #{${[email protected]} + 10} 

և դուք կարող եք օգտագործել տեղական փոփոխականներ կազմաձևման ֆայլերում՝ օգտագործելով արտահայտությունը #var:

#var feedRoot: ${[email protected]}/feed
folder:
 root: ${this@feedRoot}
 success: ${this@feedRoot}/archive
 error: ${this@feedRoot}/error

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

Եթե ​​ձեզ հետաքրքրում է այս շրջանակը, խորհուրդ եմ տալիս այցելել նրա պաշտոնական էջը և ծանոթանալ ամբողջությամբ փաստաթղթեր, կամ փորփրե՛ք աղբյուրները այստեղ.

Source: www.habr.com