Description

Rack provides a minimal, modular and adaptable interface
for developing web applications in Ruby.
By wrapping HTTP requests and responses in the simplest way possible,
it unifies and distills the API for web servers, web frameworks, and
software in between (the so-called middleware) into a single method call.

Tags:
app-servers ›

juju charm to deploy a user-defined rails app

This is an example
juju
charm to deploy a user-defined rails app
directly from revision control.

Using this charm

First, copy a config-samples/myapp.yaml over to something like ~/myapp.yaml to add info about your specific app.

Then deploy a stack

$ juju deploy mysql
$ juju deploy --config ~/myapp.yaml rails myapp
$ juju deploy haproxy

relate them

$ juju add-relation mysql myapp
$ juju add-relation myapp haproxy

scale up your app if you'd like

$ juju add-unit -n3 myapp

open it up to the outside world

$ juju expose haproxy

Find the haproxy instance's public URL from

$ juju status

What the charm does

During the install hook,

installs ruby et al
clones your rails app from the repo specified in app_repo
runs rvm and bundler to install rails and friends according to your Gemfile
writes out passenger config
sits back and waits to be joined to a database

when related to a mysql service, the charm

configures db access
starts passenger

charm configuration

Configurable aspects of the charm are listed in config.yaml
and can be set by either editing the default values directly
in the yaml file or passing a myapp.yaml configuration
file during deployment

$ juju deploy --config ~/myapp.yaml rails myapp

Please note that all configuration is meant to be immutable config specified at deploy-time. There's no configuration that makes sense to configure once the service is up and running. This will perhaps change in the future.

Charm security

Note that currently all gems in your app's Gemfile are installed regardless of signatures. The fix is to specify the security policy for your app in the charm configuration.
Once implemented, this should look something like

security-policy: { NoSecurity, LowSecurity, MediumSecurity, HighSecurity }

in your myapp.yaml config file.

TODO

split this into apache-passenger primary and a rails subordinate charms. The rails part should swap out website-relation- hooks and instead write a handful of passenger-relation- and unicorn-relation- hooks... so it can run against various different frontends.
this could probably easily generalize into a rack-app charm that'd run rails, sinatra, etc... anything with a Gemfile that hooks up to a rack-aware primary service.
write charm /tests for this
also add default Gemfile so a deployment with no config can be used as a rails development environment
move more logic from install and into config-changed to accommodate config changes on the fly
implement security-policy in config

Configuration

repo: (string) Application repository URL; https://github.com/chuckbutler/juju-is-dashing.git
rack_env: (string) Both RACK_ENV and RAILS_ENV environment variables.; production
extra_packages: (string) Extra packages to install before bundle install
env: (string) List of environment variables (e.g. SECRET_TOKEN=secret_token). These variables will override those which were set by Rack charm (like DATABASE_URL, REDIS_URL)
svn_password: (string) The user name for a user that has access to the Subversion repository (svn only).
scm_provider: (string) The name of the source control management provider to be used (git or svn).; git
deploy_key: (string) A deploy key is an SSH key that is stored on the server and grants access to a repository (git only).
svn_username: (string) The password for the user that has access to the Subversion repository (svn only).
revision: (string) The revision to be checked out. This can be symbolic, like HEAD or it can be a source control management-specific revision identifier.; HEAD