חלק 1: אינטרנט/אנדרואיד

שים לב: מאמר זה הוא תרגום לרוסית של המאמר המקורי "כלי DevOps הם לא רק עבור DevOps. "בניית תשתית אוטומציה לבדיקות מאפס". עם זאת, כל האיורים, הקישורים, הציטוטים והמונחים נשמרים בשפת המקור כדי למנוע עיוות של המשמעות בעת תרגום לרוסית. אני מאחל לך לימודים שמחים!

נכון לעכשיו, המומחיות של DevOps היא אחת המבוקשות ביותר בתעשיית ה-IT. אם תפתח אתרי חיפוש עבודה פופולריים ותסנן לפי שכר, תראה שמשרות הקשורות ל-DevOps נמצאות בראש הרשימה. עם זאת, חשוב להבין כי הכוונה היא בעיקר לתפקיד 'בכיר', מה שמרמז כי למועמד יש רמה גבוהה של כישורים, ידע בטכנולוגיה וכלים. זה מגיע גם עם מידה גבוהה של אחריות הקשורה לפעולה ללא הפרעה של הייצור. עם זאת, התחלנו לשכוח מה זה DevOps. בתחילה, זה לא היה אדם או מחלקה ספציפיים. אם נחפש הגדרות למונח זה, נמצא הרבה שמות עצם יפים ונכונים, כגון מתודולוגיה, פרקטיקות, פילוסופיה תרבותית, קבוצת מושגים וכדומה.

ההתמחות שלי היא מהנדס אוטומציה של בדיקות (מהנדס אוטומציה QA), אבל אני מאמין שאין לשייך אותה רק לכתיבת בדיקות אוטומטיות או פיתוח ארכיטקטורת מסגרת בדיקה. בשנת 2020, ידע בתשתיות אוטומציה הוא גם חיוני. זה מאפשר לך לארגן את תהליך האוטומציה בעצמך, מהפעלת בדיקות ועד מתן תוצאות לכל בעלי העניין בהתאם למטרות שלך. כתוצאה מכך, כישורי DevOps הם חובה לעבודה זו. וכל זה טוב, אבל, למרבה הצער, יש בעיה (ספוילר: מאמר זה מנסה לפשט את הבעיה הזו). הנקודה היא ש-DevOps קשה. וזה ברור, כי חברות לא ישלמו הרבה על משהו שקל לעשות... בעולם ה-DevOps יש מספר רב של כלים, מונחים ופרקטיקות שצריך לשלוט בהם. זה קשה במיוחד בתחילת הקריירה ותלוי בניסיון הטכני המצטבר.

מקור: http://maximelanciauxbi.blogspot.com/2017/04/devops-tools.html

כאן כנראה נסיים בחלק המבוא ונתמקד במטרה של מאמר זה. 

על מה המאמר הזה?

במאמר זה, אני הולך לחלוק את החוויה שלי בבניית תשתית אוטומציה לבדיקות. ישנם מקורות מידע רבים באינטרנט על כלים שונים ואופן השימוש בהם, אך הייתי רוצה להסתכל עליהם אך ורק בהקשר של אוטומציה. אני מאמין שמהנדסי אוטומציה רבים מכירים את המצב שבו אף אחד מלבדך לא מפעיל את הבדיקות שפותחו או דואג לתחזק אותם. כתוצאה מכך, המבחנים הופכים מיושנים ואתה צריך להשקיע זמן בעדכון שלהם. שוב, בתחילת הקריירה, זו יכולה להיות משימה די קשה: החלטה נבונה אילו כלים אמורים לסייע בביטול בעיה נתונה, כיצד לבחור, להגדיר ולתחזק אותם. חלק מהבודקים פונים ל-DevOps (בני אדם) לעזרה, ובואו נהיה כנים, הגישה הזו עובדת. במקרים רבים זו עשויה להיות האפשרות היחידה מכיוון שאין לנו ראות לכל התלות. אבל כידוע, DevOps הם בחורים מאוד עסוקים, כי הם צריכים לחשוב על כל התשתית של החברה, הפריסה, הניטור, שירותי המיקרו ומשימות דומות אחרות בהתאם לארגון/צוות. כפי שקורה בדרך כלל, אוטומציה אינה בראש סדר העדיפויות. במקרה כזה, עלינו לנסות לעשות כל מה שאפשר מצידנו מתחילתו ועד סופו. זה יקטין את התלות, יאיץ את זרימת העבודה, ישפר את הכישורים שלנו ויאפשר לנו לראות את התמונה הרחבה יותר של מה שקורה.

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

מה לא במאמר הזה

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

זה נעשה בגלל: 

• חומר זה קל מאוד למצוא במקורות שונים (תיעוד, ספרים, קורסי וידאו);
• אם נתחיל להעמיק, נצטרך לכתוב 10, 20, 30 חלקים של מאמר זה (בעוד שהתוכניות הן 2-3);
• אני פשוט לא רוצה לבזבז את זמנך מכיוון שאולי תרצה להשתמש בכלים אחרים כדי להשיג את אותן מטרות.

עיסוק

הייתי מאוד רוצה שהחומר הזה יהיה שימושי לכל קורא, ולא רק לקרוא ולהישכח. בכל מחקר, תרגול הוא מרכיב חשוב מאוד. לזה הכנתי מאגר GitHub עם הוראות שלב אחר שלב כיצד לעשות הכל מאפס. יש גם שיעורי בית שמחכים לך כדי לוודא שאתה לא מעתיק בלי דעת את השורות של הפקודות שאתה מבצע.

תכנית

שלב
טכנולוגיה
כלים

1
ריצה מקומית (הכן מבחני הדגמה באינטרנט / אנדרואיד והפעל אותם באופן מקומי) 
Node.js, Selenium, Appium

2
מערכות בקרת גרסאות 
Git

