juju / bundlechanges

A Go library to generate the list of changes required to deploy a bundle

Juju is an open source application orchestration engine that enables any application operation (deployment, integration, lifecycle management) on any infrastructure (Kubernetes or otherwise) at any scale (development or production) in the same easy way (typically, one line of code), through special operators called ‘charms’.

👉	Juju	Learn how to quickly deploy, integrate, and manage charms on any cloud with Juju. It's as simple as juju deploy foo, juju integrate foo bar, ..., on any cloud.
	Charmhub	Sample our existing charms on Charmhub. A charm can be a cluster (OpenStack, Kubernetes), a data platform (PostgreSQL, MongoDB, etc.), an observability stack (Canonical Observability Stack), an MLOps solution (Kubeflow), and so much more.
	Charm SDK	Write your own charm! Juju is written in Go, but our SDK supports easy charm development in Python.

Give it a try!

Let's use Juju to deploy, configure, and integrate some Kubernetes charms:

Set up

You will need a cloud and Juju. The quickest way is to use a Multipass VM launched with the charm-dev blueprint.

Install Multipass: Linux | macOS | Windows. On Linux:

sudo snap install multipass

Use Multipass to launch an Ubuntu VM with the charm-dev blueprint:

multipass launch --cpus 4 --memory 8G --disk 30G --name tutorial-vm charm-dev 

Open a shell into the VM:

multipass shell tutorial-vm

Verify that you have Juju and two localhost clouds:

juju clouds

Bootstrap a Juju controller into the MicroK8s cloud:

juju bootstrap microk8s tutorial-controller

Add a workspace, or 'model':

juju add-model tutorial-model

Deploy, configure, and integrate a few things

Deploy Mattermost:

juju deploy mattermost-k8s

See more: Charmhub | mattermost-k8s

Deploy PostgreSQL:

juju deploy postgresql-k8s --channel 14/stable --trust

See more: Charmhub | postgresql-k8s

Enable security in your PostgreSQL deployment:

juju deploy tls-certificates-operator
juju config tls-certificates-operator generate-self-signed-certificates="true" ca-common-name="Test CA"
juju integrate postgresql-k8s tls-certificates-operator

Integrate Mattermost with PostgreSQL:

juju integrate mattermost-k8s postgresql-k8s:db

Watch your deployment come to life:

juju status --watch 1s

(Press Ctrl-C to quit. Drop the --watch 1s flag to get the status statically. Use the --relations flag to view more information about your integrations.)

Test your deployment

When everything is in active or idle status, note the IP address and port of Mattermost and pass them to curl:

curl <IP address>:<port>/api/v4/system/ping

You should see the output below:

{"AndroidLatestVersion":"","AndroidMinVersion":"","IosLatestVersion":"","IosMinVersion":"","status":"OK"}

Congratulations!

You now have a Kubernetes deployment consisting of a Mattermost backed by PosgreSQL with TLS-encrypted traffic!

Clean up

Delete your Multipass VM:

multipass delete --purge tutorial-vm

Uninstall Multipass: Linux | macOS | Windows. On Linux:

snap remove multipass

Next steps

Learn more

• Read our user docs
• Read our developer docs

Chat with us

Read our Code of conduct and:

• Join our chat: Matrix
• Join our forum: Discourse

File an issue

• Report a Juju bug on Launchpad
• Raise a general https://juju.is/docs documentation issue on Github | juju/docs

Make your mark

• Read our documentation contributor guidelines and help improve a doc
• Read our codebase contributor guidelines and help improve the codebase

bundlechanges's Issues

Splitting deploy into add-machine/add-unit --to is incompatible with MAAS storage

See https://bugs.launchpad.net/juju/+bug/1691694

The problem is that MAAS disks are bound to the machines, so you cannot use "juju add-machine" and then expect to be able to deploy an application unit that requires disks to that machine. Not all machines are the same; we use the unit's storage requirements to influence the machine creation constraints.

In the Juju CLI we can probably work around this for now by combining some cases of (AddMachine, AddApplication, AddUnit) triples into single "Deploy" API calls.

bundle format doesn't support dictionary constraints

Reference to: https://bugs.launchpad.net/juju-quickstart/+bug/1478254

juju quickstart http://cloud-benchmarks.org/submissions/19.yaml
usage: juju-quickstart [-h] [-e ENV_NAME] [-n BUNDLE_NAME] [-i] [-u]
[--gui-charm-url CHARM_URL] [--gui-port PORT]
[--no-browser] [--environments-file ENV_FILE]
[--distro-only] [--ppa] [--version] [--debug]
[--description] [--upload-tools]
[--upload-series UPLOAD_SERIES]
[--constraints CONSTRAINTS]
[BUNDLE]
juju-quickstart: error: unable to open the bundle: invalid bundle data:
service mongodb has invalid constraints {u'mem': u'1700M', u'arch': u'amd64', u'cpu-power': u'138', u'cpu-cores': u'1', u'root-disk': u'10240M'}
ERROR subprocess encountered error code 2

This was a different bundle. It appears that if constraints are not a string (instead a dictionary) quickstart will fail. Deployer has support for constraints as dictionaries. While this isn't explicitly in the bundle format, it'd be great to see this become official. Treating constraints as a dictionary means better parsing and management of bundles as well as ease in writing bundles by hand.

http://bazaar.launchpad.net/~juju-deployers/juju-deployer/trunk/view/head:/deployer/env/base.py#L88