Kompileeritav konfiguratsioon jaotatud süsteemis

Sooviksin rääkida ühest huvitavast mehhanismist, mis puudutab hajutatud süsteemi konfiguratsiooni. Konfiguratsioon on otse esitatud kompileeritavas keeles (Scala) kasutades turvalisi tüüpe. Selles postituses analüüsime sellise konfiguratsiooni näidet ja käsitleme erinevaid aspekte kompileeritava konfiguratsiooni integreerimisest arenduse üldprotsessi.

(english)

Sissejuhatus

Usaldusväärse hajutatud süsteemi ülesehitamine eeldab, et kõigil sõlmedel on õige konfiguratsioon, mis on sünkroniseeritud teiste sõlmedega. T tavaliselt kasutatakse DevOps tehnoloogiaid (terraform, ansible või midagi sarnast) konfiguratsioonifailide automaatseks genereerimiseks (tihti oma iga sõlme jaoks). Soovime samuti olla kindlad, et kõikides suhtlevates sõlmedes kasutatakse samu protokolle (sh sama versiooni). Vastasel juhul võib meie hajutatud süsteemis ilmneda ühilduvuse probleem. JVM maailmas on üks sellise nõude tagajärgi vajadus kasutada igal pool sama versiooni teeki, mis sisaldab protokolli sõnumeid.

Kuidas on lood hajutatud süsteemi testimisega? Muidugi eeldame, et kõigi komponentide jaoks on ette nähtudüksus-testid enne, kui liigume integreerimistestimise juurde. (Kuna me soovime testimistulemusi eksitada runtime'ile, peame tagama samuti identse teegikomplekti nii testimise faasis kui ka runtime'is.)

Integreerimistestide puhul on sageli lihtsam kasutada igal sõlmel ühtset classpath'i. Me peame tagama, et sama classpath'i kasutatakse ka runtime'is. (Kuigi on täiesti võimalik käivitada erinevaid sõlmi erinevate classpath'idega, toob see kaasa kogu konfiguratsiooni keerukuse ning raskused juurutamise ja integreerimistestide puhul.) Selle postituse raames eeldame, et kõigil sõlmedel kasutatakse sama classpath'i.

Konfiguratsioon areneb koos rakendusega. Erinevate arendusetappide tuvastamiseks kasutame versioone. On loogiline, et tuvastame ka erinevad konfiguratsioonid. Isegi konfiguratsioon tuleks panna versioonihaldussüsteemi. Kui tootmises on ainult üks konfiguratsioon, saame kasutada lihtsalt versiooninumbrit. Kui aga on mitmeid tootmisexemplare, peame vajama mitut
konfiguratsiooniharu ja lisamärki versioonist (näiteks haru nimi). Nii saame selgelt tuvastada täpse konfiguratsiooni. Iga konfiguratsiooni identifikaator vastab ühemõtteliselt teatud jaotatud sõlmede, portide, väliste ressursside ja teegiversioonide kombinatsioonile. Selles postituses lähtume eeldusest, et on olemas ainult üks haru, ja saame konfiguratsiooni tuvastada tavapärasel viisil, kasutades kolme numbrit, mis on eraldatud punktiga (1.2.3).

Kaasaegsetes keskkondades luuakse konfiguratsioonifailid harva käsitsi. Enamasti genereeritakse need deployimiseks ja neid ei muudetaks enam (et midagi ei rikuks). Tekkib loogiline küsimus, miks me ikka veel kasutame konfiguratsiooni salvestamiseks tekstivormingut? Elujõuliseks alternatiiviks näib olevat võimalus kasutada tavalist koodi konfiguratsiooniks ja saada kasu kontrollidest kompileerimise ajal.

Selles postituses uurimegi idee, et esitada konfiguratsioon kompileeritud artefakti sees.

Kompileeritav konfiguratsioon

Selles osas on toodud näide staatilisest kompileeritavast konfiguratsioonist. Rakendatakse kahe lihtsa teenuse — eho teenuse ja eho teenuse kliendi — näidet. Nende kahe teenuse põhjal kogume kaks varianti süsteemist. Ühes variandis asuvad mõlemad teenused ühes sõlmes, teises variandis aga erinevates sõlmedes.

Tavaliselt sisaldab jaotatud süsteem mitmeid sõlmi. Sõlme saab tuvastada mõne tüüpi väärtuste abil NodeId:

sealed trait NodeId
case object Backend extends NodeId
case object Frontend extends NodeId

või

case class NodeId(hostName: String)

