Over a million developers have joined DZone.

Exploring the Stackato Base Image

DZone 's Guide to

Exploring the Stackato Base Image

· Cloud Zone ·
Free Resource

Stackato deploys apps into Docker containers that are all created from the same base image. Buildpacks applied during staging modify these containers to support whichever kind of application you're deploying. But what's in them? How basic is this base image?

The easiest way to find out is to explore one using stackato ssh to a shell inside an unmodified container. The easiest way to get an one of those is to deploy Stackato-Apps/null, an app which intentionally does nothing.

The simplest possible buildpack

If you're just trying to wrap your head around how buildpacks work, looking at some of the mega buildpacks like cloudfoundry/java-buildpack can be... daunting. The buildpack does so much, handling so many different runtimes and types of Java applications, that it's hard to figure out what it actually does to set up your particular Java application.

At the other extreme is ryandotsmith/null-buildpack. This buildpack does absolutely nothing, but it lets you quickly see the skeleton of the Heroku buildpack format.

What happens when the detect script is run?

#!/usr/bin/env bash
# bin/compile <build-dir> <cache-dir>
echo "-----> Nothing to do."


How about the compile script, which prepares the application prerequisites?

#!/usr/bin/env bash
# bin/compile <build-dir> <cache-dir>
echo "-----> Nothing to do."

Again, nothing!

How about the release script? Any default process type?

#!/usr/bin/env bash
echo "--- {}"

Nope! These scripts are there just for API compatibility, but they don't actually do anything to the container that will run the application.

So, what kind of application do you run with the null buildpack? Ryan Smith's original intention was that you can use it to run arbitrary binaries uploaded to Heroku. We could do the same with Stackato, provided we've built a binary compatible with the stackato/stack-alsek base container (Ubuntu 12.04 x86_64), but our "null" app does something even more minimal: it sleeps.

The null app

The only things the null app adds to the null buildpack is a Procfile and a minimal manifest.yml file.

Since the buildpack doesn't give us a default proccess to run, we need to specify one in a Procfile:

web: sleep 10000d

Stackato expects to launch a long-running process that it can monitor, like a web server. We're basically telling the system to watch paint dry instead.

The app uses Atlassian's fork of the buildpack, but it's basically the same.

- buildpack: https://github.com/atlassian/buildpack-null.git
name: null
path: .
urls: []

The manifest.yml has to explicitly set the buildpack key because it's not installed in Stackato by default. Even if it were, there's nothing in the buildpack's detect script to trigger it.

The urls: [] line stops Stackato from automatically allocating a URL for the app, which it would do for a typical web app. With this key set empty, Stackato disables the checks it would normally run to test that a web process is active.

What can you do with it?

To deploy the null app to your favorite Stackato endpoint, first clone the repo:

$ git clone https://github.com/Stackato-Apps/null.git

Change to the base directory of the repo and run stackato push -n. If all goes well (and there's not much that can go wrong with this one) you'll have a basic application container you can work with.

Using manifest file "manifest.yml"
BuildPack:         https://github.com/atlassian/buildpack-null.git
No Application Urls
Creating Application [null] as [https://api.stacka.to -> ActiveTest -> dev -> null] ... OK
Uploading Application [null] ... 
  Checking for bad links ... 4 OK
  Copying to temp space ... 3 OK
  Checking for available resources ... 557 < 64K, skip OK
  Processing resources ... OK
  Packing application ... OK
  Uploading (1K) ... 100% OK
Push Status: OK
Starting Application [null] ... 
stackato[dea_ng]: Staging application
stackato[fence]: Created Docker container
stackato[fence]: Prepared Docker container
staging: -----> Downloaded app package (4.0K)
staging: Cloning into '/tmp/buildpacks/buildpack-null'...
staging: -----> Nothing to do.
staging: -----> Uploading droplet (4.0K)
stackato[dea_ng]: Uploading droplet
stackato[dea_ng]: Completed uploading droplet
stackato[fence.0]: Created Docker container
stackato[fence]: Destroyed Docker container
stackato[fence.0]: Prepared Docker container
stackato[dea_ng.0]: Launching web process: sleep 10000d
stackato[dea_ng.0]: Instance is ready
null deployed to https://api.stacka.to

At this point, you can create SSH session into the container:

$ stackato ssh -a null

...and start exploring the container:

null:~$ pwd
null:~$ ls
manifest.yml  Procfile  README.md

We can check which version of Ubuntu we're running:

null:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 12.04.5 LTS
Release:    12.04
Codename:   precise

...see which kernel is running:

null:~$ uname -a
Linux f809c8ab7591 3.11.0-20-generic #35~precise1-Ubuntu SMP Fri May 2 21:32:55 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

...search to see if certain libraries are installed:

null:~$ dpkg -l |grep png
ii  libpng12-0                        1.2.46-3ubuntu4                       PNG library - runtime
ii  libpng12-dev                      1.2.46-3ubuntu4                       PNG library - development

...check the versions of language interpreters pre-installed in the base container:

null:~$ ruby --version
ruby 1.9.3p484 (2013-11-22 revision 43786) [x86_64-linux]
null:~$ python --version
Python 2.7.8
null:~$ node --version
null:~$ perl --version
This is perl 5, version 16, subversion 3 (v5.16.3)

You can run any command you would otherwise run on a Linux host, and find out what you might need to add in order to get your own application to run.

A starting point for your own buildpack

Feel free to fork the buildpack on Github and start adding things. Starting with a simple buildpack that works (even if it's not really doing anything) gives you the opportunity get your feet wet with buildpacks and learn how to construct the detect, compile, and release scripts.

The cloudfoundry-incubator/staticfile-buildpack is another buildpack worth looking at. It does a fair bit more than the null buildpack, but it uses bash to set up Nginx in a way that's fairly comprehensible to anyone with a bit of Linux experience.

It's good to know that you don't have to cover every possible use case when you're just trying to deploy your own application.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}