איך אתם מתייחסים לpackage managers און ליין?

[user32]

יש לנו תהליכי בילד די מורכבים שתלויים בהרבה repositories חיצוניים. בניה של דוקרים וכאלה. כחלק מהCI/CD ומטבע הדברים, כל דחיפת שינוי לגרסה בונה חבילות שתלויות בחבילות חיצוניות שיורדות מהרשת ממקורות שונים: apt, npmjs, maven, pip, דוקרים images ציבוריים, ועוד כמה מקורות שעדיף שלא אפרט מרוב שהם ישנים ולא מוכרים.
אתמול נפל איזשהו שירות לכמה שעות. למעשה "נפל" זו לא הגדרה הכי טובה. התעודת SSL שלהם פגה תוקף ולכן כמובן שההורדות האוטומטיות נכשלו.
זה לא היה קריטי במקרה זה כי היה מדובר אצלינו בעדכון גרסה לטסט. אבל חשבתי על זה שבמשך כמה שעות היינו למעשה בלי יכולת לשחרר שינויים בכלל. האם זה סביר שבעידן המודרני נמצא את עצמנו תלויים לגמרי בחסדיהם של 7-8 ארגונים/שרתים שאפשר להגדיר "קהילתיים"?
מה עושים אצלכם? חלק ממנהלי החבילות נתמכים בקלות יחסית בrepos פרטיים (שצריך כמובן להקים ולתחזק) ואחרים ובמיוחד הארכאיים שבהם כנראה יהיה מסובך לתמוך.

 

[BravoMan]

לא יודע אם סביר, אבל בהחלט מקובל.
זכור לי שפעם אחרונה ש-FB נפל לכמה שעות, היו חברות שלא יכלו להכניס אנשים לחדרי ישיבות שלהם, כי מישהו החליט לשים את המנעולים על מערכת שמשתמשת ב-Facebook ID.

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

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

אני מסכים עם venney - קאש מקומי יכול לפתור הרבה צרות.
"supply chain attacks" התפתחו בשנים האחרונות, אז אפילו כששירות מאגרים חיצוני לא נופל, עדיף לא להסתמך עליו בכל פעם שמריצים build.

עריכה:
ראיתי עכשיו שכתבת שאתם בונים בענן.
לא יודע איזה סדר גודל מערכת מדובר, אצלנו גם מה שדורש build server נבנה תמיד In house.

אז לא יודע מה להמליץ לך, אבל להחצין בניה זה לא סיכון בפני עצמו?

 

[user32]

רוב רובם של תהליכי הpipeline היום של CI/CD רצים בענן. לפחות הכלים של AWS ו Azure. הכלים האלה בדרך כלל מרימים מכונה (דוקר, VM, למשתמש זה שקוף) מריצים עליה את כל התהליכים כולל ההורדה של הספריות המדוברות ואז פוף זה נעלם.
במקרה הצורך תמיד יש אפשרות לעשות דברים ידנית. למשל לקחת את הגרסה האחרונה שנוצרה ונשמרה איפשהו (בדרך כלל זה נדחף לאיזה registry או הסטוריה כזה או אחר). אפשר להוריד אותה ידנית ולערוך אותה, או לדחוף אותה מחדש או כל דבר כזה.

 

[vinney]

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

 

[user32]

כן חשבתי לעשות קש מקומי. זו בדיוק השאלה. מי עושה את זה ועד כמה? זה המון טרחה, חבילות שנבנות בpipelines בענן עם כלים אוטומטיים וכאמור 6-7 מערכות ניהול חבילות שונות שאין קשר ביניהם וכל אחת תדרוש כנראה די הרבה עבודה כדי שזה יתמוך בהתקנה מקומית.
לשאלתך, יש סטנדרט מקובל בענף שנקרא versioning. אז אם אני מבקש את חבילת zoomzoom 1.4.2 כנראה שזו הגרסה שאני אקבל ומוסכם על מפיצי החבילות שלא מעלים קוד לגרסה קיימת אלא משחררים גרסה חדשה. חלק ממערכות ההפצה אף אוכפות זאת ולא מאפשרים לפרסם קוד תחת גרסה קיימת. לפחות אצלינו אם היינו מעדכנים גרסאות חדשות שרירותית הכל היה נשבר בשניה.

 

[חזי2003]

אצלנו, מסיבות אבטחה אכן מחזיקים קש מקומי. ככה, גם אם פרצו לשרת והחליפו את החבילה הנוכחית בגרסה זדונית, לא נקבל אותה אוטומטית, אלא את הגרסה הבדוקה. צמצום אפשרויות של supply chain attack. אם אני מבין נכון, הרעיון הוא שבשדרוג גרסה של חבילה היא עוברת כל מיני security analysis כחלק מה-CI pipeline שמנהל את העדכון, מריץ בילד וטסטים ואם הכול בסדר - מעלה את החבילה לקש הפנימי שלנו

 

[user32]

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

 

[Be1n]

סתם שאלה של גוניור: אי אפשר לעשות אימג מותאם של דוקר, ולעלות אותו ל docker hub?

(ואז שאתה מרים מכונה, פשוט למשוך את האימג ולהריץ את הקונטיינר)

 

[user32]

סתם שאלה של גוניור: אי אפשר לעשות אימג מותאם של דוקר, ולעלות אותו ל docker hub?

(ואז שאתה מרים מכונה, פשוט למשוך את האימג ולהריץ את הקונטיינר)

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

 

[Be1n]

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

אהא, הייתי משוכנע שזה חוסך את הבנייה. (הכוונה היא שבנית את האימג ואז עשית push לregistry)
צריך לקרוא על זה שוב.

טנקס!