Компајбилна конфигурација дистрибуираног система

У овом посту желимо да поделимо занимљив начин бављења конфигурацијом дистрибуираног система.
Конфигурација је представљена директно у Сцала језику на безбедан начин. Детаљно је описан пример имплементације. Разматрају се различити аспекти предлога, укључујући утицај на укупан процес развоја.

(на руском)

Увод

Изградња робусних дистрибуираних система захтева употребу исправне и кохерентне конфигурације на свим чворовима. Типично решење је коришћење текстуалног описа примене (терраформ, ансибле или нешто слично) и аутоматски генерисаних конфигурационих датотека (често — намењених за сваки чвор/улогу). Такође бисмо желели да користимо исте протоколе истих верзија на сваком комуникационом чвору (у супротном бисмо имали проблеме са некомпатибилношћу). У ЈВМ свету то значи да би бар библиотека за размену порука требало да буде исте верзије на свим комуникационим чворовима.

Шта је са тестирањем система? Наравно, требало би да имамо јединичне тестове за све компоненте пре него што пређемо на интеграцијске тестове. Да бисмо могли да екстраполирамо резултате тестирања на време извршавања, требало би да се уверимо да су верзије свих библиотека идентичне иу времену извођења иу окружењу тестирања.

Када покрећете интеграцијске тестове, често је много лакше имати исту путању класе на свим чворовима. Само треба да се уверимо да се иста путања класе користи при постављању. (Могуће је користити различите путање класа на различитим чворовима, али је теже представити ову конфигурацију и правилно је применити.) Дакле, да би ствари биле једноставне, размотрићемо само идентичне путање класа на свим чворовима.

Конфигурација има тенденцију да се развија заједно са софтвером. Обично користимо верзије да идентификујемо различите
фазе еволуције софтвера. Чини се разумним покрити конфигурацију под управљањем верзијама и идентификовати различите конфигурације са неким ознакама. Ако постоји само једна конфигурација у производњи, можемо користити једну верзију као идентификатор. Понекад можемо имати више производних окружења. А за свако окружење ће нам можда требати посебна грана конфигурације. Дакле, конфигурације могу бити означене граном и верзијом да би се на јединствен начин идентификовале различите конфигурације. Свака ознака гране и верзија одговарају једној комбинацији дистрибуираних чворова, портова, екстерних ресурса, верзија библиотеке путања класа на сваком чвору. Овде ћемо покрити само једну грану и идентификовати конфигурације помоћу трокомпонентне децималне верзије (1.2.3), на исти начин као и остали артефакти.

У савременим окружењима конфигурациони фајлови се више не мењају ручно. Обично генеришемо
конфигурационе датотеке у време примене и никада их не додирујте после. Дакле, неко би се могао запитати зашто још увек користимо текстуални формат за конфигурационе датотеке? Изводљива опција је да се конфигурација постави у јединицу за компилацију и да се искористи провера конфигурације у време компајлирања.

У овом посту ћемо испитати идеју чувања конфигурације у компајлираном артефакту.

Компабилна конфигурација

У овом одељку ћемо размотрити пример статичке конфигурације. Конфигуришу се и имплементирају две једноставне услуге - ехо сервис и клијент ехо сервиса. Затим се инстанцирају два различита дистрибуирана система са обе услуге. Један је за конфигурацију једног чвора, а други за конфигурацију два чвора.

Типичан дистрибуирани систем се састоји од неколико чворова. Чворови се могу идентификовати помоћу неког типа:

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

или само

case class NodeId(hostName: String)

или чак

object Singleton
type NodeId = Singleton.type

Ови чворови обављају различите улоге, покрећу неке услуге и требало би да буду у могућности да комуницирају са другим чворовима помоћу ТЦП/ХТТП веза.

За ТЦП везу је потребан бар број порта. Такође желимо да будемо сигурни да клијент и сервер разговарају истим протоколом. Да бисмо моделирали везу између чворова, хајде да декларишемо следећу класу:

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

где Port је само један Int у дозвољеном опсегу:

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

Рафинирани типови

видети пречишћен библиотека. Укратко, омогућава додавање временских ограничења за компајлирање другим типовима. У овом случају Int дозвољено је само да има 16-битне вредности које могу представљати број порта. Не постоји захтев за коришћење ове библиотеке за овај приступ конфигурацији. Само изгледа да се добро уклапа.

За ХТТП (РЕСТ) можда ће нам требати и путања услуге:

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

