תצורת מערכת מבוזרת מהודרת

אני רוצה לספר לכם מנגנון מעניין אחד לעבודה עם תצורה של מערכת מבוזרת. התצורה מיוצגת ישירות בשפה מהודרת (Scala) באמצעות סוגים בטוחים. פוסט זה מספק דוגמה לתצורה כזו ודן בהיבטים שונים של יישום תצורה מהודרת בתהליך הפיתוח הכולל.

(אנגלית)

מבוא

בניית מערכת מבוזרת אמינה פירושה שכל הצמתים משתמשים בתצורה הנכונה, המסונכרנת עם צמתים אחרים. טכנולוגיות DevOps (terraform, ansible או משהו כזה) משמשות בדרך כלל ליצירת קבצי תצורה אוטומטית (לעיתים קרובות ספציפיים לכל צומת). אנו גם רוצים להיות בטוחים שכל הצמתים המתקשרים משתמשים בפרוטוקולים זהים (כולל אותה גרסה). אחרת, אי תאימות תהיה מובנית במערכת המבוזרת שלנו. בעולם JVM, אחת ההשלכות של דרישה זו היא שיש להשתמש באותה גרסה של הספרייה המכילה את הודעות הפרוטוקול בכל מקום.

מה לגבי בדיקת מערכת מבוזרת? כמובן, אנו מניחים שלכל הרכיבים יש בדיקות יחידה לפני שאנו עוברים לבדיקות אינטגרציה. (כדי שנוכל לבצע אקסטרפולציה של תוצאות בדיקה לזמן ריצה, עלינו לספק גם קבוצה זהה של ספריות בשלב הבדיקה ובזמן הריצה.)

כשעובדים עם מבחני אינטגרציה, לרוב קל יותר להשתמש באותו נתיב מחלקה בכל מקום בכל הצמתים. כל שעלינו לעשות הוא לוודא שמשתמשים באותו נתיב מחלקה בזמן ריצה. (אמנם זה אפשרי לחלוטין להפעיל צמתים שונים עם נתיבים שונים, אבל זה מוסיף מורכבות לתצורה הכוללת ולקשיים עם בדיקות פריסה ואינטגרציה.) למטרות פוסט זה, אנו מניחים שכל הצמתים ישתמשו באותו classpath.

התצורה מתפתחת עם האפליקציה. אנו משתמשים בגרסאות כדי לזהות שלבים שונים של התפתחות התוכנית. נראה הגיוני לזהות גם גרסאות שונות של תצורות. והצב את התצורה עצמה במערכת בקרת הגרסאות. אם יש רק תצורה אחת בייצור, אז אנחנו יכולים פשוט להשתמש במספר הגרסה. אם נשתמש במופעי ייצור רבים, אז נצטרך כמה
ענפי תצורה ותווית נוספת בנוסף לגרסה (לדוגמה, שם הסניף). כך נוכל לזהות בבירור את התצורה המדויקת. כל מזהה תצורה מתאים באופן ייחודי לשילוב ספציפי של צמתים מבוזרים, יציאות, משאבים חיצוניים וגרסאות ספרייה. לצורך פוסט זה נניח שיש רק ענף אחד ונוכל לזהות את התצורה בדרך הרגילה באמצעות שלושה מספרים מופרדים בנקודה (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)

סוגי פאנטום

כדי לזהות את הפרוטוקול בזמן הקומפילציה, אנו משתמשים בפרמטר type שאינו בשימוש בתוך המחלקה. החלטה זו נובעת מהעובדה שאנו לא משתמשים במופע פרוטוקול בזמן ריצה, אך נרצה שהמהדר יבדוק תאימות לפרוטוקול. על ידי ציון הפרוטוקול, לא נוכל להעביר שירות לא הולם כתלות.

אחד הפרוטוקולים הנפוצים הוא ה-REST API עם הסדרת Json:

sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage]

