🥇वितरण प्रणालीको कम्पाइल योग्य कन्फिगरेसन

यस पोष्टमा हामी वितरित प्रणालीको कन्फिगरेसनसँग व्यवहार गर्ने एक रोचक तरिका साझा गर्न चाहन्छौं।
कन्फिगरेसन सिधै स्काला भाषामा एक प्रकार सुरक्षित तरिकामा प्रतिनिधित्व गरिएको छ। एउटा उदाहरण कार्यान्वयन विवरणमा वर्णन गरिएको छ। प्रस्तावमा समग्र विकास प्रक्रियामा पर्ने प्रभावलगायत विभिन्न पक्षमा छलफल भएको छ ।

(रुसीमा)

परिचय

बलियो वितरण प्रणालीहरू निर्माण गर्न सबै नोडहरूमा सही र सुसंगत कन्फिगरेसनको प्रयोग आवश्यक छ। एक सामान्य समाधान भनेको पाठ्य परिनियोजन विवरण (टेराफार्म, उत्तरदायी वा समान रूपमा) र स्वचालित रूपमा उत्पन्न कन्फिगरेसन फाइलहरू (प्रायः प्रत्येक नोड/भूमिकाको लागि समर्पित) प्रयोग गर्नु हो। हामी प्रत्येक सञ्चार नोडहरूमा समान संस्करणहरूको समान प्रोटोकलहरू प्रयोग गर्न चाहन्छौं (अन्यथा हामीले असंगतता समस्याहरू अनुभव गर्नेछौं)। 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)

प्रेत प्रकार

संकलनको क्रममा प्रोटोकल पहिचान गर्नको लागि हामी प्रकार तर्क घोषणा गर्ने स्काला सुविधा प्रयोग गर्दैछौं Protocol जुन कक्षामा प्रयोग हुँदैन । यो एक तथाकथित छ प्रेत प्रकार। रनटाइममा हामीलाई प्रोटोकल पहिचानकर्ताको उदाहरण विरलै चाहिन्छ, त्यसैले हामी यसलाई भण्डारण गर्दैनौं। संकलनको क्रममा यो प्रेत प्रकारले अतिरिक्त प्रकारको सुरक्षा दिन्छ। हामी गलत प्रोटोकल संग पोर्ट पास गर्न सक्दैनौं।

सबैभन्दा व्यापक रूपमा प्रयोग हुने प्रोटोकलहरू मध्ये एक Json क्रमिकरणको साथ REST API हो:

sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage]

जहाँ RequestMessage सन्देशहरूको आधार प्रकार हो जुन ग्राहकले सर्भरमा पठाउन सक्छ र ResponseMessage सर्भरबाट प्रतिक्रिया सन्देश हो। निस्सन्देह, हामीले अन्य प्रोटोकल विवरणहरू सिर्जना गर्न सक्छौं जसले संचार प्रोटोकललाई इच्छित परिशुद्धतासँग निर्दिष्ट गर्दछ।

यस पोस्टको उद्देश्यका लागि हामी प्रोटोकलको सरल संस्करण प्रयोग गर्नेछौं:

sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage]

यो प्रोटोकल अनुरोध सन्देश url मा जोडिएको छ र प्रतिक्रिया सन्देश सादा स्ट्रिङ रूपमा फर्काइन्छ।

सेवा कन्फिगरेसन सेवा नाम, पोर्टहरूको संग्रह र केही निर्भरताहरूद्वारा वर्णन गर्न सकिन्छ। स्कालामा यी सबै तत्वहरूलाई कसरी प्रतिनिधित्व गर्ने केही सम्भावित तरिकाहरू छन् (उदाहरणका लागि, 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]]
}

यस्तो प्रकार्य कार्यान्वयन गर्न केही सम्भावित तरिकाहरू छन्।

