הגדרת Deno Deploy לאפליקציות Edge גלובליות: פריסה, CI/CD ו-KV

הגדרת Deno Deploy: מה נשבר בפריסה הראשונה

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

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

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

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

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

הגדרת סביבות: מה זה נותן מבחינת לוחות זמנים ואמינות

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

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

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

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

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

אפשרויות פריסה: השוואת גישות

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

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

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

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

סדר היישום: מביקורת ועד מסירה

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

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

1. ביקורת תשתית. אוספים דומיינים, מסלולים נוכחיים, משתני סביבה ותלויות בנייה; בנפרד מתעדים מה מחושב בזמן בנייה ומה בזמן עיבוד בקשה.
2. סכימת סביבות. מפרידים סביבת תצוגה מקדימה לכל ענף, סביבת בדיקות עם סט נתונים נפרד וסביבת ייצור; מתארים את הכללים לפיהם בקשה מגיעה לכל אחת מהן.
3. הגדרת סודות. מניחים מפתחות לפי תחומי נראות: מה שנדרש רק לקוד השרת לא נכנס לבניית הלקוח, והחלפת מפתח מתבצעת בלי להנפיק מחדש את האפליקציה.
4. מסלולים ומטמון. מקבעים מפת מסלולים, כללי מטמון לסטטי ולתגובות, התנהגות בעת כשל של האזור הקרוב.
5. בדיקה לפני פרסום. מריצים בנייה על תעבורת ייצור במצב שיקוף, משווים זמן תגובה לקודם, בודקים חזרה לגרסה קודמת.
6. מסירת תיעוד. מוסרים מפת סביבות, תקנון להחלפת סודות, רשימת תיוג לשחרור וחזרה עם ציון אחראים.

ערכת ארטיפקטים: תצורות, סכימות, תקנונים

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

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

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

ניתוח יישום: העברת שירות לקצה

מה היה לפני ההעברה

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

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

מה שינו ומה קיבלו

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

זמן השחרור הצטמצם מ-40–60 דקות ל-6–8 באותו היקף שינויים. שיעור החזרות שנפלו על הלילה ירד מ-70% לאפס: כעת החזרה מתבצעת ביום, אורכת עשרות שניות וכמעט אינה דורשת תורן.

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

במה שונה KV בקצה ממסד נתונים מרכזי?

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

ההבדל הוא прежде всего בעקביות. העתק בקצה מקבל כתיבה ומתפשט לנקודות הנוכחות לא באופן מיידי: הקורא הבא עשוי לראות את הערך הקודם, ופעולות על מספר מפתחות אינן נאספות לטרנזקציה אחת.

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

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

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

ספקות טכניים נפוצים לפני ההתחלה

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

מה יקרה אם צומת באזור אינו זמין?

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

כיצד לחזור מפרסום?

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

למי שייכות ההגדרות?

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

כיצד מועברת הגישה ומה נשאר אחרינו?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

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