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

Искам да представя един интересен механизъм за работа с конфигурацията на разпределена система. Конфигурацията е представена директно на компилируем език (Scala) чрез безопасни типове. В този пост ще разгледаме пример за такава конфигурация и различни аспекти на внедряването на компилируемата конфигурация в общия процес на разработка.

(english)

Въведение

Създаването на надеждна разпределена система предполага, че на всички възли е използвана коректна конфигурация, синхронизирана с останалите възли. Обикновено се използват DevOps технологии (terraform, ansible или подобни) за автоматично генериране на конфигурационни файлове (често уникални за всеки възел). Също така нашето желание е да сме сигурни, че на всички взаимодействуващи възли се използват идентични протоколи (включително, същата версия). В противен случай в нашата разпределена система ще възникне несъвместимост. В света на JVM едно от следствията на това изискване е необходимостта от използването навсякъде на една и съща версия на библиотеката, съдържаща съобщенията на протокола.

Какво ще кажете за тестването на разпределена система? Разбира се, предвиждаме, че за всички компоненти са предвидени unit тестове, преди да преминем към интеграционното тестване. (За да можем да екстраполираме резултатите от тестването на runtime, ние също трябва да осигурим идентичен набор от библиотеки в етапа на тестване и в runtime.)

При работа с интеграционни тестове обикновено е по-лесно да се използват единни classpath на всички възли. Остава ни само да осигурим, че същият classpath е зает и в runtime. (Въпреки че е напълно възможно да се стартират различни възли с различни classpath, това води до усложняване на цялата конфигурация и трудности с разгръщането и интеграционните тестове.) В рамките на този пост изходната точка е, че на всички възли ще се използва един и същ classpath.

Конфигурацията се развива заедно с приложението. За идентифициране на различните етапи на еволюция на софтуера използваме версии. Също така е логично да идентифицираме и различни версии на конфигурациите. А самата конфигурация да бъде поставена в система за контрол на версиите. Ако в продукция съществува само една конфигурация, можем да използваме просто номер на версия. Ако обаче се използват множество инстанции на продукция, ще ни е необходима допълнителна
клонове на конфигурацията и допълнителна етикета, различна от версията (например, името на клона). Така ще можем точно да идентифицираме конкретната конфигурация. Всеки идентификатор на конфигурация уникално отговаря на определена комбинация от разпределени възли, портове, външни ресурси и версии на библиотеки. В рамките на този пост ще приемем, че има само един клон и можем да идентифицираме конфигурацията по обичайния начин използвайки три числа, разделени с точка (1.2.3).

В съвременните среди конфигурационните файлове рядко се създават ръчно. Най-често те се генерират по време на разгръщане и след това не се променят (за да не се счупят). Изниква закономерен въпрос: защо все още използваме текстов формат за съхранение на конфигурацията? Един жизнеспособен алтернативен вариант е да се използва обикновен код за конфигурация и да се получат предимства чрез проверки по време на компилацията.

В настоящия пост изследваме идеята за представяне на конфигурацията в рамките на компилирания артефакт.

Компилируема конфигурация

В този раздел се разглежда пример за статична компилируема конфигурация. Реализират се два прости услуги — echo услуга и клиент на echo услугата. На базата на тези два услуги се изграждат два варианта на системата. В един вариант и двете услуги се намират на един възел, а в другия вариант — на различни възли.

Обикновено разпределената система съдържа няколко възела. Възлите могат да бъдат идентифицирани с помощта на стойности от определен тип NodeId:

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

или

case class NodeId(hostName: String)

или дори

object Singleton
type NodeId = Singleton.type

Възлите изпълняват различни роли, на тях са стартирани услуги и между тях могат да бъдат установени TCP/HTTP връзки.

За да опишем TCP свързване, ни е необходим най-малко номер на порта. Също така искаме да отразим протокола, който се поддържа на този порт, за да гарантираме, че и клиентът, и сървърът използват един и същ протокол. Ще опишем свързването с помощта на следния клас:

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

