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

הוצאנו משימוש את הסוכן להפעלת קונטיינרים ב-Compute Engine. הסוכן הזה מאפשר לכם לפרוס קונטיינרים במכונות ב-Compute Engine כשאתם יוצרים מכונות וירטואליות.

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

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

אם רוצים להמשיך להריץ קונטיינרים במכונות וירטואליות ובקבוצות של מכונות וירטואליות לניהול מופעים (MIG) נפרדות, צריך להשתמש בסקריפטים להפעלה או ב-cloud-init.
אם יש לכם אפליקציות בקונטיינרים בלי שמירת מצב ועבודות קטנות עד בינוניות, כדאי להשתמש ב-Cloud Run.
אם הקונטיינר הוא משימה באצווה עם מצב סיום מוגדר ונדרשים משאבי מחשוב נוספים, צריך להשתמש ב-Batch.
אם אתם צריכים שליטה מתקדמת ומדרגיות, או אם אתם לא יכולים לעמוד בדרישות שלכם באמצעות האפשרויות האחרות, אתם יכולים להשתמש ב-GKE ב-Google Cloud.

תרחישי שימוש נוספים ופתרונות חלופיים מפורטים במאמר השוואה בין אפשרויות הפריסה של מאגרי תגים.

אפשרויות שהוצאו משימוש להגדרת מאגרי תגים במכונות וירטואליות

כשמגדירים קונטיינר במהלך יצירת מכונת VM,‏ Compute Engine משתמש בסוכן להפעלת קונטיינרים כדי לקרוא את המטא-נתונים של gce-container-declaration שמאחסנים את פרטי הקונטיינר, וכדי לפרוס את הקונטיינר במכונת ה-VM.

האפשרויות הבאות לפריסת קונטיינרים ישירות במכונה וירטואלית או בקבוצת מופעים מנוהלת שמשתמשות בסוכן להפעלת קונטיינרים וב-gce-container-metadata הוצאו משימוש.

המסוף

האפשרות Deploy container בדף Create an instance הוצאה משימוש:

האפשרות 'פריסת מאגר תגים'.

gcloud

הפקודות הבאות של gcloud להגדרת קונטיינר במכונה וירטואלית או בתבנית של הגדרות מכונה הוצאו משימוש:

gcloud compute instances create-with-container
gcloud compute instances update-container
gcloud compute instance-templates create-with-container
הפקודה gcloud compute instances create שמשתמשת בדגל --metadata כדי להגדיר את מפתח המטא-נתונים gce-container-declaration
הפקודה gcloud compute instance-templates create שמשתמשת בדגל --metadata כדי להגדיר את מפתח המטא-נתונים gce-container-declaration

Terraform

הוצאנו משימוש את מודול Terraform‏ gce-container ואת מפתח המטא-נתונים gce-container-declaration להגדרת קונטיינרים.

זיהוי מקרים שבהם נעשה שימוש במטא-נתונים של מאגר שהוצא משימוש

כדי לזהות מופעים בפרויקט שמשתמשים במטא-נתונים של מאגר שיצא משימוש, צריך לבצע את השלבים הבאים כדי לבדוק אם מוגדר מפתח המטא-נתונים gce-container-declaration:

מריצים אחת מהפקודות הבאות:
- כדי להציג רשימה של כל המכונות בפרויקט שמשתמשות במפתח ובערך המטא-נתונים gce-container-declaration, מריצים את הפקודה הבאה ב-Google Cloud CLI:
```
gcloud compute instances list --filter="metadata.items.key:gce-container-declaration"
```
  הפקודה הזו מספקת רשימה של כל מכונות ה-VM בפרויקט שהגדרתם שמכילות את מפתח המטא-נתונים gce-container-declaration. מפתח המטא-נתונים מזהה באופן ייחודי מכונות וירטואליות שנכללות בהיקף של הוצאת המוצר משימוש. אם אתם משתמשים בכמה פרויקטים, מריצים את הפקודה הזו בכל הפרויקטים הפעילים.
- כדי לאמת מופע ספציפי, מריצים את הפקודה הבאה ב-CLI של Google Cloud:
```
gcloud compute instances describe VM_NAME --format="(metadata.items)"
```
  מחליפים את VM_NAME בשם של מופע המכונה הווירטואלית שרוצים לאמת.
