בדיקה אוטומטית של שירותי מיקרו ב-Docker לאינטגרציה רציפה

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

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

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

אוטומציה של גישה זו מציגה מספר בעיות, שהפתרון להן יתואר להלן:

• התנגשויות של משימות מקבילות באותו מארח docker;
• התנגשויות מזהים במסד הנתונים במהלך איטרציות בדיקה;
• מחכה לשירותי מיקרו להיות מוכנים;
• מיזוג ופלט יומנים למערכות חיצוניות;
• בדיקת בקשות HTTP יוצאות;
• בדיקת שקעי אינטרנט (באמצעות SignalR);
• בדיקת אימות והרשאה של OAuth.

מאמר זה מבוסס על הנאום שלי ב-SECR 2019. אז למי שמתעצל לקרוא, הנה הקלטה של ​​הנאום.

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

אותו סקריפט מופעל הן על ידי המפתחים עצמם על שולחנות העבודה של Windows והן על ידי שרת Gitlab CI תחת לינוקס.

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

הבדיקה חייבת לפעול בשרת מקומי מהסיבות הבאות:

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

בנוסף, לא רצוי להשתמש במעמד מכיוון:

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

על הפרויקט וארגון התהליך

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

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

ארכיטקטורת פרויקט

האפליקציה מורכבת מיותר מעשרה שירותים. חלקם כתובים ב-.NET Core וחלקם ב-NodeJs. כל שירות פועל בקונטיינר Docker ב- Amazon Elastic Container Service. לכל אחד יש מסד נתונים Postgres משלו, ולחלקם יש גם Redis. אין מסדי נתונים נפוצים. אם מספר שירותים זקוקים לאותם נתונים, אזי הנתונים הללו, כאשר הם משתנים, מועברים לכל אחד מהשירותים הללו באמצעות SNS (Simple Notification Service) ו-SQS (Amazon Simple Queue Service), והשירותים שומרים אותם בבסיסי נתונים נפרדים משלהם.

SQS ו-SNS

SQS מאפשר לך להכניס הודעות לתור ולקרוא הודעות מהתור באמצעות פרוטוקול HTTPS.

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

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

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

שער API

רוב השירותים אינם נגישים ישירות מהאינטרנט. הגישה היא דרך API Gateway, שבודק זכויות גישה. זה גם השירות שלנו, וגם לזה יש בדיקות.

התראות בזמן אמת

האפליקציה משתמשת אות R.כדי להציג הודעות בזמן אמת למשתמש. זה מיושם בשירות ההתראות. הוא נגיש ישירות מהאינטרנט ובעצמו עובד עם OAuth, כי התברר שזה לא מעשי לבנות תמיכה עבור שקעי Web ב-Gateway, לעומת שילוב OAuth ושירות ההתראות.

גישת בדיקה ידועה

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

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

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

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

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

נעבור לפתרון

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

הקמת סביבת בדיקה

המשימה הראשונה היא פריסת סביבת בדיקה. השלבים הנדרשים להפעלת מיקרו-שירות:

• הגדר את השירות הנבדק עבור הסביבה המקומית, ציין את הפרטים לחיבור למסד הנתונים ול-AWS במשתני הסביבה;
• הפעל את Postgres ובצע את ההגירה על ידי הפעלת Liquibase.
  ב-DBMSs יחסי, לפני כתיבת נתונים למסד הנתונים, עליך ליצור סכימת נתונים, במילים אחרות, טבלאות. בעת עדכון אפליקציה יש להביא טבלאות לטופס המשמש את הגרסה החדשה, ורצוי, מבלי לאבד נתונים. זה נקרא הגירה. יצירת טבלאות במסד נתונים ריק בתחילה היא מקרה מיוחד של הגירה. ניתן לבנות הגירה באפליקציה עצמה. גם ל-.NET וגם ל-NodeJS יש מסגרות הגירה. במקרה שלנו, מסיבות אבטחה, נשללת משירותי המיקרו את הזכות לשנות את סכימת הנתונים, וההעברה מתבצעת באמצעות Liquibase.
