Overview
The mechanics of how upgrades work for k8s deployments is similar to what happens for non-k8s:
- Juju checks to see what agent binaries are available, using
agent-stream
to select between develop, proposed, and released binaries - the requested image is downloaded and used
A key difference is where the agent binaries are sourced. For non-k8s, it’s simplestreams. For k8s, it’s dockerhub.
The default dockerhub account used to store the Juju j8s operator images is jujusolutions
. Tags are used to represent the Juju version, 2.7.5, 2.8-beta1, 2.8-beta1.1 etc.
Production upgrades
When a user types juju upgrade-controller
, Juju will:
- list all of the jujud-operator images on dockerhub
- filter the images based on the agent-stream value
- instruct k8s to pull the most recent image, unless --agent-version is used to pick a specific image
- k8s will update the controller pod with the selected image
The agent-stream filtering is:
-
devel
selects all images taggedbeta
and higher -
proposed
selects all images taggedrc
and higher - 'released` (the default) only selects images without tags, eg 2.7.5
Upgrades in development
makefile targets
We’ll use 2 makefile targets:
- operator-image
- push-operator-image
Procedure
For developing Juju, you want to use you own dockerhub namespace to host the binaries, not jujusolutions
. So start by setting DOCKER_USERNAME=, eg
export DOCKER_USERNAME=wallyworld
Since Juju pulls all docker images it needs from this docker username, you’ll need to make sure the Mongo DB image is copied there first up.
docker pull jujusolutions/juju-db:4.0
docker tag jujusolutions/juju-db:4.0 wallyworld/juju-db:4.0
docker push wallyworld/juju-db:4.0
For the controller to use your dockerhub username, you’ll need to set the caas-image-repo
controller config. This can be done at bootstrap time:
juju bootstrap microk8s --config caas-image-repo=wallyworld
Assuming you have a 2.7.5 controller deployed, and you want to test upgrading to a 2.8-beta1 version you are working on…
-
push a locally complied 2.8-beta1 image to dockerhub
make push-operator-image
-
upgrade the controller
juju upgrade-controller --agent-stream=develop
If it were an rc, you could use --agent-stream=proposed
.
Or you could pick a specific version if --dry-run
showed something other than what was wanted
juju upgrade-controller --agent-stream=develop --agent-version=2.8-beta3
–build-agent replacement
Say you’ve deployed the latest version of Juju from develop branch and you want to make a change and try out a new build number. For k8s , --build-agent
cannot work, so the steps are:
-
build an operator image from source
(it will always have the juju version from the branch, eg 2.8-beta1)
make operator-image
-
tag the operator image with a build number eg 1
docker tag wallyworld/jujud-operator:2.8-beta1 wallyworld/jujud-operator:2.8-beta1.1
-
push this tagged image to dockerhub so Juju upgrades can see it
docker push wallyworld/jujud-operator:2.8-beta1.1
-
upgrade as normal
juju upgrade-controller --agent-stream=develop
If you’re curious what images you’ve got built locally taking up space, you can always list them
docker image list
Speeding up microk8s bootstrapping
To cut out the step to push the operator image to dockerhub and require microk8s to download it again, you can seed the microk8s image cache directly.
make microk8s-image-update
juju bootstrap microk8s
You can also use a different namespace to jujusolutions
as already covered above.
export DOCKER_USERNAME=wallyworld
make microk8s-operator-update
juju bootstrap microk8s --config caas-image-repo=wallyworld