DEVOXX בריטניה. Kubernetes בייצור: פריסה כחול/ירוק, קנה מידה אוטומטי ואוטומציה של פריסה. חלק 2

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

בעוד של-Kubernetes אין את התכונות האלה מהקופסה, היא מספקת ממשק API שבו אתה יכול להשתמש כדי לפתור בעיות דומות. כלים לפריסה אוטומטית של כחול/ירוק ושינוי קנה מידה של אשכול Kubernetes פותחו כחלק מפרויקט Cloud RTI, שנוצר על בסיס קוד פתוח.

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

DEVOXX בריטניה. Kubernetes בייצור: פריסה כחול/ירוק, קנה מידה אוטומטי ואוטומציה של פריסה. חלק 1

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

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

זהו REST, אז אתה יכול להשתמש בכל שפה או כלי כדי לעבוד עם ה-API הזה, אבל החיים שלך יהפכו להרבה יותר קלים על ידי ספריות מותאמות אישית. הצוות שלי כתב 2 ספריות כאלה: אחת עבור Java/OSGi ואחת עבור Go. השני לא משמש לעתים קרובות, אבל בכל מקרה יש לך את הדברים השימושיים האלה לרשותך. הם פרויקט קוד פתוח ברישיון חלקי. יש הרבה ספריות כאלה לשפות שונות, אז אתה יכול לבחור את אלה שמתאימות לך ביותר.

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

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

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

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

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

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

לאחר שהמערכת תוודא שכל העתקים המעודכנים פועלים, Deployer יעדכן את התצורה ויעביר את ה-confd הנכון, אשר יגדיר מחדש את ha-proxy.

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

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

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

אז, הדבר הראשון שה Deployer עושה הוא ליצור בקר שכפול RC באמצעות ה-API של Kubernetes. API זה יוצר פודים ושירותים לפריסה נוספת, כלומר, הוא יוצר אשכול חדש לחלוטין עבור היישומים שלנו. ברגע ש-RC ישתכנע שהעותקים החלו, הוא יבצע בדיקת בריאות לפונקציונליות שלהם. לשם כך, Deployer משתמש בפקודה GET /health. הוא מריץ את רכיבי הסריקה המתאימים ובודק את כל האלמנטים התומכים בפעולת האשכול.

לאחר שכל הפודים דיווחו על תקינותם, Deployer יוצר רכיב תצורה חדש - etcd distributed storage, המשמש באופן פנימי על ידי Kubernetes, כולל אחסון תצורת איזון העומס. אנו כותבים נתונים ל-etcd, וכלי קטן שנקרא confd monitors etcd עבור נתונים חדשים.

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

כפי שאתה יכול לראות, למרות שפע הרכיבים, אין כאן שום דבר מסובך. אתה רק צריך לשים לב יותר ל-API וכו'. אני רוצה לספר לכם על מפריס הקוד הפתוח שאנו עצמנו משתמשים בו - Amdatu Kubernetes Deployer.

זהו כלי לתזמור פריסות Kubernetes ויש לו את התכונות הבאות:

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

Deployer זה בנוי על גבי Kubernetes API ומספק REST API לניהול נקודות עזר ופריסה, כמו גם Websocket API להזרמת יומנים במהלך תהליך הפריסה.

זה מכניס את נתוני תצורת מאזן העומס לתוך וכו', כך שלא תצטרך להשתמש ב-ha-proxy עם תמיכה מהקופסה, אלא להשתמש בקלות בקובץ תצורת מאזן העומס שלך. Amdatu Deployer כתוב ב-Go, כמו Kubernetes עצמו, והוא מורשה על ידי Apache.

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

אחד הפרמטרים החשובים של קוד זה הוא הפעלת הדגל "useHealthCheck". עלינו לציין כי יש לבצע בדיקת שפיות במהלך תהליך הפריסה. ניתן להשבית הגדרה זו כאשר הפריסה משתמשת בקונטיינרים של צד שלישי שאין צורך לאמתם. מתאר זה מציין גם את מספר ההעתקים וכתובת ה-URL של החזית ש-ha-proxy צריך. בסוף דגל מפרט התרמיל "podspec", הקורא ל-Kubernetes לקבלת מידע על תצורת יציאה, תמונה וכו'. זהו מתאר JSON פשוט למדי.

כלי נוסף שהוא חלק מפרויקט Amdatu בקוד פתוח הוא Deploymentctl. יש לו ממשק משתמש להגדרת פריסות, מאחסן היסטוריית פריסה ומכיל webhooks להתקשרות חוזרת ממשתמשים ומפתחים של צד שלישי. אתה לא יכול להשתמש בממשק המשתמש מאחר Amdatu Deployer עצמו הוא REST API, אבל ממשק זה יכול להקל עליך את הפריסה מבלי לערב אף API. Deploymentctl נכתב ב-OSGi/Vertx באמצעות Angular 2.

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

כאן אנו יוצרים שרת HTTP שמגיב רק ל-/health, כך שהאפליקציה הזו בודקת רק את בדיקת הבריאות ולא שום דבר אחר. אם הבדיקה עוברת, נעשה שימוש במבנה ה-JSON המוצג להלן. הוא מכיל את גרסת האפליקציה שתפרוס על ידי המפייס, את ההודעה שאתה רואה בראש הקובץ וסוג הנתונים הבוליאניים - בין אם האפליקציה שלנו פועלת או לא.

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

אז בואו נתחיל. ראשית, אנו בודקים את נוכחותם של פודים פועלים באמצעות הפקודה ~ kubectl get pods, ועל סמך היעדר תגובה מכתובת ה-frontend, אנו מוודאים שלא מתבצעות כעת פריסות.

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

