🥇 একটি বিতরণ করা সিস্টেমের সংকলিত কনফিগারেশন

আমি আপনাকে একটি বিতরণ করা সিস্টেমের কনফিগারেশনের সাথে কাজ করার জন্য একটি আকর্ষণীয় প্রক্রিয়া বলতে চাই। কনফিগারেশনটি নিরাপদ প্রকার ব্যবহার করে একটি সংকলিত ভাষায় (Scala) সরাসরি উপস্থাপন করা হয়। এই পোস্টটি এই ধরনের কনফিগারেশনের একটি উদাহরণ প্রদান করে এবং সামগ্রিক উন্নয়ন প্রক্রিয়ায় একটি সংকলিত কনফিগারেশন বাস্তবায়নের বিভিন্ন দিক নিয়ে আলোচনা করে।

(ইংরেজি)

ভূমিকা

একটি নির্ভরযোগ্য বিতরণ সিস্টেম তৈরির অর্থ হল সমস্ত নোড সঠিক কনফিগারেশন ব্যবহার করে, অন্যান্য নোডের সাথে সিঙ্ক্রোনাইজ করা হয়। DevOps প্রযুক্তিগুলি (টেরাফর্ম, উত্তরযোগ্য বা এরকম কিছু) সাধারণত স্বয়ংক্রিয়ভাবে কনফিগারেশন ফাইল তৈরি করতে ব্যবহৃত হয় (প্রায়ই প্রতিটি নোডের জন্য নির্দিষ্ট)। আমরা নিশ্চিত হতে চাই যে সমস্ত যোগাযোগ নোড অভিন্ন প্রোটোকল ব্যবহার করছে (একই সংস্করণ সহ)। অন্যথায়, আমাদের বিতরণ ব্যবস্থায় অসঙ্গতি তৈরি হবে। JVM বিশ্বে, এই প্রয়োজনীয়তার একটি ফলাফল হল যে প্রোটোকল বার্তাগুলি ধারণকারী লাইব্রেরির একই সংস্করণ সর্বত্র ব্যবহার করা আবশ্যক।

একটি বিতরণ সিস্টেম পরীক্ষা সম্পর্কে কি? অবশ্যই, আমরা অনুমান করি যে আমরা ইন্টিগ্রেশন টেস্টিং এ যাওয়ার আগে সমস্ত উপাদানের ইউনিট পরীক্ষা আছে। (আমাদের রানটাইমে পরীক্ষার ফলাফল এক্সট্রাপোলেট করার জন্য, আমাদের অবশ্যই পরীক্ষার পর্যায়ে এবং রানটাইমে একটি অভিন্ন লাইব্রেরি সরবরাহ করতে হবে।)

ইন্টিগ্রেশন পরীক্ষার সাথে কাজ করার সময়, সমস্ত নোডের সর্বত্র একই ক্লাসপথ ব্যবহার করা প্রায়শই সহজ হয়। আমাদের যা করতে হবে তা নিশ্চিত করতে হবে যে রানটাইমে একই ক্লাসপথ ব্যবহার করা হয়েছে। (যদিও বিভিন্ন ক্লাসপথের সাথে বিভিন্ন নোড চালানো সম্পূর্ণভাবে সম্ভব, এটি সামগ্রিক কনফিগারেশনে জটিলতা এবং স্থাপনা এবং একীকরণ পরীক্ষায় অসুবিধা যোগ করে।) এই পোস্টের উদ্দেশ্যে, আমরা ধরে নিচ্ছি যে সমস্ত নোড একই ক্লাসপথ ব্যবহার করবে।

কনফিগারেশন অ্যাপ্লিকেশনের সাথে বিকশিত হয়। আমরা প্রোগ্রাম বিবর্তনের বিভিন্ন ধাপ সনাক্ত করতে সংস্করণ ব্যবহার করি। কনফিগারেশনের বিভিন্ন সংস্করণ সনাক্ত করাও যৌক্তিক বলে মনে হয়। এবং কনফিগারেশনটি নিজেই সংস্করণ নিয়ন্ত্রণ ব্যবস্থায় রাখুন। যদি উত্পাদনে শুধুমাত্র একটি কনফিগারেশন থাকে তবে আমরা কেবল সংস্করণ নম্বরটি ব্যবহার করতে পারি। আমরা যদি অনেকগুলি উত্পাদন দৃষ্টান্ত ব্যবহার করি, তবে আমাদের বেশ কয়েকটি প্রয়োজন হবে
কনফিগারেশন শাখা এবং সংস্করণ ছাড়াও একটি অতিরিক্ত লেবেল (উদাহরণস্বরূপ, শাখার নাম)। এইভাবে আমরা স্পষ্টভাবে সঠিক কনফিগারেশন সনাক্ত করতে পারি। প্রতিটি কনফিগারেশন শনাক্তকারী অনন্যভাবে বিতরণ করা নোড, পোর্ট, বাহ্যিক সংস্থান এবং লাইব্রেরি সংস্করণগুলির একটি নির্দিষ্ট সংমিশ্রণের সাথে মিলে যায়। এই পোস্টের উদ্দেশ্যে আমরা অনুমান করব যে শুধুমাত্র একটি শাখা রয়েছে এবং আমরা একটি বিন্দু (1.2.3) দ্বারা পৃথক করা তিনটি সংখ্যা ব্যবহার করে স্বাভাবিক পদ্ধতিতে কনফিগারেশনটি সনাক্ত করতে পারি।