• הפעל את Amazon LocalStack. זהו יישום של שירותי AWS להפעלה בבית. יש תמונה מוכנה עבור LocalStack ב- Docker Hub.
• הפעל את הסקריפט כדי ליצור את הישויות הדרושות ב-LocalStack. סקריפטים של מעטפת משתמשים ב-AWS CLI.

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

כיצד פועלת הבדיקה האוטומטית?

במהלך הבדיקה הכל עובד ב-Docker: השירות הנבדק, Postgres, כלי ההגירה ו-Postman, או יותר נכון, גרסת הקונסולה שלו - ניומן.

Docker פותר מספר בעיות:

• עצמאות מתצורת המארח;
• התקנת תלות: Docker מוריד תמונות מ- Docker Hub;
• החזרת המערכת למצבה המקורי: פשוט הוצאת המיכלים.

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

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

הסקריפט מבצע את השלבים הבאים:

• בניית תמונות Docker

  docker-compose build

• הפעלת מסד הנתונים ו-LocalStack

  docker-compose up -d <контейнер>

• הגירה של מסדי נתונים והכנת LocalStack

  docker-compose run <контейнер>

• השקת השירות הנבדק

  docker-compose up -d <сервис>

• הפעלת המבחן (ניומן)
• עצירת כל המכולות

  docker-compose down

• פרסום תוצאות ב-Slack
  יש לנו צ'אט שבו עוברות הודעות עם סימן ביקורת ירוק או צלב אדום וקישור ליומן.

התמונות הבאות של Docker מעורבות בשלבים אלה:

• השירות הנבדק הוא אותה תמונה כמו לייצור. התצורה של הבדיקה היא באמצעות משתני סביבה.
• עבור Postgres, Redis ו-LocalStack, נעשה שימוש בתמונות מוכנות מ- Docker Hub. יש גם תמונות מוכנות עבור Liquibase ו-Newman. אנחנו בונים את שלנו על השלד שלהם, מוסיפים שם את הקבצים שלנו.
• כדי להכין את LocalStack, אתה משתמש בתמונת AWS CLI מוכנה ויוצר תמונה המכילה סקריפט המבוסס עליה.

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

בעיות שאתה עלול להיתקל בהן

מחכה למוכנות

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

בעיה זו נפתרת לפעמים באמצעות סקריפט wait-for-it.sh, שמחכה להזדמנות ליצור חיבור TCP. עם זאת, LocalStack עשוי לזרוק שגיאת 502 Bad Gateway. בנוסף, הוא מורכב משירותים רבים, ואם אחד מהם מוכן, זה לא אומר כלום על האחרים.

החלטה: סקריפטים להקצאת LocalStack שמחכים לתגובה של 200 מ-SQS וגם מ-SNS.

התנגשויות משימות מקבילות

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

החלטה: הסקריפט מגדיר את המשתנה COMPOSE_PROJECT_NAME לערך ייחודי.

תכונות Windows

ישנם מספר דברים שאני רוצה לציין בעת ​​השימוש ב-Docker ב-Windows, מכיוון שחוויות אלו חשובות להבנת מדוע מתרחשות שגיאות.

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

כך מוגדר git:

git config core.autocrlf input

1. Git-bash מחקה תיקיות לינוקס סטנדרטיות, וכאשר קוראים לקובץ exe (כולל docker.exe), מחליף נתיבי לינוקס מוחלטים בנתיבי Windows. עם זאת, זה לא הגיוני עבור נתיבים שאינם במכונה המקומית (או נתיבים במיכל). לא ניתן להשבית התנהגות זו.

החלטה: הוסף לוכסן נוסף לתחילת הנתיב: //bin במקום /bin. לינוקס מבינה נתיבים כאלה; עבורה, מספר לוכסנים זהים לאחד. אבל git-bash לא מזהה נתיבים כאלה ולא מנסה להמיר אותם.

פלט יומן

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

