განაწილებული სისტემის კომპილირებადი კონფიგურაცია

ამ პოსტში გვსურს გაგიზიაროთ განაწილებული სისტემის კონფიგურაციის მოგვარების საინტერესო გზა.
კონფიგურაცია წარმოდგენილია პირდაპირ სკალას ენაზე უსაფრთხო ტიპის სახით. განხორციელების მაგალითი დეტალურად არის აღწერილი. განიხილება წინადადების სხვადასხვა ასპექტები, მათ შორის გავლენა საერთო განვითარების პროცესზე.

(на русском)

შესავალი

ძლიერი განაწილებული სისტემების აშენება მოითხოვს სწორი და თანმიმდევრული კონფიგურაციის გამოყენებას ყველა კვანძზე. ტიპიური გამოსავალი არის ტექსტური განლაგების აღწერილობის გამოყენება (ტერაფორმული, ანსიბილი ან მსგავსი) და ავტომატურად გენერირებული კონფიგურაციის ფაილები (ხშირად - გამოყოფილი თითოეული კვანძისთვის/როლისთვის). ჩვენ ასევე გვსურს გამოვიყენოთ ერთი და იგივე ვერსიების იგივე პროტოკოლები თითოეულ საკომუნიკაციო კვანძზე (წინააღმდეგ შემთხვევაში შეგვექმნება შეუთავსებლობის საკითხები). JVM სამყაროში ეს ნიშნავს, რომ შეტყობინებების ბიბლიოთეკა მაინც უნდა იყოს იგივე ვერსიით ყველა საკომუნიკაციო კვანძზე.

რაც შეეხება სისტემის ტესტირებას? რა თქმა უნდა, ინტეგრაციის ტესტებზე მისვლამდე უნდა გვქონდეს ერთეულის ტესტები ყველა კომპონენტისთვის. იმისათვის, რომ შევძლოთ ტესტის შედეგების ექსტრაპოლაცია გაშვების დროზე, უნდა დავრწმუნდეთ, რომ ყველა ბიბლიოთეკის ვერსიები იდენტურია როგორც გაშვების, ასევე ტესტირების გარემოში.

ინტეგრაციის ტესტების გაშვებისას, ხშირად ბევრად უფრო ადვილია გქონდეთ ერთი და იგივე კლასის გზა ყველა კვანძზე. ჩვენ უბრალოდ უნდა დავრწმუნდეთ, რომ იგივე კლასის გზა გამოიყენება განლაგებისას. (შესაძლებელია გამოვიყენოთ სხვადასხვა კლასის გზა სხვადასხვა კვანძზე, მაგრამ უფრო რთულია ამ კონფიგურაციის წარმოდგენა და მისი სწორად განლაგება.) ასე რომ, იმისათვის, რომ ყველაფერი მარტივი იყოს, ჩვენ განვიხილავთ მხოლოდ იდენტურ კლასის გზას ყველა კვანძზე.

კონფიგურაცია პროგრამულ უზრუნველყოფასთან ერთად ვითარდება. ჩვენ ჩვეულებრივ ვიყენებთ ვერსიებს სხვადასხვა იდენტიფიცირებისთვის
პროგრამული უზრუნველყოფის ევოლუციის ეტაპები. გონივრული ჩანს კონფიგურაციის დაფარვა ვერსიის მენეჯმენტის ქვეშ და სხვადასხვა კონფიგურაციის იდენტიფიცირება ზოგიერთი ეტიკეტით. თუ წარმოებაში მხოლოდ ერთი კონფიგურაციაა, შეიძლება გამოვიყენოთ ერთი ვერსია, როგორც იდენტიფიკატორი. ზოგჯერ შეიძლება გვქონდეს მრავალი საწარმოო გარემო. და თითოეული გარემოსთვის შეიძლება დაგვჭირდეს კონფიგურაციის ცალკე ფილიალი. ასე რომ, კონფიგურაციებს შეიძლება ეწოდოს ფილიალი და ვერსია სხვადასხვა კონფიგურაციის ცალსახად იდენტიფიცირებისთვის. თითოეული ფილიალის ეტიკეტი და ვერსია შეესაბამება განაწილებული კვანძების, პორტების, გარე რესურსების, კლასების ბიბლიოთეკის ვერსიების ერთ კომბინაციას თითოეულ კვანძზე. აქ ჩვენ დავფარავთ მხოლოდ ერთ განშტოებას და განვსაზღვრავთ კონფიგურაციებს სამკომპონენტიანი ათობითი ვერსიით (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

ეს კვანძები ასრულებენ სხვადასხვა როლს, აწარმოებენ ზოგიერთ სერვისს და უნდა შეეძლოთ სხვა კვანძებთან კომუნიკაცია TCP/HTTP კავშირების საშუალებით.

TCP კავშირისთვის საჭიროა მინიმუმ პორტის ნომერი. ჩვენ ასევე გვინდა დავრწმუნდეთ, რომ კლიენტი და სერვერი ერთსა და იმავე პროტოკოლზე საუბრობენ. კვანძებს შორის კავშირის მოდელირებისთვის, მოდით გამოვაცხადოთ შემდეგი კლასი:

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

სადაც Port არის უბრალოდ Int დაშვებულ დიაპაზონში:

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

დახვეწილი ტიპები

აგრეთვე დახვეწილი ბიბლიოთეკა. მოკლედ, ის საშუალებას გაძლევთ დაამატოთ დროის შეზღუდვები სხვა ტიპებზე. Ამ შემთხვევაში Int დასაშვებია მხოლოდ 16-ბიტიანი მნიშვნელობები, რომლებიც შეიძლება წარმოადგენდეს პორტის ნომერს. არ არის საჭირო ამ ბიბლიოთეკის გამოყენება კონფიგურაციის ამ მიდგომისთვის. უბრალოდ, როგორც ჩანს, ძალიან კარგად ჯდება.

HTTP-სთვის (REST) ​​შეიძლება ასევე დაგვჭირდეს სერვისის გზა:

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

ფანტომური ტიპი

შედგენის დროს პროტოკოლის იდენტიფიცირებისთვის ვიყენებთ Scala-ს მახასიათებელს ტიპის არგუმენტის გამოცხადებისთვის Protocol რომელიც არ გამოიყენება კლასში. ეს არის ე.წ ფანტომური ტიპი. გაშვების დროს ჩვენ იშვიათად გვჭირდება პროტოკოლის იდენტიფიკატორის მაგალითი, ამიტომ არ ვინახავთ მას. შედგენისას ეს ფანტომური ტიპი იძლევა დამატებით ტიპის უსაფრთხოებას. ჩვენ არ შეგვიძლია პორტის გავლა არასწორი პროტოკოლით.

ერთ-ერთი ყველაზე ფართოდ გამოყენებული პროტოკოლი არის REST API Json სერიალიზაციით:

sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage]

