New OpenShift Cartridge Format – Part 2 - Archived

This is part two of a multi-part blog series to explain the new cartridge format. See Part One of the New Cartridge Series for more background. This post is quite a bit longer than the last post, so give yourself thirty minutes to an hour to complete it. We’re introducing a lot of new concepts and hopefully everything will make sense by the end.


This post builds off of work done in Part One so please make sure to complete the tasks in that post first to make the most of this one. Let’s do a quick double check. The following files should be found in the httpd-example: directory:


The following command should also start Apache httpd:

httpd -f ~/httpd-example/etc/httpd.conf

In addition, confirm that the webserver can properly listen on and respond to requests at: Next let’s take a look at the template cartridge we’ll be working from. It’s called a ”mock cartridge” and it’s actually used for automated testing by the OpenShift engineers when they are building a new release. It’s also useful as a base for building new cartridges:

So go ahead and clone or download the repo zip from github: Then look for the cartridges/openshift-origin-cartridge-mock directory. Here’s a high level overview of its layout:

 # The cartridge “root” directory will get installed into the gear at ~/$CARTRIDGE_NAME/
# ./conf.d is not really needed; we'll be removing it.
# mock.conf is also not used and we'll be removing it.
 # The usr directory gets symlinked in instead of copied; we will talk about it later
# This hook directory is a list of scripts that allow the cartridges to connect to each other
# Where environment variables get set
# This “template” directory is what will be placed in the application's git repo on creation.
# Cartridge metadata, the most important of which is the manifest.yml
# managed_files.yaml for .erb processing
# This is a spec file we use for packaging, not strictly required for cartridge creation.
# This conf directory is also not strictly needed and we'll be removing it
# bin directory contains our basic scripts for the cartridge.
# control is your start/stop script so “./control start” should start the application.
# teardown is not required for most basic uses
# setup is run as part of application creation as well as updates.

Cartridge Workflow

The mock cartridge actually “works” as-is, so it’s important to know what happens when a new application is created. Below is a walk-through of roughly what would happen if a user created an application with mock via “rhc app create -a mymock -t mock-0.1”

  1. The client tools contact the broker via a REST API. The broker then finds a node to put it on. An empty gear is then created on that node.
  2. Once the gear is created, our cartridge gets copied into that gear. In the case of our mock cartridge – /var/lib/openshift/$OPENSHIFT_GEAR_UUID/mock/
  3. After the cartridge is copied, every file listed in ./metadata/locked_files.txt is created and set as owned by the user.
  4. The setup script is run.
  5. All of the files listed in ./metadata/locked_files.txt are chowned as root so the user can no longer modify them
  6. Connection hooks are run
  7. The cartridge is started via control start

The two most important steps there, especially for this example, are step 3 (the copy of the directories) and step 4 (where setup is run). The exception to copying of directories is the ./usr/ directory. This directory will typically get symlinked in. Why? Mostly to help save disk space and memory. ./usr/ should have all of your services binaries, blobs, images or other fairly large static data, the user will not have write access to this directory. Keep in mind, anything copied into the user’s gear counts against their disk quota.

Note that in our example we’re not using any binaries or blobs; we are just using the httpd that is provided by RHEL6. It’s nice to be able to rely on those binaries already being there, but if they weren’t, you could always provide your own httpd and put it in the usr directory.

First steps

So now we have a good idea of the layout of our httpd application and cartridge and how the cartridge is installed. Let’s start by removing all the bits in the mock cartridge we don’t need.

cd ~/httpd-example-cartridge
# note: The rest of these commands are run from inside the httpd-example-cartridge directory unless otherwise specified.
rm -rf ./conf ./conf.d
rm ./openshift-origin-cartridge-mock.spec ./hooks/set-db-connection-info ./env/OPENSHIFT_MOCK_SERVICE_URL.erb ./mock.conf
# Lets zero out the action hooks
cd template/.openshift/action_hooks/
echo > build
echo > deploy
echo > post-deploy
echo > pre-build

Everything else seems fairly useful or at least not harmful to have in place. So next step, copy our original files into this repo.