където Порт — просто цяло число Int с указание на диапазона на допустимите стойности:

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

Уточнени типове

Вижте библиотеката refined и мой доклад. Накратко, библиотеката позволява да добавите ограничения към типовете, проверявани на етапа на компилация. В този случай допустимите стойности на номера на порта са цели 16-битови числа. За компилираната конфигурация използването на библиотеката refined не е задължително, но позволява да се подобри способността на компилатора за проверка на конфигурацията.

За HTTP (REST) протоколите, освен номера на порта, може да се нуждаем и от пътя към услугата:

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

Фантомни типове

За идентифициране на протокола на етапа на компилация използваме параметър от тип, който не се използва в самия клас. Такова решение е свързано с факта, че в време на изпълнение не използваме инстанцията на протокола, но искаме компилаторът да провери съвместимостта на протоколите. Чрез указването на протокола няма да можем да предадем неподходяща услуга като зависимост.

Един от разпространените протоколи е REST API с Json-сериализация:

sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage]

където RequestMessage — тип на заявката, ResponseMessage — тип на отговора.
Разбира се, могат да се използват и други описания на протоколите, които осигуряват необходимата ни прецизност на описанието.

За целите на настоящия пост ще използваме опростена версия на протокола:

sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage]

Тук заявката представлява низ, добавен към url, а отговорът — връщан низ в тялото на HTTP отговора.

Конфигурацията на услугата се описва с името на услугата, портовете и зависимостите. Тези елементи могат да бъдат представени в Scala по няколко начина (например, HList-ите, алгебрични типове данни). За целите на настоящия пост ще използваме Cake Pattern и ще представим модулите с помощта на trait‘и. (Cake Pattern не е задължителен елемент от описания подход. Това е просто една от възможните реализации.)

Зависимостите между услугите могат да бъдат представени под формата на методи, които връщат портовете на EndPoint‘ите на другите възли:

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

За създаването на ехо-сервис е достатъчно само номерът на порта и указанието, че този порт поддържа ехо-протокола. Можехме да не указваме конкретен порт, тъй като trait-овете позволяват да декларираме методи без реализация (абстрактни методи). В този случай при създаването на конкретна конфигурация компилаторът щеше да изисква от нас да предоставим реализация на абстрактния метод и да посочим номер на порта. Тъй като реализирахме метода, при създаването на конкретна конфигурация можем да не указваме друг порт. Ще бъде използвана стойността по подразбиране.

В конфигурацията на клиента декларираме зависимост от ехо-сервиса:

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

Зависимостта има същия тип, както и експортирания сервис echoService. В частност, в ехо-клиента изискваме същия протокол. Следователно при свързването на двата сервиса можем да бъдем уверени, че всичко ще работи коректно.

Реализация на сервисите

За стартиране и спиране на сервиса е необходима функция. (Възможността за спиране на сервиса е критично важна за тестването.) Отново има няколко варианта за реализация на такава функция (например, можем да използваме класове типове, основаващи се на типа конфигурация). За целите на настоящия пост ще използваме Cake Pattern. Ще представим сервиса с помощта на клас 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]
  }

където

• Конфигурация — тип на конфигурация за този сервис
• AddressResolver — обект на време за изпълнение, който позволява да разберем адресите на другите възли (вж. по-долу)

и останалите типове от библиотеката cats:

• F[_] — тип ефект (в най-простия случай F[A] може да бъде просто функция () => A. В настоящия пост ще използваме cats.IO.)
• Reader[A,B] — по-близък синоним на функция A => B
• cats.Resource — ресурс, който може да бъде получен и освободен
• Timer — таймер (позволява да спим за определено време и да измерваме времеви интервали)
• ContextShift — аналог ExecutionContext
• Applicative — клас от тип ефект, позволяващ комбинирането на отделни ефекти (почти монада). В по-сложни приложения, очевидно, е по-добре да се използва Monad/ConcurrentEffect.