სადაც RequestMessage არის შეტყობინებების ძირითადი ტიპი, რომელიც კლიენტს შეუძლია გაგზავნოს სერვერზე და ResponseMessage არის საპასუხო შეტყობინება სერვერიდან. რა თქმა უნდა, ჩვენ შეიძლება შევქმნათ პროტოკოლის სხვა აღწერილობები, რომლებიც აკონკრეტებენ კომუნიკაციის პროტოკოლს სასურველი სიზუსტით.

ამ პოსტის მიზნებისთვის ჩვენ გამოვიყენებთ პროტოკოლის უფრო მარტივ ვერსიას:

sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage]

ამ პროტოკოლში მოთხოვნის შეტყობინება ემატება url-ს და საპასუხო შეტყობინება ბრუნდება როგორც ჩვეულებრივი სტრიქონი.

სერვისის კონფიგურაცია შეიძლება აღწერილი იყოს სერვისის სახელით, პორტების კოლექციით და ზოგიერთი დამოკიდებულებით. არსებობს რამდენიმე შესაძლო გზა, თუ როგორ უნდა წარმოვადგინოთ ყველა ეს ელემენტი Scala-ში (მაგალითად, HList, ალგებრული მონაცემთა ტიპები). ამ პოსტის მიზნებისთვის ჩვენ გამოვიყენებთ ტორტის შაბლონს და წარმოგიდგენთ კომბინირებულ ნაჭრებს (მოდულებს), როგორც თვისებებს. (ტორტის ნიმუში არ არის მოთხოვნა ამ კომპილირებული კონფიგურაციის მიდგომისთვის. ეს არის იდეის მხოლოდ ერთი შესაძლო განხორციელება.)

დამოკიდებულებები შეიძლება წარმოდგენილი იყოს Cake Pattern-ის გამოყენებით, როგორც სხვა კვანძების ბოლო წერტილები:

  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 სერვისს მხოლოდ პორტის კონფიგურაცია სჭირდება. და ჩვენ ვაცხადებთ, რომ ეს პორტი მხარს უჭერს ექო პროტოკოლს. გაითვალისწინეთ, რომ ჩვენ არ გვჭირდება კონკრეტული პორტის მითითება ამ მომენტში, რადგან თვისება საშუალებას იძლევა აბსტრაქტული მეთოდების დეკლარაციები. თუ ჩვენ ვიყენებთ აბსტრაქტულ მეთოდებს, შემდგენელი დასჭირდება იმპლემენტაციას კონფიგურაციის ინსტანციაში. აქ ჩვენ მივაწოდეთ განხორციელება (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](()))
  }

(იხილეთ კოდის სხვა სერვისების განხორციელებისთვის - ექო სერვისი,
ექო კლიენტი მდე სიცოცხლის კონტროლერები.)

კვანძი არის ერთი ობიექტი, რომელიც აწარმოებს რამდენიმე სერვისს (რესურსების ჯაჭვის დაწყება ჩართულია Cake Pattern-ით):

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

