Изучение базового изображения Stackato

Stackato разворачивает приложения в Docker-контейнеры, которые все созданы из одного базового образа. Пакеты сборки, применяемые во время подготовки, изменяют эти контейнеры для поддержки приложений, которые вы развертываете. Но что в них? Насколько это базовое изображение?

Самый простой способ выяснить это — изучить использование stackato sshоболочки в неизмененном контейнере. Самый простой способ получить один из них — развернуть Stackato-Apps / null , приложение, которое намеренно ничего не делает.

Самый простой из возможных сборок

Если вы просто пытаетесь разобраться в том, как работают buildpack-пакеты, посмотреть на некоторые мега-buildpack-пакеты, такие как cloudfoundry / java-buildpack, может быть … сложно. Buildpack делает так много, обрабатывая так много разных сред выполнения и типов Java-приложений, что трудно понять, что он на самом деле делает для настройки вашего конкретного Java-приложения.

Другой крайностью является ryandotsmith / null-buildpack . Этот сборочный пакет абсолютно ничего не делает, но он позволяет быстро увидеть скелет формата сборочного пакета Heroku.

Что происходит при detectзапуске скрипта?

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

Ничего такого!

Как насчет compileсценария, который готовит предварительные условия приложения?

#!/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.