3
מיכליות
Docker, רשת סלניום, סלנואיד (אינטרנט, אנדרואיד)

4
CI/CD
Gitlab CI

5
פלטפורמות ענן
פלטפורמת Google Cloud

6
תזמורת
קוברנט

7
תשתית כקוד (IaC)
Terraform, Ansible

מבנה של כל חלק

כדי לשמור על הנרטיב ברור, כל חלק מתואר על פי המתווה הבא:

• תיאור קצר של הטכנולוגיה,
• ערך עבור תשתית אוטומציה,
• המחשה של המצב הנוכחי של התשתית,
• קישורים ללימודים,
• כלים דומים.

1. הפעל בדיקות באופן מקומי

תיאור קצר של הטכנולוגיה

זהו רק שלב הכנה להפעלת מבחני ההדגמה באופן מקומי ולוודא שהם עוברים. בחלק המעשי נעשה שימוש ב-Node.js, אך גם שפת התכנות והפלטפורמה אינן חשובות וניתן להשתמש באלו שנמצאות בשימוש בחברה שלכם. 

עם זאת, ככלי אוטומציה, אני ממליץ להשתמש ב- Selenium WebDriver לפלטפורמות אינטרנט וב-Appium לפלטפורמת אנדרואיד, בהתאמה, שכן בשלבים הבאים נשתמש בתמונות Docker המותאמות לעבודה ספציפית עם כלים אלו. יתרה מכך, בהתייחס לדרישות התפקיד, הכלים הללו הם המבוקשים ביותר בשוק.

כפי שאולי שמתם לב, אנו מתייחסים רק למבחני אינטרנט ואנדרואיד. לרוע המזל, iOS הוא סיפור אחר לגמרי (תודה אפל). אני מתכנן להציג פתרונות ונהלים הקשורים ל-IOS בחלקים הקרובים.

ערך עבור תשתית אוטומציה

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

המחשה של מצב התשתית הנוכחי

קישורים לחקור

• סלניום
• אפיום
• אמולטור Android
• דוגמאות של Selenium JS GitHub
• Appium JS GitHub דוגמאות

כלים דומים

• כל שפת תכנות שתרצה בשילוב עם מבחני סלניום/אפיום;
• כל בדיקות;
• כל רץ מבחן.

2. מערכות בקרת גרסאות (Git)

תיאור קצר של הטכנולוגיה

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

ערך עבור תשתית אוטומציה

וכאן אפשר לשאול שאלה סבירה: "למה הוא מספר לנו על גיט? כולם יודעים זאת ומשתמשים בו גם לקוד פיתוח וגם לקוד בדיקה אוטומטית". אתה בהחלט צודק, אבל במאמר זה אנחנו מדברים על תשתית וסעיף זה משמש כתצוגה מקדימה לסעיף 7: "תשתית כקוד (IaC)". מבחינתנו זה אומר שכל התשתית, כולל בדיקות, מתוארת בצורת קוד, כך שנוכל להחיל עליה גם מערכות גרסאות ולקבל הטבות דומות כמו לקוד פיתוח ואוטומציה.

נסתכל על IaC ביתר פירוט בשלב 7, אבל אפילו עכשיו אתה יכול להתחיל להשתמש ב-Git באופן מקומי על ידי יצירת מאגר מקומי. התמונה הגדולה תתרחב כאשר נוסיף מאגר מרוחק לתשתית.

המחשה של מצב התשתית הנוכחי

קישורים לחקור

• מהי בקרת גרסאות
• Git
• תחילת העבודה - על בקרת גרסה

כלים דומים

• SVN
• כַּספִּיתִי 
• Microsoft TFS (כעת הוא חלק משירותי Azure DevOps)

3. מיכל (Docker)

תיאור קצר של הטכנולוגיה

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

השלב הבא של האבולוציה היה מכונות וירטואליות (VMs), אשר פתרו את בעיית בזבוז הכסף על משאבים לא מנוצלים. טכנולוגיה זו אפשרה להפעיל יישומים באופן עצמאי אחד מהשני בתוך אותו שרת, תוך הקצאת שטח מבודד לחלוטין. אבל, למרבה הצער, לכל טכנולוגיה יש את החסרונות שלה. הפעלת VM דורשת מערכת הפעלה מלאה, שצורכת מעבד, זיכרון RAM, אחסון ובהתאם למערכת ההפעלה, יש לקחת בחשבון את עלויות הרישיון. גורמים אלה משפיעים על מהירות הטעינה ומקשים על הניידות.

ועכשיו אנחנו מגיעים למכולות. שוב, טכנולוגיה זו פותרת את הבעיה הקודמת, שכן קונטיינרים אינם משתמשים במערכת הפעלה מלאה, מה שמפנה כמות גדולה של משאבים ונותן פתרון מהיר וגמיש לניידות.

כמובן, טכנולוגיית מכולות אינה חדשה והוצגה לראשונה בסוף שנות ה-70. באותם ימים בוצעו הרבה מחקרים, פיתוחים וניסיונות. אבל דוקר הוא שהתאים את הטכנולוגיה הזו והפך אותה לנגישה בקלות להמונים. כיום, כשמדברים על קונטיינרים, ברוב המקרים מתכוונים לדוקר. כשאנחנו מדברים על קונטיינרים של Docker, אנחנו מתכוונים לקונטיינרים של לינוקס. אנחנו יכולים להשתמש במערכות Windows ו-macOS כדי להפעיל קונטיינרים, אבל חשוב להבין שבמקרה זה מופיעה שכבה נוספת. לדוגמה, Docker ב-Mac מריץ בשקט קונטיינרים בתוך VM קל משקל של Linux. נחזור לנושא זה כאשר נדון בהפעלת אמולטורים של אנדרואיד בתוך קונטיינרים, כך שכאן יש ניואנס חשוב מאוד שצריך לדון בו ביתר פירוט.

