פיתוח יישומים ופריסה כחול-ירוק על בסיס מתודולוגיית The Twelve-Factor App עם דוגמאות php ו-docer

נתחיל עם תיאוריה קטנה. מה קרה אפליקציית XNUMX הפקטורים?

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

המסמך נוצר על ידי מפתחי פלטפורמת Heroku.

ניתן ליישם את מתודולוגיית ה-XNUMX-Factor App על יישומים הכתובים בכל שפת תכנות ושימוש בכל שילוב של שירותי גיבוי של צד שלישי (מסדי נתונים, תורי הודעות, מטמונים וכו').

בקצרה על הגורמים עצמם עליהם מתבססת מתודולוגיה זו:

1. בסיס קוד – בסיס קוד אחד במעקב מקור – פריסות מרובות
2. תלות - הכרזה מפורשת ובידוד תלות
3. תְצוּרָה - שמור תצורה בזמן ריצה
4. שירותי צד שלישי (שירותי גיבוי) - התייחס לשירותי גיבוי כאל משאבים הניתנים לחיבור
5. לבנות, לשחרר, לרוץ - הפרדה מוחלטת של שלבי בנייה והפעלה
6. Процессы - הפעל את האפליקציה כתהליך חסר מצב אחד או יותר
7. כריכת נמל – שירותי ייצוא באמצעות כריכת נמל
8. במקביל - הגדל את האפליקציה שלך עם תהליכים
9. חד פעמיות - הגדל את האמינות עם הפעלה מהירה וכיבוי חינני
10. התאמה לפיתוח אפליקציות/תפעול - שמור על סביבות פיתוח, הבמה והפקה דומות ככל האפשר
11. רישום - התייחס ליומן כאל זרם של אירועים
12. משימות ניהול – ביצוע משימות ניהול/ניהול בתהליכים חד-פעמיים

למידע נוסף על 12 הגורמים, עיין במשאבים הבאים:

• מקור רשמי - חייב לקרוא
• מאמר על האבר. אפליקציית Twelve Factor - אפליקציית Twelve Factor - תרגום רשמי
• מאמר על האבר. 7 גורמים חסרים באפליקציית 12 הגורמים - מבט מחודש על 12 הגורמים על מנת לשפר אותם.

מהי פריסה כחול-ירוק?

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

ערכת BG Deploy הקלאסית נראית כמו התמונה למטה.

• בהתחלה יש 2 שרתים פיזיים עם אותו קוד, אפליקציה, פרויקט, ויש נתב (איזון).
• הנתב מפנה בתחילה את כל הבקשות לאחד השרתים (зеленый).
• ברגע שאתה צריך לעשות שחרור שוב, כל הפרויקט מתעדכן בשרת אחר (Синий), שאינו מטפל כעת בבקשות.
• אחרי הקוד עבור כָּחוֹל השרת מעודכן לחלוטין, הנתב מקבל פקודה לעבור ממנו ירוק על Синий שרת
• כעת כל הלקוחות רואים את התוצאה של הקוד עם כחול שרת.
• לכמה זמן, зеленый השרת משמש כגיבוי במקרה של פריסה לא מוצלחת ל Синий שרת ובמקרה של כשל ובאגים, הנתב מעביר את זרימת המשתמש חזרה אליו зеленый שרת עם הגרסה היציבה הישנה, ​​והקוד החדש נשלח לעדכון ובדיקה.
• ובסוף התהליך הוא מתעדכן באותו אופן зеленый שרת. ולאחר עדכון זה, הנתב מעביר את זרימת הבקשות חזרה ל зеленый שרת

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

עצה רעה וטובה

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

רוב הדוגמאות יצטלבו איכשהו עם פיתוח אתרים (איזו הפתעה), עם PHP ו-Docker.

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

1. בסיס קוד

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

לפרויקט תמיד צריך להיות בסיס קוד יחיד, כלומר כל הקוד מגיע מאחד Git מאגר. שרתים (ייצור, בימוי, test1, test2...) משתמשים בקוד מהענפים של מאגר אחד משותף. לפיכך, אנו משיגים עקביות קוד.

2. תלות

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

לפרויקט תמיד צריכה להיות רשימה מובנת בבירור של תלות (בהתלות, אני מתכוון גם לסביבה). כל התלות חייבות להיות מוגדרות ומבודדות במפורש.
כדוגמה, בואו ניקח מלחין и סַוָר.

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

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

3. תצורה

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

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

כלומר, גם אם תאחסן מספר קבצי תצורה .config.prod .config.local ותשנה את שמם בזמן הפריסה ל-.config (התצורה הראשית שממנה האפליקציה קוראת נתונים) - זו לא תהיה הגישה הנכונה, שכן במקרה זה המידע מהקונפיגורציות יהיה זמין לציבור לכל מפתחי האפליקציות והנתונים משרת הייצור ייפגעו. יש לאחסן את כל התצורות ישירות במערכת הפריסה (CI / CD) ולהפיק עבור סביבות שונות עם ערכים שונים הדרושים לסביבה מסוימת בזמן הפריסה.

4. שירותי צד שלישי (שירותי גיבוי)

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

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

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

5. לבנות, לשחרר, לרוץ

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

יש להפריד את כל שלבי הפריסה זה מזה.

יש הזדמנות לחזור אחורה. בצע מהדורות עם גישה מהירה לעותקים ישנים של האפליקציה (כבר מורכבת ומוכנה לקרב), על מנת לשחזר את הגרסה הישנה במקרה של שגיאות. כלומר, בתנאי שיש תיקיה משחרר ותיקיה נוֹכְחִי, ולאחר פריסה והרכבה מוצלחים, התיקיה נוֹכְחִי קשורה בקישור סמלי למהדורה החדשה שנמצאת בפנים משחרר עם השם המותנה של מספר השחרור.

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

6. תהליכים

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

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

7. כריכת נמל

רק שרת האינטרנט צריך לדעת איך לעבוד עם שירותי צד שלישי. ועדיף בדרך כלל להעלות שירותי צד שלישי ישירות בתוך שרת האינטרנט. לדוגמה, כמודול PHP ב- Apache.
כל השירותים שלכם חייבים להיות נגישים זה לזה באמצעות קריאה לכתובת כלשהי ויציאה (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), כלומר מ-nginx אני יכול לגשת גם ל-php-fpm וגם postgres, ומ-php-fpm ל-postgres ו-nginx, ומכל שירות עצמו, אני יכול לגשת לשירות אחר. לפיכך, בריאותו של שירות אינה קשורה לבריאותו של שירות אחר.

8. מקביליות

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

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

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

9. חד פעמיות

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

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

10. זוגיות פיתוח אפליקציות/תפעול

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

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

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

11. רישום (יומנים)

אנו כותבים יומנים לקבצים ולבסיס נתונים! אנחנו לא מנקים קבצים ומסד נתונים מיומנים. בואו פשוט נקנה כונן קשיח עבור 9000 Peta בייטים ונורמות.

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

12. משימות ניהול

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

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

דוגמה ליישום ב-PHP, Laravel, Laradock, Docker-Compose

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

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

docker -v && 
docker-compose -v

1. שמנו לאראדוק

git clone https://github.com/Laradock/laradock.git && 
ls

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

2. הגדרת Laradock כך שהאפליקציה שלנו תעבוד.

cd laradock && 
cp env-example .env

2.1. פתח את ספריית ה-habr (תיקיית האב שאליה משובטים לאראדוק) בכל עורך. (במקרה PHPStorm שלי)

בשלב זה, שמנו רק את שם הפרויקט.

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

היכנס לתוך המיכל עם

docker-compose up -d workspace && 
docker-compose exec workspace bash

2.3. התקנת Laravel

composer create-project --prefer-dist laravel/laravel application

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

ls
exit
docker-compose down

2.5. אנו חוזרים ל-PHPStorm ומגדירים את הנתיב הנכון לאפליקציית laravel שלנו בקובץ .env.

3. הוסף את כל הקוד ל-Git.

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

echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status

אנחנו בודקים אם הכל תקין.

מטעמי נוחות, אני ממליץ להשתמש בממשק ויזואלי כלשהו עבור Git, במקרה שלי זהו GitKraken. (קישור להפניה כאן)

4. השקה!

לפני שתתחיל, ודא שאין לך שום דבר תלוי ביציאות 80 ו-443.

docker-compose up -d nginx php-fpm

לפיכך, הפרויקט שלנו מורכב מ-3 שירותים נפרדים:

• nginx - שרת אינטרנט
• php-fpm - php לקבלת בקשות משרת אינטרנט
• סביבת עבודה - php למפתחים

כרגע, השגנו שיצרנו אפליקציה המקבילה ל-4 נקודות מתוך 12, כלומר:

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

2. תלות - כל התלות שלנו כתובה במפורש ב-application/composer.json ובכל Dockerfile של כל מיכל.

3. שירותי צד שלישי (שירותי גיבוי) - כל אחד מהשירותים (php-fom, nignx, workspace) חי את חייו ומחובר מבחוץ וכאשר עובדים עם שירות אחד, השני לא יושפע.

4. Процессы כל שירות הוא תהליך אחד. כל שירות אינו מאחסן מצב פנימי.

5. כריכת נמל

docker ps

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

6. במקביל

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

עצור מכולות והתחל אותן עם דגל --סוּלָם

docker-compose down && 
docker-compose up -d --scale php-fpm=3 nginx php-fpm

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

7. חד פעמיות - ניתן להרוג כל מיכל מבלי לפגוע בשני. עצירה או הפעלה מחדש של המכולה לא תשפיע על פעולת האפליקציה בהשקות הבאות. ניתן גם להרים כל מיכל בכל עת.

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

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

 docker-compose logs -f

אבל, יש ליקוי בכך שערכי ברירת המחדל ב-PHP וב-Nginx כותבים גם יומנים לקובץ. כדי לעמוד ב-12 הגורמים, אתה צריך להתנתק כתיבת יומנים לקובץ בתצורות של כל מיכל בנפרד.

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

10. משימות ניהול - כל משימות הניהול נפתרות על ידי laravel הודות לכלי האומן בדיוק כפי שירצו היוצרים של יישום 12 הגורמים.

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

 
docker-compose exec workspace bash
php artisan list

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

11. תצורות ו- 12. לבנות, לשחרר, לרוץ

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

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

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

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

קוד האפליקציה פועל GitHub.
אל תשכח לאתחל את תת-מודול בעת שיבוט המאגר הזה.

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

מקור: www.habr.com