אם בפלט של הפקודה מהשלב הקודם מופיעות דוגמאות לשימוש במפתח המטא-נתונים gce-container-declaration, מריצים את הפקודה הבאה כדי לקבל פרטים נוספים על הצהרת הקונטיינר במכונות הווירטואליות:
```
gcloud compute instances list \
  --filter='metadata.items.key:gce-container-declaration AND (metadata.items.value~"image:")' \
  --format="table(name, zone, metadata.items.filter(key='gce-container-declaration').extract(value).slice(0):label=CONTAINER_DECLARATION)"
```
על סמך הפלט של הפקודה, כדאי לשים לב לנקודות הבאות:
- אם המטא-נתונים מכילים את ההגדרה של סוכן הפעלת מאגר התגים שהוצא משימוש, צריך להעביר את פריסת מאגר התגים לפתרון חלופי, כפי שמתואר במסמך הזה.
- אם מפתח המטא-נתונים gce-container-declaration קיים, אבל אתם לא משתמשים בו לסוכן הפעלת המאגר, צריך לבצע את הפעולות הבאות:
  - בודקים אם נעשה שימוש חוזר במפתח המטא-נתונים הזה בהגדרות אחרות.
  - אם משתמשים מחדש במפתח, צריך להשתמש במפתח מטא-נתונים אחר להגדרות אחרות.

מידע נוסף על הצגת מטא-נתונים זמין במאמר הצגה של מטא-נתונים והפעלת שאילתות עליהם.

השוואה בין אפשרויות הפריסה של מאגרי תגים

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

תרחישים לדוגמה	סוג ההחלפה	עלות	פתרון מומלץ
להמשיך להריץ את הקונטיינר במכונה וירטואלית או בקבוצת מופעים מנוהלת. פחות מכירים פתרונות ללא שרת או פתרונות מנוהלים. מריצים מאגר לבדיקות ולפיתוח. עומס העבודה מורכב ממכונה וירטואלית אחת. הפעלת מאגר הנתונים במצב הרשאה.	החלפה ישירה	ללא עלות נוספת	שימוש בסקריפטים לטעינה בזמן ההפעלה כדי לפרוס קונטיינרים במכונות וירטואליות.
להמשיך להריץ את הקונטיינר במכונה וירטואלית או בקבוצת מופעים מנוהלת. להריץ כמה קונטיינרים במכונה וירטואלית אחת. הגדרת תרחישים מתקדמים במאגרי מידע או במכונות וירטואליות. לדוגמה, ליצור משתמשים, לייבא קבצים, לטעון דיסקים או להשתמש במצב הרשאות. עומס העבודה מורכב מכמה מכונות וירטואליות או קבוצות מופעים מנוהלות.	החלפה ישירה	ללא עלות נוספת	שימוש ב-`cloud-init` להרצת משימות במהלך מחזור החיים של המכונה הווירטואלית.
להריץ משימה באצווה עם מצב סיום מוגדר שדורשת משאבי מחשוב נוספים.	שירות מנוהל	תלוי במאפיינים של עומס העבודה ובמורכבות של הגדרות הקונטיינר.	Batch
הפעלת אפליקציות בלי שמירת מצב. הפעלת משימות קטנות עד בינוניות.	שירות מנוהל	פתרון בעלות נמוכה או ללא עלות לעומסי עבודה קטנים יותר.	Cloud Run
כבר יש לכם אשכול GKE. אתם צריכים שליטה מתקדמת ויכולת הרחבה.	שירות מנוהל	תלוי במאפיינים של עומס העבודה ובמורכבות של הגדרת הקונטיינר.	Google Kubernetes Engine

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

מכונות וירטואליות שמופעלת בהן מערכת הפעלה שמותאמת לקונטיינרים: אתם מקבלים בעלות מלאה על ההגדרה, התצורה, האבטחה והתחזוקה של מכונות וירטואליות וזמני ריצה של קונטיינרים, ולרוב זה כולל סקריפטים עם סקריפטים להפעלה או cloud-init.
‫Cloud Run או Batch: מוודאים שהאפליקציות הן stateless ומתאימות למודל הביצוע מבוסס-הבקשות או מבוסס-העבודות. הגישה הזו עשויה לכלול התאמה של אפליקציות כדי שיפעלו עם שירותים חיצוניים לניהול מצב.
‫GKE: אימוץ עקרונות Kubernetes, הגדרת עומסי עבודה באמצעות קובצי מניפסט של Kubernetes וניהול משאבי האשכול.

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

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

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

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

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

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

