构建基于Packer不可变镜像与Argo CD的PWA持续交付管道

DevOps

文章字数: 3.2k

阅读时长: 13 分

我们团队维护一个内部运营后台，它是一个相当复杂的PWA，状态管理采用了Redux。随着业务发展，一个棘手的问题浮出水面：环境配置管理。开发、测试、预发和生产四套环境，每套环境都有不同的API端点、功能开关（Feature Flags）和第三方服务密钥。最初，我们依赖于.env文件和CI/CD中的sed命令替换，但这套体系越来越脆弱。构建过程耦合了环境信息，配置变更需要重新触发CI，而且配置的最终状态在代码仓库中无法直观追溯，这与我们推崇的GitOps理念背道而驰。

问题的根源在于，我们将前端应用视为一堆需要“配置后才能运行”的静态文件，而不是一个独立的、不可变的发布单元。受后端不可变基础设施（Immutable Infrastructure）思想的启发，我们构思了一个新方案：将PWA及其特定环境的配置完全烘焙（Bake）到一个Docker镜像中。每个环境的每次发布，都对应一个带有唯一标签的、自包含的、立即可运行的镜像。例如，my-pwa:1.5.2-staging这个镜像，就包含了版本1.5.2在staging环境下运行所需的一切，无需任何外部配置注入。

要实现这个构想，单纯的Dockerfile显得力不从心。我们需要一个更强大的工具来编排整个镜像构建过程：拉取代码、安装依赖、注入构建时环境变量、执行PWA构建、最后将产物打包进一个干净的Nginx镜像。这个过程涉及多个阶段和复杂的逻辑，这正是Packer的用武之地。Packer以其声明式的JSON/HCL配置，能够精确定义镜像构建的每一个步骤，并能与现有的CI系统无缝集成。

而部署环节，Argo CD是自然的选择。它通过监控一个专门的Git仓库（我们称之为GitOps仓库）来同步集群状态。我们的任务就是让CI在构建完不可变镜像后，自动更新GitOps仓库中对应环境的Kubernetes清单，将其中的镜像标签指向新构建的镜像。Argo CD会立即捕捉到这个变化，并执行滚动更新。

奠定基石：Packer的镜像构建范式

我们的核心是packer.pkr.hcl文件，它定义了如何为PWA构建一个包含所有环境配置的Docker镜像。这个文件不是一个简单的脚本，而是我们前端应用“生产规格”的蓝图。

// infra/packer/pwa.pkr.hcl

packer {
  required_plugins {
    docker = {
      version = ">= 1.0.8"
      source  = "github.com/hashicorp/docker"
    }
  }
}

// 定义构建变量，这些变量将由CI系统在运行时传入
variable "app_version" {
  type    = string
  default = "0.0.1-local"
}

variable "build_env" {
  type    = string
  default = "development"
}

// 根据不同环境定义配置，这是将环境配置“烘焙”进镜像的关键
locals {
  env_configs = {
    development = {
      api_url     = "https://api.dev.example.com"
      feature_a   = "true"
      sentry_dsn  = "sentry-dsn-for-dev"
    }
    staging = {
      api_url     = "https://api.staging.example.com"
      feature_a   = "true"
      sentry_dsn  = "sentry-dsn-for-staging"
    }
    production = {
      api_url     = "https://api.prod.example.com"
      feature_a   = "false"
      sentry_dsn  = "sentry-dsn-for-production"
    }
  }
  // 获取当前构建环境的配置
  current_config = local.env_configs[var.build_env]
}

source "docker" "pwa-app" {
  image  = "node:18.18-alpine" // 使用一个包含Node.js的镜像作为构建器
  commit = true               // 在构建结束后提交镜像，而不是保留一个运行的容器
  changes = [
    "WORKDIR /app/build",
    "EXPOSE 80",
    "ENTRYPOINT [\"nginx\", \"-g\", \"daemon off;\"]"
  ]
}

build {
  name = "build-pwa-image"
  sources = ["source.docker.pwa-app"]

  // Provisioner是Packer的核心，它定义了在构建环境中执行的一系列操作
  provisioner "shell" {
    // 注入环境变量，这些变量将在下一步的构建脚本中使用
    environment_vars = [
      "REACT_APP_API_URL=${local.current_config.api_url}",
      "REACT_APP_FEATURE_A_ENABLED=${local.current_config.feature_a}",
      "REACT_APP_SENTRY_DSN=${local.current_config.sentry_dsn}"
    ]
    // 执行一系列命令来构建PWA
    inline = [
      "apk add --no-cache git",
      "git clone --depth 1 --branch main https://github.com/my-org/my-pwa.git /app",
      "cd /app",
      "npm install --legacy-peer-deps", // 使用ci在真实项目中更稳定
      "npm run build",
      // 清理构建环境，安装Nginx
      "apk add --no-cache nginx",
      "mv /app/build /usr/share/nginx/html",
      // 这里的nginx.conf是项目中的一个预置文件，用于处理PWA的路由
      "cp /app/infra/nginx/nginx.conf /etc/nginx/nginx.conf",
      // 清理不必要的文件，减小镜像体积
      "rm -rf /app" 
    ]
  }

  // Post-processor在构建完成后执行，用于标记和推送镜像
  post-processor "docker-tag" {
    repository = "my-registry/pwa"
    tags       = ["${var.app_version}-${var.build_env}", "latest-${var.build_env}"]
  }

  post-processor "docker-push" {
    login          = true
    login_user     = "robot"
    login_password = "${env("REGISTRY_PASSWORD")}"
    login_server   = "my-registry"
  }
}

