יכול להיות שחלק מהמידע בדף הזה או כולו לא רלוונטי ל-Cloud de Confiance by S3NS. פרטים נוספים מופיעים במאמר מה ההבדל מ-Google Cloud.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

התקנה ידנית של סנכרון תצורות באמצעות kubectl

בדף הזה מוסבר איך להתקין את סנכרון תצורות באמצעות פקודות kubectl.

לפני שמתחילים

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

הכנת הסביבה המקומית

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

ליצור מקור מידע אמין או לקבל גישה למקור מידע אמין.
מתקינים ומפעילים את Google Cloud CLI, שמספק את הפקודות gcloud, kubectl ו-nomos שמשמשות בהוראות האלה. אם אתם משתמשים ב-Cloud Shell, ‏ Google Cloud CLI מותקן מראש.
‫kubectl לא מותקן כברירת מחדל על ידי Google Cloud CLI. כדי להתקין את kubectl, משתמשים בפקודה הבאה:
```
gcloud components install kubectl
```
מבצעים אימות ל- Cloud de Confiance by S3NS באמצעות הפקודה gcloud auth login כדי שתוכלו להוריד רכיבים של סנכרון תצורות.

הכנת האשכולות

צריך ליצור אשכול Google Kubernetes Engine או לקבל גישה לאשכול שעומד בדרישות של סנכרון תצורות.

הכנת ההרשאות

Cloud de Confiance למשתמש שמתקין את סנכרון תצורות צריכות להיות הרשאות IAM ליצירת תפקידים חדשים באשכול. אם צריך, מקצים את התפקידים האלה באמצעות הפקודות הבאות:

gcloud container clusters get-credentials CLUSTER_NAME

kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole cluster-admin --user USER_ACCOUNT

מחליפים את מה שכתוב בשדות הבאים:

‫CLUSTER_NAME: שם האשכול
USER_ACCOUNT: כתובת האימייל של חשבון Cloud de Confiance

בהתאם לאופן שבו הגדרתם את Google Cloud CLI במערכת המקומית, יכול להיות שתצטרכו להוסיף את השדות --project ו---zone.

אם אתם צריכים להעניק ל-סנכרון תצורות גישה ל-OCI באמצעות gcpserviceaccount כסוג האימות, כדי ליצור קשירת מדיניות, אתם צריכים גם את ההרשאה iam.serviceAccounts.setIamPolicy. כדי לקבל את ההרשאה הזו, צריך להקצות את תפקיד ה-IAM ‏Service Account Admin ‏(roles/iam.serviceAccountAdmin). יכול להיות שתוכלו לקבל את ההרשאה הזו גם בתפקידים בהתאמה אישית או בתפקידים אחרים שמוגדרים מראש.

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

רישום אשכול

כדי לרשום אשכול ל-Config Sync, מבצעים את השלבים הבאים:

פריסה של סנכרון תצורות
נותנים ל-סנכרון תצורות הרשאת קריאה בלבד לאחד מהבאים:
- Git
- OCI
- Helm
הגדרת סנכרון תצורות

פריסת סנכרון תצורות

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

מורידים את הגרסה העדכנית של מניפסטים של סנכרון תצורות באמצעות הפקודה הבאה. כדי להוריד גרסה ספציפית, אפשר לעיין במאמר בנושא הורדות.
```
gcloud storage cp gs://config-management-release/released/latest/config-sync.tar.gz config-sync.tar.gz
```
מחילוץ הארכיון:
```
tar -xzvf config-sync.tar.gz
```
באמצעות ההוראות שבקובץ README.md שסופק, עורכים את ההתאמה האישית בארכיון שחולץ בשלב הקודם.
כדי לעדכן את ההתקנה של סנכרון תצורות, מפעילים את המניפסט שעבר רינדור שיצרתם לפי README.md ההוראות:
```
kubectl apply -f CONFIG_SYNC_MANIFEST
```
מחליפים את CONFIG_SYNC_MANIFEST בשם של המניפסט שעבר רינדור.
מחליפים את הפקודה nomos בכל הלקוחות בגרסה החדשה. השינוי הזה מבטיח שהפקודה nomos תמיד תוכל לקבל את הסטטוס של כל האשכולות הרשומים ולאמת את ההגדרות שלהם.

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

הסטטוס של התקנה תקינה ללא בעיות הוא PENDING או SYNCED.

התקנה לא תקינה מקבלת את הסטטוס NOT CONFIGURED ומופיעה בה אחת מהשגיאות הבאות:

missing git-creds Secret
git-creds Secret is missing the key specified by secretType

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

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

הענקת הרשאת קריאה בלבד ל-Config Sync

אם אתם מאחסנים את ההגדרות ב-Git, אתם צריכים לתת ל-Config Sync גישת קריאה בלבד ל-Git. אם אתם מאחסנים את ההגדרות כתמונות OCI, אתם צריכים להעניק ל-סנכרון תצורות גישת קריאה בלבד ל-OCI. אם אתם מאחסנים את ההגדרות ב-Helm, אתם צריכים לתת ל-סנכרון תצורות גישת קריאה בלבד ל-Helm.

הענקת הרשאת קריאה בלבד ל-סנכרון תצורות ב-Git

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

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

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

‫סנכרון תצורות תומך במנגנוני האימות הבאים:

זוג מפתחות SSH‏ (ssh)
קובץ Cookie (cookiefile)
טוקן (token)
חשבון שירות של Google ‏ (gcpserviceaccount)
חשבון השירות של Compute Engine שמוגדר כברירת מחדל (gcenode)
אפליקציית GitHub‏ (githubapp)

המנגנון שתבחרו תלוי במה שהמאגר תומך בו. באופן כללי, מומלץ להשתמש בזוג מפתחות SSH. גם GitHub וגם Bitbucket תומכים בשימוש בזוג מפתחות SSH. עם זאת, אם אתם משתמשים במאגר ב-Cloud Source Repositories או ב-Secure Source Manager, מומלץ להשתמש בחשבון שירות של Google במקום זאת, כי התהליך פשוט יותר. אם המאגר מתארח בארגון שלכם ואתם לא יודעים אילו שיטות אימות נתמכות, פנו לאדמין.

כדי להשתמש במאגר ב-Cloud Source Repositories כמאגר סנכרון תצורות, צריך לבצע את השלבים הבאים כדי לאחזר את כתובת ה-URL של Cloud Source Repositories:

הצגת רשימה של כל המאגרים:
```
gcloud source repos list
```
מעתיקים את כתובת ה-URL מהמאגר שבו רוצים להשתמש. לדוגמה:
```
REPO_NAME  PROJECT_ID  URL
my-repo    my-project  https://source.developers.google.com/p/my-project/r/my-repo-csr
```
תצטרכו להשתמש בכתובת ה-URL הזו כשמגדירים את סנכרון תצורות בקטע הבא. אם מגדירים את סנכרון תצורות באמצעותCloud de Confiance המסוף, מוסיפים את כתובת ה-URL בשדה URL. אם מגדירים את סנכרון תצורות באמצעות Google Cloud CLI, מוסיפים את כתובת ה-URL לשדה syncRepo בקובץ התצורה.