আধুনিক পরিবেশে, কনফিগারেশন ফাইল খুব কমই ম্যানুয়ালি তৈরি করা হয়। প্রায়শই তারা স্থাপনার সময় তৈরি হয় এবং আর স্পর্শ করা হয় না (তাই কিছু ভেঙ্গে না) একটি স্বাভাবিক প্রশ্ন উঠেছে: কেন আমরা এখনও কনফিগারেশন সঞ্চয় করার জন্য পাঠ্য বিন্যাস ব্যবহার করি? একটি কার্যকর বিকল্প কনফিগারেশনের জন্য নিয়মিত কোড ব্যবহার করার ক্ষমতা এবং কম্পাইল-টাইম চেক থেকে সুবিধা বলে মনে হয়।

এই পোস্টে আমরা একটি সংকলিত আর্টিফ্যাক্টের ভিতরে একটি কনফিগারেশনের প্রতিনিধিত্ব করার ধারণাটি অন্বেষণ করব।

সংকলিত কনফিগারেশন

এই বিভাগটি একটি স্ট্যাটিক কম্পাইল করা কনফিগারেশনের উদাহরণ প্রদান করে। দুটি সাধারণ পরিষেবা বাস্তবায়িত হয় - ইকো পরিষেবা এবং ইকো পরিষেবা ক্লায়েন্ট। এই দুটি পরিষেবার উপর ভিত্তি করে, দুটি সিস্টেম বিকল্প একত্রিত হয়। একটি বিকল্পে, উভয় পরিষেবা একই নোডে অবস্থিত, অন্য বিকল্পে - বিভিন্ন নোডে।

সাধারণত একটি বিতরণ করা সিস্টেমে বেশ কয়েকটি নোড থাকে। আপনি কিছু ধরণের মান ব্যবহার করে নোড সনাক্ত করতে পারেন 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])

যেখানে Port - শুধু একটি পূর্ণসংখ্যা Int গ্রহণযোগ্য মানের পরিসীমা নির্দেশ করে:

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

পরিমার্জিত প্রকার

লাইব্রেরি দেখুন মিহি и আমার রিপোর্ট. সংক্ষেপে, লাইব্রেরি আপনাকে কম্পাইলের সময় চেক করা প্রকারগুলিতে সীমাবদ্ধতা যুক্ত করতে দেয়। এই ক্ষেত্রে, বৈধ পোর্ট নম্বর মান হল 16-বিট পূর্ণসংখ্যা। একটি সংকলিত কনফিগারেশনের জন্য, পরিমার্জিত লাইব্রেরি ব্যবহার করা বাধ্যতামূলক নয়, তবে এটি কনফিগারেশন পরীক্ষা করার জন্য কম্পাইলারের ক্ষমতাকে উন্নত করে।

HTTP (REST) প্রোটোকলের জন্য, পোর্ট নম্বর ছাড়াও, আমাদের পরিষেবার পথেরও প্রয়োজন হতে পারে:

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

ফ্যান্টম প্রকার

কম্পাইলের সময় প্রোটোকল সনাক্ত করতে, আমরা একটি টাইপ প্যারামিটার ব্যবহার করি যা ক্লাসের মধ্যে ব্যবহার করা হয় না। এই সিদ্ধান্তটি এই কারণে যে আমরা রানটাইমে একটি প্রোটোকল উদাহরণ ব্যবহার করি না, তবে আমরা কম্পাইলারকে প্রোটোকলগুলির সামঞ্জস্য পরীক্ষা করতে চাই। প্রোটোকল নির্দিষ্ট করে, আমরা নির্ভরতা হিসাবে একটি অনুপযুক্ত পরিষেবা পাস করতে সক্ষম হব না।

সাধারণ প্রোটোকলগুলির মধ্যে একটি হল Json সিরিয়ালাইজেশন সহ REST API:

sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage]

যেখানে RequestMessage - অনুরোধের ধরন, ResponseMessage - প্রতিক্রিয়া প্রকার।
অবশ্যই, আমরা অন্যান্য প্রোটোকল বর্ণনা ব্যবহার করতে পারি যা আমাদের প্রয়োজনীয় বর্ণনার যথার্থতা প্রদান করে।

এই পোস্টের উদ্দেশ্যে, আমরা প্রোটোকলের একটি সরলীকৃত সংস্করণ ব্যবহার করব:

sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage]

এখানে অনুরোধটি url-এর সাথে যুক্ত একটি স্ট্রিং এবং প্রতিক্রিয়া হল HTTP প্রতিক্রিয়ার মূল অংশে ফিরে আসা স্ট্রিং।

পরিষেবা কনফিগারেশন পরিষেবার নাম, পোর্ট এবং নির্ভরতা দ্বারা বর্ণনা করা হয়। এই উপাদানগুলিকে স্কালায় বিভিন্ন উপায়ে উপস্থাপন করা যেতে পারে (উদাহরণস্বরূপ, HList-s, বীজগাণিতিক ডেটা প্রকার)। এই পোস্টের উদ্দেশ্যে, আমরা কেক প্যাটার্ন ব্যবহার করব এবং মডিউল ব্যবহার করে প্রতিনিধিত্ব করব trait's (কেক প্যাটার্ন এই পদ্ধতির একটি প্রয়োজনীয় উপাদান নয়। এটি কেবল একটি সম্ভাব্য বাস্তবায়ন।)

