I am looking for best practices for using fcos configs in the most lean way always keeping additional scripting/templating effort low
Current use-case:
We manage config with a size of up to 200 lines for around 6 different instance types (quite some systemd overhead with configuring units running podman containers). Some shell scripts are pulled in addition (ignition remote files), to help bootstrapping e.g. database clusters (all not more than 50 to 100 lines).
This configs are at the moment pre-transpiled and shipped with our in-house service, an abstraction layer (unified api), to connect/manage things like aws, ci, git, chat a.s.o. as well as replacing some placeholders in ignition files e.g. stack uuid to set zincati identity group if we need fleet-lock strategy.
At the moment we manage several hundred instances from development to production. Most of them form many “small” stacks/clusters (similar to k8 but using consul and nomad to reduce our footprint)
Current issue:
If we use toml fragments to configure zincati (file section of coreos config), the transpiled version escapes our placeholders in a way we cannot use it any longer.
As this service is not written in golang and packaged as container like all our other services, we do not see it as good practice to execute a commandline from a service which only uses clean apis from third party services.
This post is related to agent: support ZINCATI_AGENT_IDENTITY_GROUP env value · Issue #275 · coreos/zincati · GitHub, to explain a bit our specific use-case. I looked into matchbox and terraform but these tools seem to not really fit or bring too much functionality we do not need at the moment.
A potential solution would be to run fcct as service to allow us to use coreos configs directly (replacing placeholder before we transpile on the fly)
GitHub - zyclonite/fcct-service: FCCT as a Service