Tàu thông minh hơn, không khó khăn hơn: Kubernetes CI/CD giá cả phải chăng với GitHub Actions + Helm

Khán giả: freelancers và các nhóm nhỏ cần giao hàng đáng tin cậy, rẻ tiền cho Kubernetes.Đây là một hướng dẫn dài, thực tế với rất nhiều mã có thể dán và giải thích bổ sung. Lời bài hát: Dr Xây dựng hình ảnh Docker trong GitHub Actions, đánh dấu mỗi hình ảnh với commit SHA, nhấn vào GitHub Container Registry (GHCR) bằng cách sử dụng tích hợp GITHUB_TOKEN, và triển khai vào Kubernetes với Helm. Tùy thuộc vào Kubernetes Deployments cho các bản cập nhật cuộn, và dây sẵn sàng + cuộc sống quét để pods không nhận được lưu lượng truy cập cho đến khi chúng sẵn sàng (và khởi động lại nếu chúng treo). làm cho đường ống chờ với mũ bảo hiểm - chờ đợi - nguyên tử và kubectl trạng thái triển khai để một công việc "xanh" thực sự có nghĩa là ứng dụng là khỏe mạnh. (Kubernetes, Helm) Ba lỗi lặp đi lặp lại tôi thấy: (1) shipping :latest, (2) không chờ đợi để triển khai, (3) cho CI cluster-admin. Fixes: tag hoặc digest-pin hình ảnh, chờ cho việc triển khai, và phạm vi triển khai quyền với RBAC trong không gian tên mục tiêu. (Kubernetes) Bảng nội dung Tại sao Stack này phù hợp với Freelancers Kiến trúc trong một hình ảnh Cài đặt một lần & bối cảnh bạn sẽ cần Một ứng dụng mẫu nhỏ (Node.js) bạn thực sự có thể chạy Dockerfile: xây dựng nhiều giai đoạn, giải thích Helm chart cấu trúc & giá trị: những gì đang xảy ra và tại sao CI: GitHub Actions workflow to build/tag/push (với bộ nhớ đệm) CD: nâng cấp mũ bảo hiểm, thời gian an toàn và kiểm tra triển khai Khám sức khỏe ngăn ngừa thời gian ngừng bất ngờ Những cạm bẫy tôi thấy hàng tuần (và làm thế nào để tránh chúng) RBAC tối thiểu cho CI (không còn cluster-admin) Đăng ký tư nhân & imagePullSecrets (GHCR note) Rollbacks, ai làm gì, và một "tôi có khỏe mạnh không?" A reusable repo layout & a secrets checklist (một bố trí repo tái sử dụng và danh sách kiểm tra bí mật) Tùy chọn: cùng một vòng với Customize Phụ lục: các bước CI bổ sung (thử nghiệm, đồng thời, kiểm tra khói) References 1) Tại sao stack này phù hợp với freelancers Khi bạn độc thân hoặc làm việc với một nhóm nhỏ, thời gian bạn chi tiêu công cụ dính với nhau là thời gian bạn có thể tính toán. sự kết hợp dưới đây giữ cho bán kính phát nổ nhỏ và các bộ phận chuyển động dễ hiểu: Đừng GitHub Actions + GHCR: bạn đã lưu trữ mã của bạn trong GitHub; Actions chạy các build của bạn và GHCR giữ hình ảnh của bạn trong cùng một giới hạn tin cậy. Với các quyền dòng công việc thích hợp, GITHUB_TOKEN tích hợp là đủ để đẩy hình ảnh - không có token bổ sung để xoay, không có tài khoản bổ sung để quản lý. (GitHub Docs) Helm: khách hàng mong đợi Helm biểu đồ. biểu đồ chỉ là mẫu với một nơi rõ ràng cho mặc định (values.yaml), và một cách đơn giản để xếp chúng trên mỗi môi trường. (Helm) Kubernetes Deployments: Rolling updates là mặc định – Kubernetes dần dần thay thế các pods cũ bằng những pods mới và chỉ tuyên bố thành công sau khi ReplicaSet mới đã sẵn sàng. 2) Kiến trúc trong một bức tranh Bước cuối cùng quan trọng: cho đến khi triển khai thực sự khỏe mạnh (hoặc thời gian tắt), có nghĩa là đường ống xanh phù hợp với một ứng dụng lành mạnh, không chỉ “thiết lộ được áp dụng”. ( ) your pipeline blocks Kubernets 3) Cài đặt một lần & bối cảnh bạn sẽ cần kubectl trên runner và trên máy của bạn. Sử dụng cài đặt chính thức để các phiên bản phù hợp với sự lệch hỗ trợ của cụm của bạn (thường là ±1 nhỏ). (Kubernetes) Helm v3 trên runner. trang cài đặt chính thức tài liệu kịch bản nhiều người sử dụng trong CI. (Helm) Thêm nhãn OCI org.opencontainers.image.source vào Dockerfile của bạn để GHCR tự động liên kết gói đến repo của bạn; sử dụng GITHUB_TOKEN với các gói: viết phạm vi theo quyền dòng công việc. (GitHub Docs) Nếu bạn Nếu bạn đang ở quá xa phía trước / phía sau, bạn sẽ theo đuổi những sai lầm kỳ lạ. các tài liệu chính thức kêu gọi quy tắc "trong vòng một nhỏ". ( ) Why versions/skew matters: kubectl Kubernets 4) Một ứng dụng mẫu nhỏ (Node.js) bạn thực sự có thể chạy Hai điểm cuối lập bản đồ trực tiếp đến 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}`)); Mức tối thiểu Vì vậy, bạn có thể chạy thử nghiệm nhanh chóng: 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": {} } Điểm của và Kubernetes đối xử với họ khác nhau - cổng giao thông; (Chúng tôi sẽ khởi động lại các container bị mắc kẹt.Chúng tôi sẽ dây cả hai vào triển khai trong một khoảnh khắc.) ) /healthz /livez readiness liveness Kubernets 5) Dockerfile: xây dựng nhiều giai đoạn, giải thích Tại sao nhiều giai đoạn? Các công cụ xây dựng (compilers, bundlers) không cần thiết trong thời gian chạy. và Các giai đoạn làm cho hình ảnh nhỏ hơn, nhanh hơn và an toàn hơn. tài liệu Docker chính thức khuyến nghị xây dựng nhiều giai đoạn để sản xuất. ( ) build runtime Docker tài liệu # 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" Nếu bạn cần nhiều hình ảnh lưu trữ (arm64 laptop, amd64 server), và QEMU làm cho điều đó có thể với một dòng công việc. Chúng tôi sẽ dính vào một cung duy nhất cho tốc độ. ( ) Buildx Docker tài liệu 6) Cấu trúc và giá trị biểu đồ mũ bảo hiểm: Điều gì đang xảy ra và tại sao Helm charts là các thư mục với một bố trí cụ thể; mặc định sống trong Và các đền thờ sống dưới Bạn có thể bỏ qua các mặc định theo môi trường với hoặc inline (đối với ) values.yaml templates/ --values path.yaml --set key=value Mũ bảo hiểm 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) (Defaults bạn sẽ override trong 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 (Thử nghiệm + Rolling Update) 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 }} Nếu bạn thích một cách tiếp cận DRY hơn, hãy thêm một Hướng dẫn thực hành tốt nhất của Helm bao gồm cách cấu trúc các giá trị và người giúp đỡ một cách sạch sẽ. ( ) _helpers.tpl Mũ bảo hiểm 7) CI: Hành động GitHub để xây dựng, đánh dấu và đẩy (với bộ nhớ đệm) Chúng tôi sẽ sử dụng các hành động chính thức của Docker: , và Chúng tôi đánh dấu hình ảnh với Vì vậy, mọi sự triển khai đều có thể theo dõi và không thay đổi. vì (đối với , ) setup-buildx login build-push commit SHA packages: write GITHUB_TOKEN GitHub Tài liệu 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 Một vài gothic ở đây: Quyền dòng công việc phải cho phép viết các gói, hoặc GHCR sẽ từ chối đẩy. Bạn có thể đặt mặc định trong cài đặt repo và vẫn hạn chế mỗi dòng công việc / công việc. (GitHub Docs) Nhãn hình ảnh với org.opencontainers.image.source giúp GHCR kết nối gói lại với UI repo. Buildx là cách được đề xuất để xây dựng hình ảnh trong Actions, với hỗ trợ bộ nhớ đệm và đa lưu trữ được tài liệu trong hướng dẫn CI của Docker. (Docker Documentation) Kubernetes xử lý các tham chiếu hình ảnh theo nghĩa đen. Tags làm cho nó khó khăn hơn để biết những gì đang chạy và có thể vượt qua mặc định chính sách kéo. Sử dụng một thẻ không thay đổi (SHA) hoặc thậm chí một (Những ) cho khả năng tái tạo hoàn hảo—Kubernetes hỗ trợ tiêu hóa tự nhiên. ( ) Why SHA tags instead of :latest :latest digest image@sha256:... Kubernets 8) CD: nâng cấp mũ bảo hiểm, thời gian an toàn và kiểm tra triển khai Sử dụng ngay sau khi đẩy thành công. xử lý cả lần đầu tiên và lặp lại triển khai. thêm (Block cho đến khi sẵn sàng) (Đừng chờ mãi) và (tự động quay trở lại khi thất bại).Sau đó, như một lưới an toàn bổ sung, chạy để lưu chuyển tiến độ vào nhật ký công việc. ( , ) helm upgrade --install --wait --timeout --atomic kubectl rollout status Mũ bảo hiểm Kubernets 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 và của helmet bong bóng lên một thành công / thất bại cấp độ phát hành; In tiến trình từng bước và cung cấp phản hồi nhanh chóng, dễ đọc khi một cái gì đó bị tắt. Chuyển đổi các lỗi thành tự động quay trở lại - hữu ích khi bạn muốn an toàn hơn là "nửa cập nhật". ( , ) Why both --wait kubectl rollout status --wait kubectl rollout status --atomic Mũ bảo hiểm Kubernets 9) Khám sức khỏe ngăn ngừa thời gian ngừng bất ngờ Bạn có thể có một bản cập nhật cuộn hoàn hảo và vẫn phục vụ lỗi nếu ứng dụng chấp nhận lưu lượng truy cập trước khi nó nóng lên. ngăn chặn: họ cổng điểm cuối dịch vụ cho đến khi pod của bạn nói "sẵn sàng". Các ứng dụng này có thể được sử dụng để khởi động lại ứng dụng sau khi bị lỗi lặp đi lặp lại; các tài liệu chính thức bao gồm các thuật ngữ này và khi nào nên sử dụng quét khởi động cho các ứng dụng chậm hơn. ) readiness probes Liveness probes Kubernets Hướng dẫn tuning thực tế: Nếu ứng dụng của bạn cần 20s để sưởi ấm, hãy đặt DelaySeconds ban đầu vào sẵn sàng tương ứng. Nếu ứng dụng của bạn thỉnh thoảng chặn (ví dụ, deadlock), hãy ưu tiên một HTTP hoặc TCP quét tính năng sống đạt đến một điểm cuối hoặc cổng tầm thường. Nếu ứng dụng của bạn chậm để khởi động, hãy thêm một thử nghiệm khởi động để trì hoãn sự sống động cho đến khi khởi động hoàn tất. (Kubernetes) 10) Bẫy tôi thấy hàng tuần (và làm thế nào để tránh chúng) 10.1 Vận tải :latest Điều gì sai: Cùng một thẻ chỉ ra các bit khác nhau theo thời gian; kéo bộ nhớ cache và chính sách quirks làm cho nó không rõ ràng nếu một nút thực sự kéo hình ảnh mới. Sửa chữa: Tag hình ảnh bằng cách commit SHA hoặc sử dụng digests (@sha256:...). Kubernetes hỗ trợ tham chiếu digest; nó sẽ luôn luôn thu thập hình ảnh chính xác. các tài liệu hình ảnh chính thức giải thích cách Kubernetes giải quyết tham chiếu hình ảnh, thẻ và digests. (Kubernetes) 10.2 Không chờ đợi cho rollouts Điều gì sai: Đường ống dẫn của bạn kết thúc "xanh", nhưng người dùng thấy lỗi trong 30-60 giây vì triển khai chưa hội tụ. Sửa chữa: Thêm --wait --timeout (và tùy chọn --atomic) vào Helm, và chạy trạng thái triển khai kubectl để các lỗi xuất hiện rõ ràng trong nhật ký. (Helm, Kubernetes) 10.3 CI quá đặc quyền (cluster-admin) Điều gì sai: Một token bị rò rỉ bằng thỏa hiệp cluster đầy đủ. Sửa chữa: Tạo một ServiceAccount + Role + RoleBinding phạm vi đến không gian tên mục tiêu, chỉ với các động từ và tài nguyên biểu đồ của bạn cần. các tài liệu RBAC gọi mô hình này ra rõ ràng. (Kubernetes) 11) RBAC tối thiểu cho CI (bản sao / dán) # 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 Điều này tiếp theo là Nguyên tắc: SA chỉ có thể chạm vào namespace và các loại tài nguyên mà biểu đồ của bạn quản lý.Nếu một token rò rỉ, thiệt hại được giới hạn ở những động từ / tài nguyên trong .RBAC là mô hình ủy quyền được hỗ trợ trong Kubernetes. ( ) least privilege prod Kubernets 12) Hồ sơ tư nhân & (Công ty TNHH) imagePullSecrets Hình ảnh bí mật GHCR gói công khai: bất cứ ai có thể rút tiền ẩn danh; không cần bí mật. Các gói GHCR riêng tư: tạo ra một bí mật đăng ký Docker và tham khảo nó trong chi tiết pod của bạn (hoặc đính kèm nó vào ServiceAccount của bạn). Kubernetes tài liệu cả loại bí mật và cơ chế imagePullSecrets. (Kubernetes) Tạo một bí mật kéo và sử dụng nó trong : 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 Sau đó trong Đối với Proud: values.yaml imagePullSecrets: - name: ghcr-pull Các tài liệu chính thức hiển thị cùng một luồng cho các sổ đăng ký tư nhân; GHCR sử dụng tiêu chuẩn Docker auth. ( ) Kubernets 13) Rollbacks, ai làm gì, và một “tôi có khỏe không?” Hai lớp có thể giúp bạn: Helm Release History → Helm History/Rollback. Lịch sử triển khai → kubectl rollout undo/status. Những lệnh điển hình: # 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 của helmet đã tự động cuộn trở lại những thất bại trong quá trình nâng cấp. Có thể sử dụng trong quá trình sử dụng máy tính xách tay hoặc máy tính xách tay. ( , ) --atomic kubectl rollout status Mũ bảo hiểm Kubernets 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): KUBECONFIG_DATA – base64 kubeconfig cho trình triển khai mũ bảo hiểm ServiceAccount. GITHUB_TOKEN – tự động tiêm; thiết lập quyền dòng công việc: gói: viết để đẩy đến GHCR (sử dụng repo/org mặc định hoặc YAML). (GitHub Docs) 15) Tùy chọn: cùng một vòng với tùy chỉnh tùy chỉnh Ưu tiên không dùng template? Nó được xây dựng trong Dòng đường ống của bạn trở thành: build → push → → Nó rất tuyệt vời cho các dịch vụ đơn và tùy chỉnh nhỏ; Helm có xu hướng thuận tiện hơn khi bạn cần khả năng đóng gói hoặc khách hàng của bạn đã sử dụng biểu đồ. ( ) Kustomize kubectl kubectl apply -k overlays/prod kubectl rollout status Kubernets Quick sketch: kustomize/ base/ deployment.yaml service.yaml kustomization.yaml overlays/ prod/ kustomization.yaml # patches image tag to $GIT_SHA 16) Phụ lục: các bước CI bổ sung (thử nghiệm, đồng thời, kiểm tra khói) (Đăng ký với 1 yêu cầu): 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:..." Nếu bạn muốn tạo mẫu sử dụng tiêu hóa vào Helm, hãy điều chỉnh hình ảnh của bạn và mẫu: # 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 }}" Kubernetes hiểu tiêu hóa trực tiếp. Đó là cách xác định nhất để lăn ra Những gì bạn đã xây dựng.) ) @sha256: chính xác Kubernets Thêm hai và bao gồm QEMU nếu cần thiết. tài liệu Docker hiển thị cả hai. ( ) Multi-arch builds (if you need arm64): platforms: linux/amd64,linux/arm64 build-push-action Docker tài liệu 17) Các tham chiếu Kubernetes Deployments (rolling update behavior & concepts). (Kubernetes) Rolling updates overview (tutorial). (Kubernetes) kubectl rollout status (command reference). (Kubernetes) Probes (living, readiness, startup). (Kubernetes) Hình ảnh: tags, digests, and imagePullSecrets. (Kubernetes) RBAC authorization (official). (Kubernetes) Install kubectl and version skew note. (Kubernetes) nâng cấp mũ bảo hiểm và lá cờ (--install, --wait, --atomic). (Helm) Cài đặt mũ bảo hiểm (CI script). (Helm) Chart structure & values reference and best practices. (Helm) GitHub Actions & GHCR Publishing Docker images with Actions. (GitHub Docs) Sử dụng GITHUB_TOKEN với quyền tối thiểu. (GitHub Docs) Làm việc với Registry Container (GHCR) và OCI labels. (GitHub Docs) Docker chính thức GitHub Actions: setup-buildx, login, build-push. (GitHub) Docker's CI guide for GitHub Actions. (Docker Documentation) Docker nhiều giai đoạn xây dựng (tại sao / làm thế nào), thực hành tốt nhất, đa nền tảng. (Docker Tài liệu) Khóa suy nghĩ Đây là con đường tôi đi đến khi một khách hàng nói: Nó mở rộng từ một dịch vụ duy nhất đến nhiều dịch vụ, và mỗi phần của nó có thể giải thích với những người không phải là nền tảng: “Chúng tôi muốn triển khai đáng tin cậy trong tuần này, không phải xây dựng lại nền tảng.” Một biểu đồ, một dòng công việc, một registry. Hình ảnh không thay đổi (thẻ SHA hoặc tiêu điểm), quét phản ánh sức khỏe ứng dụng thực tế, và triển khai chờ đợi. Quyền triển khai mục tiêu, không phải cluster-admin. Giữ kết nối Nếu bạn thích bài viết này và muốn khám phá thêm về phát triển web, vui lòng liên hệ với tôi trên các nền tảng khác nhau: Đã đến Trang chủ hackernoon.com Đánh giá hashnode.com trên twitter.com Trang Instagram.com Danh mục cá nhân v1 Các phản hồi và câu hỏi của bạn luôn được chào đón. Tiếp tục học, lập trình và tạo các ứng dụng web tuyệt vời.