אם תחזור כעת על הפקודה ~ kubectl get pods, תוכל לראות שהמערכת "קופאת" למשך 20 שניות, שבמהלכן ה-ha-proxy מוגדר מחדש. לאחר מכן, הפוד מתחיל, וניתן לראות את העתק שלנו ביומן הפריסה.

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

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

הפקודה ~ kubectl get pods מראה שיש כרגע 2 גרסאות של האפליקציה שפועלות, אבל החזית מראה שאנחנו עדיין מריצים את גרסה 1.

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

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

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

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

יש רק דבר אחד שיכול להיכשל - אם בדיקת הבריאות תצליח, אבל האפליקציה נכשלת ברגע שהופעל עליה עומס העבודה, כלומר, הקריסה תתרחש רק לאחר השלמת הפריסה. במקרה זה, תצטרך לחזור ידנית לגרסה הישנה. אז, בדקנו כיצד להשתמש ב-Kubernetes עם כלי הקוד הפתוח המיועדים לכך. תהליך הפריסה יהיה הרבה יותר קל אם תבנה את הכלים האלה לתוך צינורות ה-Build/Deploy שלך. במקביל, כדי להתחיל בפריסה, אתה יכול להשתמש בממשק המשתמש או להפוך את התהליך הזה לאוטומטי על ידי שימוש, למשל, ב-commit to master.

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

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

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

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

אז נצטרך לטפל גם בצמתים וגם בתרמילים. אנו יכולים להתאים בקלות את ההשקה של צמתים חדשים באמצעות AWS API ומכונות קבוצת קנה מידה כדי להגדיר את מספר צמתי העבודה של Kubernetes. אתה יכול גם להשתמש ב-cloud-init או בסקריפט דומה כדי לרשום צמתים באשכול Kubernetes.

המכשיר החדש מתחיל בקבוצת Scaling, יוזם את עצמו כצומת, נרשם ברישום המאסטר ומתחיל לעבוד. לאחר מכן, אתה יכול להגדיל את מספר העתקים לשימוש בצמתים המתקבלים. הקטנה דורשת יותר מאמץ, שכן עליך לוודא שצעד כזה לא יוביל להרס של יישומים שכבר פועלים לאחר כיבוי מכונות "מיותרות". כדי למנוע תרחיש כזה, עליך להגדיר את הצמתים למצב "לא ניתן לתזמון". המשמעות היא שמתזמן ברירת המחדל יתעלם מצמתים אלה בעת תזמון תרמילים של DaemonSet. המתזמן לא ימחק שום דבר מהשרתים האלה, אבל גם לא ישיק שם קונטיינרים חדשים. השלב הבא הוא להדיח את צומת הניקוז, כלומר להעביר ממנו תרמילים פועלים למכונה אחרת, או לצמתים אחרים שיש להם קיבולת מספקת לכך. לאחר שווידאתם שאין עוד מיכלים על הצמתים הללו, תוכלו להסיר אותם מ-Kubernetes. אחרי זה, הם פשוט יפסיקו להתקיים עבור Kubernetes. לאחר מכן, עליך להשתמש ב-AWS API כדי להשבית צמתים או מכונות מיותרות.
אתה יכול להשתמש ב- Amdatu Scalerd, כלי קנה מידה נוסף בקוד פתוח הדומה ל-AWS API. הוא מספק CLI להוספה או הסרה של צמתים באשכול. התכונה המעניינת שלו היא היכולת להגדיר את מתזמן באמצעות קובץ ה-json הבא.

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

אני רוצה לציין שאנשים רבים אומרים לי, "זה הכל טוב ויפה, אבל מה עם מסד הנתונים שלי, שהוא בדרך כלל סטטי?" איך אתה יכול להריץ דבר כזה בסביבה דינמית כמו Kubernetes? לדעתי, לא כדאי לעשות את זה, לא לנסות להפעיל מחסן נתונים ב-Kubernetes. זה אפשרי מבחינה טכנית, ויש מדריכים באינטרנט בנושא זה, אבל זה יסבך את החיים שלך ברצינות.

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

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

הייתה שאלה מדוע להשתמש במאזן העומס של ha-proxy עם Kubernetes. שאלה טובה כי יש כרגע 2 רמות של איזון עומסים. שירותי Kubernetes עדיין נמצאים על כתובות IP וירטואליות. אתה לא יכול להשתמש בהם עבור יציאות במכונות מארח חיצוניות מכיוון שאם אמזון תעמיס על המארח הענן שלה, הכתובת תשתנה. זו הסיבה שאנו מציבים את ha-proxy מול השירותים - כדי ליצור מבנה סטטי יותר לתנועה שתתקשר בצורה חלקה עם Kubernetes.

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

כמה מודעות 🙂

תודה שנשארת איתנו. האם אתה אוהב את המאמרים שלנו? רוצים לראות עוד תוכן מעניין? תמכו בנו על ידי ביצוע הזמנה או המלצה לחברים, Cloud VPS למפתחים החל מ-$4.99, אנלוגי ייחודי של שרתים ברמת הכניסה, שהומצא על ידינו עבורכם: כל האמת על VPS (KVM) E5-2697 v3 (6 ליבות) 10GB DDR4 480GB SSD 1Gbps החל מ-$19 או איך לשתף שרת? (זמין עם RAID1 ו-RAID10, עד 24 ליבות ועד 40GB DDR4).

Dell R730xd זול פי 2 במרכז הנתונים Equinix Tier IV באמסטרדם? רק כאן 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV החל מ-$199 בהולנד! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - החל מ-$99! לקרוא על כיצד לבנות תשתיות קורפ. מחלקה עם שימוש בשרתי Dell R730xd E5-2650 v4 בשווי 9000 יורו עבור אגורה?

מקור: www.habr.com