გაითვალისწინეთ, რომ კვანძში ჩვენ ვაზუსტებთ კონფიგურაციის ზუსტ ტიპს, რომელიც საჭიროა ამ კვანძისთვის. შემდგენელი არ გვაძლევს უფლებას ავაშენოთ ობიექტი (Cake) არასაკმარისი ტიპით, რადგან თითოეული სერვისის მახასიათებელი აცხადებს შეზღუდვას Config ტიპი. ასევე, ჩვენ ვერ შევძლებთ კვანძის დაწყებას სრული კონფიგურაციის გარეშე.

კვანძის მისამართის გარჩევადობა

კავშირის დასამყარებლად ჩვენ გვჭირდება რეალური ჰოსტის მისამართი თითოეული კვანძისთვის. ეს შეიძლება მოგვიანებით იყოს ცნობილი, ვიდრე კონფიგურაციის სხვა ნაწილები. აქედან გამომდინარე, ჩვენ გვჭირდება გზა, რათა მივაწოდოთ რუკების მიწოდება კვანძის id-სა და მის ფაქტობრივ მისამართს შორის. ეს რუქა არის ფუნქცია:

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

ასეთი ფუნქციის განხორციელების რამდენიმე შესაძლო გზა არსებობს.

1. თუ ჩვენ ვიცით ფაქტობრივი მისამართები განლაგებამდე, კვანძის ჰოსტების ინსტალაციის დროს, მაშინ შეგვიძლია Scala კოდის გენერირება რეალური მისამართებით და გაშვება შემდგომში (რომელიც ასრულებს კომპილაციის დროის შემოწმებას და შემდეგ აწარმოებს ინტეგრაციის ტესტის კომპლექტს). ამ შემთხვევაში ჩვენი რუკების ფუნქცია ცნობილია სტატიკურად და შეიძლება გამარტივდეს მსგავსებამდე Map[NodeId, NodeAddress].
2. ზოგჯერ ჩვენ ვიღებთ რეალურ მისამართებს მხოლოდ მოგვიანებით, როდესაც კვანძი რეალურად იწყება, ან არ გვაქვს კვანძების მისამართები, რომლებიც ჯერ არ დაწყებულა. ამ შემთხვევაში შეიძლება გვქონდეს აღმოჩენის სერვისი, რომელიც დაწყებულია ყველა სხვა კვანძის წინ და თითოეულმა კვანძმა შეიძლება გამოაქვეყნოს თავისი მისამართი ამ სერვისში და გამოიწეროს დამოკიდებულებები.
3. თუ შეგვიძლია შევცვალოთ /etc/hostsჩვენ შეგვიძლია გამოვიყენოთ წინასწარ განსაზღვრული ჰოსტის სახელები (როგორიცაა my-project-main-node მდე echo-backend) და უბრალოდ დააკავშირეთ ეს სახელი ip მისამართთან განლაგების დროს.

ამ პოსტში ჩვენ არ განვიხილავთ ამ შემთხვევებს უფრო დეტალურად. სინამდვილეში ჩვენს სათამაშოების მაგალითში ყველა კვანძს ექნება იგივე IP მისამართი - 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"
  }

ნახეთ, როგორ ვაზუსტებთ დამოკიდებულებას. ჩვენ ვახსენებთ სხვა კვანძის მოწოდებულ სერვისს, როგორც მიმდინარე კვანძის დამოკიდებულებას. დამოკიდებულების ტიპი შემოწმებულია, რადგან ის შეიცავს ფანტომურ ტიპს, რომელიც აღწერს პროტოკოლს. და გაშვების დროს გვექნება სწორი კვანძის ID. ეს არის შემოთავაზებული კონფიგურაციის მიდგომის ერთ-ერთი მნიშვნელოვანი ასპექტი. ის გვაძლევს შესაძლებლობას დავაყენოთ პორტი მხოლოდ ერთხელ და დავრწმუნდეთ, რომ სწორ პორტს მივმართავთ.

ორი კვანძის განხორციელება

ამ კონფიგურაციისთვის ჩვენ ვიყენებთ ზუსტად იგივე სერვისების განხორციელებას. არანაირი ცვლილება საერთოდ. თუმცა, ჩვენ ვქმნით ორ განსხვავებულ კვანძის იმპლემენტაციას, რომლებიც შეიცავს სხვადასხვა სერვისების კომპლექტს:

  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, ხოლო echo კლიენტი შეწყდება კონფიგურირებული სასრული ხანგრძლივობის შემდეგ. იხილეთ დამწყებ აპლიკაცია დამატებითი ინფორმაციისათვის.

განვითარების საერთო პროცესი

ვნახოთ, როგორ ცვლის ეს მიდგომა კონფიგურაციასთან მუშაობის გზას.