ערך עבור תשתית אוטומציה

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

• מספר עצום של תלות בעת התקנת סלניום ובמיוחד Appium;
• בעיות תאימות בין גרסאות של דפדפנים, סימולטורים ומנהלי התקנים;
• חוסר מקום מבודד לדפדפנים/סימולטורים, שהוא קריטי במיוחד לריצה במקביל;
• קשה לניהול ולתחזוקה אם אתה צריך להפעיל 10, 50, 100 או אפילו 1000 דפדפנים בו-זמנית.

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

רשת סלניום בדוקר

כלי זה הוא הפופולרי ביותר בעולם הסלניום להפעלת דפדפנים מרובים במספר מכונות וניהולם ממרכז מרכזי. כדי להתחיל, עליך לרשום לפחות 2 חלקים: רכזת וצמתים. Hub הוא צומת מרכזי שמקבל את כל הבקשות מבדיקות ומפיץ אותן לצמתים המתאימים. עבור כל Node נוכל להגדיר תצורה ספציפית, למשל, על ידי ציון הדפדפן הרצוי והגרסה שלו. עם זאת, אנחנו עדיין צריכים לדאוג למנהלי דפדפן תואמים בעצמנו ולהתקין אותם על הצמתים הרצויים. מסיבה זו, סלניום גריד אינו משמש בצורתו הטהורה, למעט כאשר אנו צריכים לעבוד עם דפדפנים שלא ניתן להתקין ב-Linux OS. עבור כל שאר המקרים, פתרון גמיש ונכון באופן משמעותי יהיה להשתמש בתמונות Docker כדי להפעיל את ה-Selenium grid Hub וצמתים. גישה זו מפשטת מאוד את ניהול הצמתים, מכיוון שאנו יכולים לבחור את התמונה הדרושה לנו עם גרסאות תואמות של דפדפנים ומנהלי התקנים שכבר מותקנים.

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

סלנואיד לאינטרנט

כלי זה מהווה פריצת דרך בעולם הסלניום מכיוון שהוא פועל ישירות מהקופסה והפך את חייהם של מהנדסי אוטומציה רבים לקלים הרבה יותר. קודם כל, זה לא עוד שינוי של רשת סלניום. במקום זאת, המפתחים יצרו גרסה חדשה לחלוטין של Selenium Hub בגולנג, אשר בשילוב עם תמונות Docker קלות משקל לדפדפנים שונים, נתנה תנופה לפיתוח אוטומציה של בדיקות. יתרה מכך, במקרה של Selenium Grid, עלינו לקבוע מראש את כל הדפדפנים הנדרשים וגרסאותיהם, וזו לא בעיה בעבודה עם דפדפן אחד בלבד. אבל כשמדובר במספר דפדפנים נתמכים, סלנואיד היא הפתרון מספר אחת הודות לתכונת 'דפדפן לפי דרישה' שלה. כל מה שנדרש מאיתנו הוא להוריד את התמונות הדרושות עם דפדפנים מראש ולעדכן את קובץ התצורה איתו סלנואיד מקיימת אינטראקציה. לאחר שסלנואיד יקבל בקשה מהבדיקות, היא תפעיל אוטומטית את המיכל הרצוי עם הדפדפן הרצוי. כאשר הבדיקה תסתיים, Selenoid תוציא את המיכל, ובכך תפנה משאבים לבקשות עתידיות. גישה זו מבטלת לחלוטין את הבעיה הידועה של 'הידרדרות הצמתים' שאנו נתקלים בה לעתים קרובות ברשת סלניום.

אבל, אבוי, סלנואיד הוא עדיין לא כדור כסף. קיבלנו את התכונה 'דפדפן לפי דרישה', אבל התכונה 'משאבים לפי דרישה' עדיין לא זמינה. כדי להשתמש בסלנואיד, עלינו לפרוס אותו בחומרה פיזית או ב-VM, מה שאומר שעלינו לדעת מראש כמה משאבים צריך להקצות. אני מניח שזו לא בעיה עבור פרויקטים קטנים המריצים 10, 20 או אפילו 30 דפדפנים במקביל. אבל מה אם אנחנו צריכים 100, 500, 1000 ועוד? זה לא הגיוני לתחזק ולשלם עבור כל כך הרבה משאבים כל הזמן. בסעיפים 5 ו-6 של מאמר זה, נדון בפתרונות המאפשרים לך לבצע קנה מידה, ובכך להוזיל משמעותית את עלויות החברה.

סלנואיד לאנדרואיד

לאחר הצלחת סלנואיד ככלי אוטומציה של אינטרנט, אנשים רצו משהו דומה עבור אנדרואיד. וזה קרה - סלנואיד שוחרר עם תמיכה באנדרואיד. מנקודת מבט של משתמש ברמה גבוהה, עקרון הפעולה דומה לאוטומציה באינטרנט. ההבדל היחיד הוא שבמקום מיכלי דפדפן, Selenoid מריץ קונטיינרים של אמולטור אנדרואיד. לדעתי, זהו כרגע הכלי החינמי החזק ביותר להפעלת מבחני אנדרואיד במקביל.

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

המחשה של מצב התשתית הנוכחי

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

קישורים לחקור

• דוקר: מה זה מכולה
• דוקר: התחל
• 5 חלופות מיכל ל-Docker
• רשת סלניום
• סלניום דוקר
• סלנואיד
• Selenoid Github
• הגדרת KVM עבור אמולטורים של אנדרואיד
• ספר דוקר Deep Dive

כלים דומים

• ישנם כלי קיבולת אחרים, אך Docker הוא הפופולרי ביותר. אם אתה רוצה לנסות משהו אחר, זכור שהכלים שסיקרנו להפעלת בדיקות סלניום במקביל לא יעבדו מהקופסה.  
• כפי שכבר נאמר, ישנם שינויים רבים ברשת סלניום, למשל, זלניום.