זוג מפתחות SSH

זוג מפתחות SSH מורכב משני קבצים: מפתח ציבורי ומפתח פרטי. למפתח הציבורי יש בדרך כלל סיומת .pub.

כדי להשתמש בזוג מפתחות SSH, צריך לבצע את השלבים הבאים:

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

הפקודה הבאה יוצרת מפתח RSA של 4096 ביט. לא מומלץ להשתמש בערכים נמוכים יותר:
```
ssh-keygen -t rsa -b 4096 \
-C "GIT_REPOSITORY_USERNAME" \
-N '' \
-f /path/to/KEYPAIR_FILENAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫GIT_REPOSITORY_USERNAME: שם המשתמש שרוצים ש-סנכרון תצורות ישתמש בו כדי לבצע אימות למאגר
- ‫/path/to/KEYPAIR_FILENAME: נתיב לזוג המפתחות
אם אתם משתמשים במאגר Git שמתארח אצל צד שלישי, כמו GitHub, או שאתם רוצים להשתמש בחשבון שירות עם Cloud Source Repositories, מומלץ להשתמש בחשבון נפרד.

הערה: צריך ליצור את מפתח ה-SSH בלי סיסמה. ‫סנכרון תצורות לא תומך בביטויי סיסמה למפתחות SSH.
מגדירים את המאגר כך שיזהה את המפתח הציבורי החדש שנוצר. אפשר לעיין בתיעוד של ספק האירוח של Git. לנוחיותכם, הוספנו הוראות לכמה ספקי אירוח פופולריים של Git:
- Cloud Source Repositories
- Bitbucket
- ‫GitHub אנחנו ממליצים ליצור מפתחות פריסה נפרדים כדי לספק גישת קריאה בלבד למאגר GitHub יחיד.
- GitLab
מוסיפים את המפתח הפרטי ל-Secret חדש באשכול:
```
kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
 --namespace=config-management-system \
 --from-file=ssh=/path/to/KEYPAIR_PRIVATE_KEY_FILENAME
```
מחליפים את /path/to/KEYPAIR_PRIVATE_KEY_FILENAME בשם של המפתח הפרטי (זה בלי הסיומת .pub).
(מומלץ) כדי להגדיר בדיקה של מארחים מוכרים באמצעות אימות SSH, אפשר להוסיף את המפתח של המארחים המוכרים לשדה data.known_hosts בסוד git_creds. כדי להשבית את הבדיקה של known_hosts, אפשר להסיר את השדה known_hosts מה-Secret. כדי להוסיף את המפתח של המארחים המוכרים, מריצים את הפקודה:
```
kubectl edit secret git-creds \
 --namespace=config-management-system
```
לאחר מכן, בקטע data, מוסיפים את הערך של המארחים המוכרים:
```
known_hosts: KNOWN_HOSTS_KEY
```
מוחקים את המפתח הפרטי מהדיסק המקומי או מגנים עליו בדרך אחרת.
כשמגדירים את סנכרון תצורות ומוסיפים את כתובת ה-URL של מאגר ה-Git, צריך להשתמש בפרוטוקול SSH. אם אתם משתמשים במאגר ב-Cloud Source Repositories, אתם צריכים להזין את כתובת ה-URL בפורמט הבא:
```
ssh://EMAIL@source.developers.google.com:2022/p/PROJECT_ID/r/REPO_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫EMAIL: שם המשתמש שלכם Cloud de Confiance
- ‫PROJECT_ID: המזהה של Cloud de Confiance הפרויקט שבו נמצא המאגר
- ‫REPO_NAME: שם המאגר

Cookiefile

התהליך לקבלת cookiefile תלוי בהגדרות של המאגר. דוגמה מופיעה במאמר בנושא יצירת פרטי כניסה סטטיים במסמכי התיעוד של Cloud Source Repositories. פרטי הכניסה מאוחסנים בדרך כלל בקובץ .gitcookies בספריית הבית, או שהם מסופקים על ידי אדמין אבטחה.

כדי להשתמש ב-cookiefile, מבצעים את השלבים הבאים:

אחרי שיוצרים את cookiefile ומקבלים אותו, מוסיפים אותו לסוד חדש באשכול.

