עצות וטריקים של Kubernetes: על פיתוח מקומי וטלנוכחות

אנחנו נשאלים יותר ויותר לגבי פיתוח שירותי מיקרו ב-Kubernetes. מפתחים, במיוחד של שפות מתפרשות, רוצים לתקן במהירות את הקוד ב-IDE המועדף עליהם ולראות את התוצאה מבלי לחכות לבנייה/פריסה - פשוט על ידי לחיצה על F5. וכשזה הגיע לאפליקציה מונוליטית, זה היה מספיק להתקין מקומית מסד נתונים ושרת אינטרנט (ב Docker, VirtualBox...), ואז מיד ליהנות מפיתוח. עם חיתוך המונוליטים למיקרו-שירותים והגעת Kubernetes, עם הופעת תלות זה בזה, הכל זה נהיה קצת יותר קשה. ככל שיותר משירותי המיקרו האלה, כך יותר בעיות. כדי ליהנות שוב מפיתוח, צריך לגייס יותר ממיכל דוקר אחד או שניים, ולפעמים אפילו יותר מתריסר... ככלל, כל זה יכול לקחת די הרבה זמן, שכן גם זה צריך להיות מעודכן .

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

1. קביים

לרוב ה-IDEs יש את היכולת לערוך קוד ישירות בשרת באמצעות FTP/SFTP. הדרך הזו מאוד ברורה ומיד החלטנו להשתמש בה. המהות שלו מסתכמת בדברים הבאים:

1. בפוד של סביבות הפיתוח (dev/review), מושק קונטיינר נוסף עם גישת SSH והעברת מפתח ה-SSH הציבורי של המפתח שיבצע/פרוס את האפליקציה.
2. בשלב הפתיחה (בתוך המיכל prepare-app) להעביר את הקוד ל emptyDirכדי לקבל גישה לקוד ממכולות האפליקציה ומשרת ה-SSH.

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

תצורות

1.1. values.yaml

ssh_pub_key:
  vasya.pupkin: <ssh public key in base64> 

כאן vasya.pupkin הוא הערך של המשתנה ${GITLAB_USER_LOGIN}.

1.2. deployment.yaml

...
{{ if eq .Values.global.debug "yes" }}
      volumes:
      - name: ssh-pub-key
        secret:
          defaultMode: 0600
          secretName: {{ .Chart.Name }}-ssh-pub-key
      - name: app-data
        emptyDir: {}
      initContainers:
      - name: prepare-app
{{ tuple "backend" . | include "werf_container_image" | indent 8 }}
        volumeMounts:
        - name: app-data
          mountPath: /app-data
        command: ["bash", "-c", "cp -ar /app/* /app-data/" ]
{{ end }}
      containers:
{{ if eq .Values.global.debug "yes" }}
      - name: ssh
        image: corbinu/ssh-server
        volumeMounts:
        - name: ssh-pub-key
          readOnly: true
          mountPath: /root/.ssh/authorized_keys
          subPath: authorized_keys
        - name: app-data
          mountPath: /app
        ports:
        - name: ssh
          containerPort: 22
          protocol: TCP
{{ end }}
      - name: backend
        volumeMounts:
{{ if eq .Values.global.debug "yes" }}
        - name: app-data
          mountPath: /app
{{ end }}
        command: ["/usr/sbin/php-fpm7.2", "--fpm-config", "/etc/php/7.2/php-fpm.conf", "-F"]
...

1.3. secret.yaml

{{ if eq .Values.global.debug "yes" }}
apiVersion: v1
kind: Secret
metadata:
  name: {{ .Chart.Name }}-ssh-pub-key
type: Opaque
data:
  authorized_keys: "{{ first (pluck .Values.global.username .Values.ssh_pub_key) }}"
{{ end }}

המגע הסופי

אחרי זה כל מה שנשאר זה להעביר משתני gitlab-ci.yml הנדרשים:

dev:
  stage: deploy
  script:
   - type multiwerf && source <(multiwerf use 1.0 beta)
   - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
   - werf deploy
     --namespace ${CI_PROJECT_NAME}-stage
     --set "global.env=stage"
     --set "global.git_rev=${CI_COMMIT_SHA}"
     --set "global.debug=yes"
     --set "global.username=${GITLAB_USER_LOGIN}"
 tags:
   - build

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

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

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

2. נוכחות טלפונית

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

בקיצור, התברר שהכל לא כל כך מפחיד. שמנו את כל הפעולות הדורשות ביצוע מצד המפתח בקובץ טקסט של Helm chart בשם NOTES.txt. לפיכך, לאחר פריסת השירות ל-Kubernetes, המפתח רואה הוראות להפעלת סביבת הפיתוח המקומית ביומן העבודה של GitLab:

!!! Разработка сервиса локально, в составе Kubernetes !!!

