What is the idiomatic approach to maintain talos manifests with git?

[spuxx-dev]

Hello there! I'm fairely new to Talos Linux and decided to give it a try.

However, I find myself wondering how to properly maintain the talos manifest files with git. I quickly found myself writing scripts to patch and apply node config files and I began to wonder whether this really was expected from me. A couple of questions I came across:

1. Am I expected to permanently keep around entire controlplane and worker config manifests? For one, they contain secrets, which I extract to a secrets.yaml that is handled with sops. It confuses me a bit that my infrastructure/config files contain secrets (by default even!) and I can't find a way to tell talosctl to keep secrets and config completely separate. And second, they quickly become quite large. I feel like falling back to Talos' defaults and only manage my changes in patch files might be a better approach.
2. I wrote myself some script that would receive cluster connetion details, a talosconfig file path and a secrets file path and would then automatically gather patches and output node config manifests. Same script would then apply those manifests to the cluster. This feels hacky. Is there a better way?
3. I'm not quite sure why I always need to provide an endpoint for talosctl even though the endpoint is set in my talosconfig file and that talosconfig file is referenced in my cli commands.

I'd be very glad if someone could give me a couple of tips or even post some examples for a gitops/infrastructure-as-code style talos repo.

[smira]

The easiest path is to use Omni, which takes care of config management for you completely.

Now, the flow if not using Omni:

• pick a --talos-version which is the initial version of Talos cluster was created with, e.g. v1.9 (patch version doesn't matter)
• generate a secrets bundle with talosctl gen secrets --talos-version=... and save this secrets bundle - this is the most important piece of information to save
• figure out a set of config patches you might need for the whole cluster, for some machines (e.g. workers), or per-machine specific; config patches should be saved as well
• now, at any moment, there's a reproducible way to generate a machine configuration for each node, providing three things as inputs:
  • --talos-version
  • secrets.yaml
  • a set of config patches
• something like talosctl gen config <name> https://<endpoint> --talos-version=... --with-secrets=secrets.yaml --config-patch @cluster.yaml .... --output-types controlplane --output controlplane1.yaml

[smira]

So the proper way is to skip storing the final machine configuration generated, but rather store all inputs to the machine configuration generation, and generate it on the fly.

[spuxx-dev]

I see, thanks for the response @smira . That's what I ended up doing: I created a repository that stores my (encrypted) secrets as well as my patches. I also included a small deno repository and a bunch of TypeScript files for encrypting, decrypting, generating and applying my configs.

I feel that talosctl could include a couple more DX things so I wouldn't have to create some custom scripts, but I'll take that for now. :)

[madeddie]

There is also https://github.com/budimanjojo/talhelper that uses a single config to generate talosconfig and can use SOPS to encrypt the secrets at rest.