კოდის სახით კონფიგურაცია შედგენილი იქნება და გამოიმუშავებს არტეფაქტს. მიზანშეწონილია კონფიგურაციის არტეფაქტის გამოყოფა სხვა კოდის არტეფაქტებისგან. ხშირად ჩვენ შეგვიძლია გვქონდეს მრავალი კონფიგურაცია იმავე კოდის ბაზაზე. და რა თქმა უნდა, ჩვენ შეგვიძლია გვქონდეს სხვადასხვა კონფიგურაციის ფილიალების მრავალი ვერსია. კონფიგურაციაში ჩვენ შეგვიძლია შევარჩიოთ ბიბლიოთეკების კონკრეტული ვერსიები და ეს მუდმივი დარჩება, როცა ამ კონფიგურაციას განვათავსებთ.

კონფიგურაციის ცვლილება ხდება კოდის შეცვლა. ასე რომ, ის უნდა იყოს დაფარული ხარისხის უზრუნველყოფის იგივე პროცესით:

ბილეთი -> PR -> მიმოხილვა -> შერწყმა -> უწყვეტი ინტეგრაცია -> უწყვეტი განლაგება

მიდგომის შემდეგი შედეგებია:

1. კონფიგურაცია თანმიმდევრულია კონკრეტული სისტემის მაგალითისთვის. როგორც ჩანს, არ არსებობს კვანძებს შორის არასწორი კავშირი.
2. არ არის ადვილი კონფიგურაციის შეცვლა მხოლოდ ერთ კვანძში. უსაფუძვლოა შესვლა და ზოგიერთი ტექსტური ფაილის შეცვლა. ასე რომ, კონფიგურაციის დრიფტი ნაკლებად შესაძლებელი ხდება.
3. კონფიგურაციის მცირე ცვლილებების გაკეთება ადვილი არ არის.
4. კონფიგურაციის ცვლილებების უმეტესობა მოჰყვება განვითარების იმავე პროცესს და გაივლის გარკვეულ განხილვას.

გვჭირდება თუ არა ცალკე საცავი წარმოების კონფიგურაციისთვის? წარმოების კონფიგურაცია შეიძლება შეიცავდეს სენსიტიურ ინფორმაციას, რომელიც გვსურს ბევრი ადამიანისათვის მიუწვდომელ შევინახოთ. ასე რომ, შესაძლოა ღირდეს ცალკეული საცავი შეზღუდული წვდომით, რომელიც შეიცავს წარმოების კონფიგურაციას. ჩვენ შეიძლება გავყოთ კონფიგურაცია ორ ნაწილად - ერთი, რომელიც შეიცავს წარმოების ყველაზე ღია პარამეტრებს და ერთი, რომელიც შეიცავს კონფიგურაციის საიდუმლო ნაწილს. ეს საშუალებას მისცემს დეველოპერების უმეტესობას წვდომა ჰქონდეს პარამეტრების დიდ უმრავლესობაზე, ხოლო შეზღუდოს წვდომა მართლაც მგრძნობიარე საგნებზე. ამის მიღწევა მარტივია შუალედური მახასიათებლების გამოყენებით ნაგულისხმევი პარამეტრის მნიშვნელობებით.

ვარიაციები

ვნახოთ შემოთავაზებული მიდგომის დადებითი და უარყოფითი მხარეები კონფიგურაციის მართვის სხვა ტექნიკასთან შედარებით.

უპირველეს ყოვლისა, ჩვენ ჩამოვთვლით რამდენიმე ალტერნატივას კონფიგურაციის შემოთავაზებული გზის სხვადასხვა ასპექტისთვის:

1. ტექსტური ფაილი სამიზნე მანქანაზე.
2. გასაღების მნიშვნელობის ცენტრალიზებული საცავი (როგორიცაა etcd/zookeeper).
3. ქვეპროცესის კომპონენტები, რომელთა ხელახლა კონფიგურაცია/გადატვირთვა შესაძლებელია პროცესის გადატვირთვის გარეშე.
4. კონფიგურაცია არტეფაქტის გარეთ და ვერსიის კონტროლი.

ტექსტური ფაილი იძლევა გარკვეულ მოქნილობას ad-hoc შესწორებების თვალსაზრისით. სისტემის ადმინისტრატორს შეუძლია შევიდეს სამიზნე კვანძში, შეიტანოს ცვლილება და უბრალოდ გადატვირთოს სერვისი. ეს შეიძლება არც ისე კარგი იყოს უფრო დიდი სისტემებისთვის. ცვლილების მიღმა კვალი არ რჩება. ცვლილება არ განიხილება სხვა წყვილი თვალით. შესაძლოა რთული იყოს იმის გარკვევა, თუ რამ გამოიწვია ცვლილება. ეს არ არის გამოცდილი. განაწილებული სისტემის პერსპექტივიდან ადმინისტრატორს შეუძლია უბრალოდ დაივიწყოს კონფიგურაციის განახლება ერთ-ერთ სხვა კვანძში.