পরিষেবাগুলির মধ্যে নির্ভরতাগুলিকে পোর্টগুলি ফেরত দেওয়ার পদ্ধতি হিসাবে উপস্থাপন করা যেতে পারে 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 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 — একটি ইফেক্ট টাইপ ক্লাস যা আপনাকে আলাদা ইফেক্ট (প্রায় একটি মোনাড) একত্রিত করতে দেয়। আরও জটিল অ্যাপ্লিকেশনে এটি ব্যবহার করা ভাল বলে মনে হয় Monad/ConcurrentEffect.

এই ফাংশন স্বাক্ষর ব্যবহার করে আমরা বেশ কয়েকটি পরিষেবা বাস্তবায়ন করতে পারি। উদাহরণস্বরূপ, একটি পরিষেবা যা কিছুই করে না:

  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
}

দয়া করে মনে রাখবেন যে আমরা এই নোডের জন্য প্রয়োজনীয় কনফিগারেশনের সঠিক ধরনটি নির্দিষ্ট করছি। যদি আমরা একটি নির্দিষ্ট পরিষেবার জন্য প্রয়োজনীয় কনফিগারেশন প্রকারগুলির একটি নির্দিষ্ট করতে ভুলে যাই, তাহলে একটি সংকলন ত্রুটি হবে। এছাড়াও, আমরা একটি নোড শুরু করতে সক্ষম হব না যদি না আমরা সমস্ত প্রয়োজনীয় ডেটা সহ উপযুক্ত ধরণের কিছু অবজেক্ট প্রদান করি।

হোস্ট নেম রেজোলিউশন

একটি দূরবর্তী হোস্টের সাথে সংযোগ করতে, আমাদের একটি আসল আইপি ঠিকানা প্রয়োজন৷ এটা সম্ভব যে ঠিকানাটি বাকি কনফিগারেশনের চেয়ে পরে জানা যাবে। তাই আমাদের একটি ফাংশন দরকার যা একটি ঠিকানায় নোড আইডি ম্যাপ করে:

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 প্রোগ্রামটি বন্ধ করুন। (Ctrl-Cও কাজ করে এবং সমস্ত সংস্থান সঠিকভাবে মুক্ত করে।)

কনফিগারেশন এবং বাস্তবায়ন বৈশিষ্ট্যের একই সেট সমন্বিত একটি সিস্টেম তৈরি করতে ব্যবহার করা যেতে পারে দুটি পৃথক নোড:

দুটি নোড কনফিগারেশন

  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'ওম, এবং ক্লায়েন্ট নোড কিছু সময়ের পরে শেষ হয়ে যায়। সেমি. লঞ্চার অ্যাপ.

সাধারণ উন্নয়ন প্রক্রিয়া

আসুন দেখি কিভাবে এই কনফিগারেশন পদ্ধতি সামগ্রিক উন্নয়ন প্রক্রিয়াকে প্রভাবিত করে।

কনফিগারেশনটি বাকি কোডের সাথে কম্পাইল করা হবে এবং একটি আর্টিফ্যাক্ট (.jar) তৈরি করা হবে। কনফিগারেশনটিকে আলাদা আর্টিফ্যাক্টে রাখা অর্থপূর্ণ বলে মনে হচ্ছে। এর কারণ হল একই কোডের উপর ভিত্তি করে আমাদের একাধিক কনফিগারেশন থাকতে পারে। আবার, বিভিন্ন কনফিগারেশন শাখার সাথে সম্পর্কিত শিল্পকর্ম তৈরি করা সম্ভব। লাইব্রেরিগুলির নির্দিষ্ট সংস্করণের উপর নির্ভরতাগুলি কনফিগারেশনের সাথে সংরক্ষিত হয় এবং যখনই আমরা কনফিগারেশনের সেই সংস্করণটি স্থাপন করার সিদ্ধান্ত নিই তখন এই সংস্করণগুলি চিরতরে সংরক্ষণ করা হয়।

যেকোনো কনফিগারেশন পরিবর্তন একটি কোড পরিবর্তনে পরিণত হয়। এবং তাই, প্রতিটি
পরিবর্তনটি স্বাভাবিক গুণমান নিশ্চিতকরণ প্রক্রিয়া দ্বারা আচ্ছাদিত করা হবে:

বাগ ট্র্যাকারে টিকিট -> PR -> পর্যালোচনা -> প্রাসঙ্গিক শাখাগুলির সাথে একত্রিত করুন ->
ইন্টিগ্রেশন -> স্থাপনা

একটি সংকলিত কনফিগারেশন বাস্তবায়নের প্রধান ফলাফলগুলি হল:

কনফিগারেশনটি বিতরণ করা সিস্টেমের সমস্ত নোড জুড়ে সামঞ্জস্যপূর্ণ হবে। এই কারণে যে সমস্ত নোড একক উত্স থেকে একই কনফিগারেশন পায়।
শুধুমাত্র একটি নোডের কনফিগারেশন পরিবর্তন করা সমস্যাযুক্ত। অতএব, "কনফিগারেশন ড্রিফট" অসম্ভাব্য।
কনফিগারেশনে ছোট পরিবর্তন করা আরও কঠিন হয়ে পড়ে।
বেশিরভাগ কনফিগারেশন পরিবর্তন সামগ্রিক উন্নয়ন প্রক্রিয়ার অংশ হিসাবে ঘটবে এবং পর্যালোচনা সাপেক্ষে হবে।