4.CI/CD

תיאור קצר של הטכנולוגיה

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

אז, יש 3 מונחים: CI - אינטגרציה מתמשכת, CD - מסירה רציפה ושוב CD - פריסה מתמשכת. (להלן אשתמש במונחים אלו באנגלית). כל שינוי מוסיף מספר שלבים נוספים לצינור הפיתוח שלך. אבל המילה רציף (רציף) הוא הדבר החשוב ביותר. בהקשר זה, אנו מתכוונים למשהו שקורה מתחילתו ועד סופו, ללא הפרעות או התערבות ידנית. הבה נסתכל על CI & CD ו-CD בהקשר זה.

• אינטגרציה מתמשכת זהו השלב הראשוני של האבולוציה. לאחר שליחת קוד חדש לשרת, אנו מצפים לקבל משוב מהיר שהשינויים שלנו בסדר. בדרך כלל, CI כולל הפעלת כלים לניתוח קוד סטטי ובדיקות API פנימיות של יחידה/יחידה. זה מאפשר לנו לקבל מידע על הקוד שלנו תוך מספר שניות/דקות.
• משלוח רציף הוא שלב מתקדם יותר שבו אנו מפעילים מבחני אינטגרציה/ממשק משתמש. עם זאת, בשלב זה איננו משיגים תוצאות במהירות כמו עם CI. ראשית, בדיקות מסוג זה לוקחות יותר זמן. שנית, לפני ההשקה, עלינו לפרוס את השינויים שלנו בסביבת הבדיקה/ביימה. יתרה מכך, אם אנחנו מדברים על פיתוח מובייל, נראה שלב נוסף ליצירת מבנה של האפליקציה שלנו.
• פריסה מתמשכת מניח שאנחנו משחררים אוטומטית את השינויים שלנו לייצור אם כל מבחני הקבלה עברו בשלבים הקודמים. בנוסף לכך, לאחר שלב השחרור, ניתן להגדיר שלבים שונים, כגון הפעלת בדיקות עשן על ייצור ואיסוף מדדים בעלי עניין. פריסה רציפה אפשרית רק עם כיסוי טוב על ידי בדיקות אוטומטיות. אם נדרשות התערבויות ידניות, כולל בדיקות, זה כבר לא רציף (רָצִיף). אז אנחנו יכולים לומר שהצינור שלנו תואם רק את הנוהג של משלוח רציף.

ערך עבור תשתית אוטומציה

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

ולפני שנסתכל על ההמחשה של השינוי בארכיטקטורה, אני רוצה לומר כמה מילים על GitLab CI. בניגוד לכלי CI/CD אחרים, GitLab מספקת מאגר מרוחק ותכונות נוספות רבות אחרות. לפיכך, GitLab הוא יותר מ-CI. הוא כולל ניהול קוד מקור, ניהול זריז, צינורות CI/CD, כלי רישום ואיסוף מדדים מהקופסה. ארכיטקטורת GitLab מורכבת מ- Gitlab CI/CD ו- GitLab Runner. להלן תיאור קצר מהאתר הרשמי:

Gitlab CI/CD היא אפליקציית אינטרנט עם API המאחסנת את מצבה במסד נתונים, מנהלת פרויקטים/בונים ומספקת ממשק משתמש. GitLab Runner הוא אפליקציה שמעבדת בנייה. ניתן לפרוס אותו בנפרד ועובד עם GitLab CI/CD דרך API. עבור בדיקות שפועלות אתה צריך גם מופע Gitlab וגם Runner.

המחשה של מצב התשתית הנוכחי

קישורים לחקור

• מרטין פאולר: אינטגרציה מתמשכת
• GitLab CI / CD
• ספר אינטגרציה מתמשכת
• ספר משלוח רציף

כלים דומים

• ג'נקינס
• TeamCity
• טראוויס 
• ורבים אחרים

5. פלטפורמות ענן

תיאור קצר של הטכנולוגיה

בחלק זה נדבר על טרנד פופולרי שנקרא 'עננים ציבוריים'. למרות היתרונות העצומים שטכנולוגיות הוירטואליזציה והקונטיינריזציה שתוארו לעיל מספקות, אנו עדיין זקוקים למשאבי מחשוב. חברות רוכשות שרתים יקרים או שוכרות מרכזי נתונים, אך במקרה זה יש צורך לבצע חישובים (לפעמים לא מציאותיים) של כמה משאבים נצטרך, האם נשתמש בהם 24/7 ולאילו מטרות. למשל, הייצור דורש שרת הפועל XNUMX/XNUMX, אך האם אנו זקוקים למשאבים דומים לבדיקה מחוץ לשעות העבודה? זה תלוי גם בסוג הבדיקה המתבצעת. דוגמה לכך היא מבחני עומס/לחץ שאנו מתכננים לערוך בשעות שאינן עבודה על מנת לקבל תוצאות למחרת. אבל בהחלט לא נדרשת זמינות שרת XNUMX/XNUMX עבור בדיקות אוטומטיות מקצה לקצה ובמיוחד לא עבור סביבות בדיקה ידניות. במצבים כאלה, יהיה טוב להשיג כמה משאבים שצריך לפי דרישה, להשתמש בהם ולהפסיק לשלם כשאין בהם עוד צורך. יתר על כן, זה יהיה נהדר לקבל אותם באופן מיידי על ידי ביצוע כמה לחיצות עכבר או הפעלת כמה סקריפטים. לשם כך משתמשים בעננים ציבוריים. בואו נסתכל על ההגדרה:

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

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

ערך עבור תשתית אוטומציה

