סקירה: רד האט עושה את דוקר בדרך הקשה

הפרויקט אטומי של Red Hat הוא דרך דעתנית להפעיל מכולות לינוקס. מערכת ההפעלה Atomic Host מגיעה עם Docker (מכולות), Flannel (רשת), OSTree (ניהול מארח), Etcd (מאגר ערכי מפתח מבוזר) ו- Kubernetes (תזמור) כבר מותקנים. 

Kubernetes היא אחת משתי מערכות תזמור המכולות הפופולריות, השנייה היא Docker Swarm. אתה יכול לקרוא לזה "כוח מלא", אך עם זאת מורכבות נוספת ותקורה מנהלית.

Kubernetes מרכז את יצירת "תרמילים" על פני מספר מארחים אטומיים. תרמילים הם קבוצות של מכולות Docker המפרידות באופן הגיוני בין שירותים ביישום. המכולות בתרמיל חולקות כתובת IP ומתקשרות דרך localhost.

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

Etcd משמש לאחסון תצורות עבור Kubernetes ו- Flannel בכל המארחים באשכול.

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

אם אתה שולט ב"עיצוב לפי מוסכמה "ואתה רוצה יותר חופש וגמישות במארח מכולות, אתה יכול לשקול RancherOS או VMware פוטון. אם המטרה הסופית שלך היא להפעיל מכולות רבות על מארחים רבים, אז Atomic Host, Kubernetes וחברים עשויים להיות בדיוק מה שאתה צריך.  

ניהול מערכת מארח אטומי

Atomic Host משתמש בגרסה משלו של dockerהפקודה atomic, אם כי dockerהפקודה האמיתית  זמינה ב- / bin / docker. מיקומו ב / bin מרמז על חלק מהעיבודים שעשו ל- RHEL / CentOS / Fedora כדי להפוך את מערכת ההפעלה Atomic המיועדת למכולות. בדרך כלל רק בינאריות חשובות של המערכת ממוקמות ב / bin.

אתה מנהל את Atomic Host באמצעות שתי תת מערכות. RPM-OSTree מטפל בפריסה ובעדכונים של המערכת המארחת, ואילו Docker מטפל בהקצאת מכולות להפעלת שירותים ויישומים. שתי מערכות המשנה הללו מנוהלות על ידי atomicהפקודה הממוקמת ב- / usr / bin /.

RPM-OSTree הופך את מערכת הקבצים Atomic לבלתי ניתנת לשינוי; כלומר, מערכת הקבצים היא לקריאה בלבד למעט / var ו / וכו '. בספריה / var / lib / docker מאוחסנים כל הקבצים והתמונות הקשורים ל- Docker, ואילו / etc מכילים את כל קבצי התצורה. כפי שנראה בהמשך, הדבר מאפשר שדרוגים ושדרוגים נמוכים ופשוטים יותר של המארח, דרישה חיונית בעת ניהול אלפי מארחי מכולות באשכול.

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

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