প্রোডাকশন কনফিগারেশন সঞ্চয় করার জন্য আমার কি আলাদা রিপোজিটরি দরকার? এই কনফিগারেশনে পাসওয়ার্ড এবং অন্যান্য সংবেদনশীল তথ্য থাকতে পারে যা আমরা অ্যাক্সেস সীমাবদ্ধ করতে চাই। এর উপর ভিত্তি করে, এটি একটি পৃথক সংগ্রহস্থলে চূড়ান্ত কনফিগারেশন সংরক্ষণ করার জন্য অর্থপূর্ণ বলে মনে হচ্ছে। আপনি কনফিগারেশনটিকে দুটি অংশে বিভক্ত করতে পারেন—একটি সর্বজনীনভাবে অ্যাক্সেসযোগ্য কনফিগারেশন সেটিংস এবং একটি সীমাবদ্ধ সেটিংস ধারণকারী। এটি বেশিরভাগ ডেভেলপারদের সাধারণ সেটিংস অ্যাক্সেস করার অনুমতি দেবে। ডিফল্ট মান ধারণকারী মধ্যবর্তী বৈশিষ্ট্য ব্যবহার করে এই বিচ্ছেদ অর্জন করা সহজ।

সম্ভাব্য বৈচিত্র

আসুন কিছু সাধারণ বিকল্পের সাথে সংকলিত কনফিগারেশনের তুলনা করার চেষ্টা করি:

টার্গেট মেশিনে টেক্সট ফাইল।
কেন্দ্রীভূত কী-মূল্যের দোকান (etcd/zookeeper).
প্রসেস কম্পোনেন্ট যেগুলো প্রসেস রিস্টার্ট না করেই পুনরায় কনফিগার/রিস্টার্ট করা যায়।
আর্টিফ্যাক্ট এবং সংস্করণ নিয়ন্ত্রণের বাইরে কনফিগারেশন সংরক্ষণ করা।

টেক্সট ফাইলগুলি ছোট পরিবর্তনের ক্ষেত্রে উল্লেখযোগ্য নমনীয়তা প্রদান করে। সিস্টেম অ্যাডমিনিস্ট্রেটর রিমোট নোডে লগ ইন করতে, উপযুক্ত ফাইলগুলিতে পরিবর্তন করতে এবং পরিষেবাটি পুনরায় চালু করতে পারে। বড় সিস্টেমের জন্য, তবে, এই ধরনের নমনীয়তা পছন্দসই নাও হতে পারে। করা পরিবর্তনগুলি অন্য সিস্টেমে কোন চিহ্ন রেখে যায় না। কেউ পরিবর্তন পর্যালোচনা. ঠিক কে এবং কি কারণে পরিবর্তনগুলি করেছে তা নির্ধারণ করা কঠিন। পরিবর্তন পরীক্ষা করা হয় না. যদি সিস্টেমটি বিতরণ করা হয়, তাহলে প্রশাসক অন্যান্য নোডগুলিতে সংশ্লিষ্ট পরিবর্তন করতে ভুলে যেতে পারেন।

(এটাও লক্ষ করা উচিত যে একটি কম্পাইল করা কনফিগারেশন ব্যবহার করলে ভবিষ্যতে টেক্সট ফাইল ব্যবহার করার সম্ভাবনা বন্ধ হবে না। এটি একটি পার্সার এবং ভ্যালিডেটর যোগ করার জন্য যথেষ্ট হবে যা একই ধরনের আউটপুট তৈরি করে। Config, এবং আপনি টেক্সট ফাইল ব্যবহার করতে পারেন। এটি অবিলম্বে অনুসরণ করে যে একটি সংকলিত কনফিগারেশন সহ একটি সিস্টেমের জটিলতা পাঠ্য ফাইল ব্যবহার করে একটি সিস্টেমের জটিলতার চেয়ে কিছুটা কম, কারণ পাঠ্য ফাইলের জন্য অতিরিক্ত কোড প্রয়োজন।)

একটি কেন্দ্রীভূত কী-মানের দোকান একটি বিতরণ করা অ্যাপ্লিকেশনের মেটা পরামিতি বিতরণের জন্য একটি ভাল প্রক্রিয়া। আমাদের সিদ্ধান্ত নিতে হবে কনফিগারেশন পরামিতি কি এবং কি শুধু ডেটা। আমাদের একটি ফাংশন আছে C => A => B, এবং পরামিতি C কদাচিৎ পরিবর্তন, এবং ডেটা A - প্রায়ই এক্ষেত্রে আমরা তা বলতে পারি C - কনফিগারেশন পরামিতি, এবং A - ডেটা। এটি প্রদর্শিত হয় যে কনফিগারেশন পরামিতিগুলি ডেটা থেকে আলাদা যে তারা সাধারণত ডেটার তুলনায় কম ঘন ঘন পরিবর্তিত হয়৷ এছাড়াও, ডেটা সাধারণত একটি উৎস থেকে আসে (ব্যবহারকারীর কাছ থেকে), এবং কনফিগারেশন পরামিতি অন্য (সিস্টেম প্রশাসকের কাছ থেকে)।

