הכרות עם Docker Swarm
פרקי ההרצאה: הכרות עם Docker Swarm
תמלול ההרצאה: הכרות עם Docker Swarm
הטקסט המלא של הדקות הראשונות בהרצאה «הכרות עם Docker Swarm» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום לכולם, אנחנו רוצים להתחיל בהרצאות שקשורות לקלאסטר, לקבוצת מחשבים שעובדת כיחידה אחת, ואם שרת אחד נופל ועליו קונטיינרים שעובדים, אז שרת אחר ישר תופסת מיקומו ושום דבר לא נפגע, אולי לכמה שניות הלקוח מרגיש איזשהו דיליי, אבל לא יותר מזה, שהכל עובד במקביל ושום דבר לא נופל,
שלא תהיה נקודת כשל בודדת. זאת אומרת שאם משהו אחד נופל, יש נקודת כשל כלשהי ומשהו נפל, אז המערכת כולה ממשיכה לעבוד. זה נקרא אפס נקודות כשל.
אז אנחנו רוצים קלאסטר. זה נקרא SwarmMode או קוברנטיס, יש גם קוברנטיס וגם Swarm. זה למעשה שתי טכנולוגיות, שתי שיטות שמתחרות על השירות הזה של קלאסטר.
עכשיו, כש-Swarm, Swarm זה הקלאסטר המובנה בתוך דוקר. אתם רואים current version of docker הגרסה הנוכחית של docker includes כבר כוללת בפנים מצב של swarm שזה מצב של קלאסטר ששני מחשבים יודעים לדבר אחד עם השני ואם אחד נופל השני קם במקומו.
בשביל לעשות native זה אומר בצורה טבעית המובנית בדוקר management cluster זאת אומרת הם מנהלים קלאסטר בצורה מובנית בתוך דוקר זה נקרא swarm ומה הוא יודע לעשות?
קודם כל קלאסטר מנג'מנט אינטגרייטד מובנה בתוך דוקר אנג'ן זאת אומרת בתוך הדוקר כבר מובנה ניהול של הקלאסטר לא צריך להתקין שום דבר כמו בו קוברנטי שצריך להוסיף שמה דברים ולבנות אותם דיסנטרליסט דיזיין זה אומר שאין משהו אחד מרכזי שאם הוא נופל הכל נופל שימו לב יש גם מושג שנקרא מנג'רס אנד וורקרס יש שרתים שמנהלים את הקלאסטר הם נקראים מנג'רס הם אומרים תריץ שם את הקונטיינר הזה תריץ פה עוד משהו.
זאת אומרת, המנהלים, והם מדברים ביניהם, ויש וורקרס, וורקרס רק מקבלים הוראות, לא יודעים מה קורה בקלאסטר, הם רק מקבלים הוראות להפעיל משהו, לכבות משהו.
עכשיו, הוורקרס האלו, הם למעשה מריצים את הדברים הכבדים, נניח, אתר וורדפרס, והם לא מפטפטים כמו המנהלים מפטפטים ביניהם ויוצרים המון תקשורת שהיא לא רלוונטית לשירות.
זאת אומרת, מנאג'רס זה שרתים שמדברים ביניהם מי יעשה איזה עבודה וכל הזמן יש ביניהם שיחות ופטפוטים על הניהול של הקלאסטר הם יכולים להריץ קונטיינרים אין שום בעיה אבל חוץ מלהריץ קונטיינרים הם גם מנהלים את כל ההתנהלות של הקלאסטר וורקרס רק מריצים קונטיינרים מקבלים הוראה להריץ מריצים לא יודעים מה קורה
שם עם האחרים אז הם פחות מפטפטים אפשר כמובן כל מחשב להפוך למנאג'ר לוורקר להוריד וורקר להעלות וורקר מוורקר למנאג'ר להוריד מנאג'ר למנאג'ר לוורקר כמובן שהמנאג'ר זה המוח של הקלאסטר והוורקר זה המבצע כאשר גם מנאג'ר יכול להריץ קונטיינרים שלא תחשבו שהוא רק מנהל את הקלאסטר וזהו כמובן שאם אין אף מנאג'ר זמין אז כל הקלאסטר
לא יתפקד כמו שצריך הלאה declarative service model זה אומר שאנחנו רושמים בצורה דקלרטיבית מה אנחנו רוצים כמו שעשינו את קבצי הyaml אנחנו נעשה את זה איתכם ביחד זאת אומרת בתוך קובץ yaml אנחנו כותבים desire state לאיזה מצב אנחנו רוצים להגיע והסרוויס של הקלאסטר מביא את זה למצב שאנחנו רוצים שימו לב המצב הרצוי אנחנו
מתארים את הסרוויס ובתוך סרוויס יש קונטיינרים שרצים סרוויס אנחנו נדבר יש פה מושגים יש פה הרבה מושגים קטנים כאלו שמבלבלים אוקיי סקיילינג מה זה אומר זאת אומרת, סקיילינג זה אומר שאנחנו יכולים להריץ לא רק וורדפרס כשרת ווב אחד, אנחנו יכולים להריץ כמה וורדפרסים.
זאת אומרת, יהיה לנו כמה וורקרים או וורקר ומנאג'ר שמריצים אתרי אינטרנט של וורדפרס, ולוקחים על עצמם את כל העומס, וזה לא חייב להיות אחד, זה יכול להיות שתיים, שלוש, חמש, עשרים, כמה שאנחנו רוצים קונטיינרים, זה למעשה כמה קונטיינרים מטפלים בבקשות של הלקוח.
ואז אם יש לי יותר לקוחות, אני יכול להקפיץ מאותו השירות עוד קונטיינרים. הוא יכול לעשות סקייל אפ, לגדול, לקטון, מה שאנחנו רוצים לעשות.
המנאג'רים למעשה אוטומטיקלי יודעים לעשות התאמה. אני אומר, אני רוצה שלושה שרתי וב. הם רואים מה המצב בקלאסטור, רואים שמישהו נפל, אומרים, הופה, אתה תרים עוד קונטיינר כי אני צריך שלושה ויש לי רק שניים באוויר.
אז למעשה Swarm יודע לעשות אדפטציה למצב החדש באופן אוטומטי. Removing Task, מה זה Task? זה משימה שנותנים לו להרים קונטיינר, אוקיי?
אז יש פה כל מיני מושגים, הם הכניסו בכל ה-Swarm, בכל הקלאסטר, כביכול במקום קונטיינר הם קוראים לזה Task, אוקיי?
זה מה שנקרא Desire Statric Consolation, זה אומר שהוא מפעיל את עצמו, כמה שאני אגיד. Swarm Manager, המנאג'ר של ה... זוכרים אמרנו שיש תפקיד מנאג'ר לו?
כל הזמן עושה מוניטורינג של הקלאסטר סטייט, של מצב הקלאסטר, ואם משהו חסר הוא עושה ריקונסייל, כאילו מדביק את הפערים, את הפערים בין המצב בפועל, נניח מישהו נפל, מישהו קם, ואת המצב הרצוי שתיארנו לו בקובץ יאמל.
שימו לב, בקובץ יאמל אנחנו יכולים להגיד לו שאנחנו רוצים עבור סרוויס מסוים, עבור שירות מסוים, נניח אתר וורדפרס, 10 רפליקות, 10 קונטיינרים, אנחנו רוצים 10 קונטיינרים באוויר כי יש לי 2,000 מי שנכנסים ואני רוצה ככה לבדוק שיש לי 10 קונטיינרים באוויר כל הזמן.
אם חסר קונטיינר, המנאג'ר אומר למישהו תרים את הקונטיינר. אז זה נקרא רפליקס והוורקר משין שעושה קראש נופל, נניח וורקר משין שיש בו 2 עושה קראש, נופל.
מנאג'רס אומרים ליצור 2 חדשים במקומו, אוקיי? יש שני קונטיינרים חדשים, הבנתם? The Swarm Manager assigns new replicas, מדביק את הפערים לזה.
הלאה, מה עוד יש? או, זה משהו מגניב. יש Network רשת, נכון, כמו רשת סגורה, אבל שהיא עוברת כמו VPN בין ה-nodes של הקלאסטר.
זאת אומרת, בין המחשבים הפיזיים שמריצים את הקלאסטר, יש רשת שעוברת כמו VPN, הם חושבים שזו רשת אחת שהיא מסוג Overlay, זה נקרא דרייבר שלה, נקרא Overlay, ולמעשה כל המחשבים שמחוברים לרשת הזאת יכולים לעשות ביניהם פינג.
כאילו יש לי סוויץ' פרטי ביניהם, כאילו פיזי, בפועל זה נראה ממש כמו VPN. אז עוד פעם, יש לי כמה שרתים פיזיים שיש להם רשת וירטואלית שלא באמת קיימת, והיא אותה רשת בין כל המחשבים וכולם יכולים לעשות ביניהם פינגים.
כל האוסטים יודעים לעשות ביניהם פינגים. מי שמכיר VPN יודע שאתה בבית מקבל IP של המחשב בעבודה, וכאילו אתה יושב שם ברשת, אתה יכול לעשות פינגים להתחבר לכל השירותים.
אז אותו דבר פה, הם לקחו את הרעיון של כביכול VPN והכניסו אותו בין הנודים, בין המחשבים בקלאסטר. וזה מצוין. למה זה מצוין? כי אני לא צריך לחשוף פורטים החוצה ברשת הפיזית.
זאת אומרת, אני יכול לעשות כמה רשתות אוברלי שונות, וכל המחשבים שם מדברים עם כל המחשבים בתוך הרשת הזאת, כאילו יש להם רשת פרטית, אבל היא לא מוגבלת למחשב אחד.
הבנתם? שהרשת הפרטית בין המכונות, בין הקונטיינרים, לא מוגבלת לאותו מחשב פיזי. זה יכול להיות על כל המחשבים שיש לי בקלאסטר.
אם לא היה לי את זה, הייתי צריך בשביל לעשות תקשורת בין קונטיינר במחשב פיזי אחד לקונטיינר במחשב פיזי אחר,