מיפוי המטא נתונים של מאגר התגים לפקודה `docker run`

אפשר למפות את המטא-נתונים של המכונה הווירטואלית או את gcloudהדגלים לטיעונים של docker run ולכלול את המיפוי הזה בסקריפט לטעינה בזמן ההפעלה ליצירת מכונות וירטואליות.

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

  # Get your existing VM instance configuration in yaml format
  gcloud compute instances describe VM_NAME --format="(metadata.items)"

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

  metadata:
    items:
    - key: gce-container-declaration
      value: |
        spec:
          containers:
          - args:
            - '"hello world!"'
            command:
            - echo
            env:
            - name: ONE
              value: '1'
            image: docker.io/library/busybox
            name: my-instance
            securityContext:
              privileged: true
            stdin: true
            tty: true
          restartPolicy: Always
    - key: google-logging-enabled
      value: 'true'

אתם יכולים להיעזר בטבלה הבאה כדי למפות מפרט קיים לפקודות docker run:

דגל Google Cloud CLI	מפתח מטא-נתונים של מכונה וירטואלית	פקודת Docker run
`--container-image`	`containers.image`	מציינים אותו כארגומנט בלי דגל. לדוגמה: `docker run gcr.io/google-containers/busybox`
`--container-command`	`command`	מציינים את הארגומנט ללא דגל, אחרי שם קובץ האימג' בקונטיינר. לדוגמה: `docker run gcr.io/google-containers/busybox echo "hello world"`
`--container-arg`	`args`	מציינים אותו כארגומנט ללא דגל, אחרי הפקודה. לדוגמה: `docker run gcr.io/google-containers/busybox echo "hello world"`
`--container-env`	`containers.env array`	`--env KEY=VALUE [--env KEY=VALUE ...]`
`--container-restart-policy`	`restartPolicy`	`--restart` הערכים האפשריים הם `no`,‏ `on-failure` ו-`always`. ברירת המחדל היא `no`.
`--container-stdin`	`containers.stdin`	`-i` תכונה ניסיונית בוליאנית, הערך שלה הוא true אם היא קיימת, ו-false כברירת מחדל.
`--container-tty`	`containers.tty`	`-t` תכונה ניסיונית בוליאנית, הערך שלה הוא true אם היא קיימת, ו-false כברירת מחדל.
`--container-privileged`	`containers.securityContext.privileged`	`--privileged` תכונה ניסיונית בוליאנית, הערך שלה הוא true אם היא קיימת, ו-false כברירת מחדל.
`--container-mount-disk`	-	אין פקודה מקבילה ל-`docker run`. אפשר לחבר את הדיסק בנפרד.

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

בדוגמאות הבאות אפשר לראות איך לכלול את הפקודות docker בסקריפט ההפעלה:

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

דוגמה 1

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

#!/bin/bash

# A name for the container
CONTAINER_NAME="my-app-container"

# Stop and remove the container if it exists
docker stop $CONTAINER_NAME || true
docker rm $CONTAINER_NAME || true

# Pull the latest version of the container image from Docker Hub
docker pull busybox:latest

# Run docker container from image in docker hub
docker run busybox:latest \
  echo "hello world!"

דוגמה 2

הפעלת קונטיינר של שרת אינטרנט במכונה וירטואלית שמבוססת על מערכת הפעלה שמותאמת לקונטיינרים:

#!/bin/bash

# Enable incoming traffic
iptables -A INPUT -j ACCEPT

# A name for the container
CONTAINER_NAME="my-app-container"

# Stop and remove the container if it exists
docker stop $CONTAINER_NAME || true
docker rm $CONTAINER_NAME || true

# Pull the latest version of the container image from Docker Hub
docker pull nginx:latest

# Run docker container from image in docker hub
docker run \
  --name=$CONTAINER_NAME \
  --privileged \
  --restart=always \
  --tty \
  --detach \
  --network="host" \
  nginx:latest

אפשרויות הגדרה נוספות לפריסת מאגרי תגים

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

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

גישה לתמונות ב-Artifact Registry