või isegi

object Singleton
type NodeId = Singleton.type

Sõlmed täidavad erinevaid rolle, neis on teenuseid ja nende vahel võivad olla TCP/HTTP suhted.

TCP ühenduse kirjeldamiseks on meil vähemalt vajalik port. Samuti soovime peegeldada protokolli, mis on sellel pordil toetatud, et tagada, et nii klient kui server kasutavad sama protokolli. Kirjeldame ühendust järgmise klassi abil:

case class TcpEndPoint[Protocol](node: NodeId, port: Port[Protocol])

kus Port — lihtsalt täisarv Int kivide lubatud väärtuste vahemiku näitamisega:

type PortNumber = Refined[Int, Closed[_0, W.`65535`.T]]

Täpsustatud tüübid

Vaata raamatukogu refined ja minu ettekanne. Lühidalt, raamatukogu võimaldab tüüpidele lisada piiranguid, mida kontrollitakse kompileerimise ajal. Antud juhul on lubatud pordi numbriteks 16-bitised täisarvud. Raamatukogu refined kasutamine kompileeritava konfiguratsiooni jaoks ei ole kohustuslik, kuid see parandab kompilaatori kontrollimisvõimet.

HTTP (REST) protokollide jaoks võib pordi numbrist lisaks vaja minna ka teenuse teed:

type UrlPathPrefix = Refined[String, MatchesRegex[W.`"[a-zA-Z_0-9/]*"`.T]]
case class PortWithPrefix[Protocol](portNumber: PortNumber, pathPrefix: UrlPathPrefix)

Fantoomtüübid

Protokolli tuvastamiseks kompileerimise ajal kasutame tüüpparameetrit, mida klassis ei kasutata. See lahendus tuleneb sellest, et runtime'is me protokolli eksemplari ei kasuta, kuid soovime, et kompilaator kontrolliks protokollide ühilduvust. Protokolli määratlemise tõttu ei saa me ebamugavat teenust sõltuvusena edastada.

Üks levinumaid protokolle on REST API JSON-seerialiseerimisega:

sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage]

kus RequestMessage — päringu tüüp, ResponseMessage — vastuse tüüp.
Loomulikult võib kasutada ka muid protokolli kirjeldusi, mis pakuvad vajalikku täpsust.

Selle postituse eesmärkide saavutamiseks kasutame lihtsustatud versiooni protokollist:

sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage]

Siin on päring string, mis lisatakse url-ile, ja vastus on string, mis tagastatakse HTTP vastuse kehas.

Teenuse konfiguratsioon kirjeldatakse teenuse nime, portide ja sõltuvustega. Neid elemente saab esitada Scala-s mitmel viisil (nt. HList-de, algebrailiste andmetüüpide kaudu). Selle postituse eesmärkide saavutamiseks kasutame Cake Pattern'i ja esindame mooduleid kaudu trait‘de. (Cake Pattern ei ole kirjeldatud lähenemise kohustuslik element. See on lihtsalt üks võimalikest teostustest.)

Teenuste vahelisi sõltuvusi saab esitada meetodite kujul, mis tagastavad portid EndPoint‘de teiste sõlmede:

  type EchoProtocol[A] = SimpleHttpGetRest[A, A]

  trait EchoConfig[A] extends ServiceConfig {
    def portNumber: PortNumber = 8081
    def echoPort: PortWithPrefix[EchoProtocol[A]] = PortWithPrefix[EchoProtocol[A]](portNumber, "echo")
    def echoService: HttpSimpleGetEndPoint[NodeId, EchoProtocol[A]] = providedSimpleService(echoPort)
  }

Echo teenuse loomiseks on piisav ainult porti number ja määramine, et see port toetab echo protokolli. Me võiksime ka mitte määrata konkreetset porti, kuna trait'id võimaldavad deklaratsiooni ilma rakenduseta (abstraktsed meetodid). Sellisel juhul nõuaks konkreetse konfiguratsiooni loomine kompilaatorilt, et me esitaksime abstraktsiooni rakenduse ja porti numbri. Kuna me oleme meetodi rakendanud, ei pea me konkreetse konfiguratsiooni loomisel määrama teist porti. Kasutusele võetakse vaikeväärtus.

Kliendi konfiguratsioonis kuulutame välja sõltuvuse echo teenusest:

  trait EchoClientConfig[A] {
    def testMessage: String = "test"
    def pollInterval: FiniteDuration
    def echoServiceDependency: HttpSimpleGetEndPoint[_, EchoProtocol[A]]
  }