אם אתם לא משתמשים ב-proxy מסוג HTTPS, אתם יכולים ליצור את הסוד באמצעות הפקודה הבאה:
```
kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
 --namespace=config-management-system \
 --from-file=cookie_file=/path/to/COOKIEFILE
```
אם אתם צריכים להשתמש בשרת proxy מסוג HTTPS, אתם יכולים להוסיף אותו ל-Secret יחד עם cookiefile באמצעות הפקודה הבאה:
```
kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
 --namespace=config-management-system \
 --from-file=cookie_file=/path/to/COOKIEFILE \
 --from-literal=https_proxy=HTTPS_PROXY_URL
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫/path/to/COOKIEFILE: הנתיב ושם הקובץ המתאימים
- ‫HTTPS_PROXY_URL: כתובת ה-URL של שרת ה-proxy ל-HTTPS שבו משתמשים כשמתקשרים עם מאגר Git
הערה: מטעמי אבטחה, לא מומלץ להשתמש ב-proxy מסוג HTTP.
אם עדיין צריך את התוכן של cookiefile באופן מקומי, צריך להגן עליו. אחרת, מוחקים אותו.

אסימון

אם הארגון שלכם לא מאפשר שימוש במפתחות SSH, יכול להיות שתעדיפו להשתמש בטוקן. באמצעות סנכרון תצורות, אתם יכולים להשתמש בטוקנים של גישה אישית (PAT) של GitHub, בטוקנים של PAT או במפתחות פריסה של GitLab, או בסיסמאות לאפליקציות של Bitbucket כטוקנים שלכם.

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

יוצרים טוקן באמצעות GitHub,‏ GitLab או Bitbucket:
- ‫GitHub: יצירת PAT. נותנים לטוקן את ההיקף repo כדי שהוא יוכל לקרוא ממאגרים פרטיים. מכיוון שמקשרים את ה-PAT לחשבון GitHub, מומלץ גם ליצור משתמש מכונה ולקשר את ה-PAT למשתמש המכונה.
- ‫GitLab: יצירת PAT או יצירת טוקן פריסה
- ‫Bitbucket: יצירת סיסמה לאפליקציה
אחרי שיוצרים את האסימון ומקבלים אותו, מוסיפים אותו ל-Secret חדש באשכול.

אם אתם לא משתמשים ב-proxy מסוג HTTPS, אתם יכולים ליצור את הסוד באמצעות הפקודה הבאה:
```
kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
  --namespace="config-management-system" \
  --from-literal=username=USERNAME \
  --from-literal=token=TOKEN
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫USERNAME: שם המשתמש שרוצים להשתמש בו.
- ‫TOKEN: האסימון שיצרתם בשלב הקודם.
אם אתם צריכים להשתמש בשרת proxy מסוג HTTPS, אתם יכולים להוסיף אותו ל-Secret יחד עם username ו-token באמצעות הפקודה הבאה:
```
kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
 --namespace=config-management-system \
 --from-literal=username=USERNAME \
  --from-literal=token=TOKEN \
 --from-literal=https_proxy=HTTPS_PROXY_URL
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫USERNAME: שם המשתמש שרוצים להשתמש בו.
- ‫TOKEN: האסימון שיצרתם בשלב הקודם.
- ‫HTTPS_PROXY_URL: כתובת ה-URL של שרת ה-proxy ל-HTTPS שבו אתם משתמשים כשאתם מתקשרים עם מאגר Git.
הערה: מטעמי אבטחה, לא מומלץ להשתמש ב-proxy מסוג HTTP.
אם עדיין צריך את האסימון באופן מקומי, צריך להגן עליו. אחרת, מוחקים אותו.

חשבון שירות של Google

אם המאגר שלכם נמצא ב-Cloud Source Repositories או ב-Secure Source Manager, והאשכול שלכם משתמש ב-איחוד זהויות של עומסי עבודה ל-GKE או ב-fleet Workload Identity Federation for GKE, אתם יכולים להעניק ל-סנכרון תצורות גישה למאגר באותו פרויקט כמו האשכול המנוהל שלכם באמצעות חשבון שירות של Google.

אם עדיין אין לכם חשבון שירות, יוצרים חשבון שירות.
מקצים לחשבון השירות את התפקידים הנכונים ב-IAM כדי שתהיה לו גישה למאגר:
Cloud Source Repositories
מקצים לחשבון השירות של Google את תפקיד ה-IAM 'קורא Cloud Source Repositories' (roles/source.reader). מידע נוסף על תפקידים והרשאות ב-Cloud Source Repositories זמין במאמר בנושא הענקת הרשאות לצפייה במאגרי קוד.
- כדאי להעניק הרשאה ברמת הפרויקט אם אותן הרשאות חלות על כל המאגרים בפרויקט.
  gcloud projects add-iam-policy-binding PROJECT_ID \ --role=roles/source.reader \ --member="serviceAccount:GSA_NAME@PROJECT_ID.s3ns.iam.gserviceaccount.com"
- כדאי להעניק הרשאה ספציפית למאגר כשרוצים שלחשבונות שירות יהיו רמות גישה שונות לכל מאגר בפרויקט.
  gcloud source repos set-iam-policy REPOSITORY POLICY_FILE --project=PROJECT_ID
Secure Source Manager
מקצים לחשבון השירות של Google את תפקידי ה-IAM‏ Secure Source Manager Instance Accessor (roles/securesourcemanager.instanceAccessor) ו-Secure Source Manager Repo Reader (roles/securesourcemanager.repoReader). מידע נוסף על תפקידים והרשאות ב-Secure Source Manager זמין במאמר ניהול תפקידים במאגר.
- כדאי להעניק הרשאה ברמת הפרויקט אם אותן הרשאות חלות על כל המאגרים בפרויקט.
  gcloud projects add-iam-policy-binding PROJECT_ID \ --role=roles/securesourcemanager.instanceAccessor \ --member="serviceAccount:GSA_NAME@PROJECT_ID.s3ns.iam.gserviceaccount.com"
  gcloud projects add-iam-policy-binding PROJECT_ID \ --role=roles/securesourcemanager.repoReader \ --member="serviceAccount:GSA_NAME@PROJECT_ID.s3ns.iam.gserviceaccount.com"
- כדי להעניק הרשאות ספציפיות למאגר, אפשר להשתמש בממשק האינטרנט של Secure Source Manager למאגר. מידע נוסף זמין במאמר הקצאת תפקידים ברמת המאגר למשתמשים.
אם מגדירים את סנכרון תצורות באמצעות Cloud de Confiance המסוף, בוחרים באפשרות איחוד זהויות של עומסי עבודה ל-GKE בתור סוג האימות ואז מוסיפים את כתובת האימייל של חשבון השירות.

אם אתם מגדירים את סנכרון תצורות באמצעות Google Cloud CLI, מוסיפים את gcpserviceaccount כ-secretType ואז מוסיפים את כתובת האימייל של חשבון השירות ל-gcpServiceAccountEmail.
אם אתם משתמשים במאגר ב-Secure Source Manager, אתם צריכים להשתמש בפורמט הבא כשאתם מגדירים את סנכרון תצורות ומוסיפים את כתובת ה-URL של מאגר Git:
```
https://INSTANCE_ID-PROJECT_NUMBER-git.LOCATION.sourcemanager.dev/PROJECT_ID/REPO_NAME.git
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫INSTANCE_ID: השם של מופע Secure Source Manager.
- ‫PROJECT_ID: מזהה הפרויקט ב- Cloud de Confianceשבו נמצאת המכונה.
- ‫PROJECT_NUMBER: Cloud de Confiance מספר הפרויקט שבו נמצאת המכונה.
- ‫LOCATION: האזור שבו נמצאת המכונה.
- ‫REPO_NAME: שם המאגר.
אחרי הגדרת סנכרון תצורות, יוצרים קישור של מדיניות IAM בין חשבון השירות של Kubernetes לבין חשבון השירות של Google. חשבון השירות של Kubernetes נוצר רק כשמגדירים את סנכרון תצורות בפעם הראשונה.

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

הקישור הזה מאפשר לחשבון השירות של Kubernetes ב-Config Sync לפעול כחשבון השירות של Google:
```
gcloud iam service-accounts add-iam-policy-binding \
    GSA_NAME@PROJECT_ID.s3ns.iam.gserviceaccount.com \
    --role=roles/iam.workloadIdentityUser \
    --member="serviceAccount:FLEET_HOST_PROJECT_ID.s3ns.svc.id.goog[config-management-system/KSA_NAME]" \
    --project=PROJECT_ID
```

מחליפים את מה שכתוב בשדות הבאים:

‫PROJECT_ID: מזהה הפרויקט של הארגון.
‫FLEET_HOST_PROJECT_ID: אם אתם משתמשים באיחוד זהויות של עומסי עבודה ל-GKE, הערך הזה זהה לערך של PROJECT_ID. אם אתם משתמשים באיחוד זהויות של עומסי עבודה ל-GKE, זהו מזהה הפרויקט של ה-fleet שהאשכול רשום בו.
‫GSA_NAME: חשבון השירות המותאם אישית של Google שבו רוצים להשתמש כדי להתחבר ל-Artifact Registry. לחשבון השירות צריך להיות מוקצה תפקיד הקורא (roles/artifactregistry.reader) ב-IAM של Artifact Registry.
‫KSA_NAME: חשבון השירות של Kubernetes עבור ה-reconciler.
- אם שם מאגר הבסיס (root) הוא RootSync, משתמשים ב-root-reconciler.root-sync אחרת, משתמשים ב-root-reconciler-ROOT_SYNC_NAME. אם מתקינים את סנכרון תצורות באמצעות מסוף Cloud de Confiance או Google Cloud CLI,‏ סנכרון תצורות יוצר באופן אוטומטי אובייקט RootSync בשם root-sync.
‫REPOSITORY: שם המאגר.
‫POLICY_FILE: קובץ JSON או YAML עם מדיניות ניהול הזהויות והגישה.