cp -adv ~/httpd-example/* ./

The first somewhat non-obvious change we need to make is to our template directory. This directory contains the default git environment at app creation. In our case we want our default index.html “hello world” file to be the default home page. So let’s move it and clean up.

mv html/index.html template/
rmdir html

We also need to make changes to our etc/httpd.conf file. Recall from part 1 we have some hard-coded paths in the config file, specifically ServerRoot. Here’s the example provided:

ServerRoot "/home/mmcgrath/httpd-example/"

Lucky for us, OpenShift has a full template system that can easily substitute the proper value in instances like this. To enable it we need to rename the file to a .erb:

mv etc/httpd.conf etc/httpd.conf.erb

Note: the “httpd.conf.erb” is important because after the template has been processed, the “.erb” suffix will be removed leaving only “httpd.conf” Next we need to inject the cartridge home directory into our ServerRoot string. So replace the ServerRoot example above with:

ServerRoot “<%= ENV['OPENSHIFT_HTTPD_DIR'] %>”

There are several environment variables provided; the full list can be found here: but look closely because you’ll see “OPENSHIFT_HTTPD_DIR” isn’t one of the variables explicitly listed, but it is provided. Later in the blog post we define how this cartridge is internally referred to in the manifest.yml, with “Cartridge-Short-Name: HTTPD”. Once defined, OPENSHIFT_HTTPD_DIR will be set to something similar to “/var/lib/openshift/511e1b1e500d451fb70003e8/httpd/”

In part 1 of the series we set some other paths to be relative to this ServerRoot. We can keep all of those paths the same except for one. In earlier steps index.html was moved to a different directory. Apache httpd needs to be made aware of these changes. Look for:

DocumentRoot "html"

and change it to

DocumentRoot "<%= ENV['OPENSHIFT_REPO_DIR'] %>"

Using the same gear ID as above this directory would resolve to:

DocumentRoot "/var/lib/openshift/511e1b1e500d451fb70003e8/app-root/runtime/repo"

This is where the exploded git repository ends up when a user issues a git push. It’s also, therefore, where the template/ directory in our cartridge ends up. At least until the user makes a change to it.

There was also the matter of our IP address and port. We had initially picked which is a loopback address. OpenShift uses loopback addresses for intranode communication. When a cartridge is installed on a gear, it must use one of the IP addresses allocated to that gear. An IP address will be assigned to each cartridge (if it is needed) via the manifest.yml file (more details below). That IP will be available in an environment variable and it’s one we can reference in the template just as we did above with OPENSHIFT_REPO_DIR. So let’s do that. Find:


and replace it with


The last bit before we move on is simply cleanup from our earlier tests. When the log dir was copied over it had logs in it. Let’s clean that out.

rm -f logs/*
echo "Logs are stored here" >> logs/README

Cartridge Metadata

The cartridge metadata is how the cartridge describes itself to the rest of the system. It also has some handy files for controlling how the cartridge behaves. lock_files.txt was described earlier but let’s look a bit closer. All of the files in locked_files.txt get created as part of the installation setup. Once setup is done, all of the files listed get owned as root. Any file created by the cartridge not listed in locked_files.txt remain owned by the user.

For example, we have a logs/ dir that we want the user to be able to write to. Httpd will run as the ‘gear’ user and it’s certainly going to generate logs. The env/ dir, on the other hand, has information in it that we want to remain static. Thus, after the cartridge is done installing, it gets chowned as root and prevents further alterations.

The snapshot* files in metadata/ allow the cartridge writer to decide to ignore certain directories during the snapshot phase. This can be useful when creating a database cartridge. Perhaps you’d prefer the db dump be snapshotted instead of the raw db files. Remember a snapshot is more like a backup and will download files onto the users workstation (it’s usually called from the command line tools)

The last and most complex part of the cartridge metadata is the manifest.yml. This file contains all the naming, version and connection hook information about the cartridge. You can dig deeper into the cartridge creation documentation for more information, but for now let’s just edit the metadata/manifest.yml file and make it look like this:

Name: httpd
Cartridge-Short-Name: HTTPD
Display-Name: HTTPD Cartridge
Description: "A httpd cartridge for development use only."
Version: '0.1'
License: "None"
Vendor: Custom Cartridges Inc
Cartridge-Version: 0.0.1
Cartridge-Vendor: customcarts
  - service
  - web_framework
  - httpd
    Type: environment
    Description: "An example environment variable using ERB processing"
  - components:
    - httpd
    Type: "NET_TCP:db:connection-info"
    Required: false
  - Private-IP-Name:   IP
    Private-Port-Name: PORT
    Private-Port:      8080
    Public-Port-Name:  PROXY_PORT
      - Frontend:      ""
        Backend:       ""
        Options:       { websocket: false }


The managed_files.yml file contains a list of files that OpenShift should manage. Previously some may have known this as locked_files.txt but that has been deprecated for managed_files.yml which has additional features built in to it. Locked files dictates what files get owned as root and therefore can not be altered by the user. processed_templates should be a list of erb files to process as part of installing the system. Recall we made httpd.conf.erb in part-2 of this series.

- env/
- env/*
- '**/*.erb'