(Btw, თუ საბოლოოდ დაგჭირდებათ ტექსტის კონფიგურაციის ფაილების გამოყენების დაწყება, ჩვენ მხოლოდ უნდა დავამატოთ პარსერი + ვალიდატორი, რომელიც იგივეს წარმოქმნის Config აკრიფეთ და ეს საკმარისი იქნება ტექსტის კონფიგურაციის გამოყენების დასაწყებად. ეს ასევე აჩვენებს, რომ კომპილაციის დროის კონფიგურაციის სირთულე ცოტა უფრო მცირეა ვიდრე ტექსტზე დაფუძნებული კონფიგურაციის სირთულე, რადგან ტექსტზე დაფუძნებულ ვერსიაში ჩვენ გვჭირდება დამატებითი კოდი.)

ცენტრალიზებული გასაღები-მნიშვნელობის შენახვა კარგი მექანიზმია განაცხადის მეტა პარამეტრების განაწილებისთვის. აქ ჩვენ უნდა ვიფიქროთ იმაზე, თუ რას მივიჩნევთ კონფიგურაციის მნიშვნელობებად და რა არის მხოლოდ მონაცემები. მოცემული ფუნქცია C => A => B ჩვენ ჩვეულებრივ ვუწოდებთ იშვიათად ცვალებად მნიშვნელობებს C "კონფიგურაცია", ხოლო ხშირად იცვლებოდა მონაცემები A - უბრალოდ შეიყვანეთ მონაცემები. კონფიგურაცია უნდა მიეწოდოს ფუნქციას მონაცემებზე ადრე A. ამ იდეიდან გამომდინარე, შეგვიძლია ვთქვათ, რომ ცვლილებების მოსალოდნელი სიხშირეა, რაც შეიძლება გამოყენებულ იქნას კონფიგურაციის მონაცემების განასხვავებლად მხოლოდ მონაცემებისგან. ასევე მონაცემები ჩვეულებრივ მოდის ერთი წყაროდან (მომხმარებლიდან) და კონფიგურაცია მოდის სხვა წყაროდან (ადმინისტრატორი). პარამეტრებთან ურთიერთობა, რომლებიც შეიძლება შეიცვალოს ინიციალიზაციის პროცესის შემდეგ, იწვევს განაცხადის სირთულის ზრდას. ასეთი პარამეტრებისთვის ჩვენ მოგვიწევს მათი მიწოდების მექანიზმი, ანალიზი და ვალიდაცია, არასწორი მნიშვნელობების დამუშავება. ამიტომ, პროგრამის სირთულის შესამცირებლად, უმჯობესია შევამციროთ იმ პარამეტრების რაოდენობა, რომლებიც შეიძლება შეიცვალოს გაშვების დროს (ან თუნდაც საერთოდ აღმოვფხვრათ ისინი).

ამ პოსტის პერსპექტივიდან ჩვენ უნდა განვასხვავოთ სტატიკური და დინამიური პარამეტრები. თუ სერვისის ლოგიკა მოითხოვს რამდენიმე პარამეტრის იშვიათ ცვლილებას გაშვების დროს, მაშინ მათ შეიძლება ვუწოდოთ დინამიური პარამეტრები. წინააღმდეგ შემთხვევაში, ისინი სტატიკურია და მათი კონფიგურაცია შესაძლებელია შემოთავაზებული მიდგომის გამოყენებით. დინამიური რეკონფიგურაციისთვის შეიძლება საჭირო გახდეს სხვა მიდგომები. მაგალითად, სისტემის ნაწილები შეიძლება გადაიტვირთოს ახალი კონფიგურაციის პარამეტრებით, ისევე როგორც განაწილებული სისტემის ცალკეული პროცესების გადატვირთვა.
(ჩემი მოკრძალებული აზრია, რომ თავიდან ავიცილოთ გაშვების რეკონფიგურაცია, რადგან ეს ზრდის სისტემის სირთულეს.
შეიძლება უფრო მარტივი იყოს მხოლოდ OS-ის მხარდაჭერაზე დაყრდნობა პროცესების გადატვირთვისას. თუმცა, ეს შეიძლება ყოველთვის არ იყოს შესაძლებელი.)