यदि हामीले डिप्लोइमेन्ट अघि वास्तविक ठेगानाहरू थाहा पाउँछौं, नोड होस्ट इन्स्ट्यान्टिएसनको बेला, तब हामी वास्तविक ठेगानाहरूसँग स्काला कोड उत्पन्न गर्न सक्छौं र पछि निर्माण चलाउन सक्छौं (जसले कम्पाइल टाइम जाँच गर्छ र त्यसपछि एकीकरण परीक्षण सुइट चलाउँछ)। यस अवस्थामा हाम्रो म्यापिङ प्रकार्य स्थिर रूपमा चिनिन्छ र केहि जस्तै सरलीकृत गर्न सकिन्छ Map[NodeId, NodeAddress].
कहिलेकाहीँ हामी वास्तविक ठेगानाहरू पछिको बिन्दुमा मात्र प्राप्त गर्छौं जब नोड वास्तवमा सुरु हुन्छ, वा हामीसँग नोडहरूको ठेगानाहरू छैनन् जुन अहिलेसम्म सुरु गरिएको छैन। यस अवस्थामा हामीसँग एउटा खोज सेवा हुन सक्छ जुन अन्य सबै नोडहरू अघि सुरु गरिएको छ र प्रत्येक नोडले त्यो सेवामा आफ्नो ठेगानाको विज्ञापन गर्न सक्छ र निर्भरताहरूको सदस्यता लिन सक्छ।
यदि हामी परिमार्जन गर्न सक्छौं /etc/hosts, हामी पूर्वनिर्धारित होस्ट नामहरू प्रयोग गर्न सक्छौं (जस्तै my-project-main-node र echo-backend) र केवल यो नामलाई आईपी ठेगानासँग डिप्लोइमेन्ट समयमा सम्बद्ध गर्नुहोस्।

यस पोष्टमा हामी यी केसहरूलाई थप विवरणहरूमा कभर गर्दैनौं। वास्तवमा हाम्रो खेलौना उदाहरणमा सबै नोडहरूमा समान आईपी ठेगाना हुनेछ - 127.0.0.1.

यस पोष्टमा हामी दुई वितरण प्रणाली लेआउटहरू विचार गर्नेछौं:

एकल नोड लेआउट, जहाँ सबै सेवाहरू एकल नोडमा राखिन्छन्।
दुई नोड लेआउट, जहाँ सेवा र ग्राहक फरक नोडहरूमा छन्।

ए को लागि कन्फिगरेसन एकल नोड लेआउट निम्नानुसार छ:

एकल नोड कन्फिगरेसन

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, जबकि इको क्लाइन्ट कन्फिगर गरिएको परिमित अवधि पछि समाप्त हुनेछ। हेर्नुहोस् स्टार्टर आवेदन विवरण लागि।

समग्र विकास प्रक्रिया

यो दृष्टिकोणले हामीले कन्फिगरेसनसँग काम गर्ने तरिकालाई कसरी परिवर्तन गर्छ हेरौं।

कोडको रूपमा कन्फिगरेसन कम्पाइल गरिनेछ र एक कलाकृति उत्पादन गर्दछ। यो अन्य कोड कलाकृतिहरु बाट कन्फिगरेसन कलाकृति अलग गर्न उचित देखिन्छ। प्रायः हामीसँग एउटै कोड आधारमा धेरै कन्फिगरेसनहरू हुन सक्छ। र अवश्य पनि, हामीसँग विभिन्न कन्फिगरेसन शाखाहरूको बहु संस्करणहरू हुन सक्छ। कन्फिगरेसनमा हामी पुस्तकालयहरूको विशेष संस्करणहरू चयन गर्न सक्छौं र यो स्थिर रहनेछ जब हामी यो कन्फिगरेसन डिप्लोय गर्छौं।

कन्फिगरेसन परिवर्तन कोड परिवर्तन हुन्छ। त्यसैले यो समान गुणस्तर आश्वासन प्रक्रिया द्वारा कभर गर्नुपर्छ:

टिकट -> PR -> समीक्षा -> मर्ज -> निरन्तर एकीकरण -> निरन्तर तैनाती

त्यहाँ दृष्टिकोणको निम्न परिणामहरू छन्:

कन्फिगरेसन एक विशेष प्रणालीको उदाहरणको लागि सुसंगत छ। यस्तो देखिन्छ कि नोडहरू बीच गलत जडान हुन कुनै तरिका छैन।
केवल एक नोडमा कन्फिगरेसन परिवर्तन गर्न सजिलो छैन। लग इन गर्न र केहि पाठ फाइलहरू परिवर्तन गर्न अनुचित देखिन्छ। त्यसैले कन्फिगरेसन बहाव कम सम्भव हुन्छ।
साना कन्फिगरेसन परिवर्तनहरू बनाउन सजिलो छैन।
धेरै जसो कन्फिगरेसन परिवर्तनहरूले समान विकास प्रक्रियालाई पछ्याउनेछ, र यसले केही समीक्षा पास गर्नेछ।

के हामीलाई उत्पादन कन्फिगरेसनको लागि छुट्टै भण्डार चाहिन्छ? उत्पादन कन्फिगरेसनमा संवेदनशील जानकारी हुन सक्छ जुन हामी धेरै मानिसहरूको पहुँचबाट टाढा राख्न चाहन्छौं। त्यसैले उत्पादन कन्फिगरेसन समावेश हुने प्रतिबन्धित पहुँचको साथ छुट्टै भण्डार राख्न लायक हुन सक्छ। हामी कन्फिगरेसनलाई दुई भागमा विभाजन गर्न सक्छौं - एउटा जसले उत्पादनको सबैभन्दा खुला प्यारामिटरहरू समावेश गर्दछ र अर्कोमा कन्फिगरेसनको गोप्य भाग समावेश गर्दछ। यसले धेरैजसो विकासकर्ताहरूलाई धेरैजसो प्यारामिटरहरूमा पहुँच सक्षम पार्छ जबकि वास्तवमा संवेदनशील चीजहरूमा पहुँच प्रतिबन्धित गर्दछ। पूर्वनिर्धारित प्यारामिटर मानहरूसँग मध्यवर्ती विशेषताहरू प्रयोग गरेर यो पूरा गर्न सजिलो छ।

बदलाव

अन्य कन्फिगरेसन व्यवस्थापन प्रविधिहरूको तुलनामा प्रस्तावित दृष्टिकोणको फाइदा र विपक्ष हेरौं।

सबैभन्दा पहिले, हामी कन्फिगरेसनसँग व्यवहार गर्ने प्रस्तावित तरिकाका विभिन्न पक्षहरूको लागि केही विकल्पहरू सूचीबद्ध गर्नेछौं:

लक्ष्य मेसिनमा पाठ फाइल।
केन्द्रीकृत कुञ्जी-मान भण्डारण (जस्तै etcd/zookeeper).
सबप्रोसेस कम्पोनेन्टहरू जुन प्रक्रिया पुन: सुरु नगरी पुन: कन्फिगर / पुन: सुरु गर्न सकिन्छ।
कलाकृति र संस्करण नियन्त्रण बाहिर कन्फिगरेसन।

टेक्स्ट फाइलले एड-हक फिक्सहरूको सन्दर्भमा केही लचिलोपन दिन्छ। प्रणालीको प्रशासकले लक्षित नोडमा लगइन गर्न, परिवर्तन गर्न र सेवा पुन: सुरु गर्न सक्छ। यो ठूला प्रणालीहरूको लागि राम्रो नहुन सक्छ। परिवर्तनको पछाडि कुनै निशान बाँकी छैन। परिवर्तनलाई आँखाको अर्को जोडीले समीक्षा गर्दैन। परिवर्तनको कारण के हो भनेर पत्ता लगाउन गाह्रो हुन सक्छ। यसको परीक्षण भएको छैन। वितरित प्रणालीको परिप्रेक्ष्यबाट प्रशासकले अन्य नोडहरू मध्ये एउटामा कन्फिगरेसन अद्यावधिक गर्न बिर्सन सक्छ।