这段HCL配置做了几件关键的事情：

参数化构建: 通过variable定义了应用版本和构建环境，使得CI可以动态调用。
集中化环境配置: locals块像一个配置中心，清晰地定义了每个环境的差异。在真实项目中，这里可能会通过file()函数读取外部的tfvars或json文件。
声明式构建过程: provisioner "shell"精确地描述了从拉代码到最终清理的每一步。这里的关键在于environment_vars，它将locals中的配置作为环境变量注入到构建环境中，React的构建脚本（如Create React App）会自动读取REACT_APP_前缀的变量并将其打包到最终的静态文件中。
原子化发布单元: post-processor确保构建成功后，会立刻生成一个带有版本和环境双重标识的镜像（如my-registry/pwa:1.5.2-staging）并推送到镜像仓库。这个镜像就是我们的原子发布单元。

应用层适配：Redux与构建时配置

在PWA应用内部，我们需要一种机制来消费这些在构建时注入的配置。对于Redux应用，一个常见的实践是在创建Store时，将这些配置作为初始状态（initial state）的一部分注入，或者用于配置与API通信的客户端实例。

// src/store/index.js
import { createStore, applyMiddleware } from 'redux';
import thunk from 'redux-thunk';
import rootReducer from './reducers';
import createApiClient from '../services/api';

// 从环境变量中读取配置，这些值由Packer在构建时注入
const config = {
  apiUrl: process.env.REACT_APP_API_URL,
  featureAEnabled: process.env.REACT_APP_FEATURE_A_ENABLED === 'true',
  sentryDsn: process.env.REACT_APP_SENTRY_DSN,
};

// 我们可以基于配置创建一个API客户端实例
// 这样整个应用中的API请求就自然地指向了正确的环境
const apiClient = createApiClient(config.apiUrl);

// 也可以将一些配置作为Redux的初始状态
const initialState = {
  // ... 其他模块的初始状态
  config: {
    features: {
      featureA: config.featureAEnabled,
    },
  },
};

// 在创建store时，将API客户端作为thunk的额外参数传入
// 这样在action creator中就可以直接调用，无需关心其具体配置
const store = createStore(
  rootReducer,
  initialState,
  applyMiddleware(thunk.withExtraArgument({ apiClient }))
);

// 初始化Sentry等第三方服务
if (config.sentryDsn) {
  // Sentry.init({ dsn: config.sentryDsn });
  console.log(`Sentry initialized for environment with DSN: ${config.sentryDsn}`);
}

export default store;

这种模式的优势在于，应用代码本身与环境无关。它只关心process.env中的变量，而这些变量的来源和正确性由构建管道保证。开发者在本地开发时，可以通过.env.development文件来模拟这些变量，体验与生产一致的配置注入机制。

容器运行时：一个精简且健壮的Nginx环境

Packer构建出的镜像，其最终运行环境是一个精简的Nginx服务器。Dockerfile被隐式地定义在Packer的source和provisioner中，但其核心是服务于PWA的Nginx配置。

# infra/nginx/nginx.conf

worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;

events {
  worker_connections  1024;
}

http {
  include       /etc/nginx/mime.types;
  default_type  application/octet-stream;

  log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';

  access_log  /var/log/nginx/access.log  main;

  sendfile        on;
  keepalive_timeout  65;

  gzip on;
  gzip_vary on;
  gzip_proxied any;
  gzip_comp_level 6;
  gzip_types text/plain text/css text/xml application/json application/javascript application/xml+rss application/atom+xml image/svg+xml;

  server {
    listen 80;
    server_name  localhost;
    root   /usr/share/nginx/html;
    index  index.html;

    # 对所有静态资源设置积极的缓存策略
    location ~* \.(?:css|js|jpg|jpeg|gif|png|ico|cur|gz|svg|svgz|mp4|ogg|ogv|webm|htc)$ {
      expires 1y;
      add_header Cache-Control "public";
      access_log off;
    }

    # 这是PWA路由的关键配置
    # 任何不存在的文件请求（通常是前端路由）都回退到index.html
    location / {
      try_files $uri $uri/ /index.html;
    }

    # Service Worker文件不应该被缓存
    location = /service-worker.js {
      expires off;
      add_header Cache-Control "no-cache";
      access_log off;
    }
  }
}