אם אתם צריכים לגשת לקובצי אימג' של קונטיינרים מ-gcr.io או מ-pkg.dev, אתם יכולים להשתמש בכלי docker-credential-gcr, שמותקן מראש במערכת הפעלה שמותאמת לקונטיינרים, ולהגדיר אימות ל-Artifact Registry עבור Docker. מריצים את הפקודה הבאה לפני שמריצים את המאגר:

  # Set home directory to save docker credentials
  export HOME=/home/appuser

  # Configure docker with credentials for gcr.io and pkg.dev
  docker-credential-gcr configure-docker

למידע נוסף, ראו הגדרת אימות ל-Artifact Registry עבור Docker.

הגדרת רישום ביומן

מומלץ להשתמש ב-Cloud Logging על ידי הפעלת סוכן רישום ביומן במכונת VM.

לחלופין, אם רוצים לשנות את מנהל יומן הרישום, אפשר לכלול את הפרמטר --log-driver בפקודה docker run:

  # Use Cloud Logging logging driver
  docker run --log-driver=gcplogs nginx:latest

מידע נוסף זמין במאמר בנושא שימוש ב-Cloud Logging עם מערכת הפעלה שמותאמת לקונטיינרים

הגדרת חומת אש פנימית

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

מידע נוסף זמין במאמר שימוש בכללים של חומת האש ב-VPC.

  # Enable all incoming and routed traffic
  iptables -A INPUT -j ACCEPT
  iptables -A FORWARD -j ACCEPT

מידע נוסף מופיע במאמר בנושא הגדרת חומת האש של המארח.

צירוף אמצעי אחסון למאגר

אם כרכים מצורפים למאגר, המטא-נתונים של המאגר כוללים את הרשומה volumes ומערך volumeMounts. ה-name של רשומה ב-volumes תואם לשם של רשומה ב-volumeMounts, ולהפך. לכל נפח שאתם אוספים, אתם צריכים לאסוף את המידע הנדרש מvolumes או מהרשומה volumeMounts.

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

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

הרכבת מערכת קבצים מסוג tmpfs

כדי לטעון מערכת קבצים ריקה של tmpfs למאגר, צריך לציין את הארגומנט --tmpfs בפקודה docker run. לדוגמה, כדי לטעון מערכת קבצים של מטמון לקונטיינר nginx, מריצים את הפקודה הבאה:

  # mount a cache file system to the nginx container
  docker run -d --name=$CONTAINER_NAME --tmpfs /var/cache/nginx:rw,size=512m,noexec,nosuid,nodev --network="host" nginx:latest

מידע נוסף על טעינת מערכות קבצים של tmpfs זמין במאמר טעינות של tmpfs.

טעינת ספרייה של מארח

כדי לטעון ספרייה ממכונה וירטואלית מארחת למאגר, מציינים את הארגומנט --mount עם הפקודה docker run:

  # mount a read-only directory to the nginx container
  docker run -d --name=$CONTAINER_NAME --mount type=bind,source=/var/www/html,target=/usr/share/nginx/html,ro nginx:latest

מידע נוסף זמין במאמר בנושא Bind mounts.

טעינת דיסק אחסון מתמיד (persistent disk) לקונטיינר

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

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

#!/bin/bash

DISK_DEVICE_NAME="my-persistent-disk" # This name MUST match the 'device-name' in the gcloud --disk flag
DISK_BY_ID_PATH="/dev/disk/by-id/google-${DISK_DEVICE_NAME}"
HOST_MOUNT_POINT="/mnt/disks/my-persistent-disk" # This is the path where the disk will be mounted on the VM
CONTAINER_MOUNT_PATH="/usr/share/my-persistent-disk" # This is the path where the disk will be mounted in the container

# format a disk as an ext4 filesystem, if it doesn't already contain one
file -sL $DISK_BY_ID_PATH | grep -q filesystem || \
        mkfs.ext4 -m 0 -E lazy_itable_init=0,lazy_journal_init=0,discard $DISK_BY_ID_PATH

# create a directory for mounting point
sudo mkdir -p "${HOST_MOUNT_POINT}"

# mount a disk to the VM
sudo mount -o defaults,discard "${DISK_BY_ID_PATH}" "${HOST_MOUNT_POINT}"

אחרי שמצמידים את הדיסק ל-VM, מוסיפים את הדגל --mount לפקודה docker run כדי להצמיד את הדיסק למאגר התגים:
```
docker run -d --name=$CONTAINER_NAME --mount type=bind,source="${HOST_MOUNT_POINT}",target="${CONTAINER_MOUNT_PATH}",readonly nginx:latest
```

