תצורה ניתנת לקומפילציה של מערכת מבוזרת

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

(на русском)

מבוא

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

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

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

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

sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage]

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

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

sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage]

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

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

אנו יכולים להכריז על תלות בתצורה של לקוח שירות הד:

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

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

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

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

  type ResourceReader[F[_], Config, A] = Reader[Config, Resource[F, A]]

  trait ServiceImpl[F[_]] {
    type Config
    def resource(
      implicit
      resolver: AddressResolver[F],
      timer: Timer[F],
      contextShift: ContextShift[F],
      ec: ExecutionContext,
      applicative: Applicative[F]
    ): ResourceReader[F, Config, Unit]
  }

איפה

• 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 סוּג. כמו כן, לא נוכל להפעיל את הצומת מבלי לספק תצורה מלאה.

רזולוציית כתובת הצומת

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

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

ישנן כמה דרכים אפשריות ליישם פונקציה כזו.

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

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

יישום שני צמתים

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

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

תהליך פיתוח כולל

בואו נראה כיצד גישה זו משנה את הדרך בה אנו עובדים עם תצורה.

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

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

כרטיס -> יחסי ציבור -> סקירה -> מיזוג -> אינטגרציה מתמשכת -> פריסה מתמשכת

ישנן ההשלכות הבאות של הגישה:

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

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

וריאציות

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

קודם כל, נפרט כמה חלופות להיבטים השונים של הדרך המוצעת להתמודד עם תצורה:

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

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

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

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

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

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

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

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

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

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

יתרונות

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

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

חסרונות

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

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

יש כמה מגבלות של הדוגמה המיושמת:

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

סיכום

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

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

ניתן להרחיב גישה זו בדרכים שונות:

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

תודה

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

מקור: www.habr.com