这个Nginx配置是生产级的。它不仅配置了Gzip压缩和静态资源缓存，更重要的是通过try_files指令正确处理了HTML5 History API路由，这是单页应用（包括PWA）部署时最常见的坑。

GitOps闭环：Argo CD与Kustomize

现在我们有了生成不可变镜像的能力，接下来是如何以GitOps的方式部署它们。我们使用Kustomize来管理不同环境的Kubernetes清单差异，Argo CD则负责监控并应用这些清单。

我们的GitOps仓库结构如下：

gitops-repo/
└── apps/
    └── my-pwa/
        ├── base/
        │   ├── kustomization.yaml
        │   ├── deployment.yaml
        │   └── service.yaml
        └── overlays/
            ├── staging/
            │   ├── kustomization.yaml
            │   └── deployment-patch.yaml
            └── production/
                ├── kustomization.yaml
                └── replicas-patch.yaml

Base清单 (base/deployment.yaml)

# gitops-repo/apps/my-pwa/base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pwa-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: pwa
  template:
    metadata:
      labels:
        app: pwa
    spec:
      containers:
      - name: pwa-container
        # 这里的镜像标签是一个占位符，它将被overlay覆盖
        image: my-registry/pwa:placeholder 
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: "50m"
            memory: "64Mi"
          limits:
            cpu: "100m"
            memory: "128Mi"

Staging的Overlay (overlays/staging/kustomization.yaml)

这个文件定义了staging环境的特定配置。

# gitops-repo/apps/my-pwa/overlays/staging/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: staging
resources:
- ../../base

# 这是关键：使用patches来修改base中的镜像标签
images:
- name: my-registry/pwa
  newName: my-registry/pwa
  newTag: 1.5.2-staging # 这个标签由CI/CD管道在构建后自动更新

patches:
- path: deployment-patch.yaml
  target:
    kind: Deployment
    name: pwa-deployment

deployment-patch.yaml可以包含其他针对性的修改，比如副本数。

# gitops-repo/apps/my-pwa/overlays/staging/deployment-patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pwa-deployment
spec:
  replicas: 2 # Staging环境需要2个副本

Argo CD的应用定义

最后，我们定义一个Argo CD Application来监控staging环境的路径。

# argocd/application-staging.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: pwa-staging
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'https://github.com/my-org/gitops-repo.git'
    path: apps/my-pwa/overlays/staging
    targetRevision: HEAD
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: staging
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

完整工作流的可视化

整个流程形成了一个从代码提交到服务上线的自动化闭环。

graph TD
    A[开发人员推送代码到main分支] --> B{触发CI Pipeline};
    B --> C[运行单元测试和Lint];
    C --> D{Packer构建};
    D -- 注入staging配置 --> E[构建 my-registry/pwa:1.5.2-staging];
    D -- 注入production配置 --> F[构建 my-registry/pwa:1.5.2-production];
    E --> G{自动更新GitOps仓库};
    F --> G;
    G --> H[修改 staging overlay 的 kustomization.yaml, 将镜像tag更新为1.5.2-staging];
    H --> I[Argo CD检测到GitOps仓库变更];
    I --> J[Argo CD执行kubectl apply -k];
    J --> K[Kubernetes拉取新镜像并执行滚动更新];
    K --> L[Staging环境部署完成];

这个流程的真正价值在于它的可审计性和可靠性。任何环境的任何部署，其状态都唯一地由GitOps仓库中的一个commit定义。回滚操作不再是执行复杂的CI回滚命令，而是一个简单的git revert，Argo CD会自动将集群状态同步回上一个版本。

当前方案的局限性与未来展望

尽管这套体系解决了我们最初的配置管理痛点，但它并非银弹。首先，镜像构建时间相对较长。每次代码变更都需要完整的npm install和npm run build，虽然可以通过优化Packer的缓存或多阶段构建来缓解，但依然比简单的文件上传要慢。

其次，镜像膨胀问题。每个版本、每个环境都会产生一个新镜像，这要求我们有严格的镜像仓库清理策略，否则存储成本会迅速增加。

再者，对于需要频繁变更的配置，例如A/B测试的流量分配比例，将其烘焙进镜像并不合适。这种高度动态的配置更适合通过外部配置中心（如LaunchDarkly、Consul）在应用运行时获取。我们的方案解决了“构建时”配置的问题，但“运行时”配置是另一个需要独立解决的课题。未来的迭代方向可能是混合模式：将稳定的基础配置烘焙进镜像，同时PWA在启动时从配置中心拉取动态配置，并更新到Redux store中。这种方式兼顾了部署的稳定性和运营的灵活性。

PWA 容器化 Argo CD Redux Packer

基于Tornado与ScyllaDB构建支持动态请求批处理的机器学习推理网关

2023-10-27 后端架构

Scikit-learn ScyllaDB Tornado API Gateway

构建与压测一套面向iOS应用、运行于GKE之上的高基数Prometheus指标管道

2023-10-27 可观测性

Prometheus TSDB GCP GKE iOS 开发测试