חשבון השירות של Compute Engine שמוגדר כברירת מחדל

אם המאגר שלכם נמצא ב-Cloud Source Repositories, והאפשרות איחוד זהויות של עומסי עבודה ל-GKE מושבתת באשכול GKE, תוכלו להשתמש ב-gcenode כסוג האימות.

אם מגדירים את סנכרון תצורות באמצעות המסוף Cloud de Confiance , בוחרים באפשרות Google Cloud Repository בתור Authentication Type (סוג האימות).

אם אתם מגדירים את סנכרון תצורות באמצעות Google Cloud CLI, מוסיפים את gcenode כsecretType.

אם בוחרים באפשרות Google Cloud Repository או באפשרות gcenode, אפשר להשתמש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine. צריך להקצות לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine את תפקיד ה-IAM ‏Cloud Source Repositories Reader ‏ (roles/source.reader). מידע נוסף על תפקידים והרשאות ב-Cloud Source Repositories זמין במאמר מתן הרשאות לצפייה במאגרים.

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role=roles/source.reader \
  --member="serviceAccount:PROJECT_NUMBER-compute@developer.s3ns-system.iam.gserviceaccount.com"

מחליפים את PROJECT_ID במזהה הפרויקט של הארגון ואת PROJECT_NUMBER במספר הפרויקט של הארגון.

אפליקציית GitHub

אם המאגר שלכם נמצא ב-GitHub, אתם יכולים להשתמש ב-githubapp כסוג האימות.

כדי להשתמש באפליקציית GitHub, צריך לבצע את השלבים הבאים:

פועלים לפי ההוראות ב-GitHub כדי להקצות אפליקציית GitHub ולהעניק לה הרשאה לקרוא מהמאגר.
מוסיפים את ההגדרה של אפליקציית GitHub לסוד חדש באשכול:
שימוש במזהה לקוח
```
kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
  --namespace=config-management-system \
  --from-literal=github-app-client-id=CLIENT_ID \
  --from-literal=github-app-installation-id=INSTALLATION_ID \
  --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
  --from-literal=github-app-base-url=BASE_URL
```
- מחליפים את CLIENT_ID במזהה הלקוח של אפליקציית GitHub.
- מחליפים את INSTALLATION_ID במזהה ההתקנה של אפליקציית GitHub.
- מחליפים את /path/to/GITHUB_PRIVATE_KEY בשם הקובץ שמכיל את המפתח הפרטי.
- מחליפים את הערך BASE_URL בכתובת ה-URL הבסיסית של נקודת קצה ל-API של GitHub. הפרמטר הזה נדרש רק אם המאגר לא מתארח בכתובת www.github.com. אחרת, אפשר להשמיט את הארגומנט, ובמקרה כזה ברירת המחדל תהיה https://api.github.com/.
שימוש במזהה האפליקציה
```
kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
  --namespace=config-management-system \
  --from-literal=github-app-application-id=APPLICATION_ID \
  --from-literal=github-app-installation-id=INSTALLATION_ID \
  --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
  --from-literal=github-app-base-url=BASE_URL
```
- מחליפים את APPLICATION_ID במזהה האפליקציה של אפליקציית GitHub.
- מחליפים את INSTALLATION_ID במזהה ההתקנה של אפליקציית GitHub.
- מחליפים את /path/to/GITHUB_PRIVATE_KEY בשם הקובץ שמכיל את המפתח הפרטי.
- מחליפים את הערך BASE_URL בכתובת ה-URL הבסיסית של נקודת קצה ל-API של GitHub. הפרמטר הזה נדרש רק אם המאגר לא מתארח בכתובת www.github.com. אחרת, אפשר להשמיט את הארגומנט, ובמקרה כזה ברירת המחדל תהיה https://api.github.com/.
מוחקים את המפתח הפרטי מהדיסק המקומי או מגנים עליו בדרך אחרת.
כשמגדירים את סנכרון תצורות ומוסיפים את כתובת ה-URL של מאגר Git, משתמשים בסוג האימות githubapp.

הענקת הרשאת קריאה בלבד ל-סנכרון תצורות ב-OCI

לסנכרון תצורות נדרשת גישה לקריאה בלבד לתמונת ה-OCI שמאוחסנת ב-Artifact Registry, כדי שיוכל לקרוא את ההגדרות שכלולות בתמונה ולהחיל אותן על האשכולות.

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

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

חשבון שירות של Kubernetes (k8sserviceaccount)
חשבון שירות של Google ‏ (gcpserviceaccount)
חשבון השירות של Compute Engine שמוגדר כברירת מחדל (gcenode)

חשבון שירות ב-Kubernetes

אתם יכולים להשתמש בחשבון שירות של Kubernetes כסוג האימות אם אתם מאחסנים את תמונת ה-OCI ב-Artifact Registry והאשכול שלכם משתמש ב-איחוד זהויות של עומסי עבודה ל-GKE או ב-איחוד זהויות של עומסי עבודה ל-GKE.