Използвайки тази сигнатура на функцията, можем да реализираме няколко сервиса. Например, сервис, който нищо не прави:

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

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

Възелът представлява обект, който може да стартира няколко услуги (стартирането на веригата от ресурси се осигурява чрез Cake Pattern):

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

Обърнете внимание, че посочваме точния тип конфигурация, която е необходима за този възел. Ако пропуснем да посочим някой от типовете конфигурация, изисквани от отделна услуга, ще възникне грешка при компилацията. Също така, не можем да стартираме възел, ако не предоставим някакъв обект с подходящ тип, съдържащ всички необходими данни.

Разрешаване на имена на възли

За да се свържем с отдалечен възел, ни е необходим реален IP адрес. Възможно е адресът да стане известен по-късно от останалите части на конфигурацията. Ето защо ни трябва функция, която да отразява идентификатора на възела в адрес:

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

Можем да предложим няколко начина за реализиране на такава функция:

1. Ако адресите станат известни преди разгръщането, можем да генерираме Scala код с
   адресите и след това да стартираме компилация. При това ще се извърши компилация и ще се изпълнят тестове.
   В такъв случай функцията ще бъде известна статично и може да бъде представена в кода под формата на отразяване Map[NodeId, NodeAddress].
2. В някои случаи валидният адрес става известен само след стартиране на възела.
   В този случай можем да реализираме „услуга за откритие“ (discovery), която се стартира преди останалите възли и всички възли ще се регистрират в тази услуга и ще запитват адресите на другите възли.
3. Ако можем да модифицираме /etc/hosts, можем да използваме предварително определени имена на хостове (като my-project-main-node и echo-backend) и просто да свързваме тези имена
   с IP адресите по време на разгръщането.

В рамките на настоящото пост ние няма да разглеждаме тези случаи по-подробно. За нашия
играчки пример всички възли ще имат един IP адрес — 127.0.0.1.

По-долу ще разгледаме два варианта на разпределена система:

1. Разполагане на всички услуги на един възел.
2. И разполагане на ехо услугата и ехо клиента на различни възли.

Конфигурация за един възел:

Конфигурация за един възел