სტატიკური კონფიგურაციის გამოყენების ერთ-ერთი მნიშვნელოვანი ასპექტი, რომელიც ზოგჯერ აიძულებს ადამიანებს განიხილონ დინამიური კონფიგურაცია (სხვა მიზეზების გარეშე) არის სერვისის შეფერხება კონფიგურაციის განახლების დროს. მართლაც, თუ ჩვენ გვიწევს ცვლილებების შეტანა სტატიკურ კონფიგურაციაში, ჩვენ უნდა გადავტვირთოთ სისტემა ისე, რომ ახალი მნიშვნელობები ეფექტური გახდეს. შეფერხების მოთხოვნები განსხვავებულია სხვადასხვა სისტემებისთვის, ამიტომ ეს შეიძლება არც ისე კრიტიკული იყოს. თუ ეს კრიტიკულია, მაშინ წინასწარ უნდა დავგეგმოთ ნებისმიერი სისტემის გადატვირთვა. მაგალითად, ჩვენ შეგვიძლია განვახორციელოთ AWS ELB კავშირის დრენაჟი. ამ სცენარში, როდესაც ჩვენ გვჭირდება სისტემის გადატვირთვა, ჩვენ პარალელურად ვიწყებთ სისტემის ახალ ინსტანციას, შემდეგ გადავდივართ მასზე ELB-ზე, ხოლო ძველ სისტემას ვაძლევთ საშუალებას დაასრულოს არსებული კავშირების სერვისი.

რაც შეეხება კონფიგურაციის შენარჩუნებას ვერსიული არტეფაქტის შიგნით თუ გარეთ? კონფიგურაციის შენახვა არტეფაქტის შიგნით ნიშნავს უმეტეს შემთხვევაში, რომ ამ კონფიგურაციამ გაიარა იგივე ხარისხის უზრუნველყოფის პროცესი, როგორც სხვა არტეფაქტებმა. ასე რომ, შეიძლება დარწმუნებული იყოს, რომ კონფიგურაცია კარგი ხარისხის და სანდოა. პირიქით, ცალკე ფაილში კონფიგურაცია ნიშნავს, რომ არ არსებობს კვალი იმის შესახებ, თუ ვინ და რატომ შეიტანა ცვლილებები ამ ფაილში. ეს მნიშვნელოვანია? ჩვენ გვჯერა, რომ წარმოების სისტემების უმეტესობისთვის უკეთესია სტაბილური და მაღალი ხარისხის კონფიგურაცია.

არტეფაქტის ვერსია საშუალებას გაძლევთ გაარკვიოთ როდის შეიქმნა, რა მნიშვნელობებს შეიცავს, რა ფუნქციებია ჩართული/გამორთული, ვინ იყო პასუხისმგებელი კონფიგურაციის თითოეულ ცვლილებაზე. მას შესაძლოა გარკვეული ძალისხმევა დასჭირდეს არტეფაქტის შიგნით კონფიგურაციის შესანარჩუნებლად და ეს დიზაინის არჩევანია.

დადებითი და უარყოფითი მხარეები

აქ ჩვენ გვსურს გამოვყოთ შემოთავაზებული მიდგომის რამდენიმე უპირატესობა და განვიხილოთ ზოგიერთი უარყოფითი მხარე.

უპირატესობები

სრული განაწილებული სისტემის კომპილირებადი კონფიგურაციის მახასიათებლები:

1. კონფიგურაციის სტატიკური შემოწმება. ეს იძლევა მაღალი დონის ნდობას, რომ კონფიგურაცია სწორია ტიპის შეზღუდვების გათვალისწინებით.
2. კონფიგურაციის მდიდარი ენა. როგორც წესი, სხვა კონფიგურაციის მიდგომები შემოიფარგლება მაქსიმუმ ცვლადის ჩანაცვლებით.
   Scala-ს გამოყენებით შეგიძლიათ გამოიყენოთ ენის ფუნქციების ფართო სპექტრი კონფიგურაციის გასაუმჯობესებლად. მაგალითად, ჩვენ შეგვიძლია გამოვიყენოთ თვისებები ნაგულისხმევი მნიშვნელობების უზრუნველსაყოფად, ობიექტები სხვადასხვა მასშტაბის დასაყენებლად, შეგვიძლია მივმართოთ vals განისაზღვრება მხოლოდ ერთხელ გარე ზონაში (DRY). შესაძლებელია ლიტერატურული თანმიმდევრობების ან გარკვეული კლასების მაგალითების გამოყენება (Seq, Map, და ა.შ.).