הפתרון המקורי היה לעשות docker-compose למעלה ללא דגל -d, אבל באמצעות יכולות המעטפת, שלח את התהליך הזה לרקע:

docker-compose up <service> &

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

החלטה:

docker attach --no-stdin ${COMPOSE_PROJECT_NAME}_<сервис>_1 &

התנגשות מזהה במהלך איטרציות בדיקה

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

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

החלטה: צור GUIDs באמצעות סקריפטים של Postman.

var uuid = require('uuid');
var myid = uuid.v4();
pm.environment.set('myUUID', myid);

לאחר מכן השתמש בסמל בשאילתה {{myUUID}}, שיוחלף בערך המשתנה.

שיתוף פעולה באמצעות LocalStack

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

החלטה: בקשות מ-Postman ל-LocalStack.

ה-API של שירותי AWS מתועד, ומאפשר לבצע שאילתות ללא SDK.

אם שירות כותב לתור, אנו קוראים אותו ובודקים את תוכן ההודעה.

אם השירות שולח הודעות ל-SNS, בשלב ההכנה LocalStack גם יוצר תור ונרשם לנושא ה-SNS הזה. ואז הכל מסתכם במה שתואר לעיל.

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

בדיקת בקשות HTTP שמקורן בשירות המיקרו הנבדק

שירותים מסוימים עובדים על HTTP עם משהו אחר מלבד AWS, וחלק מתכונות AWS אינן מיושמות ב-LocalStack.

החלטה: במקרים אלו זה יכול לעזור MockServer, שיש בו תמונה מוכנה רכזת דוקר. בקשות צפויות ותגובות להן מוגדרות על ידי בקשת HTTP. ה-API מתועד, ולכן אנו פונים בקשות מ-Postman.

בדיקת אימות והרשאה של OAuth

אנו משתמשים ב-OAuth ו סמלי אינטרנט של JSON (JWT). הבדיקה דורשת ספק OAuth שנוכל להריץ באופן מקומי.

כל אינטראקציה בין השירות לספק ה-OAuth מסתכמת בשתי בקשות: ראשית, התצורה מתבקשת /.well-known/openid-configuration, ולאחר מכן המפתח הציבורי (JWKS) מתבקש בכתובת מהתצורה. כל זה הוא תוכן סטטי.

החלטה: ספק ה-OAuth לבדיקה שלנו הוא שרת תוכן סטטי ושני קבצים עליו. האסימון נוצר פעם אחת ומחויב ל-Git.

תכונות של בדיקת SignalR

Postman לא עובד עם websockets. כלי מיוחד נוצר לבדיקת SignalR.

לקוח SignalR יכול להיות יותר מסתם דפדפן. קיימת עבורו ספריית לקוח תחת .NET Core. הלקוח, שנכתב ב-.NET Core, יוצר חיבור, מאומת ומחכה לרצף מסוים של הודעות. אם מתקבלת הודעה לא צפויה או שהחיבור אבד, הלקוח יוצא עם קוד של 1. אם ההודעה הצפויה האחרונה מתקבלת, הלקוח יוצא עם קוד של 0.

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

כדי להפעיל מספר לקוחות השתמש באפשרות --סוּלָם בשורת הפקודה docker-compose.

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

החלטה: הלקוח במיכל משתמש במנגנון בדיקת בריאותכדי ליידע את התסריט במארח על מצבו. הלקוח יוצר קובץ בנתיב מסוים, למשל /healthcheck, ברגע שהחיבור נוצר. סקריפט HealthCheck בקובץ docker נראה כך:

HEALTHCHECK --interval=3s CMD if [ ! -e /healthcheck ]; then false; fi

קבוצה דוקר לבדוק מציג את המצב הרגיל, מצב הבריאות וקוד היציאה של המכולה.

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

האפינס קיים

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

בדיקות אלו מגנות על צוות של 30+ מפתחים מפני שגיאות באפליקציה עם אינטראקציה מורכבת של 10+ שירותי מיקרו עם פריסות תכופות.

מקור: www.habr.com