אילו משאבים ספציפיים אנחנו צריכים עבור מבחני ממשק משתמש מקצה לקצה? בעצם אלו מכונות וירטואליות או אשכולות (נדבר על Kubernetes בסעיף הבא) להפעלת דפדפנים ואמולטורים. ככל שנרצה להפעיל יותר דפדפנים ואמולטורים בו-זמנית, כך נדרשים יותר מעבד וזיכרון ואנחנו צריכים לשלם על כך יותר כסף. כך, עננים ציבוריים בהקשר של אוטומציה של בדיקות מאפשרים לנו להפעיל מספר רב (100, 200, 1000...) של דפדפנים/אימולטורים לפי דרישה, לקבל תוצאות בדיקה כמה שיותר מהר ולהפסיק לשלם עבור כל כך עתיר משאבים בטירוף. כּוֹחַ. 

ספקי הענן הפופולריים ביותר הם Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). המדריך מספק דוגמאות לשימוש ב-GCP, אבל באופן כללי זה לא משנה במה אתה משתמש למשימות אוטומציה. כולם מספקים בערך את אותה פונקציונליות. בדרך כלל, כדי לבחור ספק, ההנהלה מתמקדת בתשתית הכוללת ובדרישות העסקיות של החברה, וזה מעבר להיקף של מאמר זה. עבור מהנדסי אוטומציה, יהיה מעניין יותר להשוות את השימוש בספקי ענן לשימוש בפלטפורמות ענן במיוחד למטרות בדיקה, כמו Sauce Labs, BrowserStack, BitBar וכדומה. אז בואו נעשה את זה גם! לדעתי, Sauce Labs היא חוות בדיקות הענן המפורסמת ביותר, וזו הסיבה שהשתמשתי בה לשם השוואה. 

GCP לעומת Sauce Labs למטרות אוטומציה:

בואו נדמיין שאנחנו צריכים להריץ 8 מבחני אינטרנט ו-8 מבחני אנדרואיד בו זמנית. לשם כך נשתמש ב-GCP ונפעיל 2 מכונות וירטואליות עם Selenoid. בראשון נעלה 8 מכולות עם דפדפנים. על השני יש 8 מיכלים עם אמולטורים. בואו נסתכל על המחירים:  

כדי להפעיל מכולה אחת עם Chrome, אנחנו צריכים n1-standard-1 אוטו. במקרה של אנדרואיד זה יהיה n1-standard-4 עבור אמולטור אחד. למעשה, דרך גמישה וזולה יותר היא להגדיר ערכי משתמש ספציפיים למעבד/זיכרון, אבל כרגע זה לא חשוב להשוואה עם Sauce Labs.

והנה התעריפים לשימוש ב-Sauce Labs:

אני מאמין שכבר שמת לב להבדל, אבל עדיין אספק טבלה עם חישובים עבור המשימה שלנו:

משאבים נדרשים
מונטלי
שעות עבודה(8 בבוקר - 8 בערב)
שעות עבודה+ מונע

GCP לאינטרנט
n1-standard-1 x 8 = n1-standard-8
$194.18
23 ימים * 12 שעות * 0.38 = $104.88 
23 ימים * 12 שעות * 0.08 = $22.08

Sauce Labs עבור האינטרנט
Virtual Cloud8 בדיקות מקבילות
$1.559
-
-

GCP עבור אנדרואיד
n1-standard-4 x 8: n1-standard-16
$776.72
23 ימים * 12 שעות * 1.52 = $419.52 
23 ימים * 12 שעות * 0.32 = $88.32

Sauce Labs עבור אנדרואיד
בדיקות מקבילות של Real Device Cloud 8
$1.999
-
-

כפי שאתה יכול לראות, ההבדל בעלות הוא עצום, במיוחד אם אתה מפעיל בדיקות רק במהלך תקופת עבודה של שתים עשרה שעות. אבל אתה יכול לצמצם עלויות עוד יותר אם אתה משתמש במכונות מונעות. מה זה?

VM מונע הוא מופע שאתה יכול ליצור ולהפעיל במחיר הרבה יותר נמוך ממופעים רגילים. עם זאת, Compute Engine עשוי לסיים (להקדים) מקרים אלה אם הוא דורש גישה למשאבים אלה עבור משימות אחרות. מופעים מונעים הם קיבולת Compute Engine עודפת, כך שהזמינות שלהם משתנה בהתאם לשימוש.

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

וזה עדיין לא נגמר! במציאות, אני בטוח שאף אחד לא עורך מבחנים במשך 12 שעות ללא הפסקה. ואם כן, אז אתה יכול להפעיל ולעצור אוטומטית מכונות וירטואליות כאשר אין בהן צורך. זמן השימוש בפועל עשוי להיות מופחת ל-6 שעות ביום. אז התשלום בהקשר של המשימה שלנו יקטן ל-$11 לחודש עבור 8 דפדפנים. האין זה נפלא? אבל עם מכונות מונעות עלינו להיות זהירים ולהיות מוכנים להפרעות וחוסר יציבות, למרות שניתן לספק ולטפל במצבים אלה בתוכנה. זה שווה את זה!

אבל בשום פנים ואופן אני לא אומר 'לעולם אל תשתמש בחוות בדיקות ענן'. יש להם מספר יתרונות. קודם כל, לא מדובר רק במכונה וירטואלית, אלא בפתרון אוטומציית בדיקות מלא עם סט פונקציונליות מחוץ לקופסה: גישה מרחוק, יומנים, צילומי מסך, הקלטת וידאו, דפדפנים שונים ומכשירים ניידים פיזיים. במצבים רבים, זו יכולה להיות חלופה שיק חיונית. פלטפורמות בדיקה שימושיות במיוחד עבור אוטומציה של IOS, כאשר עננים ציבוריים יכולים להציע רק מערכות Linux/Windows. אבל נדבר על iOS במאמרים הבאים. אני ממליץ תמיד להסתכל על המצב ולהתחיל מהמשימות: בחלק מהמקרים זול ויעיל יותר להשתמש בעננים ציבוריים, ובאחרים פלטפורמות הבדיקה בהחלט שוות את הכסף שמוציאים.

