Introduction to Image Features

All of the images provided share a common set of features designed as a standard development framework which also caters to the varied needs of complex cloud deployments. In other words, these images were designed from the ground-up in the spirit of DevOps, creating a seamless technology bridge between the needs of developers and the needs of those who manage infrastructure and deployment.

All containers (and derivatives you create) support the following features:

1. They support three modes of operation: closed, attached-storage, and developer.
2. They have consistent start-up command lines and have consistent environment variable usage, which developers can build upon.
3. They support various externally-triggerable tasks such as get-help to get a self-documenting descripiton of the image, get-launcher to extract pre-defined launcher scripts tailored to the image, and get-chaplocal to get scripts to allow developers to create their own local development environment for working on the image.
4. They have a pre-established start-up sequence, including a startup.d directory where additional start-up scripts can be stored, along with README files where needed so that such things are self-documenting.
5. They are highly customizable.

###Modes of Operation

Images are designed to work in three distinct modes:

1. Closed mode, where the container is completely self-contained and needs no external storage.
2. Attached-storage mode, where the container contains all needed infrastructure (including application code), and persistent storage is attached to /apps/var.
3. Developer mode, where the container provides infrastructure, but the application code as well as persistent storage are located somewhere in the developer's local home directory.

The first two modes are generally used for production and you can read about them in the separate page Production Modes.

The third mode, "Developer Mode", provides a more extensive set of features and best practices to assist developers working on the image and you can read about them on the separate page Developer Mode.

All modes are designed to be compatible and interchangeable. For example, an production image can also be used as the basis for development, and a development-mode image can quickly create derivative images which share the same set of common features.

The modes also have a unified approach to user and group credentials management. Images are designed so that services never run as root, and never have pre-defined user-credentials assigned to them. While developers can create exceptions to this rule, it is a best practice that makes images more versatile, especially when using attached storage where externally-defined credentials must be respected. You can read more about this under User Credentials Management.

###External Tasks

Aside from their normal function as service-providing containers, all of these containers support externally-triggerable tasks, or just "tasks". These tasks are operations which provide utility to the developer or deployment team. They help make the container self-documenting, and can be augmented by the developer with additional tasks.

Tasks are initiated on an image by running the container with the --task switch. For example, to get image-specific help:

docker run -i --rm chapdev/chaperone-alpinejava --task get-help

The above will print a help message describing any special features, services, or configuration needs the container may have.

In addition, since each container may have special requirements at launch time, a sample launcher script can be obtained using the get-launcher task:

docker run -i --rm chapdev/chaperone-alpinejava --task get-launcher | sh

Note that some tasks, such as get-launcher are piped into a local shell, since they provide custom shell scripts.

These tasks are designed to be easily customized by developers by adding help and launcher templates in the /apps/etc/skel directory.