যদি প্রোগ্রামটি পুনরায় চালু না করে কদাচিৎ পরিবর্তনশীল পরামিতিগুলি আপডেট করার প্রয়োজন হয়, তবে এটি প্রায়শই প্রোগ্রামের জটিলতার দিকে নিয়ে যেতে পারে, কারণ আমাদের কোনওভাবে প্যারামিটার সরবরাহ করতে হবে, সংরক্ষণ করতে হবে, পার্স করতে হবে এবং পরীক্ষা করতে হবে এবং ভুল মানগুলি প্রক্রিয়া করতে হবে। অতএব, প্রোগ্রামের জটিলতা কমানোর দৃষ্টিকোণ থেকে, প্রোগ্রাম পরিচালনার সময় পরিবর্তিত হতে পারে এমন পরামিতিগুলির সংখ্যা হ্রাস করা বোধগম্য হয় (বা এই জাতীয় পরামিতিগুলিকে সমর্থন করে না)।

এই পোস্টের উদ্দেশ্যে, আমরা স্ট্যাটিক এবং ডাইনামিক প্যারামিটারের মধ্যে পার্থক্য করব। যদি পরিষেবার যুক্তির জন্য প্রোগ্রামের অপারেশন চলাকালীন পরামিতি পরিবর্তনের প্রয়োজন হয়, তাহলে আমরা এই ধরনের পরামিতিগুলিকে গতিশীল বলব। অন্যথায় বিকল্পগুলি স্ট্যাটিক এবং কম্পাইল করা কনফিগারেশন ব্যবহার করে কনফিগার করা যেতে পারে। ডায়নামিক রিকনফিগারেশনের জন্য, অপারেটিং সিস্টেমের প্রসেসগুলি পুনরায় আরম্ভ করার অনুরূপ প্রোগ্রামের অংশগুলিকে নতুন প্যারামিটার সহ পুনরায় চালু করার জন্য আমাদের একটি ব্যবস্থার প্রয়োজন হতে পারে। (আমাদের মতে, রিয়েল-টাইম রিকনফিগারেশন এড়ানোর পরামর্শ দেওয়া হচ্ছে, যেহেতু এটি সিস্টেমের জটিলতা বাড়ায়। যদি সম্ভব হয়, প্রসেস পুনরায় চালু করার জন্য স্ট্যান্ডার্ড OS ক্ষমতাগুলি ব্যবহার করা ভাল।)

স্ট্যাটিক কনফিগারেশন ব্যবহার করার একটি গুরুত্বপূর্ণ দিক যা লোকেদের গতিশীল পুনর্বিন্যাস বিবেচনা করে তা হল কনফিগারেশন আপডেট (ডাউনটাইম) এর পরে সিস্টেমটি রিবুট হতে সময় লাগে। প্রকৃতপক্ষে, যদি আমাদের স্ট্যাটিক কনফিগারেশনে পরিবর্তন করতে হয়, নতুন মান কার্যকর করার জন্য আমাদের সিস্টেমটি পুনরায় চালু করতে হবে। ডাউনটাইম সমস্যা বিভিন্ন সিস্টেমের জন্য তীব্রতায় পরিবর্তিত হয়। কিছু ক্ষেত্রে, যখন লোড ন্যূনতম হয় তখন আপনি একটি রিবুটের সময় নির্ধারণ করতে পারেন। আপনি যদি ক্রমাগত পরিষেবা প্রদান করতে চান, আপনি বাস্তবায়ন করতে পারেন AWS ELB সংযোগ নিষ্কাশন. একই সময়ে, যখন আমাদের সিস্টেমটি পুনরায় বুট করতে হবে, আমরা এই সিস্টেমের একটি সমান্তরাল উদাহরণ চালু করি, এতে ব্যালেন্সারটি স্যুইচ করি এবং পুরানো সংযোগগুলি সম্পূর্ণ হওয়ার জন্য অপেক্ষা করি। সমস্ত পুরানো সংযোগ বন্ধ হয়ে যাওয়ার পরে, আমরা সিস্টেমের পুরানো উদাহরণটি বন্ধ করে দিই।

আসুন এখন আর্টিফ্যাক্টের ভিতরে বা বাইরে কনফিগারেশন সংরক্ষণের বিষয়টি বিবেচনা করা যাক। যদি আমরা একটি আর্টিফ্যাক্টের ভিতরে কনফিগারেশনটি সঞ্চয় করি, তাহলে অন্তত আমাদের আর্টিফ্যাক্টের সমাবেশের সময় কনফিগারেশনের সঠিকতা যাচাই করার সুযোগ ছিল। কনফিগারেশনটি নিয়ন্ত্রিত আর্টিফ্যাক্টের বাইরে থাকলে, কে এই ফাইলে পরিবর্তন করেছে এবং কেন তা ট্র্যাক করা কঠিন। এটা কতটা গুরুত্বপূর্ণ? আমাদের মতে, অনেক উত্পাদন সিস্টেমের জন্য একটি স্থিতিশীল এবং উচ্চ-মানের কনফিগারেশন থাকা গুরুত্বপূর্ণ।

