IBM Cloud Docs
使用 Kustomize 打包应用程序以在多个环境中复用

使用 Kustomize 打包应用程序以在多个环境中复用

作为 十二要素云原生应用程序的一部分，您希望通过建立使用通用版本控制代码库源的持续开发和交付管道来保持 dev-to-prod 的均等性。 在代码库中，您通常以YAML格式存储 Kubernetes 资源配置清单文件。 您可以使用 Kubernetes 项目 Kustomize 在多个环境中标准化和定制您的部署。

例如，您可以创建一个基础 kustomization YAML文件来声明 Kubernetes 对象，例如部署和PVC，这些对象在开发、测试和生产环境中共享。 接下来，您可以为每个环境分别设置 kustomization YAML文件，其中包含自定义配置，例如在生产环境中创建比测试环境中更多的副本。 这些自定义的YAML文件可以覆盖或构建在共享的YAML文件基础上，以便您可以管理除少数覆盖配置差异外基本相同的多个环境，这些差异由您进行源代码管理。 如需了解有关 Kustomize 的更多信息，如术语表和常见问题解答，请查看 Kustomize 文档。

开始之前: 访问 Red Hat OpenShift 集群。

要使用 Kustomize 设置配置文件，请执行以下操作：

  1. 安装 kustomize 工具。

    • 对于 macOS，可以使用 brew 软件包管理器。
      brew install kustomize
    • 对于 Windows，可以使用 chocolatey 软件包管理器。
      choco install kustomize

  2. 在版本控制系统中为应用程序创建目录，例如 Git。

    git init ~/<my_app>

  3. 为您的 kustomize base目录、overlay目录以及环境目录（如暂存和生产环境）创建您的存储库结构。 在后续步骤中，设置这些存储库以用于 kustomize。

    mkdir -p ~/<my_app>/base &&
mkdir -p ~/<my_app>/overlay &&
mkdir -p ~/<my_app>/overlay/staging &&
mkdir -p ~/<my_app>/overlay/prod

    示例存储库结构

    .
├── base
└── overlay
    ├── prod
    └── staging

  4. 设置 base 存储库。

    1. 导航至 base 存储库。

      cd ~/<my_app>/base

    2. 为应用程序部署创建一组初始的 Kubernetes 配置 YAML 文件。 您可以使用 wasliberty YAML 示例来创建部署、服务、配置映射和持久卷声明。

    3. 创建 一个 kustomization 文件，指定要在各种环境中应用的基本配置。 kustomization 文件必须包含存储在同一 base 存储库中的 Kubernetes 资源配置 YAML 的列表。 在 kustomization 文件中，还可以添加应用于 base 存储库中所有资源 YAML 的配置，例如附加到所有资源名称的前缀或后缀，以及标签、私钥、配置映射、在其中创建所有资源的现有名称空间等。

      apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: wasliberty
namePrefix: kustomtest-
nameSuffix: -v2
commonLabels:
  app: kustomized-wasliberty
resources:
- deployment.yaml
- service.yaml
- pvc.yaml
- configmap.yaml
- secret.yaml

      resources 下各 YAML 的名称必须与 base 存储库中其他文件的名称相匹配。 您可在同一文件中包含多个配置，但在示例中，这些配置分别位于不同的文件中，例如 deployment.yaml、service.yaml 和 pvc.yaml。

    4. 使用在 kustomization 基本 YAML 文件中定义的配置来构建资源 YAML 文件。 通过将 kustomization 和资源 YAML 中的配置组合在一起来构建资源。 合并后的YAML文件将以 stdout 的形式返回到输出中。 使用此相同的命令可构建对 kustomization YAML 进行的任何后续更改，例如添加标签。

      kustomize build

  5. 使用对每个环境（例如，编译打包和生产）唯一的 kustomization YAML 文件来设置 overlay 存储库。

    1. 在 staging 存储库中，创建 kustomization.yaml 文件。 添加对于编译打包唯一的任何配置（例如，标签或映像标记），或为要测试的新组件添加 YAML。

      apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namePrefix: staging-
commonLabels:
  env: staging
  owner: TeamA
