@runeron that’s exactly right, and I’d wager a bet that it’s the same thing @marco-m is after. In k8s world, this would be something like ArgoCD or Flux CD (already mentioned by you), where an operator deployed to the cluster monitors a got repo (our single source of truth) and ensures that in the event there is some external change, then the state is reconciled with git repo.
Example:
A new version of the app is deployed and possibly k8s manifests are updated too. This goes through a rigorous testing and PR and gets merged. The gitops operator sees there is a new version and deploys these updates. Later, there is an issue, and someone starts debugging, changing k8s deployment configs etc. If they forget to submit an updated manifest with any changes they made, the operator will override those, as the git repo is the source of truth. This therefore ensures and enforces to some extent, that developers always commit any ad-hoc changes they may have made.
In Nomad, I’d think something akin to that would be cool. Possibly something in the server stanza config stating which repo to watch, and all job specs get picked up from that repo. Obviously, that would render the nomad cli/ui as useless as the reconciliation would override it.
The problem is that HashiCorp and many others think that GitOps is a one-way thing where a git commit triggers a pipeline that then deploy something. Thats only half the solution.
As some here has mentioned, you need a controller that keeps looking for changes, and enforces the state in git in your cluster.
We have a lot of ideas for the controller, but its still developed in our spare time. It’s not finished, and all contributions are welcome.
We tried Waypoint, but it’s basically doing the same as a Jenkins would do. Pull, build, test and deploy. We want to separate CI and CD from deployment, making releasing/deployment a simple business decision and done by a simple git operation.
For those that are comfortable using terraform, there is a nomad terraform provider. Terraform also has a github action available. I define all my jobs as “nomad_job” resources in terraform, then have an action on push to main to run terraform apply which deploys / updates all my nomad jobs, creates volumes, etc. i am pretty happy with the terraform approach. It is simple, easy to run locally if-needed, and is mostly bullet proof with the caveat that some nomad specific issues arent caught by “terraform plan”. Still works really well and is fully declarative.