exclusivetaya.blogg.se

1. #Rails unicorn https apache install#
2. #Rails unicorn https apache mod#
3. #Rails unicorn https apache full#
4. #Rails unicorn https apache software#

We now have the code cloned locally and ruby dependencies installed, next we’ll need a database.

#Rails unicorn https apache install#

The actual code here is straightforward, we fetch some things from the juju configuration and write them out to the nf file with a utility function, then use the bundle command from the ruby layer to install gem dependencies. To prevent the initial configuration from running multiple times, we guard the function with a state we set at the end, discourse.installed, which we can also use to trigger additional reactions as we flow through the installation process. Likewise, the ruby layer sets ruby.available when it’s ready, so we’re waiting on both those states. The git-deploy layer sets the codebase.avilable state when it has successfully cloned the configured git repo from the remote source. Hookenv.status_set('blocked', 'Discourse installed, waiting on database.') # Bundle command is from the ruby layer, it'll install our gem dependencies # There's no config default for this, so only write it if it's setĬonfig = nfig('admin-users') # Required to work with a stock install postfixĬonfig = "none"Ĭonfig = nfig('hostname') It happens that the Discourse code is distributed as a git tree and there’s a charm layer specifically for deploying from git repos, so the base of the install is quite install_discourse():Ĭonfig =

#Rails unicorn https apache full#

Note that some code is redacted for the sake of clarity, but the full charm is available at for anyone to view. Both the charm tool and charms.reactive are amply documented elsewhere, so let’s skip to the code. The charm tool helpfully provides a set of defaults for working with charms.reactive. I’ll be building the charm with charms.reactive, the most current framework for writing charms, which provides a set of pre-built layers and interfaces to make interfacing with other services and charms quick and easy. Luckily, writing charms with the reactive toolkit provides layers to abstract away much of the technology specific aspects of the process, allowing the charmer to focus on code directly related to the application they’re charming. This process has some interesting challenges as an exercise in charming, Discourse is a Ruby on Rails application which Canonical IS doesn’t have substantial institutional experience with and with which I personally have essentially no experience.

#Rails unicorn https apache software#

An initial, exploratory deployment was done to get a feel for the software and then the obvious next step for us towards production deployment was charming Discourse for easy, repeatable deployment in the future. Discourse is a modernization of classic forum/bulletin board software packages and is something IS has had an interest in for some time, so I was happy to help the Community team get this deployed. Should I use config.action_controller.asset_host or is there something wrong with my Apache config.Recently the Canonical IS department was asked to deploy the Discourse forum software for a revamp of the Ubuntu Community site at. I have precompiled assets too but it won't make any difference as no file is available from public directory unless Rails (Rack I guess) is doing the serving.

I have to enable serve_static_assets or I cannot download any static stuff. ProxyPassReverse / balancer://unicornservers/ # Redirect all non-static requests to rails

#Rails unicorn https apache mod#

I like using h264 streaming but since Rails is serving these video files, the Apache Mod won't work. My Apache settings are below and production.rb looks like this.

I have Rails 3.1, Unicorn and Apache setup.