הגדרת משתני סביבה

תוכן העניינים:

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

סיכום

בעיה

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

• כדי להשיג זאת, אנו רוצים להשתמש בהגדרת משתני סביבה.

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

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

החלטה

הוחלט על קובצי .env עם קובץ ברירות מחדל קשור וקובץ סכמה.

מצב

הוחלט. פתוחים לשקול יכולות חדשות כשיעלו.

פרטים

הנחות

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

אנו מעדיפים את נוהג התעשייה של "12 factor app" ועוד יותר את הנוהג הקשור של "15 factor app".

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

אילוצים

אנו רוצים להשאיר סודות מחוץ למערכת בקרת הגרסאות (VCS) של ניהול קוד המקור (SCM) שלנו.

אנו רוצים לשאוף לתאימות למסגרות וספריות תוכנה פופולריות. לדוגמה, ל-Node יש מודול "dotenv" לקריאת הגדרות משתני סביבה.

עמדות

שקלנו כמה גישות:

• לשמור את ההגדרות ביישום, למשל בקובץ config.js.

• לשמור את ההגדרות בסביבה, למשל בקובץ .env.

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

טיעון

בחרנו בגישה של קובץ .env כי:

• היא פופולרית, כולל בקרב מומחים.

• היא עוקבת אחר התבנית של קובצי .env שהצוותים שלנו השתמשו בהם בהצלחה פעמים רבות בפרויקטים רבים.

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

השלכות

עלינו למצוא דרך להפריד הגדרות משתני סביבה ציבוריות מכל ניהול סודות.

נושאים קשורים

החלטות קשורות

אנו מצפים שכל היישומים שלנו ישתמשו בגישה הזו.

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

נשאיר כפי שהוא כל יישום שלנו שמשתמש בגישה מסוגלת יותר, כמו שרת רישוי.

דרישות קשורות

נוסיף יכולות devops לקבצים, כולל hooks, בדיקות ואינטגרציה רציפה.

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

תוצרים קשורים

כל אזור שבו אנו פורסים יצטרך קובץ .env משלו וקבצים קשורים.

עקרונות קשורים

הפיך בקלות.

הערות

דוגמה לקובץ .env:

NAME=Alice Anderson
EMAIL=alice@example.com

דוגמה לקובץ .env.defaults:

NAME=Joe Doe
EMAIL=joe@example.com

דוגמה לקובץ .env.schema עם המפתחות בלבד:

NAME
EMAIL