איפה RequestMessage - סוג בקשה, ResponseMessage - סוג תגובה.
כמובן, אנו יכולים להשתמש בתיאורי פרוטוקול אחרים המספקים את דיוק התיאור שאנו דורשים.

למטרות פוסט זה, נשתמש בגרסה פשוטה של ​​הפרוטוקול:

sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage]

כאן הבקשה היא מחרוזת המצורפת לכתובת ה-URL והתגובה היא המחרוזת המוחזרת בגוף תגובת ה-HTTP.

תצורת השירות מתוארת לפי שם השירות, היציאות והתלות. אלמנטים אלה יכולים להיות מיוצגים בסקאלה בכמה דרכים (לדוגמה, HList-s, סוגי נתונים אלגבריים). למטרות פוסט זה, נשתמש בתבנית העוגה ונציג מודולים המשתמשים trait'אוב. (דפוס העוגה אינו מרכיב נדרש בגישה זו. הוא פשוט יישום אפשרי אחד).

תלות בין שירותים יכולה להיות מיוצגת כשיטות המחזירות יציאות 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. בפרט, ב-echo client אנו דורשים את אותו פרוטוקול. לכן, כאשר מחברים שני שירותים, אנו יכולים להיות בטוחים שהכל יעבוד כמו שצריך.

הטמעת שירותים

נדרשת פונקציה כדי להפעיל ולהפסיק את השירות. (היכולת לעצור שירות היא קריטית לבדיקה.) שוב, ישנן מספר אפשרויות ליישום תכונה כזו (לדוגמה, נוכל להשתמש במחלקות סוג המבוססות על סוג התצורה). למטרות פוסט זה נשתמש בתבנית העוגה. נציג את השירות באמצעות מחלקה 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
}

שים לב שאנו מציינים את סוג התצורה המדויק הנדרש עבור צומת זה. אם נשכח לציין את אחד מסוגי התצורה הנדרשים על ידי שירות מסוים, תהיה שגיאת קומפילציה. כמו כן, לא נוכל להפעיל צומת אלא אם נספק אובייקט כלשהו מהסוג המתאים עם כל הנתונים הדרושים.

רזולוציית שם מארח

כדי להתחבר למארח מרוחק, אנחנו צריכים כתובת IP אמיתית. ייתכן שהכתובת תיוודע מאוחר יותר משאר התצורה. אז אנחנו צריכים פונקציה שממפה את מזהה הצומת לכתובת:

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

ישנן מספר דרכים ליישם פונקציה זו:

1. אם הכתובות נודעות לנו לפני הפריסה, אז נוכל ליצור קוד Scala עם
   כתובות ולאחר מכן הפעל את ה-build. זה יקמפל ויפעיל בדיקות.
   במקרה זה, הפונקציה תהיה ידועה באופן סטטי וניתן לייצג אותה בקוד כמיפוי 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 להפסיק את התוכנית. (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). נראה הגיוני לשים את התצורה בחפץ נפרד. הסיבה לכך היא שיכולות להיות לנו מספר תצורות המבוססות על אותו קוד. שוב, ניתן ליצור חפצים התואמים לענפי תצורה שונים. התלות בגרסאות ספציפיות של ספריות נשמרות יחד עם התצורה, וגרסאות אלו נשמרות לנצח בכל פעם שאנו מחליטים לפרוס את הגרסה הזו של התצורה.

כל שינוי תצורה הופך לשינוי קוד. ולכן, כל אחד
השינוי יכוסה בתהליך אבטחת האיכות הרגיל:

כרטיס במעקב אחר באגים -> יחסי ציבור -> סקירה -> מיזוג עם סניפים רלוונטיים ->
אינטגרציה -> פריסה

ההשלכות העיקריות של יישום תצורה מהודרת הן:

1. התצורה תהיה עקבית בכל הצמתים של המערכת המבוזרת. בשל העובדה שכל הצמתים מקבלים את אותה תצורה ממקור יחיד.

2. זה בעייתי לשנות את התצורה רק באחד מהצמתים. לכן, "סחף תצורה" אינו סביר.

