Best practices for "fat" charms

Simon Davy bloodearnest at gmail.com
Wed Apr 2 08:27:27 UTC 2014


Resending this to the list, rather than just Jorge, sorry.

On 1 April 2014 20:07, Jorge O. Castro <jorge at ubuntu.com> wrote:
> Hi everyone,
>
> Matt Bruzek and I have been doing some charm testing on a machine that
> does not have general access to the internet. So charms that pull from
> PPAs, github, etc. do not work.
>
> We've been able to "fatten" the charms by doing things like creating a
> /files directory in the charm itself and putting the
> package/tarball/jar file in there, and given the networking issues
> that we might face in production environments that we should start
> thinking about best practices for having charms with payloads instead
> of pulling from a network source.

Great question :)

So we have been deploying "fat" charms in a restricted environment
like this since we started using juju. Our build machines have no
internet access, but they *can* access the ubuntu archives, a private
archive, and launchpad, and other internal services.

For us there are two kinds of charms that need different work to
support these restrictions.

One type is the regular charmstore charms than make up your
infrastructure glue (like apache2, haproxy, squid, postgresql, etc).
These kinds of packages don't change their core software payload
often, usually on stable releases.

For charms like these that install things that are not in the ubuntu
archives, we fork and modify them as necessary to support installing
from a custom archive, for which we build a package ourselves. A good
example of a charm that works well this way is elastic search, which
uses the vendor packages by default, but allows you to specify a ppa
or archive to install from instead in the config. Many other charms
also do this, but not all, so it's worth noting I think.

The other type is "application" charms, which are typically private
charms where the payload is your application, and you can change the
core software payload multiple times a day.

For these charms (our core workload) we do a "fat" charm as you suggest above.

1) check out pinned version of the charms into a local repository

2) run a build step over the local repository that looks for a
Makefile with a charm-payload target in each local charm's dir.

3) if found, it is run, which pulls deps and builds. Source deps
have to be mirrored in lp, package deps not in main need to be added
to the private archive. A build will fail if it tries to reach
something it can't.

4) this produces some artifact(s) in the charms files/ directory
(tarballs, executable, scripts, etc).

5) a subsequent deploy/upgrade then ships these out to the charm dir
on the unit, and the hooks unpack as appropriate for that project.


This works reasonably well. It has a few downsides:

a) conflates charm upgrade with code deployment. This required some
hacks with the charm revision (now fixed I think).

b) some build deps on the build machine need manual management.

c) the build step is repeated at each stage: dev, CI, staging,
production, which is wasteful and error prone.


One of the things we are looking at at the moment is to deploy the
build artifacts from an internal trusted url. For us, this would be an
openstack swift bucket. The ideal goal is that if the CI build/tests
succeed, it would deposit the build artifacts in a versioned swift
url. A charm's config can then be updated to the new url. This
potentially allows us to

a) deploy code separately to charm upgrades
b) reuse the same build artifact for CI/staging/dev,
c) roll back easily with a config change
d) manually do rolling upgrades via juju run if needed.

Michael Nelson's been working on this, I expect he'll have more to add.

So in essence we are thinking of trying to move away from "fat"
charms, and use build artifacts at trusted urls to get the payload on
the units, for the reasons above.

Some final thoughts:

We're still looking to simultaneously support the fat charm approach
of bundling payload with upgrade-charm as well, as it's really nice
for upgrading code and charm in a single juju "action", which the url
approach doesn't do.

Our build artifacts are usually tarballs for python projects, and
binaries for go projects, plus an assortment of scripts. I am planning
to look at PEX files for python, as well as maybe docker images, to
see if this can be simplified further and made more robust.

HTH

On 1 April 2014 20:07, Jorge O. Castro <jorge at ubuntu.com> wrote:
> Hi everyone,
>
> Matt Bruzek and I have been doing some charm testing on a machine that
> does not have general access to the internet. So charms that pull from
> PPAs, github, etc. do not work.
>
> We've been able to "fatten" the charms by doing things like creating a
> /files directory in the charm itself and putting the
> package/tarball/jar file in there, and given the networking issues
> that we might face in production environments that we should start
> thinking about best practices for having charms with payloads instead
> of pulling from a network source.
>
> Marco has some ideas on how we can generalize this and he will respond
> to this thread.
>
> --
> Jorge Castro
> Canonical Ltd.
> http://juju.ubuntu.com/ - Automate your Cloud Infrastructure
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju



-- 
Simon



More information about the Juju mailing list