Фантомски тип

Да бисмо идентификовали протокол током компилације, користимо Сцала карактеристику декларисања аргумента типа Protocol који се не користи у разреду. То је тзв фантомски тип. У току рада ретко нам треба инстанца идентификатора протокола, зато је не чувамо. Током компилације овај фантомски тип даје додатну сигурност типа. Не можемо проћи порт са нетачним протоколом.

Један од најчешће коришћених протокола је РЕСТ АПИ са Јсон серијализацијом:

sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage]

где RequestMessage је основни тип порука које клијент може послати серверу и ResponseMessage је порука одговора са сервера. Наравно, можемо креирати друге описе протокола који специфицирају комуникациони протокол са жељеном прецизношћу.

За потребе овог поста користићемо једноставнију верзију протокола:

sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage]

У овом протоколу порука са захтевом се додаје УРЛ-у, а порука одговора се враћа као обичан стринг.

Конфигурација услуге се може описати именом услуге, колекцијом портова и неким зависностима. Постоји неколико могућих начина како све ове елементе представити у Сцали (нпр. HList, алгебарски типови података). За потребе овог поста користићемо узорке колача и представљати комаде (модуле) који се могу комбиновати као особине. (Узорак колача није услов за овај приступ конфигурације који се може компајлирати. То је само једна могућа имплементација идеје.)

Зависности се могу представити коришћењем узорка колача као крајњих тачака других чворова:

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

Ецхо сервису је потребан само конфигурисан порт. И изјављујемо да овај порт подржава ехо протокол. Имајте на уму да у овом тренутку не морамо да наводимо одређени порт, јер особина дозвољава декларације апстрактних метода. Ако користимо апстрактне методе, компајлер ће захтевати имплементацију у инстанци конфигурације. Овде смо обезбедили имплементацију (8081) и користиће се као подразумевана вредност ако је прескочимо у конкретној конфигурацији.

Можемо да прогласимо зависност у конфигурацији клијента услуге ехо:

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

Зависност има исти тип као и echoService. Конкретно, захтева исти протокол. Дакле, можемо бити сигурни да ће, ако повежемо ове две зависности, радити исправно.

Имплементација услуга

Сервису је потребна функција за покретање и грациозно гашење. (Могућност гашења сервиса је критична за тестирање.) Опет постоји неколико опција за одређивање такве функције за дату конфигурацију (на пример, могли бисмо да користимо класе типа). За овај пост ћемо поново користити Цаке Паттерн. Можемо представљати услугу користећи cats.Resource који већ обезбеђује заграде и ослобађање ресурса. Да бисмо набавили ресурс, требало би да обезбедимо конфигурацију и неки контекст времена извршавања. Дакле, функција покретања услуге може изгледати овако:

  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]
  }

где

• Config — тип конфигурације коју захтева овај стартер сервиса
• AddressResolver — рунтиме објекат који има могућност да добије стварне адресе других чворова (наставите да читате за детаље).

остали типови потичу из cats:

• F[_] — тип ефекта (У најједноставнијем случају F[A] могао бити праведан () => A. У овом посту ћемо користити cats.IO.)
• Reader[A,B] — је мање-више синоним за функцију A => B
• cats.Resource — има начина за стицање и ослобађање
• Timer — омогућава спавање/мерење времена
• ContextShift - аналог од ExecutionContext
• Applicative — омотач функција на снази (скоро монада) (могли бисмо га евентуално заменити нечим другим)

Користећи овај интерфејс можемо имплементирати неколико услуга. На пример, услуга која не ради ништа:

  trait ZeroServiceImpl[F[_]] extends ServiceImpl[F] {
    type Config <: Any
    def resource(...): ResourceReader[F, Config, Unit] =
      Reader(_ => Resource.pure[F, Unit](()))
  }

(Види Изворни код за имплементацију других услуга — ецхо сервице,
ецхо цлиент животни контролори.)

Чвор је један објекат који покреће неколико услуга (покретање ланца ресурса омогућава Цаке Паттерн):

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

Имајте на уму да у чвору наводимо тачан тип конфигурације који је потребан овом чвору. Компајлер нам не дозвољава да направимо објекат (Цаке) са недовољним типом, јер свака карактеристика услуге декларише ограничење на Config тип. Такође нећемо моћи да покренемо чвор без пружања комплетне конфигурације.

Резолуција адресе чвора