יצירת מכונה וירטואלית באמצעות סקריפט לטעינה בזמן ההפעלה

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

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

המסוף

נכנסים לדף Create an instance במסוף Google Cloud .

כניסה לדף Create an instance

אם מוצגת בקשה לעשות זאת, בוחרים פרויקט ולוחצים על המשך. הדף Create an instance מופיע ובו החלונית Machine configuration.
בחלונית Machine configuration, בוחרים את משפחת המכונות ואת סוג המכונה של מכונת ה-VM.
בתפריט הניווט, לוחצים על מערכת הפעלה ואחסון. בחלונית Operating system and storage שמופיעה, מגדירים את דיסק האתחול באופן הבא:
1. לוחצים על Change. מופיעה החלונית דיסק אתחול עם הכרטיסייה Public images.
2. ברשימה Operating system בוחרים באפשרות Container Optimized OS.
3. ברשימה Version בוחרים את גרסת מערכת ההפעלה.
4. ברשימה Boot disk type בוחרים את סוג דיסק האתחול.
5. (אופציונלי) אם אתם צריכים דיסקים נוספים, מוסיפים אותם בקטע דיסקים נוספים.
6. לוחצים על בחירה.
בתפריט הניווט, לוחצים על מתקדם.
1. בקטע Automation, מדביקים את סקריפט לטעינה בזמן ההפעלה שיצרתם לפריסת הקונטיינר.
כדי ליצור את המכונה הווירטואלית ולהפעיל אותה, לוחצים על Create (יצירה).

gcloud

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

