Docker Swarm, Kubernetes ו-Mesos הן מסגרות התזמור הפופולריות ביותר. בהרצאתו, ארון גופטה משווה את ההיבטים הבאים של Docker, Swarm ו-Kubernetes:
- פיתוח מקומי.
- פונקציות פריסה.
- יישומי ריבוי מכולות.
- גילוי שירות.
- קנה מידה של השירות.
- משימות הרצה פעם אחת.
- אינטגרציה עם Maven.
- עדכון "מתגלגל".
- יצירת אשכול מסד נתונים של Couchbase.
כתוצאה מכך, תקבל הבנה ברורה של מה יש לכל כלי תזמור להציע ותלמד כיצד להשתמש בפלטפורמות הללו ביעילות.
ארון גופטה הוא הטכנולוג הראשי למוצרי קוד פתוח בשירותי האינטרנט של אמזון, אשר מפתח את קהילות המפתחים Sun, Oracle, Red Hat ו-Couchbase כבר למעלה מ-10 שנים. בעל ניסיון רב בעבודה בהובלת צוותים צולבים בפיתוח ויישום אסטרטגיה לקמפיינים ותכניות שיווקיות. הוא הוביל צוותים של מהנדסי Sun, הוא אחד ממייסדי צוות Java EE והיוצר של הסניף האמריקאי של Devoxx4Kids. ארון גופטה הוא המחבר של יותר מ-2 פוסטים בבלוגי IT ונשא הרצאות ביותר מ-40 מדינות.
שורה 55 מכילה COUCHBASE_URI המצביע על שירות מסד נתונים זה, שנוצר גם הוא באמצעות קובץ התצורה של Kubernetes. אם אתה מסתכל על שורה 2, אתה יכול לראות סוג: שירות הוא השירות שאני יוצר בשם couchbase-service, ואותו שם מופיע בשורה 4. להלן כמה יציאות.
שורות המפתח הן 6 ו-7. בשירות אני אומר, "היי, אלו התוויות שאני מחפש!", והתוויות האלה הן לא יותר משמות זוגות משתנים, ושורה 7 מצביעה על couchbase-rs-pod שלי יישום. להלן היציאות המספקות גישה לאותן תוויות.
בשורה 19 אני יוצר סוג חדש של ReplicaSet, שורה 31 מכילה את שם התמונה, ושורות 24-27 מצביעות על המטא-נתונים המשויכים לתרמיל שלי. זה בדיוק מה שהשירות מחפש ולמה צריך לעשות את החיבור. בסוף הקובץ יש איזשהו קשר בין שורות 55-56 ו-4, האומר: "השתמש בשירות הזה!"
אז, אני מתחיל את השירות שלי כשיש ערכת העתק, ומכיוון שלכל סט העתק יש יציאה משלו עם התווית המתאימה, הוא כלול בשירות. מנקודת מבטו של מפתח, אתה פשוט מתקשר לשירות, אשר לאחר מכן משתמש בערכת ההעתקים שאתה צריך.
כתוצאה מכך, יש לי פוד של WildFly שמתקשר עם ה-backend של מסד הנתונים באמצעות Couchbase Service. אני יכול להשתמש ב-frontend עם מספר פודים של WildFly, שגם מתקשר עם ה-couchbase דרך שירות couchbase.
בהמשך נבחן כיצד שירות הממוקם מחוץ לאשכול מתקשר דרך כתובת ה-IP שלו עם אלמנטים שנמצאים בתוך האשכול ובעלי כתובת IP פנימית.
אז, מכולות חסרות מדינה הן נהדרות, אבל עד כמה זה טוב להשתמש במיכלים ממלכתיים? בואו נסתכל על הגדרות המערכת עבור מיכלים מצביים או מתמשכים. ב-Docker, ישנן 4 גישות שונות לפריסת אחסון נתונים שכדאי לשים לב אליהן. הראשון הוא Implicit Per-Container, מה שאומר שכאשר משתמשים בקונטיינרים מלאים ב-couchbase, MySQL או MyDB, כולם מתחילים ברירת המחדל של Sandbox. כלומר, כל מה שמאוחסן בבסיס הנתונים מאוחסן בקונטיינר עצמו. אם המיכל נעלם, הנתונים נעלמים יחד איתו.
השני הוא Explicit Per-Container, כאשר אתה יוצר אחסון ספציפי עם אמצעי האחסון של docker צור פקודה ואחסן בו נתונים. גישת Per-Host השלישית קשורה למיפוי אחסון, כאשר כל מה שמאוחסן במיכל משוכפל בו זמנית על המארח. אם המכולה נכשל, הנתונים יישארו במארח. האחרון הוא שימוש במספר מארחים של Multi-Host, מה שמומלץ בשלב הייצור של פתרונות שונים. נניח שהמכולות שלך עם האפליקציות שלך פועלות על המארח, אבל אתה רוצה לאחסן את הנתונים שלך במקום כלשהו באינטרנט, ולשם כך אתה משתמש במיפוי אוטומטי עבור מערכות מבוזרות.
כל אחת מהשיטות הללו משתמשת במיקום אחסון ספציפי. מרומז ומפורש לכל מיכל מאחסן נתונים על המארח ב- /var/lib/docer/volumes. כאשר משתמשים בשיטת Per-Host, האחסון מותקן בתוך המיכל, והמיכל עצמו מותקן על המארח. עבור ריבוי מארחים, ניתן להשתמש בפתרונות כגון Ceph, ClusterFS, NFS וכו'.
אם מיכל מתמשך נכשל, ספריית האחסון הופכת ללא נגישה בשני המקרים הראשונים, אך בשני המקרים האחרונים הגישה נשמרת. עם זאת, במקרה הראשון, אתה יכול לגשת למאגר דרך מארח Docker הפועל על מכונה וירטואלית. במקרה השני, גם הנתונים לא יאבדו, כי יצרת אחסון מפורש.
אם המארח נכשל, ספריית האחסון אינה זמינה בשלושת המקרים הראשונים; במקרה האחרון, החיבור עם האחסון אינו מופרע. לבסוף, הפונקציה המשותפת לא נכללת לחלוטין לאחסון במקרה הראשון והיא אפשרית בשאר. במקרה השני, אתה יכול לשתף אחסון תלוי אם מסד הנתונים שלך תומך באחסון מבוזר או לא. במקרה של Per-Host, הפצת נתונים אפשרית רק על מארח נתון, ועבור מרובה מארח היא מסופקת על ידי הרחבת אשכול.
יש לקחת זאת בחשבון בעת יצירת מיכלים סטטיסטיים. כלי שימושי נוסף של Docker הוא תוסף Volume, שפועל על העיקרון של "סוללות קיימות, אך יש להחליף אותן." כאשר אתה מפעיל קונטיינר Docker, הוא אומר, "היי, ברגע שאתה מתחיל קונטיינר עם מסד נתונים, אתה יכול לאחסן את הנתונים שלך במיכל הזה!" זוהי תכונת ברירת המחדל, אך אתה יכול לשנות אותה. תוסף זה מאפשר לך להשתמש בכונן רשת או משהו דומה במקום מסד נתונים של מיכל. הוא כולל מנהל התקן ברירת מחדל לאחסון מבוסס מארח ומאפשר אינטגרציה של מיכלים עם מערכות אחסון חיצוניות כגון Amazon EBS, Azure Storage ודיסקים GCE Persistent.
השקף הבא מציג את הארכיטקטורה של התוסף Docker Volume.
הצבע הכחול מייצג את לקוח ה- Docker המשויך למארח ה- Docker הכחול, שיש לו מנוע אחסון מקומי המספק לך קונטיינרים לאחסון נתונים. ירוק מציין את Plugin Client ואת Plugin Daemon, שגם הם מחוברים למארח. הם מספקים את ההזדמנות לאחסן נתונים באחסון רשת מהסוג של Storage Backend שאתה צריך.
ניתן להשתמש בתוסף Docker Volume עם אחסון Portworx. מודול PX-Dev הוא למעשה קונטיינר שאתה מפעיל שמתחבר למארח ה- Docker שלך ומאפשר לך לאחסן נתונים בקלות ב- Amazon EBS.
לקוח Portworx מאפשר לך לעקוב אחר המצב של מיכלי אחסון שונים המחוברים למארח שלך. אם תבקר בבלוג שלי, תוכל לקרוא כיצד להפיק את המרב מ-Portworx עם Docker.
הרעיון של אחסון ב-Kubernetes דומה ל-Docker ומיוצג על ידי ספריות הנגישות למיכל שלך בפוד. הם בלתי תלויים באורך החיים של כל מיכל. סוגי האחסון הנפוצים ביותר הזמינים הם hostPath, nfs, awsElasticBlockStore ו-gsePersistentDisk. בואו נסתכל על איך החנויות האלה עובדות ב-Kubernetes. בדרך כלל, תהליך החיבור ביניהם מורכב מ-3 שלבים.
הראשון הוא שמישהו בצד הרשת, בדרך כלל מנהל מערכת, מספק לך אחסון מתמשך. יש קובץ תצורה של PersistentVolume מתאים לכך. לאחר מכן, מפתח האפליקציה כותב קובץ תצורה בשם PersistentVolumeClaim, או בקשת אחסון PVC, האומרת: "יש לי 50GB של אחסון מבוזר, אבל כדי שאנשים אחרים יוכלו להשתמש גם בקיבולת שלו, אני אומר ל-PVC הזה שאני כרגע צריך רק 10 GB". לבסוף, השלב השלישי הוא שהבקשה שלך מותקן כאחסון, והאפליקציה שיש לה את הפוד, או ערכת העתק, או משהו דומה, מתחילה להשתמש בה. חשוב לזכור שתהליך זה מורכב מ-3 השלבים שהוזכרו וניתן להרחבה.
השקופית הבאה מציגה את מיכל Kubernetes Persistence Container של ארכיטקטורת AWS.
בתוך המלבן החום המייצג את אשכול Kubernetes, יש צומת מאסטר אחד ושני צמתי עבודה, המצוינים בצהוב. אחד מצמתי העובדים מכיל תרמיל כתום, אחסון, בקר העתק ומיכל Docker Couchbase ירוק. בתוך האשכול, מעל הצמתים, מלבן סגול מציין את השירות הנגיש מבחוץ. ארכיטקטורה זו מומלצת לאחסון נתונים במכשיר עצמו. במידת הצורך, אני יכול לאחסן את הנתונים שלי ב-EBS מחוץ לאשכול, כפי שמוצג בשקופית הבאה. זהו מודל טיפוסי לקנה מידה, אבל יש היבט פיננסי שיש לקחת בחשבון בעת השימוש בו - אחסון נתונים במקום כלשהו ברשת עשוי להיות יקר יותר מאשר במארח. כאשר בוחרים בפתרונות קונטיינריזציה, זהו אחד הטיעונים כבדי המשקל.
בדיוק כמו עם Docker, אתה יכול להשתמש בקונטיינרים קבועים של Kubernetes עם Portworx.
זה מה שבטרמינולוגיה הנוכחית של Kubernetes 1.6 נקרא "StatefulSet" - דרך עבודה עם יישומי Stateful המעבדת אירועים לגבי עצירת הפוד וביצוע כיבוי חינני. במקרה שלנו, יישומים כאלה הם מסדי נתונים. בבלוג שלי תוכלו לקרוא כיצד ליצור StatefulSet ב-Kubernetes באמצעות Portworx.
בואו נדבר על היבט הפיתוח. כפי שאמרתי, ל-Docker יש 2 גרסאות - CE ו-EE, במקרה הראשון אנחנו מדברים על גרסה יציבה של ה-Community Edition שמתעדכנת אחת ל-3 חודשים, בניגוד לגרסה המעודכנת החודשית של EE. אתה יכול להוריד את Docker עבור Mac, Linux או Windows. לאחר ההתקנה, Docker יתעדכן אוטומטית וקל מאוד להתחיל.
עבור Kubernetes, אני מעדיף את גרסת Minikube - זו דרך טובה להתחיל עם הפלטפורמה על ידי יצירת אשכול על צומת בודד. כדי ליצור אשכולות של מספר צמתים, מבחר הגרסאות רחב יותר: אלו הם kops, kube-aws (CoreOS+AWS), kube-up (מיושן). אם אתם מחפשים להשתמש ב-Kubernetes מבוססי AWS, אני ממליץ להצטרף ל-AWS SIG, שנפגש באינטרנט בכל יום שישי ומפרסם מגוון חומרים מעניינים על עבודה עם AWS Kubernetes.
בואו נסתכל כיצד מתבצע עדכון מתגלגל בפלטפורמות אלו. אם יש אשכול של מספר צמתים, הוא משתמש בגרסה ספציפית של התמונה, למשל, WildFly:1. עדכון מתגלגל אומר שגרסת התמונה מוחלפת ברצף בגרסה חדשה בכל צומת, בזה אחר זה.
לשם כך אני משתמש בפקודה docker service update (שם שירות), שבה אני מציין את הגרסה החדשה של תמונת WildFly:2 ואת שיטת העדכון update-parallelism 2. המספר 2 אומר שהמערכת תעדכן 2 תמונות אפליקציה במקביל, אז עיכוב עדכון של 10 שניות 10s, ולאחר מכן 2 התמונות הבאות יעודכנו בעוד 2 צמתים וכו'. מנגנון עדכון מתגלגל פשוט זה מסופק לך כחלק מ-Docker.
ב-Kubernetes, עדכון מתגלגל עובד כך. בקר השכפול rc יוצר קבוצה של העתקים של אותה גרסה, וכל פוד ב-webapp-rc זה מסופק עם תווית הממוקמת ב-etcd. כשאני צריך פוד, אני משתמש בשירות היישומים כדי לגשת למאגר etcd, שמספק לי את הפוד באמצעות התווית שצוינה.
במקרה זה, יש לנו 3 pods בבקר השכפול המריצים את אפליקציית WildFly גרסה 1. בעת עדכון ברקע, נוצר בקר שכפול נוסף עם אותו שם ואינדקס בסוף - - xxxxx, כאשר x הם מספרים אקראיים, ו עם אותן תוויות. כעת ל- Application Service יש שלושה פודים עם הגרסה הישנה של האפליקציה ושלושה פודים עם הגרסה החדשה בבקר השכפול החדש. לאחר מכן, הפודים הישנים נמחקים, בקר השכפול עם הפודים החדשים משנה את שמו ומופעל.
בואו נעבור לניטור. ל-Docker יש הרבה פקודות ניטור מובנות. לדוגמה, ממשק שורת הפקודה docker container stats מאפשר להציג מידע על מצב הקונטיינרים לקונסולה בכל שנייה - שימוש במעבד, שימוש בדיסק, עומס ברשת. הכלי Docker Remote API מספק נתונים על האופן שבו הלקוח מתקשר עם השרת. הוא משתמש בפקודות פשוטות, אך מבוסס על Docker REST API. במקרה זה, המילים REST, Flash, Remote אומרות את אותו הדבר. כאשר אתה מתקשר עם המארח, זה REST API. ה-API של Docker Remote מאפשר לך לקבל מידע נוסף על הפעלת קונטיינרים. הבלוג שלי מתאר את הפרטים של השימוש בניטור זה עם Windows Server.
ניטור אירועי מערכת Docker בעת הפעלת אשכול מרובה מארח מאפשר לקבל נתונים על קריסת מארח או קריסת קונטיינר במארח ספציפי, שירותי קנה מידה וכדומה. החל מ-Docker 1.20, הוא כולל את Prometheus, שמטמיע נקודות קצה באפליקציות קיימות. זה מאפשר לך לקבל מדדים באמצעות HTTP ולהציג אותם על לוחות מחוונים.
תכונת ניטור נוספת היא cAdvisor (קיצור של Container advisor). הוא מנתח ומספק נתוני שימוש במשאבים וביצועים ממכולות פועלות, ומספק מדדי Prometheus ישירות מהקופסה. הדבר המיוחד בכלי זה הוא שהוא מספק נתונים רק עבור 60 השניות האחרונות. לכן, אתה צריך להיות מסוגל לאסוף את הנתונים האלה ולהכניס אותם למסד נתונים כדי שתוכל לפקח על תהליך ארוך טווח. ניתן להשתמש בו גם להצגת מדדי לוח מחוונים בצורה גרפית באמצעות Grafana או Kibana. בבלוג שלי יש תיאור מפורט כיצד להשתמש ב-cAdvisor כדי לנטר קונטיינרים באמצעות לוח המחוונים של Kibana.
השקף הבא מציג כיצד נראה פלט נקודת הקצה של Prometheus ואת המדדים הזמינים לתצוגה.
בצד שמאל למטה רואים מדדים עבור בקשות HTTP, תגובות וכו', בצד ימין התצוגה הגרפית שלהם.
Kubernetes כולל גם כלי ניטור מובנים. שקופית זו מציגה אשכול טיפוסי המכיל מאסטר אחד ושלושה צמתים עובדים.
כל אחד מצמתי העבודה מכיל cAdvisor המופעל אוטומטית. בנוסף, יש את Heapster, מערכת ניטור ביצועים ואיסוף מדדים התואמת Kubernetes גרסה 1.0.6 ומעלה. Heapster מאפשר לך לאסוף לא רק מדדי ביצועים של עומסי עבודה, פודים ומכולות, אלא גם אירועים ואותות אחרים שנוצרו על ידי האשכול כולו. כדי לאסוף נתונים, הוא מדבר עם Kubelet של כל פוד, מאחסן אוטומטית את המידע במסד הנתונים של InfluxDB ומוציא אותו כמדדים ללוח המחוונים של Grafana. עם זאת, זכור שאם אתה משתמש ב-miniKube, תכונה זו אינה זמינה כברירת מחדל, כך שתצטרך להשתמש בתוספות לניטור. אז הכל תלוי איפה אתה מריץ את הקונטיינרים ובאילו כלי ניטור אתה יכול להשתמש כברירת מחדל ואלו אתה צריך להתקין כתוספות נפרדות.
השקף הבא מציג לוחות מחוונים של Grafana המציגים את מצב הריצה של המכולות שלי. יש כאן די הרבה נתונים מעניינים. כמובן, ישנם כלי ניטור תהליכים מסחריים רבים של Docker ו-Kubernetes, כגון SysDig, DataDog, NewRelic. לחלקם יש תקופת ניסיון חינם של 30 שנה, כך שתוכלו לנסות ולמצוא את המתאים לכם ביותר. באופן אישי, אני מעדיף להשתמש ב-SysDig וב-NewRelic, שמשתלבים היטב עם Kubernetes. ישנם כלים המשתלבים באותה מידה גם בפלטפורמות Docker וגם בפלטפורמות Kubernetes.
כמה מודעות 🙂
תודה שנשארת איתנו. האם אתה אוהב את המאמרים שלנו? רוצים לראות עוד תוכן מעניין? תמכו בנו על ידי ביצוע הזמנה או המלצה לחברים, , אנלוגי ייחודי של שרתים ברמת הכניסה, שהומצא על ידינו עבורכם: (זמין עם RAID1 ו-RAID10, עד 24 ליבות ועד 40GB DDR4).
Dell R730xd זול פי 2 במרכז הנתונים Equinix Tier IV באמסטרדם? רק כאן בהולנד! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - החל מ-$99! לקרוא על
מקור: www.habr.com