* Настройка окружения
* * Должен быть доступ до кластера через VPN
* * На локальном ПК установлен kubectl ( https://kubernetes.io/docs/tasks/tools/install-kubectl/ )
* * Получить config-файл для kubectl (скопировать в ~/.kube/config)
* * На локальном ПК установлен telepresence ( https://www.telepresence.io/reference/install )
* * Должен быть установлен Docker
* * Необходим доступ уровня reporter или выше к репозиторию https://gitlab.site.com/group/app
* * Необходимо залогинится в registry с логином/паролем от GitLab (делается один раз):

#########################################################################
docker login registry.site.com
#########################################################################

* Запуск окружения

#########################################################################
telepresence --namespace {{ .Values.global.env }} --swap-deployment {{ .Chart.Name  }}:backend --mount=/tmp/app --docker-run -v `pwd`:/app -v /tmp/app/var/run/secrets:/var/run/secrets -ti registry.site.com/group/app/backend:v8
#########################################################################

לא נתעכב בפירוט על השלבים המתוארים בהוראה זו... למעט האחרון. מה קורה במהלך השקת Telepresence?

עבודה עם Telepresence

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

• מרחב השמות שבו פועל המיקרו-שירות;
• שמות הפריסה והמיכל שאנו רוצים לחדור אליהם.

שאר הטיעונים הם אופציונליים. אם השירות שלנו מקיים אינטראקציה עם ועבור ה-API של Kubernetes חשבון שירות נוצר, עלינו להעלות אישורים/אסימונים על שולחן העבודה שלנו. כדי לעשות זאת, השתמש באפשרות --mount=true (או --mount=/dst_path), שיעלה את השורש (/) ממיכל Kubernetes לשולחן העבודה שלנו. לאחר מכן, אנו יכולים (בהתאם למערכת ההפעלה ואיך האפליקציה מופעלת) להשתמש ב"מפתחות" מהאשכול.

ראשית, בואו נסתכל על האפשרות האוניברסלית ביותר להפעלת אפליקציה - בקונטיינר של Docker. לשם כך נשתמש במפתח --docker-run והעלה את הספרייה עם הקוד לתוך המיכל: -v `pwd`:/app

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

בא: -v /tmp/app/var/run/secrets:/var/run/secrets - כדי לעלות את הספרייה עם האישור/אסימון למיכל.

לאחר אפשרות זו מופיעה לבסוף התמונה שבה האפליקציה תפעל. NB: בעת בניית תמונה, עליך לציין CMD או ENTRYPOINT!

מה בדיוק יקרה אחר כך?

• ב-Kubernetes, עבור הפריסה שצוינה, מספר העתקים ישתנה ל-0. במקום זאת, תושק פריסה חדשה - עם מיכל חלופי backend.
• 2 קונטיינרים יושקו על שולחן העבודה: הראשון עם Telepresence (הוא יציג בקשות פרוקסי מ/אל Kubernetes), השני עם האפליקציה בפיתוח.
• אם נבצע ביצוע לתוך הקונטיינר עם האפליקציה, אז כל משתני ה-ENV שהועברו על ידי Helm במהלך הפריסה יהיו זמינים לנו, וכל השירותים יהיו זמינים גם כן. כל מה שנותר הוא לערוך את הקוד ב-IDE המועדף עליך וליהנות מהתוצאה.
• בסיום העבודה, רק צריך לסגור את הטרמינל בו פועל Telepresence (לסיים את הסשן עם Ctrl+C) - קונטיינרים של Docker ייעצרו על שולחן העבודה, וב-Kubernetes הכל יחזור למצבו ההתחלתי. כל מה שנותר הוא להתחייב, להנפיק את ה-MR ולהעבירו לבדיקה/מיזוג/... (בהתאם לזרימות העבודה שלכם).

אם אנחנו לא רוצים להריץ את האפליקציה בקונטיינר של Docker - למשל, אנחנו מפתחים לא ב-PHP, אלא ב-Go, ועדיין בונים אותו באופן מקומי - השקת Telepresence תהיה פשוטה אפילו יותר:

telepresence --namespace {{ .Values.global.env }} --swap-deployment {{ .Chart.Name  }}:backend --mount=true

אם האפליקציה ניגשת אל Kubernetes API, תצטרך לעלות את ספריית המפתחות (https://www.telepresence.io/howto/volumes). יש כלי עזר ללינוקס שורש:

proot -b $TELEPRESENCE_ROOT/var/run/secrets/:/var/run/secrets bash

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

NB: בעת שימוש, למשל, ב-PHP, יש לזכור להשבית את op_cache, apc ומאיצים אחרים לפיתוח - אחרת עריכת הקוד לא תוביל לתוצאה הרצויה.

תוצאות של

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

נ.ב.

אחר מסדרת הטיפים והטריקים של K8s:

• «עצות וטריקים של Kubernetes: דפי שגיאה מותאמים אישית ב-NGINX Ingress";
• «העברת משאבים הפועלים באשכול לניהול Helm 2";
• «על הקצאת צמתים ועומסים ביישום אינטרנט";
• «גישה לאתרי פיתוח";
• «זירוז אתחול עבור מסדי נתונים גדולים".

מקור: www.habr.com