5 עקרונות השכל הישר לבניית אפליקציות מקוריות בענן

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

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

עקרונות עיצוב תוכנה

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

• KISS (שמור על זה פשוט, טיפש) - אל תסבך את זה;
• DRY (אל תחזור על עצמך) - אל תחזור על עצמך;
• YAGNI (אתה לא תזדקק לזה) - אל תיצור משהו שאין בו צורך מיד;
• SoC הפרדת חששות - חלק באחריות.

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

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

מכולות מקוריות בענן: גישת Red Hat

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

עיקרון דאגה יחידה (SCP)

עיקרון זה דומה במובנים רבים לעקרון האחריות היחידה. SRP), שהוא חלק מהסט SOLID וקובע שלכל אובייקט חייבת להיות אחריות אחת, והאחריות הזו חייבת להיות מובלעת לחלוטין במחלקה. הנקודה של SRP היא שכל אחריות היא סיבה לשינוי, ולכיתה חייבת להיות סיבה אחת ויחידה לשינוי.

ב-SCP, אנו משתמשים במילה "דאגה" במקום המילה "אחריות" כדי לציין את רמת ההפשטה הגבוהה והמטרה הרחבה יותר של מיכל בהשוואה למחלקה של OOP. ואם המטרה של SRP היא שתהיה רק ​​סיבה אחת לשינוי, אז מאחורי SCP עומד הרצון להרחיב את היכולת לעשות שימוש חוזר ולהחליף מכולות. על ידי מעקב אחר ה-SRP ויצירת קונטיינר שפותר בעיה בודדת ועושה אותה בצורה מלאה מבחינה פונקציונלית, אתה מגדיל את הסיכוי לעשות שימוש חוזר בתמונת המכולה בהקשרי אפליקציה שונים.

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

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

עקרון צפיות גבוה (HOP)

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

בפועל, אפליקציה מכוללת צריכה, לכל הפחות, להיות בעלת API לסוגים שונים של בדיקות בריאות: בדיקות חיים ובדיקות מוכנות. אם אפליקציה מתיימרת לעשות יותר, עליה לספק אמצעים אחרים לפיקוח על מצבה. לדוגמה, רישום אירועים חשובים באמצעות STDERR ו-STDOUT לצבירה יומנים באמצעות Fluentd, Logstash וכלים דומים אחרים. כמו גם אינטגרציה עם ספריות איסוף ומדדים, כגון OpenTracing, Prometheus וכו'.

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

עיקרון התאמה למחזור החיים (LCP)

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

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

ברור שאירועים מסוימים חשובים יותר מאחרים. לדוגמה, אם אפליקציה לא סובלת קריסות היטב, עליה לקבל הודעות אות: סיום (SIGTERM) ולהתחיל את שגרת הסיום שלה במהירות האפשרית כדי לתפוס את האות: kill (SIGKILL) שמגיע אחרי SIGTERM.

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

עקרון אי-השינוי בתמונה (IIP)

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

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

עיקרון חד פעמי בתהליך (PDP)

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

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

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

עיקרון הכליאה העצמית (S-CP)

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

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

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

עיקרון זמן ריצה (RCP)

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

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

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

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

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

• נסו להקטין את גודל התמונות: מחק קבצים זמניים ואל תתקין חבילות מיותרות - ככל שגודל הקונטיינר קטן יותר, כך הוא מורכב מהר יותר ומועתק למארח היעד דרך הרשת.
• התמקדו במזהי User-ID שרירותיים: אל תשתמש בפקודה sudo או בכל משתמש מיוחד כדי להפעיל את הקונטיינרים שלך.
• סמן יציאות חשובות: אתה יכול להגדיר מספרי יציאות בזמן ריצה, אבל עדיף לציין אותם באמצעות הפקודה EXPOSE - זה יקל על אנשים ותוכנות אחרים להשתמש בתמונות שלך.
• אחסן נתונים קבועים על אמצעי אחסון: יש לכתוב את הנתונים שאמורים להישאר לאחר השמדת המכולה.
• כתוב מטא נתונים של תמונה: תגיות, תוויות והערות הופכות תמונות לקלות יותר לשימוש - מפתחים אחרים יודו לך.
• סנכרון מארח ותמונות: יישומים מסויימים עם מיכל דורשים שהמכולה יסנכרן עם המארח על תכונות מסוימות, כגון זמן או מזהה מחשב.
• לסיכום, אנו חולקים תבניות ושיטות עבודה מומלצות שיעזרו לך ליישם בצורה יעילה יותר את העקרונות המפורטים לעיל:
  www.slideshare.net/luebken/container-patterns
  docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices
  docs.projectatomic.io/container-best-practices
  docs.openshift.com/enterprise/3.0/creating_images/guidelines.html
  www.usenix.org/system/files/conference/hotcloud16/hotcloud16_burns.pdf
  leanpub.com/k8spatterns
  12factor.net

סמינר מקוון על הגרסה החדשה של OpenShift Container Platform - 4
11 ביוני בשעה 11.00

מה תלמדו:

• Red Hat Enterprise Linux CoreOS בלתי ניתן לשינוי
• רשת שירות OpenShift
• מסגרת מפעיל
• מסגרת קנאטיבית

מקור: www.habr.com