העברה מלאה מ-Amazon S3 ל-Cloud Storage

בדף הזה נסביר איך לבצע העברה מלאה מ-Amazon Simple Storage Service ‫(Amazon S3) ל-Cloud Storage, למשתמשים ששולחים בקשות באמצעות API. אחרי ההעברה המלאה תוכלו להשתמש בכל התכונות של Cloud Storage, כולל שימוש בכמה פרויקטים במקביל ואימות OAuth 2.0.

אם אתם רוצים להתחיל להשתמש ב-Cloud Storage כמה שיותר מהר, אתם יכולים לבצע העברה פשוטה שדורשת רק כמה שינויים בכלים ובספריות שבהם אתם משתמשים ב-Amazon S3.

מעבר מ-Amazon S3 ל-Cloud Storage

כדי לבצע את ההעברה המלאה מ-Amazon S3 ל-Cloud Storage, צריך להשלים את השלבים הבאים:

  • החלפת כל הכותרות הקיימות מסוג x-amz-* לכותרות תואמות מסוג x-goog-*.
  • החלפת קובץ ה-XML עם הרשימה של בקרת גישה (ACL) של AWS לקובץ ה-XML התואם של Cloud Storage ACL (מידע נוסף זמין במאמר יצירה וניהול של רשימות של בקרת גישה).
  • הגדרת הכותרת x-goog-project-id בבקשות.

  • הגדרת השימוש באימות OAuth 2.0. כשמשתמשים ב-OAuth 2.0, הכותרת Authorization צריכה להיראות כך:

    Authorization: Bearer OAUTH2_TOKEN

    ‫OAuth 2.0 מסתמך על SSL לאבטחה, במקום לדרוש מהאפליקציה לבצע חתימה קריפטוגרפית ישירות, ולכן קל יותר להטמיע אותו. באמצעות OAuth, האפליקציה יכולה לבקש גישה לנתונים שמשויכים לחשבון של המשתמש, ולקבל גישה בכמה רמות, כולל לקריאה בלבד, לקריאה וכתיבה וגישה מלאה. מידע נוסף זמין במאמרים בנושא היקפים של OAuth 2.0 ב-Cloud Storage וגישה לנתונים בשם משתמש.

בקרת גישה

בקטע הזה מוצגות כמה דוגמאות של בקרת גישה שיעזרו לבצע את ההעברה מ-Amazon S3 ל-Cloud Storage. במאמר בקרת גישה תוכלו לקרוא סקירה כללית על בקרת הגישה ב-Cloud Storage.

ב-Cloud Storage אפשר להחיל רשימות בקרת גישה (ACL) לקטגוריות ולאובייקטים בכמה דרכים (מידע נוסף זמין במאמר יצירה וניהול של רשימות של בקרת גישה). שתי הדרכים הבאות להחלת רשימות ACL מקבילות לדרך שבה עושים את זה ב-Amazon S3:

  • באמצעות הפרמטר acl של מחרוזת השאילתה אפשר להחיל רשימות ACL על היקפים ספציפיים.
  • באמצעות כותרת הבקשה x-goog-acl אפשר להחיל רשימות ACL שהוגדרו מראש, שנקראות לפעמים 'רשימות ACL מוכנות מראש'.

שימוש בפרמטר acl של מחרוזת השאילתה

אפשר להשתמש בפרמטר acl של מחרוזת השאילתה בבקשת Cloud Storage בדיוק באותה הדרך שבה משתמשים בו בבקשות ב-Amazon S3. משתמשים בפרמטר acl בשילוב עם השיטה PUT כדי להחיל רשימות ACL על: אובייקט קיים, קטגוריה קיימת או קטגוריה שאתם יוצרים. כשמשתמשים בפרמטר acl של מחרוזת השאילתה בבקשת PUT, צריך לצרף לגוף הבקשה מסמך XML (בתחביר של Cloud Storage ACL). מסמך ה-XML מכיל את כל רשומות ה-ACL שאתם רוצים להחיל על הקטגוריה או האובייקט.

הדוגמה הבאה מציגה בקשת PUT ל-Amazon S3 שמשתמשת בפרמטר acl של מחרוזת השאילתה. רשימות ה-ACL מוגדרות במסמך ה-XML שנשלח בגוף הבקשה. בקשת ה-PUT משנה את רשימות ה-ACL באובייקט בשם europe/france/paris.jpg שנמצא בקטגוריה בשם my-travel-maps. ה-ACL מעניק ל- jeffersonloveshiking@gmail.com FULL_CONTROL את ההרשאה.

