במדריך הזה נסביר איך להעביר מאגר Git, כולל כל המידע שבו, מ-Cloud Source Repositories (CSR) של Google אל Secure Source Manager (SSM). ההעברה הזו משתמשת בפקודות Git רגילות כדי לשכפל ולהעביר ב-push נתוני מאגר.
דרישות מוקדמות
לפני שמתחילים בהעברה, חשוב לוודא שמתקיימים התנאים הבאים:
- הרשאות: למשתמש או לחשבונות השירות צריכות להיות ההרשאות הבאות כדי לבצע את ההעברה:
-
source.repos.get, שזמין בתפקידroles/source.readerבמאגר ה-CSR של המקור -
securesourcemanager.instances.access, שזמין בתפקידroles/securesourcemanager.instanceAccessor, ו-securesourcemanager.repositories.fetch, שזמין בתפקידroles/securesourcemanager.repoWriter, במאגר ובמופע SSM של היעד. אם אתם יוצרים מאגרי מידע חדשים, כדאי לעיין במאמר בנושא יצירת מאגר מידע.
-
- לקוח Git: צריך מחשב עם כלי שורת הפקודה של Git מותקן.
- Google Cloud SDK: כדי לבצע אימות כשמשתמשים ב-HTTPS, צריך להתקין גרסה 395.0.0 ואילך באותו מחשב שבו התקנתם את כלי Git. אם אין לכם Google Cloud SDK, אתם צריכים להתחבר ל-CSR ול-SSM באמצעות מפתחות SSH.
- SSM Instance: מוודאים שיש לכם גישה ל-SSM Instance מהמחשב. אם המכונה שלכם מוגדרת באמצעות Private Service Connect, תוכלו לקרוא את המאמר בנושא גישה למכונה פרטית כדי לקבל פרטים על הגישה.
- אחסון מקומי: צריך מספיק מקום פנוי בדיסק המקומי כדי לאחסן באופן זמני עותקים של המאגרים שמעבירים.
שלבים להעברה
תהליך ההעברה כולל שיבוט של המאגר המלא מ-CSR למחשב המקומי, ואז דחיפה של השיבוט למאגר SSM.
קביעת שיטת הגישה והמשתמש הראשי למאגרי CSR ו-SSM
אתם יכולים להתחבר ל-CSR באמצעות פרוטוקולי HTTP או SSH כשאתם מבצעים אימות כמשתמש ראשי, או באמצעות HTTP כשאתם מבצעים אימות כחשבון שירות. אתם יכולים להתחבר ל-SSM ולבצע אימות באמצעות פרוטוקולי HTTP או SSH, בתור משתמש או חשבון שירות.
לא צריך להשתמש באותו אמצעי תחבורה או באותו גורם ראשי ב-CSR וב-SSM. קובעים את העיקרון וההעברה שבהם תשתמשו בכל פלטפורמה. מידע נוסף על התחזות לחשבונות שירות זמין במאמר התחזות לחשבון שירות.
מוודאים שמאגר ה-CSR הוא לקריאה בלבד
במדריך ההעברה הזה לא נעשה שימוש בשיקוף אוטומטי או בסנכרון.
לכן, חשוב לוודא שאף אחד לא כותב למאגר ה-CSR במהלך ההעברה או אחריה. מעדכנים את הרשאות ה-IAM כך שלאף משתמש לא יהיה תפקיד אחר מלבד roles/source.reader במאגר. אפשר גם לתאם עם המשתמשים כדי להפסיק את כל השמירות במהלך ההעברה.
יצירת מאגר Secure Source Manager
אפשר לדלג על השלב הזה אם אדמין כבר יצר עבורכם את המאגר.
כדי ליצור מאגר ריק במכונת ה-SSM, פועלים לפי ההוראות ליצירת מאגר חדש. חשוב לוודא ש:
- אם משתמשים בממשק המשתמש, לא בוחרים באפשרות Initialize Repository (הפעלת מאגר), כי היא יוצרת מאגר לא ריק.
- אם משתמשים ב-Google Cloud CLI, לא מגדירים את הדגלים
--gitignores,--readmeו---licenses, כי זה יוצר מאגר לא ריק. - אם משתמשים ב-API, לא מגדירים את השדות
gitignores,licenseו-readmeשלInitialConfig, כי זה יוצר מאגר לא ריק.
אימות הגדרות המאגר של SSM
בודקים בממשק המשתמש שהמאגר ריק, או משכפלים את המאגר ומריצים את הפקודה git show-ref. הפלט ריק אם המאגר ריק.
כדי לוודא שאין כללים פעילים להגנה על ענפים, בודקים את ממשק המשתמש או משתמשים ב-API. כדי למנוע חסימה של ההעברה, לא צריכים להיות כללים, או שכל הכללים צריכים להיות מושבתים.
איך מוודאים שיש מספיק נפח אחסון בכונן המקומי ובכונן המרוחק
לפני שיבוט מאגר ה-CSR, צריך לברר מה הגודל הכולל שלו. מריצים את gcloud source repos describe <var>CSR_REPO_NAME</var>. הפקודה הזו מציגה את המספר הכולל של הבייטים במאגר. כדי להעריך את המקום הפנוי בדיסק במערכת Linux, מריצים את הפקודה df . כדי לראות את מספר הבייטים שזמינים בספרייה הנוכחית.
ב-SSM יש מגבלת אחסון של 100GB לכל מופע כברירת מחדל. לפני שמשכפלים את מאגר ה-CSR, צריך לוודא שהוא ייכנס.
שכפול מאגר ה-CSR
משכפלים את ההיסטוריה המלאה של המאגר מ-CSR למחשב המקומי.
- עוברים לספרייה המקומית שבה רוצים לאחסן באופן זמני את המאגר.
- משכפלים את המאגר:
sh git clone <var>CSR_REPO_URL</var> --mirror
הפקודה הזו יוצרת שיבוט bare, שעבר אופטימיזציה להעברת כל התוכן של המאגר למאגר מרוחק אחר. תשימו לב שהספרייה מכילה רק קבצים כמו config ו-HEAD, במקום את התוכן של המאגר.
זו התנהגות צפויה. כל התוכן במאגר שובט ומופיע בספרייה objects ובספריות אחרות, אבל אין עותק עבודה.
הוספת מאגר Secure Source Manager כמאגר מרוחק חדש
מריצים את הפקודה הבאה:
git remote add ssm <var>SSM_REPOSITORY_URL</var>
העברת המאגר המלא אל Secure Source Manager
דחיפה של כל הענפים, התגים וההפניות מהשיבוט המקומי אל ה-SSM המרוחק:
git push --mirror ssm
אימות
אחרי שהפעולה של שליחת הנתונים מסתיימת, משכפלים את מאגר ה-SSM לספרייה אחרת. לאחר מכן, משווים בין העותקים של המאגר ב-CSR וב-SSM:
- מספר הענפים: מריצים את הפקודה
git branch -rבכל מאגר ומאמתים שמספר הענפים זהה. במערכות Linux או macOS, העברת הפקודה ל-wc -lבאמצעות צינור סופרת את שורות הפלט. - מספר התגים: מריצים את הפקודה
git tagבכל מאגר ומאמתים שמספר התגים זהה. במערכות Linux או macOS, העברת הפקודה ל-wc -lסופרת את שורות הפלט. - HEAD commit: מריצים את הפקודה
git rev-parse HEADבכל מאגר, ומוודאים שהגיבוב של ה-commit זהה. - מספר הקומיטים: מריצים את הפקודה
git rev-list --all --countבכל מאגר, ומוודאים שמספר הקומיטים זהה.
הסרת המשאבים
- אם התחזיתם לחשבון שירות במהלך ההעברה, מריצים את הפקודה
gcloud config set accountכדי לאפס את פרטי הכניסה. - אם השבתתם את הכללים להגנה על הסתעפות, צריך להפעיל מחדש את הכללים להגנה על הסתעפות במאגר SSM.
- מסירים מהמחשב שבו השתמשתם להעברה עותקים לא מוצפנים של מאגר ה-CSR.
- מוחקים את מאגר ה-CSR המקורי.