כמה מילים לגבי שדרוג ל-RHEL-7/CENTOS-7

בשבועות האחרונים מאז יצאה RHEL-7 לשוק ואחריה CentOS-7, שוחחתי עם מספר עמיתים ולקוחות לגבי התקנה של המערכת. שמעתי מאותם אנשים המון תסכול, עצבים על דברים שהשתנו וגם תכנונים לא נכונים להטמעה של המערכת ההפעלה הנ"ל (אני אתייחס אל RHEL/CENTOS כאחת לשם מאמר זה).

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

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

ניקח לדוגמא את מערכת SystemD, זו מערכת חדשה שמחליפה את SysV הישנה שהיתה עד כה בהפצות לינוקס. ב-RHEL-7 אין יותר SysV ואי אפשר במחי פקודת yum להעיף את systemd, היא משובצת לאורך ולרוחב ההפצעה, מה-Boot ועד ה-Login ונוגעת בכל החלקים, כולל שרותים (Services), לוגים וכו'. כל פורום לינוקס רציני שתבקרו בו, תמצאו ויכוחים ופיצוצים בעד ונגד SystemD, ואפשר למצוא בכל מיני מקומות "בעד" ו"נגד" כאשר אנשי יוניקס ותיקים רוקעים ברגליים ורוצים את Sys V init בחזרה ולעומתם רבים אחרים מסבירים את יתרונות ה-SystemD (כאן לדוגמא). הסיבה העיקרית שרד האט (ולאחרונה גם הפצות אחרות כמו אובונטו הבא) עוברים ל-SystemD זה התמודדות עם הצרכים של היום שלא היו בעבר. כיום יש מספיק מקרים שבהם אתה מכניס ציוד בצורה "חמה" (כלומר ללא כיבוי והפעלה) ובמקרים של שרתים יקרים מאוד גם ציוד שבעבר לא היה ניתן להכניס בצורה חמה כמו מעבדים, זכרונות, והתקנים נוספים (גם כרטיסי PCI-E), ומערכות Sys V init שהיו צריכות סקריפטים מסובכים ו-1001 ספריות ו-daemons שונים כדי להתמודד עם זה – הכל הוחלף ב-SystemD. יש לו Journal (מערכת לוגים משולבת) שנותנת לך לראות בפקודה אחת פשוטה סטטוס יותר מפורט של שרות, אם הוא לא עלה, מדוע הוא לא עלה – מבלי שתשב ותכתוב תוך כמה דקות/שעות (תלוי בכשרון שלך) משהו שינפה את הפלט של dmesg או var/log/messages/ או קבצי לוג אחרים.

ב-RHEL-7 (וכמובן CentOS-7), בשונה מגרסאות לינוקס ל-Enterprise הכל השתנה, החל מה-Kernel שהוא גירסה 3 (בעבר 2.6), המשך ב-Boot (כיום GRUB-2 a שהוא הרבה הרבה יותר מורכב מה-GRUB הראשון), דרך שפות פיתוח, ממשק גרפי, טיפול בציודים, הגדרות רשת, דיסקים, File System וכו', מה שאומר שאם תיקח שרת שרץ עליו RHEL-6 ותעביר אותו לגירסה 7, יש סיכוי רב שחלק מהדברים לא יעבוד או שהמכונה אפילו לא תעלה (כבר יצא לי לראות שרת שמישהו החליט שזה רעיון מעולה לשדרג אותו דרך YUM מ-CentOS 6.1 ל-7 ובסופו של דבר נשאר שרת יקר אבל שלא מצליח לעשות אפילו Boot).