Да бисмо успоставили везу потребна нам је права адреса домаћина за сваки чвор. Можда ће бити познато касније од осталих делова конфигурације. Дакле, потребан нам је начин да обезбедимо мапирање између ИД-а чвора и његове стварне адресе. Ово мапирање је функција:

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

Постоји неколико могућих начина за имплементацију такве функције.

1. Ако знамо стварне адресе пре постављања, током инстанцирања хостова чворова, онда можемо да генеришемо Сцала код са стварним адресама и затим покренемо градњу (која врши проверу времена компајлирања, а затим покреће пакет за тестирање интеграције). У овом случају наша функција мапирања је статички позната и може се поједноставити на нешто попут а Map[NodeId, NodeAddress].
2. Понекад добијамо стварне адресе тек касније када је чвор стварно покренут, или немамо адресе чворова који још нису покренути. У овом случају можемо имати услугу откривања која се покреће пре свих осталих чворова и сваки чвор може да рекламира своју адресу у тој услузи и да се претплати на зависности.
3. Ако можемо да изменимо /etc/hosts, можемо користити унапред дефинисана имена хостова (нпр my-project-main-node echo-backend) и само повежите ово име са ИП адресом у време примене.

У овом посту не покривамо ове случајеве детаљније. У ствари, у нашем примеру играчке сви чворови ће имати исту ИП адресу - 127.0.0.1.

У овом посту ћемо размотрити два распореда дистрибуираног система:

1. Изглед једног чвора, где су све услуге смештене на једном чвору.
2. Изглед са два чвора, где су услуга и клијент на различитим чворовима.

Конфигурација за а један чвор распоред је следећи:

Конфигурација једног чвора

object SingleNodeConfig extends EchoConfig[String] 
  with EchoClientConfig[String] with FiniteDurationLifecycleConfig
{
  case object Singleton // identifier of the single node 
  // configuration of server
  type NodeId = Singleton.type
  def nodeId = Singleton

  /** Type safe service port specification. */
  override def portNumber: PortNumber = 8088

  // configuration of client

  /** We'll use the service provided by the same host. */
  def echoServiceDependency = echoService

  override def testMessage: UrlPathElement = "hello"

  def pollInterval: FiniteDuration = 1.second

  // lifecycle controller configuration
  def lifetime: FiniteDuration = 10500.milliseconds // additional 0.5 seconds so that there are 10 requests, not 9.
}

Овде креирамо једну конфигурацију која проширује конфигурацију сервера и клијента. Такође конфигуришемо контролер животног циклуса који ће након тога нормално прекинути клијента и сервера lifetime интервал пролази.

Исти скуп имплементација и конфигурација услуге може се користити за креирање распореда система са два одвојена чвора. Само треба да стварамо две одвојене конфигурације чвора са одговарајућим услугама:

Конфигурација два чвора

  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! dependency specification
    def echoServiceDependency = NodeServerConfig.echoService

    def pollInterval: FiniteDuration = 1.second

    def lifetime: FiniteDuration = 10500.milliseconds // additional 0.5 seconds so that there are 10 request, not 9.

    def testMessage: String = "dolly"
  }

Погледајте како специфицирамо зависност. Помињемо пружену услугу другог чвора као зависност од тренутног чвора. Тип зависности је проверен јер садржи фантомски тип који описује протокол. И током времена рада имаћемо исправан ИД чвора. Ово је један од важних аспеката предложеног приступа конфигурацији. Пружа нам могућност да само једном поставимо порт и да се уверимо да референцирамо исправан порт.

Имплементација два чвора

За ову конфигурацију користимо потпуно исте имплементације услуга. Нема никаквих промена. Међутим, ми креирамо две различите имплементације чвора које садрже различит скуп услуга:

  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
  }

Први чвор имплементира сервер и потребна му је само конфигурација на страни сервера. Други чвор имплементира клијента и треба му други део конфигурације. Оба чвора захтевају неке доживотне спецификације. За потребе ове поштанске услуге чвор ће имати бесконачан животни век који се може прекинути коришћењем SIGTERM, док ће ехо клијент прекинути након конфигурисаног коначног трајања. Видите стартер апликација за детаље.

Укупан процес развоја

Хајде да видимо како овај приступ мења начин на који радимо са конфигурацијом.

