האבולוציה של כלי משלוח, או מחשבות על Docker, deb, jar ועוד

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

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

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

אז, בימים הטובים... שיטת המסירה המוקדמת ביותר שמצאתי הייתה קלטות מקלטות. היה לי מחשב BK-0010.01...

עידן המחשבונים

לא, היה רגע מוקדם עוד יותר, היה גם מחשבון MK-61 и MK-52.

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

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

גודל התוכנית הגדולה ביותר במחשבון היה 105 צעדים, וגודל הזיכרון הקבוע ב-MK-52 היה 512 צעדים.

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

• אמולטור MK-61 לאנדרואיד
• קטלוג תוכניות עבור MK-61

סטייה קצרה על MK-52 (מתוך ויקיפדיה)

MK-52 טס לחלל בחללית סויוז TM-7. זה היה אמור לשמש לחישוב מסלול הנחיתה למקרה שהמחשב המובנה יכשל.

מאז 52, ה-MK-1988 עם יחידת הרחבת הזיכרון Elektronika-Astro מסופק לספינות חיל הים כחלק מערכת מחשוב ניווט.

המחשבים האישיים הראשונים

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

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

הופעתם של אמצעי אחסון אמינים וגדולים

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

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

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

באותה תקופה, קיומה של לינוקס עדיין לא היה פתוח בפניי; חייתי בעולם של MS DOS ומאוחר יותר Windows, וכתבתי בבורלנד פסקל ובדלפי, לפעמים הסתכלתי לעבר C++. אנשים רבים השתמשו ב-InstallShield כדי לספק מוצרים אז. ru.wikipedia.org/wiki/InstallShield, אשר פתר בהצלחה רבה את כל המשימות שהוקצו של פריסה והגדרת התוכנה.

עידן האינטרנט

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

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

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

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

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

חבילות RPM ו-DEB

מצד שני, עם התפתחות האינטרנט, מערכות דמויות UNIX החלו לצבור יותר ויותר פופולריות, במיוחד באותה תקופה גיליתי את RedHat Linux 6, בערך 2000. כמובן, היו גם אמצעים מסוימים לאספקת תוכנה; לפי ויקיפדיה, RPM כמנהל החבילות הראשי הופיע כבר ב-1995, בגרסת RedHat Linux 2.0. ומאז ועד היום, המערכת נמסרה בצורה של חבילות RPM והיא קיימת ומתפתחת בהצלחה רבה.

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

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

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

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

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

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

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

תסריטים בכתב עצמי

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

אבל לתסריטים יש כמה חסרונות:

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

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

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

סַוָר

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

באילו אי נוחות נתקלנו?

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

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

כפי שהראה בפועל, במציאות זה לא הכרחי, חבילת deb מספיקה ב-90% מהמקרים.

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

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

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

הצמד חבילות

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

כתוצאה מכך, אנו משתמשים כעת גם בחבילות deb וגם במכולות docker בשילוב סביר, שאולי, במקרים מסוימים, נחליף בחבילות snap.

רק משתמשים רשומים יכולים להשתתף בסקר. להתחברבבקשה.

במה אתה משתמש למשלוח?

• תסריטים בכתב עצמי

• העתק ידנית ל-FTP

• חבילות deb

• חבילות סל"ד

• חבילות הצמד

• דוקר-תמונות

• תמונות של מכונות וירטואליות

• שכפל את כל הדיסק הקשיח

• בובות

• ansible

• אחר

109 משתמשים הצביעו. 32 משתמשים נמנעו.

מקור: www.habr.com