একটি আর্টিফ্যাক্টের সংস্করণ আপনাকে এটি কখন তৈরি করা হয়েছিল, এতে কী কী মান রয়েছে, কী ফাংশন সক্ষম/অক্ষম করা হয়েছে এবং কনফিগারেশনে যে কোনও পরিবর্তনের জন্য কে দায়ী তা নির্ধারণ করতে দেয়। অবশ্যই, একটি আর্টিফ্যাক্টের ভিতরে কনফিগারেশন সংরক্ষণ করার জন্য কিছু প্রচেষ্টা প্রয়োজন, তাই আপনাকে একটি জ্ঞাত সিদ্ধান্ত নিতে হবে।

প্রো এবং কনস

আমি প্রস্তাবিত প্রযুক্তির সুবিধা এবং অসুবিধাগুলিতে থাকতে চাই।

উপকারিতা

নীচে একটি সংকলিত বিতরণ করা সিস্টেম কনফিগারেশনের প্রধান বৈশিষ্ট্যগুলির একটি তালিকা রয়েছে:

স্ট্যাটিক কনফিগারেশন চেক। আপনি যে নিশ্চিত হতে অনুমতি দেয়
কনফিগারেশন সঠিক।
সমৃদ্ধ কনফিগারেশন ভাষা. সাধারণত, অন্যান্য কনফিগারেশন পদ্ধতিগুলি সর্বাধিক স্ট্রিং পরিবর্তনশীল প্রতিস্থাপনের মধ্যে সীমাবদ্ধ। Scala ব্যবহার করার সময়, আপনার কনফিগারেশন উন্নত করার জন্য ভাষা বৈশিষ্ট্যের একটি বিস্তৃত পরিসর উপলব্ধ। উদাহরণস্বরূপ আমরা ব্যবহার করতে পারেন
ডিফল্ট মানের জন্য বৈশিষ্ট্য, গ্রুপ প্যারামিটারে অবজেক্ট ব্যবহার করে, আমরা এনক্লোসিং স্কোপে শুধুমাত্র একবার (DRY) ঘোষিত ভালগুলি উল্লেখ করতে পারি। আপনি সরাসরি কনফিগারেশনের ভিতরে যেকোনো ক্লাস ইনস্ট্যান্ট করতে পারেন (Seq, Map, কাস্টম ক্লাস)।
ডিএসএল। স্কালাতে অনেকগুলি ভাষা বৈশিষ্ট্য রয়েছে যা একটি DSL তৈরি করা সহজ করে তোলে। এই বৈশিষ্ট্যগুলির সুবিধা নেওয়া এবং ব্যবহারকারীদের লক্ষ্য গোষ্ঠীর জন্য আরও সুবিধাজনক একটি কনফিগারেশন ভাষা প্রয়োগ করা সম্ভব, যাতে কনফিগারেশনটি অন্তত ডোমেন বিশেষজ্ঞদের দ্বারা পাঠযোগ্য হয়। বিশেষজ্ঞরা, উদাহরণস্বরূপ, কনফিগারেশন পর্যালোচনা প্রক্রিয়ায় অংশগ্রহণ করতে পারেন।
নোডের মধ্যে অখণ্ডতা এবং সিঙ্ক্রোনি। একটি একক বিন্দুতে সংরক্ষিত একটি সম্পূর্ণ বিতরণ করা সিস্টেমের কনফিগারেশন থাকার সুবিধাগুলির মধ্যে একটি হল যে সমস্ত মান ঠিক একবার ঘোষণা করা হয় এবং তারপরে যেখানে প্রয়োজন সেখানে পুনরায় ব্যবহার করা হয়। পোর্ট ঘোষণা করার জন্য ফ্যান্টম প্রকারগুলি ব্যবহার করা নিশ্চিত করে যে নোডগুলি সমস্ত সঠিক সিস্টেম কনফিগারেশনে সামঞ্জস্যপূর্ণ প্রোটোকল ব্যবহার করছে। নোডগুলির মধ্যে স্পষ্ট বাধ্যতামূলক নির্ভরতা থাকা নিশ্চিত করে যে সমস্ত পরিষেবা সংযুক্ত রয়েছে।
উচ্চ মানের পরিবর্তন। একটি সাধারণ বিকাশ প্রক্রিয়া ব্যবহার করে কনফিগারেশনে পরিবর্তন করা কনফিগারেশনের জন্যও উচ্চ মানের মান অর্জন করা সম্ভব করে তোলে।
যুগপত কনফিগারেশন আপডেট। কনফিগারেশন পরিবর্তনের পরে স্বয়ংক্রিয় সিস্টেম স্থাপনা নিশ্চিত করে যে সমস্ত নোড আপডেট করা হয়েছে।
আবেদন সরলীকরণ. অ্যাপ্লিকেশনটির পার্সিং, কনফিগারেশন চেকিং বা ভুল মান পরিচালনার প্রয়োজন নেই। এটি প্রয়োগের জটিলতা হ্রাস করে। (আমাদের উদাহরণে পরিলক্ষিত কিছু কনফিগারেশন জটিলতা সংকলিত কনফিগারেশনের একটি বৈশিষ্ট্য নয়, তবে শুধুমাত্র একটি সচেতন সিদ্ধান্ত যা বৃহত্তর ধরণের নিরাপত্তা প্রদানের ইচ্ছা দ্বারা চালিত হয়।) স্বাভাবিক কনফিগারেশনে ফিরে আসা বেশ সহজ - শুধু অনুপস্থিতগুলি বাস্তবায়ন করুন অংশ অতএব, আপনি, উদাহরণস্বরূপ, একটি সংকলিত কনফিগারেশন দিয়ে শুরু করতে পারেন, অপ্রয়োজনীয় অংশগুলির বাস্তবায়নকে স্থগিত করে যতক্ষণ না এটি সত্যিই প্রয়োজন হয়।
যাচাইকৃত কনফিগারেশন। যেহেতু কনফিগারেশন পরিবর্তনগুলি অন্য যেকোনো পরিবর্তনের স্বাভাবিক ভাগ্যকে অনুসরণ করে, তাই আমরা যে আউটপুটটি পাই তা একটি অনন্য সংস্করণ সহ একটি আর্টিফ্যাক্ট। এটি আমাদের অনুমতি দেয়, উদাহরণস্বরূপ, প্রয়োজনে কনফিগারেশনের পূর্ববর্তী সংস্করণে ফিরে যেতে। আমরা এমনকি এক বছর আগে থেকে কনফিগারেশন ব্যবহার করতে পারি এবং সিস্টেমটি ঠিক একইভাবে কাজ করবে। একটি স্থিতিশীল কনফিগারেশন একটি বিতরণ সিস্টেমের পূর্বাভাস এবং নির্ভরযোগ্যতা উন্নত করে। যেহেতু কনফিগারেশনটি সংকলন পর্যায়ে স্থির করা হয়েছে, তাই উৎপাদনে এটি জাল করা বেশ কঠিন।
মডুলারিটি। প্রস্তাবিত কাঠামোটি মডুলার এবং মডিউলগুলিকে বিভিন্ন উপায়ে একত্রিত করে বিভিন্ন সিস্টেম তৈরি করা যেতে পারে। বিশেষ করে, আপনি একটি মূর্তিতে একটি একক নোডে এবং অন্যটিতে একাধিক নোডে চালানোর জন্য সিস্টেমটিকে কনফিগার করতে পারেন। আপনি সিস্টেমের উত্পাদন উদাহরণের জন্য বিভিন্ন কনফিগারেশন তৈরি করতে পারেন।
পরীক্ষামূলক. মক অবজেক্টগুলির সাথে পৃথক পরিষেবাগুলি প্রতিস্থাপন করে, আপনি সিস্টেমের বেশ কয়েকটি সংস্করণ পেতে পারেন যা পরীক্ষার জন্য সুবিধাজনক।
ইন্টিগ্রেশন টেস্টিং. সমগ্র বিতরণ করা সিস্টেমের জন্য একটি একক কনফিগারেশন থাকার ফলে ইন্টিগ্রেশন পরীক্ষার অংশ হিসাবে একটি নিয়ন্ত্রিত পরিবেশে সমস্ত উপাদান চালানো সম্ভব হয়। এটি অনুকরণ করা সহজ, উদাহরণস্বরূপ, এমন একটি পরিস্থিতি যেখানে কিছু নোড অ্যাক্সেসযোগ্য হয়ে ওঠে।

