קבצים מקומיים בעת העברת אפליקציה ל-Kubernetes

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

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

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

אחסון סטטי

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

• webroot/assets/2072c2df/css/…
• webroot/assets/2072c2df/images/…
• webroot/assets/2072c2df/js/…

מה זה אומר במונחים של אשכול?

הדוגמה הפשוטה ביותר

ניקח מקרה נפוץ למדי, כאשר לפני PHP קודמת nginx כדי להפיץ נתונים סטטיים ולעבד בקשות פשוטות. הדרך הקלה ביותר - פְּרִיסָה עם שני מיכלים:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: site
spec:
  selector:
    matchLabels:
      component: backend
  template:
    metadata:
      labels:
        component: backend
    spec:
      volumes:
        - name: nginx-config
          configMap:
            name: nginx-configmap
      containers:
      - name: php
        image: own-image-with-php-backend:v1.0
        command: ["/usr/local/sbin/php-fpm","-F"]
        workingDir: /var/www
      - name: nginx
        image: nginx:1.16.0
        command: ["/usr/sbin/nginx", "-g", "daemon off;"]
        volumeMounts:
        - name: nginx-config
          mountPath: /etc/nginx/conf.d/default.conf
          subPath: nginx.conf

בצורה פשוטה, התצורה של nginx מסתכמת לדברים הבאים:

apiVersion: v1
kind: ConfigMap
metadata:
  name: "nginx-configmap"
data:
  nginx.conf: |
    server {
        listen 80;
        server_name _;
        charset utf-8;
        root  /var/www;

        access_log /dev/stdout;
        error_log /dev/stderr;

        location / {
            index index.php;
            try_files $uri $uri/ /index.php?$args;
        }

        location ~ .php$ {
            fastcgi_pass 127.0.0.1:9000;
            fastcgi_index index.php;
            include fastcgi_params;
        }
    }

כאשר אתה ניגש לראשונה לאתר, נכסים מופיעים במיכל ה-PHP. אבל במקרה של שני קונטיינרים בתוך פוד אחד, nginx לא יודע דבר על הקבצים הסטטיים האלה, שאותם (לפי התצורה) צריך לתת להם. כתוצאה מכך, הלקוח יראה שגיאה 404 עבור כל הבקשות לקבצי CSS ו-JS. הפתרון הפשוט ביותר כאן יהיה לארגן ספרייה משותפת לקונטיינרים. אפשרות פרימיטיבית - כללית emptyDir:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: site
spec:
  selector:
    matchLabels:
      component: backend
  template:
    metadata:
      labels:
        component: backend
    spec:
      volumes:
        - name: assets
          emptyDir: {}
        - name: nginx-config
          configMap:
            name: nginx-configmap
      containers:
      - name: php
        image: own-image-with-php-backend:v1.0
        command: ["/usr/local/sbin/php-fpm","-F"]
        workingDir: /var/www
        volumeMounts:
        - name: assets
          mountPath: /var/www/assets
      - name: nginx
        image: nginx:1.16.0
        command: ["/usr/sbin/nginx", "-g", "daemon off;"]
        volumeMounts:
        - name: assets
          mountPath: /var/www/assets
        - name: nginx-config
          mountPath: /etc/nginx/conf.d/default.conf
          subPath: nginx.conf

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

אחסון מתקדם יותר

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

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

• בואו נרחיב את זה פְּרִיסָה עד שני העתקים.
• כאשר הגישה לאתר הייתה לראשונה, נוצרו נכסים בהעתק אחד.
• בשלב מסוים, Ingress החליטה (למטרות איזון עומסים) לשלוח בקשה לעותק השני, והנכסים הללו עדיין לא היו שם. או אולי הם כבר לא שם כי אנחנו משתמשים RollingUpdate וכרגע אנחנו מבצעים פריסה.

באופן כללי, התוצאה היא שוב טעויות.

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

מהם הפתרונות?

1. אם החומרה והמשאבים מאפשרים, אתה יכול להשתמש cephfs לארגן ספרייה נגישה באותה מידה לצרכים סטטיים. תיעוד רשמי ממליץ על כונני SSD, שכפול לפחות פי שלושה וחיבור "עבה" יציב בין צמתי אשכול.
2. אפשרות פחות תובענית תהיה לארגן שרת NFS. עם זאת, אז אתה צריך לקחת בחשבון את העלייה האפשרית בזמן התגובה עבור עיבוד בקשות על ידי שרת האינטרנט, וסובלנות תקלות תשאיר הרבה לרצוי. ההשלכות של הכישלון הן קטסטרופליות: אובדן ההר גוזר למוות את המקבץ בלחץ העומס של לוס אנג'לס שממהר לשמיים.

בין היתר, כל האפשרויות ליצירת אחסון מתמשך ידרשו ניקוי רקע סטים מיושנים של קבצים שהצטברו במשך פרק זמן מסוים. מול קונטיינרים עם PHP אתה יכול לשים DaemonSet מהמטמון nginx, אשר יאחסן עותקים של נכסים לזמן מוגבל. התנהגות זו ניתנת להגדרה בקלות באמצעות proxy_cache עם עומק אחסון בימים או ג'יגה-בייט של שטח דיסק.

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

המלצה

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

אם נחזור לדוגמא הספציפית עם מסגרת Yii ולא נעמיק במבנה שלה (וזה לא מטרת המאמר), די להצביע על שתי גישות פופולריות:

1. שנה את תהליך בניית התמונה כדי למקם נכסים במיקום צפוי. זה מוצע/מיושם בהרחבות כמו yii2-static-assets.
2. הגדר גיבוב ספציפי עבור ספריות נכסים, כפי שנדון למשל. המצגת הזו (החל משקופית מס' 35). אגב, כותב הדו"ח בסופו של דבר (ולא בלי סיבה!) מייעץ שאחרי הרכבת נכסים על שרת ה-build, העלה אותם לאחסון מרכזי (כמו S3), מולו תציב CDN.

הורדות

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

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

המלצה

פתרון אחד הוא באמצעות אחסון תואם S3 (גם אם זו איזושהי קטגוריה באירוח עצמי כמו מיניו). המעבר ל-S3 ידרוש שינויים ברמת הקוד, וכיצד התוכן יועבר בחזית הקצה, כבר הבנו писали.

הפעלות משתמש

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

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

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: nginx-test
  annotations:
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/session-cookie-name: "route"
    nginx.ingress.kubernetes.io/session-cookie-expires: "172800"
    nginx.ingress.kubernetes.io/session-cookie-max-age: "172800"

spec:
  rules:
  - host: stickyingress.example.com
    http:
      paths:
      - backend:
          serviceName: http-svc
          servicePort: 80
        path: /

אבל זה לא יבטל בעיות עם פריסות חוזרות ונשנות.

המלצה

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

מסקנה

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

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

נ.ב.

קרא גם בבלוג שלנו:

• «העברת קבצים מ-AWS S3 באמצעות nginx";
• «7 שיטות עבודה מומלצות לשימוש בקונטיינרים לפי גוגל";
• «7 עקרונות לעיצוב יישומים מבוססי מיכל» (מתוך Red Hat);
• «7 גורמים חסרים באפליקציית 12 הגורמים".

מקור: www.habr.com