kubernetes
elasticsearch
kafka
zookeeper
ceph
cassandra
percona-cluster
glance
mariadb
spark
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.
This is an example juju charm to deploy a user-defined rails app directly from revision control.
First, copy a config-samples/myapp.yaml over to something like ~/myapp.yaml to add info about your specific app.
config-samples/myapp.yaml
~/myapp.yaml
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
During the install hook,
install
app_repo
rvm
bundler
Gemfile
when related to a mysql service, the charm
mysql
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
config.yaml
myapp.yaml
$ 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.
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.
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.
apache-passenger
rails
website-relation-
passenger-relation-
unicorn-relation-
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.
rack-app
write charm /tests for this
/tests
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
config-changed
implement security-policy in config