היכרות עם Terraform
|
Getting your Trinity Audio player ready...
|
המייסד וה- CTO של HashiCorp מסביר את היסודות של Terraform, מה זה ואיך זה עובד בסרטון הלוח האינפורמטיבי הזה.
שלום! אני Armon Dadgar ואני רוצה לדבר קצת על HashiCorp Terraform היום.
Terraform, אם מעולם לא שמעתם על המוצר – זהו הכלי שלנו לביצוע Provisioning (הקצאה). כשאנחנו מדברים על Provisioning יש שתי בעיות שונות שאנחנו מדברים עליהן: היום הראשון והיום השני.
כאשר אנו מבצעים Provisioning, ישנו האתגר הראשון שלנו – "היום הראשון" – בו עדיין לא התחלנו להריץ דבר. איך נעבור מלא להריץ כלום להרצה של משהו?
ואז יש את אתגר "היום השני": כעת יש לנו משהו שבנינו ביום הראשון. ואז את היום השני: יש לנו מערך תשתית קיים, ואנחנו צריכים לפתח אותו ולעדכן אותו – הרי זה משהו שמשתנה לאורך זמן: אנו מוסיפים סרביסים חדשים, מסירים סרביסים ובדרך כלל גם מפתחים את התשתית שלנו.
כיצד Terraform פותר בעיה זו? אנו עקרונית מאמינים בגישה של "תשתית כקוד" (Infrastructure as Code). כוונתי היא שאנו מאפשרים לך להגדיר באופן הצהרתי, במעין קבוצה של קבצי תצורה של Terraform כיצד תרצה שהתשתית שלך תיראה. זהו משהו פשוט מאוד לקריאה, שבו אנו מתארים את הטופולוגיה שלנו. כוונתי לזה היא כשאנחנו מדברים על תשתית, יש בה לעתים הרבה "חלקים נעים": אולי יש לי VPC (ענן וירטואלי פרטי), או הרשת עצמה; כללי קבוצת האבטחה שלי (security rules); האופן בו אבטחת הרשת שלי מוגדרת. ואז בסביבה זו, אני מגדיר את קבוצת המכונות הווירטואליות (VMs) שלי. יכול להיות שיש לי כמה מחשבי VM שאני רוצה לספק. ואז בשכבה בנוסף על כך, יש לי load balancer.
דיאגרמה של הסביבה שלנו ב "יום השני"
אתם יכולים לדמיין כיצד הגרף הזה גדל לאורך זמן. אני מוסיף לו חלקים שונים, כמויות מורכבות שונות, ואני מפתח את התשתית בהדרגה יום-יום, שבוע-שבוע. אמנם זה תיאור גרפי, אך הדרך בה אנו לוכדים אותו בתצורת Terraform היא קלה מאוד בתיאור של כמות משאבים ברמה גבוהה. אנו מתארים את משאב ה- VPC ואת השדות הנדרשים ליצירת אלמנט זה של התשתית שלנו. ואז כאשר אנו מגדירים את הדברים האחרים הללו, אנו יכולים להתייחס למרכיבים האחרים של התשתית שלנו.
מה ש- Terraform עושה הוא נותן לנו זרימת עבודה ליצירה וניהול של זה. בסופו של דבר, מדובר בשלוש פקודות עיקריות שונות שאנו מריצים:
- Refresh
הפקודה הראשונה היא Terraform refresh. זה מיישב בין איך ש- Terraform חושב שהעולם נראה וה-view של Terraform על התשתית שלנו עם העולם האמיתי. איך זה עובד, Terraform יוצא ומדבר עם העולם האמיתי. שואל את ספקי התשתית השונים שלנו, בין אם זה VMware, או AWS, או Azure, וישאל אותם: "מה באמת פועל?"
באופן זה, Terraform מקבל תצוגה מעודכנת של מה באמת התשתית שלנו. - Plan
ואז אנחנו מנהלים תוכנית – Plan. תוכנית היא המקום בו Terraform מגלה מה היא צריכה לעשות. אפשר לחשוב על תוכנית כעל התאמה בין העולם האמיתי, אילו דברים באמת פועלים, לבין מה שאנחנו רוצים להפעיל ואת התצורה הרצויה שלנו. כשאנחנו מדברים על התצורה של Terraform, מה שאנחנו מכניסים לגרף הזה, זה המצב הרצוי לנו, זה אולי לא המצב כמו שהוא.
כדוגמא, ביום הראשון, כאשר אנו מבצעים זאת, שום דבר עדיין לא פועל. כאשר Terraform מריץ את התוכנית, הוא מבין שאין שום דבר שעדיין פועל במציאות. כדי להגיע לתצורה הרצויה הזו, Terraform צריך לאתחל את כל ארבעת המשאבים הללו, וזה הופך להיות התוכנית.
Terraform ייתן לנו output שאומר, "כדי להביא את העולם להיראות כמו שאתה רוצה שהוא יהיה, אני אלך לאתחל את ארבעת הדברים האלה".
ואז החלק האחרון הוא למעשה לעשות את זה – ע"י Apply - Apply
זהו שלב היישום של הביצוע של Terraform. כאשר אנו מיישמים את הביצוע של Terraform, זה מתחיל בתוכנית שלנו, של מה שאנחנו צריכים לעשות, והוא יוצא ומבצע אותה בעולם האמיתי.
כך Terraform ייצא החוצה, ויבין מהו הסדר הנכון בו יש לעשות זאת. יש כאן תלות טבעית. יש להגדיר את הרשת תחילה לפני שנוכל להגדיר את קבוצות האבטחה סביב. ברגע שאלה מוגדרים, אנו יכולים לאתחל את כל ה- VMs שלנו, בין אם אנו מבצעים אתחול אחד ובין אם אנו מבצעים אתחול של מאות כאלה במקביל, ו- Terraform יבין היכן יש את ההזדמנות ליצור דברים במקביל, ואיפה זה צריך להיות סדרתי אחד אחרי השני. ברגע ש- VMs אלה זמינים, Terraform יכול ליצור את ה- load balancer ולומר: "הכל הסתיים."
זה נותן לנו דרך לעשות את התשתית של היום הראשון, אנו מתארים כיצד אנו רוצים שתראה הסביבה שלנו, ניהלנו Terraform refresh, הוא אמר שאין שום דבר קיים, התוכנית אמרה שכל הדברים הללו ייווצרו, ואז ה- Apply יוצא ובונה אותו.
מה שקורה כעת ביום השני, הוא שאנו מתחילים לפתח את התשתית שלנו. בזמן שזה היה התשתית שלנו ביום הראשון, ביום השני ניכנס ונאמר, "אני רוצה תיעוד DNS שמצביע על איזון העומס שלי. אני רוצה שתהיה לי רשת הפצת תוכן כמו fastly לפני זה. ואני רוצה שה- VM שלי יהיה מחובר למערכת ניטור".
אני יכול לפקח על מחשבי ה- VM השונים האלה.
כעת, אנו משנים את תצורת ה- Terraform שלנו, אנו משפרים אותה על ידי הוספת ההגדרות של אלמנטים אחרים אלה לתצורת ה- TF שלנו, ואנחנו מפעילים מחדש את אותו תרשים עבודה בדיוק. כשאנחנו מריצים refres, אז Terraform יבין שארבעת המשאבים הראשונים הללו קיימים, אך החדשים לא. כאשר אנו מריצים את ה- plan שלנו, זה יגיד לנו ששום דבר לא צריך להיעשות עם ארבעת אלה. הם כבר קיימים והם במצב הרצוי, אך עלינו להוסיף שלושה אלמנטים חדשים כדי להגיע למקום בו אנו צריכים להיות. כעת כאשר אנו מפעילים את Terraform, הוא ממשיך ומדבר עם העולם האמיתי ומוסיף את שלושת הדברים החדשים האלה, ומביא את הסביבה להיראות כמו המצב הרצוי לנו.
היתרונות
היתרון בתהליך עבודה זה הוא רב. האחת, העבודה שלנו ביום הראשון זהה ליום השני שלנו. זה באמת חשוב מכיוון שהיום השני הוא סוג של נצח, זה משהו שנמשיך לעשות.
היתרון הנוסף של זה הוא משהו שדילגנו עליו למעשה, שהוא יום "n", כאשר אנו מחליטים להוציא את זה משימוש, אנחנו כבר לא צריכים את השירות הזה, אנחנו לא רוצים את התשתית הזו, אולי זה היה רק סביבת staging, או סביבת בדיקה, יש לנו אפשרות להיכנס ולהרוס.
Destroy
כשאנחנו עושים הרס (destroy), זה בעצם ביטול של כל מה שנעשה, נכון? במובן מסוים, זו גרסה מיוחדת של Apply, שיוצר תוכנית הרס מיוחדת, ואז יוצא, ומדבר עם העולם האמיתי, להשמיד את כל האלמנטים הקיימים. עכשיו אנחנו יכולים ביעילות, בסוף תהליך העבודה לעבור מכלום למשהו, לפתח אותו יום-יום, והיום האחרון בו אנו צריכים לפרק אותו, Terraform יודעת לנקות את כל המשאבים הקשורים לאפליקציה ההיא.
עד כה כל מה שדיברנו עליו הוא באמת על תהליך העבודה, וזה לא ספציפי לשום טכנולוגיה, אז איך Terraform בעצם גורם לכל הדברים האלה לעבוד?
זה המקום שבו הארכיטקטורה של Terraform הופכת להיות חשובה. כשאנחנו מדברים על האופן שבו Terraform עובד בפועל, יש שני סוגי מרכיבים עיקריים:
האחד הוא ה- core של Terraform, שהליבה המונוליטית אחראית לכמה דברים. היא לוקחת את התצורה של Terraform, המסופקת על ידי המשתמש, ואז היא לוקחת את התצוגה של Terraform על הסביבה, או על הstate של Terraform. זה מנוהל ע"י Terraform עצמה.
אלה מוזנים ל- core , והוא אחראי להבין מהו אותו גרף של המשאבים השונים שלנו, כיצד החלקים השונים מתייחסים זה לזה? מה צריך ליצור? מה צריך לעדכן? מה צריך להשמיד? זה עושה את כל הניהול המרכזי הזה של מחזור העבודה.
בצד האחורי, Terraform תומך בספקים (providers) רבים ושונים. ספקים הם איך ש- Terraform מתחבר לשאר הסביבה. אלה יכולים להיות דברים כמו ספקי ענן, דברים כמו AWS, או Azure, או GCP. הם יכולים להיות תשתית מקומית (on-premise), דברים כמו OpenStack או VMware, אך זה לא מוגבל רק לתשתיות כשירות. Terraform יכול גם לנהל דברים ברמה גבוהה יותר, פלטפורמות כשירות כמו Heroku, או Kubernetes, או דברים כמו lambda. אלה דברים ברמה גבוהה יותר ממה שאנחנו רואים באופן מסורתי בתשתית כשירות, יותר בתחום של פלטפורמה כשירות (Platform-as-a-service).
סוגי הדברים האחרים ש- Terraform יכולה לנהל הם תוכנה כשירות, דברים ברמה גבוהה מאוד, אולי ניטור, כמו Datadog, או CDNs כמו Fastly, או אפילו דברים כמו ניהול צוותי GitHub.
זה מה שהיינו רואים בתוכנה טהורה כשירות, אלה שירותים מנוהלים חיצונית, אך ה- view שאנו לוקחים כמחברי Terraform היא שכל החלקים הללו מחוברים. כשאני מדבר על תשתית מודרנית, אני עשוי לחבר את כל המשאבים השונים האלה. יכול להיות שיש לי איזשהו תשתית שהיא תשתית כשירות, ואז אני יכול לחבר את זה ולהגיד, "אתה יודע מה? אני הולך לספק cluster שח Kubernetes . על גבי ה- cluster שלי, אני אגדיר מרחב שמות ואגדיר שירותים.
אלה קיימים כעת על גבי התשתית כשירות, ואולי אני יכול לחבר אפילו אלה עם דברים ברמה גבוהה יותר כמו DNS ו- CDN. כל אלה הם חלקים חשובים בתשתית שלנו, איננו יכולים לספק את היישום שלנו ללא ה- iOS, ללא הפלטפורמה כשירות, וללא התוכנה ברמה הגבוהה יותר כשירות, כולם חלק מהקצה ההגיוני שלנו- מסירה סופית. מה שאנחנו רוצים להגיע אליו עם Terraform, הוא תהליך עבודה אחיד. אנחנו לא רוצים שזה יהיה שאתה משתמש בכלי אחד כדי לנהל את זה, ועכשיו אתה צריך להבין איך אתה עובר את החוויה המפורקת הזו כדי לנהל את החלק הבא, ואז חוויה אחרת של זה, ואתה צריך לחבר את כולם את הדברים האלה.
במקום זאת, כל מה שיש לו ממש ממשק API ויש לו מחזור חיים, איך נוכל לאפשר לזה להיות ספק, כך שטראפורם יכול לעזור לנו לפתור את הבעיה מקצה לקצה? זה באמת המקום שבו הספקים נכנסים. כיום יש לנו מעל 100 ספקים, ואלה יכולים לנהל בנפרד מעל 1000 משאבים שונים, כאשר משאב יכול להיות AWS, EC2 VM או Azure Blob Store, סוגים שונים של משאבים אלה הם כל מה ש ענן, או אפילו דברים ברמה גבוהה יותר אלה חושפים.
הרשימה הזו גדלה כל הזמן. Terraform הוא פרוייקט מסיבי פתוח לחלוטין עם אלפי תורמים, ולכן בכל יום יש ספקים חדשים ומשאבים חדשים.
איך זה באמת עובד ברמות שונות בתוך הצוותים?
זו הופכת לשאלת עבודה מעניינת סביב האופן שבו אתה באמת מנהל את Terraform. בתחילה זה חוזר לתהליך העבודה המרכזי שדיברנו עליו. אנחנו מתחילים עם מתרגל בודד אחד, שמשתמש בטראפורם באופן מקומי, וזרימת העבודה שלהם היא להתחיל בכתיבת תצורה כלשהי של Terraform, ואז הם מריצים תוכנית Terraform, התוכנית אומרת להם, "מה תצורה זו תעשה? מה Terraform חושבת שצריך לעשות כדי להחיל את השינויים האלה? " אם זה נראה טוב, המטפל ישים את השינויים ואז המחזור נמשך, הם ממשיכים לפתח את התשתית.
זה עשוי להיראות דומה מאוד לפיתוח תוכנה, שם אנו כותבים קוד כלשהו, אנו מיישמים בדיקות יחידה, אנו מבצעים שינויים אלה ואז אנו ממשיכים במחזור שלנו. מה קורה כשאנחנו עוברים מאדם יחיד לעכשיו אנו מוסיפים מספר חברי צוות? יש לנו אנשים אחרים שאנחנו רוצים לשתף פעולה בניהול אותה תשתית. ובכן, ישנם כמה אתגרים, בדומה הרבה לכתיבת תוכנה, וכך אנו מוודאים שיש לנו מבט עקבי על התצורה בפועל וכיצד נדאג שלא לדרוך אחד על אצבעותיו של זה, ולהריץ מספר שינויים במקביל? אם שנינו מנסים להוסיף חמישה מחשבים ניידים חדשים, כיצד נמנע מאתחול של 10 מחשבים ניידים חדשים במקום זאת?
בעיה זו, במובן מסוים, דומה מאוד לבעיית השימוש ב- git באופן מקומי, לעומת השימוש ב- Git כצוות. כשאנחנו הולכים לצוות, אנו משתמשים במערכת ל- GitHub, כדי לספק שיתוף פעולה מרכזי זה. המקבילה שלנו לזה היא מה שאנחנו מכנים Terraform Enterprise. זרימת העבודה של Terraform Enterprise מגדילה זאת מעט. מה היינו עושים במקום להפעיל אותו באופן מקומי ולהפעיל את סיכוני התיאום האלו, כפרט, אנו עדיין כותבים את ה- Terraform שלנו ומתכננים באופן מקומי, אך כעת אנו דוחפים זאת למערכת בקרת גרסאות. זה יכול להיות GitHub, יכול להיות Bitbucket, יכול להיות באמת כל דבר, אבל הרעיון הוא איך נעבור למאגר מרכזי שבו אנו מנהלים את זה, ולתאם בדיוק כמו שהיינו עושים לבקרת המקור. ואז אנחנו יוצאים מהיישום הזה של Terraform Enterprise.
המטרה כאן היא פי כמה. האחת, האם כיצד אנו מוודאים כי ניהול המדינה מתבצע באופן מקומי? כמו שאמרתי, Terraform עוקב אחר כל המשאבים שהוענקו לו, כך שהוא יידע בזמן ההרס מה הוא צריך להפיל, או כאשר אנו מבצעים שינויים מדורגים, מה כבר קיים. ה- state file הוא דבר חשוב לניהול מרכזי, כך שהוא לא מתפצל ולא מסתיים בשורות שונות בהן אנו מתפצלים, ואז מריצים את Terraform באופן עצמאי, וכעת קבצי המדינה מתנגשים עם אחר. על ידי ניהול זה באופן מרכזי, אנו נמנעים מסוג זה של התנגשויות. היתרון החשוב הנוסף כאן הוא כאשר אנו מוודאים שאנחנו מבצעים רק ריצה אחת בכל פעם. אנו מבטיחים שיש את היישום הרציף, כך שאם אליס ובוב עובדות על אותה תשתית, ושניהם מנסים לעשות שינוי – הם לא דורכים זה על זו.
לבסוף, אחד האתגרים הוא לעתים קרובות, בסביבה זו מפתחים משתמשים במשתנים מקומיים כדי לאכלס דברים כמו מפתחות AWSI או אישורים רגישים אחרים. אנחנו לא רוצים שהאישורים הרגישים האלה יהיו מפוזרים על כל מכונות המפתחים שלנו. במקום זאת, אם אנו רוצים שהמשתנים האלה יישמרו באופן מרכזי, ויצופנו, כך שלא נצטרך לדאוג שהדברים האלה ייחשפו, או ידלפו החוצה בטקסט רגיל, נוכל להציב אותם במקום מרכזי ובקרת גרסאות, ובקרת גישה מי יכול לשנות בפועל ולראות את הדברים האלה.
סוג זה משנה את ה- workflow שלנו, וכעת מאפשר לקומץ אנשים לשתף פעולה בבטחה יחד. ובכן, מה מתחיל לקרות כשאנחנו מתחילים לרצות להוסיף עוד אנשים? לדוגמה, אנו עשויים לעבור מהמפעילים המוקדמים שלנו, שמכירים מאוד את סביבת הענן לחשוף אותה יותר לקבוצות הפיתוח שלנו. זה המקום שבו הרעיון של Terraform של מודול שימושי. מודול Terraform הוא בערך כמו קופסה שחורה של תשתית, שם מה שאנחנו יכולים להגדיר כמערכת של משתני קלט שמאפשרים לנו להחליף את ההתנהגות של מודול זה והמודול עשוי לפלוט קבוצה של משתני פלט.
דוגמה לכך עשויה להיות, אני יכול להגדיר מודול לביצוע Java, לפריסת יישום ה- Java שלי ב- AWS, והתשומות שלי עשויות להיות מה הנתיב לצנצנת שלי, וכמה מקרים של יישום Java שלי אני רוצה? בתוך מודול זה, אנו יכולים לפעול כקופסה שחורה ולפרוס את כל ה- VM באמצעות EC2, אנו יכולים לפרוס פונקציות למבדה, נוכל לפרוס מכולות עם ECS, כל אלה הופכים לפרט המוסתר בתוך מודול זה שצרכן אינו צריך. לדעת על. התפוקה שלהם יכולה להיות פשוט מה הכתובת של מאזן העומסים שפוגע ביישום שלי? באופן זה אנו עוטפים את המורכבות ההופכת אותה לנגישה יותר לקהל רחב יותר.
כיצד אנו באמת מנהלים ומשתפים את המודולים הללו?
באופן כללי, אנו מפרסמים דברים אלה ברישום מרכזי. ישנו רישום מרכזי שקיים כיום עבור Terraform אם תעבור ל- registry.terraform.io, זה הרישום הציבורי הגלובלי שלנו, ושם תמצא מאות מודולים המכסים צורות נפוצות של תשתיות, דפוסים אדריכליים נפוצים, ורבים מהם הם פורסם על ידי ספקי הענן. אתה יכול להתחבר ולראות את ההמלצה הרשמית של גוגל כיצד לספק את הרשת שלהם או את ההמלצה הרשמית של Azure כיצד לנהל רשת וירטואלית בתוך Azure.
מודולים אלה הופכים את זה להרבה יותר מתכלה עבורנו לפעול בסביבות אלה, משום שאיננו צריכים להכיר כל פרט ממנו. אנחנו יכולים פשוט ללכת ולהגיד "אני רוצה להתחבר לאמזון, או בגוגל או לתכלת", ולמלא כמה מהקלטים החשובים לנו, ולתת למודול לדאוג לשאר המורכבות, נכון? ניתן להרחיב את אותו רעיון ליישומים שונים, סוגי תשתיות שונים.
אחת הדרכים שנוכל להחיל את אותו דפוס באופן פנימי על הארגון שלנו היא באמצעות הפעלת רישום פרטי. במקום להשתמש ברישום הציבורי הזמין ברחבי העולם, אנו יכולים להפעיל רישום פרטי בארגון שלנו. זו יכולת המשולבת ב- Terraform Enterprise. מה שבאמת מאפשר לנו להתחיל לעשות, הוא לעשות את הפיצול בין קבוצת האנשים הפנימיים שהם מכירים, ומכירים את התשתית הפנימית שלנו, ואיך צריך לנהל אותה, לבין סביבות ענן, והם יכולים לדחוף בעצם קטלוג, או רישום מודולים, את כל דפוסי המפתח השונים הדרושים.
אנו עשויים לפרסם, כך אנו עושים אפליקציית Java, כך אנו עושים אפליקציית C #, כך אנו מבצעים מסד נתונים וחושפים זאת לקהילת המפתחים הפנימית שלנו. לאחר מכן, בסיס הצרכנים הגדול הרבה יותר שלנו יכול פשוט להיכנס לקטלוג ולשלוף את הדברים שהם צריכים. צרכנים אלה יכולים לדעת הרבה פחות על אופן פעולתו של הענן, אך עדיין לקבל את המודולים המאושרים שהם סוג של שיטות עבודה מומלצות באופן פנימי, נכון?
יש סוג של כמה דרכים לצרוך את זה, עבור אנשים שמכירים יותר את Terraform, הם יכולים לצרוך את זה בדיוק כמו מודול Terraform רגיל ולעשות תשתית כגישת קוד. לאנשים שהם פחות מוכרים, הם עשויים לרצות לנקוט יותר בגישה של פאת סחרחורת, והם יכולים לעשות זאת עם Terraform Enterprise על ידי בחירת המודולים שלהם, מילוי המשתנים השונים, ובעצם לתת למערכת ליצור באופן אוטומטי את ה- Terraform המקביל עבור אוֹתָם.
הם יכולים להשתמש ב- Terraform המקביל כנקודת התחלה ולהתאים אותו משם הלאה, או אם אין להם באמת עניין ללמוד, ולהשתמש ישירות ב- Terraform, הם יכולים פשוט להשתמש ב- Terraform שנוצר באופן אוטומטי ולשירות עצמי את התשתית שלהם. . המטרה שלנו באמת הופכת לאופן שבו אנו מאפשרים לקהל הצרכנים הגדול הזה להגיע לשירות עצמי בתשתיות באופן שעדיין עומד בקנה אחד עם האופן שבו העסק רוצה לעשות את זה, ולא ליצור את זרימת העבודה העצומה הזו לבעלי אתרים כל הזמן. ליצור תשתית מותאמת אישית, והגדרות מותאמות אישית לגוף הצרכנים העצום בארגון שלנו.
בתמונת מצב זו Terraform, כך זה חל בתשתית כגישת קוד, על אספקה, באמת להסתכל גם על האתגר ביום הראשון, וחשוב מכך, ויותר מאתגר, על היום השני פלוס האתגר. ואז המסע הטבעי כשאנחנו עוברים מאדם יחיד המשתמש בטראפורם, לצוות קטן, לסוג של ארגון שלם שמנסה למנף את טרפורם לניהול תשתיות. אם אתה מעוניין ללמוד עוד על Terraform, או Terraform Enterprise, תודה.