PUT europe/france/paris.jpg?acl HTTP/1.1
Host: my-travel-maps.s3.amazonaws.com
Date: Wed, 06 Nov 2013 19:28:18 GMT
Content-Length: 598
Content-Type: application/xml
Authorization: AWS4-HMAC-SHA256 Credential=AWS-ACCESS-KEY/20131106/us-east-1/s3/aws4_request, SignedHeaders=content-length;content-type;date;host, Signature=4c45f25bb679fdab0de5a287625d6a143414728d93c9aeb9f4cc91c33a1c45fg

<?xml version='1.0' encoding='utf-8'?>
<AccessControlPolicy>
  <Owner>
    <ID>5a6557ba40f7c86496ffceae789fcd888abc1b62a7149873a0fe12c0f60a7d95</ID>
    <DisplayName>ownerEmail@example.com</DisplayName>
  </Owner>
  <AccessControlList>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
        <ID>fd447671d60b979f78ee6fcec7b22afc80e6b26a4db16eed01afb8064047949b</ID>
        <DisplayName>jeffersonloveshiking@gmail.com</DisplayName>
      </Grantee>
      <Permission>FULL_CONTROL</Permission>
    </Grant>
  </AccessControlList>
</AccessControlPolicy>

זאת אותה הבקשה, ל-Cloud Storage:

PUT europe/france/paris.jpg?acl HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Wed, 06 Nov 2013 19:37:33 GMT
Content-Length: 268
Content-Type: application/xml
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

<?xml version='1.0' encoding='utf-8'?>
<AccessControlList>
  <Entries>
  <Entry>
    <Permission>FULL_CONTROL</Permission>
    <Scope type="UserByEmail">
      <EmailAddress>jeffersonloveshiking@gmail.com</EmailAddress>
    </Scope>
  </Entry>
  </Entries>
</AccessControlList>

שימו לב שב-Cloud Storage לא נדרש הרכיב <Owner/> במסמך ה-XML של ACL. מידע נוסף זמין במאמר בעלות על קטגוריות ואובייקטים.

אתם יכולים גם לאחזר רשימות ACL של קטגוריות ואובייקטים באמצעות הפרמטר acl של מחרוזת השאילתה, עם השיטה GET. רשימות ה-ACL מתוארות במסמך ה-XML שמצורף לגוף התגובה. כדי להחיל או לאחזר רשימות ACL לאובייקט או לקטגוריה, נדרשת ההרשאה FULL_CONTROL.

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

אתם יכולים להשתמש בכותרת x-goog-acl בבקשה של Cloud Storage, בדיוק באותו האופן שבו משתמשים בכותרת x-amz-acl בבקשת Amazon S3, כדי להחיל רשימות ACL מוגדרות מראש על קטגוריות ואובייקטים. בדרך כלל משתמשים בכותרת x-goog-acl‏ (x-amz-acl) כדי להחיל רשימת ACL מוגדרת מראש על קטגוריה או אובייקט, כשיוצרים או מעלים את הקטגוריה או האובייקט. רשימות ה-ACL המוגדרות מראש ב-Cloud Storage דומות לרשימות ACL מוכנות מראש של Amazon S3, כולל רשימות פרטיות, רשימות לקריאה ציבורית, רשימות לקריאה וכתיבה ציבורית ורשימות אחרות. ‫רשימה שמפרטת את רשימות ה-ACL המוגדרות מראש ב-Cloud Storage

הדוגמה הבאה מציגה בקשת PUT לאובייקט שמחילה את ה-ACL‏ public-read על אובייקט בשם europe/france/paris.jpg שמעלים לקטגוריה בשם my-travel-maps ב-Amazon S3.

PUT europe/france/paris.jpg HTTP/1.1
Host: my-travel-maps.s3.amazonaws.com
Date: Wed, 06 Nov 2013 20:48:42 GMT
Content-Length: 888814
Content-Type: image/jpg
x-amz-acl: public-read
Authorization: AWS4-HMAC-SHA256 Credential=AWS-ACCESS-KEY/20131106/us-east-1/s3/aws4_request, SignedHeaders=content-length;content-type;date;host, Signature=808150c37dbd1b425b2398421d6fc3dd6d4942dfaae9e519fd5835aa62fd62ab

<888814 bytes in entity body>

זאת אותה הבקשה, ל-Cloud Storage:

PUT europe/france/paris.jpg HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Wed, 06 Nov 2013 20:49:57 GMT
Content-Length: 888814
Content-Type: image/jpg
x-goog-acl: public-read
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

<888814 bytes in entity body>

