Repeatable spell deployments with conjure-up

In our upcoming 2.2 release conjure-up will now automatically write out a custom bundle that incorporates your deployment and any configuration changes that were made in order to ease the burden of customized repeatable deployments.

Deployment and Customization

First, as of this writing, you'll need to install conjure-up from our beta channel in order to pickup this new feature:

sudo snap install conjure-up --classic --beta  

For this example, we'll walk through a simple Kubernetes deployment and making a small application configuration change.

Application List

Next, you'll select the cloud you wish to deploy to and if necessary the bootstrap process will begin. Once that is complete the Application List screen will appear and this is where we'll make a the adjustment.

Navigate your keyboard arrow keys over to the kubernetes-master [Configure] button and press enter. You will then be presented with the ability to change a few configuration options. For this exercise we are going to install the Docker bits from upstream and not from the Ubuntu archive.

Once that's done, tab over to APPLY CHANGES button and proceed.

Now at this point the bundle has been written and we can finish up the installation by answering the questions at the Additional Application Tasks. I'm not going to go into that section but jump to the end where the summary screen has been displayed to you and you've exited out of conjure-up.

Creating the repeatable spell deployment

This next part requires copying both the kubernetes-core spell and the bundle that was written to your own custom spell directory. To do that we'll need to look in our cache directory located at ~/.cache/conjure-up. Running a tree on that directory shows us the following:

$ tree ~/.cache/conjure-up
.cache/conjure-up
├── conjure-up.log
├── kubernetes-core
│   ├── metadata.yaml
│   ├── readme.md
│   ├── steps
│   │   ├── 00_deploy-done
│   │   ├── 00_pre-deploy
│   │   ├── lxd-profile.yaml
│   │   ├── step-01_get-kubectl
│   │   ├── step-01_get-kubectl.yaml
│   │   ├── step-02_cluster-info
│   │   └── step-02_cluster-info.yaml
│   └── tests
│       ├── deploy
│       └── verify
└── kubernetes-core-deployed-2017-04-07-20:26:25.yaml

What you see here is the kubernetes-core spell that we just deployed via conjure-up along with a file named kubernetes-core-deployed-2017-04-07-20:26:25.yaml which is the bundle that was written out during our customization section.

Viewing this particular bundle file we can see that our customization's were applied in addition to the rest of the required bundle needed for conjure-up to deploy.

machines:  
  '0':
    series: xenial
  '1':
    series: xenial
  '2':
    series: xenial
  '3':
    series: xenial
relations:  
- - kubernetes-master:certificates
  - easyrsa:client
- - kubernetes-worker:certificates
  - easyrsa:client
- - etcd:certificates
  - easyrsa:client
- - kubernetes-master:etcd
  - etcd:db
- - kubernetes-master:kube-api-endpoint
  - kubernetes-worker:kube-api-endpoint
- - kubernetes-master:cluster-dns
  - kubernetes-worker:kube-dns
series: xenial  
services:  
  easyrsa:
    charm: cs:~containers/easyrsa-7
    num_units: 1
    to:
    - '0'
  etcd:
    charm: cs:~containers/etcd-24
    num_units: 1
    to:
    - '1'
  kubernetes-master:
    charm: cs:~containers/kubernetes-master-12
    num_units: 1
    options:
      install_from_upstream: true  # <- Look here I'm new!
    to:
    - '2'
  kubernetes-worker:
    charm: cs:~containers/kubernetes-worker-14
    num_units: 1
    to:
    - '3'

What happens here is conjure-up first downloads the bundle from the CharmStore and is then reconstructed with our custom configuration changes and spits out a new compatible bundle that can be used within a conjure-up spell.

In order to get your new spell in working order there are just a couple of steps to perform:

Copy the cached spell to somewhere of your choosing, we'll stick with $HOME/kubernetes-core

cp -a ~/.cache/conjure-up/kubernetes-core ~/kubernetes-core  

Next, copy the newly created bundle and place it within the recently copied spell directory while also making sure to change the filename to bundle.yaml.

cp ~/.cache/conjure-up/kubernetes-core-deployed-2017-04-07-20\:26\:25.yaml ~/kubernetes-core/bundle.yaml  

And that's it!

You can test that your deployment reflects the changes you made by simply re-running conjure-up against that spell directory:

$ conjure-up ~/kubernetes-core

This should prove very useful for teams who wish to document and version control spells for use in automated deployments or perhaps a teaching tool that is customized for your lab environment. Couple this feature with the ability to further customize headless deployments and you've just become the coolest kid at the party.

Further information

Website, GitHub, AskUbuntu, Chat