GitOps workflow?

1

Any thoughts on how someone could use a gitops workflow with Juju?

What I’m think about is:

  1. Create a juju controller and model
  2. Bind the model to a git repository
  3. Write bundle
  4. Git commit the changes
  5. Changed get applied to juju model
  6. Further changes get applied each time there’s a new git commit in the repo

Has anyone played with this idea already?

1 Like
2

Hey @davecore

I’m currently experimenting using Ansible Tower and Gitlab to manage the life cycles of my models.

I’ve written a simple playbook to clone the repo locally and then run things like juju switch “{{ model_var }}” and then juju deploy ./"{{ charmbundle }}"

The Tower template gets triggered by a webhook from Gitlab on committing changes.

I started doing this to track which changes were causing issues. Right now the workflow is a little fragile but the lazyness and visibility factor is great.

3

I know someone had played with a charm that ran as a git-webhook receiver, and then would publish the revision from the webhook as relation data. (So what version of the website should the Website charm deploy.)
I haven’t seen one that would control the entire layout of the deployment. That requires something that has model level access, rather than just be related to other applications. This would also be a very good use case for “Stacks” (where you have a bundle of applications controlled by one of the charms in the bundle). That is still more conceptual than realized, but it would fit that model fairly well.

4

Depending on how far you want to go down this rabbit hole and how large of an environment you want to control using this flow there is a project called mojo that is used to do exactly this. It uses mojo configuration objects called manifests to apply changes to an entire Juju environment.

I haven’t used it in years so I can’t offer any first hand anecdotes but I know that it is being used by others to manage very large deployments where auditing all changes (and having the ability to roll back) is important.

1 Like
5

Hello,

We are already keeping our own OpenStack bundle on our Gitlab server that runs on OpenStack. We have CI/CD ops already. Once we commit, Gitlab runner connects to a server via SSH and pulls bundle configs and runs the bundle deploy command automatically.

We are using it in our testing environment and it saves a lot of time for us.

2 Likes
6

Thanks for the ideas everyone. I did something similar but with GitHub Actions:

https://github.com/davecore82/juju-gitops

name: Test bundle
on: [push]
jobs:
  test-bundle:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      #- uses: mxschmitt/action-tmate@v3
      - run: sudo snap install juju --classic
      - run: sudo snap install juju-wait --classic
      - run: sudo juju bootstrap localhost --config test-mode=true --config automatically-retry-hooks=false
      - run: sudo juju deploy ./bundle.yaml
      - run: sudo /snap/bin/juju-wait -wv
      - run: sudo juju status

Once I commit the code to my github repo, github actions creates an ubuntu VM and installs juju and bootstraps on LXD and deploys my bundle.

I would consider using an ssh action to ssh to an existing juju controller host somewhere and run the deploy there too. It could even be conditional to this local run exiting successfully.

1 Like