imaginator

The imaginator daemon builds OS and OS+application images which are specified by image manifests.

Status page

The imaginator provides a web interface on port 6975 which shows a status page, links to built-in dashboards and access to performance metrics and logs. If imaginator is running on host myhost then the URL of the main status page is http://myhost:6975/. An RPC over HTTP interface is also provided over the same port.

Startup

Imaginator is started at boot time, usually by one of the provided init scripts. The imaginator process is baby-sat by the init script; if the process dies the init script will re-start it. It may be stopped with the command:

service imaginator stop

which also kills the baby-sitting init script. It may be started with the command:

service imaginator start

There are many command-line flags which may change the behaviour of imaginator, generally with defaults which should be adequate for most deployments. Built-in help is available with the command:

imaginator -h

Key configuration parameters

The init script reads configuration parameters from the /etc/default/imaginator file. The following is the minimum likely set of parameters that will need to be configured.

The CONFIGURATION_URL variable specifies the main configuration URL, which may be a local file or a HTTP URL. It is recommended to specify a HTTP URL which references a file in a Git repository.

The IMAGE_SERVER_HOSTNAME variable specifies the hostname where the imageserver is running. This hostname must be resolvable by the imaginator.

The VARIABLES_FILE variable specifies an optional filename from which to read special variables which may be used for variable expansion. These are typically used to store secrets for accessing Git repositories which require authentication. Each line should contain a single NAME=Value entry.

Security

RPC access is restricted using TLS client authentication. Imaginator expects a root certificate in the file /etc/ssl/CA.pem which it trusts to sign certificates which grant access. It also requires a certificate and key which grant it the ability to add and get images and objects from the imageserver. These should be in the files /etc/ssl/imaginator/cert.pem and /etc/ssl/imaginator/key.pem, respectively.

Control

The builder-tool utility may be used to request the imaginator to build an image.

Main Configuration URL

The main configuration URL points to a JSON encoded file that describes all the image streams and how to build them. The top-level JSON object defines the following fields:

A sample configuration file is provided which may be modified to suit your environment. This is a fully working configuration and only requires modification of the location of the package repositories and the ImageStreamsUrl for your custom image streams. Details on some of the above configuration entries are described below.

BootstrapStreams configuration

Each bootstrap stream is configured by a JSON object with the following fields:

Cache configuration

It's considered an anti-pattern to use the Imaginator to compile code; instead code should be separately pre- compiled into binary artefacts and added when building images. However, in some cases - such as extra kernel drivers - it may be difficult to pre-compile for the kernel being added to an image. In this case it may be simpler to compile during the image build. A cache can be used to avoid re-building if an appropriate artefact has already been built.

The cache configuration is a JSON object with the following fields:

The name of the image stream is appended to the BaseDirectory and this sub-directory of the cache is mounted in the build environments. This provides each image stream with it's own subsection of the cache.

ImageStreams URL

This is a JSON encoded configuration file listing all the user-defined image streams. It contains the following top-level fields:

The $ARCH variable in the pattern strings or stream names expands to the value of runtime.GOARCH.

The configuration for an image stream is a JSON object with the following fields:

An example configuration file is provided. Note the use of variables in different places.

PackagerTypes

Each packager type is configured by a JSON object with the following fields:

These parameters are used to generate a /bin/generic-packager script which is used as an interface to the native OS packaging tools.