rails #4

Supports: precise

Add to new model

Description

Rails is a full-stack, open-source web framework in Ruby for writing
real-world applications.

Being a full-stack framework means that all layers are built to work
seamlessly together. That way you don't repeat yourself and you can
use a single language from top to bottom. Everything from templates to
control flow to business logic is written in Ruby.


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

app_name
(string) Application Name
myapp
extra_packages
(string) extra packages to install before bundle install
install_root
(string) Install the application in app_name under this directory
/opt
repo_branch
(string) Application branch name (git only, for bzr the branch is in the url)
master
repo_type
(string) Repository type {git|bzr} for now
git
repo_url
(string) Application repository URL
https://github.com/mmm/testrails.git