כדי ליצור מכונה וירטואלית באמצעות סקריפט לטעינה בזמן ההפעלה, מריצים את הפקודה הבאה:
```
gcloud compute instances create VM_NAME \
    --zone=ZONE \
    --image-family=IMAGE_FAMILY \
    --image-project=IMAGE_PROJECT \
    --machine-type=MACHINE_TYPE \
    --metadata-from-file=startup-script=STARTUP_SCRIPT_FILE
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫VM_NAME: name של המכונה הווירטואלית החדשה.
- ‫ZONE: האזור שבו רוצים ליצור את המכונה.
- ‫IMAGE_PROJECT: פרויקט האימג' של מערכת ההפעלה שמותאמת לקונטיינרים שמכיל את האימג', לדוגמה, cos-cloud.
- ‫IMAGE_FAMILY: משפחת התמונות של מערכת ההפעלה שמותאמת לקונטיינרים, לדוגמה, cos-stable.
- ‫MACHINE_TYPE: סוג המכונה של המכונה הווירטואלית החדשה, שיכול להיות סוג מכונה מוגדר מראש או סוג מכונה בהתאמה אישית.
- ‫STARTUP_SCRIPT_FILE: הנתיב היחסי במחשב לקובץ סקריפט לטעינה בזמן ההפעלה, לדוגמה, ./startup_script.sh.
לדוגמה:
```
# Create COS-based VM by using a startup script
gcloud compute instances create "cos-instance-with-startup-script" \
--zone="us-central1-c" \
--machine-type="e2-medium" \
--image-family="cos-stable" \
--image-project="cos-cloud" \
--metadata-from-file=startup-script="./startup_script.sh"
```
מריצים את הפקודה הבאה כדי לוודא ש-Compute Engine יצר את מכונת ה-VM:
```
gcloud compute instances describe VM_NAME
```
מחליפים את VM_NAME בשם של המכונה הווירטואלית שיצרתם.

Terraform

כדי ליצור מכונה וירטואלית, אפשר להשתמש בgoogle_compute_instance משאב.

provider "google" {
project = "PROJECT_ID"
}

resource "google_compute_instance" "cos_vm_instance" {
name         = "VM_NAME"
machine_type = "MACHINE_TYPE"
zone         = "ZONE"

# Use a Container-Optimized OS image for the boot disk
boot_disk {
  initialize_params {
    image = "IMAGE_PROJECT/IMAGE_FAMILY"
  }
}

# Attaches the instance to the default network
network_interface {
  network = "default"
}

# Specify the relative path to the startup script on your local machine
metadata = {
  startup-script = file("STARTUP_SCRIPT_FILE")
}
}

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

VM_NAME: name of the new VM
‫ZONE: האזור שבו רוצים ליצור את המכונה.
‫IMAGE_PROJECT: פרויקט האימג' של מערכת ההפעלה שמותאמת לקונטיינרים שמכיל את האימג', לדוגמה, cos-cloud.
‫IMAGE_FAMILY: משפחת התמונות של מערכת ההפעלה שמותאמת לקונטיינרים, לדוגמה, cos-stable.
‫MACHINE_TYPE: סוג המכונה של המכונה הווירטואלית החדשה, שיכול להיות סוג מכונה מוגדר מראש או סוג מכונה בהתאמה אישית.
‫STARTUP_SCRIPT_FILE: הנתיב היחסי במחשב לקובץ סקריפט לטעינה בזמן ההפעלה, לדוגמה, ./startup_script.sh.

לדוגמה:

provider "google" {
  project = "my-project"
}

resource "google_compute_instance" "my_container_vm" {
  name = "my-container-vm-startup"
  machine_type = "e2-medium"
  zone = "us-central1-a"

  boot_disk {
    initialize_params {
      image = "cos-cloud/cos-stable"
    }
  }

  network_interface {
    network = "default"
  }

  metadata = {
    startup-script = file("./startup_script.sh")
  }
}

יצירת קבוצת MIG באמצעות סקריפט לטעינה בזמן ההפעלה

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

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

המסוף

יוצרים תבנית של הגדרות מכונה שמבוססת על סקריפט לטעינה בזמן ההפעלה שיצרתם בקטע הקודם.
1. בקטע מערכת הפעלה, בוחרים Container Optimized OS וגרסה.
2. בקטע Automation, מדביקים את סקריפט לטעינה בזמן ההפעלה שיצרתם לפריסת הקונטיינר.
יוצרים קבוצת MIG באמצעות תבנית של הגדרות מכונה שנוצרה בשלב הקודם.

gcloud

יוצרים תבנית של הגדרות מכונה באמצעות הפקודה instance-templates create.

חובה להשתמש בקובץ אימג' של מערכת הפעלה שמותאמת לקונטיינרים עבור מכונת ה-VM. אפשר לציין את הנתיב היחסי לקובץ הסקריפט לטעינה בזמן ההפעלה באמצעות הדגל --metadata-from-file.
יוצרים קבוצת MIG באמצעות תבנית של הגדרות מכונה שנוצרה בשלב הקודם.

לדוגמה:

  # Create the instance template that uses a startup script
  gcloud compute instance-templates create startup-template \
      --machine-type=e2-medium \
      --image-family=cos-stable \
      --image-project=cos-cloud \
      --metadata-from-file=startup-script=./startup_script.sh

  # Create the managed instance group
    gcloud compute instance-groups managed create startup-mig \
      --template=startup-template \
      --size=2 \
      --zone=us-central1-a

Terraform

משתמשים במשאבים google_compute_instance_template ו-google_compute_instance_group_manager כדי ליצור תבנית של הגדרות מכונה וקבוצת MIG, כמו בדוגמה הבאה:

דוגמה:

resource "google_compute_instance_template" "startup_template" {
  name_prefix = "startup-template-"
  machine_type = "e2-medium"
  disk {
    source_image = "cos-cloud/cos-stable"
    auto_delete  = true
    boot         = true
  }

  network_interface {
    network = "default"
  }
  metadata = {
    startup-script = file("./startup_script.sh")
}
}

resource "google_compute_instance_group_manager" "startup_mig" {
  name               = "startup-mig"
  base_instance_name = "startup-vm"
  zone               = "us-central1-a"
  version {
    instance_template = google_compute_instance_template.startup_template.id
  }
  target_size = 2
}

בדיקה וניקוי

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

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

פתרון בעיות בסקריפטים לטעינה בזמן ההפעלה

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

לא ניתן לשמור את הגדרת Docker

כשמריצים את הפקודה docker-credential-gcr configure-docker בסקריפט לטעינה בזמן ההפעלה, יכול להיות שתוצג הודעת השגיאה הבאה:

ERROR: Unable to save docker config: mkdir /root/.docker: read-only file system

השגיאה הזו מתרחשת כי docker-credential-gcr מנסה לכתוב פרטי כניסה לקובץ /root/.docker/config.json. מערכת הקבצים root במערכת הפעלה שמותאמת לקונטיינרים היא לקריאה בלבד, ולכן אי אפשר לכתוב בה.

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

דוגמה:

  export HOME=/home/appuser
  docker-credential-gcr configure-docker

צפייה ביומנים כדי לנפות באגים

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

כדי להציג את היומנים של הסקריפט לטעינה בזמן ההפעלה במכונת ה-VM, מריצים את הפקודה הבאה:
```
sudo journalctl | grep "startup-script"
```
כדי להציג יומנים מהקונטיינר של Docker, מריצים את הפקודה docker logs:
```
docker logs CONTAINER_NAME
```
מחליפים את CONTAINER_NAME בשם הקונטיינר.

כדי לפתור בעיות אחרות, אפשר לעיין במאמרים הבאים:

שימוש ב-`cloud-init` עם מערכת הפעלה שמותאמת לקונטיינרים

אתם יכולים להשתמש ב-cloud-init, פתרון מקובל בתחום ובפלטפורמות שונות, כדי לפרוס קונטיינרים במכונות וירטואליות שמופעלות על ידי מערכת הפעלה שמותאמת לקונטיינרים. הכלי הזה מאפשר להריץ הגדרה בהתאמה אישית במהלך יצירת מכונת ה-VM או ההפעלה שלה. מידע נוסף זמין במאמר בנושא שימוש ב-cloud-init עם פורמט ההגדרות של Cloud.

שימוש בשירותים מנוהלים לפריסת קונטיינרים

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

Cloud Run

‫Cloud Run הוא אפשרות טובה לאפליקציות בקונטיינרים ללא שמירת מצב ולמשימות קטנות עד בינוניות.

התכונות העיקריות של Cloud Run כוללות את התכונות הבאות:

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

מידע נוסף על פריסת קונטיינרים ב-Cloud Run זמין במאמר פריסת קובצי אימג' של קונטיינרים ב-Cloud Run

Batch

‫Batch הוא שירות מנוהל במלואו שמאפשר לתזמן, להוסיף לתור ולהפעיל עומסי עבודה של עיבוד באצווה במשאבי Google Cloud . הוא מיועד להרצת עומסי עבודה מקבילים בסגנון אצווה, כולל עומסי עבודה שמופיעים בחבילות בקונטיינרים.

מידע נוסף על פריסת קונטיינרים ב-Batch זמין במסמכים הבאים:

Google Kubernetes Engine

אם אתם מפעילים אפליקציות מורכבות, מיקרו-שירותים (microservice), פעולה רציפה ואתם צריכים שליטה מפורטת ומדרגיות, Google Kubernetes Engine‏ (GKE) הוא הפתרון המתאים ביותר. מידע נוסף על פריסת קונטיינרים ב-GKE זמין במאמרים הבאים:

פנייה לתמיכה

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

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

אפשרויות שהוצאו משימוש להגדרת מאגרי תגים במכונות וירטואליות

המסוף

gcloud

Terraform

זיהוי מקרים שבהם נעשה שימוש במטא-נתונים של מאגר שהוצא משימוש

השוואה בין אפשרויות הפריסה של מאגרי תגים

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

מיפוי המטא נתונים של מאגר התגים לפקודה docker run

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

דוגמה 1

דוגמה 2

אפשרויות הגדרה נוספות לפריסת מאגרי תגים

גישה לתמונות ב-Artifact Registry

הגדרת רישום ביומן

הגדרת חומת אש פנימית

צירוף אמצעי אחסון למאגר

הרכבת מערכת קבצים מסוג tmpfs

טעינת ספרייה של מארח

טעינת דיסק אחסון מתמיד (persistent disk) לקונטיינר

יצירת מכונה וירטואלית באמצעות סקריפט לטעינה בזמן ההפעלה

המסוף

gcloud

Terraform

יצירת קבוצת MIG באמצעות סקריפט לטעינה בזמן ההפעלה

המסוף

gcloud

Terraform

בדיקה וניקוי

פתרון בעיות בסקריפטים לטעינה בזמן ההפעלה

לא ניתן לשמור את הגדרת Docker

צפייה ביומנים כדי לנפות באגים

שימוש ב-cloud-init עם מערכת הפעלה שמותאמת לקונטיינרים

שימוש בשירותים מנוהלים לפריסת קונטיינרים

Cloud Run

Batch

Google Kubernetes Engine

פנייה לתמיכה

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

מיפוי המטא נתונים של מאגר התגים לפקודה `docker run`

שימוש ב-`cloud-init` עם מערכת הפעלה שמותאמת לקונטיינרים