docker_practice/21_case_devops/21.1_devops_workflow.md at 7d9ed83d45ad9dce95eb0fdf9da07f0f03682fc5

mirror of https://github.com/yeasy/docker_practice.git synced 2026-10-19 17:46:09 +00:00

Files

T

yeasy ef2625531d style: 含中文的括号统一为全角（336 处 / 110 文件）

全书此前是真·五五开：含中文的括号 336 处半角 : 336 处全角，而且**在同一文件
内混用**——`18_security/18.1_kernel_ns.md` 第 11/17/20 行写 `（如 runC）`，
第 31 行写 `(用户命名空间映射)`。这不是体例问题，是它自己跟自己不一致。

集群里其余 13 本都一边倒（llm_internals 5 : 1049、oc_guide 2 : 713、
forward_deployed_engineering_guide 0 : 108），blockchain_guide 已在 2026-08-05
按同一方向统一过 97 处，故取全角，而非另立新规。全角括号前后不留空格，
原先 `概念 (镜像、容器、仓库) 和` 两侧的空格一并收掉。

**纯拉丁内容的半角括号一个没动**——`新建一个层 (Layer)`、`项目 (project)`
保持原样：改动前后「半角且内容纯拉丁」的数量都是 **1163**，而「半角且含中文」
从 **336 变成 0**。

其余验证：改动前后各自抹掉全部空白与圆括号后**逐字节相同**（两侧均 19559 字符）；
左右括号总数改动前后都是 399 : 399，证明没有吞括号也没有配错对。
`check_project_rules` 202/202、`check_emphasis` 202/202、37 tests OK、
根 `format_checker` 与 `validate_codeblocks` 干净、`git diff --check` 干净。

2026-08-24 13:13:23 -07:00

2.9 KiB

Raw Blame History

21.1 DevOps 完整工作流

本章将演示一个基于 Docker、Kubernetes 和 Jenkins/GitLab CI 的完整 DevOps 工作流。

21.1.1 工作流概览

Code：开发人员提交代码到 GitLab。
Build：GitLab CI 触发构建任务。
Test：运行单元测试和集成测试。
Package：构建 Docker 镜像并推送到 Harbor/Registry。
Deploy (Staging)：自动部署到测试环境 Kubernetes 集群。
Verify：人工或自动化验证。
Release (Production)：审批后自动部署到生产环境。

21.1.2 关键配置示例

本节通过一组最小可用的片段，展示典型 DevOps 流程中与 Docker 相关的关键配置。

1. Dockerfile 多阶段构建

使用 Docker 多阶段构建可以有效减小镜像体积。

## Build stage

FROM golang:1.26 AS builder
WORKDIR /app
COPY . .
RUN go build -o main .

## Final stage

FROM alpine:3.21
WORKDIR /app
COPY --from=builder /app/main .
CMD ["./main"]

2. GitLab CI 配置

GitLab CI（.gitlab-ci.yml）配置如下：

stages:
  - test
  - build
  - deploy

unit_test:
  stage: test
  image: golang:1.26
  script:
    - go test ./...

build_image:
  stage: build
  image: docker:29
  services:
    - docker:29-dind
  script:
    - echo "$CI_REGISTRY_PASSWORD" | docker login -u "$CI_REGISTRY_USER" --password-stdin $CI_REGISTRY
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

deploy_staging:
  stage: deploy
  image: dtzar/helm-kubectl
  script:
    - printf '%s' "$KUBE_CA_PEM" > kube-ca.crt
    - kubectl config set-cluster k8s --server=$KUBE_URL --certificate-authority=kube-ca.crt --embed-certs=true
    - kubectl config set-credentials admin --token=$KUBE_TOKEN
    - kubectl config set-context default --cluster=k8s --user=admin
    - kubectl config use-context default
    - kubectl set image deployment/myapp myapp=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
      -n staging
  only:
    - develop

21.1.3 最佳实践

不可变基础设施：一旦镜像构建完成，在各个环境（Dev、Staging、Prod）中都应该使用同一个镜像 tag（通常是 commit hash），而不是重新构建。
配置分离：使用 ConfigMap 和 Secret 管理环境特定的配置，不要打包进镜像。
应对 Docker Hub 限额 (Rate Limits)：
- Docker Hub 对匿名拉取实施了严格的限制（6 小时内约 100 次）。若在 CI/CD 中频繁构建，极易触发 toomanyrequests 错误。
- 最佳策略：
  - 在流水线开头始终执行安全的身份认证（使用 PAT，而非密码）。
  - 将常用的基础镜像缓存到自建的 Harbor/Nexus，使用 Pull-Through Cache。
  - 开启 Docker 构建引擎 (BuildKit) 的 inline 或 registry 缓存功能，以降低全量拉取频率。
GitOps：考虑引入 ArgoCD，将部署配置也作为代码存储在 Git 中，实现 Git 驱动的部署同步。

2.9 KiB Raw Blame History Unescape Escape