מעניקים את תפקיד הקורא ב-Artifact Registry ‏ (roles/artifactregistry.reader) ב-IAM לחשבון השירות של Kubernetes עם מאגר איחוד זהויות של עומסי עבודה ל-GKE. מידע נוסף על תפקידים והרשאות ב-Artifact Registry זמין במאמר הגדרת תפקידים והרשאות ב-Artifact Registry.
- כדאי להעניק הרשאה ברמת הפרויקט אם אותן הרשאות חלות על כל המאגרים בפרויקט.
```
gcloud projects add-iam-policy-binding PROJECT_ID \
      --role=roles/artifactregistry.reader \
      --member="serviceAccount:FLEET_HOST_PROJECT_ID.s3ns.svc.id.goog[config-management-system/KSA_NAME]"
```
- כדאי להעניק הרשאה ספציפית למאגר כשרוצים שלחשבונות שירות יהיו רמות גישה שונות לכל מאגר בפרויקט.
```
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
   --location=LOCATION \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:FLEET_HOST_PROJECT_ID.s3ns.svc.id.goog[config-management-system/KSA_NAME]" \
   --project=PROJECT_ID
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫PROJECT_ID: מזהה הפרויקט של הארגון.
- ‫FLEET_HOST_PROJECT_ID: אם אתם משתמשים באיחוד זהויות של עומסי עבודה ל-GKE, הערך הזה זהה לערך של PROJECT_ID. אם אתם משתמשים באיחוד זהויות של עומסי עבודה ל-GKE, זהו מזהה הפרויקט של ה-fleet שהאשכול רשום בו.
- ‫KSA_NAME: חשבון השירות של Kubernetes עבור ה-reconciler.
  - אם שם מאגר הבסיס (root) הוא RootSync, משתמשים ב-root-reconciler.root-sync אחרת, משתמשים ב-root-reconciler-ROOT_SYNC_NAME. אם מתקינים את סנכרון תצורות באמצעות מסוף Cloud de Confiance או Google Cloud CLI,‏ סנכרון תצורות יוצר באופן אוטומטי אובייקט RootSync בשם root-sync.
- ‫REPOSITORY: מזהה המאגר.
- ‫LOCATION: המיקום האזורי או הרב-אזורי של המאגר.
הערה: כדי ליצור את קישור המדיניות הזה, צריך את ההרשאה iam.serviceAccounts.setIamPolicy.

חשבון השירות של Compute Engine שמוגדר כברירת מחדל

אם אתם מאחסנים את תרשים Helm ב-Artifact Registry והאשכול שלכם הוא GKE עם איחוד זהויות של עומסי עבודה ל-GKE מושבת, אתם יכולים להשתמש ב-gcenode כסוג האימות. ‫סנכרון תצורות משתמש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine. צריך להעניק לחשבון השירות שמוגדר כברירת המחדל ב-Compute Engine גישת קריאה ל-Artifact Registry.

מריצים את הפקודה הבאה כדי להעניק לחשבון השירות של Compute Engine הרשאת קריאה ל-Artifact Registry:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
   --member=serviceAccount:PROJECT_NUMBER-compute@developer.s3ns-system.iam.gserviceaccount.com \
   --role=roles/artifactregistry.reader
```
מחליפים את PROJECT_ID במזהה הפרויקט של הארגון, ואת PROJECT_NUMBER במספר הפרויקט של הארגון.

הגדרת סנכרון תצורות לרשות אישורים

בשרתים שהוגדרו עם אישורים מרשות אישורים (CA) שלא נחשבת למהימנה, אפשר להגדיר את סנכרון תצורות כך שישתמש באישור CA כדי לאמת חיבורי HTTPS לשרת. המאפיין הזה נתמך בשרתי Git,‏ Helm או OCI. אישור ה-CA צריך לכלול אישורי SSL מלאים (בסיס/ביניים/קצה). אם השרת שלכם כבר משתמש ב-CA מהימן או שאתם לא מתחברים דרך HTTPS, אתם יכולים לדלג על השלב הזה ולהשאיר את caCertSecretRef ללא הגדרה.

`RootSync`

מאחזרים את אישור ה-CA ששימש להנפקת האישור לשרת Git ושומרים אותו בקובץ.

עבור אובייקטים מסוג RootSync, צריך ליצור את הסוד במרחב השמות config-management-system. לדוגמה:

kubectl create ns config-management-system && 

kubectl create secret generic ROOT_CA_CERT_SECRET_NAME 

 --namespace=config-management-system 

 --from-file=cert=/path/to/CA_CERT_FILE

כשמגדירים את סנכרון תצורות, מגדירים את הערך של השדה caCertSecretRef.name באובייקט RootSync ל-ROOT_CA_CERT_SECRET_NAME.

`RepoSync`

מאחזרים את אישור ה-CA ששימש להנפקת האישור לשרת Git ושומרים אותו בקובץ.

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

kubectl create ns REPO_SYNC_NAMESPACE && 

kubectl create secret generic NAMESPACE_CA_CERT_SECRET_NAME 

 --namespace=REPO_SYNC_NAMESPACE 

 --from-file=cert=/path/to/CA_CERT_FILE

כשמגדירים את RepoSync, צריך להגדיר את הערך של השדה caCertSecretRef.name באובייקט RepoSync כ-NAMESPACE_CA_CERT_SECRET_NAME.

הענקת הרשאת קריאה בלבד ל-Helm ל-סנכרון תצורות

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

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

אבל רוב המשתמשים צריכים ליצור פרטי כניסה כדי לגשת למאגרי Helm פרטיים. ‫סנכרון תצורות תומך במנגנוני האימות הבאים:

טוקן (token)
חשבון שירות של Kubernetes (k8sserviceaccount)
חשבון שירות של Google ‏ (gcpserviceaccount)
חשבון השירות של Compute Engine שמוגדר כברירת מחדל (gcenode)

אסימון

יוצרים Secret עם שם משתמש וסיסמה של מאגר Helm:

kubectl create secret generic SECRET_NAME \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
    --from-literal=password=PASSWORD

מחליפים את מה שכתוב בשדות הבאים:

‫SECRET_NAME: השם שרוצים לתת לסוד.
‫USERNAME: שם המשתמש במאגר Helm.
‫PASSWORD: הסיסמה למאגר Helm.

כשמגדירים את סנכרון תצורות, משתמשים בשם הסוד שבחרתם בשביל spec.helm.secretRef.name.

חשבון שירות ב-Kubernetes

אם שומרים את תרשים Helm ב-Artifact Registry והאשכול משתמש ב-איחוד זהויות של עומסי עבודה ל-GKE או ב-איחוד זהויות של עומסי עבודה ל-GKE, אפשר להשתמש בחשבון שירות של Kubernetes כסוג האימות.

מעניקים את תפקיד הקורא ב-Artifact Registry ‏ (roles/artifactregistry.reader) ב-IAM לחשבון השירות של Kubernetes עם מאגר איחוד זהויות של עומסי עבודה ל-GKE. מידע נוסף על תפקידים והרשאות ב-Artifact Registry זמין במאמר הגדרת תפקידים והרשאות ב-Artifact Registry.
- כדאי להעניק הרשאה ברמת הפרויקט אם אותן הרשאות חלות על כל המאגרים בפרויקט.
```
gcloud projects add-iam-policy-binding PROJECT_ID \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:FLEET_HOST_PROJECT_ID.s3ns.svc.id.goog[config-management-system/KSA_NAME]"
```
- כדאי להעניק הרשאה ספציפית למאגר כשרוצים שלחשבונות שירות יהיו רמות גישה שונות לכל מאגר בפרויקט.
```
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
   --location=LOCATION \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:FLEET_HOST_PROJECT_ID.s3ns.svc.id.goog[config-management-system/KSA_NAME]" \
   --project=PROJECT_ID
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫PROJECT_ID: מזהה הפרויקט של הארגון.
- ‫FLEET_HOST_PROJECT_ID: אם אתם משתמשים באיחוד זהויות של עומסי עבודה ל-GKE, הערך הזה זהה לערך של PROJECT_ID. אם אתם משתמשים באיחוד זהויות של עומסי עבודה ל-GKE, זהו מזהה הפרויקט של ה-fleet שהאשכול רשום בו.
- ‫KSA_NAME: חשבון השירות של Kubernetes עבור ה-reconciler.
  - אם שם מאגר הבסיס (root) הוא RootSync, משתמשים ב-root-reconciler.root-sync אחרת, משתמשים ב-root-reconciler-ROOT_SYNC_NAME.
- ‫REPOSITORY: מזהה המאגר.
- ‫LOCATION: המיקום האזורי או הרב-אזורי של המאגר.

חשבון השירות של Compute Engine שמוגדר כברירת מחדל

נותנים לחשבון השירות של Compute Engine הרשאת קריאה ל-Artifact Registry:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:PROJECT_NUMBER-compute@developer.s3ns-system.iam.gserviceaccount.com \
    --role=roles/artifactregistry.reader
```
מחליפים את PROJECT_ID במזהה הפרויקט של הארגון, ואת PROJECT_NUMBER במספר הפרויקט של הארגון.

