openstackNeutron is the Network as a Service (NaaS) layer of OpenStack. Part of Neutron is the LBaaS (Load Balancer as a Server) plugin which offers an abstraction layer that handles communication with load balancers. It is possible to configure the LBaaS modular with different drivers of load balancers.

The LBaaS agent normally runs on the same host as the L3 agent (the network host). This host can be seen as the gateway to your Cloud. The network must ensure high availability for production systems because if the host breaks none of the running instances on the Cloud are reachable. This scenario is a level 1 incident and each administrator or system architect must try to eliminate such SPOF services to guarantee maximum accessibility for your Cloud. read more

Define your application deployments with deployment manifest files

The anynines PaaS allows you to define your application deployments using deployment manifest files. A deployment manifest is a yaml file describing all needed configuration options for your application’s runtime. The cf push command will automatically look for a file named manifest.yml in your current directory and use it for your deployment request. In case you need to manage different deployment configurations you can use the ‘-f’ parameter to specify the manifest for your current deployment like this:

$> cf push -f /path/to/your/manifest.yml

The following snippet shows an example of a basic deployment manifest:

Let’s have a closer look at the configuration read more

sidekiq

In a growing system, you will some times need to run extensive and complex tasks, which, because of their resulting accumulated load time, are not fit to process within a single request. This is where background jobs come in.

Background jobs allow you to trigger/enqueue a job, which then get processed in the background by so called workers.

Sounds neat, what do I need for that?

In this particular case, we use Sidekiq, a full-featured background processing framework for Ruby. Sidekiq enqueues its jobs into Redis, that’s why we need that, too.

Our ingredients thus far:
Ruby 2.x (or JRuby 1.7.x)
Sidekiq
Redis 2.4 or greater

Let’s start with the initializing

First, we create an initializer config/initializers/01_cloud_services.rb
This gives us the service credentials in the anynines environment. After that, we need to initialize Sidekiq. Therefor we create another initializer, config/initializers/02_sidekiq.rb

Now we can implement our workers and start enqueueing*, but how do we get this deployed to anynines?

How do I deploy this to anynines?

First of all, we need to create the Redis service. Therefor, we do following:

cf create-service redis 100 sidekiq-example-bj-queue

This creates our needed redis instance which we need to bind to our existing application.

cf bind-service my-sidekiq-example-app sidekiq-example-bj-queue

After that, we create a new application for the sidekiq workers in our manifest.yml

Deploy your application as usual and after that deploy your workers with the following command:

cf push my-sidekiq-example-workers

Now you’re ready to process some of that complex stuff in the background. Enjoy!

* For details about the usage of Sidekiq take a look at sidekiq.org.