משתתף מגיע לקורס או לקורס אינטנסיבי. הוא רואה שורות מסודרות של תמיכה טכנית, כבלי חשמל מסודרים, דוגמת לוח שחמט של אולם ההרצאות, תמונות בהירות ודיאגרמות שקופיות. דוברים עם בדיחות וחיוכים מחלקים מידע כך שיהיה לך זמן רק להבין. היציעים מוצבים, המשימות המעשיות פשוט עפות לך בין האצבעות, אלא שלפעמים אתה זקוק לעזרה מתמיכה טכנית.
וגם הפסקות קפה עם אנשים בעלי דעות דומות, אווירה עליזה ואנרגטית, חילופי חוויות, השאלות הכי לא צפויות לדוברים. ותשובות, ומידע שלא תמצאו במדריכים, אלא רק בפועל.
כמה זמן, מאמץ ועצבים לדעתך נדרשו כדי שזה ייראה בדיוק ככה?
תודה לוולודיה גוריאנוב, מנהל Kubernetes מוסמך ומהנדס/ראש צוות בסאות'ברידג', שהיה עד ושותף פעיל ביצירתם של קורסי Slurm רבים מההתחלה.
הוא ראה את הצד הפנימי של יצירת קורסים - הקשיים והמכשולים, התובנות והפתרונות הבלתי צפויים. ואת הקורסים האינטנסיביים המוכרים כבר על Kubernetes, כמו Slurm Basic ו-Slurm Mega. ואת הקורס החדש, שעוצב מחדש ברובו. , אשר מתקרב בהתמדה ויתחיל ב-19 באוגוסט.
אבל, אולי, מספיק עם המילים, בואו נעבור לסיפור עצמו. כיצד כמה נושאים אינטנסיביים התפתחו בהדרגה לסיפור עצמאי ורב-גוני לחלוטין. אז אני אתחיל את הסיפור על איך נוצרים ומפותחים קורסים - בדיוק כמו "לפני זמן רב בגלקסיה רחוקה, רחוקה..."
מה קורה מאחורי הקלעים?
אם תשאלו איך אנחנו עושים קורסים ומהיכן הכל מתחיל, אענה בפשטות, "הכל מתחיל ברעיון".
בדרך כלל, רעיון מגיע מאיפשהו - אנחנו לא יושבים אזוקים במרתף עד שאנחנו מעלים את השאלה: "על איזה נושא כדאי לעשות קורס?". רעיונות מגיעים מאיפשהו מבחוץ. לפעמים אנשים מתחילים לשאול באופן פעיל: "מה אתה יודע על טכנולוגיה ספציפית כזו וכזו?" או כמו עם Docker, היה בלתי אפשרי להתאים את זה לזמן של הקורס האינטנסיבי - ברור שהיה צריך להוציא את זה החוצה כדי שיהיה לנו זמן לספר משהו במסגרת הקורס.
כך רעיון נוצר.
אחרי שהיא הכריזה על עצמה, מתחיל הרגע הכי קשה, לדעתי - להבין מה לכלול בקורס הזה - זה מאוד דומה לאופן שבו דוברים מתכוננים לכל מיני כנסים.
יש נקודת כאב עיקרית אחת, כשנראה שבחרת נושא וחושב: "מה אני צריך לספר עליו? זה פשוט מדי, זה ברור מאליו, כולם יודעים את זה גם."
אבל למעשה, זה בכלל לא נכון. ואני אישית אומר במקומות רבים שמה שנראה לכם מובן מאליו, לאלה שבאים להקשיב לכם או לקחת את הקורס, כלל לא מובן מאליו. וכאן עולה שכבה כל כך גדולה של עבודה וקונפליקט פנימי, ומה לכלול בקורס. כתוצאה מכך, מתקבלת רשימה כזו של פרקים במשיכות גדולות גורפות כל כך, על מה הקורס יעסוק.
ואז מתחילה העבודה השגרתית הפשוטה:
- בחירת חומר
- קרא בעיון את התיעוד של הגרסה הנוכחית, מכיוון שעולם ה-IT מתפתח כעת במהירויות קוסמיות מסוימות. גם אם אתה עובד עם משהו ומכין קורס בנושא, אתה צריך לגשת לתיעוד ולראות מה חדש, מה מעניין לדבר עליו, מה יכול להיות שימושי במיוחד להזכיר.
- ומופיע שלד מסוים של הקורס, שבו רוב הנושאים כבר, באופן כללי, מתוארים ונראה שיש שם משהו - להקליט סרטונים ולהשיק אותם להפקה.
- אבל למעשה, לא, אז מתחילה העבודה הקשה, אבל לא עבור מחברי הקורסים, אלא עבור אלו שבודקים. בדרך כלל, בודקי האלפא שלנו הם אנשי התמיכה הטכנית, שראשית, עורכים הגהה לקורסים על כל מיני שגיאות תחביריות ודקדוקיות. שנית, הם מכים אותנו במקלות ומקללים אותנו כשיש כמה מקומות לא ברורים מאליהם ולא מובנים. כשמופיעים בטקסטים כמה משפטים משניים מורכבים לאורך כמה עמודים או שטויות ברורות. הם עורכים הגהה לכל זה, שימו לב לזה.
- אז מתחיל שלב תרגול הבדיקות, שבו נתפסים גם כמה דברים ברורים שאינם עובדים ומוצגים כמה רגעים שיכולים להיות מסובכים, או להיפך, כי זה הופך להיות לא ממש מעניין - סתם לשבת ולהעתיק - ונחשפים מקומות שבהם זה מאוד קשה ואנחנו רוצים הרבה מאנשים שייקחו את הקורס הזה. ואז מגיעות המלצות: "חבר'ה, תעשו את זה פשוט יותר כאן, זה יהיה קל יותר לתפוס ותהיה יותר תועלת מזה."
- אחרי שכמות העבודה הזו נעשתה, החלק שקשור לסרטון נכתב, הכל נראה בסדר. וכבר אפשר לתת את זה לשחרור, לפרסום הקורס הזה. אבל שוב, לא, זה מוקדם מדי - מאז לאחרונה הפסקנו לסמוך קצת על עצמנו, ובאופן עקרוני, התחלנו לעבוד יותר עם משוב. יש דבר כזה שנקרא בדיקות בטא - זה כאשר אנשים שנמצאים לגמרי מחוץ לחברה שלנו, לא קשורים לחברה שלנו בשום צורה, מוזמנים ותמורת הטבות מסוימות מוצגים להם כל חלקי הקורס, וידאו, טקסט, משימות מעשיות, כדי שיוכלו להעריך את איכות החומר, את נגישות החומר ולעזור לנו להפוך את הקורס לטוב ככל האפשר.
- וכאשר מתרחשות מספר איטרציות כאלה, דוברים, בדיקות אלפא בצורה של תמיכה טכנית, בדיקות בטא, שיפורים. ואז הכל מתחיל מחדש - תמיכה טכנית, בדיקות בטא, שיפורים.
- ובשלב מסוים, מגיעה ההבנה שאו שנפסיק לעשות שיפורים, כי זה לגמרי לא מציאותי לגרום לזה להיות ככה שכולם יאהבו את זה, או שמתקבלות כמה החלטות קרדינליות. כאשר הרבה הערות על מקומות ספציפיים הן קריטיות - צריך לעשות אותן מחדש באופן גלובלי, כי משהו השתבש.
- ואז מגיע הזמן לעריכות קלות - איפשהו משפט לא מנוסח יפה, איפשהו מישהו לא אוהב את הגופן, 14,5, אבל הייתי רוצה 15,7.
- כאשר תגובות מסוג זה נשארות, אז זהו, הקורס פחות או יותר נפתח, והמכירות הרשמיות מתחילות.
ובמבט ראשון, המשימה הקצרה והפשוטה של הכנת קורס מתגלה כלא פשוטה כלל ולוקחת זמן רב להפליא.
ויש עוד נקודה חשובה, שהעבודה עם הקורס לא מסתיימת כשהקורס יוצא לאור. ראשית, אנו קוראים בעיון את ההערות שנותרות על חלקים מסוימים. ולמרות כל המאמצים שעשינו, עדיין מתגלים כמה פגמים, כמה תקלות, אשר מתוקנות בזמן אמת, מעודנות, כך שכל משתמש נוסף יקבל שירות איכותי יותר.
לכל קורס יש בעל מוצר משלו, אשר בנוסף להגדרת הקונספט הכללי, בדיקת דד-ליינים, רושם הערות בשוליים שכאשר יגיע הזמן לכתוב מחדש את הקורס לחלוטין, וזה בהחלט יגיע, כי בעוד שנתיים, או אפילו שנה, חלק ממה שנספר יהפוך ללא רלוונטי פשוט כי הוא יתיישן מבחינה מוסרית. בעל המוצר רושם הערות בשוליים שרוב הזמן אנשים שואלים אילו רגעים היו לא ברורים, אילו משימות נראו קשות מאוד, ואילו, להיפך, נראו פשוטות מאוד. וכל זה נלקח בחשבון בעת הקלטה מחדש של הקורס, במהלך עיבוד מחדש כלשהו, כך שכל איטרציה של הקורס הגלובלי הופכת טובה יותר, נוחה ונוחה יותר.
כך נראים קורסים.
איך נולד קורס הדוקר
זהו נושא נפרד ואף יוצא דופן עבורנו. כי מצד אחד, לא תכננו לעשות זאת, מכיוון שבתי ספר מקוונים רבים מציעים זאת. אבל מצד שני, זה ביקש שחרור ומצא מקום הגיוני בקונספט שלנו של הכשרת מומחה IT ב-Kubernetes.
אם נדבר בצורה גלובלית מאוד, אז בהתחלה הכל התחיל עם קורס קוברנטס, כשהוא הושק, אני חושב, אחרי ה-Slurm הראשון. אספנו משוב וראינו שהרבה אנשים רצו לקרוא משהו אחר על Docker במקום אחר ובכלל הרבה אנשים מגיעים לקורס קוברנטס הבסיסי בלי לדעת מהו. .
זו הסיבה שיצרנו קורס לקורס השני של הסלרם - או ליתר דיוק, אפילו לא קורס, אלא כמה פרקים על דוקר. שם סיפרנו כמה דברים בסיסיים מאוד כדי שאנשים שמגיעים לקורס האינטנסיבי לא ירגישו מקופחים ובאופן כללי יבינו מה קורה.
ואז האירועים התפתחו, בערך, כך. כמות החומר גדלה ולא נכנסה עוד ל-3 ימים. וצץ רעיון הגיוני וברור: למה לא ליצור איזשהו קורס קטן ממה שאנחנו מדברים עליו ב-Slurm Basic, שאליו נוכל לשלוח אנשים שרוצים לראות משהו על Docker לפני הקורס האינטנסיבי על Kubernetes.
Slurm Junior הוא, למעשה, שילוב של כמה קורסים בסיסיים כאלה. כתוצאה מכך, הקורס על Docker הפך לחלק מ-Slurm Junior. כלומר, זהו צעד אפס לפני... и ואז היו כמה הפשטות בסיסיות מאוד.
בשלב מסוים, אנשים התחילו לשאול: "חבר'ה, כל זה נהדר, זה מספיק כדי להבין על מה אתם מדברים בסמינרים האינטנסיביים. איפה אני יכול לקרוא עוד על מה דוקר יכול לעשות ואיך לעבוד איתו, ומה זה?" כך עלה הרעיון להפוך אותו ל... , כך שראשית, יהיה ניתן לשלוח אליו אנשים שמגיעים ל-Slurm על Kubernetes, ומצד שני, עבור אלו שאינם מעוניינים כלל ב-Kubernetes בשלב זה של הפיתוח. כך שמומחה IT יוכל לבוא ולצפות בקורס שלנו על Docker ולהתחיל את דרכו האבולוציונית פשוט עם Docker טהור. כדי שנוכל לקבל קורס מלא ומלא כל כך - ורבים לאחר מכן, לאחר שצפו בקורס הזה, לאחר שעבדו זמן מה עם Docker טהור, הגיעו לרמה שבה הם כבר צריכים את Kubernetes או מערכת תזמור אחרת. והם פנו אלינו במיוחד.
לפעמים אנשים שואלים: "איזה סוג של אנשים אולי לא יצטרכו את Kubernetes עכשיו?" אבל השאלה הזו אינה על אנשים, אלא על חברות. כאן צריך להבין של-Kubernetes יש מקרים מסוימים שבהם היא מתאימה היטב ומשימות שהיא פותרת היטב, ולהיפך, ישנם תרחישים מסוימים של שימוש בקוברנטס שבהם הוא גורם לכאב נוסף וסבל נוסף. לכן, זה אפילו לא תלוי באנשים, אלא במה וכמה זמן חברות מתפתחות.
לדוגמה, איזה מונולית Legacy נוראי - כנראה שלא כדאי להכניס לתוך Kubernetes, כי זה יגרום ליותר בעיות מתועלת. או, למשל, אם זה פרויקט קטן - יש לו עומסים קטנים או, באופן עקרוני, לא הרבה כסף ומשאבים. אז אין טעם לגרור אותו לתוך Kubernetes.
ובכלל, כנראה, בכלל, כמו שכבר אמרו רבים, אם אתם שואלים את עצמכם את השאלה: "האם אני צריך את קוברנטס?", אז סביר להניח שאתם לא צריכים את זה. אני לא זוכר מי הגה את זה ראשון, אני חושב שזה היה פאשה סליבנוב. אני מסכים עם זה ב-100%. ואתם צריכים להתבגר לקוברנטס - וכשאתם כבר מבינים שאני צריך את קוברנטס והחברה שלנו צריכה את זה, זה יעזור לפתור בעיות כאלה ואחרות, אז, כנראה, הגיוני ללכת ללמוד ולהבין איך ספציפית להגדיר את זה טוב, כדי שתהליך המעבר לקוברנטס לא יהיה כואב במיוחד.
חלק ממחלות הילדות וחלק דברים פשוטים באמת ואפילו דברים לא כל כך פשוטים, תוכלו לגלות במיוחד אצלנו, ולא לעבור את הסבל והכאב של עצמכם.
חברות רבות עברו בהתחלה דרך של תשתית פשוטה ללא קונטיינריזציה. לאחר מכן הן הגיעו לנקודה שבה היה קשה לנהל את כל זה, הן עברו ל-Docker ובשלב מסוים הן התפתחו לנקודה שבה Docker ומה שהוא מציע הפך צפוף. והן התחילו לבחון מה קיים, אילו מערכות פותרות את הבעיות הללו, ובפרט Kubernetes היא אחת מאותן מערכות שמאפשרות לפתור בעיות כאשר Docker טהור הופך צפוף וחסר פונקציונליות, זהו מקרה ממש טוב שבו אנשים הולכים מלמטה למעלה צעד אחר צעד, מבינים שהטכנולוגיה הזו לא מספיקה ועוברים לשלב הבא. הם השתמשו במשהו, זה הפך שוב ללא מספיק - והם ממשיכים הלאה.
זו בחירה מודעת - וזה דבר ממש מגניב.
באופן כללי, אני רואה שהמערכת שלנו נבנית בצורה יפה מאוד, למשל, , אפילו מקורסי וידאו. ואז אחרי docker מגיע , אם כך , אם כך הכל בנוי בצורה הגיונית - אדם עובר את זה ומתקבל מקצוע שלם.
באופן עקרוני, מערך הקורסים מאפשר לנו לסגור הרבה תיקים, ממש מודרניים. עדיין יש תחומים שנותרו כתמים אפורים, אני מקווה שבקרוב ניצור כמה קורסים שיאפשרו לנו לסגור את התחומים האפורים האלה, ובפרט, נגיע למשהו בנושא אבטחה. כי זה הופך להיות מאוד רלוונטי.
בקיצור, יש לנו כמה אזורים אפורים שיהיה נחמד מאוד לסגור, כדי שתהיה תמונה שלמה, שלמה - ואנשים יוכלו לבוא, וכמו שקוברנטס עצמו הוא בנאי לגו, אפשר להרכיב ממנו דברים שונים, אם עדיין אין מספיק - להוסיף, בדיוק כמו עם הקורסים שלנו, כדי שאנשים יוכלו להבין מה הם צריכים מזה, להרכיב מעין פאזל, מעין בנאי מהקורסים שלנו.
אם תשאלו את עצמכם את השאלה הנכונה והכנה: "מי ירוויח מקורס Docker פעיל עכשיו?", אז:
- לתלמידים שרק מתחילים להיכנס לקצב.
- לצוות מחלקת הבדיקות.
- למעשה, ישנן חברות רבות שעדיין, לא רק שלא משתמשות ב-Docker, אלא שאף אחד לא שמע על טכנולוגיה כזו, ובאופן עקרוני, לא יודע איך להשתמש בה. ואני מכיר כמה חברות גדולות בסנט פטרסבורג שפיתחו במשך שנים רבות, והן השתמשו בטכנולוגיות ישנות, והן נעות בכיוון הזה. בפרט, עבור חברות כאלה, עבור מהנדסים בחברות כאלה, קורס זה יכול להיות מעניין מאוד, שכן, ראשית, הוא יאפשר לכם להתעמק במהירות בטכנולוגיה הזו, ושנית, ברגע שיופיעו כמה מהנדסים שמבינים איך הכל עובד, הם יכולים להביא את זה לחברה ולפתח את התרבות הזו ואת הכיוונים האלה בתוך החברה.
- לדעתי, הקורס הזה עדיין יכול להיות שימושי למי שכבר עבד עם Docker, אבל מעט מאוד ויותר בסגנון של "עשה את זה פעם אחת, תעשה את זה פעמיים" - ועכשיו הם הולכים איכשהו לתקשר עם אותם Kubernetes, וזה מטיל עליהם חובות מסוימות, אם יש ידע שטחי מאוד מה זה Docker, איך להפעיל אותו, אבל באותו הזמן אתה לא יודע איך הוא עובד מבפנים, אתה לא יודע מה עדיף לעשות איתו, ומה עדיף לא לעשות, אז הקורס הזה מתאים היטב לסיסטמטיזציה והעמקת ידע.
אבל אם הידע שלכם הוא ברמה של: "אני לא יודע איך לכתוב את אותם קבצי docker בצורה נכונה, אני יכול לדמיין מהם מרחבי שמות, איך עובדים קונטיינרים, איך הם מיושמים בפועל ברמת מערכת ההפעלה" - אז בהחלט אין טעם לבוא אלינו, לא תלמדו שום דבר חדש ותהיו קצת עצובים מהכסף והזמן שהושקעו.
אם ננסח את היתרונות של הקורס שלנו, אז:
- ניסינו לבנות קורס זה עם מספר מספיק של מקרים מעשיים שיאפשרו לכם לא רק להבין את החלק התיאורטי שקיים, אלא גם להבין מדוע אתם זקוקים לו וכיצד תשתמשו בו בעתיד;
- ישנם כמה חלקים שהם נדירים מאוד - ובכל מקרה אין עליהם הרבה חומר. הם מתייחסים לאינטראקציה של Docker עם מערכת ההפעלה, אפילו בצורה מעט שונה. אילו מנגנונים Docker שאלה ממערכת ההפעלה כדי ליישם מערכת קונטיינריזציה? זה מספק הבנה עמוקה יותר של כל נושא הפעלת קונטיינרים בתוך מערכת ההפעלה. Linuxאיך זה עובד, איך זה מתקשר אחד עם השני בתוך מערכת ההפעלה, מחוצה לה וכן הלאה.
זוהי מבט כל כך מעמיק שזה קורה לעתים רחוקות למדי, ובו בזמן, לדעתי, זה מאוד חשוב. אם אתם רוצים להבין כל טכנולוגיה היטב ולהבין למה לצפות ממנה, אתם צריכים לפחות שיהיה לכם מושג כללי על איך היא עובדת ברמה נמוכה.
הקורס שלנו מדגים ומסביר כיצד זה עובד מנקודת מבט של מערכת הפעלה. מצד אחד, כל מערכות הקונטיינריזציה משתמשות באותם מנגנוני מערכת הפעלה. מצד שני, הן ממנפות את מה שכבר קיים במערכת ההפעלה. Linux, כמו Docker. מערכות קונטיינריזציה אחרות לא המציאו שום דבר חדש - הן לקחו את מה שכבר היה קיים. Linux ופשוט כתבנו מעטפת נוחה המאפשרת לך להפעיל, להפעיל או לקיים אינטראקציה עם המערכת במהירות. Docker, לדוגמה, הוא שכבה קטנה בין מערכת ההפעלה לשורת הפקודה; זהו כלי עזר המאפשר לך ליצור קונטיינר מבלי לכתוב המון פקודות או קוד C, ובמקום זאת פשוט להקליד כמה שורות בטרמינל.
ובנוסף, אם אנחנו מדברים ספציפית על Docker, מה ש-Docker באמת הביא לעולם ה-IT זה סטנדרטים. איך יש להפעיל אפליקציה, איך היא צריכה לעבוד, מהן הדרישות ללוגים, מהן הדרישות להרחבה, וקביעת תצורה של האפליקציה עצמה.
במובנים רבים, docker עוסק בסטנדרטים.
גם תקנים עוברים לקוברנטס - ויש שם בדיוק את אותם תקנים, אם אתם יודעים איך להריץ את האפליקציה שלכם היטב ב-Docker, אז ב-99% מהמקרים זה יעבוד באותה מידה גם בתוך קוברנטס.
אם התעניינתם לא רק באופן שבו נוצר קורס Docker, כמו גם קורסים אחרים, אלא גם בקורס עצמו מנקודת מבט מעשית, אז...
נשמח לראותך!
מקור: www.habr.com