bases:
- ../../base
patchesStrategicMerge:
- configmap.yaml
- new_staging_resource.yaml
resources:
- new_staging_resource.yaml
      了解 YAML 组件
      组件 描述
      namePrefix 指定一个前缀，附加到您想要用临时 kustomization 文件创建的每个资源的名称上，例如 staging-。
      commonLabels 添加对编译打包对象（例如，编译打包环境和负责团队）唯一的标签。
      bases 将目录或 URL 的相对路径添加到包含基本 kustomization 文件的远程存储库。 在此示例中，相对路径指向先前创建的 kustomization 存储库中的基本 base 文件。 对于覆盖 kustomization，此字段是必需的。
      patchesStrategicMerge 列出要合并到基本 kustomization 的资源配置 YAML 文件。 您还必须将这些文件添加到 kustomization 文件所在的存储库，例如 overlay/staging。 这些资源配置文件可以包含小型更改，这些更改会合并到与补丁同名的基本配置文件。 该资源将获取 base 配置文件中的所有组成部分，以及在 overlay 配置文件中指定的任何其他组成部分。 如果配置是不在 base 中的新文件，那么还必须将文件名添加到 resources 字段中。
      resources 列出对 staging 存储库唯一且不包含在 base 存储库中的任何资源配置 YAML 文件。 将这些文件也添加到 patchesStrategicMerge 字段中，并将其与 kustomization 文件添加到同一个存储库中，例如 overlay/staging。
      其他可能的配置 如需了解可添加到文件中的更多配置，请参阅 创建 kustomization 文件。

    2. 构建编译打包覆盖配置文件。

      kustomize build overlay/staging

    3. 重复这些步骤以创建生产覆盖 kustomization 及其他配置 YAML 文件。 例如，可能会增加 deployment.yaml 中的副本数，以便生产环境可以处理更多用户请求。

    4. 复查 kustomize 存储库结构，以确保它包含您需要的所有 YAML 配置文件。 此结构可能类似于以下示例。

      ├── base
│   ├── configmap.yaml
│   ├── deployment.yaml
│   ├── kustomization.yaml
│   ├── pvc.yaml
│   ├── secret.yaml
│   └── service.yaml
└── overlay
    ├── prod
    │   ├── deployment.yaml
    │   ├── kustomization.yaml
    │   └── new_prod_resource.yaml
    └── staging
        ├── configmap.yaml
        ├── kustomization.yaml
        └── new_staging_resource.yaml

  6. 对要部署的环境应用 Kubernetes 资源。 以下示例使用 staging 存储库。

    1. 导航至 overlay 下的 staging 目录。 如果在上一步中未构建资源，请立即创建这些资源。
      cd overlay/staging && kustomize build
    2. 将 Kubernetes 资源应用于集群。 包括 -k 选项和 kustomization 文件所在的目录。 例如，如果已经位于 staging 目录中，请包含 ../staging 以标记该目录的路径。
      oc apply -k ../staging
      示例输出 
      configmap/staging-kustomtest-configmap-v2 created
secret/staging-kustomtest-secret-v2 created
service/staging-kustomtest-service-v2 created
deployment.apps/staging-kustomtest-deployment-v2 created
job.batch/staging-pi created
persistentvolumeclaim/staging-kustomtest-pvc-v2 created
    3. 检查以确保应用了对于编译打包唯一的更改。 例如，如果添加了 staging- 前缀，那么创建的 pod 和其他资源将在其名称中包含此前缀。
      oc get -k ../staging
      示例输出 
      NAME                                        DATA   AGE
configmap/staging-kustomtest-configmap-v2   2      90s

NAME                                  TYPE     DATA   AGE
secret/staging-kustomtest-secret-v2   Opaque   2      90s

NAME                                    TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
service/staging-kustomtest-service-v2   NodePort   172.21.xxx.xxx   <none>        9080:30200/TCP   90s

NAME                                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/staging-kustomtest-deployment-v2   0/3     3            0           91s

NAME                   COMPLETIONS   DURATION   AGE
job.batch/staging-pi   1/1           41s        2m37s

NAME                                              STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS       AGE
persistentvolumeclaim/staging-kustomtest-pvc-v2   Pending                                      ibmc-file-bronze   90s
    4. 针对要构建的每个环境，重复上述步骤。

  7. 可选：通过除去使用 Kustomize 应用的所有资源，清除您的环境。

    oc delete -k <directory>

    示例输出

    configmap "staging-kustomtest-configmap-v2" deleted
secret "staging-kustomtest-secret-v2" deleted
service "staging-kustomtest-service-v2" deleted
deployment.apps "staging-kustomtest-deployment-v2" deleted
job.batch "staging-pi" deleted
persistentvolumeclaim "staging-kustomtest-pvc-v2" deleted