{"id":39476,"date":"2019-10-31T22:33:41","date_gmt":"2019-10-31T19:33:41","guid":{"rendered":"https:\/\/prohoster.info\/blog\/legkoe-upravlenie-konfiguratsiyami-mikroservisov-s-pomoshhyu-microconfig-io\/"},"modified":"2019-10-31T22:33:41","modified_gmt":"2019-10-31T19:33:41","slug":"legkoe-upravlenie-konfiguratsiyami-mikroservisov-s-pomoshhyu-microconfig-io","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/legkoe-upravlenie-konfiguratsiyami-mikroservisov-s-pomoshhyu-microconfig-io","title":{"rendered":"Gestione semplice delle configurazioni dei microservizi tramite microconfig.io","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Uno dei principali problemi nella progettazione e successiva gestione dei microservizi \u00e8 la corretta e accurata configurazione delle loro istanze. A mio avviso, un nuovo framework pu\u00f2 aiutare in questo. microconfig.io<\/a><\/noindex>. Esso consente di affrontare in modo piuttosto elegante alcune delle attivit\u00e0 di configurazione routinarie delle applicazioni.
\n<\/a><\/noindex>
\nSe hai molti microservizi, e ciascuno di essi viene fornito con il proprio file\/file di configurazione, c'\u00e8 una grande probabilit\u00e0 di commettere un errore in uno di essi, che senza la dovuta esperienza e un sistema di registrazione potrebbe essere molto difficile da individuare. L'obiettivo principale del framework \u00e8 ridurre al minimo i parametri di configurazione duplicati delle istanze, in modo da diminuire la probabilit\u00e0 di aggiungere errori.<\/p>\n

Consideriamo un esempio. Supponiamo di avere una semplice applicazione con un file di configurazione yaml<\/b>. Questo pu\u00f2 essere qualsiasi microservizio in qualsiasi linguaggio. Vediamo come il framework pu\u00f2 essere applicato a questo servizio. <\/p>\n

Ma prima, per maggiore comodit\u00e0, creiamo un progetto vuoto in Idea IDE, installando precedentemente il plugin microconfig.io: <\/p>\n

\"Gestione
\n
\nStiamo configurando la configurazione di avvio del plugin, \u00e8 possibile utilizzare la configurazione predefinita, come nello screenshot sopra.<\/p>\n

Il nostro servizio si chiama order, quindi nel nuovo progetto creeremo una struttura simile:<\/p>\n

\"Gestione
\n
\nNella cartella con il nome del servizio mettiamo il file di configurazione \u2014 application.yaml<\/b>. Tutti i microservizi vengono eseguiti in un ambiente specifico, quindi, oltre a creare la configurazione del servizio stesso, \u00e8 necessario descrivere anche l'ambiente: per farlo, creeremo una cartella envs<\/b> e aggiungeremo al suo interno un file con il nome del nostro ambiente di lavoro. In questo modo, il framework creer\u00e0 file di configurazione per i servizi nell'ambiente dev<\/b>, poich\u00e9 nelle impostazioni del plugin \u00e8 impostato proprio questo parametro.<\/p>\n

La struttura del file dev.yaml<\/b> sar\u00e0 piuttosto semplice: <\/p>\n

mainorder:\n    components:\n         - order<\/code><\/pre>\n
\nIl framework lavora con configurazioni che sono raggruppate. Per il nostro servizio scegliamo un nome per il gruppo mainorder<\/b>. Il framework trova ciascun gruppo di applicazioni nel file degli ambienti e crea configurazioni per tutti loro, che trova nelle cartelle corrispondenti. <\/p>\n
Nel file di configurazione del servizio order<\/b> indicheremo per ora solo un parametro: <\/p>\n
spring.application.name: order<\/code><\/pre>\n
\nOra avviamo il plugin, che generer\u00e0 la configurazione necessaria per il nostro servizio secondo il percorso specificato nelle propriet\u00e0:<\/p>\n
\"Gestione
\n
\n\u00c8 possibile fare a meno<\/a><\/noindex> anche senza installare il plugin, semplicemente scaricando il pacchetto del framework e avviandolo dalla riga di comando.
\nQuesta soluzione \u00e8 adatta per l'uso su un server di build.<\/p>\n
Vale la pena notare che il framework comprende perfettamente property<\/b> la sintassi, cio\u00e8 i normali file di propriet\u00e0 che possono essere utilizzati insieme a yaml<\/b> configurazioni.<\/p>\n
Aggiungiamo un altro servizio payment<\/b> e contemporaneamente complicheremo quello esistente.
\nIn order<\/b>:<\/p>\n
eureka:\n instance.preferIpAddress: true\n client:\n   serviceUrl:\n     defaultZone: http:\/\/192.89.89.111:6782\/eureka\/\nserver.port: 9999\nspring.application.name: order\ndb.url: 192.168.0.100<\/code><\/pre>\n
\nIn payment<\/b>:<\/p>\n
eureka:\n instance.preferIpAddress: true\n client:\n   serviceUrl:\n     defaultZone: http:\/\/192.89.89.111:6782\/eureka\/\nserver.port: 9998\nspring.application.name: payments\ndb.url: 192.168.0.100<\/code><\/pre>\n
\nIl principale problema di queste configurazioni \u00e8 la presenza di una grande quantit\u00e0 di copiaincolla nelle impostazioni dei servizi. Vediamo come il framework pu\u00f2 aiutare a eliminarlo. Iniziamo con la pi\u00f9 ovvia: la presenza della configurazione eureka<\/b> nella descrizione di ogni microservizio. Creiamo una nuova directory con un file di impostazioni e aggiungiamoci una nuova configurazione:<\/p>\n
\"Gestione
\n
\nE ora aggiungiamo una riga a ciascuno dei nostri progetti #include eureka<\/i>.<\/p>\n
Il framework trover\u00e0 automaticamente la configurazione di Eureka e la copier\u00e0 nei file di configurazione dei servizi, senza creare una configurazione separata poich\u00e9 non la indicheremo nel file di ambiente. dev.yaml<\/b>. Servizio order<\/b>:<\/p>\n
#include eureka\nserver.port: 9999\nspring.application.name: order\ndb.url: 192.168.0.100<\/code><\/pre>\n
\nPossiamo anche spostare le impostazioni del database in una configurazione separata, modificando la riga di importazione in #include eureka, oracle<\/i>.<\/p>\n
Va notato che ogni modifica durante la rigenerazione dei file di configurazione viene tracciata dal framework e registrata in un file speciale accanto al file di configurazione principale. La registrazione nel suo log appare cos\u00ec: \u201cStored 1 property changes to order\/diff-application.yaml<\/b>\u201d. Questo consente di individuare rapidamente le modifiche in grandi file di configurazione.<\/p>\n
Spostare le parti comuni della configurazione aiuta a eliminare molte duplicazioni inutili, ma non consente di creare configurazioni flessibili per diversi ambienti: gli endpoint dei nostri servizi sono unici e hardcoded, il che \u00e8 un problema. Proviamo a rimuoverlo.<\/p>\n
Una buona soluzione sarebbe tenere tutti gli endpoint in un'unica configurazione, cui gli altri potrebbero fare riferimento. Per questo, il framework ha introdotto il supporto per i segnaposto. Ecco come cambier\u00e0 il file di configurazione. eureka<\/b>:<\/p>\n
 client:\n   serviceUrl:\n     defaultZone: http:\/\/${endpoints@eurekaip}:6782\/eureka\/<\/code><\/pre>\n
\nOra vediamo come funziona questo segnaposto. Il sistema trova il componente con il nome endpoints<\/b> e cerca al suo interno il valore eurekaip<\/b>, dopodich\u00e9 lo inserisce nella nostra configurazione. Ma come gestire le diverse ambienti? A tal fine, creiamo un file di configurazione in endpoints<\/b> questo formato application.dev.yaml<\/b>. Il framework identifica automaticamente, in base all'estensione del file, a quale ambiente appartiene questa configurazione e la carica:<\/p>\n
\"Gestione
\n
\nIl contenuto del file dev:<\/p>\n
eurekaip: 192.89.89.111\ndbip: 192.168.0.100<\/code><\/pre>\n
\nPossiamo creare la stessa configurazione anche per le porte dei nostri servizi:<\/p>\n
server.port: ${ports@order}.<\/code><\/pre>\n
\nTutte le impostazioni importanti si trovano in un unico luogo, riducendo cos\u00ec la probabilit\u00e0 di errori dovuti a parametri sparsi nei file di configurazione.<\/p>\n
Il framework offre molti segnaposto gi\u00e0 pronti, ad esempio, \u00e8 possibile ottenere il nome della directory in cui si trova il file di configurazione e assegnarlo:<\/p>\n
#include eureka, oracle\nserver.port: ${ports@order}\nspring.application.name: ${this@name}<\/code><\/pre>\n
\nGrazie a questo, non \u00e8 necessario specificare ulteriormente il nome dell'applicazione nella configurazione e pu\u00f2 anche essere spostato in un modulo comune, ad esempio, nello stesso eureka:<\/p>\n
client:\n   serviceUrl:\n     defaultZone: http:\/\/${endpoints@eurekaip}:6782\/eureka\/\n spring.application.name: ${this@name}<\/code><\/pre>\n
\nFile di configurazione order<\/b> verr\u00e0 ridotto a una sola riga:<\/p>\n
#include eureka, oracle\nserver.port: ${ports@order}<\/code><\/pre>\n
\nSe qualche impostazione della configurazione principale non \u00e8 necessaria, possiamo specificarla nella nostra configurazione e sar\u00e0 questa ad essere applicata durante la generazione. Cio\u00e8, se per qualche motivo abbiamo bisogno di un nome univoco per il servizio order, possiamo semplicemente lasciare il parametro spring.application.name<\/b>.<\/p>\n
Supponiamo di dover aggiungere delle impostazioni di logging personalizzate al servizio, che sono memorizzate in un file separato, ad esempio, logback.xml<\/b>. Creeremo un gruppo separato di impostazioni per esso:<\/p>\n
\"Gestione
\n
\nNella configurazione di base, indicheremo al framework dove posizionare il file di configurazione del logging necessario utilizzando il segnaposto @ConfigDir<\/b>:<\/p>\n
microconfig.template.logback.fromFile: ${logback@configDir}\/logback.xml<\/code><\/pre>\n
\nNel file logback.xml<\/b> configuriamo gli appender standard, che possono a loro volta contenere segnaposto che il framework modificher\u00e0 durante la generazione dei config, ad esempio:<\/p>\n
logs\/${this@name}.log<\/code><\/pre>\n
\nAggiungendo nelle configurazioni dei servizi l'import logback<\/b>, otteniamo automaticamente la registrazione configurata per ogni servizio:<\/p>\n
#include eureka, oracle, logback\nserver.port: ${ports@order}<\/code><\/pre>\n
\n\u00c8 giunto il momento di familiarizzare pi\u00f9 dettagliatamente con tutti i segnaposto disponibili del framework:<\/p>\n
${this@env}<\/b> \u2014 restituisce il nome dell'ambiente corrente.
\n${…@name} <\/b> \u2014 restituisce il nome del componente.
\n${…@configDir}<\/b> \u2014 restituisce il percorso completo della directory di configurazione del componente.
\n${…@resultDir}<\/b> \u2014 restituisce il percorso completo della directory di destinazione del componente (i file ottenuti saranno collocati in questa directory).
\n${this@configRoot}<\/b> \u2014 restituisce il percorso completo della directory principale del repository di configurazioni.<\/p>\n
Inoltre, il sistema consente di ottenere variabili ambientali, come il percorso di java:
\n${env@JAVA_HOME}<\/b>
\nO, poich\u00e9 il framework \u00e8 scritto in JAVA<\/b>, possiamo ottenere variabili di sistema simili alla chiamata System::getProperty<\/b> usando una costruzione di questo tipo:
\n${system@os.name}<\/b>
\nVale la pena menzionare il supporto per il linguaggio di espressione Spring EL<\/b>. Nella configurazione sono applicabili espressioni simili:<\/p>\n
connection.timeoutInMs: #{5 * 60 * 1000}\ndatasource.maximum-pool-size: #{${this@datasource.minimum-pool-size} + 10} <\/code><\/pre>\n
\ne si possono utilizzare variabili locali nei file di configurazione tramite l'espressione #var<\/b>:<\/p>\n
#var feedRoot: ${system@user.home}\/feed\nfolder:\n root: ${this@feedRoot}\n success: ${this@feedRoot}\/archive\n error: ${this@feedRoot}\/error<\/code><\/pre>\n
\nPertanto, il framework si presenta come uno strumento molto potente per una configurazione fine e flessibile dei microservizi. Il framework svolge alla perfezione il suo compito principale: eliminare il copincolla nelle configurazioni, consolidare le impostazioni e, di conseguenza, ridurre al minimo le possibili errori, consentendo nel contempo di combinare facilmente le configurazioni e modificarle per diversi ambienti.<\/p>\n
Se questo framework ha destato il vostro interesse, vi consiglio di visitare la sua pagina ufficiale e di prendere visione della documentazione completa documentazione<\/a><\/noindex>, oppure di dare un'occhiata al codice sorgente qui<\/a><\/noindex>.
\n
Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041e\u0434\u043d\u043e\u0439 \u0438\u0437 \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u0445 \u043f\u0440\u043e\u0431\u043b\u0435\u043c \u043f\u0440\u0438 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u0438 \u043f\u043e\u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0435\u0439 \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0433\u0440\u0430\u043c\u043e\u0442\u043d\u0430\u044f \u0438 \u0430\u043a\u043a\u0443\u0440\u0430\u0442\u043d\u0430\u044f \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0430 \u0438\u0445 \u0438\u043d\u0441\u0442\u0430\u043d\u0441\u043e\u0432. \u0412 \u044d\u0442\u043e\u043c, \u043d\u0430 \u043c\u043e\u0439 \u0432\u0437\u0433\u043b\u044f\u0434, \u043c\u043e\u0436\u0435\u0442 \u043f\u043e\u043c\u043e\u0447\u044c \u043d\u043e\u0432\u044b\u0439 \u0444\u0440\u0435\u0439\u043c\u0432\u043e\u0440\u043a microconfig.io. \u041e\u043d \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u0435\u0442 \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u044d\u043b\u0435\u0433\u0430\u043d\u0442\u043d\u043e \u0440\u0435\u0448\u0438\u0442\u044c \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0440\u0443\u0442\u0438\u043d\u043d\u044b\u0435 \u0437\u0430\u0434\u0430\u0447\u0438 \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439. \u0415\u0441\u043b\u0438 \u0443 \u0432\u0430\u0441 \u043c\u043d\u043e\u0433\u043e \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432, \u0438 \u043a\u0430\u0436\u0434\u044b\u0439 \u0438\u0437 \u043d\u0438\u0445 \u043f\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0432\u043c\u0435\u0441\u0442\u0435 \u0441\u043e \u0441\u0432\u043e\u0438\u043c \u0444\u0430\u0439\u043b\u043e\u043c\/\u0444\u0430\u0439\u043b\u0430\u043c\u0438 \u043d\u0430\u0441\u0442\u0440\u043e\u0435\u043a, \u0442\u043e \u0432\u0435\u043b\u0438\u043a\u0430 \u0432\u0435\u0440\u043e\u044f\u0442\u043d\u043e\u0441\u0442\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":39477,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39476","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Gestione semplice delle configurazioni dei microservizi con microconfig.io | ProHoster","description":"Una delle principali problematiche nella sviluppo e successivo funzionamento dei microservizi \u00e8 la corretta e accurata configurazione delle loro istanze.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/legkoe-upravlenie-konfiguratsiyami-mikroservisov-s-pomoshhyu-microconfig-io","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041b\u0435\u0433\u043a\u043e\u0435 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0435 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u044f\u043c\u0438 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e microconfig.io | ProHoster","og:description":"\u041e\u0434\u043d\u043e\u0439 \u0438\u0437 \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u0445 \u043f\u0440\u043e\u0431\u043b\u0435\u043c \u043f\u0440\u0438 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u0438 \u043f\u043e\u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0435\u0439 \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0433\u0440\u0430\u043c\u043e\u0442\u043d\u0430\u044f \u0438 \u0430\u043a\u043a\u0443\u0440\u0430\u0442\u043d\u0430\u044f \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0430 \u0438\u0445 \u0438\u043d\u0441\u0442\u0430\u043d\u0441\u043e\u0432.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/legkoe-upravlenie-konfiguratsiyami-mikroservisov-s-pomoshhyu-microconfig-io","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:33:41+00:00","article:modified_time":"2019-10-31T19:33:41+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39476","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 02:05:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 13:48:28","updated":"2026-01-24 02:05:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/39476","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=39476"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/39476\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/39477"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=39476"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=39476"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=39476"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}