מידע על קונטיינרים של מערכת Linux

בעזרת כלי ה-CLI של Migrate to Containers אפשר להעביר אפליקציות מבוססות Linux לסביבות בקונטיינרים. הוא משתמש בקונטיינר מערכת Linux מוכן מראש שפועל כתוכנת אתחול לשירותים שנדרשים לאפליקציה המודרנית. באמצעות Migrate to Containers לאפליקציות Linux, אתם יכולים לבצע מודרניזציה למגוון רחב של אפליקציות חסרות מצב (stateless) כדי להפעיל אותן ב-Google Kubernetes Engine‏ (GKE), ב-Cloud Run ובאשכולות GKE.

מידע נוסף זמין במאמר ארכיטקטורת Migrate to Containers CLI.

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

העברה באמצעות קונטיינר של מערכת Linux

הכלי Migrate to Containers מגלה את הקבצים והתהליכים של אפליקציית המקור. לאחר מכן, הוא יוצר פריטי מידע שנוצרו בתהליך פיתוח (Artifact), כולל קובץ Dockerfile, מניפסט Kubernetes ותצורת Skaffold.

הפונקציה העיקרית של קונטיינר במערכת Linux היא להפעיל את השירותים שהופעלו במקור במכונה הווירטואלית (VM) של המקור, כולל שירותים רלוונטיים של מערכת ההפעלה והאפליקציה.

קובץ ה-Dockerfile משמש ליצירת האימג' של המכונה הווירטואלית שהועברה. קובץ Dockerfile של קונטיינר במערכת Linux בדרך כלל נראה כך:

# Please refer to the documentation:
# https://cloud.google.com/migrate/anthos/docs/dockerfile-reference

FROM us-docker.pkg.dev/migrate-modernize-public/modernize-plugins-prod/service-manager-runtime:1.0.0 as service-manager-runtime

FROM scratch

# Tar containing data captured from the source VM
ADD vmFiles.tar.gz /

COPY --from=service-manager-runtime / /

ADD blocklist.yaml /.m4a/blocklist.yaml

ADD logs.yaml /code/config/logs/logsArtifact.yaml

ADD services-config.yaml /.m4a/

ADD tempfiles.yaml  /.m4a/

# If you want to update parts of the image, add your commands here.
# For example:
# RUN apt-get update
# RUN apt-get install -y \
#       package1=version \
#       package2=version \
#       package3=version
# RUN yum update
# RUN wget http://github.com

ENTRYPOINT ["/ko-app/service-manager-runtime", "start", "-c", "/.m4a/"]

כשמבצעים העברה, ההצהרות הבאות ב-קובץ Docker מעתיקות או מוסיפות את נתוני ה-VM ממקור הנתונים המקורי ל-קובץ אימג' של Docker:

ההצהרה הבאה מוסיפה את קובץ ה-tar שמכיל את הנתונים שנאספו ממכונת ה-VM של המקור לקובץ אימג' של Docker:
```
ADD vmFiles.tar.gz /
```
קובץ ה-tar הזה נוצר על ידי Migrate to Containers. הוא מכיל את מערכת קבצי הבסיס של מכונת ה-VM של המקור, עם כל מה שמופיע במסננים בתוכנית ההעברה, וכל תיקייה שמופיעה בתוכנית העברת הנתונים מסוננת.
ההצהרה הבאה מייבאת את זמן הריצה של Migrate to Containers ממאגר Docker אל קובץ אימג' של Docker:
```
FROM us-docker.pkg.dev/migrate-modernize-public/modernize-plugins-prod/service-manager-runtime:1.0.0 as service-manager-runtime
```
ההצהרה הבאה מעתיקה את זמן הריצה של Migrate to Containers לתוך קובץ אימג' של Docker:
```
COPY --from=service-manager-runtime / /
```

לחיצה להצגת פרטים על קובץ זמן הריצה של Migrate to Containers

‫/ko-app/service-manager-runtime הוא קובץ זמן הריצה הראשי של Migrate to Containers. זו מערכת הפעלה שנוצרה עבור קונטיינרים. היא מבצעת את הפעולות הבאות:

קורא את הקובץ /.m4a/services-config.yaml ומריץ את הקבצים הבינאריים שצוינו לפי הסדר בהתאם לשיטת ההרצה שצוינה, כמו daemonize, ‏ not daemonize, ‏ wait for finish.
הכלי אוסף את היומנים שצוינו בקובץ /code/config/logs/logsArtifact.yaml ומדפיס אותם ב-stdout של מאגר התגים. בנוסף, ב-GKE ובאשכולות GKE, הפרמטר הזה מוודא שהיומנים נשלחים אל Cloud Logging.

תחזוקה של עומסי עבודה שהועברו

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

בתרשים הבא מוצגת דוגמה לצינור עיבוד נתונים באמצעות Migrate to Containers:

תהליך אוטומטי של CI/CD להעברת פלטפורמה של אפליקציה באמצעות Migrate to Containers

בתרשים הזה מוצג תהליך השינוי של אפליקציה קיימת.

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

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