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.
applications: - 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 OK null deployed to https://api.stacka.to
At this point, you can create SSH session into the container:
$ stackato ssh -a null null:~$
…and start exploring the container:
null:~$ pwd /home/stackato/app 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 v0.10.22 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.