3. זה הופך להיות קשה יותר לבצע שינויים קטנים בתצורה.

4. רוב שינויי התצורה יתרחשו כחלק מתהליך הפיתוח הכולל ויהיו כפופים לבדיקה.

האם אני צריך מאגר נפרד כדי לאחסן את תצורת הייצור? תצורה זו עשויה להכיל סיסמאות ומידע רגיש אחר אליהם נרצה להגביל את הגישה. בהתבסס על זה, נראה הגיוני לאחסן את התצורה הסופית במאגר נפרד. אתה יכול לפצל את התצורה לשני חלקים - אחד המכיל הגדרות תצורה נגישות לציבור ואחד המכיל הגדרות מוגבלות. זה יאפשר לרוב המפתחים לקבל גישה להגדרות נפוצות. הפרדה זו קלה להשגה באמצעות תכונות ביניים המכילות ערכי ברירת מחדל.

וריאציות אפשריות

הבה ננסה להשוות את התצורה המורכבת עם כמה חלופות נפוצות:

1. קובץ טקסט במחשב היעד.
2. חנות מפתח-ערך מרכזית (etcd/zookeeper).
3. רכיבי תהליך שניתן להגדיר/להפעיל מחדש מבלי להפעיל מחדש את התהליך.
4. אחסון תצורה מחוץ לחפצים ובקרת גרסאות.

קבצי טקסט מספקים גמישות משמעותית מבחינת שינויים קטנים. מנהל המערכת יכול להיכנס לצומת המרוחק, לבצע שינויים בקבצים המתאימים ולהפעיל מחדש את השירות. עם זאת, עבור מערכות גדולות, גמישות כזו עשויה שלא להיות רצויה. השינויים שבוצעו אינם משאירים עקבות במערכות אחרות. אף אחד לא סוקר את השינויים. קשה לקבוע מי בדיוק ביצע את השינויים ומאיזו סיבה. שינויים אינם נבדקים. אם המערכת מופצת, המנהל עשוי לשכוח לבצע את השינוי המתאים בצמתים אחרים.

(יש לציין גם ששימוש בתצורה מהודרת לא סוגר את האפשרות להשתמש בקבצי טקסט בעתיד. יספיק להוסיף מנתח ומאמת שמייצר את אותו הסוג כמו פלט Config, ואתה יכול להשתמש בקבצי טקסט. מיד נובע שהמורכבות של מערכת עם תצורת קומפילציה קטנה במעט מהמורכבות של מערכת המשתמשת בקבצי טקסט, מכיוון קובצי טקסט דורשים קוד נוסף.)

מאגר מפתח-ערך מרכזי הוא מנגנון טוב להפצת מטא פרמטרים של יישום מבוזר. אנחנו צריכים להחליט מה הם פרמטרי תצורה ומה הם רק נתונים. תנו לנו פונקציה C => A => B, והפרמטרים C משתנה לעתים רחוקות, ונתונים A - לעתים קרובות. במקרה הזה אפשר להגיד את זה C - פרמטרי תצורה, ו A - נתונים. נראה כי פרמטרי תצורה שונים מהנתונים בכך שהם בדרך כלל משתנים בתדירות נמוכה יותר מאשר נתונים. כמו כן, נתונים בדרך כלל מגיעים ממקור אחד (מהמשתמש), ופרמטרי תצורה ממקור אחר (ממנהל המערכת).

אם לעתים נדירות יש לעדכן פרמטרים המשתנים מבלי להפעיל מחדש את התוכנית, אז זה יכול להוביל לעתים קרובות לסיבוך של התוכנית, מכיוון שנצטרך איכשהו לספק פרמטרים, לאחסן, לנתח ולבדוק ולעבד ערכים שגויים. לכן, מנקודת המבט של הפחתת המורכבות של התוכנית, הגיוני לצמצם את מספר הפרמטרים שיכולים להשתנות במהלך פעולת התוכנית (או לא לתמוך בפרמטרים כאלה בכלל).