обект SingleNodeConfig разширява EchoConfig[String] 
  с EchoClientConfig[String] с FiniteDurationLifecycleConfig
{
  случайен обект Singleton \/\/ идентификатор на единствения възел 
  \/\/ конфигурация на сървъра
  тип NodeId = Singleton.type
  деф nodeId = Singleton

  \/** Спецификация на безопасен тип за порт на услугата. *\/ 
  преоверете деф portNumber: PortNumber = 8088

  \/\/ конфигурация на клиента

  \/** Ще използваме услугата, предоставяна от същия хост. *\/ 
  деф echoServiceDependency = echoService

  преоверете деф testMessage: UrlPathElement = "hello"

  деф pollInterval: FiniteDuration = 1.second

  \/\/ конфигурация на контролера на жизнения цикъл
  деф lifetime: FiniteDuration = 10500.milliseconds \/\/ допълнителни 0.5 секунди, за да се постигнат 10 заявки, а не 9.
}

Обектът реализира конфигурацията и на клиента, и на сървъра. Също така се използва конфигурация на времето на живот, за да приключи работата на програмата след изтичането на интервал жизнен цикъл програмата да се затвори. (Ctrl-C също работи и правилно освобождава всички ресурси.)

Същият набор от trait'ове за конфигурация и реализации може да се използва за създаване на система, състояща се от две отделни възли:

Конфигурация за два възела

  обект NodeServerConfig разширява EchoConfig[String] с SigTermLifecycleConfig
  {
    тип NodeId = NodeIdImpl

    деф nodeId = NodeServer

    преоверете деф portNumber: PortNumber = 8080
  }

  обект NodeClientConfig разширява EchoClientConfig[String] с FiniteDurationLifecycleConfig
  {
    \/\/ NB! спецификация на зависимост
    деф echoServiceDependency = NodeServerConfig.echoService

    деф pollInterval: FiniteDuration = 1.second

    деф lifetime: FiniteDuration = 10500.milliseconds \/\/ допълнителни 0.5 секунди, за да се постигнат 10 заявки, а не 9.

    деф testMessage: String = "dolly"
  }

Важно! Обърнете внимание как се извършва свързването на услуги. Посочваме услугата, реализирана от един възел, като реализация на метода-зависимост на другия възел. Типът на зависимостта се проверява от компилатора, тъй като съдържа типа на протокола. При стартиране зависимостта ще съдържа правилния идентификатор на целевия възел. Благодарение на тази схема посочваме номера на порта само веднъж и винаги гарантирано посочваме правилния порт.

Реализация на два възела на системата

За тази конфигурация използваме същите реализации на услуги, без промени. Единствената разлика е, че сега имаме два обекта, реализиращи различни набори от услуги:

  обект TwoJvmNodeServerImpl разширява ZeroServiceImpl[IO] с EchoServiceService и SigIntLifecycleServiceImpl {
    тип Config = EchoConfig[String] с SigTermLifecycleConfig
  }

  обект TwoJvmNodeClientImpl разширява ZeroServiceImpl[IO] с EchoClientService и FiniteDurationLifecycleServiceImpl {
    тип Config = EchoClientConfig[String] с FiniteDurationLifecycleConfig
  }

Първият възел реализира сървър и се нуждае само от сървърна конфигурация. Вторият възел реализира клиент и използва друга част от конфигурацията. Също така, и двата възела се нуждаят от управление на жизнения цикъл. Сървърният възел работи неограничено дълго, докато не бъде спиран SIGTERMот клиента, а клиентският възел завършва след известно време. Вижте приложението за стартиране.

Общият процес на разработка

Да видим как този подход към конфигурирането влияе на общия процес на разработка.

Конфигурацията ще бъде компилирана заедно с останалия код и ще бъде генериран артефакт (.jar). Явно е смислено да се постави конфигурацията в отделен артефакт. Това е свързано с факта, че може да имаме множество конфигурации, основани на един и същ код. Отново, може да се генерират артефакти, съответстващи на различни клонове на конфигурацията. Заедно с конфигурацията се запазват зависимости от конкретни версии на библиотеките и тези версии се запазват завинаги, когато и да решим да внедрим тази версия на конфигурацията.

Всяка промяна в конфигурацията се превръща в промяна в кода. Следователно, всяка такава
промяна ще бъде обхваната от обичайния процес на осигуряване на качество:

Билет в багтракера -> PR -> преглед -> сливане с отговорните клонове ->
интеграция -> разгръщане

Основните последствия от внедряването на компилируема конфигурация:

1. Конфигурацията ще бъде синхронизирана на всички възли на разпределената система. Поради факта, че всички възли получават същата конфигурация от един единствен източник.

2. Проблематично е да промените конфигурацията само в един от възлите. Следователно „дисинхронизация на конфигурацията“ (configuration drift) е малко вероятна.

3. Става все по-трудно да се правят малки промени в конфигурацията.

4. По-голямата част от промените в конфигурацията ще се извършват в рамките на общия процес на разработка и ще подлежат на ревю.

Нужен ли е отделен репозиторий за съхранение на production конфигурацията? В такава конфигурация могат да се съдържат пароли и друга секретна информация, достъпът до която бихме искали да ограничим. Исходя от това, очевидно има смисъл да се съхранява крайната конфигурация в отделен репозиторий. Може да се раздели конфигурацията на две части — една, съдържаща публичните параметри на конфигурацията, и друга, съдържаща параметрите с ограничен достъп. Това ще позволи на повечето разработчици да имат достъп до общите параметри. Такова разпределение не е трудно да се постигне, използвайки междинни trait-ове, съдържащи стойности по подразбиране.

Възможни вариации

Нека се опитаме да сравним компилираната конфигурация с някои разпространени алтернативи:

1. Текстов файл на целевата машина.
2. Централизирано хранилище ключ-стойност (etcd/zookeeper).
3. Компоненти на процеса, които могат да бъдат реконфигурирани/рестартирани без ребут на процеса.
4. Съхранение на конфигурацията извън артефакта и контрол на версиите.

Текстовите файлове предоставят значителна гъвкавост относно малките промени. Системният администратор може да влезе в отдалечен възел, да направи промени в съответните файлове и да рестартира услугата. За големи системи обаче такава гъвкавост може да е нежелателна. От направените промени не остават следи в другите системи. Никой не извършва преглед на промените. Трудно е да се установи кой точно е направил промените и по каква причина. Промените не се тестват. Ако системата е разпределена, администраторът може да забрави да направи съответната промяна на другите възли.

(Също така е важно да се отбележи, че използването на компилирана конфигурация не изключва възможността за използване на текстови файлове в бъдеще. Достатъчно е да се добави парсер и валидатор, които да дават на изхода същия тип Конфигурация, и може да се използват текстови файлове. Оттук следва, че сложността на системата с компилирана конфигурация е малко по-малка от сложността на система, която използва текстови файлове, тъй като за текстовите файлове е необходим допълнителен код.)

Централизирано хранилище ключ-стойност е добър механизъм за разпределение на мета-параметрите на разпределеното приложение. Трябва да определим какво представляват конфигурационните параметри и какво - просто данни. Нека имаме функция C => A => B, като параметрите C рядко се променят, а данните A — често. В този случай можем да кажем, че C — конфигурационни параметри, а A — данни. Изглежда, че конфигурационните параметри се различават от данните по това, че обикновено се променят по-рядко от данните. Също така данните обикновено идват от един източник (от потребителя), а конфигурационните параметри - от друг (от администратора на системата).

Ако параметрите, които рядко се променят, трябва да се обновяват без рестартиране на програмата, то често това може да доведе до усложнение на програмата, тъй като ще ни трябва по някакъв начин да доставяме параметрите, да ги съхраняваме, парсваме и проверяваме, и да обработваме некоректни стойности. Следователно, от гледна точка на намаляване на сложността на програмата, има смисъл да се намали броят на параметрите, които могат да се променят по време на работата на програмата (или изобщо да не се поддържат такива параметри).

От гледна точка на настоящия пост, ще разграничим статични и динамични параметри. Ако логиката на работа на услугата изисква промяна на параметрите по време на изпълнение на програмата, ще наречем тези параметри динамични. В противен случай, параметрите са статични и могат да бъдат конфигурирани с помощта на компилирана конфигурация. За динамична реконфигурация може да се наложи механизъм за рестартиране на части от програмата с нови параметри, подобно на това как протича рестартирането на процесите в операционната система. (По наше мнение, е желателно да се избягва реконфигурацията в реално време, тъй като сложността на системата нараства. Ако е възможно, е по-добре да се използват стандартните възможности на ОС за рестартиране на процесите.)

Един от важните аспекти на използването на статична конфигурация, който кара хората да разглеждат динамичното реконфигуриране, е времето, необходимо на системата да се рестартира след актуализация на конфигурацията (downtime). Всъщност, ако е необходимо да направим промени в статичната конфигурация, ще трябва да рестартираме системата, за да влязат новите стойности в сила. Проблемът с downtime-а има различна острота за различни системи. В някои случаи рестартирането може да бъде планирано за време, когато натоварването е минимално. В случай, че е необходимо да се осигури непрекъсната услуга, може да се реализира «отводняване на връзките» (AWS ELB connection draining). Когато е необходимо да рестартираме системата, стартираме паралелен екземпляр на тази система, пренасочваме балансиращия механизъм към него и изчакваме, докато старите връзки приключат. След като всички стари връзки приключат, изключваме стария екземпляр на системата.

Нека сега разгледаме въпроса за съхранение на конфигурацията вътре в артефакта или извън него. Ако съхраняваме конфигурацията вътре в артефакта, поне имаме възможност по време на изграждането на артефакта да се уверим в коректността на конфигурацията. В случай, че конфигурацията е извън контролирания артефакт, е трудно да се проследи кой и защо е направил промени в този файл. Каква е важността на това? На нашето мнение, за много production системи е важно да имат стабилна и висококачествена конфигурация.

Версия на артефакта позволява да се определи кога е създаден, какви стойности съдържа, какви функции са включени/изключени и кой носи отговорност за всякакви изменения в конфигурацията. Разбира се, съхранението на конфигурацията в артефакта изисква усилия, затова трябва да се вземе осъзнато решение.

За и против

Бих искал да се спра на предимствата и недостатъците на предлаганата технология.

Предимства

По-долу е списък с основните възможности на компилираната конфигурация на разпределена система:

1. Статична проверка на конфигурацията. Позволява да бъдем сигурни, че
   конфигурацията е коректна.
2. Богат език за конфигурация. Обикновено другите методи за конфигуриране са ограничени максимум до подмяна на стрингови променливи. При използване на Scala става достъпен широк спектър от възможности на езика за подобряване на конфигурацията. Например, можем да използваме
   trait'ове за стойности по подразбиране, с помощта на обекти да групираме параметри, можем да се позовем на val'ове, обявени единствено веднъж (DRY) в обхващащата видимост. Можем директно в конфигурацията да инстанцираме всякакви класове (Seq, Map, потребителски класове).
3. DSL. В Scala има редица езикови възможности, улесняващи създаването на DSL. Можем да се възползваме от тези възможности и да реализираме език за конфигурация, който да бъде по-удобен за целевата група потребители, така че конфигурацията да бъде поне четима от специалистите в съответната област. Специалистите могат, например, да участват в процеса на преглед на конфигурацията.
4. Цялостност и синхронност между възлите. Едно от предимствата на това, че конфигурацията на цялата разпределена система се съхранява на едно място, е, че всички стойности се обявяват точно веднъж и след това се преизползват навсякъде, където са необходими. Използването на фантомни типове за обявяване на портове позволява да се гарантира, че във всички коректни конфигурации на системата възлите използват съвместими протоколи. Наличието на ясни задължителни зависимости между възлите гарантира, че всички услуги ще бъдат свързани помежду си.
5. Високо качество на измененията. Изменения в конфигурацията, извършвани с общ процес на разработка, правят високите стандарти за качество достъпни и за конфигурацията.
6. Синхронно обновление на конфигурацията. Автоматичното разгръщане на системата след изменения в конфигурацията гарантира, че всички възли ще бъдат обновени.
7. Оптимизация на приложението. Приложението не изисква парсинг, проверка на конфигурацията и обработка на невалидни стойности. Това намалява сложността на приложението. (Някои усложнения на конфигурацията, наблюдавани в нашия пример, не са характеристика на компилираяемата конфигурация, а само осъзнато решение, породено от желанието за по-голяма типобезопасност.) Лесно е да се върнем обратно към обикновената конфигурация — просто реализирайте отсъстващите части. Следователно можем, например, да започнем с компилируема конфигурация, отлагайки реализирането на излишните части за времето, когато наистина са необходими.
8. Версионирана конфигурация. Тъй като конфигурационните промени следват същата съдба като всякакви други изменения, в края получаваме артефакт с уникална версия. Това ни позволява, например, да се върнем към предишна версия на конфигурацията при необходимост. Можем дори да се възползваме от конфигурация от преди година, и системата ще функционира точно така. Стабилната конфигурация увеличава предвидимостта и надеждността на разпределената система. Тъй като конфигурацията е фиксирана на етапа на компилация, тя е доста трудна за фалшифициране в производството.
9. Модуларност. Предложеният фреймуърк е модулен, и модулите могат да бъдат комбинирани в различни варианти за получаване на различни системи. В частност, може да се конфигурира система за работа на един възел в един вариант, а в друг — на няколко възли. Могат да бъдат създадени няколко конфигурации за производствени инстанции на системата.
10. Тестиране. Замествайки отделни услуги с mock-обекти, можем да получим няколко версии на системата, удобни за тестване.
11. Интеграционно тестване. Наличието на единна конфигурация на цялата разпределена система осигурява възможността за стартиране на всички компоненти в контролирана среда в рамките на интеграционното тестване. Лесно е да се емулира, например, ситуация, в която някои възли стават недостъпни.

Недостатъци и ограничения

Компилираната конфигурация се различава от другите подходи за конфигуриране и за някои приложения може да не е подходяща. По-долу са изброени някои недостатъци:

1. Статична конфигурация. Понякога се изисква бързо да се поправи конфигурацията в продукционна среда, пропускайки всички защитни механизми. В рамките на този подход това може да бъде по-трудно. Най-малкото компилацията и автоматичното разгръщане все пак ще бъдат необходими. Това е едновременно полезна характеристика на подхода и недостатък в някои случаи.
2. Генериране на конфигурация. В случай, че конфигурационният файл се генерира от автоматичен инструмент, може да се наложат допълнителни усилия за интегриране на скрипта за сборка.
3. Инструменти. В момента утилитите и методите, предназначени за работа с конфигурация, са основани на текстови файлове. Не всички такива утилити/методи ще бъдат налични при компилираната конфигурация.
4. Необходимо е изменение на нагласите. Разработчиците и DevOps са свикнали с текстовите файлове. Самата идея за компилация на конфигурация може да бъде донякъде неочаквана и нетипична, предизвиквайки отхвърляне.
5. Необходим е висококачествен процес на разработка. За да се работи удобно с компилирана конфигурация, е необходима пълна автоматизация на процеса на сборка и разгръщане на приложението (CI/CD). В противен случай ще бъде доста неудобно.

Ще разгледаме също така редица ограничения на разглеждания пример, които не са свързани с идеята за компилирана конфигурация:

1. Ако предоставим излишна конфигурационна информация, която не се използва от възела, компилаторът няма да ни помогне да открием отсъствието на реализация. Този проблем може да бъде решен, ако се откажем от Cake Pattern и използваме по-строги типове, например, HList или алгебрични типове данни (case класове) за представяне на конфигурация.
2. В конфигурационния файл има низове, които не се отнасят конкретно към конфигурацията: (пакет, import, декларации на обекти; преобразувам defЗа параметри с подразбирани стойности). Частично може да се избегне, ако реализирате свой DSL. Освен това, други видове конфигурация (например, XML) също налагат определени ограничения на структурата на файла.
3. В рамките на тази публикация не разглеждаме динамичната реконфигурация на клъстери от подобни възли.

Заключение

В тази публикация разгледахме идеята за представяне на конфигурацията в изходния код, като използваме разширените възможности на типичната система на Scala. Този подход може да намери приложение в различни програми като заместител на традиционните методи за конфигуриране, базирани на xml или текстови файлове. Въпреки че нашият пример е реализиран на Scala, същите идеи могат да бъдат пренесени в други компилируеми езици (като Kotlin, C#, Swift и т.н.). Този подход може да бъде изпитан в един от следващите проекти и, ако не се окаже подходящ, да преминете към текстови файлове, добавяйки липсващите детайли.

Естествено, компилируемата конфигурация изисква висококачествен процес на разработка. В замяна се осигурява високо качество и надеждност на конфигурациите.

Разгледаният подход може да бъде разширен:

1. Могат да се използват макроси за извършване на проверки по време на компилация.
2. Може да се реализира DSL за представяне на конфигурацията в достъпен формат за крайните потребители.
3. Може да се реализира динамично управление на ресурсите с автоматична настройка на конфигурацията. Например, при промяна на броя на възлите в клъстера е необходимо да (1) всеки възел получи малко различна конфигурация; (2) мениджърът на клъстера да получи информация за новите възли.

Благодарности

Благодаря на Андрей Саксонов, Павел Попов и Антон Нехаев за конструктивната критика на черновата на статията.

Източник: habr.com