אפשר גם להשתמש בכותרת x-goog-acl כדי להחיל רשימת ACL מוגדרת מראש על קטגוריה או אובייקט קיימים. כדי לעשות את זה צריך לכלול בבקשה את הפרמטר acl של מחרוזת השאילתה, אבל לא לצרף לבקשה מסמך XML. האפשרות להחיל רשימת ACL מוגדרת מראש על אובייקט או קטגוריה קיימים שימושית אם רוצים לעבור מרשימת ACL מוגדרת מראש אחת לרשימה אחרת, או להחליף רשימות ACL מותאמות אישית ברשימות ACL מוגדרת מראש. לדוגמה, בקשת ה-PUT הבאה לאובייקט מחילה את רשימת ה-ACL המוגדרת מראש private על האובייקט europe/france/paris.jpg שנמצא בקטגוריה my-travel-maps.

PUT europe/france/paris.jpg?acl HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Wed, 06 Nov 2013 00:26:36 GMT
Content-Length: 0
x-goog-acl: private
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

<empty entity body>

למידע נוסף על ניהול רשימות ACL, ראו יצירה וניהול של רשימות של בקרת גישה.

מעבר מ-Amazon S3 לשיטות הבקשה של Cloud Storage

השיטות הסטנדרטיות של בקשת HTTP לקריאה ולכתיבה של נתונים בקטגוריות שנתמכות ב-Amazon S3 נתמכות גם ב-Cloud Storage. לכן, רוב הכלים והספריות שבהם אתם משתמשים כרגע ב-Amazon S3 יעבדו באותה צורה גם ב-Cloud Storage. אלה השיטות של הבקשות שנתמכות ב-Cloud Storage:

  • בקשת GET לשירותים.
  • הבקשות PUT,‫ GET,‏ DELETE לקטגוריות.
  • הבקשות GET,‫ POST,‫ PUT,‫ HEAD ו-DELETE לאובייקטים.

מידע נוסף זמין במאמר שיטות הפנייה ב-API ל-XML. חשוב לזכור שכששולחים בקשות ל-Cloud Storage, צריך לשנות את התחביר בגוף הבקשה, במקרה הצורך, לתחביר המתאים של Cloud Storage. לדוגמה, כשיוצרים הגדרה של מחזור חיים לקטגוריה, צריך להשתמש ב-XML של מחזור החיים ב-Cloud Storage, ששונה מה-XML של מחזור החיים ב-Amazon S3.

בטבלה הבאה מוצג סיכום של ההבדלים בין ה-API ל-XML של Cloud Storage לבין Amazon S3:

הפונקציונליות ב-Amazon S3 הפונקציונליות של API ל-XML ב-Cloud Storage
כשמשתמשים במפתחות הצפנה באספקת הלקוח (CSEK) בהעלאה מרובת חלקים, הבקשה הסופית לא כוללת את מפתח ההצפנה באספקת הלקוח (CSEK). ב-API ל-XML של Cloud Storage בקשות בהעלאה מרובת חלקים, כולל הבקשה הסופית, חייבות לספק את אותו מפתח ההצפנה באספקת הלקוח (CSEK). הסיבה לדרישה הזאת היא שפרטי מפתח ההצפנה לא מאוחסנים ב-Cloud Storage במהלך ההמתנה לסיום ההעלאה של הבקשה, אבל המפתח נדרש כדי לחשב סיכום ביקורת (checksum) של האובייקט שהושלם.
ב-Amazon S3 אפשר להשתמש בחתימות V4 כדי לאמת העלאות שמשתמשות בקידוד של מקטעים בהעברה. ב-API ל-XML של Cloud Storage, אי אפשר להשתמש כרגע במקביל גם בקידוד של מקטעים בהעברה וגם בחתימות V4. חלק מהכלים של Amazon S3 משתמשים כברירת מחדל בקידוד של מקטעים בהעברה במקביל לחתימות. במקרים כאלה צריך להשבית את הקידוד של מקטעים בהעברה.
הפרמטרים של GET/POST במחרוזת השאילתה לקטגוריה:
  • ‫"policy" – עבודה עם מדיניות הקטגוריות של Amazon S3.
  • ‫"notification" – התראה על אירועים בקטגוריה.
  • ‫"requestPayment" – הגדרה של הגורם שמשלם על הבקשה ועל הורדת הנתונים מהקטגוריה.
 חלופות:
  • ‫"policy" – רשימות ACL של Cloud Storage, חברוּת בצוות הפרויקט ויכולת להשתמש בכמה פרויקטים, טיפול בתרחישים שבהם נעשה שימוש במדיניות של הקטגוריות.
  • ‫"notification" – שימוש בהתראות Pub/Sub ב-CLI של gcloud או ב-API ל-JSON.
  • ‫"requestPayment" – ב-Cloud Storage, הפרמטר המקביל של requestPayment הוא billing במחרוזת השאילתה.