לצורך הפוסט הזה, נבדיל בין פרמטרים סטטיים ודינאמיים. אם ההיגיון של השירות דורש שינוי פרמטרים במהלך פעולת התוכנית, אזי נקרא לפרמטרים כאלה דינמיים. אחרת האפשרויות הן סטטיות וניתן להגדיר אותן באמצעות התצורה הקומפילטית. עבור הגדרה מחדש דינמית, ייתכן שנצטרך מנגנון להפעלה מחדש של חלקים מהתוכנית עם פרמטרים חדשים, בדומה לאופן שבו תהליכי מערכת ההפעלה מופעלים מחדש. (לדעתנו, רצוי להימנע מהגדרה מחדש בזמן אמת, שכן הדבר מגדיל את מורכבות המערכת. במידת האפשר, עדיף להשתמש ביכולות מערכת ההפעלה הסטנדרטיות לצורך הפעלה מחדש של תהליכים).

היבט חשוב אחד של שימוש בתצורה סטטית שגורם לאנשים לשקול תצורה מחדש דינמית הוא הזמן שלוקח למערכת לאתחל מחדש לאחר עדכון תצורה (השבתה). למעשה, אם נצטרך לבצע שינויים בתצורה הסטטית, נצטרך להפעיל מחדש את המערכת כדי שהערכים החדשים ייכנסו לתוקף. בעיית זמן ההשבתה משתנה בחומרתה עבור מערכות שונות. במקרים מסוימים, אתה יכול לתזמן אתחול מחדש בזמן שבו העומס מינימלי. אם אתה צריך לספק שירות רציף, אתה יכול ליישם ניקוז חיבור AWS ELB. במקביל, כאשר אנו צריכים לאתחל את המערכת, אנו מפעילים מופע מקביל של מערכת זו, מעבירים אליו את האיזון ומחכים להשלמת החיבורים הישנים. לאחר שכל החיבורים הישנים הסתיימו, אנו מכבים את המופע הישן של המערכת.

הבה נבחן כעת את הנושא של אחסון התצורה בתוך או מחוצה לו החפץ. אם נאחסן את התצורה בתוך חפץ, אז לפחות הייתה לנו הזדמנות לאמת את נכונות התצורה במהלך ההרכבה של החפץ. אם התצורה נמצאת מחוץ לארטיפקט הנשלט, קשה לעקוב אחר מי ביצע שינויים בקובץ הזה ומדוע. כמה זה חשוב? לדעתנו, עבור מערכות ייצור רבות חשוב שתהיה תצורה יציבה ואיכותית.

הגרסה של חפץ מאפשרת לך לקבוע מתי הוא נוצר, אילו ערכים הוא מכיל, אילו פונקציות מופעלות/מושבתות ומי אחראי לכל שינוי בתצורה. כמובן, אחסון התצורה בתוך חפץ דורש קצת מאמץ, אז אתה צריך לקבל החלטה מושכלת.

היתרונות והחסרונות

אני רוצה להתעכב על היתרונות והחסרונות של הטכנולוגיה המוצעת.

יתרונות

להלן רשימה של התכונות העיקריות של תצורת מערכת מבוזרת מהודרת:

1. בדיקת תצורה סטטית. מאפשר לך להיות בטוח בכך
   התצורה נכונה.
2. שפת תצורה עשירה. בדרך כלל, שיטות תצורה אחרות מוגבלות להחלפת משתני מחרוזת לכל היותר. בעת שימוש ב-Scala, מגוון רחב של תכונות שפה זמינות כדי לשפר את התצורה שלך. למשל אנחנו יכולים להשתמש
   תכונות עבור ערכי ברירת מחדל, באמצעות אובייקטים לקבץ פרמטרים, אנו יכולים להתייחס ל-vals שהוכרזו רק פעם אחת (DRY) בהיקף המקיף. אתה יכול להפעיל כל שיעור ישירות בתוך התצורה (Seq, Map, שיעורים מותאמים אישית).
