הגדרת קונטיינר Docker עבור בוט מסחר

למה בוט מסחר נופל בלילה: Docker ומשאבים

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

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

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

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

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

מה נותנת קונטיינריזציה של בוט מסחר על שרת

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

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

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

סביבה זהה בבדיקות ובייצור

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

בידוד: כמה אסטרטגיות על שרת אחד

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

חזרה לגרסה קודמת באופן צפוי

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

אפשרויות פריסה: Docker, שירות מערכת ההפעלה, ענן

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

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

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

איך אנחנו מגדירים קונטיינר Docker לבוט מסחר

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

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

1. ביקורת של ההרצה הנוכחית. בודקים איך הבוט עולה היום, איפה נשמרים המפתחות, מה קורה להזמנות פתוחות בנפילה ולאן נכתבים הלוגים. מתעדים תלויות ונקודות כשל — זה הבסיס לסכמת הסביבה.
2. סכמת הסביבה. קובעים אילו שירותים נדרשים לבוט לצידו: גישה ל-API המסחר, מסד עסקאות, מטמון. מפרידים מה נכנס לאימג', מה נטען כ-volume ומה חי ברשת משותפת ושורד בנייה מחדש.
3. בניית האימג'. התלויות מקובעות במניפסט, הבוט עובד תחת משתמש לא־פריווילגי. הלוגים נכתבים לזרם משותף עם רוטציה — מערכת הלוגים אוספת אותם, ושום דבר לא הולך לאיבוד בהפעלה מחדש.
4. מגבלות משאבים ומדיניות הפעלה מחדש. מגדירים מגבלות זיכרון ומעבד, בדיקת חיות וסיום תקין לפי אות: הקונטיינר סוגר את החיבור לבורסה ולא משאיר הזמנות «תלויות». מדיניות ההפעלה מחדש מרימה את הבוט אחרי תקלה באופן אוטומטי.
5. סודות ומפתחות גישה. המפתחות לא נכנסים לא לאימג' ולא למאגר — הם נטענים לזמן העבודה עם הרשאות מוגבלות, בנפרד למסלול הבדיקות ולמסלול הייצור. רוטציה של מפתח לא מחייבת בנייה מחדש.
6. בדיקה על שוק בדיקות ומסירה. מריצים את הבוט עם מפתחות בדיקה, מנתחים את הלוגים לפי מחזורי עסקאות, מתעדים את פקודות הניהול ומוסרים תיעוד עם הדרכת הצוות.

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

מה נשאר אצלכם אחרי הגדרת הקונטיינר

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

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

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

מקרה בוחן: בוט על Docker הפסיק ליפול בשעות תנודתיות

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

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

מה שינו

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

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

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

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

במה נבדל קונטיינר ממכונה וירטואלית עבור בוט?

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

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

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

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

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

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

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

סיכונים ומגבלות של קונטיינר: שאלות נפוצות

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

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

איך נשמרים מפתחות הגישה לבורסה?

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

אפשר להעביר בוט פועל בלי השבתה?

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

מי אחראי על עדכון האימג'?

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

נדבר על המשימה: ביקורת בוט ותוכנית העברה

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

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

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