מחיקה של אובייקטים מרובים.‫
POST /?delete‎

אפשר להשתמש במסוףGoogle Cloud כדי להסיר בקלות אובייקטים מרובים.

לחלופין, API ל-JSON תומך בשליחה של בקשות בכמות גדולה כדי לצמצם את מספר חיבורי ה-HTTP שהלקוח יוצר.

מעבר מכותרות של Amazon S3 לכותרות של Cloud Storage

ב-Cloud Storage משתמשים בכמה כותרות HTTP רגילות וגם בכמה כותרות HTTP בהתאמה אישית (תוספים). אם אתם עוברים מ-Amazon S3 ל-Cloud Storage, אתם יכולים להמיר את הכותרות המותאמות אישית ב-Amazon S3 לכותרות המותאמות אישית המקבילות ב-Cloud Storage או לפונקציונליות דומה אחרת כמו שמוצג בטבלאות שלמטה.

בהרבה מהכותרות של Amazon S3 צריך רק להחליף את הקידומת x-amz ב-x-goog:

כותרת של Amazon S3 כותרת של Cloud Storage
x-amz-storage-class x-goog-storage-class
x-amz-acl x-goog-acl
x-amz-date x-goog-date
x-amz-meta-* x-goog-meta-*
x-amz-copy-source x-goog-copy-source
x-amz-metadata-directive x-goog-metadata-directive
x-amz-copy-source-if-match x-goog-copy-source-if-match
x-amz-copy-source-if-none-match x-goog-copy-source-if-none-match
x-amz-copy-source-if-unmodified-since x-goog-copy-source-if-unmodified-since
x-amz-copy-source-if-modified-since x-goog-copy-source-if-modified-since
‫

יש כמה כותרות שהן שונות או לא רלוונטיות ב-Cloud Storage:

כותרת של Amazon S3 כותרת של Cloud Storage
x-amz-server-side-encryption לא נדרשת. ב-Cloud Storage כל הנתונים מוצפנים באופן אוטומטי לפני שהם נכתבים בדיסק. למידע נוסף, קראו את המאמר בנושא הצפנה.
x-amz-grant-* הכותרת x-goog-acl עם ערך ACL מוגדר מראש.
x-amz-version-id x-goog-generation
x-amz-mfa שימוש באימות OAuth 2.0.
x-amz-decoded-content-length לא נתמך ככותרת x-goog
x-amz-website-redirect-location, x-amz-copy-source-range לא רלוונטי

מידע נוסף על כותרות של Cloud Storage זמין במאמר כותרות HTTP ופרמטרים של מחרוזות שאילתה ב-API ל-XML.

השפעת מדיניות הארגון על אימות מפתח HMAC

אם עומסי העבודה שאתם מעבירים מ-Amazon S3 ל-Cloud Storage מסתמכים על מפתחות של קוד אימות הודעות (HMAC) מבוססי-גיבוב (hash) לצורך אימות, חשוב לדעת שGoogle Cloud שירות מדיניות הארגון מאפשר לאדמינים לאכוף אילוצי אבטחה. אפשר להשתמש במדיניות constraints/storage.restrictAuthTypes כדי למנוע שימוש בסוגים ספציפיים של אימות. מידע נוסף על כל סוג אימות זמין במאמר הגבלה של סוגי אימות.

אם בארגון שלכם יש מדיניות שדוחה את סוג מפתחות ה-HMAC שהכלים שלכם מוגדרים להשתמש בהם, הניסיונות שלכם להתחבר ל-Cloud Storage ייכשלו עם השגיאה 403 Forbidden.

כדי למנוע את השגיאה הזו, לפני העברת תהליכי עבודה שתלויים באימות באמצעות מפתח HMAC, צריך להתייעץ עם האדמין של הארגון כדי לברר אם המדיניות נאכפת ואילו סוגי אימות, אם בכלל, מוגבלים. Google Cloud constraints/storage.restrictAuthTypes אם השימוש במפתח HMAC לא מותר, צריך להתאים את הכלים והאפליקציות לשימוש ב Google Cloud שיטות אימות חלופיות, כמו פרטי כניסה לחשבון שירות עם OAuth 2.0.

המאמרים הבאים