(Btw, यदि अन्ततः पाठ कन्फिग फाइलहरू प्रयोग गर्न सुरु गर्न आवश्यक छ भने, हामीले पार्सर + प्रमाणिकरण मात्र थप्नु पर्छ जसले समान उत्पादन गर्न सक्छ। Config टाइप गर्नुहोस् र त्यो पाठ कन्फिगहरू प्रयोग गर्न सुरु गर्न पर्याप्त हुनेछ। यसले यो पनि देखाउँछ कि कम्पाइल-टाइम कन्फिगरेसनको जटिलता पाठ-आधारित कन्फिगरेसनको जटिलता भन्दा सानो छ, किनभने पाठ-आधारित संस्करणमा हामीलाई केही थप कोड चाहिन्छ।)

केन्द्रीकृत कुञ्जी-मान भण्डारण अनुप्रयोग मेटा प्यारामिटरहरू वितरणको लागि राम्रो संयन्त्र हो। यहाँ हामीले कन्फिगरेसन मानहरू र केवल डाटा के हो भनेर सोच्न आवश्यक छ। समारोह दिनुभयो C => A => B हामी सामान्यतया विरलै परिवर्तन हुने मानहरू भन्छौं C "कन्फिगरेसन", बारम्बार डाटा परिवर्तन गर्दा A - केवल इनपुट डाटा। कन्फिगरेसन डेटा भन्दा पहिले प्रकार्यमा प्रदान गरिनु पर्छ A। यो विचार दिएर हामी भन्न सक्छौं कि यो परिवर्तनहरूको अपेक्षित आवृत्ति हो जुन केवल डेटाबाट कन्फिगरेसन डेटा छुट्याउन प्रयोग गर्न सकिन्छ। साथै डेटा सामान्यतया एक स्रोत (प्रयोगकर्ता) बाट आउँछ र कन्फिगरेसन फरक स्रोत (व्यवस्थापक) बाट आउँछ। प्रारम्भिक प्रक्रिया पछि परिवर्तन गर्न सकिने प्यारामिटरहरूसँग व्यवहार गर्दा अनुप्रयोग जटिलताको वृद्धि हुन्छ। त्यस्ता प्यारामिटरहरूका लागि हामीले तिनीहरूको डेलिभरी मेकानिजम, पार्सिङ र प्रमाणीकरण, गलत मानहरू ह्यान्डल गर्नुपर्नेछ। तसर्थ, कार्यक्रमको जटिलता कम गर्नको लागि, हामीले रनटाइममा परिवर्तन गर्न सक्ने प्यारामिटरहरूको संख्यालाई अझ राम्रोसँग घटाउनेछौं (वा तिनीहरूलाई पूर्ण रूपमा हटाउन पनि)।