Конфигурација као код ће бити преведена и производи артефакт. Чини се разумним одвојити артефакт конфигурације од осталих артефаката кода. Често можемо имати мноштво конфигурација на истој бази кода. И наравно, можемо имати више верзија различитих конфигурационих грана. У конфигурацији можемо изабрати одређене верзије библиотека и то ће остати константно кад год применимо ову конфигурацију.

Промена конфигурације постаје промена кода. Дакле, требало би да буде покривен истим процесом осигурања квалитета:

Улазница -> ПР -> преглед -> спајање -> континуирана интеграција -> континуирана примена

Постоје следеће последице приступа:

1. Конфигурација је кохерентна за одређену инстанцу система. Чини се да не постоји начин да имате погрешну везу између чворова.
2. Није лако променити конфигурацију само у једном чвору. Чини се неразумним да се пријавите и промените неке текстуалне датотеке. Дакле, одступање конфигурације постаје мање могуће.
3. Мале промене конфигурације није лако направити.
4. Већина промена конфигурације ће пратити исти процес развоја и проћи ће неки преглед.

Да ли нам је потребно посебно спремиште за конфигурацију производње? Конфигурација производње може да садржи осетљиве информације које бисмо желели да држимо ван дохвата многих људи. Дакле, можда би било вредно чувати одвојено спремиште са ограниченим приступом које ће садржати конфигурацију производње. Конфигурацију можемо поделити на два дела – један који садржи најотвореније параметре производње и онај који садржи тајни део конфигурације. Ово би омогућило приступ већини програмера великој већини параметара док би се ограничио приступ заиста осетљивим стварима. То је лако постићи коришћењем средњих особина са подразумеваним вредностима параметара.

Варијације

Хајде да видимо предности и недостатке предложеног приступа у поређењу са другим техникама управљања конфигурацијом.

Пре свега, навешћемо неколико алтернатива за различите аспекте предложеног начина решавања конфигурације:

1. Текстуални фајл на циљној машини.
2. Централизовано складиште кључ/вредност (нпр etcd/zookeeper).
3. Компоненте потпроцеса које се могу поново конфигурисати/поново покренути без поновног покретања процеса.
4. Конфигурација ван контроле артефаката и верзија.

Текстуална датотека даје одређену флексибилност у смислу ад-хоц поправки. Администратор система може да се пријави на циљни чвор, изврши промену и једноставно поново покрене услугу. Ово можда неће бити добро за веће системе. Иза промена не остају никакви трагови. Промену не прегледа други пар очију. Можда ће бити тешко открити шта је изазвало промену. Није тестирано. Из перспективе дистрибуираног система, администратор може једноставно заборавити да ажурира конфигурацију у једном од других чворова.

(Бтв, ако на крају буде потребно да почнемо да користимо текстуалне конфигурационе датотеке, мораћемо само да додамо парсер + валидатор који би могао да произведе исто Config укуцајте и то би било довољно да почнете да користите текстуалне конфигурације. Ово такође показује да је сложеност конфигурације времена компајлирања мало мања од сложености конфигурација заснованих на тексту, јер нам је у верзији заснованој на тексту потребан додатни код.)

Централизовано складиште кључ/вредност је добар механизам за дистрибуцију мета параметара апликације. Овде треба да размислимо о томе шта сматрамо конфигурационим вредностима, а шта само подацима. Задата функција C => A => B обично називамо ретко променљивим вредностима C „конфигурација“, док често мењани подаци A - само унесите податке. Конфигурацију треба обезбедити функцији раније од података A. Имајући у виду ову идеју, можемо рећи да је очекивана учесталост промена оно што би се могло користити за разликовање конфигурационих података од само података. Такође подаци обично долазе из једног извора (корисника), а конфигурација долази из другог извора (администратора). Бављење параметрима који се могу променити након процеса иницијализације доводи до повећања сложености апликације. За такве параметре мораћемо да се бавимо њиховим механизмом испоруке, рашчлањивањем и валидацијом, руковањем нетачним вредностима. Стога, да бисмо смањили сложеност програма, боље би било да смањимо број параметара који се могу променити током извршавања (или их чак потпуно елиминисати).

Из перспективе овог поста требало би да направимо разлику између статичких и динамичких параметара. Ако логика сервиса захтева ретку промену неких параметара током рада, онда их можемо назвати динамичким параметрима. Иначе су статичне и могу се конфигурисати коришћењем предложеног приступа. За динамичку реконфигурацију могу бити потребни други приступи. На пример, делови система могу се поново покренути са новим конфигурационим параметрима на сличан начин као што се поново покреће одвојени процес дистрибуираног система.
(Моје скромно мишљење је да избегавам реконфигурацију времена извршавања јер то повећава сложеност система.
Можда би било једноставније ослонити се на подршку ОС-а за поновно покретање процеса. Мада, то можда није увек могуће.)