המחשה של מצב התשתית הנוכחי

קישורים לחקור

• GCP
• GCP: מונע
• GCP: תמחור VM
• SauceLabs
• השוואה בין ספקי ענן

כלים דומים:

• AWS 
• תכלת

6. תזמור

תיאור קצר של הטכנולוגיה

יש לי חדשות טובות - אנחנו כמעט בסוף המאמר! נכון לעכשיו, תשתית האוטומציה שלנו מורכבת מבדיקות אינטרנט ואנדרואיד, אותם אנו מריצים דרך GitLab CI במקביל, תוך שימוש בכלים התומכים ב-Docker: Selenium grid ו-Selenoid. יתרה מכך, אנו משתמשים במכונות וירטואליות שנוצרו באמצעות GCP כדי לארח קונטיינרים עם דפדפנים ואמולטורים. כדי להפחית עלויות, אנו מפעילים את המכונות הווירטואליות הללו רק לפי דרישה ומפסיקים אותן כאשר הבדיקות אינן מבוצעות. האם יש משהו אחר שיכול לשפר את התשתית שלנו? התשובה היא כן! הכירו את Kubernetes (K8s)!

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

למען האמת, פריסה ידנית של Kubernetes מאפס היא לא משימה טריוויאלית בכלל. אני אשאיר קישור למדריך המפורסם "Kubernetes The Hard Way" ואם אתה מעוניין, אתה יכול לתרגל אותו. אבל, למרבה המזל, יש שיטות וכלים חלופיים. הדרך הקלה ביותר היא להשתמש ב-Google Kubernetes Engine (GKE) ב-GCP, שיאפשר לכם לקבל אשכול מוכן בכמה קליקים. אני ממליץ להשתמש בגישה זו כדי להתחיל ללמוד, מכיוון שהיא תאפשר לך להתמקד בלימוד כיצד להשתמש ב-K8s עבור המשימות שלך במקום ללמוד כיצד הרכיבים הפנימיים צריכים להשתלב אחד עם השני. 

ערך עבור תשתית אוטומציה

בואו נסתכל על כמה תכונות משמעותיות שה-K8s מספקות:

• פריסת יישומים: שימוש באשכול רב-צמתים במקום מחשבי VM;
• קנה מידה דינמי: מפחית את עלות המשאבים המשמשים רק לפי דרישה;
• ריפוי עצמי: התאוששות אוטומטית של תרמילים (כתוצאה מכך משוחזרים גם מיכלים);
• השקת עדכונים והחזרה של שינויים ללא זמן השבתה: עדכון כלים, דפדפנים ואמולטורים אינם מפריעים לעבודתם של המשתמשים הנוכחיים

אבל ה-K8s עדיין לא כדור כסף. כדי להבין את כל היתרונות והמגבלות בהקשר של הכלים שאנו שוקלים (Selenium grid, Selenoid), נדון בקצרה במבנה של K8s. אשכול מכיל שני סוגים של צמתים: צמתים ראשיים וצמתי עובדים. צמתי מאסטר אחראים על החלטות ניהול, פריסה ותזמון. צמתי עובדים הם המקום שבו מופעלים יישומים. צמתים מכילים גם סביבת זמן ריצה של מיכל. במקרה שלנו, מדובר ב-Docker, שאחראית על פעולות הקשורות למכולות. אבל יש גם פתרונות חלופיים, למשל מכיל. חשוב להבין כי אבנית או ריפוי עצמי אינם חלים ישירות על מיכלים. זה מיושם על ידי הוספה/הפחתה של מספר הפודים, שבתורם מכילים מיכלים (בדרך כלל מיכל אחד לכל פוד, אך בהתאם למשימה עשויים להיות יותר). ההיררכיה ברמה הגבוהה מורכבת מצמתי עובדים, שבתוכם יש תרמילים, שבתוכם מורמים מיכלים.

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

עכשיו בואו נסתכל על הכלים שלנו בהקשר של המונחים לעיל.

רשת סלניום

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

סלנואיד:

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

ירח:

מתוך ידיעת צוואר הבקבוק הזה כשעבדו עם Selenoid, המפתחים שחררו כלי חזק יותר בשם Moon. כלי זה תוכנן במקור לעבוד עם Kubernetes, וכתוצאה מכך, ניתן וצריך להשתמש בתכונת קנה המידה האוטומטי. יתר על כן, הייתי אומר שכרגע זה כך יחיד כלי בעולם הסלניום, שיש לו תמיכת אשכולות K8s מקורית מהקופסה (לא זמין יותר, ראה הכלי הבא ). תכונות המפתח של ירח המספקות תמיכה זו הן: 

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

אז ירח הוא פתרון מצוין, אבל יש בעיה אחת: הוא לא בחינם. המחיר תלוי במספר המפגשים. אתה יכול להריץ רק 0-4 מפגשים בחינם, וזה לא שימושי במיוחד. אבל, החל מהפגישה החמישית, תצטרך לשלם $5 עבור כל אחד. המצב עשוי להיות שונה מחברה לחברה, אבל במקרה שלנו, השימוש ב-Moon הוא חסר טעם. כפי שתיארתי לעיל, אנו יכולים להפעיל מחשבי VM עם Selenium Grid לפי דרישה או להגדיל את מספר הצמתים באשכול. עבור צינור אחד בערך, אנו משיקים 500 דפדפנים ועוצרים את כל המשאבים לאחר השלמת הבדיקות. אם השתמשנו ב-Moon, היינו צריכים לשלם 500 x 5 נוספים = 2500 דולר לחודש, לא משנה באיזו תדירות נבצע בדיקות. שוב, אני לא אומר אל תשתמש מון. עבור המשימות שלך, זה יכול להיות פתרון הכרחי, למשל, אם יש לך הרבה פרויקטים/צוותים בארגון שלך ואתה צריך אשכול ענק משותף לכולם. כמו תמיד, אני משאיר קישור בסוף וממליץ לעשות את כל החישובים הנדרשים בהקשר של המשימה שלך.

