Charles Butler
on 16 April 2015
Charmbox – a chapter from my workflow
A couple weeks ago we announced the GA of our experimental Docker images for testing the latest TRUNK and to isolate your charm development experience. The docker images are much lighter weight than the vagrant counterpart (even though most systems that are not linux leverage a middleware solution of virtualization in some fashion – boot2docker is actually spinning up docker containers in a VM – nifty right?)
Leveraging charmbox has helped alleviate me from tainting my system with all the testing dependencies introduced by the review queue. Each charm can run the 00-setup
script as root and install whatever unholiness is required to really leverage the charm. Most often this is as simple as just the amulet packages but some charms go even further and install full API SDK’s so they can really root around in the deployed service and validate we have a good configuration.
While this is excellent in theory – in practice – I wound up with > 8 GB of extra cruft installed, that I won’t be using in my own every-day charm development.
Workflow enhancement
Since we have this nifty isolation story – lets look at how we can somewhat supercharge the workflow, and what this looks like. I’ll only make 3 assumptions here.
- you’re using bash
- you have docker installed
- you want to manage charm context (Review, Work, Personal)
I have 3 particular contexts in which I will be focused on charms.
- My personal network of services (in home services)
- My obligations to canonical to develop interesting new workload charms
- My obligations as a charmer to review incoming charms
With these clearly defined “scopes” of charms, I find it often handy to keep a repository of charms isolated in each context, and to work out of that particular repository until I have reached the end of my objective, and then I can switch contexts.
Show me the code
# This goes in .bashrc
# Load my custom exports
# Load my custom exports
if [ -f $HOME/.bash_exports ]; then
. $HOME/.bash_exports
fi
if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi
# Check for which juju environment is loaded and execute based on contents
if [ -f $HOME/.juju_repository_env ]; then
JEN=`cat $HOME/.juju_repository_env`
if [ $JEN = 'work' ]; then
jwork
fi
if [ $JEN = 'personal' ]; then
jhome
fi
if [ $JEN = 'review' ]; then
jreview
fi
fi
# This goes in .bash_aliases
# Move between work and personal juju context
# Depends on some special vars I have in bash_exports,
# and thats not tracked in my dotfiles repo
jujuwork()
{
export JUJU_REPOSITORY=$JUJU_WORK_REPO;
echo "work" > $HOME/.juju_repository_env;
}
jujupersonal()
{
export JUJU_REPOSITORY=$JUJU_PERSONAL_REPO;
echo "personal" > $HOME/.juju_repository_env;
}
jujureview()
{
export JUJU_REPOSITORY=$JUJU_REVIEW_REPO;
echo "review" > $HOME/.juju_repository_env;
}
alias jwork=jujuwork
alias jhome=jujupersonal
alias jreview=jujureview
# This goes in .bash_exports, but can live in .bash_aliases or .bashrc
JUJU_WORK_REPO="$HOME/projects/work/charms"
JUJU_PERSONAL_REPO="$HOME/projects/charms"
JUJU_REVIEW_REPO="$HOME/tmp/charms"
How this works
The repositories setup in $HOME/.bash_exports
manage the pointers to my charm repository directories, and resemble any other charm repo, separated out by series/service
The methods declared allow me to run a single command to switch the context of my exported $JUJU_REPOSITORY
– and set a sentinel file that is read on each new shell execution.
The bits in $HOME/.bashrc
are run on each new shell, and correctly set the context of my $JUJU_REPOSITORY
without any manual intervention. What I set as my last context, will be the context of my next shell.
Thats great, but what does this have to do with Docker?
Really glad you asked! I spoke to the isolation, and contexts earlier – now lets see how we can bridge the gap here to make this as seamless as possible.
alias charmbox='docker run --rm -v $HOME/.juju:/home/ubuntu/.juju -v
$JUJU_REPOSITORY/trusty:/home/ubuntu/trusty -v $JUJU_REPOSITORY/precise:/home/ubuntu/precise -ti johnsca/charmbox'
The following alias when added to ~/.bash_aliases
will give you the charmbox
command. Which will spin up the appropriate docker container, and mount your charm archives in the charmbox environment. Whats nice is you didn’t have to do any further fuddling with commands, and you automatically get the context you’re in mounted into the charmbox. With the –rm passed to docker, anything we have done in the image is immediately removed once we exit the context of the docker container, so we get fresh results, every time.
Deploy happy 🙂