שלב אחר שלב - לפתח את ה Cloud Service הראשון תחת Windows Azure

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

מה נעשה?

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

• Web Role - יהווה ממשק WEB-י לאפליקציה שלנו. יאפשר למשתמשים להעלות את הקובץ, ולצפות בקבצים המומרים.
• Worker Role - יבצע בפועל את ההמרה.

מה צריך?

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

יצירת הפרוייקט החדש

ב Visual Studio, צרו פרוייקט חדש מהסוג Web and Worker Cloud Service. הסוג הזה,  הוא למעשה template של cloud service שמגיעה עם שני roles מוגדרים וכל ההוראות הדרושות כדי שנוכל לבצע build ולדבג לוקאלית, מהמכונה שלנו, ואף לפבלש בהמשך כ Hosted Service ל Windows Azure.

כדי שנוכל לעבוד בקלות עם queues ו blobs, עליהם דיברתי בפוסט הקודם, נוסיף רפרנס לDLL של הפרוייקט StorageClient, שנמצא בתיקייה של ה SDK. את הרפרנס נוסיף גם ל Worker Role וגם ל Web Role.

הכנת קבצי הקונפיגורציה

פרוייקטים של cloud service  מכילים שני סוגי קבצי קונפיגורציה דיפולטיים. הראשון, נקרא ServiceDefinition.csdef ואמור להכיל את הרשימה של איזה הגדרות יכיל קובץ הקונפיגורציה. ההגדרות עצמם, בדיוק כל ההגדרות שהוגדרו ללא הוספה או החסרה, אמורות להופיע בקובץ ServiceConfiguration.cscfg.  את התוכן המדוייק של הקבצים, תוכלו לראות בפרוייקט ההדגמה שזמין להורדה בתחתית הפוסט. בגדול, הגדרנו AccountName ו AccountSharedKey שמיועדים להדגמה. BlobStorageEndpoint ו QueueStorageEndpoint אלה הגדרות שמתייחסות לאן יישלכו בקשות ה REST לעבודה עם כלים אלה. הערכים שהכנסתי, 127.0.0.1 בפורטים 1000 ו-1001 בהתאמה, אלה הערכים שבהם פועלת סביבת הפיתוח הלוקאלית.

כתיבת ה Web Role

הממשק ה WEB-י שלנו עומד להיות ממש פשוט, ולהכיל שני דברים בדיוק: אפשרות להעלות קובץ חדש להמרה, וקישורים להורדה של הקבצים שכבר הומרו. להעלאת הקבצים נשתמש ב FileUpload control.

למען הנוחוות, הנה הקוד המלא של העמוד עם ה WebRole (לחצו להגדלה):

בקוד הזה יש כמה חלקים:
בחלק הראשון, במידה ויש קובץ להעלאה, אני בודק האם כבר בוצע אתחול ראשוני. באתחול ראשוני, הכוונה ליצירת blob containers ויצירת queue. אני יוצר container, כאשר אני מגדיר שלא לשייך לו metadata כלשהו ולהגדיר שהוא public. את ההגדרות, כלומר, את ה endpoints אני לוקח מהקובץ קונפיגורציה.

בחלק השני, אני יוצר את ה blob, כלומר את הקובץ עצמו ומוסיף אותה ל container (אני מקבל שוב פעם את המופע הקיים, ויוצר את ה blob). הפרמטר true אומר לדרוס במידה שהשם כבר קיים. בחלק השלישי אני שם message ב queue וכותב ללוג.

למעשה, זה כל ה web role, והוא באמת עובד (כפי שתוכלו לראות כשתריצו את הפרוייקט המוגמר אצלכם) ומאפשר להעלות קבצים.

עצה: אם אתם רוצים להעלות אם קבצים הועלו בסביבת הפיתוח הלוקאלית שלכם, תריצו את פרוייקט הדוגמא Cloud Drive שיפתח לכם חלון powershell עם provider שמאפשר לנווט ב blob containers.

כתיבת ה Worker Role

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

כל הקוד הזה נמצא בתוך ה class שנוצר אוטומטית כחלק מהטמפלייט שיורש מ RoleEntryPoint במתודה Start.

מה שאנחנו עושים פה, זה דבר ראשון לכתוב ללוג. שימו לב, שאת ההודעות של הלוג אפשר לראות כשמפעילים במכונה הלוקאלית את ה Development Fabric.
לאחר מכן, בחלק הראשון והשני, אנחנו יוצרים שני containers. הראשון, למעשה מקבל את ה container שאליו נשמרים הקבצים המקוריים, bmptoconvertcontainer והשני הוא converted, שאליו נשמור את הקבצים המומרים.

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

ואז, בלולאה אין סופית, אנחנו שולפים מהתור, במידה וקיים פריט ומעבדים אותו - בחלק החמישי. אנחנו למעשה מכניסים למשתנה path את מה שמכיל ההודעה בתור, שזה למעשה הGUID של blob ואז אנחנו מוציאים את ה blob מה container ואת התוכן שלו מכניסים לאובייקט BlobContents שיצרנו.

בהמשך, אנחנו מוסיפים blob (קובץ) חדש ל blob container של המומרים (converted), ואנחנו למעשה כותבים אליו את המערך bytes שחוזר מהמתודה שכתבתי ConvertImage שממירה מBMP ל-JPEG. ואז, אני כותב ללוג שהומר ומוחק את הפריט מהתור.

כבר בשלב הזה הכל עובד. אם נריץ את ה web role, לאחר שנעלה, נראה בלוג את ההודעה עם הGUID של הפריט והמידע שהוא מוכן לעיבוד. במקביל, נוכל להסתכל על הלוג (דרך ה Development Fabric) של ה Woker ושם נראה שהוא באמת מעבד את הפריט. אבל, רק כדי שיהיה נוח, אני הוספתי ל Page Load של דף הבית של ה web role קוד קטן שיציג לנו את מה שנמצא ב blob container של converted. למעשה, שיציג את כל ה blobs שם.

שימו לב, ש list blobs מקבלת פרמטר אחד שאליו העברנו string ריק. מדובר, למעשה, ב prefix. ב blob container אחד נוכל לשמור כמה סוגים של פריטים (נניח, את הקבצים לפני ההמרה ואחרי ההמרה) כשהדרך שנפריד בהם זה ה prefix. הסיבה העיקרית לכך, היא לחסוך מקום במידה והתימחור יהיה על בסיס blob containers. לטעמי, הרבה יותר נוח להשתמש בזוג blob containers נפרדים עבור כל סוג.

וזהו, עכשיו יש לנו הכל עובד.

אז, מה הלאה?

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

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

בהצלחה!