קליסטו: (תשומת הלב! זה לא מופיע במאמר המקורי והוא כלול רק בתרגום לרוסית)

כפי שאמרתי, סלניום הוא כלי מאוד פופולרי, ותחום ה-IT מתפתח מהר מאוד. בזמן שעבדתי על התרגום, הופיע ברשת כלי מבטיח חדש בשם Callisto (שלום ברוש ​​ורוצחי סלניום אחרים). זה עובד באופן מקורי עם K8s ומאפשר לך להפעיל מיכלי סלנואיד בתרמילים, המופצים על פני צמתים. הכל עובד ישירות מהקופסה, כולל קנה מידה אוטומטי. פנטסטי, אבל צריך להיבדק. כבר הצלחתי לפרוס את הכלי הזה ולהריץ מספר ניסויים. אבל זה מוקדם מדי להסיק מסקנות, לאחר קבלת תוצאות ממרחק רב, אולי אעשה סקירה במאמרים עתידיים. לעת עתה אני משאיר רק קישורים למחקר עצמאי.  

המחשה של מצב התשתית הנוכחי

קישורים לחקור

• Kubernetes: הגדרה
• Kubernetes: בדרך הקשה
• Kubernetes: סלניום
• GCP: מנוע Kubernetes
• ירח
• ספר קוברנטס
• אוטומציה מבוזרת באמצעות Kubernetes
• רשת סלניום 4
• Callisto GitHub
• Wrike TechClub (קליסטו)

כלים דומים

• נחיל דוקר 
• מרתון 

7. תשתית כקוד (IaC)

תיאור קצר של הטכנולוגיה

ועכשיו הגענו לסעיף האחרון. בדרך כלל, טכנולוגיה זו ומשימות נלוות אינן באחריותם של מהנדסי אוטומציה. ויש לכך סיבות. ראשית, בארגונים רבים, נושאי התשתית נמצאים בשליטה של ​​מחלקת DevOps ולצוותי הפיתוח לא ממש אכפת ממה שגורם לצינור לעבוד ואיך צריך לתמוך בכל מה שקשור אליו. שנית, בואו נהיה כנים, הפרקטיקה של Infrastructure as Code (IaC) עדיין לא מאומצת בחברות רבות. אבל זה בהחלט הפך לטרנד פופולרי וחשוב לנסות להיות מעורב בתהליכים, הגישות והכלים הקשורים אליו. או לפחות להישאר מעודכנים.

נתחיל עם המוטיבציה לשימוש בגישה זו. כבר דנו שכדי להפעיל בדיקות ב- GitlabCI, נצטרך לכל הפחות את המשאבים כדי להפעיל את Gitlab Runner. וכדי להפעיל קונטיינרים עם דפדפנים/אימולטורים, עלינו להזמין VM או אשכול. בנוסף למשאבי בדיקה, אנו זקוקים לכמות משמעותית של קיבולת לתמיכה בפיתוח, בימוי, בסביבות ייצור, הכוללת גם מסדי נתונים, לוחות זמנים אוטומטיים, תצורות רשת, מאזני עומסים, זכויות משתמש וכו'. הנושא המרכזי הוא המאמץ הנדרש כדי לתמוך בכל זה. ישנן מספר דרכים בהן אנו יכולים לבצע שינויים ולהפיץ עדכונים. לדוגמה, בהקשר של GCP, נוכל להשתמש במסוף ממשק המשתמש בדפדפן ולבצע את כל הפעולות על ידי לחיצה על כפתורים. אלטרנטיבה תהיה להשתמש בקריאות API כדי ליצור אינטראקציה עם ישויות ענן, או להשתמש בכלי שורת הפקודה gcloud כדי לבצע את המניפולציות הרצויות. אבל עם מספר גדול באמת של ישויות ומרכיבי תשתית שונים, זה הופך להיות קשה או אפילו בלתי אפשרי לבצע את כל הפעולות באופן ידני. יתר על כן, כל הפעולות הידניות הללו אינן ניתנות לשליטה. איננו יכולים להגיש אותם לבדיקה לפני ביצוע, להשתמש במערכת בקרת גרסאות ולבטל במהירות את השינויים שהובילו לאירוע. כדי לפתור בעיות כאלה, המהנדסים יצרו ויצרו סקריפטים אוטומטיים של bash/shell, שאינם טובים בהרבה משיטות קודמות, מכיוון שלא קל כל כך לקרוא אותם במהירות, להבין אותם, לתחזק ולשנות אותם בסגנון פרוצדורלי.

במאמר זה ובמדריך איך לעשות, אני משתמש בשני כלים הקשורים לתרגול IaC. אלה Terraform ו-Ansible. יש אנשים המאמינים שאין זה הגיוני להשתמש בהם בו זמנית, מכיוון שהפונקציונליות שלהם דומה והם ניתנים להחלפה. אבל העובדה היא שבתחילה הם מקבלים משימות שונות לחלוטין. והעובדה שהכלים הללו צריכים להשלים זה את זה אושרה במצגת משותפת של מפתחים המייצגים את HashiCorp ו-RedHat. ההבדל הרעיוני הוא ש- Terraform הוא כלי אספקה ​​לניהול השרתים עצמם. בעוד Ansible הוא כלי לניהול תצורה שתפקידו להתקין, להגדיר ולנהל תוכנות בשרתים אלו.