הגדרת סנכרון תצורות

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

אם אתם משתמשים ב-Config Sync admission webhook (ה-admission webhook מושבת כברירת מחדל) ומתקינים את Config Sync באשכול פרטי, צריך להוסיף כלל חומת אש כדי לאפשר את היציאה 10250. ה-webhook של סנכרון תצורות admission משתמש ביציאה 10250 למניעת סטיות.

מחכים עד ש-CRD‏ RootSync ו-CRD‏ RepoSync יהיו זמינים:

until kubectl get customresourcedefinitions rootsyncs.configsync.gke.io reposyncs.configsync.gke.io; do date; sleep 1; echo ""; done

שומרים אחד מהקובצי המניפסט הבאים בשם root-sync.yaml. משתמשים בגרסת המניפסט שמתאימה לסוג המקור של ההגדרות.
Git
```
# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: ROOT_REPOSITORY
    revision: ROOT_REVISION
    branch: ROOT_BRANCH
    dir: ROOT_DIRECTORY
    auth: ROOT_AUTH_TYPE
    gcpServiceAccountEmail: ROOT_EMAIL
    secretRef:
      name: ROOT_SECRET_NAME
    noSSLVerify: ROOT_NO_SSL_VERIFY
    caCertSecretRef:
      name: ROOT_CA_CERT_SECRET_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ROOT_SYNC_NAME: מוסיפים את השם של אובייקט RootSync.
- ROOT_REPOSITORY: מוסיפים את כתובת ה-URL של מאגר Git לשימוש כמאגר הבסיסי. אפשר להזין כתובות URL באמצעות פרוטוקול HTTPS או פרוטוקול SSH. לדוגמה, https://github.com/GoogleCloudPlatform/anthos-config-management-samples משתמש בפרוטוקול HTTPS. חובה למלא את השדה הזה.
- ‫ROOT_REVISION: מוסיפים את הגרסה של Git (תג או גיבוב) או את ההסתעפות שממנה רוצים לסנכרן. השדה הזה הוא אופציונלי וערך ברירת המחדל שלו הוא HEAD. כשמשתמשים בגיבוב, הוא חייב להיות גיבוב מלא ולא קיצור.
- ‫ROOT_BRANCH: מוסיפים את ההסתעפות של המאגר שממנו רוצים לסנכרן. השדה הזה הוא אופציונלי וערך ברירת המחדל הוא master. מומלץ להשתמש בשדה revision כדי לציין שם של ענף, כדי לפשט את התהליך. אם מציינים גם את השדה revision וגם את השדה branch, השדה revision מקבל עדיפות על פני השדה branch.
- ROOT_DIRECTORY: מוסיפים את הנתיב במאגר Git לספריית הבסיס שמכילה את ההגדרה שרוצים לסנכרן. השדה הזה הוא אופציונלי, וערך ברירת המחדל הוא ספריית הבסיס (/) של המאגר.
- ‫ROOT_AUTH_TYPE: מוסיפים אחד מסוגי האימות הבאים:
  - ‫none: לא להשתמש באימות
  - ‫ssh: שימוש בזוג מפתחות SSH
  - cookiefile: שימוש ב-cookiefile
  - ‫token: שימוש בטוקן
  - ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת ל-Cloud Source Repositories.
  - ‫gcenode: שימוש בחשבון שירות של Google כדי לגשת אל Cloud Source Repositories. בוחרים באפשרות הזו רק אם איחוד זהויות של עומסי עבודה ל-GKE לא מופעל באשכול.
  מידע נוסף על סוגי האימות האלה זמין במאמר בנושא הענקת גישת קריאה בלבד ל-Git ב-סנכרון תצורות.
  
  חובה למלא את השדה הזה.
- ‫ROOT_EMAIL: אם הוספתם את gcpserviceaccount כROOT_AUTH_TYPE, צריך להוסיף את כתובת האימייל של חשבון השירות שלכם ב-Google. לדוגמה, acm@PROJECT_ID.s3ns.iam.gserviceaccount.com.
- ‫ROOT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, צריך להוסיף את המפתח הציבורי של הסוד לספק Git. השדה הזה הוא אופציונלי.
- ‫ROOT_NO_SSL_VERIFY: כדי להשבית את האימות של אישור ה-SSL, מגדירים את השדה הזה לערך true. ערך ברירת המחדל הוא false.
- ‫ROOT_CA_CERT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, ספק Git צריך להשתמש באישור שהונפק על ידי רשות האישורים (CA) הזו. הסוד חייב להכיל את אישור רשות האישורים (CA) תחת מפתח בשם cert. השדה הזה אופציונלי.
  
  מידע נוסף על הגדרת אובייקט Secret לאישור CA זמין במאמר הגדרת רשות אישורים
הסבר על השדות ורשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעים במאמר שדות RootSync.

קובץ המניפסט הזה יוצר אובייקט RootSync שמשתמש ב-Git כמקור.
OCI
```
# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: oci
  sourceFormat: unstructured
  oci:
    image: ROOT_IMAGE
    dir: ROOT_DIRECTORY
    auth: ROOT_AUTH_TYPE
    gcpServiceAccountEmail: ROOT_EMAIL
    caCertSecretRef:
      name: ROOT_CA_CERT_SECRET_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ROOT_SYNC_NAME: מוסיפים את השם של אובייקט RootSync.
- ‫ROOT_IMAGE: כתובת ה-URL של תמונת OCI שבה רוצים להשתמש כמאגר הבסיס, לדוגמה LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. כברירת מחדל, התמונה נמשכת מהתג latest, אבל אפשר למשוך תמונות באמצעות התגים TAG או DIGEST. מציינים TAG או DIGEST במאפיין PACKAGE_NAME:
  - כדי למשוך לפי TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
  - כדי למשוך לפי DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