Један важан аспект коришћења статичке конфигурације који понекад наводи људе да размотре динамичку конфигурацију (без других разлога) је прекид сервиса током ажурирања конфигурације. Заиста, ако морамо да променимо статичку конфигурацију, морамо поново покренути систем како би нове вредности постале ефективне. Захтеви за време застоја се разликују за различите системе, тако да то можда није толико критично. Ако је критично, онда морамо унапред планирати било које поновно покретање система. На пример, могли бисмо да имплементирамо Пражњење АВС ЕЛБ везе. У овом сценарију кад год треба да поново покренемо систем, паралелно покрећемо нову инстанцу система, а затим пребацимо ЕЛБ на њу, док старом систему дозвољавамо да заврши сервисирање постојећих веза.

Шта је са држањем конфигурације унутар верзионисаног артефакта или споља? Одржавање конфигурације унутар артефакта значи у већини случајева да је ова конфигурација прошла исти процес осигурања квалитета као и други артефакти. Дакле, неко може бити сигуран да је конфигурација доброг квалитета и поуздана. Напротив, конфигурација у посебном фајлу значи да нема трагова ко је и зашто извршио измене у тој датотеци. Да ли је ово важно? Верујемо да је за већину производних система боље имати стабилну и квалитетну конфигурацију.

Верзија артефакта омогућава да се сазна када је креиран, које вредности садржи, које функције су омогућене/онемогућене, ко је одговоран за сваку промену у конфигурацији. Можда ће бити потребно мало труда да се конфигурација задржи унутар артефакта и то је избор дизајна.

Предност Мане

Овде бисмо желели да истакнемо неке предности и да размотримо неке недостатке предложеног приступа.

Предности

Карактеристике компајбилне конфигурације комплетног дистрибуираног система:

1. Статичка провера конфигурације. Ово даје висок ниво поверења, да је конфигурација исправна с обзиром на ограничења типа.
2. Богат језик конфигурације. Обично су други приступи конфигурацији ограничени на највише променљиве замене.
   Користећи Сцала може се користити широк спектар језичких карактеристика да би се конфигурација побољшала. На пример, можемо да користимо особине да обезбедимо подразумеване вредности, објекте за постављање различитог опсега, на које се можемо позивати valс дефинисан само једном у спољашњем опсегу (ДРИ). Могуће је користити литералне секвенце или инстанце одређених класа (Seq, Map, Итд).
3. ДСЛ. Сцала има пристојну подршку за ДСЛ писце. Ове функције се могу користити за успостављање конфигурационог језика који је погоднији и прилагођенији крајњем кориснику, тако да је коначна конфигурација барем читљива од стране корисника домена.
4. Интегритет и кохерентност међу чворовима. Једна од предности поседовања конфигурације за цео дистрибуирани систем на једном месту је да се све вредности дефинишу стриктно једном, а затим поново користе на свим местима где су нам потребне. Такође унесите декларације безбедног порта да обезбеде да ће у свим могућим исправним конфигурацијама чворови система говорити исти језик. Постоје експлицитне зависности између чворова што отежава заборављање пружања неких услуга.
5. Висок квалитет промена. Укупан приступ проласка промена конфигурације кроз нормалан ПР процес успоставља високе стандарде квалитета иу конфигурацији.
6. Истовремене промене конфигурације. Кад год извршимо било какве промене у конфигурацији, аутоматска примена осигурава да се сви чворови ажурирају.
7. Поједностављење апликације. Апликација не мора да анализира и проверава конфигурацију и рукује нетачним вредностима конфигурације. Ово поједностављује целокупну апликацију. (Неки пораст сложености је у самој конфигурацији, али то је свестан компромис ка безбедности.) Прилично је једноставно вратити се на уобичајену конфигурацију — само додајте делове који недостају. Лакше је започети са компајлираном конфигурацијом и одложити имплементацију додатних делова за нека каснија времена.
8. Версионирана конфигурација. Због чињенице да промене конфигурације прате исти процес развоја, као резултат добијамо артефакт са јединственом верзијом. Омогућава нам да вратимо конфигурацију ако је потребно. Можемо чак да применимо конфигурацију која је коришћена пре годину дана и она ће функционисати на потпуно исти начин. Стабилна конфигурација побољшава предвидљивост и поузданост дистрибуираног система. Конфигурација је фиксирана у време компајлирања и не може се лако мењати у производном систему.
9. Модуларност. Предложени оквир је модуларан и модули се могу комбиновати на различите начине
   подржавају различите конфигурације (поставке/изгледи). Конкретно, могуће је имати мали распоред једног чвора и поставку више чворова великог обима. Разумно је имати више распореда производње.