RHEL-7 לפיכך אינו מתאים לשדרוג דרך YUM או דרך בחירת "שדרוג" כשעושים BOOT ל-ISO. במילים אחרות אל תסמכו על ה"שדרוג" הזה. הוא בהחלט ישדרג את קבצי ה-RPM, אבל יש מספיק דברים שהשתנו לגמרי בין 6.5 ל-7. סתם דוגמא: מריצים שרת Apache? מריצים מודולים שקימפלתם? תתפלאו – ב-RHEL-7 האפאצ'י הוא גירסה 2.4 ומודולים רבים לא מצליחים להתקמפל מולו, וחלק מהמודולים האחרים מתקמפלים אבל נופלים בעת העלאת שרות ה-Apache. כיף!

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

  • תחנות Desktop/Workstations שמריצים תוכנות סגורות (שרטוט תלת מימד, קומפיילרים קנייניים, תוכנות IDE קנויות וכו') – לא לשדרג כרגע ל-7. תוכנות סגורות רבות עדיין אינן מתאימות לגירסה 7. אגב, שדרוג לגירסה 6.6 יצא בקרוב, אם בא לכם, אתם יכולים לשחק עם ה-Beta כאן.
  • תחנת שמריצות דברים בקוד פתוח – מומלץ להרים מכונות VM נסיוניות (לא שדרוג) עם האפליקציות ולתת למפתחים לשחק עם זה כמה ימים כדי לראות מה פעיל ומה שבור.
  • שרתים – גם כאן, אני ממליץ להרים מכונת VM ריקה עם RHEL-7 ולהתקין עליה את האפליקציות ולראות מה עובד ומה לא עובד. מצאתם שהכל עובד? אל תשדרגו עם הכלים של רד-האט, עדיף שתפרמטו ותתקינו מחדש, ועל כך תיכף ארחיב.
  • מכונות קומפילציות, Hadoop ושאר דברים יעודיים – נסו עם מספר מכונות VM להרים חווה קטנטנה כדי לראות שהכל עובד, כולל Stress Testing. קצת אחרי ששוחררה RHEL-7 היה באג רציני שתוקן באחד העדכונים.

כפי שציינתי לעיל, בשדרוגים יש סיכוי גבוה שמעבר מ-6.5 ל-7 (או גירסה מוקדמת יותר ל-7) דברים ישברו מבחינת סימנים (Symbols), תאימות בינארית (צורך בהתקנת compat למיניהם) ולכן אני ממליץ להקים את המכונה מחדש. לשמור את כל ה-DATA בנפרד ולהתחיל התקנה מחדש (ובהזדמנות להתחיל לחשוב על שימוש יותר מאסיבי עם Kickstart למי ש…אהממ… עדיין עובד עם ה-ISO). ישנם מערכות File Systems חדשות ויותר יציבות שיודעות לטפל בכמות הרבה יותר גדולה של קבצים – כמו XFS של סיליקון גרפיקס (בברירת מחדל אם לא תגדיר ידנית, RHEL תפרמט את הדיסק שלך ב-XFS). ה-LVM עבר שיפור (בבקשה, בבקשה, חדל מההתקנה של כל מערכת ההפעלה יחד עם הקבצים של המשתמש וה-SWAP הכל תחת Partition יחיד!), אם אתם משתמשים בחברה ב-Active Directory אז תוכלו ישירות מההתקנה להגדיר חיבור לדומיין ואת המשתמשים, וישנם שיפורים רבים נוספים, ובכלל, מומלץ לקרוא לעומק את ה-Installation Guide.

אם אתם הולכים להתקין את ההפצה על וירטואליזציה כמו HyperV או ESXI, אז אני שמח להודיעכם שאין צורך להתקין שום תוספים (ולא, גם לא VMWare Tools). הכל מגיע עם ההפצה בהתקנה רגילה, כך שאינכם צריכים להתקין כלום. למשתמשי HyperV – הבאג המעצבן של NFS עם NetApp על CentOS (המתנה של כמה עשרות שניות בין פקודה לפקודה) – תוקן ע"י רד-האט בתוך ההפצה. משתמשי ESXI – אתם תראו שה-TOOLS מופיעים כ-3rd Party, זה בסדר, הכלי שמותקן בפנים ושמפעיל vmtoolsd נעשה בשיתוף המהנדסים של VMWare.

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

לסיכום: כן, דברים השתנו לחלוטין בגירסה 7, אבל מה לעשות, דברים משתנים וטכנולוגיות והגדרות משתנות. אי אפשר להישאר כל הזמן בעבר. הטכנולוגיה היום דורשת פתרונות יותר דינמיים, הצרכים משתנים והפתרונות גם. נכון, לסקריפטולוגים מביניכם שקיצרו את העבודה היום יומית שלהם לפקודות של 3-4 אותיות תהיה קצת עבודה לשנות את הסקריפטים (לחובבי פייתון – הגירסת ברירת מחדל עכשיו היא 2.7 עדיין, אבל זו הגירסה האחרונה שתתן אותו כברירת מחדל. הגירסה הבאה תקפוץ ישר ל-3.4 או מה שיהיה אז), אבל מבחינת SystemD עדיין סקריפטים שמשתמשים ב-chkconfig, service וכו' יוכלו לרוץ, תסתכלו במסמך הזה אך יחד עם זאת, תתחילו להכין את הסקריפטים שלכם ל-SystemD. לא לשכוח גם להוסיף את ה-REPO הזה.

בהצלחה

ושוב מנסים למכור שמן נחשים

בתחילת השבוע (27/7) החלה התקפת DDoS רצינית על בזק בינ"ל, מה שגרם לכך שאתרים כמו "וואלה" לא הגיבו אפילו לרמה של DNS Resolve ללקוחות בזק בינ"ל ולספקים נסמכים (018, אינטרנט רימון ואחרים). בזק בינלאומי לא היו היחידים שמותקפים חזק (אם כי הייתי קצת מופתע – לבזק בינלאומי יש קו של כמה טרה מחו"ל לארץ בבעלותם), גם נטויז'ן חטפה חזק שבוע שעבר, וגם פרטנר ואחרים. בד"כ התקיפות האלו החזיקו כמה שעות עד שהם נפתרו בפתרונות שונים.

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

ובמקרים רבים הציוד נקנה לשווא.

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

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

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

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

הפתרון לסיטואציה זו מורכב מ-2 חלקים:

  • יצירת קשר עם ספק האינטרנט שלך ובקשה לניתוק זמני מחו"ל. מכיוון שרוב מוחלט של התקפות ה-DDOS מגיע מחו"ל, ההתקפה תיפסק מיידית ומי שיספוג אותה הוא ספק האינטרנט שלך.
  • שימוש בקו DSL יחיד או כפול (עם IP קבוע ולא דינמי) עם QoS עצמאי ברמת המתג שלך לקבלת מיילים ומשלוח, ואם יש לך 2 קווים, הקו השני יכול לתת שרותי גלישה לעובדים (שוב, QoS כדי לעצור כל מיני Uploads מופרעים). אגב, אם משתמשים בפתרון כזה, חשוב להכניס את ה-IP הקבוע של ה-DSL לתוך רשימות ה-MX/SPF/PTR של הדומיין/ים שלכם (כעדיפות משנית, שלישית וכו')

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

עסק עם שרתים שנמצאים בארץ אשר מגיש אתרים לציבור בארץ

גם כאן, כשמתקיפים אותך, הספק יכול לנתק אותך מחו"ל, וקופסא "נגד DDOS" היא מיותרת, ובכל מה שקשור למייל, אפשר להשתמש ב-IP נוסף שדרכו ינותב המייל (לא לשכוח את ה-IP המשני להכניס לרשימת ה-MX לפני ההתקפה), בד"כ ההתקפה מגיעה לשרתי Web, לא לשרתי Mail ולכן תוכל להמשיך לתת ללקוחות שרות קבלת/שליחת מייל אם יש להם client משלהם.

עסק עם שרתים שנמצאים בארץ/בחו"ל אשר מגיש אתרים לציבור בחו"ל
במקרים כאלו, חשוב מאוד להשתמש בספק CDN (כן, גם אם יש לך מספר שרתים בחו"ל משל עצמך). ספק כמו Cloudflare יכול לתת לך בחינם הגנה בסיסית נגד DDoS ובמחיר של 20$ לחודש תוכל לקבל גם הגנה לא רעה על האפליקציה שלך (Web Application Firewall). אם יש לך אתר מאוד גדול שאתה מרוויח ממנו ואתה מותקף תדיר, כדאי שתכיר את התוכנית ביזנס שלהם שעולה 200$ לחודש, אבל מבחינת התקפות אתה מקבל שקט.  (כל התוכניות שלהם נמצאים כאן, ולא – אני לא מרוויח מההפניה. יש כמובן ספקי CDN אחרים, ומומלץ לבדוק את המחירים של המתחרים לפני כן).

אתרים בענן (Google/Amazon/Microsoft)
גם כאן שרות CDN עדיף, מכיוון שהוא "יחטוף" את ההתקפה. גם אמזון וגם מיקרוסופט מציעים שרותי CDN שפרוסים במקומות שונים בעולם אך הם בתשלום נוסף. יוצאי דופן במקרה הזה הם דווקא גוגל, ואם אתה משתמש בשרותי ה-App Engine שלהם, אתה מקבל את שרותי ה-CDN "על הדרך" ללא תשלום נוסף, כלומר אתה תקבל שרות CDN בדיוק באותה רמה שגוגל נותנים עם יוטיוב, תוצאות חיפוש וכו'.

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

בפתרון CDN טוב, מי שחוטף את ההתקפה הוא ספק ה-CDN וספקי CDN רציניים (כמו Cloudflare ואחרים) יש ברשותם קווים של מאות ג'יגהביט ומעלה והם יכולים לעמוד ברוב ההתקפות בלי יותר מדי בעיות. פתרון מקיף לבעיית DDoS צריך לכלול אלמנטים נוספים שספק ה-CDN יכול להצביע עליהם (אם לדוגמא אני מחליט "להתלבש" על קבצים שספק ה-CDN שלך לא עושה להם Cache כמו סרטים וכו'), הם דואגים להחביא את ה-IP הישיר שלך, לנהל את ה-DNS שלך בצורה מוגנת ועוד. כיום אותם פתרונות של CDN טוב יכולים לעלות מ-0 דולר לחודש (הגנה בסיסית) עד כמה מאות דולרים (לאתרים גדולים ומורכבים), אז לפני שאתה מתפתה לרכוש קופסא (שתעלה לך כמה אלפי דולרים + עוד כמה אלפים כל שנה), בדוק פתרון CDN טוב נגד הצרות הללו ותחסוך לעצמך כספים וכאבי ראש.

תכירו את Docker

homepage-docker-logoלהלן סיטואציה שבוודאי מוכרת לכם מהתשתית אצלכם בחברה: יש לכם שרת שמריץ אפליקציה וכל העולם ואחותו בחברה מתחבר כדי לעבוד על האפליקציה. האפליקציה היא קריטית ויכול להיות שעקב עומס אתה מריץ שרת נוסף, בין אם אתה עושה Load Balancing או High Availability – זה לא חשוב כרגע.

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

כלומר עד כה, ספרנו 5 שרתים שמריצים פחות או יותר את אותה אפליקציה ואת אותה מערכת הפעלה. אם אתם משתמשים בוירטואליזציה כמו ESXI או Hyper-V או Xen – אז אתם מריצים 5 מערכות הפעלה זהות שתופסות לא מעט משאבים, הן מבחינת CPU, הן מבחינת דיסק וכמובן מבחינת RAM, וכנראה גם Storage. אם אתם מריצים את זה על ברזלים אמיתיים, אז התשתית שהסביבה לעיל תופסת היא בערך רבע/חמישית ארון.

וירטואליזציית "ברזל" (כמו ESXI, Hyper-V, KVM, Xen) נתנה לנו משהו מדהים לארכיטקטורת ה-PC (זה היה קיים הרבה לפני כן במערכות IBM ואחרות): תיאורתית אתה יכול לקחת ארון שלם של שרתים ו"לדחוף" את כולו ל-2 שרתים עוצמתיים. החסכון בתחזוקה, בחשמל ובמשאבים. פתאום אתה יכול להרים עוד 10 שרתים וירטואליים מבלי לרוץ ולבקש תקציב נוסף ל-10 שרתים פיזיים עם כל כאב הראש המתלווה לכך.

מערכות הוירטואליזציה האלו הן בד"כ מסוג HyperVisor Type 1. יש גם Hypervisor Type-2 כמו VirtualBox או VMWare Workstation שרצות בעצם על מערכת הפעלה קיימת (בין אם זה Linux או Windows) ואינן ניגשות ישירות ל"ברזל" כמו ESXI ואחרות.

ישנה עוד וירטואליזציה. נקרא לזה "וירטואליזציה אפליקטיבית". גם כאן, הרעיון עצמו ישן והוא רץ שנים רבות על OS/400 (מכירים LPAR?), בסולאריס (Zones), בגרסאות BSD (נקרא Jails) ובלינוקס בזמנו היתה תוכנה מסחרית שנקראה OpenVZ (שהיום גם אם ישלמו לי, עם מקל אני לא נוגע בה!) וכמובן Jailed Root/Chroot בכל מערכת יוניקס/לינוקס והתוספת שהיתה ללינוקס מלפני מס' שנים: LXC. כולן נתנו (מי פחות ומי יותר) בערך את אותו דבר: הרצת אותה מערכת הפעלה כמו ה-Host (או גרסאות קרובות, לדוגמא: Solaris 9 על Solaris 11) בצורה נפרדת ללא צורך בעותק נוסף של מערכת ההפעלה. יתרון ענקי שיש לשיטה זו על פני כל Hypervisor היא המהירות: האפליקציה רצה ב-100% מהירות, כך שכל מכונה וירטואלית בשיטה זו תופסת כמעט כלום מבחינת משאבים (היא כמובן תתפוס לאחר שתמלא את המכונה באפליקציה שלך, אבל עדיין, כמות המשאבים שהיא תצרוך קטנה בהרבה בהשוואה לאפליקציה כזו שתרוץ תחת מערכת הפעלה נפרדת ב-Hypervisor כלשהו).

וכאן אנו מגיעים ל-Docker (שאגב, בקרוב יהיה זמין גם רשמית לסולאריס ע"י אורקל. כך השמועות אומרות).

להלן תרשים של Docker בגירסה 0.9:

Docker Execution Drivers

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

Docker משתמש ב"מילה האחרונה" מבחינת טכנולוגיות לינוקס עדכניות כדי לתת כמה שיותר עוצמה לקונטיינר. כך לדוגמא אתה יכול לקבוע כמות כרטיסי רשתות, כמות זכרון, דיסקים, אתה יכול להשתמש ב-Device Mapper (תודה לאלכסנדר לארסון מ-Red Hat שכתב את המימוש) כך שבעצם קונטיינר ישב תחת Device ממופה, ואותו Device הוא בעצם "דיסק" שאתה יכול לקבוע את גודלו ומה שהכי נחמד – הוא Thin Provisioned ללא "קנסות" בביצועים. (אפשר לקרוא את הפוסט של אלכסנדר על כך כאן). אנחנו יכולים לבצע הגנות על הקונטיינרים עם SELinux ועוד.

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

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

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

לסיום: נקודה חשובה גם למי שמכיר את Docker: החל מגירסה 0.9 Docker כבר אינו משתמש יותר ב-LXC (לא אכנס לנסיבות מדוע. דמיינו לבד..), והאפליקציה משתמשת בספריה משלה (libcontainer) שיודעת לדבר עם דברים כמו libvirt ואחרים.

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

(גילוי נאות: הח"מ נותן שרותים בתשלום על הדרכה והטמעת Docker בחברות וארגונים).

בוקר שחור: TrueCrypt

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

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

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

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

כשבודקים את המפתחות שנחתמו איתם קבצי ה-Installer ל-Windows לדוגמא, מוצאים כי גירסת ה-EXE האחרונה ששוחררה לפני יומיים בלבד משתמשת באותו מפתח שאיתו נחתמה הגירסה מינואר. בדיקת WHOIS ובדיקת DNS מראה כי אין שינויים שבוצעו לאחרונה כך שעניין ההתפרקות הוא אותנטי. בבלוג Kerb On Security כותב הבלוג שופך אור יותר על העניין כולל ראיון קצרצר עם מי שעדיין בודק את הקוד לאחר שאנשים תרמו כסף לקמפיין לבדיקת הקוד אם הוא לא כולל חורים "תודות" ל-NSA ושאר גורמים שמעוניינים להיכנס לתכנים מוצפנים. אני ממליץ להיכנס ללינק ולקרוא שם, לאלו המתעניינים.

נעבור לתכל'ס: האם לפרק את ההצפנה מהדיסקים שמוצפנים ב-TrueCrypt? אני ממליץ לחשוב בהגיון: עדיין אין הוכחות שיש קוד שתול ומר גרין, הבחור שבודק את הקוד בעצמו טוען זאת (תסתכלו בלינק לעיל). אני בטוח שרבים יחשבו שאולי מישהו מהמפתחים נשבר והחליט להלשין שארגון כמו NSA שכר אותו לשתול הצפנה חלשה כדי שהם יוכלו לפרק את ההצפנה בקלות, אבל אני יכול להעלות תיאוריה אחרת: אולי מישהו מנסה לארגן הפחדה כדי שתעברו מהצפנה כמו של TrueCrypt להצפנה מסחרית של-NSA אולי יש לה מפתחות ופתרונות פירוק הצפנה? גם זה וגם זה – הם רק תאוריות.

לכן, ההמלצות שלי בשלב זה הן:

  1. לא להתקין את הגירסה שיצאה לפני יומיים. לאלו שיודעים לקרוא קוד, אפשר לראות את ה-DIFF כאן – הגירסה ששוחררה לפני יומיים, חלק גדול מהקוד של ההצפנה פשוט נעקר!
  2. לא להסיר את ההצפנות עדיין מהדיסקים. המצב מעורפל וישנם המוני מהנדסים ומפתחים שמשתמשים בהצפנות האלו, כך שאני די בטוח שיהיו קבוצה חדשה שיקחו את הקוד, ישנו את הרשיון ויוציאו גירסה חדשה. אני מהמר שבגוגל המהנדסים שם הבוקר גם כנראה יחליטו להתערב ולסייע היכן שניתן (הרבה מאוד מהנדסים בגוגל משתמשים בהצפנה עם האפליקציה הזו), כנ"ל לגבי פייסבוק ואפל.

אם יהיו עדכונים, אעדכן פוסט זה.

ניתוח פירצת Heartbleed

heartbleed1

יש עדכונים בסוף הפוסט.

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

בפוסט זה אנסה לסכם כמה דברים לגבי הפירצה ולהסביר כמה דברים נוספים לגביה.

תחילה אסביר מהו אותו חלק שפרוץ. ב-OpenSSL ישנה פונקציה הנקראת Heartbeat. מטרת הפונקציה הזו היא לייעל את התקשורת בין הדפדפן (או ה-Client) לבין השרת שמגיש תוכן. מה ש-Heartbeat עושה הוא בעצם "מסכם" עם השרת להשאיר את תקשורת ה-SSL פתוחה בין השרת ל-Client גם כשאין מידע שעובר באותו ערוץ. היתרון כמובן הוא שאין צורך בכל תהליך יצירת תקשורת מוצפנת מחדש בכל פעם שהשרת צריך להעביר תוכן ל-Client או ההיפך.

הפריצה עצמה נותנת "להציץ" בחלק מהתקשורת עצמה, חור בגודל 64K. לא בכולה. בימים האחרונים יצאו הודעות שבעצם חור האבטחה אינו נורא כל כך, הואיל וקשה מאוד לחלץ את המפתח הפרטי (Private key). אחרי הכל – אם יש לפורץ את ה-Private key, לא חשוב מה בעל האתר המוצפן יבצע, עם המפתח הפרטי אפשר להאזין לתקשורת ללא שום בעיה, גם כשהתקלה תוקנה.

חברת Cloudflare ניסתה במשך שבועיים להוציא מפתח פרטי דרך חור האבטחה בשרת טסטים שלהם והם נכשלו ולפיכך הם הכריזו על אתגר – הם הקימו שרת עצמאי עם חור האבטחה ואתגרו את הגולשים למצוא את המפתח הפרטי של השרת. עברו יומיים ו-2 פורצים שונים הצליחו לחלץ את המפתח (לא בקלות – אחד שלך 2,500,000 בקשות והשני 100,000) כך שפתרון הבעיה עצמה ע"י הטמעת טלאי (או עדכון גירסה) אינו מספק ואם יש למישהו מידע חשוב, יש צורך בלהנפיק תעודת SSL חדשה (Re-issue – זה לא עולה כסף). כל החברות שמוכרות תעודות SSL כבר פרסמו הוראות כיצד לבצע זאת.

עדיין, נקודה אחת שחלק גדול לא התייחס אליה הוא עניין ה-Clients. כן, הם גם צריכים עדכון גירסת SSL ואם הם מתחברים מבחוץ דרך https לאתרים שונים, גם הם צריכים עדכון. אפל הודיעה שהמערכות באייפון/אייפד אין להן את הבעיה, אבל אם אתם משתמשים ב-BBM (שרות ההודעות של BlackBerry) אז אתם כן צריכים עדכון (לאפליקציה, שכוללת מימוש OpenSSL משלה). בכל הקשור לאנדרואיד – הגירסה היחידה שכוללת את חור האבטחה היא 4.1.1 (מכשירים של סמסונג ישנים הכוללים אנדרואיד 4.1 כבר כוללים תיקון ל-OpenSSL והם עם אנדרואיד 4.1.2). לחברות פיתוח שמשתמשות בתחנות קצה מבוססות לינוקס (אובונטו, RHEL/CENTOS) – גם את התחנות יש לעדכן אם הן משתמשות בתקשורת החוצה (אחסון בענן, GIT או כל דבר אחר שעובר דרך https). לשם שינוי, הפעם תחנות ושרתים מבוססי Windows לא צריכים עדכון.

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

כמו תמיד, כשצץ לו חור אבטחה גדול, חובבי תיאוריות הקונספירציה מתועררים מריבצם. לא חשוב כמה הבחור שתרם את הקוד נשבע ביקר לו שזו היתה טעות שלו, תמיד יהיו אלו שיהיו בטוחים שהוא עשה את "הטעות" מטעם ה-NSA (שאגב, לפי בלומברג, כבר ידעה על החור כבר שנתיים וניצלה אותו. ה-NSA מכחישים כמובן) ואז כ-ו-ל-ם פתאום שואלים מדוע לא נעשה Code Auditing (בדיקת קוד) והתשובה לכך היא פשוטה: Code Auditing הוא תהליך יקר (תשאלו את הקבוצה שמפתחים את trucrypt), וזה שחברה תעשה בדיקה על קוד של OpenSSL ותכריז "לא מצאנו שום חורים" לא אומר שמישהו יסמוך על הבדיקה הזו (גם פה תמיד יגיע איזה מישהו וימצא שבן דוד של סמנכ"ל הכספים של אותה חברה נראה בפאב יושב במרחק 100 מטר מסתכל על החצאית של מישהי שעבדה ממזמן כמזכירה באיזה ארגון בטחוני ו"בטח יש משהו שם ואסור לסמוך על זה!!") ולכן יש צורך גם בכספים וגם בגוף ניטרלי.

עדכון 1: יובל סיני (ארכיטקט אבטחת מידע בבנק פועלים) מוסיף:

  •  ציודים עם פגיעות: F5 עם ממשקי ניהול כלפי העולם (כלומר הבעיה היא בממשק הניהול, ולא בכל המוצר).
  • Imperva 10.5
  • ב-OpenSSL ישנו חלק שנקרא Heartbeat – בגדול הסוגיה לא קשורה ל OpenSSL, אלא לשיטת עבודה של אפליקציות ב TCP.
  • בעייה דומה הייתה קיימת בעת עבודה עם mod-ssl, ולא כל הארגונים הטמיעו את הפאץ המתאים.

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

עדכון 3: אין שום קשר בין הפריצה הזו ל-SSH. חבילת OpenSSL אין צורך בה לשם הקמת שרת SSH או בשביל SSH Client, והמשכיות התקשורת הרציפה בין מכונות בחיבור SSH נעשית עם keepalive שיש לו קוד שונה לחלוטין מ-Heartbeat.

על איומי סייבר וסחטנות דיגיטלית

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

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

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

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

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

כל נסיון לפתוח את הקבצים הנ"ל יתן תמונה שבה מופיעה הודעה חגיגית כי הקבצים מוצפנים ועל מנת לשחרר אותם, יש לשלם סכום של 500$ בביטקוין ואת ההעברה יש לבצע דרך הרשת המוצפנת TOR. יש לך 48 שעות להעביר את הכסף. ניסית להתחכם ולהכניס קוד שגוי? התוכנה תקצץ לך כמה שעות מה-48 שעות. לא שילמת אחרי 48 שעות? הסכום מוכפל. לא שילמת אחרי חודש? המפתח ימחק ואתה תישאר עם קבצים שלא תוכל לפתוח.

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

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

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

מה ניתן לעשות? כמה דברים:

  • כרגיל, אנטי וירוס יעיל יכול לעזור בעצירה של הנוזקה מלהיכנס אל המחשב שלך.
  • גיבוי – אם הינך מגבה לדיסק אחר שמחובר למחשב שלך או לתיקיה אחרת, זה לא מספיק. נוזקה כזו יודעת להיכנס גם לגיבוי כזה ולהשמיד אותו. לפיכך מומלץ לגבות לענן לשרות כמו DropBox או Google Drive שנותנים כמה ג'יגהבייט בחינם, אך הפתרון הכי טוב הוא גיבוי שאינו זמין כ"כונן" במחשב – פתרון כמו של Backblaze יכול להיות טוב למרות שהוא אינו חינמי (5$ לחודש ללא הגבלת מקום). כעקרון – גם גיבויים למקומות אחרים טובים, כל עוד השרות אינו ממופה כ"כונן".
  • קצת מחשבה – מכיר מי שלח לך? אם לא, אל תפתח. אתה סקרן ולא בטוח? שמור את הקובץ ואל תריץ, סרוק אותו באנטי וירוס שלך או בשרות החינמי Virus Total.
  • מאוד מומלץ לעבור משימוש מתוכנות מייל שמותקנות על המחשב למייל מבוסס רשת כמו GMail, Outlook.com, Yahoo Mail. שרותים אלו סורקים כל הצמדה ומונעים הורדה.
  • אם גיבוי – אז גיבוי מלא: ודא שלפחות אחת לחודש יש לך גיבוי של Full Backup ולא רק Incremental.
  • אם הנוזקה הזו דפקה את המחשב שלך, אל תשחזר מגיבויים לפני שהנוזקה מוסרת ממחשבך, אחרת גם השחזור יוצפן.

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

מדינת ישראל מציגה: הגנת סייבר מפגרת

Emblem of the State of Israelאתמול פורסמה כתבה על הכוונה של ממשלת ישראל לנתק את שרותי הדואר של הממשלה מתקשורת עם שרתי מייל מחו"ל.

הסיבה? כי ב-7/4 תהיה "התקפת סייבר" של OpIsrael – קבוצות של ילדים שמריצים סקריפטים (סקריפט קידיז) שמחפשים כל מיני פרצות באתרים (כדי לעשות Defacement בחלק מהמקרים, וכדי להשחית DB בחלק נדיר מהמקרים) ובמיוחד – התקפות DDoS על אתרים שונים שרובם מסתיימים ב- co.il או gov.il

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

  • אפשר להעביר את כל הטראפיק של האתרים הממשלתיים דרך שרות CDN כלשהו שנותן הגנת DDoS – החל מ-Cloudflare, incapsula ואחרים. כך אזרחי ישראל היו יכולים להמשיך לגלוש לאתרים ולקבל שרות.
  • בעניין שרתי מייל וכל מיני מרעין בישין שישלחו לעובדי ממשלה ומשרדים ממשלתיים, ישנם מספר פתרונות שיכולים להיות או קופסאות או VM שיושבים "לפני" שרתי הדואר הארגוני וניתן בעזרת אותם פתרונות לבחור איזו רמת הקשחה רוצים. לדוגמא: כל Attachment ינותק מהאימיילים וישב בשרת נפרד עד שמערכת סריקה חזקה כלשהי תעבור על ההצמדה לבדוק אם יש חורים. אפשר ממש להגזים ו"לגרד" מהמייל כל סימון HTML ולהעביר את הטקסט עם HTML בסיסי של יוניקוד והטקסט בלבד.

אבל פה בישראל יושבים מנהלים בצמתים השונים שכפי הנראה הידע שלהם באבטחה ופתרונות – לוקה בחסר (ואני מנומס…). כאן בישראל החליט מי שהחליט לנתק לגמרי את ה-SMTP מחוץ לישראל.

אז אתמול בלילה הלכתי לקרוא את ה-RFC שמדבר על SMTP, אתם יכולים לראות אותו כאן. (זהירות, קובץ טקסט ארוך, ולמי שלא מביא בנושא ושונא לקרא RFC – חומר שיכול להרדים אותך תוך דקות…). מצאתי כי בעמוד 75 תחת סעיף 4.5.4.1 ישנה התייחסות למשלוח חוזר במקרה ששרת המייל היעודי אינו עונה.

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

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

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

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

Google App Engine – הדור הבא

google-app-engineבפוסט הקודם שלי כתבתי על פלטפורמת ה-Google Cloud וספציפית על Google App Engine (בקיצור: GAE) והיתרונות הגדולים שלו לבעלי אתרים שהולכים וגדלים.

העניין הוא שמאז ש-GAE יצא לעולם מ-Beta ב-2011, קמו מתחרים רבים לו. לאמזון יש את BeanStalk, ל-רד-האט יש את OpenShift ויש עוד המון חברות שמציעות משהו דומה שנקרא PaaS (ר"ת Platform As a Service) עם אותו עקרון: כתוב את האפליקציה שלך עם הפלטפורמה שלנו, ואנחנו נארח אותה ונדאג לכל עניין הגדילה, אבטחה, משאבים וכו'.

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

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

עד היום הפתרון לדבר כזה היה לקחת שרת נוסף, שיעודי רק לכך. השרת הזה היה שונה לחלוטין מכל מה ש-PaaS נותן לי. זהו שרת שהייתי צריך להקים מ-אפס, להתקין עליו FFMPEG, לבנות תקשורת בינו לשרותי ה-PaaS, לתחזק אותו מבחינה אבטחה, עדכוני אבטחה ושאר דברים שהיו גוזלים את זמני. את השרת הייתי יכול לקחת משרות EC2 של אמזון או Cloud Compute של גוגל או אחרים. בקיצור – עכשיו עבודת התחזוקה של המערכת היתה יותר גדולה ואני גם אצטרך לשבור את הראש איך לעשות Scale אם הרבה גולשים ניצלו את היום שמש בחוץ וצילמו 500 קליפים וכולם מנסים להעלות אותם במקביל.

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

גוגל החליטו ליצור בתגובה משהו חדש: יש לנו מצד אחד את PaaS שמאפשר לגדול ולתת שרות מהיר ללקוחות, אבל הוא מוגבל מבחינת אפשרויות שימוש באפליקציות צד ג' או אפליקציות Native שכתובות בשפות כמו C או ++C. מצד שני יש לנו IaaS שזה בעצם ה-EC2 או Cloud Compute ואחרים שמאפשרים לנו להקים VM ולעשות את כל עבודת ההקמה/הגדרות/תחזוקה עליו ואנחנו צריכים לשבור את הראש כמעט על כל פיפס.

הפתרון של גוגל? מדוע שלא נשלב את שתי העולמות יחד? גוגל קוראים לזה: Managed VMs. (בשביל הפוסט אני אקרא לזה בקצרה MVMS)

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

ב-MVMS ה-YAML הורחב. מעתה תוכל להגדיר ב-YAML שהסשן יהיה בעצם VM, תוכל לאמר אם אתה מעוניין שהגדילה תהיה ידנית או אוטומטית, תוכל להגדיר איזה סוג Image אתה רוצה ל-VM ומה שהכי חשוב: אתה יכול להוסיף בסוף ה-YAML שורות שאומרות למערכת אלו חבילות להתקין (ואת ההגדרות) בזמן שהיא מקימה עבורך את ה-VMs. ב-GAE יש לך 5 סוגי instances שעליהם רצה האפליקציה. ברגע שאתה מגדיר את הסשן כ-VM, האפשרויות שלך גודלות בהרבה לכל סוג VM שגוגל מציעה. צריך מכונה עם הרבה זכרון? הרבה ליבות? פשוט תציין את סוג המכונה ב-YAML.

ומה עם שאר הדברים כמו Load Balancing וכו'? מה עם SSH למכונה? אין צורך לדאוג, הכל אוטומטי. בזמן ההקמה הוא יחבר את המכונה ל-Load Balancer ותוכל להשתמש בשרות כמו memcache השיתופי (או אחד יעודי עבורך שעולה 6 סנט לשעה) ושאר שרותי GAE כאילו מדובר בסשן GAE רגיל.

היתרונות של שיטת MVMS ברורים:

  1. אין צורך ברכישת מכונות רזרביות. בין אם אתה צריך מכונה אחת נוספת או 10,000, תוכל לבצע זאת מיידית.
  2. לא צריך שרות נוסף של Load Balancing שעולה כסף.
  3. אין צורך "לחמם" מכונות VM כדי שיהיו מוכנות להתחבר ל-Load Balancer.
  4. אין צורך בלהקים שרתי Apache או nginx עם כל ההגדרות שישמשו Front End, אתה פשוט יכול להקים סשן GAE בשפה שאתה רוצה (PHP לדוגמא) ולהרים בו את אתר ה-Front End שלך.
  5. לא צריך לשבור את הראש לגבי כתובות IP
  6. אתה יכול להקים אצלך בעבודה את ה-IMAGE שלך עם הלינוקס שאתה אוהב, עם כל ההגדרות שאתה צריך ואתה יכול להעלות את ה-IMAGE ולהשתמש בו.
  7. אתה יכול לבצע SSH ישירות לתוך כל מכונה מבלי להוסיף לה כתובת IP חיצונית ומבלי לזכור את כתובת ה-IP הזמנית שהמערכת מצמידה לה.
  8. אתה תמיד יכול לשנות את ה-VM, לבצע Snapshot ואז להגדיר ב-YAML שכשהמערכת מקימה מכונה חדשה, היא תשתמש ב-IMAGE (שנוצר מה-snapshot).
  9. אין יותר "ביצועים רנדומאליים". מכירים את זה שאתם מתחילים לעבוד על VM שרץ על ענן ופעם אותו VM רץ כמו שד ופעם אחרת זז כמו צב? פה אין את זה. גוגל מגדירים את השרתים לתת ביצועים באופן ליניארי, כך ש-VM אחד לא "חונק" VM שני.
  10. כן – אפשר גם להשתמש במכונת Windows (כרגע 2008, עוד חודשיים בערך – גם 2012).

שימוש ב-MVMS נותן לך סוף סוף את החופש להשתמש באיזו אפליקציה שתרצה, עם הגדרות שתרצה, והמערכות של גוגל ידאגו לרוב הדברים. אתה לא צריך, בניגוד למצב שקיים כיום, להתחיל להגדיר את הכל מאפס, את שרתי ה-Web, את שרות ה-EMAIL, וכו'. אתה אפילו יכול לחבר בקלות מערכות ניהול תצורה כמו Puppet או CHEF בקלות לסשנים שלך, כך שבסוף היום העסק שלך יכול להתרכז יותר בפיתוח האתר/שרות מאשר לסבול מבעיות תחזוקה, הגדרות חוזרות, "רדיפה" אחרי שרת סורר וכו'.

שרות ה-Managed VMs עדיין לא זמין לציבור (אפשר להירשם בלינק לעיל) והוא יהיה זמין במהלך השבועות הקרובים.

(גילוי נאות: הח"מ נותן שרותי פרילאנס לשרותי הענן של גוגל).

על אתרים שגודלים ו-Google Cloud Platform

cloud-homepage-logo_short_900px

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

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

ככל שהאתר יותר פופולרי, האופטימיזציות שבעל האתר (או מי שהוא שוכר שיעשה עבורו את העבודה הטכנית) יצטרך לעשות הן יותר עמוקות, כמו שימוש בתוספי Cache, אופטימיזציות לבסיס הנתונים, שימוש ב-Cache ב-DB והמתקדמים ישתמשו בפתרונות כמו memcache או Varnish (או שילוב שלהם).

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

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

גוגל בשבוע שעבר הכריזה על מגוון שרותים חדשים במסגרת ה-Cloud Platform שלה, ובאותה הזדמנות הם גם חתכו מחירים בכל השרותי ה-Cloud שהם מספקים, וזו הזדמנות מצויינת לבעלי אתרים פופולריים להסתכל על ה-Google App Engine (ובקצרה: GAE)

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

השימוש ב-GAE מצריך "החלפת דיסקט" אצל בעל האתר. עד היום, כפי שתיארתי לעיל, כשהאתר היה יותר פופולרי, היה צריך לעבור לפלפטפורמה של שרת וירטואלי שאותו מגדילים כמה שצריך עד למצב שצריך מספר שרתים, Load Balancing ועוד.

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

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

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

עכשיו נגיע לחלק של עלויות.

גוגל באופן עקרוני נותנת לכל אחד להתנסות בחינם עם GAE. פשוט כנסו לכאן, פתחו פרויקט ותתנסו. התוכנית החינמית מאפשרת דברים מוגבלים, כמו כמות תעבורה של 1 ג'יגה ליום, מקסימום 28 סשנים של GAE ועוד כפי שניתן לראות באתר הנ"ל, שזה מספיק לדוגמא לדברים פשוטים כמו לארח אתרים אישיים שלכם (למען האמת, הח"מ מתכנן השבוע להעביר את הכל ל-GAE).

אז כמה עולה התענוג? העלות מורכבת מכמה חלקים שנצטרך כדי להשתמש ב-GAE ומומלץ להשתמש בדף הזה כדי לחשב עלויות (לא לשכוח בכל סעיף שאני מזכיר להכניס מספר וללחוץ על Add to Estimate  – התוצאה תהיה מימין למעלה):

  • אנחנו צריכים קודם כל מקום לאחסן את האתר, זה נקרא Google Cloud Storage והמחיר שם מצחיק – 100 ג'יגהבייט יעלו לכם 2.60$ לחודש.
  • אנחנו צריכים לחשב רוחב תעבורה החוצה (תעבורה פנימה היא בחינם). כאן מומלץ לכם להיכנס לאתר שמודד לכם את הטראפיק כדי לראות כמה ג'יגהבייט השתמשתם בממוצע בחודשים האחרונים. אם לדוגמא יש לכם 100 ג'יגהבייט של תעבורה החוצה, העלות תהיה 12$ לחודש. שימו לב: המחיר הזה כולל שרות CDN, כך שאם אתם משלמים כיום לספק CDN, תוכלו לחסוך את ההוצאה הזו.
  • אנחנו צריכים בסיס נתונים. מה גודל ה-DB שלכם וכמה השרת שלכם "מבלה" בעיבוד ה-DB? גוגל מציעים את Cloud SQL שהוא תואם MySQL. אתם יכולים לבקש מהאיש הטכני שלכם לאמר לכם מה גודל ה-DB או שאתם אתם יודעים להשתמש ב-MySQL שימוש פשוט, בצעו mysqldump ל-DB וראו מה גודל הקובץ. בדף החישוב, תבחרו Part Time. מבחינת גודל Instance תבחרו במשהו קטן (תיכף אסביר מדוע) והכניסו את גודל ה-DB שלכם (סביר להניח שהוא לא יותר מכמהה ג'יגה בודדים אם בכלל הוא מגיע לג'יגה. באתרי תוכן רוב הדברים הגדולים הם קבצי המדיה).
  • מה עם שרותי Cache? שרות memcache הוא בחינם. לא עולה לכם כלום 🙂
  • מה עם שרת מייל? אין צורך. ל-GAE יש משלו, כך שהוורדפרס יוציא מיילים בלי שום בעיה.
  • מה עם שרת WEB? יש ל-GAE שרת משל עצמו ואתם לא צריכים להגדיר אותו, כך שאין צורך בשרת Web משלכם.
  • מה עם תוספים לאפליקציות CMS שלכם? את זה אתם מתקינים כמו שאתם מתקינים כרגיל בתוך האפליקציה. אין שינוי.
  • שרותים כמו Compute Engine ו-Persistent Disk במקרה שלנו – אין לנו צורך בהם.
  • מה עם Load Balancing ושאר ירקות לאתרים גדולים? זה מבוצע אוטומטית ע"י ה-GAE ללא תשלום נוסף.

ויש עוד עלות נוספת – עלות ה-Instance. בכל זאת, האפליקציה צריכה לרוץ על משהו. כפי שאתם יכולים לראות כאן, ישנם 4 סוגי instance עם מחירים בין 5 סנט לשעה ל-30 סנט לשעה. עכשיו, לפני שאתם שולפים מחשבי כיס ונבהלים, צריך לזכור כי כבר יש memcache משותף לשרתים (instances) והוא לא נכלל ב-RAM של ה-instance, כך שאתם בעצם צריכים פחות זכרון ממצב רגיל שהייתם משתמשים ב-VM/VPS ובעברית פשוטה: נסו את F1 או F2 ותראו איך האפליקציה שלכם עובדת (וקראו את המסמך בלינק!) לפני שתבחרו את F4.

על מנת שלא תצא לנו חשבונית עם 4 או 5 ספרות ודולרים (והתקף לב בדרך), מומלץ שכשאנו מקימים את האפליקציה ב-GAE, שנשתמש ב-memcache. כך לדוגמא אנחנו נחסוך בפניות רבות ל-SQL ופניות אליו יתבצעו רק אם יש צורך בעדכון (אם מישהו הגיב, או אם אתם מעלים תוכן חדש שיכנס ל-DB).

הגענו לחלק המעניין – של ההתקנה.

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

רוצים להתקין וורדפרס או ג'ומלה? בכיף. כאן ההוראות איך להתקין וורדפרס, וכאן ההוראות איך להתקין Joomla. שימו לב: תצטרכו להתקין שרת MySQL אצלכם במכונה (בכלל הייתי ממליץ לבצע את ההוראות התקנה על מכונת VM אצלכם בבית), ורק לאחר שתריצו את פקודת ה-update והנתונים יעברו ל-GAE ול-Cloud SQL תוכלו להיפטר מהסביבה (אם כי יכול להיות שתרצו לעשות הכל מקומית ואחרי זה לעשות deploy ל-GAE – הכל תלוי בכם).

עוד משהו אחד: יש לכם ערימות של דומיינים? גוגל מציגה שרות חדש שנקרא Google Cloud DNS שנותן לכם להשתמש בתשתית DNS של גודל לנהל את כל הדומיינים שלכם בחינם. לא צריך יותר שרתים שלכם לכך, ולא צריך לדאוג אם שרת זה או אחר נפל או ששוב מישהו אצל רשם הדומיינים דפק רקורד (סבלתי מספיק מהדברים האלו, תודה לכם נטויז'ן!). עוד פרטים – כאן.

בהצלחה

(גילוי נאות: הח"מ נותן שרותי פרילאנס להעברת אתרים ל-GAE ול-Google Cloud).

טיפ בנושא: שדרוג מכונות RHEL

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

כשיש לכם שרת אחד או 2, או מספר קטן מאוד של תחנות RHEL, אז העדכון הוא עניין די פעוט (מבחינת udates, מבחינת upgrade עם אותם עדכונים זה משהו אחר), אבל מה עושים כשיש לך כמה עשרות ואולי מאות שרתים/תחנות עבודה? לתת לכל מכונה להוריד את העדכונים שלה זה נחמד אבל זה לוקח זמן, רוחב פס ודיסק בכל פעם. האם אי אפשר לסדר זאת בתצורה כזו שכל המכונות ישאבו משרת אחד?

לרד-האט יש פתרו שנקרא Red Hat Satellite המאפשר לא רק עדכונים אלא life-cycle שלם למכונות ושרתים שכולל שרותים כמו דיווחי באגים, תמיכה, קבלת תיקונים, בדיקות, יצירת ISO לצרכים שונים וכו'. הכלי הוא כלי גדול וגם עולה בהתאם (כמה אלפי דולרים מחיר התחלתי). אנחנו לעומת זאת צריכים רק את העדכונים, לאחסן אותם על שרת שלנו ואנחנו כבר נפיץ אותם בזמן שנקבע.

על מנת לבצע זאת, נצטרך קודם כל לברר אלו גרסאות RHEL אנחנו משתמשים בחברה. 5? 6? עבור כל אחת מהגרסאות העיקריות נצטרך VM עם המון דיסק פנוי (במינימום 40-50 ג'יגה) וכמובן רשיונות, רשיון פר גירסה Major כך שאם אנחנו משתמשים בחברה ב-RHEL-6 וגם RHEL-5 ולשתיהם אנחנו צריכים עדכונים, אנחנו צריכים 2 רשיונות (כמובן שצריך רשיונות לכל תחנת/שרת RHEL כדי לקבל תמיכה וכו') על מנת לבצע את הקמת ה-REPO החדש שלנו.

ראשית, יש להקים VM עם גירסת RHEL הרצויה. ההתקנה מספיק שתהיה בסיסית עם גישת רשת החוצה ב-HTTP. ויש לבצע register של אותה מכונה ל-RHN. לאחר ההתקנה יש ליצור תיקיה שאליה נאחסן את הקבצים. נקרא לה var/repo/

כעת יש לוודא שחבילת yum-utils וחבילת createrepo מותקנות. אם לא, אפשר להתקין אותם ישירות מה-ISO או בעזרת yum.

כעת נוודא שהשרת רשום לערוץ שממנו אנו רוצים לשאוב עדכונים. לשם כך אפשר להשתמש בפקודה:

rhn-channel -l

אם הכל תקין, נקבל תשובה: rhel-x86_64-server-6 (במקרה שההתקנה היא 64 ביט גירסה 6).

כעת נתחיל לשאוב את העדכונים:

cd /var/repo
reposync -l --repoid=rhel-x86_64-server-6

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

הסתיים? מצוין, עכשיו ניצור ממה שירד repository עם הפקודה הבאה:

createrepo -v --update rhel-x86_64-server-6/getPackage/

זהו. יש לנו repo עם כל ה-RPMS שיש ב-RHEL-6 כולל דברים ישנים וחדשים.

על מנת לאפשר גישה לקבצים שהורדנו, נקים שרות httpd. התקינו את חבילת httpd ובתוך etc/httpd/conf.d/ נקים קובץ בשם repo.conf שיאפשר גישה לקבצים. הנה דוגמא לקובץ:

<VirtualHost *:80>
ServerName rhelrepo
DocumentRoot /var/repo/rhel-x86_64-server-6
ErrorLog logs/repo-error_log
CustomLog logs/repo-access_log common
<Directory "/var/repo/rhel-x86_64-server-6/">
Options Indexes FollowSymLinks
</Directory>
</VirtualHost>

שימו לב לשנות את שם ה-ServerName לשם השרת שלכם.

כעת נפעיל את שרות ה-httpd (עם הפקודה: service httpd restart) ועם הדפדפן ניגש לכתובת: http://rhelrepo/getPackage (שוב, שנו את השם rhelrepo לשם השרת שלכם). אם הכל תקין, תקבלו רשימה ארוכה של קבצי ה-RPM.

עכשיו מגיע החלק שתפיצו בעזרת כל כלי שתרצו – אל כל השרתים שלכם, קובץ repo שב בתיקיה etc/yum.repos.d/ שם ניצור קובץ שנקרא לו rhel6.repo

[RHEL-6-UPDATES]
name=RHEL-6.x Updates
baseurl=http://rhelrepo/getPackage/
enabled=1
gpgcheck=0

מומלץ למחוק את שאר הקבצים שנמצאים באותה תיקיה (ושמורידים את אותם עדכונים מרחוק).

כעת הגיע המבחן הגדול: הריצו yum update ותראו אם המערכת מוצאת עדכונים ומורידה אותם. אם כן, אז ברכותיי – הרמתם לכם שרת REPO מקומי משלכם.

מה שנשאר לעשות הוא להשתמש בפקודות ה-reposync וה-createrepo בתוך סקריפט שירוץ אחת ליום דרך ה-crontab ויעדכן את החבילות ישירות מרד-האט. את זמן ההפצה לכל השרתים והתחנות אתם קובעים לפי הנהלים באותה חברה.

אם אתם צריכים עדכונים ל-RHEL-5, ההבדל היחיד הוא בשם הערוץ, אותו תוכלו לקבל עם פקודת rhn-channel -l

בהצלחה