זהירות: סנכרון תצורות דורש ששכבת ה-OCI תידחס בפורמט tar או tar+gzip. פורמטים אחרים (לדוגמה, tar+bz2) לא יזוהו על ידי סנכרון תצורות. מעבר מ-REPO תקין לתמונת OCI עם פורמט לא נתמך יגרום לגיזום של משאבים מנוהלים ללא שגיאה.
- ‫ROOT_DIRECTORY: מוסיפים את הנתיב במאגר לספריית הרמה הבסיסית (root) שמכילה את ההגדרה שרוצים לסנכרן. השדה הזה הוא אופציונלי, וערך ברירת המחדל הוא ספריית הבסיס (/) של המאגר.
- ‫ROOT_AUTH_TYPE: מוסיפים אחד מסוגי האימות הבאים:
  - ‫none: לא להשתמש באימות
  - ‫gcenode: שימוש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine כדי לגשת לאימג' ב-Artifact Registry. בוחרים באפשרות הזו רק אם התכונה איחוד זהויות של עומסי עבודה ל-GKE לא מופעלת באשכול.
  - ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת לתמונה.
  חובה למלא את השדה הזה.
- ‫ROOT_EMAIL: אם הוספתם את gcpserviceaccount כROOT_AUTH_TYPE, צריך להוסיף את כתובת האימייל של חשבון השירות שלכם ב-Google. לדוגמה, acm@PROJECT_ID.s3ns.iam.gserviceaccount.com.
- ‫ROOT_CA_CERT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, ספק OCI צריך להשתמש באישור שהונפק על ידי רשות האישורים (CA) הזו. הסוד חייב להכיל את אישור רשות האישורים (CA) תחת מפתח בשם cert. השדה הזה אופציונלי.
מידע נוסף על הגדרת אובייקט Secret לאישור CA זמין במאמר הגדרת רשות אישורים

הסבר על השדות ורשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעים במאמר שדות RootSync.

קובץ המניפסט הזה יוצר אובייקט RootSync שמשתמש בתמונה של OCI כמקור.
Helm
```
# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: helm
  sourceFormat: unstructured
  helm:
    repo: ROOT_HELM_REPOSITORY
    chart: HELM_CHART_NAME
    version: HELM_CHART_VERSION
    releaseName: HELM_RELEASE_NAME
    namespace: HELM_RELEASE_NAMESPACE
    values:
      foo:
        bar: VALUE_1
      baz:
      - qux: VALUE_2
        xyz: VALUE_3
    includeCRDs: HELM_INCLUDE_CRDS
    auth: ROOT_AUTH_TYPE
      gcpServiceAccountEmail: ROOT_EMAIL
      secretRef:
        name: ROOT_SECRET_NAME
    caCertSecretRef:
      name: ROOT_CA_CERT_SECRET_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ROOT_SYNC_NAME: מוסיפים את השם של אובייקט RootSync.
- ‫ROOT_HELM_REPOSITORY: כתובת ה-URL של מאגר Helm שמשמש כמאגר הבסיס. אפשר להזין כתובות URL באמצעות פרוטוקול HTTPS או פרוטוקול SSH. לדוגמה, https://github.com/GoogleCloudPlatform/anthos-config-management-samples משתמש בפרוטוקול HTTPS. חובה למלא את השדה הזה.
- ‫HELM_CHART_NAME: מוסיפים את השם של תרשים Helm. חובה למלא את השדה הזה.
- ‫HELM_CHART_VERSION: הגרסה של התרשים. השדה הזה הוא אופציונלי. אם לא תציינו ערך, נשתמש בגרסה האחרונה.
- ‫HELM_RELEASE_NAME: השם של מהדורת Helm. השדה הזה הוא אופציונלי.
- ‫HELM_RELEASE_NAMESPACE: מרחב השמות של היעד לגרסה. היא מגדירה מרחב שמות רק למשאבים שמכילים את namespace: {{ .Release.Namespace }} בתבניות שלהם. השדה הזה הוא אופציונלי. אם לא תציינו ערך, נשתמש במרחב השמות שמוגדר כברירת מחדל config-management-system.
- ‫HELM_INCLUDE_CRDS: צריך להגדיר את הערך true אם רוצים שתבנית Helm תיצור גם CustomResourceDefinition. השדה הזה הוא אופציונלי. אם לא תציינו ערך, ברירת המחדל היא false ולא ייווצר CRD.
- ‫VALUE: ערכים לשימוש במקום ערכי ברירת המחדל שמצורפים לתרשים Helm. הפורמט של השדה הזה צריך להיות זהה לפורמט של קובץ values.yaml של תרשים helm. השדה הזה הוא אופציונלי.
- ‫ROOT_AUTH_TYPE: מוסיפים אחד מסוגי האימות הבאים:
  - ‫none: לא להשתמש באימות
  - ‫token: משתמשים בשם משתמש ובסיסמה כדי לגשת למאגר Helm פרטי.
  - ‫gcenode: שימוש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine כדי לגשת לאימג' ב-Artifact Registry. בוחרים באפשרות הזו רק אם התכונה איחוד זהויות של עומסי עבודה ל-GKE לא מופעלת באשכול.
  - ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת לתמונה.
  חובה למלא את השדה הזה.
- ‫ROOT_EMAIL: אם הוספתם את gcpserviceaccount כROOT_AUTH_TYPE, צריך להוסיף את כתובת האימייל של חשבון השירות שלכם ב-Google. לדוגמה, acm@PROJECT_ID.s3ns.iam.gserviceaccount.com.
- ‫ROOT_SECRET_NAME: מוסיפים את השם של הסוד אם token הוא ROOT_AUTH_TYPE. השדה הזה הוא אופציונלי.
- ‫ROOT_CA_CERT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, ספק Helm שלכם חייב להשתמש באישור שהונפק על ידי רשות האישורים (CA) הזו. הסוד חייב להכיל את אישור רשות האישורים (CA) תחת מפתח בשם cert. השדה הזה אופציונלי.
מידע נוסף על הגדרת אובייקט Secret לאישור CA זמין במאמר הגדרת רשות אישורים

הסבר על השדות ורשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעים במאמר שדות RootSync.

קובץ המניפסט הזה יוצר אובייקט RootSync שמשתמש ב-Helm כמקור.
מחילים את השינויים:
```
kubectl apply -f root-sync.yaml
```

אימות סטטוס הסנכרון של מאגר הבסיס

אפשר להשתמש בפקודה nomos status כדי לבדוק את סטטוס הסנכרון של מאגר הבסיס:

nomos status

הפלט אמור להיראות כך:

my_managed_cluster-1
  --------------------
  <root>   git@github.com:foo-corp/acme/admin@main
  SYNCED   f52a11e4

אימות ההתקנה של RootSync

כשיוצרים אובייקט RootSync, ‏ סנכרון תצורות יוצר כלי לתיקון שגיאות עם הקידומת root-reconciler. תהליך הגישור הוא Pod שמתבצע כפריסה. הוא מסנכרן מניפסטים ממאגר Git לאשכול.

כדי לוודא שאובייקט RootSync פועל בצורה תקינה, בודקים את הסטטוס של הפריסה של root-reconciler:

kubectl get -n config-management-system deployment \
    -l configsync.gke.io/sync-name=ROOT_SYNC_NAME

מחליפים את ROOT_SYNC_NAME בשם של RootSync.

הפלט אמור להיראות כך:

NAME              READY   UP-TO-DATE   AVAILABLE   AGE
root-reconciler   1/1     1            1           3h42m

במאמר מעקב אחרי אובייקטים של RootSync ו-RepoSync מוסבר על דרכים נוספות לבדיקת הסטטוס של אובייקט RootSync.

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

שדרוג סנכרון תצורות

השלבים לשדרוג סנכרון תצורות תלויים בגרסה שמשדרגים אליה ובגרסה שממנה משדרגים. החל מגרסה 1.20.0, ‏ סנכרון תצורות מסופק כהתקנה עצמאית ללא ConfigManagement Operator. אם אתם משדרגים מגרסה קודמת לגרסה 1.20.0 או לגרסה מאוחרת יותר, אתם צריכים קודם להסיר את ConfigManagement Operator לפני השדרוג.

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

הסרת האופרטור ConfigManagement

אם אתם משדרגים מגרסה שלפני 1.20.0 לגרסה 1.20.0 ואילך, אתם צריכים להסיר קודם את ConfigManagement Operator לפני השדרוג.

כדי לבדוק אם Config Management מותקן באשכול, מריצים את הפקודה הבאה:

kubectl get configmanagement

אם הפלט לא ריק, Config Management מותקן באשכול. כדי להסיר את Config Management, מבצעים את השלבים הבאים להסרת Config Management, אבל משאירים את סנכרון תצורות מותקן באשכול. מומלץ להשתמש ב-nomos CLI כדי להסיר את ConfigManagement Operator כי יש לו ממשק עשיר יותר וטיפול שגיאות חזק יותר. כדאי להשתמש בסקריפט מעטפת רק אם אין לכם גישה אל nomos CLI.

nomos (מומלץ)

מוודאים שמשתמשים בגרסה העדכנית של nomos CLI.
מריצים את הפקודה הבאה כדי לעדכן את האשכול בהקשר הנוכחי של kubectl:
```
nomos migrate --remove-configmanagement
```

shell script

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

 #!/bin/bash

 set -euox pipefail

 hnc_enabled="$(kubectl get configmanagements.configmanagement.gke.io config-management -o=jsonpath="{.spec.hierarchyController.enabled}" --ignore-not-found)"

 if [[ "${hnc_enabled}" == "true" ]]; then
   echo "Hierarchy Controller is enabled on the ConfigManagement object. It must be disabled before migrating."
   echo "This can be done by unsetting the spec.hierarchyController field on ConfigManagement."
   exit 1
 fi

 kubectl delete deployment -n config-management-system config-management-operator --ignore-not-found --cascade=foreground

 if kubectl get configmanagement config-management &> /dev/null ; then
   kubectl patch configmanagement config-management --type="merge" -p '{"metadata":{"finalizers":[]}}'
   kubectl delete configmanagement config-management --cascade=orphan --ignore-not-found
 fi

 kubectl delete clusterrolebinding config-management-operator --ignore-not-found
 kubectl delete clusterrole config-management-operator --ignore-not-found
 kubectl delete serviceaccount -n config-management-system config-management-operator --ignore-not-found
 kubectl delete customresourcedefinition configmanagements.configmanagement.gke.io --ignore-not-found

התקנת הגרסה החדשה של סנכרון תצורות

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

מורידים את המניפסט של סנכרון תצורות ואת הפקודות של גרסה חדשה.nomos
מחילוץ הארכיון:
```
tar -xzvf config-sync.tar.gz
```
באמצעות ההוראות שבקובץ README.md שסופק, עורכים את ההתאמה האישית בארכיון שחולץ בשלב הקודם.

הערה: עריכת kustomization.yaml נדרשת עבור הגדרות מסוימות, למשל הגדרת שם אשכול לשימוש עם ClusterSelector או הכללת קובץ admission-webhook.yaml לשימוש עם מניעת סחף.
כדי לעדכן את ההתקנה של סנכרון תצורות, מפעילים את המניפסט שעבר רינדור שיצרתם לפי README.md ההוראות:
```
kubectl apply -f CONFIG_SYNC_MANIFEST
```
מחליפים את CONFIG_SYNC_MANIFEST בשם של המניפסט שעבר רינדור.
מחליפים את הפקודה nomos בכל הלקוחות בגרסה החדשה. השינוי הזה מבטיח שהפקודה nomos תמיד תוכל לקבל את הסטטוס של כל האשכולות הרשומים ולאמת את ההגדרות שלהם.

הסרת ההתקנה של סנכרון תצורות

כדי להסיר את סנכרון תצורות, מבצעים את השלבים הבאים:

אדמין מרכזי צריך להסיר את מאגר הבסיס:
1. אם הפעלתם את ה-webhook ואתם רוצים לשמור את המשאבים, צריך להשבית את מניעת הסחף למשאבים שהוצאו משימוש. אם לא הפעלתם את ה-webhook, לא צריך לבצע פעולות נוספות כדי לשמור את המשאבים.
2. מריצים את הפקודה הבאה כדי למחוק את האובייקט RootSync:
```
kubectl delete -f root-sync.yaml
```
הסרת מאגרי מידע
אפשר גם להסיר את סנכרון תצורות באמצעות קובצי המניפסט ששימשו להתקנתו.
```
   kubectl delete -f CONFIG_SYNC_MANIFEST --ignore-not-found
