ספינה חכמה יותר, לא קשה יותר: Kubernetes CI/CD זול עם GitHub פעולות + קסדה

קהל: פועלים חופשיים וקבוצות קטנות הדורשות משלוח אמין וזול ל-Kubernetes. תגית: DR צור תמונות של Docker ב-GitHub Actions, תווית כל תמונה עם ה-Commit SHA, הקש ל-GitHub Container Registry (GHCR) באמצעות ה-GITHUB_TOKEN המובנה, ולאחר מכן הפעל ל-Kubernetes עם Helm. סומכים על Kubernetes הפעלה עבור עדכוני גלגל, ו כבל הכנה + ניווט חיוניות כך pods לא לקבל תנועה עד שהם מוכנים (ואם להתחיל מחדש אם הם תלויים). שלוש שגיאות חוזרות אני רואה: (1) משלוח :אחרון, (2) לא מחכה להרחבה, (3) נותן CI קבוצה-מנהל. תיקונים: תגית או דיג'סט-פין תמונות, לחכות להרחבה, והגבלת גבולות הפעלה עם RBAC במרחב השמות של היעד. (Kubernetes) שולחן התוכן מדוע הסטק הזה מתאים לפרילנסרים האדריכלות בתמונה אחת התקנה חד פעמית & הקשר שתזדקקו אפליקציית דוגמה קטנה (Node.js) שאתה יכול למעשה להפעיל Dockerfile: Multi-stage build, הסבר מבנה וערכים של תרשים הקלדה: מה קורה ומדוע CI: GitHub Action Workflow to build/tag/push (עם חיבור קשיח) CD: שדרוג קסדה, תאריכים בטוחים ובדיקות הפעלה טיפים שיעזרו למנוע הפתעות מקלטים שאני רואה מדי שבוע (והאיך להימנע מהם) RBAC מינימלי עבור CI (לא יותר cluster-admin) רישומים פרטיים & imagePullSecrets (הערה של GHCR) רולבקסים, מי עושה מה, ו "האם אני בריא?" A Reusable Repo Layout & a Secrets Checklist - רשימת בדיקות אופציונלי: אותו מעגל עם Customize תוספת: שלבים נוספים CI (בדיקות, תזמון, בדיקות עשן) התייחסות 1) מדוע עגלה זו מתאימה לפרילנסרים כאשר אתה סולו או עובד עם צוות קטן, הזמן שאתה השילוב להלן שומר על רדיוס הפיצוץ קטן וחלקים זזים מובן: לא פעולות GitHub + GHCR: אתה כבר מאחסן את הקוד שלך ב- GitHub; פעולות פועלות את היצירות שלך ו- GHCR שומר על התמונות שלך באותה גבול אמון. קלם: הלקוחות מצפים לגרפים של הלם.הגרפים הם רק תבניות עם מקום ברור עבור ערכים ברירת המחדל (values.yaml), ודרך פשוטה לסדר אותם לפי סביבה. (Helm) הפעלת Kubernetes: עדכוני ריצה הם כברירת מחדל – Kubernetes מחליף בהדרגה את הפונטים הישנים עם פונטים חדשים ומכריז על הצלחה רק לאחר שהמכשיר החדש ReplicaSet מוכן. 2) האדריכלות בתמונה אחת הצעד האחרון חשוב: עד שההפצה היא למעשה בריאה (או זמנים פוסקים), כלומר צינורות ירוקות מצוידים עם אפליקציה בריאה, לא רק "מופיעים מיושמים". ( ) your pipeline blocks קובניטים 3) התקנה חד פעמית & הקשר שתצטרך השתמש בהתקנה הרשמית כך שהגרסאות תואמות את ההפרעה המומלצת של הקבוצת שלך (בדרך כלל ±1 מיעוט). (Kubernetes) Helm v3 על המרוץ. דף ההתקנה הרשמי מסמך את התסריט שאנשים רבים משתמשים ב- CI. (Helm) הוסף את התווית OCI org.opencontainers.image.source ב-Dockerfile שלך, כך שה-GHCR מקשר באופן אוטומטי את החבילה ל-repo שלך; השתמש ב-GITHUB_TOKEN עם חבילות: לכתוב בסביבות על-ידי הרשאות זרימת עבודה. (GitHub Docs) אם שלך כלומר, אם אתם מחפשים את המכשיר המושלם עבורכם, אתם תצטרכו לבחור את המכשיר המושלם עבורכם (במיוחד אם אתם מחפשים את המכשיר המושלם עבורכם). ) Why versions/skew matters: kubectl Kubernetes 4) יישום דוגמה קטן (Node.js) שאתה יכול למעשה להפעיל שני נקודות קצה המפותלות ישירות לניווט Kubernetes: // app/server.js import http from 'node:http'; const port = process.env.PORT || 3000; let ready = false; // Simulate warm-up work: DB connection, JIT, caches... setTimeout(() => (ready = true), 3000); const server = http.createServer((req, res) => { if (req.url === '/livez') return res.end('ok'); // liveness probe if (req.url === '/healthz') return res.end(ready ? 'ok' : 'starting'); // readiness probe res.writeHead(200, { 'content-type': 'text/plain' }); res.end('hello'); }); server.listen(port, () => console.log(`listening on ${port}`)); • מינימום כך תוכלו לבצע את הבדיקות במהירות: package.json { "name": "demo-app", "type": "module", "scripts": { "start": "node app/server.js", "test": "node -e \"const http=require('http');http.get('http://127.0.0.1:3000',r=>process.exit(r.statusCode===200?0:1))\"" }, "dependencies": {} } הנקודה של ו : Kubernetes treats them differently— דלתות תנועה נתחיל מחדש את המכולות המצורפות.אנו נשלח את שניהם לתוך ההפצה תוך זמן קצר. ( ) /healthz /livez readiness liveness קובניטים Dockerfile: Multi-stage build, הסבר למה מרובות שלבים? כלים בנייה (מפרקים, חבילות) אינם נחוצים בזמן ביצוע. ו דוקרים רשמיים של Docker ממליצים באופן מפורש על יצירות מרובות שלבים לייצור. ( ) build runtime Docker Documentation # Dockerfile # -------- build stage -------- FROM node:20 AS build WORKDIR /app COPY package*.json ./ RUN npm ci --omit=dev COPY . . # leave only prod deps RUN npm prune --omit=dev # -------- runtime stage -------- FROM node:20-slim WORKDIR /app COPY --from=build /app ./ EXPOSE 3000 CMD ["node","app/server.js"] # helps GHCR link this image to your repo automatically LABEL org.opencontainers.image.source="https://github.com/your-org/your-repo" אם אי פעם אתה צריך תמונות מרובות ארכיון (arm64 laptop, amd64 server), וQEMU לעשות את זה אפשרי עם זרימת עבודה אחת. ) Buildx תיעוד Docker 6) מבנה וערכים של תרשים קסדה: מה קורה ומדוע תרשימים קסדה הם תיקיות עם פריסה ספציפית; דפוסים ברירת המחדל לחיות מקדשים חיים תחת באפשרותך להוריד את הפריטים לפי סביבה עם או Inline • ( ) values.yaml templates/ --values path.yaml --set key=value קסדה chart/Chart.yaml apiVersion: v2 name: app description: Minimal demo app type: application version: 0.1.0 # chart version appVersion: "0.1.0" # your app version (for humans; not enforced) (הדפוסים שאתה תוריד ב CI) chart/values.yaml image: repository: ghcr.io/your-org/your-repo/app tag: "CHANGE_ME" # CI will set this to the commit SHA pullPolicy: IfNotPresent service: type: ClusterIP port: 80 targetPort: 3000 replicaCount: 2 resources: requests: { cpu: 100m, memory: 128Mi } limits: { cpu: 500m, memory: 256Mi } # optional if using private images # imagePullSecrets: # - name: ghcr-pull (התנסות + עדכון רולינג) chart/templates/deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: {{ include "app.fullname" . }} labels: app.kubernetes.io/name: {{ include "app.name" . }} spec: replicas: {{ .Values.replicaCount }} strategy: { type: RollingUpdate } selector: matchLabels: app.kubernetes.io/name: {{ include "app.name" . }} template: metadata: labels: app.kubernetes.io/name: {{ include "app.name" . }} spec: {{- if .Values.imagePullSecrets }} imagePullSecrets: {{- range .Values.imagePullSecrets }} - name: {{ .name }} {{- end }} {{- end }} containers: - name: app image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" imagePullPolicy: {{ .Values.image.pullPolicy }} ports: - containerPort: {{ .Values.service.targetPort }} readinessProbe: httpGet: { path: /healthz, port: {{ .Values.service.targetPort }} } initialDelaySeconds: 5 periodSeconds: 5 livenessProbe: httpGet: { path: /livez, port: {{ .Values.service.targetPort }} } initialDelaySeconds: 15 periodSeconds: 10 chart/templates/service.yaml apiVersion: v1 kind: Service metadata: name: {{ include "app.fullname" . }} spec: type: {{ .Values.service.type }} selector: app.kubernetes.io/name: {{ include "app.name" . }} ports: - port: {{ .Values.service.port }} targetPort: {{ .Values.service.targetPort }} אם אתה מעדיף גישה יבש יותר, להוסיף a to standardize names/labels. Helm’s best-practices guide covers how to structure values and helpers cleanly. ( ) _helpers.tpl Helm 7) CI: פעולות GitHub כדי לבנות, תווית, ולדחוף (עם חיבוי) נשתמש בפעולות הרשמיות של Docker: , , ו אנו מציגים את התמונה עם כל תרגיל הוא מעקב ובלתי משתנה. עבור • ( , ) setup-buildx login build-push commit SHA packages: write GITHUB_TOKEN Github GitHub מסמכים .github/workflows/ci.yml name: ci on: push: branches: [ "main" ] permissions: contents: read packages: write # allow pushing to GHCR (least privilege) jobs: build-and-push: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 # optional: speed up local tests - uses: actions/setup-node@v4 with: node-version: '20' cache: 'npm' - run: npm ci - run: npm test - name: Set up Docker Buildx uses: docker/setup-buildx-action@v3 - name: Log in to GHCR uses: docker/login-action@v3 with: registry: ghcr.io username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} - name: Build and push image uses: docker/build-push-action@v6 with: context: . push: true tags: ghcr.io/${{ github.repository }}/app:${{ github.sha }} cache-from: type=gha cache-to: type=gha,mode=max A few gotchas here: רשיונות זרימת עבודה חייבים לאפשר כתיבה של חבילות, אחרת GHCR יכחיש דחיפות. תווית תמונות עם org.opencontainers.image.source מסייעת ל-GHCR לחבר את החבילה חזרה ל-repo UI. (GitHub Docs) is the recommended way to build images in Actions, with caching and multi-arch support documented in Docker’s CI guide. ( ) Buildx Docker Documentation Kubernetes מתייחס לתמונות באופן מילולי. תגיות הופכות לקשה יותר לדעת מה פועל ויכולות לעקוף את ההגדרות המותאמות למדיניות דחייה. ( ) for perfect reproducibility—Kubernetes supports digests natively. ( ) Why SHA tags instead of :latest :latest digest image@sha256:... קובניטים 8) CD: Helm upgrade, safe timeouts, and rollout checks להפעיל מיד לאחר דחיפה מוצלחת. פועלת גם בפעם הראשונה וגם בפיתוח חוזר. (הופנה עד מועד הפתיחה) (אל תחכה לנצח) (החזרה אוטומטית על כישלון) ולאחר מכן, כמו רשת אבטחה נוספת, כדי להעביר את ההתקדמות לתוך יומן העבודה. ( , ) helm upgrade --install --wait --timeout --atomic kubectl rollout status קסדה Kubernetes deploy: needs: build-and-push runs-on: ubuntu-latest environment: production steps: - uses: actions/checkout@v4 - name: Install kubectl (official) run: | curl -LO "https://dl.k8s.io/release/$(curl -Ls https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" chmod +x kubectl && sudo mv kubectl /usr/local/bin/ - name: Install Helm run: curl -fsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash - name: Configure kubeconfig env: { KUBECONFIG_DATA: ${{ secrets.KUBECONFIG_DATA }} } run: | mkdir -p $HOME/.kube echo "$KUBECONFIG_DATA" | base64 -d > $HOME/.kube/config - name: Helm upgrade (create or update) run: | helm upgrade --install app ./chart \ --namespace prod --create-namespace \ --set image.tag=${{ github.sha }} \ --wait --timeout=10m --atomic - name: Rollout status (extra verification) run: kubectl rollout status deploy/app -n prod --timeout=180s and הלם של שחרור ברמה של הצלחה / כישלון; הדפסת התקדמות שלב אחר שלב ומספקת משוב מהיר וקריא כאשר משהו לא עובד. הופך את הכישלונות לביטול אוטומטי - שימושי כאשר אתה מעדיף להיות בטוח מאשר "חצי מעודכן". ( , ) Why both --wait kubectl rollout status --wait kubectl rollout status --atomic קסדה Kubernetes 9) סונדיות בריאות המונעות הפתעות זמן הפסקה אתה יכול לקבל עדכון ריצה מושלם ועדיין לשרת שגיאות אם האפליקציה מקבלת תנועה לפני שהיא מתחממת. prevent: they gate Service endpoints until your pod says “ready.” are your safety rope if the app wedges itself; the kubelet restarts the container after repeated failures. The official docs cover these semantics and when to use startup probes for slower apps. ( ) readiness probes Liveness probes קובניטים מדריכים מעשיים לטינינג: If your app needs 20s to warm up, set on accordingly. initialDelaySeconds readiness If your app occasionally blocks (e.g., deadlock), prefer an or liveness probe that hits a trivial endpoint or port. HTTP TCP אם האפליקציה איטית להתחיל, הוסף סנדה להתחלה כדי לדחות את החיים עד שההתחלה תסתיים. (Kubernetes) מקלטים שאני רואה מדי שבוע (והאיך להימנע מהם) 10.1 Shipping :latest The same tag points to different bits over time; pull cache and policy quirks make it unclear whether a node actually pulled the new image. What goes wrong: התיקון: תווית התמונות על-ידי commit SHA או השתמש בדיגסט (@sha256:...). Kubernetes תומך בהתייחסות דיגסט; זה תמיד יביא את התמונה המדויקת. 10.2 לא מחכים לרוולו מה לא בסדר: הצינור שלך מסתיים "ירוק", אך משתמשים רואים שגיאות במשך 30-60 שניות כי ההפצה עדיין לא התכנסה. התיקון: הוסף --Wait --timeout (ואופציונלי - אטומי) לחם, והפעיל את מצב הפעלת kubectl כך כישלונות מופיעים בבירור בלוגים. (הלם, Kubernetes) 10.3 CI יתר על המידה (cluster-admin) A leaked token equals full cluster compromise. What goes wrong: תיקון: צור ServiceAccount + Role + RoleBinding המוקף למרחב השמות של היעד, עם רק את המילים והמשאבים שאתה צריך תרשים. 11) Minimal RBAC for CI (copy/paste) # rbac/deployer.yaml apiVersion: v1 kind: ServiceAccount metadata: name: helm-deployer namespace: prod --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: helm-deployer namespace: prod rules: - apiGroups: ["apps"] resources: ["deployments","replicasets"] verbs: ["get","list","watch","create","update","patch"] - apiGroups: [""] resources: ["services","configmaps","secrets"] verbs: ["get","list","watch","create","update","patch"] - apiGroups: ["networking.k8s.io"] resources: ["ingresses"] verbs: ["get","list","watch","create","update","patch"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: helm-deployer namespace: prod subjects: - kind: ServiceAccount name: helm-deployer namespace: prod roleRef: kind: Role name: helm-deployer apiGroup: rbac.authorization.k8s.io זה עוקב אחר עיקרון: SA יכול לגעת רק בסביבת השמות וסוגי המשאבים שאתה מנהל את הגרף. RBAC הוא מודל הרשאה נתמך ב- Kubernetes. ( ) least privilege prod קובניטים 12) רישום פרטי & (למשלת GHCR) imagePullSecrets תמונה סוד חבילות GHCR ציבוריות: כל אחד יכול למשוך באופן אנונימי; אין צורך בסוד. חבילות GHCR פרטיות: יצירת סוד רישום Docker והפניה אליו ב-pod spec (או הוספת אותו לחשבון ServiceAccount שלך). Create a pull secret and use it in : prod kubectl create secret docker-registry ghcr-pull \ --docker-server=ghcr.io \ --docker-username=YOUR_GITHUB_USERNAME \ --docker-password=YOUR_GHCR_TOKEN_OR_PAT \ --docker-email=you@example.com \ -n prod לאחר מכן ב על ידי Proud: values.yaml imagePullSecrets: - name: ghcr-pull דוגמאות רשמיות מציגות את אותו זרימה עבור רישומים פרטיים; GHCR משתמש ב- Docker auth. ( ) קובניטים 13) רולבקסים, מי עושה מה, ו"אם אני בריא?" שתי תוספות יכולות לעזור לכם: היסטוריית השחרור של הלם → helm history/rollback. היסטוריית ההפצה → kubectl rollout undo/status. פקודות טיפוסיות : # See release history managed by Helm helm history app -n prod # Roll back to the previous release helm rollback app 1 -n prod # Verify the Deployment converges kubectl rollout status deploy/app -n prod --timeout=180s הלם אוטומטית חוזרת על כישלונות במהלך השדרוג. יש להקפיד על שימוש במכשירים מסחריים או במכשירים מסחריים. ( , ) --atomic kubectl rollout status קסדה קובניטים 14) A Reusable Repo Layout & a Secrets Checklist repo-root/ app/ # your code Dockerfile chart/ Chart.yaml values.yaml values-staging.yaml values-prod.yaml templates/ deployment.yaml service.yaml _helpers.tpl rbac/ deployer.yaml .github/workflows/ci.yml Secrets (GitHub → Settings → Secrets and variables → Actions): – base64 kubeconfig for the ServiceAccount. KUBECONFIG_DATA helm-deployer GITHUB_TOKEN – Auto-injected; Set workflow permissions: packages: write to push to GHCR (use repo/org defaults or YAML). 15) Optional: the same loop with Kustomize התאמה מעדיפים לבלות בלי מקדשים? הוא בנוי . Your pipeline becomes: build → push → → זה נהדר עבור שירות יחיד repos ו התאמה אישית קטנה; הלם נוטה להיות נוח יותר כאשר אתה צריך חבילות או הלקוח שלך כבר משתמש תרשימים. ( ) Kustomize kubectl kubectl apply -k overlays/prod kubectl rollout status Kubernetes Quick sketch: kustomize/ base/ deployment.yaml service.yaml kustomization.yaml overlays/ prod/ kustomization.yaml # patches image tag to $GIT_SHA 16) תוספת: שלבים נוספים CI (בדיקות, תזמון, בדיקות עשן) (למשל עבור 1 בקשה): A tiny smoke check after deploy - name: Port-forward and smoke test run: | kubectl -n prod port-forward svc/app 8080:80 & PF_PID=$! sleep 3 curl -fsS http://127.0.0.1:8080/healthz | grep -q "ok" kill $PF_PID Digest pinning (even stricter than tags): # Check the pushed image's digest docker buildx imagetools inspect ghcr.io/${OWNER}/${REPO}/app:${GITHUB_SHA} # Then set in values-prod.yaml: # image: # repository: ghcr.io/${OWNER}/${REPO}/app # tag: "" # leave empty when using a digest # digest: "sha256:..." If you want to template digest usage into Helm, adjust your image stanza and template: # values.yaml (allow either tag OR digest) image: repository: ghcr.io/your-org/your-repo/app tag: "CHANGE_ME" digest: "" # templates/deployment.yaml (image reference) image: "{{ .Values.image.repository }}{{- if .Values.image.digest -}}@{{ .Values.image.digest }}{{- else -}}:{{ .Values.image.tag }}{{- end }}" קובייקטים מבינים digests directly. It’s the most deterministic way to roll out מה שאתה בונה ( ) @sha256: בדיוק קובניטים תוספת 2 אם יש צורך ב-Docker's Docks יש להציג את שניהם. ( ) Multi-arch builds (if you need arm64): platforms: linux/amd64,linux/arm64 build-push-action תיעוד Docker 17) התייחסות Deployments (rolling update behavior & concepts). ( ) Rolling updates overview (tutorial). ( ) (command reference). ( ) Probes (liveness, readiness, startup). ( ) Images: tags, digests, and . ( ) RBAC authorization (official). ( ) Install and version skew note. ( ) Kubernetes Kubernetes Kubernetes kubectl rollout status Kubernetes Kubernetes imagePullSecrets Kubernetes Kubernetes kubectl Kubernetes שדרוג קסדה ודגלים (--install, --wait, --atomic). (Helm) Installing Helm (CI script). (Helm) תרשים מבנה וערכים הפניה ופרקטיקות הטובות ביותר. (Helm) GitHub Actions & GHCR Publishing Docker images with Actions. (GitHub Docs) Using GITHUB_TOKEN with least-privilege permissions. (GitHub Docs) Working with the Container registry (GHCR) and OCI labels. (GitHub Docs) Docker official GitHub Actions: setup-buildx, login, build-push. (GitHub) Docker's CI guide for GitHub Actions. Docker Multi-stage builds (why/how), best practices, multi-platform (Docker Documentation) מחשבות סגור This is the path I reach for when a client says: הוא מתרחב משירות יחיד לרבים, וכל חלק ממנו ניתן להסביר לאנשים שאינם פלטפורמה: אנחנו רוצים פיתוח אמין השבוע, לא בנייה מחדש של פלטפורמה". תרשים אחד, זרימת עבודה אחת, רישום אחד. תמונות בלתי משתנות (תגיות SHA או דיגסטים), סנדיות המשקפות את בריאות האפליקציה האמיתית, ופיתוחים שמחכים. הוראות הפעלת מטרה, לא Cluster-admin. להישאר מחוברים אם אהבתם את המאמר הזה ורוצים לחקור עוד על פיתוח אינטרנט, תרגישו חופשיים ליצור איתי קשר על פלטפורמות שונות: ע"י תגית: hackernoon.com hashnode.com באתר טוויטר.com אינסטגרם.com ארכיון תגיותV1 המשך ללמוד, לקוד, וליצור יישומים אינטרנט מדהימים.