3. DSL. Scala-ს აქვს ღირსეული მხარდაჭერა DSL დამწერებისთვის. ამ ფუნქციების გამოყენება შესაძლებელია კონფიგურაციის ენის დასამყარებლად, რომელიც უფრო მოსახერხებელი და საბოლოო მომხმარებლისთვის მოსახერხებელია, რათა საბოლოო კონფიგურაცია მინიმუმამდე იყოს წაკითხული დომენის მომხმარებლებისთვის.
4. მთლიანობა და თანმიმდევრულობა კვანძებში. მთელი განაწილებული სისტემის ერთ ადგილას კონფიგურაციის ერთ-ერთი უპირატესობა არის ის, რომ ყველა მნიშვნელობა მკაცრად არის განსაზღვრული ერთხელ და შემდეგ ხელახლა გამოიყენება ყველა ადგილას, სადაც ჩვენ გვჭირდება. ასევე აკრიფეთ უსაფრთხო პორტის დეკლარაციები, რათა უზრუნველყოს, რომ ყველა შესაძლო სწორ კონფიგურაციაში სისტემის კვანძები ერთსა და იმავე ენაზე ისაუბრებენ. არსებობს აშკარა დამოკიდებულებები კვანძებს შორის, რაც ართულებს ზოგიერთი სერვისის მიწოდების დავიწყებას.
5. ცვლილებების მაღალი ხარისხი. კონფიგურაციის გავლის საერთო მიდგომა იცვლება ნორმალური PR პროცესის მეშვეობით, ადგენს ხარისხის მაღალ სტანდარტებს ასევე კონფიგურაციაში.
6. კონფიგურაციის ერთდროული ცვლილებები. როდესაც ჩვენ ვაკეთებთ რაიმე ცვლილებას კონფიგურაციაში, ავტომატური განლაგება უზრუნველყოფს ყველა კვანძის განახლებას.
7. განაცხადის გამარტივება. აპლიკაციას არ სჭირდება კონფიგურაციის გაანალიზება და დამოწმება და არასწორი კონფიგურაციის მნიშვნელობების დამუშავება. ეს ამარტივებს მთლიან აპლიკაციას. (სირთულის გარკვეული ზრდა არის თავად კონფიგურაციაში, მაგრამ ეს არის შეგნებული ვაჭრობა უსაფრთხოების მიმართ.) ჩვეულებრივი კონფიგურაციის დაბრუნება საკმაოდ მარტივია - უბრალოდ დაამატეთ დაკარგული ნაწილები. უფრო ადვილია შედგენილი კონფიგურაციის დაწყება და დამატებითი ნაწილების განხორციელების მოგვიანებით გადადება.
8. ვერსიული კონფიგურაცია. გამომდინარე იქიდან, რომ კონფიგურაციის ცვლილებები მოჰყვება განვითარების იგივე პროცესს, შედეგად ვიღებთ არტეფაქტს უნიკალური ვერსიით. ეს გვაძლევს საჭიროების შემთხვევაში კონფიგურაციის უკან გადართვას. ჩვენ შეგვიძლია განვათავსოთ კონფიგურაცია, რომელიც გამოიყენებოდა ერთი წლის წინ და ის იმუშავებს ზუსტად იგივე გზით. სტაბილური კონფიგურაცია აუმჯობესებს განაწილებული სისტემის პროგნოზირებადობას და საიმედოობას. კონფიგურაცია ფიქსირდება კომპილაციის დროს და არ შეიძლება ადვილად შეიცვალოს წარმოების სისტემაში.
9. მოდულარულობა. შემოთავაზებული ჩარჩო მოდულარულია და მოდულები შეიძლება გაერთიანდეს სხვადასხვა გზით
   სხვადასხვა კონფიგურაციის მხარდაჭერა (კონფიგურაცია/განლაგება). კერძოდ, შესაძლებელია გქონდეთ მცირე მასშტაბის ერთი კვანძის განლაგება და დიდი მასშტაბის მრავალ კვანძის პარამეტრი. მიზანშეწონილია გქონდეთ მრავალი წარმოების განლაგება.
10. ტესტირება. სატესტო მიზნებისთვის შეიძლება იმიტირებული სერვისის დანერგვა და დამოკიდებულების სახით გამოყენება უსაფრთხოდ. რამდენიმე განსხვავებული ტესტირების განლაგება სხვადასხვა ნაწილებით შეცვლილი იმიტირებით შეიძლება შენარჩუნდეს ერთდროულად.
11. ინტეგრაციის ტესტირება. ზოგჯერ განაწილებულ სისტემებში რთულია ინტეგრაციის ტესტების ჩატარება. აღწერილი მიდგომის გამოყენებით სრული განაწილებული სისტემის უსაფრთხო კონფიგურაციის ჩასაწერად, ჩვენ შეგვიძლია გავატაროთ ყველა განაწილებული ნაწილი ერთ სერვერზე კონტროლირებადი გზით. სიტუაციის მიბაძვა ადვილია
    როდესაც ერთ-ერთი სერვისი მიუწვდომელია.

ნაკლოვანებები

შედგენილი კონფიგურაციის მიდგომა განსხვავდება "ნორმალური" კონფიგურაციისგან და ის შეიძლება არ მოერგოს ყველა საჭიროებას. აქ არის შედგენილი კონფიგურაციის რამდენიმე უარყოფითი მხარე:

