חנות פרמטרים AWS לעומת משתנים סביבתיים

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

מקרה למשתני סביבה

קל להתקנה

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

npm התקן dotenv

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

דורש ('dotenv'). config ()

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

תוכל למצוא מידע נוסף על מודול dotenv כאן:

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

  • אתה זקוק לגישה לחשבון AWS
  • אתה צריך לדעת לנווט בלוח המחוונים של AWS - במיוחד את החלק SSM.
  • יש להצפין פרמטרים רגישים / מאובטחים באמצעות KMS - אשר כשלעצמו דורש הגדרה נוספת (https://aws.amazon.com/kms/)
  • בהתאם לצרכים שלך, יתכן שתזדקק לידע בתצורה של שירותי AWS אחרים כמו IAM ו- SSM כדי לגרום לחנות הפרמטרים לעבוד כראוי.
  • כל הפרמטרים מתארחים בענן המחייבים גישה תכנתית של IAM, מה שאומר שיש צורך בחיבור ללא הפרעה (יש לציין שניתן ליצור הגדרות מקומיות בהתאמה אישית עם משתנים מקומיים שניתן להשתמש בהם במקום משתני חנות פרמטרים בהתאם למצב - I למעשה יעודד גישה מסוג זה).

קל לעדכון במהלך פיתוח, פריסה ובדיקה

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

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

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

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

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

משתנים מסביב הם חופשיים לשימוש

למרות שחנות הפרמטרים של AWS אינה כוללת חיובים נוספים (https://aws.amazon.com/systems-manager/pricing), מבנה התמחור של אמזון עבור שירותים קשורים כמו KMS (https://aws.amazon.com/kms/pricing) ) יתחילו לעלות בעלויות נוספות בהתבסס על השימוש. מצד שני, שימוש במשתני סביבה הוא בחינם.

אז למה להחליף משתנים סביבתיים? : תיק לחנות הפרמטרים

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

ניתן לשתף משתני חנות פרמטרים בין פרויקטים מרובים

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

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

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

חנות פרמטרים יכולה להשתמש בבקרת גישה

השליטה הספציפית בגישה למשתמשים הופכת את שירות ה- IAM לאחת מהתכונות הגדולות ביותר של AWS, במיוחד כשמדובר בהתמודדות עם מידע שעשוי להיות רגיש כמו מפתחות API או סיסמאות. הרעיון של שליטה בגישה למשתני סביבה במובן הוניל (למשל באמצעות גישת הדוטנוב) הוא פשוט לא אפשרות (אלא אם כן אתה מוכן לפתח פיתרון מותאם אישית משלך - או לעבור מחוץ לתחום 'שיטות העבודה המומלצות').

ערכי פרמטרים בחנות מתעדכנים בקלות

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

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

KMS יכול להצפין ערכי חנות פרמטרים בקלות

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

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

ניתן לארגן משתני חנות פרמטרים

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

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

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

סיכום

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

אם יש לך גורמים אחרים שאתה מרגיש ששווה לקחת בחשבון הייתי רוצה לשמוע את מחשבותיך.