ניהול Connection Strings ותצורה בין סביבות

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

מה יש בעצם בתוך Connection String

מבחינה טכנית, connection string הוא בעצם כתובת מובנית שמכילה את כל מה שצריך כדי להתחבר למסד נתונים ספציפי - כתובת השרת (host), הפורט, שם המשתמש והסיסמה, שם מסד הנתונים הספציפי בתוך השרת, ולפעמים גם פרמטרים נוספים כמו האם להשתמש בהצפנה (SSL) או כמה זמן לחכות לפני timeout. משהו כמו postgres://user:password@db.example.com:5432/mydb הוא בעצם כל הפרטים האלה, ארוזים במחרוזת אחת שהספרייה שמתחברת למסד הנתונים יודעת לפרסר.

למה אסור לקבע אותו בקוד

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

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

תצורה שונה לכל סביבה

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

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

סדר עדיפויות - מאיפה מגיע כל ערך

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

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

מחרוזת החיבור היא סוד, לא רק תצורה

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

לסיכום

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

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

הצטרפו לקהילה בדיסקורד