1. სტატიკური კონფიგურაცია. ეს შეიძლება არ იყოს შესაფერისი ყველა აპლიკაციისთვის. ზოგიერთ შემთხვევაში საჭიროა წარმოების კონფიგურაციის სწრაფად დაფიქსირება უსაფრთხოების ყველა ზომის გვერდის ავლით. ეს მიდგომა უფრო ართულებს. შედგენა და ხელახალი განლაგება საჭიროა კონფიგურაციის ნებისმიერი ცვლილების განხორციელების შემდეგ. ეს არის თვისებაც და ტვირთიც.
2. კონფიგურაციის გენერაცია. როდესაც კონფიგურაცია გენერირდება რაიმე ავტომატიზაციის ხელსაწყოს მიერ, ეს მიდგომა მოითხოვს შემდგომ კომპილაციას (რაც, თავის მხრივ, შეიძლება ვერ მოხერხდეს). შესაძლოა დამატებითი ძალისხმევა დასჭირდეს ამ დამატებითი ნაბიჯის ინტეგრირებას build სისტემაში.
3. ინსტრუმენტები. დღეს გამოიყენება უამრავი ინსტრუმენტი, რომელიც ეყრდნობა ტექსტზე დაფუძნებულ კონფიგურაციას. Ზოგიერთი მათგანი
   არ იქნება გამოყენებული კონფიგურაციის შედგენისას.
4. საჭიროა აზროვნების შეცვლა. დეველოპერები და DevOps იცნობენ ტექსტის კონფიგურაციის ფაილებს. კონფიგურაციის შედგენის იდეა მათთვის შეიძლება უცნაური აღმოჩნდეს.
5. კომპილირებადი კონფიგურაციის დანერგვამდე საჭიროა მაღალი ხარისხის პროგრამული უზრუნველყოფის განვითარების პროცესი.

განხორციელებული მაგალითის გარკვეული შეზღუდვები არსებობს:

1. თუ ჩვენ გთავაზობთ დამატებით კონფიგურაციას, რომელიც არ არის მოთხოვნილი კვანძის იმპლემენტაციის მიერ, შემდგენელი არ დაგვეხმარება არარსებული იმპლემენტაციის აღმოჩენაში. ეს შეიძლება მოგვარდეს გამოყენებით HList ან ADT-ები (ქეისების კლასები) კვანძების კონფიგურაციისთვის ნიშან-თვისებებისა და Cake Pattern-ის ნაცვლად.
2. ჩვენ უნდა მივაწოდოთ რამდენიმე ქვაბის ფირფიტა კონფიგურაციის ფაილში: (package, import, object დეკლარაციები;
   override def's იმ პარამეტრებისთვის, რომლებსაც აქვთ ნაგულისხმევი მნიშვნელობები). ეს შეიძლება ნაწილობრივ გადაიჭრას DSL-ის გამოყენებით.
3. ამ პოსტში ჩვენ არ განვიხილავთ მსგავსი კვანძების კლასტერების დინამიურ რეკონფიგურაციას.

დასკვნა

ამ პოსტში ჩვენ განვიხილეთ იდეა კონფიგურაციის წარმოდგენის პირდაპირ წყაროს კოდში ტიპის უსაფრთხო გზით. მიდგომა შეიძლება გამოყენებულ იქნას მრავალ აპლიკაციაში, როგორც xml- და სხვა ტექსტზე დაფუძნებული კონფიგურაციის ჩანაცვლება. მიუხედავად იმისა, რომ ჩვენი მაგალითი დანერგილია Scala-ში, ის ასევე შეიძლება ითარგმნოს სხვა კომპილირებად ენებზე (როგორიცაა Kotlin, C#, Swift და ა.შ.). შეიძლება სცადო ეს მიდგომა ახალ პროექტში და, თუ ის კარგად არ ჯდება, გადაერთო ძველმოდურ გზაზე.

რა თქმა უნდა, კომპილირებადი კონფიგურაცია მოითხოვს მაღალი ხარისხის განვითარების პროცესს. ამის სანაცვლოდ ის გვპირდება თანაბრად მაღალი ხარისხის მტკიცე კონფიგურაციის უზრუნველყოფას.

ეს მიდგომა შეიძლება გაფართოვდეს სხვადასხვა გზით:

1. შეიძლება გამოყენებულ იქნას მაკროები კონფიგურაციის ვალიდაციის შესასრულებლად და წარუმატებლობა კომპილაციის დროს ნებისმიერი ბიზნეს-ლოგიკური შეზღუდვების წარუმატებლობის შემთხვევაში.
2. DSL შეიძლება განხორციელდეს, რათა წარმოადგინოს კონფიგურაცია დომენისთვის მოსახერხებელი გზით.
3. დინამიური რესურსების მართვა ავტომატური კონფიგურაციის კორექტირებით. მაგალითად, როდესაც ჩვენ ვარეგულირებთ კლასტერული კვანძების რაოდენობას, შეიძლება გვსურს (1) კვანძებმა მიიღონ ოდნავ შეცვლილი კონფიგურაცია; (2) კლასტერის მენეჯერი ახალი კვანძების ინფორმაციის მისაღებად.

მადლობა

მინდა მადლობა გადავუხადო ანდრეი საქსონოვს, პაველ პოპოვს, ანტონ ნეჰაევს ამ პოსტის პროექტზე ინსპირაციული გამოხმაურებისთვის, რაც დამეხმარა უფრო ნათლად გამეხსნა.

წყარო: www.habr.com