Sõltuvus on sama tüüpi nagu eksponeeritud teenus echoService. Ehkki echo kliendis nõuame sama protokolli. Seega, kui kaks teenust omavahel ühendada, saame olla kindlad, et kõik töötab õigesti.

Teenuste rakendamine

Teenuse käivitamiseks ja peatamiseks on vajalik funktsioon. (Teenuse peatamise võimalus on testimise jaoks kriitilise tähtsusega.) Jälle on mitu võimalust sellise funktsiooni rakendamiseks (näiteks võiksime kasutada konfiguratsioonitüüpi põhiseid klasside tüüpe). Käesoleva postituse jaoks kasutame Cake Pattern'it. Me esindame teenust klassi kaudu cats.Resource, kuna see klass sisaldab juba vahendeid ressursside turvaliseks ja garanteerituks vabastamiseks probleemide korral. Ressursi saamiseks peame esitama konfiguratsiooni ja valmis runtime konteksti. Teenuse käivitamise funktsioon võib olla järgmine:

  type ResourceReader[F[_], Config, A] = Reader[Config, Resource[F, A]]

  trait ServiceImpl[F[_]] {
    type Config
    def resource(
      implicit
      resolver: AddressResolver[F],
      timer: Timer[F],
      contextShift: ContextShift[F],
      ec: ExecutionContext,
      applicative: Applicative[F]
    ): ResourceReader[F, Config, Unit]
  }

kus

• Konfiguratsioon — konfiguratsiooni tüüp selle teenuse jaoks
• AddressResolver — käitamise objekt, mis võimaldab teada teiste sõlmede aadresse (vt allpool)

ja ülejäänud tüübid raamatukogust cats:

• F[_] — efekti tüüp (lihtsaimatel juhtudel F[A] võib olla lihtsalt funktsioon () => A. Käesolevas postituses kasutame cats.IO.)
• Reader[A,B] — rohkem-või vähem funktsiooni sünonüüm A => B
• cats.Resource — ressurss, mida saab hankida ja vabastada
• Timer — taimer (võimaldab teatud ajaks uinuda ja mõõta ajavahemikke)
• ContextShift — analoog ExecutionContext
• Applicative — efekti tüübi klass, mis võimaldab eraldi efekte ühendada (peaaegu monaad). Tõenäoliselt on keerukamates rakendustes parem kasutada Monad/ConcurrentEffect.

Kasutades seda funktsiooni signatuuri saame rakendada mitmeid teenuseid. Näiteks teenus, mis ei tee midagi:

  trait ZeroServiceImpl[F[_]] extends ServiceImpl[F] {
    type Config  Resource.pure[F, Unit](()))
  }

(Vt. allikas kood, kus on rakendatud teisi teenuseid — kaja teenus, kaja klient
ja eluea kontrollerid.)