```

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

כך מגדירים סנכרון מכמה מאגרי מידע.

התקנה ידנית של סנכרון תצורות באמצעות kubectl

לפני שמתחילים

הכנת הסביבה המקומית

הכנת האשכולות

הכנת ההרשאות

רישום אשכול

פריסת סנכרון תצורות

הענקת הרשאת קריאה בלבד ל-Config Sync

הענקת הרשאת קריאה בלבד ל-סנכרון תצורות ב-Git

זוג מפתחות SSH

Cookiefile

אסימון

חשבון שירות של Google

Cloud Source Repositories

Secure Source Manager

חשבון השירות של Compute Engine שמוגדר כברירת מחדל

אפליקציית GitHub

שימוש במזהה לקוח

שימוש במזהה האפליקציה

הענקת הרשאת קריאה בלבד ל-סנכרון תצורות ב-OCI

חשבון שירות ב-Kubernetes

חשבון השירות של Compute Engine שמוגדר כברירת מחדל

הגדרת סנכרון תצורות לרשות אישורים

RootSync

RepoSync

הענקת הרשאת קריאה בלבד ל-Helm ל-סנכרון תצורות

אסימון

חשבון שירות ב-Kubernetes

חשבון השירות של Compute Engine שמוגדר כברירת מחדל

הגדרת סנכרון תצורות

Git

OCI

Helm

אימות סטטוס הסנכרון של מאגר הבסיס

אימות ההתקנה של RootSync

שדרוג סנכרון תצורות

הסרת האופרטור ConfigManagement

nomos (מומלץ)

shell script

התקנת הגרסה החדשה של סנכרון תצורות

הסרת ההתקנה של סנכרון תצורות

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

`RootSync`

`RepoSync`