Unofficial Juju Docker Images
Charles Butler
on 10 July 2015
Early this year the juju-solutions team has been experimenting with Juju in
Docker – namely for isolation, and portability reasons. The Vagrant image gives
a nice isolated and rebuildable environment – however the overhead of the
bootstrap every time, spinning up the GUI, and etc – caused a latency that we
just didnt want or need in our CI environment(s) – as well as when running the
review queue.
Up until this point, the images have all been distributed under various
namespaces in the Docker hub registry – and one thing we wanted to ensure was
that these images were accessable, and under a high standard for quality.
Where do I find these magical images?
We’re aggregating our project images under the jujusolutions
namespace on the docker registry for now. A star would go a long way towards
helping discoverability. In addition, the source repositories are available for
bugreports and feature requests in our Github Organization
Both images are shipped with 2 possible tags.
:latest
(recommended) – will pull the latest stable Juju release baked into the image:devel
(experimental) – will pull the latest development Juju release baked into the image
I will be working hand in hand with Aisreal to get a :nightly tag added for
those wanting to explore the current Juju built from tip of the Github archives.
This is really handy when testing new features, and not wanting to pollute your
system with the dev dependencies for compiling Juju from source, or breaking
an existing installation.
Whats the difference between Jujubox and Charmbox?
Jujubox
is a bare-bones juju image, shipped and configured for the Ubuntu user
as the primary juju user. You can use this image to run automated deployments
from say a CI/CD server. It doesn’t ship with any additional tooling.
- juju
- juju-quickstart
- juju-plugins
Charmbox
is a fatter package, but ships with all the tooling needed to perform
the daily tasks of a Juju Charmer. It ships by default with:
- git
- bzr
- charm-tools
- juju-plugins
- juju-deployer
- juju
- juju-quickstart
- build-essential
- amulet
- bundletester
How often are they updated?
As new juju releases are shipped, these images are now rebuilt every night at
3 am EDT.
Whats the catch?
Using the local provider in these docker images is extremely tricky, and is
covered in the Charmbox repository README
How is the Juju Solutions team using these images?
We’re currently using these images in house in our Jenkins CI system that powers
our review testing of incoming charms, and charm updates.
Another CI based Usecase has been a Drone.io Implementation i’ve been working on
to run our Kubernetes upstream validations as they cut new revisions. I will
be sure to post an in-depth follow up post once this particular use case has been
classified as stable. But this shows the extensibility of these images, and how
they can be applied for your own CI setup, to run express, upstream integration
jobs.
Here’s a snippet from the Dockerfile:
FROM jujusolutions/charmbox
ADD install-gvm.sh /tmp/install-gvm.sh
RUN /tmp/install-gvm.sh
ADD kubes-ci-run.sh /kubes-ci-run.sh
ADD requires/ssh /home/ubuntu/.ssh
ADD requires/juju /home/ubuntu/.juju
ENTRYPOINT
CMD sudo -u ubuntu /bin/bash -c "/kubes-ci-run.sh"
When doing Review Queue we also like to isolate our reviews using these images
and running them with the –rm to ensure any development dependencies are wiped
when we exit the context of the image. I posted about this in-depth in
Expediting Isolation with Juju and Docker
And finally, we find these images are great for a portable Juju installation on
any distro/platform – regardless of it being windows, OSX, or Linux based. The
fact these containers are light enough weight to spin up in a second or less means
you can get to hacking on your cloud deployments faster than our shipped Vagrant
image.
What’s the risk of unsolved vulnerabilities in Docker images?
Recent surveys found that many popular containers had known vulnerabilities. Container images provenance is critical for a secure software supply chain in production. Benefit from Canonical’s security expertise with the LTS Docker images portfolio, a curated set of application images, free of vulnerabilities, with a 24/7 commitment.
Newsletter signup
Related posts
Maximizing CPU efficiency and energy savings with IntelⓇ QuickAssist Technology on Ubuntu 24.04
In this post, we show that IntelⓇ QAT can be used in Ubuntu 24.04 LTS to offload compute intensive workloads, maximizing CPU efficiency and driving cost savings.
Meet Canonical at SIGGRAPH 2024: Innovating Animation and VFX
We are coming to Siggraph 2024. Discover how Ubuntu and other Canonical solutions can drive innovation in animation and enable secure usage of open-source software.
Canonical offers 12 year LTS for any open source Docker image
‘Everything LTS’ – Canonical will build distroless Docker images to customer spec that include upstream components not packaged in Ubuntu, and fix critical...