1

I am exploring the possibility to deploy our applications infrastructure using Juju.

My application are built using the Play Framework and run on the Java Virtual Machine. I envision the following setup:

  • Proxy server for SSL offloading (maybe redundant if that is not too hard)
  • Primary node running application and JVM
  • Secondary node (hot spare) running application and JVM

The proxy server should only use the secondary node if the primary node is down. There should be only a single application node receiving requests. Scaling horizontally is something we do not need and it complicates business logic.

The above setup seems fairly doable. It becomes (in my mind) more complicated when I think about the continuous deployment part.

My applications are built with a private Jenkins machine and result in a zip file containing the application (as a runnable bash script) with all of it's dependencies.

The following steps should be taken to deploy it:

  • Send the zip to a server
  • Deploy a new proxy, primary and secondary node with the application
  • Switch to the new proxy

I want to create a charm for this, but I am not sure how to proceed.

Is it possible to deploy a charm bundle from within a charm? If so, how?

Note that any advice is welcome. I do not need concrete implementations, just pointers and general directions.

hatch
  • 2,323
EECOLOR
  • 111

1 Answers1

2

Sending a 'built' application to your environment is actually a fairly common technique especially for those using tools like docker.

Typically you'll want to create a charm for each component in your environment. In this case it looks like you would have 'proxy' and 'application'.

So you would create a proxy charm which has, in addition to the install and start hooks, a relation-joined and relation-broken hook scripts. These scripts will modify the proxy settings when a relation is joined to add the new application location and subsequently remove an application location on broken. This will allow you to keep the proxy up and running and swap out application servers at will.

The application service will have similar hook scripts to send its location to the proxy service. It will also need a charm configuration option for the location of the application zip file to which it needs to deploy. When the applications install hook is run it will then pull down the zip file at the location supplied extract and then run it in the start hook.

The continuous deployment is where Juju really shines. First you're going to need a bootstrapped environment juju bootstrap <your-env-name> and juju switch <your-env-name>.

Your Jenkins instance will build your proxy zip and application zip file and then upload them to a place where your servers can access. If you're on EC2 this would likely be on S3. It would then take note of the location paths and build number, and service names of the currently running proxy and application services.

It will then run:

juju deploy your-proxy your-proxy-<build-number>
juju deploy your-application your-application-<build-number>
juju add-unit your-application-<build-number> -n 2

At this point you'd likely want something on an interval checking periodically to see when your proxy and application services are up and running. At which point you will want to connect the new application service to the proxy, switch traffic to your new proxy and tear down the old services.

juju add-relation your-proxy-<build-number> your-application-<build-number>
# add code here to switch to new proxy
juju destroy your-proxy-<old-build-number>
juju destroy your-application-<old-build-number>

This assumes that you will be rebuilding your proxy every time your application changes. If not then simply remove the proxy steps from the above commands. This also assumes that the applications take time to start and you wouldn't want to incur that downtime so a simple upgrade-charm hook wouldn't work.

hatch
  • 2,323