如何使用Kustomize在Spring Boot应用程序中管理配置文件和容器镜像

"""Catalog Service的基本Kustomization指示Kustomize从application.yml文件生成一个catalog-config ConfigMap。要自定义该ConfigMap中的值，我们有两个主要选项：替换整个ConfigMap或仅覆盖在staging中应该不同的值。在第二种情况下，我们可以通常依赖于一些高级的Kustomize修补策略来覆盖ConfigMap中的特定值。\n\n在使用Spring Boot时，我们可以利用Spring配置文件的功能。我们可以添加一个application-staging.yml文件，当staging配置文件激活时，我们知道它优先于application.yml。最终的结果将是一个包含两个文件的ConfigMap。\n\n首先，在Catalog Service的staging overlay中创建一个application-staging.yml文件。我们将使用此属性文件为polar.greeting属性定义一个不同的值。由于我们将使用前面的minikube集群作为staging环境，因此后端服务的URL和凭据与开发环境中的相同。在真实的场景中，这个阶段可能会涉及更多的定制。\n\n接下来，我们可以依赖Kustomize提供的ConfigMap Generator将application-staging.yml文件（在staging overlay中定义）与application.yml文件（在base Kustomization中定义）合并到同一个catalog-config ConfigMap中。请按照以下步骤更新staging overlay的kustomization.yml文件。\n\n就这样，关于ConfigMaps的内容就到这里了。接下来的部分将介绍如何配置要部署的镜像名称和版本。\n\nCatalog Service代码库（catalog-service/k8s/deployment.yml）中定义的基本Deployment清单配置为使用本地容器镜像，并且没有指定版本号（这意味着使用最新的标签）。这在开发阶段很方便，但在其他部署环境中不起作用。\n\n如果您按照本文进行操作，应该在GitHub上的catalog-service代码库中跟踪了您的Catalog Service源代码，并发布了一个ghcr.io/<your_github_username>/catalog-service:latest容器镜像到GitHub Container Registry（根据Commit Stage工作流程）。下一章将介绍发布策略和版本控制。在那之前，我们仍将使用最新的标签。不过，关于镜像名称，是时候开始从注册表拉取容器镜像而不是使用本地镜像了。\n\n注意：发布到GitHub Container Registry的镜像将具有与相关GitHub代码库相同的可见性。我假设我们为Polar Bookshop构建的所有镜像都可以通过GitHub Container Registry公开访问。如果不是这种情况，您可以转到GitHub上的特定仓库页面，访问该仓库的Packages部分。然后从侧边栏菜单中选择Package Settings，滚动到设置页面的底部，并通过单击Change Visibility按钮将包设置为公开。\n\n与环境变量的做法类似，我们可以使用补丁来更改Catalog Service Deployment资源使用的镜像。然而，由于这是一个非常常见的定制化需求，并且每次交付新版本的应用程序时都需要更改，因此Kustomize提供了一种更方便的方式来声明我们要为每个容器使用的镜像名称和版本。此外，我们可以直接更新kustomization.yml文件，也可以依赖于Kustomize CLI（作为Kubernetes CLI的一部分安装）。让我们尝试后者。\n\n打开一个终端窗口，导航到Catalog Service的staging overlay（kubernetes/applications/catalog-service/staging），并运行以下命令来定义catalog-service容器使用的镜像和版本。请记得将<your_github_username>替换为您的小写GitHub用户名。\n""\