מסכת פריסה

ניהול סביבות

5 הלכות

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

ודרשו חכמים: קוד שמכיל סיסמה — כבר אינו קוד, אלא פצצה מתקתקת. השתמש ב-.env, ב-secrets manager, בכל דבר — רק לא ב-hardcode.

production אינו development. מה שעובד אצלך — לא בהכרח עובד שם. "אצלי זה עבד" — אינה טענה.

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

מחלוקת

רבי דוקר המיכל אומר:

הפתרון לבעיית "אצלי זה עבד" הוא container. Docker מבטיח שהסביבה זהה בכל מקום — מחשב המפתח, CI, וייצור.

רבי סביבה הוירטואלית חולק ואומר:

Docker מוסיף מורכבות עצומה. environment variables, staging server, ו-parity טוב — מספיקים לרוב הפרויקטים. אל תורה תותח על זבוב.

רבי דוקר המיכל:

environment variables אינם מספיקים. גרסת Node, גרסת OS, syscall behavior — הכל שונה.

רבי סביבה הוירטואלית:

ומשך הלמידה? ה-overhead? startup time? לא לכל פרויקט מתאים Docker.

פרויקט קטן — parity טוב מספיק. פרויקט גדול עם צוות — Docker הוא כמעט חובה.

סביבת staging חייבת להיות מראה של production. staging עם DB ריק ו-config שונה — אינה staging, אלא אשליה.

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

אסור לסיסמאות ולמפתחות להופיע ב-logs. המדפיס secrets ל-log — חייב להתחשב בכל מי שיקרא אי פעם את אותו log.

logs נשמרים, logs מועברים, logs נקראים. ומעשה היה בחברה שהדפיסה token ב-debug log — ויגנוב הגנב, ויפרוץ, ולא ידעו מאין. בדוק את ה-logs שלך לפני שאתה מפרס.

לכל סביבה — .env משלה. אסור לשתף קובץ .env בין development ו-production, ואסור לשלוח .env בוואטסאפ.

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