3. DSL. ל-Scala יש מספר תכונות שפה המקלות על יצירת DSL. אפשר לנצל את התכונות הללו ולהטמיע שפת קונפיגורציה הנוחה יותר לקבוצת היעד של המשתמשים, כך שהקונפיגורציה תהיה ניתנת לקריאה לפחות על ידי מומחי תחום. מומחים יכולים, למשל, להשתתף בתהליך סקירת התצורה.
4. שלמות וסנכרון בין צמתים. אחד היתרונות של התצורה של מערכת מבוזרת שלמה מאוחסנת בנקודה אחת הוא שכל הערכים מוצהרים בדיוק פעם אחת ואז נעשה בהם שימוש חוזר בכל מקום בו הם נדרשים. שימוש בסוגי פנטום להכרזה על יציאות מבטיח שהצמתים משתמשים בפרוטוקולים תואמים בכל תצורות המערכת הנכונות. תלות חובה מפורשת בין צמתים מבטיחה שכל השירותים מחוברים.
5. שינויים באיכות גבוהה. ביצוע שינויים בתצורה באמצעות תהליך פיתוח משותף מאפשר להגיע לתקני איכות גבוהים גם לתצורה.
6. עדכון תצורה בו זמנית. פריסת מערכת אוטומטית לאחר שינויי תצורה מבטיחה שכל הצמתים מעודכנים.
7. פישוט היישום. היישום אינו זקוק לניתוח, בדיקת תצורה או טיפול בערכים שגויים. זה מקטין את מורכבות היישום. (חלק ממורכבות התצורה שנצפתה בדוגמה שלנו היא לא תכונה של התצורה המהודרת, אלא רק החלטה מודעת המונעת מהרצון לספק בטיחות טיפוסית גדולה יותר.) די קל לחזור לתצורה הרגילה - פשוט יישם את החסר חלקים. לכן, אתה יכול, למשל, להתחיל עם תצורה מהודרת, לדחות את היישום של חלקים מיותרים עד למועד שבו זה באמת נחוץ.
8. תצורה מאומתת. מכיוון ששינויי תצורה עוקבים אחר הגורל הרגיל של כל שינוי אחר, הפלט שאנו מקבלים הוא חפץ עם גרסה ייחודית. זה מאפשר לנו, למשל, לחזור לגרסה קודמת של התצורה במידת הצורך. אנחנו יכולים אפילו להשתמש בתצורה מלפני שנה והמערכת תעבוד בדיוק אותו הדבר. תצורה יציבה משפרת את הניבוי והאמינות של מערכת מבוזרת. מכיוון שהתצורה קבועה בשלב ההידור, די קשה לזייף אותה בייצור.
9. מודולריות. המסגרת המוצעת היא מודולרית וניתן לשלב את המודולים בדרכים שונות ליצירת מערכות שונות. בפרט, אתה יכול להגדיר את המערכת לפעול על צומת בודד בהתגלמות אחת, ועל מספר צמתים באחר. ניתן ליצור מספר תצורות עבור מופעי ייצור של המערכת.
10. בדיקה. על ידי החלפת שירותים בודדים באובייקטים מדומים, ניתן לקבל מספר גרסאות של המערכת שנוחות לבדיקה.
11. בדיקת אינטגרציה. קיום תצורה אחת לכל המערכת המבוזרת מאפשרת להפעיל את כל הרכיבים בסביבה מבוקרת כחלק מבדיקות אינטגרציה. קל לחקות, למשל, מצב שבו צמתים מסוימים הופכים נגישים.

חסרונות ומגבלות

תצורה מהודרת שונה מגישות תצורה אחרות וייתכן שלא תתאים ליישומים מסוימים. להלן כמה חסרונות:

