标签: gitops

我刚刚阅读https://docs.fluxcd.io/projects/helm-operator/en/stable/helmrelease-guide/debugging/#manually-performing-a-release-to-debug以及常见问题解答，但无法不知道如何触发 HelmRelease 的重试。

我的解决方法是对监视的版本存储库提交一个无关紧要的更改，只是为了让 helmoperator 获取差异。有没有更好的办法？

我正在使用 ArgoCD，我想跟踪不同子目录下的文件。我已将路径设置为 ./root_directory，但我还想跟踪 root_directory 子目录中的文件。例如 /root_directory/dir1、/root_directory/dir2，还有 /root_directory/dir1/dir1.1 ecc.. 我该怎么做？

感谢您的帮助

我已经通过 ArgoCD 成功部署了应用程序，并且可以通过其入口 url 访问它

应用程序使用带有最新标签的图像名称，例如

image: <private_registry>/app_1_service:latest

我还管理同一标签上的其他标签latest，例如image:<commit_id> or image:<1.0.xxx>

现在，开发人员将更新代码，提交更改后，gitlab 管道会自动运行并构建新映像并覆盖以latest使用其他标签进行标记并推送到私有 docker 注册表

那么 ArgoCD 的下一步是什么？

argocd 如何知道应用程序已更改，需要重新部署，以及image:latest需要再次拉取？

我们有一个 ArgoCD 项目。在这个项目中，我们有多个应用程序（我们称它们为 A、B 和 C），它们通过 Kafka 集群相互传递消息。为此，需要创建主题。

应用程序 A 负责管理 Kafka 集群（除其他外）。我们在应用程序 A 中有一个 PreSync 挂钩，用于在更新应用程序 B 和 C 所依赖的其他资源之前创建和配置主题的作业。

这意味着我们需要应用程序 A 在其他应用程序之前同步，以确保顺利推出。为了尝试管理这个问题，我们将应用程序 A 添加到 SyncWave -1，其他应用程序处于默认状态0

kind: Application
metadata:
  name: "A"
  annotations:
    argocd.argoproj.io/sync-wave: "-1"

我们最初的假设（也许是愚蠢的）是同步协调应用于项目内，但是，它似乎仅应用于应用程序内。

因此，应用程序 A 中的资源会等待 PreSync 挂钩按预期配置主题，但应用程序 B 和 C 不会等待应用程序 A 同步。

有没有办法控制项目内应用程序之间同步的顺序/依赖关系？

我见过提到“应用程序的应用程序”模式，其中您有一个应用程序部署所有其他应用程序。这样做是否允许我们利用 SyncWave 确保应用程序 A 在尝试同步应用程序 B 和 C 之前完全解析？如果没有，还有其他办法吗？

我们正在尝试在我的公司使用 ArgoCD 使用 GitOps，我们有一个主要问题：

Jenkins, our CI tool, currently pushed to our docker repo on merge of any PR with a tag relating to the git commit hash currently in use.

Edit: We would like, upon choosing a targetRevision, to get its git hash as a string to use in value overwriting the imageTag in our helm charts.

Now Option 1 is we just have it also change the imageTag in any relevant kubernetes files.

However I wonder if there …

我正在寻找 ArgoCD for Kubernetes 以 GitOps 方式部署应用程序。

只是想知道是否有适用于 AWS ECS 和 Hashicorp Nomad 的类似产品。

我知道AWS Proton，它不像ArgoCD那么简单。对于AWS ECS，我只是在寻找一些可以读取ECS任务定义和服务定义并将其与AWS ECS同步的工具。

我已经开始使用 k8s 和 argoCD 进行 GitOps 之旅，使用应用程序源和部署文件（清单、环境配置等）的单独存储库，并且我试图弄清楚，如果应用程序源代码更改还需要更改环境配置。

示例：应用程序已部署并在测试/QA 环境中运行，我想推送代码更改，这需要新的“DB_ConnectionString”环境变量。由于此环境变量是新的，因此它不存在于我的部署/gitops 存储库的配置文件中（假设它是 Helm value-QA.yml）。

如果我推送这个新的代码更改，CI 将构建应用程序并更新容器，这会提示 argoCD 部署新的容器版本 - 但因为我还没有更新 GitOps 存储库，所以它缺少这个新变量，并且部署将失败。

我想我很难理解，如果在这些情况下，我被迫始终确保我的 GitOps 存储库在我的应用程序存储库之前更新，以及是否有最佳实践来处理此流程？

我正在尝试在我们公司引入 GitOps。大多数情况下，我们都有用 Django 编写的微服务（但是，它也可以是任何其他 Web 框架）。我对数据库迁移有一个概念性问题。向前迁移很简单：您可以将它们作为作业或 init 容器或 helm 中的钩子来运行。但是向后迁移呢？假设我想从 v1.1 回滚到 v1.0，并且我有一些迁移需要取消应用。现在怎么办？我想使用 argo cd 或 Flux。

有一篇非常好的文章：https://www.weave.works/blog/how-to- Correctly-handle-db-schemas-during-kubernetes-rollouts 。然而，它需要一些 Django 中没有的纪律

我已经使用Flux v2设置了持续交付管道（因为 Flux v1 已弃用），并且运行良好。另一方面，我看到 Argo 和 Flux 在 2019 年底开始合并（请检查此链接）。

我想知道 Flux v2 是否是 Argo-Flux 合并的演变，或者它们是两个独立的 GitOps 实现选项。

我的印象是 Flux v2 非常活跃，所以我想它是一个真正的选择，并且至少会存在一段时间。但我对 Argo-Flux 不了解，也找不到太多信息。

谢谢！

我有一个我认为常见的用例，但我真的很难找到解决方案：

我想Kustomize在我们的部署中重用补丁中的变量。具体来说，我们使用提交 ID 来引用图像标签（用例 A）和与部署相关的 k8s 作业（用例 B）。

我们使用的设置中，对于每个 ArgoCD 应用程序，我们都有一个/base/文件夹/overlays/[environment-name]，并且该基础用kustomization.yaml.

用例A：

一个非常简单的用法 -/overlays/[environment-name]我们有一个kustomization.yaml使用：

images:
- name: our-aws-repo-url
  newName: our-aws-repo-url
  newTag: commit-id

工作起来就像一个魅力，因为我们可以将其重新用于部署本身及其相关作业，所有这些都只需一个提交引用。

用例 B：

问题：

我们使用 N 个作业来进行 0 停机部署的迁移，其中我们运行运行迁移的 alembic 容器，并且我们有一个waitforit initContainer监听作业完成的容器，即当迁移成功时才能进行部署。

现在的问题是，我需要触摸一个服务覆盖层中的 4 个文件来修补各处的 id（我们用它来识别作业）：

• 部署.yaml 像这样：

- image: groundnuty/k8s-wait-for:v1.4
  imagePullPolicy: IfNotPresent
  args: 
   - "job"
   - "job-commit-id"

• job.yaml 本身更改作业的重新触发以进行新的部署/潜在的迁移：

apiVersion: batch/v1
kind: Job
metadata:
  name: job-commit-id

• kustomization.yaml，如用例 A 中所述。

我认为应该可行的是：

1. 在 kustomization.yaml 中以某种方式定义变量 …