Querying Tiller configuration from a running Docker container

Note : This page may contain outdated information and/or broken links; some of the formatting may be mangled due to the many different code-bases this site has been through in over 20 years; my opinions may have changed etc. etc.

Tiller 0.2.2 now brings a simple HTTP API that allows you to query the state of the Tiller configuration inside running Docker containers. This may be particularly useful when you’re attempting to debug configuration issues; you can quickly and easily check the templates, global values and Tiller configuration.

You can enable this API by passing the --api (and optional --api-port) command-line arguments. Alternatively, you can also set these in common.yaml :

api_enable: true
api_port: 6275

Now, once Tiller has forked a child process (specified by the exec parameter), you will see a message on stdout informing you the API is starting :

Tiller API starting on port 6275

If you want to expose this port from inside a Docker container, you will need to add this port to your list of mappings (e.g. docker run ... -p 6275:6275 ...). As a demonstration, here’s a walk-through using the Docker container built from my Tiller and Environment Variables blog post. Assuming that you’ve run through that tutorial and built the Docker container, just make a small addition to your common.yaml, so it now looks like:

# data/tiller/common.yaml
exec: /usr/sbin/nginx
data_sources:
  - file
  - environment
template_sources:
  - file
api_enable: true
api_port: 6275

And rebuild your container:

$ docker build --no-cache -t tiller-docker-example .

Now, run it again using the previous article’s example, but also map port 6275:

$ docker run -e environment=production -e name=Mark \
 -t -i -p 80:80 -p 6275:6275 tiller-docker-example
 
tiller v0.2.2 (https://github.com/markround/tiller) <[email protected]>
Using configuration from /etc/tiller
Using plugins from /usr/local/lib/tiller
Using environment production
Template sources loaded [FileTemplateSource]
Data sources loaded [FileDataSource, EnvironmentDataSource]
Templates to build ["welcome.erb"]
Building template welcome.erb
Setting ownership/permissions on /usr/share/nginx/html/welcome.html
Template generation completed
Executing /usr/sbin/nginx...
Child process forked.
Tiller API starting on port 6275

And you should now be able to ping the API (replace $DOCKER_HOST_IP with the IP address or hostname of your Docker host here (e.g. localhost)):

$ curl -D - http://$DOCKER_HOST_IP:6275/ping

HTTP/1.1 200 OK
Content-Type: application/json
Server: Tiller 0.2.2 / API v1

{ "ping": "Tiller API v1 OK" }

You can check out the Tiller config:

$ curl http://$DOCKER_HOST_IP:6275/v1/config

And the result (in formatted JSON):

{
    "tiller_base": "/etc/tiller",
    "tiller_lib": "/usr/local/lib",
    "environment": "production",
    "no_exec": false,
    "verbose": true,
    "api_enable": true,
    "exec": "/usr/sbin/nginx",
    "data_sources": [
        "file",
        "environment"
    ],
    "template_sources": [
        "file"
    ],
    "api_port": 6275
}

Or a particular template :

curl http://$DOCKER_HOST:6275/v1/template/welcome.erb

This returns the following JSON:

{
    "merged_values": {
        "environment": "production",
        "env_home": "/",
        "env_path": "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
        "env_hostname": "0aaed58b34db",
        "env_term": "xterm",
        "env_environment": "production",
        "env_name": "Mark",
        "env_color": "Blue"
    },
    "target_values": {
        "target": "/usr/share/nginx/html/welcome.html"
    }
}

For other API endpoints, see the Documentation. And please bear in mind that this is intended as a development / debugging tool - there are serious security implications involved in exposing this port (and your configuration details)to an untrusted network!

Note : Tiller v0.7.0 and later support a new configuration system, where you can place most configuration blocks in one file, instead of splitting it out over different environment files. However, this article still refers to the old “one file per environment” approach as it’s still supported and won’t be removed.