1. תצורה סטטית. לפעמים אתה צריך לתקן במהירות את התצורה בייצור, לעקוף את כל מנגנוני ההגנה. עם גישה זו זה יכול להיות קשה יותר. לכל הפחות, עדיין יידרשו קומפילציה ופריסה אוטומטית. זו גם תכונה שימושית של הגישה וגם חיסרון במקרים מסוימים.
2. יצירת תצורה. במקרה שקובץ התצורה נוצר על ידי כלי אוטומטי, ייתכן שיידרשו מאמצים נוספים כדי לשלב את סקריפט ה-build.
3. כלים. נכון לעכשיו, כלי עזר וטכניקות שנועדו לעבוד עם תצורה מבוססים על קבצי טקסט. לא כל כלי השירות/טכניקות כאלה יהיו זמינים בתצורה מהודרת.
4. נדרש שינוי עמדות. מפתחים ו-DevOps רגילים לקבצי טקסט. עצם הרעיון של הידור של תצורה עשוי להיות מעט בלתי צפוי וחריג ולגרום לדחייה.
5. נדרש תהליך פיתוח באיכות גבוהה. על מנת להשתמש בנוחות בתצורת הקומפילציה, יש צורך באוטומציה מלאה של תהליך הבנייה והפריסה של האפליקציה (CI/CD). אחרת זה יהיה די לא נוח.

הבה נתעכב גם על מספר מגבלות של הדוגמה הנחשבת שאינן קשורות לרעיון של תצורה מהודרת:

1. אם נספק מידע תצורה מיותר שאינו בשימוש על ידי הצומת, אז המהדר לא יעזור לנו לזהות את המימוש החסר. ניתן לפתור בעיה זו על ידי נטישת דפוס העוגה ושימוש בסוגים נוקשים יותר, למשל, HList או סוגי נתונים אלגבריים (מחלקות מקרה) לייצג תצורה.
2. ישנן שורות בקובץ התצורה שאינן קשורות לתצורה עצמה: (package, import,הצהרות חפצים; override defעבור פרמטרים שיש להם ערכי ברירת מחדל). זה יכול להימנע חלקית אם אתה מיישם DSL משלך. בנוסף, סוגים אחרים של תצורה (לדוגמה, XML) מטילים גם הגבלות מסוימות על מבנה הקובץ.
3. למטרות פוסט זה, איננו שוקלים הגדרה מחדש דינמית של אשכול של צמתים דומים.

מסקנה

בפוסט זה, בדקנו את הרעיון של ייצוג תצורה בקוד המקור באמצעות היכולות המתקדמות של המערכת מסוג Scala. גישה זו יכולה לשמש ביישומים שונים כתחליף לשיטות תצורה מסורתיות המבוססות על קבצי xml או טקסט. למרות שהדוגמה שלנו מיושמת ב-Scala, ניתן להעביר את אותם רעיונות לשפות קומפילציה אחרות (כגון Kotlin, C#, Swift, ...). אתה יכול לנסות גישה זו באחד מהפרויקטים הבאים, ואם זה לא עובד, לעבור לקובץ הטקסט, להוסיף את החלקים החסרים.

באופן טבעי, תצורה מהודרת דורשת תהליך פיתוח באיכות גבוהה. בתמורה, איכות גבוהה ואמינות של תצורות מובטחת.

ניתן להרחיב את הגישה הנחשבת:

1. אתה יכול להשתמש בפקודות מאקרו כדי לבצע בדיקות זמן קומפילציה.
2. אתה יכול ליישם DSL כדי להציג את התצורה בצורה נגישה למשתמשי הקצה.
3. אתה יכול ליישם ניהול משאבים דינמי עם התאמת תצורה אוטומטית. לדוגמה, שינוי מספר הצמתים באשכול מחייב (1) כל צומת יקבל תצורה מעט שונה; (2) מנהל האשכול קיבל מידע על צמתים חדשים.

תודות

אני רוצה להודות לאנדריי סקסונוב, פאבל פופוב ואנטון נקייב על הביקורת הבונה שלהם על טיוטת המאמר.

מקור: www.habr.com