Containers are an abstraction in the application layer, whereby code and dependencies are compiled or packaged together. In this doc, we'll cover, container images, compiling a container, and automating a container registry.
The container image as a building block
A container image is a fixed, static file which contains executable code that allows it to run an isolated process in a computing environment. The image consists of system libraries and binaries (which are system tools, and other platforms settings) needed by a software program to run on the containerization platform. Examples of containerization platforms include Docker, Red Hat OpenShift, D2IQ-Mesosphere, Amazon Web Services ECS/EKS, Microsoft Azure Container Service, and Google Container Engine-GKE, among others. The container image shares the operating system (OS) kernel of its host machine.
Compiling a container
The container image is compiled from file system layers to form a starting image. This is usually accomplished using the relevant build command on a containerization platform. Compiling the file system layers results in the reuse of various components. The developer need not create everything again; when a new container needs to be created, the same starting image can be used. The container starting image can be modified to add or remove functionality and fix errors.
Automate a container registry
You can enable automation when creating container images by developing and applying a set of layers to the image. A container registry is used to store container images. For example, software providers like Microsoft have created SQL Server 2017 container images for use on containerization platforms. A container registry could be public, as obtained from a container platform provider such as Docker Registry, or Azure Marketplace, or from an open source registry. Or, it could be from a private registry, which means it is developed by the organization that will utilize it.
Containers are an abstraction in the application layer, whereby code and dependencies are compiled or packaged together. It is possible to run multiple containers on one machine. Each container instance shares the OS kernel with other containers, each running as an isolated process. A sample application, or a microservice, is packaged into a container image and deployed for use through the container platform. The container platform is a client-server software facilitating the execution of the container by providing three key operational components:
- A daemon is a process that runs in the background. This daemon manages objects like images, containers, and other communication (network), and storage (data volume) objects needed by the microservice encapsulated within the container.
- An application programming interface (API) allows programs to interact with and direct the daemon process.
- A command line interface (CLI) client issues commands, like "pull" and "run", and is used to access container images from a configured registry. The command line uses the API to control or interact with the daemon through direct commands, or scripts containing commands. The daemon, in turn, delivers the results through the Host OS System for further processing, or as a final output.
As an example, the container platform from Docker, the Docker Engine, consists of a daemon server, a REST API, and a CLI client.
The process at a glance
A container is compiled from a base image, and the sample application or microservice is packaged into a container image and deployed for use through the container platform. The container platform is a client-server software facilitating the execution of the container by providing three key operational components, a daemon service, an API, and a CLI interface. Once deployed. the container remains active as long as the application or microservice needs to perform its role in the overall application, and it shuts down once the delivery is complete. The container can be further activated as needed.