Creating your control script

The control script (found in bin/control) will look familiar to anyone who has written an init script before. It takes some of the expected arguments as well like start, stop, restart, status and reload. In OpenShift we have implemented a few other functions which I’ll go over now:

  • tidy: tidy should be implemented to cause your script to make efforts to clean up disk space. It could, for example, remove temp files, or rotate and compress old logs. There are gear-level tidy commands as well; for example, a git garbage collection (git gc) is done.
  • pre-build: When a user does a build, usually as part of a git push, pre-build gets run before the build
  • build: When a user does a build, the build script is called. This should attempt to auto-resolve deps, update cache, build the user’s code, possibly even run tests, etc.
  • deploy: This is part of the deploy phase and should be run whenever the application is deployed (which would typically happen after it is built)
  • post-deploy: This script would typically be called after the application is deployed but before it is started.

For the purposes of this post, let’s implement start, stop and restart. Pick your favorite editor and open the bin/control file. First, let’s pick the start section. As you’ll recall previously we started httpd with this command:

httpd -f ~/httpd-example/etc/httpd.conf

Perhaps a more correct command would have been:

/usr/sbin/httpd -f ~/httpd-example/etc/httpd.conf -k start

So let’s put those into our functions. We want to replace the sections that look like:

function start {
  touch $MOCK_STATE/control_start
  touch $MOCK_STATE/mock_process

and change them to look like (remembering that /usr/sbin is not in the default PATH in OpenShift):

function start {
    /usr/sbin/httpd -f $OPENSHIFT_HTTPD_DIR/etc/httpd.conf -k start

Do the same for stop and restart. $OPENSHIFT_HTTPD_DIR is the same environment variable we used earlier to reference where the cartridge was installed (so ~/httpd/etc/httpd.conf would be used). While we’re in there, let’s also replace other MOCK specifics with something more generic. Something like this:

#!/bin/bash -e



function start {
    httpd -f $OPENSHIFT_HTTPD_DIR/etc/httpd.conf -k start

function stop {
    httpd -f $OPENSHIFT_HTTPD_DIR/etc/httpd.conf -k stop

function restart {
    httpd -f $OPENSHIFT_HTTPD_DIR/etc/httpd.conf -k restart

function catchall {
    echo "not yet implemented"

case "$1" in
  start)       start ;;
  stop)        stop ;;
  restart)     restart ;;
  status)      status ;;
  reload)      catchall ;;
  tidy)        catchall ;;
  pre-build)   catchall ;;
  build)       catchall ;;
  deploy)      catchall ;;
  post-deploy) catchall ;;
  *)           exit 0

exit 0

I would also recommend making the control script non-executable until we’re confident it works. So a simple:

chmod -x bin/control

Will do the trick. The reason for this is that when a cartridge is installed, the default action is to start it. If the resulting control start fails, OpenShift will assume the cartridge installation process has failed. By leaving it non-executable we can ssh into the gear and run bin/control start manually and easily troubleshoot / catch any errors without having to check logs.

Next let’s look at the setup script.

Creating setup

The setup script is called as part of installing the cartridge into the gear. It is run as the gear user and can help you further customize the cartridge. For example, let’s say we want to pre-create a database or download a bunch of libraries. The setup script can help with this. In other cartridges we also use it to allow a single cartridge to support multiple versions. Take a look at the ruby cartridge for example:

In our case though, once the httpd cartridges are put in place there’s very little we need to customize. In fact there’s nothing we need to customize. So let’s blank out the file and move on:

echo > bin/setup

I’ll cover more advanced setup use cases in a future blog post. It’s important to note that when doing a cartridge upgrade, setup may be called. We’re building out a more advanced systems so cartridge writers can specify ‘patch’ level updates. But it’s important to remember that an update could very well be a “copy the cartridge in place of what’s there, and re-run setup”. So setup needs to be aware that it will be called multiple times, so make it re-entrant or idempotent.


Unfortunately as of the writing of this blog there’s no way for you to test your cartridge on OpenShift Online directly. I promise it’s coming. For now though, to test your cartridge you’ll need to use OpenShift Origin (our free community edition) or OpenShift Enterprise (our paid enterprise edition). Unfortunately the current version of Enterprise does not use the new cartridge format but a soon to be released version will. For this demo I’ll assume you have Origin already up and running. If not check out the Origin docs at

Comments are closed.