অসুবিধা এবং সীমাবদ্ধতা

কম্পাইল করা কনফিগারেশন অন্যান্য কনফিগারেশন পদ্ধতির থেকে আলাদা এবং কিছু অ্যাপ্লিকেশনের জন্য উপযুক্ত নাও হতে পারে। নীচে কিছু অসুবিধা আছে:

স্ট্যাটিক কনফিগারেশন। কখনও কখনও আপনাকে সমস্ত প্রতিরক্ষামূলক প্রক্রিয়া বাইপাস করে উত্পাদনে কনফিগারেশনটি দ্রুত সংশোধন করতে হবে। এই পদ্ধতির সাথে এটি আরও কঠিন হতে পারে। খুব অন্তত, সংকলন এবং স্বয়ংক্রিয় স্থাপনা এখনও প্রয়োজন হবে। এটি পদ্ধতির একটি দরকারী বৈশিষ্ট্য এবং কিছু ক্ষেত্রে একটি অসুবিধা উভয়ই।
কনফিগারেশন প্রজন্ম। যদি কনফিগারেশন ফাইলটি একটি স্বয়ংক্রিয় সরঞ্জাম দ্বারা তৈরি করা হয়, তবে বিল্ড স্ক্রিপ্টকে সংহত করার জন্য অতিরিক্ত প্রচেষ্টার প্রয়োজন হতে পারে।
টুলস। বর্তমানে, কনফিগারেশনের সাথে কাজ করার জন্য ডিজাইন করা ইউটিলিটি এবং কৌশলগুলি পাঠ্য ফাইলের উপর ভিত্তি করে। কম্পাইল করা কনফিগারেশনে এই ধরনের সমস্ত ইউটিলিটি/টেকনিক পাওয়া যাবে না।
দৃষ্টিভঙ্গির পরিবর্তন প্রয়োজন। বিকাশকারী এবং DevOps পাঠ্য ফাইলে অভ্যস্ত। একটি কনফিগারেশন কম্পাইল করার ধারণাটি কিছুটা অপ্রত্যাশিত এবং অস্বাভাবিক এবং প্রত্যাখ্যানের কারণ হতে পারে।
একটি উচ্চ মানের উন্নয়ন প্রক্রিয়া প্রয়োজন. সংকলিত কনফিগারেশনটি আরামদায়কভাবে ব্যবহার করার জন্য, অ্যাপ্লিকেশন (CI/CD) তৈরি এবং স্থাপনের প্রক্রিয়াটির সম্পূর্ণ অটোমেশন প্রয়োজন। অন্যথায় এটি বেশ অসুবিধাজনক হবে।