10. Тестирање. За потребе тестирања може се имплементирати лажна услуга и користити је као зависност на безбедан начин. Неколико различитих распореда тестирања са различитим деловима замењеним лажним може се одржавати истовремено.
11. Интеграционо тестирање. Понекад је у дистрибуираним системима тешко покренути интеграцијске тестове. Користећи описани приступ безбедној конфигурацији комплетног дистрибуираног система, можемо покренути све дистрибуиране делове на једном серверу на контролисан начин. Лако је опонашати ситуацију
    када једна од услуга постане недоступна.

Мане

Приступ компајлиране конфигурације се разликује од „нормалне“ конфигурације и можда неће одговарати свим потребама. Ево неких недостатака компајлиране конфигурације:

1. Статичка конфигурација. Можда није погодан за све апликације. У неким случајевима постоји потреба за брзим фиксирањем конфигурације у производњи заобилазећи све сигурносне мере. Овај приступ отежава. Компилација и поновно распоређивање су потребни након било какве промене у конфигурацији. Ово је и карактеристика и терет.
2. Генерисање конфигурације. Када конфигурацију генерише неки алат за аутоматизацију, овај приступ захтева накнадну компилацију (која би заузврат могла да не успе). Можда ће бити потребни додатни напори да се овај додатни корак интегрише у систем изградње.
3. Инструменти. Данас је у употреби много алата који се ослањају на конфигурације засноване на тексту. Неки од њих
   неће бити применљиво када се конфигурација компајлира.
4. Потребна је промена у начину размишљања. Програмери и ДевОпс су упознати са текстуалним конфигурационим датотекама. Идеја о компајлирању конфигурације могла би им изгледати чудна.
5. Пре увођења компајбилне конфигурације потребан је процес развоја софтвера високог квалитета.

Постоје нека ограничења имплементираног примера:

1. Ако обезбедимо додатну конфигурацију коју имплементација чвора не захтева, компајлер нам неће помоћи да откријемо одсуство имплементације. Ово би се могло решити коришћењем HList или АДТ (класе случајева) за конфигурацију чвора уместо особина и узорка колача.
2. Морамо да обезбедимо неки шаблон у конфигурационој датотеци: (package, import, object декларације;
   override def'с за параметре који имају подразумеване вредности). Ово се може делимично решити коришћењем ДСЛ-а.
3. У овом посту не покривамо динамичку реконфигурацију кластера сличних чворова.

Закључак

У овом посту смо разговарали о идеји представљања конфигурације директно у изворном коду на безбедан начин. Приступ би се могао користити у многим апликацијама као замена за кмл и друге текстуалне конфигурације. Упркос томе што је наш пример имплементиран у Сцала-у, могао би се превести и на друге компајбилне језике (као што су Котлин, Ц#, Свифт, итд.). Овај приступ би се могао испробати у новом пројекту и, у случају да се не уклапа добро, прећи на стари начин.

Наравно, компилибилна конфигурација захтева висок квалитет процеса развоја. Заузврат, обећава да ће обезбедити једнако квалитетну робусну конфигурацију.

Овај приступ се може проширити на различите начине:

1. Могли би се користити макрои да би се извршила валидација конфигурације и да не успе у време компајлирања у случају неуспеха било каквих ограничења пословне логике.
2. ДСЛ би се могао имплементирати да представља конфигурацију на начин прилагођен кориснику домена.
3. Динамичко управљање ресурсима са аутоматским подешавањима конфигурације. На пример, када прилагодимо број чворова кластера, можда бисмо желели (1) да чворови добију мало измењену конфигурацију; (2) менаџер кластера за примање информација о новим чворовима.

хвала

Желео бих да се захвалим Андреју Саксонову, Павлу Попову, Антону Нехајеву што су дали инспиративне повратне информације о нацрту овог поста које су ми помогле да то буде јасније.

Извор: ввв.хабр.цом