Sõlm on objekt, mis suudab käivitada mitmeid teenuseid (ressursside käivitamine tagatakse Cake Pattern'i kaudu):

object SingleNodeImpl extends ZeroServiceImpl[IO]
  with EchoServiceService
  with EchoClientService
  with FiniteDurationLifecycleServiceImpl
{
  type Config = EchoConfig[String] with EchoClientConfig[String] with FiniteDurationLifecycleConfig
}

Pange tähele, et me märgime täpset konfiguratsiooni tüüpi, mis on selle sõlme jaoks vajalik. Kui unustame määrata mõne konfiguratsiooni tüübi, mis on vajalik eraldi teenuse jaoks, siis tekib kompileerimise viga. Samuti ei saa me sõlme käivitada, kui ei esita mõnd objekti, mis omab sobivat tüüpi koos kõigi vajalike andmetega.

sõlmede nimed

Kaugsõlmest ühenduse loomiseks on meil vajalik päris IP-aadress. On täiesti võimalik, et aadress muutub tuntuks hiljem kui ülejäänud konfiguratsiooni osad. Seetõttu on meil vajalik funktsioon, mis seob sõlme identifikaatori aadressiga:

case class NodeAddress[NodeId](host: Uri.Host)
trait AddressResolver[F[_]] {
  def resolve[NodeId](nodeId: NodeId): F[NodeAddress[NodeId]]
}

Võime pakkuda mitmeid viise sellise funktsiooni rakendamiseks:

1. Kui aadressid saavad meile tuntuks enne juurutamist, siis saame genereerida Scala-koodi koos
   aadressidega ja seejärel käivitada kogumise. Sellega toimub kompileerimine ja testide läbiviimine.
   Sellisel juhul on funktsioon staatiliselt teada ja seda saab esitada koodis kaardistamisena Map[NodeId, NodeAddress].
2. Mõnel juhul muutub kehtiv aadress tuntuks alles pärast sõlme käivitamist.
   Sellisel juhul saame rakendada «avastamisteenust» (discovery), mis käivitatakse enne teisi sõlmi, ja kõik sõlmed registreeritakse selles teenuses ning küsivad teiste sõlmede aadresse.
3. Kui suudame muuta /etc/hosts, siis saab kasutada eelmääratud hostide nimesid (näiteks my-project-main-node ja echo-backend) ja lihtsalt siduda need nimed
   IP-aadressidega juurutamise käigus.

Käesolevas postituses ei käsitle me neid juhtumeid lähemalt. Meie
mänguasja näite puhul on kõik sõlmedel üks IP-aadress — 127.0.0.1.

Vaatame kahte jaotatud süsteemi varianti:

1. Kõik teenused paiknevad ühel sõlmel.
2. Ja kaja teenus ja kaja klient asuvad erinevates sõlmedes.

Konfiguratsioon ühele sõlmele konfiguratsioon ühele sõlmele:

Konfiguratsioon ühele sõlmele

object SingleNodeConfig extends EchoConfig[String] 
  with EchoClientConfig[String] with FiniteDurationLifecycleConfig
{
  case object Singleton \/\/ ainus sõlm 
  \/\/ serveri konfiguratsioon
  type NodeId = Singleton.type
  def nodeId = Singleton

  \/** Type safe teenuse porte määratlemine. *\/ 
  override def portNumber: PortNumber = 8088

  \/\/ kliendi konfiguratsioon

  \/** Kasutame teenust, mis on sama hosti poolt. *\/ 
  def echoServiceDependency = echoService

  override def testMessage: UrlPathElement = "hello"

  def pollInterval: FiniteDuration = 1.second

  \/\/ elutsükli juhtimise konfiguratsioon
  def lifetime: FiniteDuration = 10500.milliseconds \/\/ lisaks 0.5 sekundit, et saaksime 10 päringut, mitte 9.
}

Objekt rakendab nii kliendi kui ka serveri konfiguratsiooni. Samuti kasutatakse eluea konfiguratsiooni, et mõne aja möödudes elutsüklit programm lõpetada. (Ctrl-C töötab samuti ja vabastab õigesti kõik ressursid.)

Sama konfiguratsiooni ja implementatsioonide komplekti saab kasutada süsteemi, mis koosneb kahest eraldi sõlmest:

Konfiguratsioon kahest sõlmest

  object NodeServerConfig extends EchoConfig[String] with SigTermLifecycleConfig
  {
    type NodeId = NodeIdImpl

    def nodeId = NodeServer

    override def portNumber: PortNumber = 8080
  }

  object NodeClientConfig extends EchoClientConfig[String] with FiniteDurationLifecycleConfig
  {
    \/\/ NB! sõltuvuse määratlemine
    def echoServiceDependency = NodeServerConfig.echoService

    def pollInterval: FiniteDuration = 1.second

    def lifetime: FiniteDuration = 10500.milliseconds \/\/ lisaks 0.5 sekundit, et saaksime 10 päringut, mitte 9.

    def testMessage: String = "dolly"
  }

Oluline! Pange tähele, kuidas teenuste sidumine toimub. Näitame teenust, mille teostab üks sõlm, kui teise sõlme sõltuvuse rakendamise meetodit. Sõltuvuse tüüp kontrollitakse kompilatsiooni käigus, kuna see sisaldab protokolli tüüpi. Käivitamisel sisaldab sõltuvus õiget sihtsõlme identifikaatorit. Selle skeemi abil määrame sadama numbri ainult üks kord ja viitame alati õigetele sadamatele.

Kaks sõlme süsteemi rakendamine

Selle konfiguratsiooni jaoks kasutame samu teenuste rakendusi muutumatul kujul. Ainus erinevus on see, et nüüd on meil kaks objekti, mis rakendavad erinevaid teenuste komplekte:

  object TwoJvmNodeServerImpl extends ZeroServiceImpl[IO] with EchoServiceService with SigIntLifecycleServiceImpl {
    type Config = EchoConfig[String] with SigTermLifecycleConfig
  }

  object TwoJvmNodeClientImpl extends ZeroServiceImpl[IO] with EchoClientService with FiniteDurationLifecycleServiceImpl {
    type Config = EchoClientConfig[String] with FiniteDurationLifecycleConfig
  }

Esimene sõlm rakendab serverit ja vajab ainult serveri konfiguratsiooni. Teine sõlm rakendab klienti ja kasutab teist konfiguratsiooni osa. Samuti vajavad mõlemad sõlmed eluea haldamist. Serverisõlm töötab piiramatu aja jooksul, kuni see peatatakse SIGTERMja kliendisõlm lõpetatakse teatud aja pärast. Vaata. rakenduse käivitamine.

Üldine arendusprotsess

Vaatame, kuidas see konfiguratsiooni lähenemine mõjutab üldist arendusprotsessi.

Konfiguratsioon kompileeritakse koos muu koodiga ja genereeritakse artefakt (.jar). Ilmselt on mõistlik paigutada konfiguratsioon eraldi artefakti. See tuleneb sellest, et meil võib olla palju konfiguratsioone sama koodi põhjal. Taaskord on võimalik genereerida artefakte, mis vastavad erinevatele konfiguratsiooni harudele. Koos konfiguratsiooniga säilivad sõltuvused konkreetsete teekide versioonide osas ja need versioonid säilitatakse igavesti, kui otsustame selle konfiguratsiooni versiooni juurutada.

Iga konfiguratsiooni muutmine muutub koodi muutmiseks. Seega on iga selline
muutus hõlmatud tavapärase kvaliteediprotsessiga:

Pääsme viga jälgimisse -> PR -> ülevaatus -> liitmine vastavate harudega ->
integreerimine -> juurutamine

Peamised tagajärjed kompileeritava konfiguratsiooni rakendamisel:

1. Konfiguratsioon kooskõlastatakse kõigis hajutatud süsteemi sõlmedes. Kuna kõik sõlmed saavad sama konfiguratsiooni ühelt allikalt.

2. Konfiguratsiooni muutmine ainult ühes sõlmes on keeruline. Seetõttu on "konfiguratsiooni desünkroniseerimine" (configuration drift) ebatõenäoline.

3. Väikeste muudatuste tegemine konfiguratsioonis muutub keerulisemaks.

4. Enamik konfiguratsioonimuudatusi toimub osana üldisest arendusprotsessist ja läbib ülevaatuse.

Kas on vaja eraldi hoidlat tootmisreakonfiguratsiooni salvestamiseks? Sellises konfiguratsioonis võivad olla paroolid ja muu salajane teave, millele soovime juurdepääsu piirata. Seega tundub mõistlik hoida lõplik konfiguratsioon eraldi hoidlas. Konfiguratsiooni võib jagada kaheks osaks - ühe, mis sisaldab avalikke konfiguratsiooni parameetreid, ja teise, mis sisaldab piiratud juurdepääsuga parameetreid. See võimaldab enamikul arendajatest pääseda juurde avalikele parameetritele. Sellist jagamist on lihtne saavutada vahetreitide kasutamisega, mis sisaldavad vaikimisi väärtusi.

Võimalikud variatsioonid

Proovime võrrelda kompileeritud konfiguratsiooni mõne levinud alternatiiviga:

1. Tekstifail sihtmasinas.
2. Keskne võtme-väärtuse ladu (etcd/zookeeper).
3. Protsessi komponendid, mida saab konfigureerida / taaskäivitada ilma protsessi taaskäivitamiseta.
4. Konfiguratsiooni hoidmine väljaspool artefakti ja versioonihaldust.

Tekstifailid pakuvad olulist paindlikkust väikeste muudatuste tegemisel. Süsteemiadministraator saab kaugelt sõlmedesse sisse logida, teha vastavatesse failidesse muudatused ja teenuse taaskäivitada. Suurte süsteemide puhul võib selline paindlikkus siiski olla ebasoovitav. Tehtud muudatustest ei jää jälgi teistes süsteemides. Keegi ei tee muudatuste ülevaatust. Raske on kindlaks teha, kes ja miks muudatusi tegi. Muudatusi ei testita. Kui süsteem on hajutatud, võib administraator unustada teha vastava muudatuse teistes sõlmedes.

(Samuti tuleks märkida, et kompileeritava konfiguriatsiooni kasutamine ei välista tulevikus tekstifailide kasutamist. Piisab, kui lisada parser ja valideerija, mis annavad tulemusena sama tüüpi Konfiguratsioon, ja saab kasutada tekstifaile. Siit järeldub, et kompileeritava konfiguriatsiooni süsteemi keerukus on mõnevõrra väiksem kui tekstifailide kasutava süsteemi keerukus, kuna tekstifailide jaoks on vajalik täiendav kood.)

Keskne võtme-väärtuse hoidla on hea mehhanism jaotatud rakenduse meta-parameetrite edastamiseks. Peame kindlaks tegema, mis on konfigureerimisparameetrid ja mis on lihtsalt andmed. Oletame, et meil on funktsioon C => A => B, ning parameetrid C muutuvad harva, samas kui andmed A — muutuvad sageli. Sellisel juhul saame öelda, et C — on konfigureerimisparameetrid, ja A — on andmed. Tundub, et konfigureerimisparameetrid erinevad andmetest selle poolest, et nad muutuvad üldjuhul harvem kui andmed. Samuti tulevad andmed tavaliselt ühest allikast (kasutajalt), samas kui konfigureerimisparameetrid - teisest (süsteemi administraatorilt).

Kui harva muutuvaid parameetreid tuleb värskendada ilma programmi taaskäivitamiseta, siis võib see sageli viia programmi keerukuse suurenemiseni, kuna me peame kuidagi edastama parameetreid, neid hoidma, parsima ja kontrollima, töötlema valeväärtusi. Seetõttu on programmi keerukuse vähendamise seisukohalt mõistlik vähendada parameetrite arvu, mis võivad programmi töö käigus muutuda (või isegi mitte neid parameetreid toetada).

Antud postituse kontekstis eristame me staatilisi ja dünaamilisi parameetreid. Kui teenuse tööloogika nõuab parameetrite muutmist programmi töö käigus, nimetame selliseid parameetreid dünaamilisteks. Vastupidisel juhul on parameetrid staatilised ja neid saab seadistada kompileeritava konfiguratsiooni abil. Dünaamiliseks rekontekureerimiseks võib meil olla vajalik mehhanism programmiosade taaskäivimiseks koos uute parameetritega, sarnaselt sellele, kuidas operatsioonisüsteemi protsesse taaskäivitada. (Meie arvates on soovitatav vältida reaalajas rekontekureerimist, kuna see suurendab süsteemi keerukust. Vajadusel on parem kasutada operatsioonisüsteemi standardfunktsioone protsesside taaskäivitamiseks.)

Üks tähtsamaid aspekte staatilise konfiguratsiooni kasutamisel, mis paneb inimesi kaaluma dünaamilist rekontekureerimist, on aeg, mis süsteemil on vajalik konfiguratsiooni uuendamisel taaskäivitamiseks (downtime). Tõepoolest, kui peame tegema muudatusi staatilises konfiguratsioonis, peame süsteemi taaskäivitama, et uued väärtused jõustuksid. Downtime'i probleem on erinevates süsteemides erineva teravusega. Mõnedes juhtumites on võimalik taaskäivitamine planeerida ajale, mil koormus on minimaalne. Kui on vaja tagada pidev teenus, saab rakendada „ühenduste tühjendamine“ (AWS ELB connection draining). Sel juhul, kui peame süsteemi taaskäivitama, käivitame parallelse selle süsteemi eksemplari, lülitame koormuse tasakaalustaja sellele ja ootame, kuni kõik vanad ühendused lõpetatakse. Pärast seda, kui kõik vanad ühendused on lõpetatud, lülitame välja vana süsteemi eksemplari.

Vaatame nüüd küsimust konfiguratsiooni salvestamisest kas artefakti sees või väljas. Kui me salvestame konfiguratsiooni artefakti sisse, on meil vähemalt võimalus veenduda artefakti koostamise ajal konfiguratsiooni õigsuses. Kui konfiguratsioon asub kontrollitavast artefaktist väljaspool, on raske jälgida, kes ja miks tegi selle faili muutused. Kui oluline see on? Meie arvates on paljude tootmisüsteemide jaoks oluline omada stabiilset ja kvaliteetset konfiguratsiooni.

Artefakti versioon võimaldab määrata, millal see loodi, milliseid väärtusi see sisaldab, millised funktsioonid on sisse või välja lülitatud ning kes on vastutav mis tahes muutuste eest konfiguratsioonis. Loomulikult nõuab konfiguratsiooni säilitamine artefakti sees teatud pingutusi, seega tuleb teha teadlik otsus.

Plussid ja miinused

Sooviksin peatuda pakutava tehnoloogia plussidel ja miinustel.

Eelised

Allpool on toodud peamised võimalused kompileeritud konfiguratsiooniga hajutatud süsteemi jaoks:

1. Konfiguratsiooni staatiline kontroll. See tagab, et
   konfiguratsioon on korrektne.
2. Rikka konfiguratsioonikeele kasutamine. tavaliselt on muud seadistamisviisid piiratud maksimaalselt stringimuutujatega. Scala kasutamisel on saadaval lai valik keele võimalusi, et parandada konfiguratsiooni. Näiteks saame kasutada
   trait'e vaikese väärtuste jaoks, gruppeerida parameetreid objektide kaudu, viidata korduvatele val'idele, mis on määratletud ühes kohas (DRY) ulatuses. Saame otse konfiguratsioonis instantsi luua igasuguseid klasse (Seq, Map, kasutajate klassid).
3. DSL. Scalas on mitu keelelist võimalust, mis lihtsustavad DSL-i loomist. Saame neid võimalusi kasutada ja rakendada konfiguratsiooni keelt, mis oleks sihtrühmale mugavam, et konfiguratsioon oleks vähemalt valdkonna spetsialistide arusaadav. Spetsialistid saavad näiteks osaleda konfiguratsiooni ülevaatamise protsessis.
4. Terviklikkus ja sünkroonsus sõlmede vahel. Üks eelis, et terve hajutatud süsteemi konfiguratsioon on hoitud ühes kohas, on see, et kõik väärtused kuulutatakse välja ainult üks kord ja neid kasutatakse seejärel igal pool, kus neid vajatakse. Fantoomtüüpide kasutamine sadamate kuulutamiseks tagab, et kõik õiges süsteemi konfiguratsioonis kasutatavad sõlmed kasutavad ühilduvaid protokolle. Selgete nõutavate sõltuvuste olemasolu sõlmede vahel tagab, et kõik teenused on omavahel ühendatud.
5. Kõrge kvaliteedi muutused. Konfiguratsiooni muutmine üldise arendusprotsessi kaudu võimaldab saavutada kõrgemaid kvaliteedistandardeid ka konfiguratsiooni jaoks.
6. Samaaegne konfiguratsiooni värskendamine. Süsteemi automaatne levitamine pärast konfiguratsiooni muudatuste tegemist tagab, et kõik sõlmed uuendatakse.
7. Rakenduse lihtsustamine. Rakendus ei vaja analüüsi, konfiguratsiooni kontrolle ega vigaste väärtuste töötlemist. Seeläbi väheneb rakenduse keerukus. (Mõningane konfiguratsiooni keerukus, mis meie näites ilmneb, ei ole kompileeritava konfiguratsiooni omadus, vaid teadlik valik, mis tuleneb soovist tagada suurem tüübisõbralikkus.) Tavalise konfiguratsiooni juurde on üsna lihtne tagasi minna — lihtsalt rakendage puuduolevad osad. Seega võite alustada näiteks kompileeritava konfiguratsiooniga, lükates üleliigsete osade teostamise edasi ajaks, mil seda tõeliselt vajate.
8. Versiooniga konfiguratsioon. Kuna konfiguratsiooni muutused järgivad tavalist saatusese muudatuste, saame lõpuks ainulaadse versiooniga artefakti. See võimaldab meil näiteks naasta eelmise konfiguratsiooni versiooni juurde, kui vajadus tekib. Saame isegi kasutada aasta tagasi loodud konfiguratsiooni ning süsteem töötab täpselt sama moodi. Stabiilne konfiguratsioon parandab jaotatud süsteemi ettearvamatust ja usaldusväärsust. Kuna konfiguratsioon on fikseeritud kompileerimise etapis, on seda üsna keeruline tootmises valeandmetega segada.
9. Modulaarsus. Pakutav raamistik on modulaarne ning mooduleid saab erinevates kombinatsioonides ühendada erinevate süsteemide saamiseks. Eriti on võimalik ühes variandis konfigureerida süsteemi töötama ühel sõlmel, teises aga mitmel sõlmel. Saate luua mitu konfiguratsiooni tootmiseksemplaride jaoks.
10. Testimine. Asendades üksikud teenused makettide objektidega, on võimalik saada mitu süsteemi versiooni, mis on testimiseks mugavad.
11. Integreerimise testimine. Ühe konfiguratsiooni olemasolu kogu jaotatud süsteemis tagab kõikide koostisosade käivitamise võimaluse kontrollitud keskkonnas integreerimise testimise raames. Näiteks on lihtne emuleerida olukorda, kus mõned sõlmed muutuvad kättesaamatuks.

Puudused ja piirangud

Kompileeritav konfiguratsioon erineb teistest konfiguratsioonimeetoditest ja ei pruugi mõnede rakenduste jaoks sobida. Siin on mõned puudused:

1. Statiline konfiguratsioon. Mõnikord on vaja kiiresti parandada konfiguratsiooni tootmises, mööda minnes kõigist kaitsemehhanismidest. Selle lähenemise raames võib see olla keerulisem. Igatahes on kompileerimine ja automaatne juurutamine ikkagi vajalikud. See on samas nii kasulik omadus lähenemise puhul kui ka mõnes olukorras puudus.
2. Konfiguratsiooni genereerimine. Kui konfiguratsioonifail genereeritakse automaatse tööriistaga, võib tekkida vajadus täiendavate pingutuste järele skripti integreerimisel.
3. Tööriistakomplekt. Käesoleval hetkel põhinevad konfiguratsiooni haldamiseks mõeldud tööriistad ja meetodid tekstifailidel. Kõik sellised tööriistad/meetodid ei pruugi olla kergesti kättesaadavad kompileeritava konfiguratsiooni korral.
4. Vajadus muuta hoiakuid. Arendajad ja DevOps on harjunud tekstifailidega. Ideed konfiguratsiooni kompileerimisest võib pidada mõnevõrra üllatavaks ja ebatavaliseks ning see võib tekitada vastumeelsust.
5. Kvaliteetne arendusprotsess on vajalik. Mugavaks kompileeritava konfiguratsiooni kasutamiseks on vajalik täielik automatiseerimine rakenduse ehitus- ja juurutamisprotsessis (CI/CD). Muud tingimused võivad olla ebamugavad.

Vaadakem ka uuringu näite mõningaid piiranguid, mis ei ole seotud kompileeritava konfiguratsiooni ideega:

1. Kui pakume liigset konfiguratsiooni teavet, mis ei ole sõlme poolt kasutatav, ei aita kompilaator meil rakenduse puudumist avastada. Selle probleemi saab lahendada, loobudes Cake Pattern'ist ja kasutades rangemaid tüüpe, näiteks HList või algebralisi andmetüüpe (case class'id) konfiguratsiooni esitamiseks.
2. Konfiguratsioonifailis on read, mis ei kuulu otse konfiguratsiooni alla: (pakett, import, objektide deklaratsioonid; ülekirjutamise funktsioonMõned määrangud, millel on vaikimisi väärtused). Osaliselt on võimalik seda vältida, kui rakendada oma DSL-i. Samuti seavad muud konfiguratsiooni tüübid (näiteks XML) failistruktuurile teatud piirangud.
3. Selles postituses ei käsitle me sarnaste sõlmede klastrite dünaamilist rekonstrueerimist.

Kokkuvõte

Selles postituses vaatlesime ideed esitada konfiguratsiooni lähtekoodis, kasutades Scala tüüpsüsteemi arenenud võimalusi. Sellist lähenemist saab kasutada erinevates rakendustes traditsiooniliste XML- või tekstifailide põhiste konfiguratsioonimeetodite asendamiseks. Kuigi meie näide on rakendatud Scala-s, saab samu ideid rakendada ka teistes kompileeritavates keeltes (nt Kotlin, C#, Swift, jne). Seda lähenemist saab katsetada mõnes järgmistest projektidest ja juhul, kui see ei sobi, saab naasta tekstifailide juurde, lisades puuduolevad detailid.

Muidugi nõuab kompileeritav konfiguratsioon kvaliteetset arendusprotsessi. Vastutasuks tagatakse kõrge kvaliteet ja usaldusväärsus.

Käsitletud lähenemist saab laiendada:

1. Saab kasutada makrosid kontrollide teostamiseks kompileerimise ajal.
2. Saab rakendada DSL-i, et esitada konfiguratsiooni lõppkasutajatele arusaadavas vormis.
3. Saab rakendada dünaamilist ressursside haldust, mis automaatselt kohandab konfiguratsiooni. Näiteks, kui klastris sõlmede arv muutub, on vajalik, et (1) iga sõlm saab veidi erineva konfiguratsiooni; (2) klastrihaldur saaks teavet uute sõlmede kohta.

Tänud

Soovin tänada Andrei Saksonovit, Pavel Popovit ja Anton Nehaevit konstruktiivse kriitika eest artikli mustandi kohta.

Allikas: habr.com