מבוא לספינקר

1. סקירה כללית

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

המערכת בנויה על גבי Spring Boot ותומכת בספקי ענן רבים.

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

2. רקע

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

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

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

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

3. ספינקר

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

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

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

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

4. רכיבים

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

4.1. פריסות ענן מסורתיות

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

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

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

4.2. שכבת הפשטה

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

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

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

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

4.3. אספקה ​​רציפה

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

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

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

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

5. מודל הענן של נטפליקס

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

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

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

6. אסטרטגיית פריסה

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

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

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

7. למה ספינקר

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

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

8. מסקנה

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

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