במילים פשוטות,  atomic הפקודה מאפשרת לך לתפעל את תשתית המארח הבסיסית (קבוצות קבוצות, מרחבי שמות, SELinux וכו ') להפעלת היישומים שלך. לדוגמא, נניח שבנית יישום מיכל של Network Time Protocol (ntpd) הדורש יכולת SYS_TIME על מנת לשנות את זמן המערכת של המארח. תוכל להגדיר זאת על ידי הוספת מטא נתונים לתמונת המכולה שלך באמצעות הפקודה:

LABEL RUN /usr/bin/docker run -d —cap-add=SYS_TYPE ntpd

לאחר מכן, כאשר אתה מפעיל את המיכל ( atomic run ntpd), המערכת תקרא את המטא-נתונים ותגדיר את יכולת SYS_TIME ומשאבים אחרים עבור המכולה. 

התקנה ותצורה של מארח אטומי

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

עבור כל מי שמכיר התקנת CentOS, הליך המתכת החשוף יהיה קל. ההבדלים הבולטים היחידים הם בפריסת הדיסק, כאשר המקום שמור אוטומטית ל- Docker ולמכולות, יחד עם שפע התושבות עבור SELinux, קבוצות קבוצות וכו 'המלווים בהתקנת מערכת הפעלה למכולות.

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

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

לאחר הגדרת התצורה של המאסטר עם Kubernetes, אישורים, שירותים ורשת שכבת-על של פלנל, לאחר מכן התקנתי את Flannel (flanneld), Kubernetes (kubelet) ו- Etcd בכל צומת, סוף סוף פעלתי אשכול מכולות בן חמש צמתים. למרבה הצער זה אכל לא מעט זיכרון, ולא הצלחתי למצוא דרך לבדוק באמצעות צומת יחיד, כמו שעשיתי בבדיקת RancherOS ו- VMware פוטון.

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

אחסון ורשתות מארח אטומי

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

ב- Docker, תמונות וקבצים קשורים מאוחסנים בדרך כלל ב- / var / lib / docker, וברוב מערכות ההפעלה הסטנדרטיות פשוט תרכיב התקן בנקודה זו במערכת הקבצים כדי להוסיף אחסון. עם זאת, Atomic משתמש בכרכים ישירים של LVM (Linux Volume Manager) דרך הגב של Mapper Device כדי לאחסן תמונות דוקר ומטא נתונים: / dev / atomicos / docker-data ו- dev / atomicos / docker-meta. זה אומר שתצטרך ללמוד משהו על LVM ונפחים כדי להוסיף מקום למארח Atomic.

נקודת המוצא לניהול אחסון ב- Atomic היא סקריפט ההתקנה, / etc / sysconfig / setup-docker-storage. ל- Atomic Host יש בריכת אחסון לאחסון Docker (ו- host), כך שהטריק כאן הוא הוספת מכשיר חדש לבריכה זו. תוכלו לעשות זאת על ידי הוספת לרשימת המכשירים בקובץ, כך:

DEVS="/dev/vdb /dev/vdc"

ואז אתה מפעיל את סקריפט העוזר, / usr / bin / docker-storage-setup. אם הכל מסתדר כשורה, הדיסקים שלך נוספו לבריכה, ולמארח Atomic שלך יש מקום ל- Docker. אני מניח ש- LVM ינוהל בייצור באמצעות כלי ניהול קיימים, או עם סוגים של תסריטים של Ansible / Salt / Chef / Puppet, כך שהם כנראה ייראו סטנדרטיים יותר עבור מנהלים העובדים בסביבות מרכזים גדולים.

Project Atomic משתמש ב- Flannel כדי לספק רשת כיסוי מכולה באמצעות Etcd. אתה מגדיר זאת על ידי דחיפת קובץ תצורה של JSON לחנות ערך המפתח וכו ', באמצעות כלים כמו Curl. כדי להגדיר רשת משנה עבור המכולות, אנו עשויים ליצור קובץ JSON שנראה כך:

   "רשת": "172.16.0.0/12",

   "SubnetLen": 24,

   "Backend": {

      "סוג": "vxlan"

   }

}

וכדי להכניס את זה למנהל ה- Etcd, אנו דוחפים אותו למפתח תצורת הרשת:

curl -L //localhost:2379/v2/keys/atomic.io/config -XPUT --data-urlencode [email protected]

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

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

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

שדרוגים ושדרוגים של מארח אטומי

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

atomic host upgrade

atomic host rollback

שים לב שלא בדקתי החזרה, כי לא היה לי למה לחזור.

מארח האטומים של רד האט מתאים ביותר לארגונים עם השקעה כבדה בכישורים ובתשתיות של רד האט. חברות שמתחילות מזווית אחרת עשויות לרצות לשקול אפשרויות אחרות. הכללת Kubernetes וההיסטוריה של Red Hat בסביבות ייצור גדולות פירושן ש- Atomic Host תהיה כמעט "ירידה" להפעלת עומסי עבודה במיכלים בארגונים. אבל אני לא רואה במפתחים להרים את זה כפלטפורמת ה- Docker שלהם.