מאפיין נוסף המבחין של כלים אלה הוא סגנון הקידוד. שלא כמו bash ו-Ansible, Terraform משתמש בסגנון הצהרתי המבוסס על תיאור של מצב הקצה הרצוי שיושג כתוצאה מביצוע. לדוגמה, אם אנחנו הולכים ליצור 10 VMs ולהחיל את השינויים דרך Terraform, אז נקבל 10 VMs. אם נריץ את הסקריפט שוב, שום דבר לא יקרה מכיוון שכבר יש לנו 10 VMs, ו-Terraform יודע על זה כי הוא מאחסן את המצב הנוכחי של התשתית בקובץ מצב. אבל Ansible משתמשת בגישה פרוצדורלית, ואם תבקש ממנה ליצור 10 VMs, אז בהשקה הראשונה נקבל 10 VMs, בדומה ל- Terraform. אבל לאחר הפעלה מחדש יהיו לנו כבר 20 VMs. זה ההבדל החשוב. בסגנון פרוצדורלי, אנחנו לא מאחסנים את המצב הנוכחי ומתארים פשוט רצף של שלבים שיש לבצע. כמובן, אנחנו יכולים להתמודד עם מצבים שונים, להוסיף כמה בדיקות לקיומם של משאבים ולמצב הנוכחי, אבל אין טעם לבזבז את זמננו ולהשקיע מאמצים בשליטה בהיגיון הזה. בנוסף, זה מגביר את הסיכון לטעויות. 

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

ערך עבור תשתית אוטומציה

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

הנה כמה דוגמאות לשימוש ב- Terraform ו-Ansible בהקשר של אוטומציה של בדיקות והכלים שדנו בהם קודם:

1. תאר את המאפיינים והפרמטרים הדרושים של מחשבי VM ואשכולות באמצעות Terraform.

2. באמצעות Ansible, התקן את הכלים הדרושים לבדיקה: docker, Selenoid, Selenium Grid והורד את הגרסאות הנדרשות של דפדפנים/אימולטורים.

3. באמצעות Terraform, תאר את המאפיינים של ה-VM בו יושק GitLab Runner.

4. התקן את GitLab Runner ואת הכלים הנלווים הדרושים באמצעות Ansible, הגדר הגדרות ותצורות.

המחשה של מצב התשתית הנוכחי

קישורים לחקור:

• Terraform
• בלתי אפשרי
• Ansible ו- Terraform טובים יותר ביחד
• מדריך מקיף ל- Terraform
• מדוע אנו משתמשים ב- Terraform ולא ב- Chef, Puppet, Ansible, SaltStack או CloudFormation
• GCP: IaC

כלים דומים

• שֶׁף
• בּוּבָּה
• SaltStack
• מְשׁוֹטֵט

בואו נסכם את זה!

שלב
טכנולוגיה
כלים
ערך עבור תשתית אוטומציה

1
ריצה מקומית
Node.js, Selenium, Appium

• הכלים הפופולריים ביותר לאינטרנט ולנייד
• תומך בשפות ופלטפורמות רבות (כולל Node.js)

2
מערכות בקרת גרסאות 
Git

• יתרונות דומים עם קוד פיתוח

3
מיכליות
Docker, רשת סלניום, סלנואיד (אינטרנט, אנדרואיד)

• הפעלת מבחנים במקביל
• סביבות מבודדות
• שדרוגי גרסה פשוטים וגמישים
• עצירה דינמית של משאבים שאינם בשימוש
• קל להתקנה

4
CI/CD
Gitlab CI

• בודק חלק מהצינור
• משוב מהיר
• נראות לכל החברה/צוות

5
פלטפורמות ענן
פלטפורמת Google Cloud

• משאבים לפי דרישה (אנחנו משלמים רק כשצריך)
• קל לניהול ולעדכון
• נראות ושליטה בכל המשאבים

6
תזמורת
קוברנט
בהקשר של מכולות עם דפדפנים/אימולטורים בתוך פודים:

• קנה מידה / קנה מידה אוטומטי
• ריפוי עצמי
• עדכונים והחזרות ללא הפרעות

7
תשתית כקוד (IaC)
Terraform, Ansible

• יתרונות דומים עם תשתית פיתוח
• כל היתרונות של גירסאות קוד
• קל לבצע שינויים ולתחזק
• אוטומטי לחלוטין

דיאגרמות מפת חשיבה: אבולוציה של תשתית

שלב 1: מקומי

שלב 2: VCS

שלב 3: מיכליות 

שלב 4: CI/CD 

שלב 5: פלטפורמות ענן

שלב 6: תזמור

שלב 7: IaC

מה הלאה?

אז זהו סוף המאמר. אבל לסיכום, אני רוצה לקבוע איתך כמה הסכמים.

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

אבל גם אחרי זה, אל תעצרו, תתרגלו, תלמדו קישורים וספרים רלוונטיים, תבררו איך זה עובד בחברה שלכם, מצאו מקומות שאפשר לשפר וקחו בזה חלק. בהצלחה!

מהצד שלי

מהכותרת אפשר לראות שזה היה רק ​​החלק הראשון. למרות העובדה שהתברר שהוא די גדול, נושאים חשובים עדיין לא מכוסים כאן. בחלק השני, אני מתכנן להסתכל על תשתית אוטומציה בהקשר של IOS. בשל ההגבלות של אפל להפעיל סימולטורים של iOS רק במערכות macOS, מגוון הפתרונות שלנו מצומצם. לדוגמה, אנחנו לא יכולים להשתמש ב-Docker כדי להפעיל את הסימולטור או בעננים ציבוריים כדי להפעיל מכונות וירטואליות. אבל זה לא אומר שאין חלופות אחרות. אשתדל לעדכן אתכם בפתרונות מתקדמים ובכלים חדישים!

כמו כן, לא הזכרתי נושאים די גדולים הקשורים לניטור. בחלק 3, אני הולך לבחון את כלי ניטור התשתית הפופולריים ביותר ואיזה נתונים ומדדים לקחת בחשבון.

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

מקור: www.habr.com