আসুন আমরা বিবেচিত উদাহরণের বেশ কয়েকটি সীমাবদ্ধতার বিষয়েও চিন্তা করি যা একটি সংকলিত কনফিগারেশনের ধারণার সাথে সম্পর্কিত নয়:

যদি আমরা অপ্রয়োজনীয় কনফিগারেশন তথ্য প্রদান করি যা নোড দ্বারা ব্যবহৃত হয় না, তাহলে কম্পাইলার আমাদের অনুপস্থিত বাস্তবায়ন সনাক্ত করতে সাহায্য করবে না। এই সমস্যাটি কেক প্যাটার্ন ত্যাগ করে এবং আরও কঠোর ধরনের ব্যবহার করে সমাধান করা যেতে পারে, উদাহরণস্বরূপ, HList বা বীজগাণিতিক ডেটা টাইপ (কেস ক্লাস) কনফিগারেশন প্রতিনিধিত্ব করতে.
কনফিগারেশন ফাইলে এমন লাইন রয়েছে যা কনফিগারেশনের সাথে সম্পর্কিত নয়: (package, import,বস্তু ঘোষণা; override defডিফল্ট মান আছে এমন প্যারামিটারের জন্য 's)। আপনি যদি নিজের ডিএসএল বাস্তবায়ন করেন তবে এটি আংশিকভাবে এড়ানো যেতে পারে। উপরন্তু, অন্যান্য ধরনের কনফিগারেশন (উদাহরণস্বরূপ, XML) ফাইল কাঠামোর উপর নির্দিষ্ট সীমাবদ্ধতা আরোপ করে।
এই পোস্টের উদ্দেশ্যে, আমরা অনুরূপ নোডগুলির একটি ক্লাস্টারের গতিশীল পুনর্বিন্যাস বিবেচনা করছি না।

উপসংহার

এই পোস্টে, আমরা স্কালা টাইপ সিস্টেমের উন্নত ক্ষমতা ব্যবহার করে সোর্স কোডে কনফিগারেশনের প্রতিনিধিত্ব করার ধারণাটি অন্বেষণ করেছি। এই পদ্ধতিটি xml বা টেক্সট ফাইলের উপর ভিত্তি করে প্রচলিত কনফিগারেশন পদ্ধতির প্রতিস্থাপন হিসাবে বিভিন্ন অ্যাপ্লিকেশনে ব্যবহার করা যেতে পারে। যদিও আমাদের উদাহরণ স্কালাতে প্রয়োগ করা হয়েছে, একই ধারণাগুলি অন্যান্য সংকলিত ভাষায় স্থানান্তর করা যেতে পারে (যেমন কোটলিন, সি#, সুইফট, ...)। আপনি নিম্নলিখিত প্রকল্পগুলির মধ্যে একটিতে এই পদ্ধতির চেষ্টা করতে পারেন, এবং, যদি এটি কাজ না করে, অনুপস্থিত অংশগুলি যোগ করে পাঠ্য ফাইলে যান।

স্বাভাবিকভাবেই, একটি সংকলিত কনফিগারেশনের জন্য একটি উচ্চ মানের উন্নয়ন প্রক্রিয়া প্রয়োজন। বিনিময়ে, কনফিগারেশনের উচ্চ গুণমান এবং নির্ভরযোগ্যতা নিশ্চিত করা হয়।

বিবেচিত পদ্ধতি প্রসারিত করা যেতে পারে:

আপনি কম্পাইল-টাইম চেক করতে ম্যাক্রো ব্যবহার করতে পারেন।
কনফিগারেশনটি এমনভাবে উপস্থাপন করতে আপনি একটি DSL প্রয়োগ করতে পারেন যা শেষ ব্যবহারকারীদের কাছে অ্যাক্সেসযোগ্য।
আপনি স্বয়ংক্রিয় কনফিগারেশন সমন্বয় সহ গতিশীল সম্পদ ব্যবস্থাপনা বাস্তবায়ন করতে পারেন। উদাহরণস্বরূপ, একটি ক্লাস্টারে নোডের সংখ্যা পরিবর্তন করার জন্য প্রয়োজন যে (1) প্রতিটি নোড একটি সামান্য ভিন্ন কনফিগারেশন পায়; (2) ক্লাস্টার ম্যানেজার নতুন নোড সম্পর্কে তথ্য পেয়েছেন।

স্বীকৃতি

খসড়া নিবন্ধের গঠনমূলক সমালোচনার জন্য আমি আন্দ্রেই সাকসোনভ, পাভেল পপভ এবং আন্তন নেখায়েভকে ধন্যবাদ জানাতে চাই।

উত্স: www.habr.com

কম্পাইল ডিস্ট্রিবিউটেড সিস্টেম কনফিগারেশন