यस पोष्टको परिप्रेक्ष्यबाट हामीले स्थिर र गतिशील प्यारामिटरहरू बीचको भिन्नता बनाउनु पर्छ। यदि सेवा तर्कले रनटाइममा केही प्यारामिटरहरूको दुर्लभ परिवर्तन चाहिन्छ भने, हामी तिनीहरूलाई गतिशील प्यारामिटरहरू भन्न सक्छौं। अन्यथा तिनीहरू स्थिर छन् र प्रस्तावित दृष्टिकोण प्रयोग गरेर कन्फिगर गर्न सकिन्छ। गतिशील पुन: कन्फिगरेसनको लागि अन्य दृष्टिकोणहरू आवश्यक हुन सक्छ। उदाहरण को लागी, प्रणाली को भागहरु लाई नयाँ कन्फिगरेसन मापदण्डहरु संग एक वितरित प्रणाली को अलग प्रक्रियाहरु पुन: सुरु गर्न को लागी पुन: सुरु गर्न सकिन्छ।
(मेरो नम्र राय रनटाइम पुन: कन्फिगरेसनबाट बच्न हो किनभने यसले प्रणालीको जटिलता बढाउँछ।
यो' पुन: सुरु गर्ने प्रक्रियाहरूको OS समर्थनमा भर पर्न अझ सरल हुन सक्छ। यद्यपि, यो सधैं सम्भव नहुन सक्छ।)

स्थिर कन्फिगरेसन प्रयोग गर्ने एउटा महत्त्वपूर्ण पक्ष जसले कहिलेकाँही मानिसहरूलाई गतिशील कन्फिगरेसन (अन्य कारणहरू बिना) लाई कन्फिगरेसन अद्यावधिकको समयमा सेवा डाउनटाइममा विचार गर्दछ। वास्तवमा, यदि हामीले स्थिर कन्फिगरेसनमा परिवर्तनहरू गर्नुपर्दछ भने, हामीले प्रणाली पुन: सुरु गर्नुपर्छ ताकि नयाँ मानहरू प्रभावकारी बन्न सकून्। डाउनटाइमका लागि आवश्यकताहरू विभिन्न प्रणालीहरूको लागि भिन्न हुन्छन्, त्यसैले यो महत्त्वपूर्ण नहुन सक्छ। यदि यो महत्वपूर्ण छ भने, हामीले कुनै पनि प्रणाली पुन: सुरुको लागि अगाडि योजना गर्नुपर्छ। उदाहरणका लागि, हामीले कार्यान्वयन गर्न सक्छौं AWS ELB जडान निकास। यस परिदृश्यमा जब पनि हामीले प्रणालीलाई पुन: सुरु गर्न आवश्यक छ, हामी समानान्तर रूपमा प्रणालीको नयाँ उदाहरण सुरु गर्छौं, त्यसपछि पुरानो प्रणालीलाई अवस्थित जडानहरू पूरा गर्न दिँदै त्यसमा ELB स्विच गर्छौं।

संस्करण गरिएको कलाकृति भित्र वा बाहिर कन्फिगरेसन राख्ने बारे के? कलाकृति भित्र कन्फिगरेसन राख्नु भनेको धेरै जसो केसहरूमा यो कन्फिगरेसनले अन्य कलाकृतिहरू जस्तै गुणस्तर आश्वासन प्रक्रिया पास गरेको हो। त्यसैले एक निश्चित हुन सक्छ कि कन्फिगरेसन राम्रो गुणस्तर र विश्वसनीय छ। यसको विपरित एक अलग फाइलमा कन्फिगरेसनको मतलब त्यहाँ कसले र किन फाइलमा परिवर्तनहरू गर्यो भन्ने कुनै ट्रेसहरू छैनन्। के यो महत्त्वपूर्ण छ? हामी विश्वास गर्छौं कि अधिकांश उत्पादन प्रणालीहरूको लागि स्थिर र उच्च गुणस्तर कन्फिगरेसन हुनु राम्रो छ।

कलाकृतिको संस्करणले पत्ता लगाउन अनुमति दिन्छ कि यो कहिले सिर्जना गरिएको थियो, कुन मानहरू समावेश छन्, कुन सुविधाहरू सक्षम छन् / असक्षम छन्, कन्फिगरेसनमा प्रत्येक परिवर्तन गर्न को लागी जिम्मेवार थियो। यो एक कलाकृति भित्र कन्फिगरेसन राख्न केहि प्रयास आवश्यक हुन सक्छ र यो बनाउन को लागी एक डिजाइन विकल्प हो।

पेशेवरहरु र विपक्ष

यहाँ हामी केही फाइदाहरू हाइलाइट गर्न चाहन्छौं र प्रस्तावित दृष्टिकोणका केही बेफाइदाहरू छलफल गर्न चाहन्छौं।

फाइदा

पूर्ण वितरण प्रणाली को कम्पाइल कन्फिगरेसन को विशेषताहरु:

कन्फिगरेसनको स्थिर जाँच। यसले उच्च स्तरको आत्मविश्वास दिन्छ, कि कन्फिगरेसन सही दिइएको प्रकार बाधाहरू छन्।
कन्फिगरेसनको समृद्ध भाषा। सामान्यतया अन्य कन्फिगरेसन दृष्टिकोणहरू धेरै चर प्रतिस्थापनमा सीमित छन्।
Scala प्रयोग गरेर कन्फिगरेसन राम्रो बनाउन भाषा सुविधाहरूको विस्तृत दायरा प्रयोग गर्न सकिन्छ। उदाहरणका लागि, हामी पूर्वनिर्धारित मानहरू प्रदान गर्नका लागि विशेषताहरू प्रयोग गर्न सक्छौं, फरक दायरा सेट गर्न वस्तुहरू, हामी सन्दर्भ गर्न सक्छौं। valबाहिरी दायरा (DRY) मा एक पटक मात्र परिभाषित गरिएको छ। शाब्दिक अनुक्रमहरू, वा निश्चित वर्गहरूको उदाहरणहरू प्रयोग गर्न सम्भव छ (Seq, Map, आदि)।
DSL। स्कालासँग DSL लेखकहरूको लागि सभ्य समर्थन छ। एकले यी सुविधाहरू प्रयोग गर्न सक्छ कन्फिगरेसन भाषा स्थापना गर्न जुन अधिक सुविधाजनक र अन्त-प्रयोगकर्ता मैत्री छ, ताकि अन्तिम कन्फिगरेसन कम्तिमा डोमेन प्रयोगकर्ताहरूले पढ्न योग्य होस्।
नोडहरूमा अखण्डता र एकता। एकै ठाउँमा सम्पूर्ण वितरण प्रणालीको लागि कन्फिगरेसन हुनुको एउटा फाइदा भनेको सबै मानहरूलाई एक पटक कडाइका साथ परिभाषित गरिन्छ र त्यसपछि हामीलाई आवश्यक पर्ने सबै ठाउँहरूमा पुन: प्रयोग गरिन्छ। सुरक्षित पोर्ट घोषणाहरू पनि टाइप गर्नुहोस् कि सबै सम्भावित सही कन्फिगरेसनहरूमा प्रणालीको नोडहरूले उही भाषा बोल्नेछन्। त्यहाँ नोडहरू बीच स्पष्ट निर्भरताहरू छन् जसले केही सेवाहरू प्रदान गर्न बिर्सन गाह्रो बनाउँछ।
परिवर्तनको उच्च गुणस्तर। सामान्य PR प्रक्रिया मार्फत कन्फिगरेसन परिवर्तनहरू पारित गर्ने समग्र दृष्टिकोणले कन्फिगरेसनमा पनि गुणस्तरको उच्च स्तरहरू स्थापना गर्दछ।
एकै साथ कन्फिगरेसन परिवर्तनहरू। जब हामी कन्फिगरेसनमा कुनै परिवर्तन गर्छौं स्वचालित डिप्लोयमेन्टले सबै नोडहरू अद्यावधिक भइरहेका छन् भन्ने सुनिश्चित गर्दछ।
आवेदन सरलीकरण। अनुप्रयोगले कन्फिगरेसनलाई पार्स र प्रमाणीकरण गर्न र गलत कन्फिगरेसन मानहरू ह्यान्डल गर्न आवश्यक पर्दैन। यसले समग्र अनुप्रयोगलाई सरल बनाउँछ। (केही जटिलता वृद्धि कन्फिगरेसनमा नै छ, तर यो सुरक्षाको लागि एक सचेत ट्रेड-अफ हो।) यो सामान्य कन्फिगरेसनमा फर्कन धेरै सीधा छ - हराएको टुक्राहरू थप्नुहोस्। कम्पाइल गरिएको कन्फिगरेसनको साथ सुरू गर्न र थप टुक्राहरूको कार्यान्वयनलाई पछिको समयमा स्थगित गर्न सजिलो छ।
संस्करण कन्फिगरेसन। कन्फिगरेसन परिवर्तनहरूले समान विकास प्रक्रियालाई पछ्याउने तथ्यको कारणले गर्दा, हामीले अद्वितीय संस्करणको साथ एक कलाकृति पाउँछौं। यसले हामीलाई आवश्यक भएमा कन्फिगरेसन फिर्ता गर्न अनुमति दिन्छ। हामी एक वर्ष पहिले प्रयोग गरिएको कन्फिगरेसन पनि डिप्लोय गर्न सक्छौं र यसले ठ्याक्कै उस्तै काम गर्नेछ। स्थिर कन्फिगरेसनले वितरण प्रणालीको भविष्यवाणी र विश्वसनीयता सुधार गर्दछ। कन्फिगरेसन कम्पाइल समयमा निश्चित गरिएको छ र उत्पादन प्रणालीमा सजिलैसँग छेडछाड गर्न सकिँदैन।
मोडुलरिटी। प्रस्तावित ढाँचा मोड्युलर छ र मोड्युलहरू विभिन्न तरिकामा जोड्न सकिन्छ
विभिन्न कन्फिगरेसनहरू (सेटअप/लेआउटहरू) समर्थन गर्नुहोस्। विशेष गरी, यो एक सानो स्केल एकल नोड लेआउट र ठूलो स्केल बहु नोड सेटिङ हुन सम्भव छ। बहु उत्पादन लेआउटहरू हुनु उचित छ।
परीक्षण। परीक्षण उद्देश्यका लागि एक नक्कली सेवा लागू गर्न र एक प्रकार सुरक्षित तरिकामा निर्भरता रूपमा प्रयोग गर्न सक्छ। नक्कली द्वारा प्रतिस्थापित विभिन्न भागहरु संग केहि फरक परीक्षण लेआउट एकै साथ कायम गर्न सकिन्छ।
एकीकरण परीक्षण। कहिलेकाहीँ वितरित प्रणालीहरूमा एकीकरण परीक्षणहरू चलाउन गाह्रो हुन्छ। पूर्ण वितरण प्रणालीको सुरक्षित कन्फिगरेसन टाइप गर्न वर्णित दृष्टिकोण प्रयोग गरेर, हामी सबै वितरित भागहरू एकल सर्भरमा नियन्त्रणयोग्य तरिकामा चलाउन सक्छौं। परिस्थिति अनुकरण गर्न सजिलो छ
जब सेवाहरू मध्ये एक अनुपलब्ध हुन्छ।

बेफाइदा

कम्पाइल गरिएको कन्फिगरेसन दृष्टिकोण "सामान्य" कन्फिगरेसन भन्दा फरक छ र यसले सबै आवश्यकताहरू अनुरूप नहुन सक्छ। यहाँ कम्पाइल गरिएको कन्फिगरेसनका केही बेफाइदाहरू छन्:

स्थिर कन्फिगरेसन। यो सबै अनुप्रयोगहरूको लागि उपयुक्त नहुन सक्छ। केही अवस्थामा त्यहाँ उत्पादन मा कन्फिगरेसन छिटो फिक्सिङ सबै सुरक्षा उपायहरू बाइपास गर्न आवश्यक छ। यो दृष्टिकोणले अझ गाह्रो बनाउँछ। कन्फिगरेसनमा कुनै पनि परिवर्तन गरेपछि संकलन र पुन: प्रयोग आवश्यक छ। यो सुविधा र बोझ दुवै हो।
कन्फिगरेसन पुस्ता। जब कन्फिगरेसन केहि स्वचालन उपकरण द्वारा उत्पन्न हुन्छ यस दृष्टिकोणलाई पछिको संकलन आवश्यक पर्दछ (जुन असफल हुन सक्छ)। निर्माण प्रणालीमा यो अतिरिक्त चरण एकीकृत गर्न थप प्रयास आवश्यक हुन सक्छ।
उपकरणहरू। त्यहाँ आज प्रयोगमा धेरै उपकरणहरू छन् जुन पाठ-आधारित कन्फिगरेसनहरूमा निर्भर छन्। तिनीहरूमध्ये केही
कन्फिगरेसन कम्पाइल हुँदा लागू हुने छैन।
मानसिकतामा परिवर्तन आवश्यक छ। विकासकर्ताहरू र DevOps पाठ कन्फिगरेसन फाइलहरूसँग परिचित छन्। कन्फिगरेसन कम्पाइल गर्ने विचार तिनीहरूलाई अनौठो लाग्न सक्छ।
कम्पाइल योग्य कन्फिगरेसन परिचय गर्नु अघि एक उच्च गुणस्तर सफ्टवेयर विकास प्रक्रिया आवश्यक छ।

लागू उदाहरणका केही सीमितताहरू छन्:

यदि हामीले अतिरिक्त कन्फिगरेसन प्रदान गर्छौं जुन नोड कार्यान्वयनद्वारा माग गरिएको छैन, कम्पाइलरले हामीलाई अनुपस्थित कार्यान्वयन पत्ता लगाउन मद्दत गर्दैन। यसलाई प्रयोग गरेर सम्बोधन गर्न सकिन्छ HList वा लक्षण र केक ढाँचाको सट्टा नोड कन्फिगरेसनको लागि ADTs (केस वर्गहरू)।
हामीले कन्फिगरेसन फाइलमा केही बोइलरप्लेट प्रदान गर्नुपर्छ: (package, import, object घोषणाहरू;
override defपूर्वनिर्धारित मानहरू भएका प्यारामिटरहरूको लागि)। यसलाई आंशिक रूपमा DSL प्रयोग गरेर सम्बोधन गर्न सकिन्छ।
यस पोष्टमा हामी समान नोडहरूको क्लस्टरहरूको गतिशील पुन: कन्फिगरेसनलाई कभर गर्दैनौं।

निष्कर्ष

यस पोष्टमा हामीले स्रोत कोडमा सीधा प्रकार सुरक्षित तरिकामा कन्फिगरेसन प्रतिनिधित्व गर्ने विचारलाई छलफल गरेका छौं। दृष्टिकोण धेरै अनुप्रयोगहरूमा xml- र अन्य पाठ-आधारित कन्फिगहरू प्रतिस्थापनको रूपमा प्रयोग गर्न सकिन्छ। यद्यपि हाम्रो उदाहरण स्कालामा लागू गरिएको छ, यो अन्य कम्पाइल गर्न योग्य भाषाहरूमा पनि अनुवाद गर्न सकिन्छ (जस्तै कोटलिन, सी #, स्विफ्ट, आदि)। कसैले नयाँ परियोजनामा यो दृष्टिकोण प्रयास गर्न सक्छ र, यदि यो राम्रोसँग फिट भएन भने, पुरानो शैलीमा स्विच गर्नुहोस्।

निस्सन्देह, कम्पाइल कन्फिगरेसन उच्च गुणस्तर विकास प्रक्रिया आवश्यक छ। बदलामा यसले समान रूपमा उच्च गुणस्तरको बलियो कन्फिगरेसन प्रदान गर्ने वाचा गर्दछ।

यो दृष्टिकोण विभिन्न तरिकामा विस्तार गर्न सकिन्छ:

एकले कन्फिगरेसन प्रमाणीकरण गर्न म्याक्रोहरू प्रयोग गर्न सक्छ र कुनै पनि व्यवसाय-तर्क अवरोध विफलताको अवस्थामा कम्पाइल समयमा असफल हुन सक्छ।
डोमेन-प्रयोगकर्ता-अनुकूल तरिकामा कन्फिगरेसन प्रतिनिधित्व गर्न DSL लागू गर्न सकिन्छ।
स्वचालित कन्फिगरेसन समायोजनको साथ गतिशील स्रोत व्यवस्थापन। उदाहरणका लागि, जब हामीले क्लस्टर नोडहरूको सङ्ख्या समायोजन गर्छौं भने हामीले (१) नोडहरू थोरै परिमार्जित कन्फिगरेसन प्राप्त गर्न चाहन्छौं; (1) क्लस्टर प्रबन्धक नयाँ नोड जानकारी प्राप्त गर्न।

धन्यवाद

म यस पोष्टको मस्यौदामा प्रेरणादायी प्रतिक्रिया दिनु भएकोमा Andrey Saksonov, Pavel Popov, Anton Nehaev लाई धन्यवाद भन्न चाहन्छु जसले मलाई यो स्पष्ट बनाउन मद्दत गर्यो।

स्रोत: www.habr.com