Container deployment involves multiple stages. Read through to learn the different stages involves with a Docker-specific use case.
Container deployment basics
Container deployment entails the action of installing container images to their computing environment, this could include environment variations like cloud (private/public) or bare-metal servers. In a normal production environment, it is common to have multiple containers deployed at once, in fact large scale operations might deploy hundreds or thousands of containers a day.
The containerization platform
Containers are deployed by using containerization platforms like, Docker Desktop, Red Hat OpenShift, D2IQ-Mesosphere DCOS, Amazon Web Services ECS/EKS, Microsoft Azure Container Service and Google Container Engine-GKE among others.
Starting with the container image
First step for a container deployment is to build a container image for your container. This can be done by creating a new image or reusing existing container images from the container repository. Each containerization platform hosts its own container repository. For example, on the Docker Platform, the Docker Image can be sourced from the Docker Hub repository. The container repositories have platform provided images as well as publicly shared pre-coded images for common services and applications. Respective platform documentation covers these procedures well.
Solutions like AWS App2Container on the AWS Container Platform help containerize and migrate .NET and Java applications, others offer the ability to create scripts that help partially or fully automate container deployments. Solutions like Google Build help run build steps in a Docker container, with the possibility to build, test, and deploy on Google’s platform.
Container deployment general steps
Container deployment can be generalized into 3 steps
1. Assess
A good pre-deployment practice is to assess/test the microservice or application planned to be encapsulated in the container. The assessment is to ensure that basic unit and functional goals are met. These Assessments, apart from ensuring the application delivers intended outcome, would also expose the system dependencies needed. These dependencies are inputs for the binaries and system files needed in the container image that will be used to encapsulate the application. For example, a “Java application” may have a dependency on a specific “JDK”(Java Development Kit). The base container image sourced from the repository to build the new “Java app container” will need the relevant JDK file-layers used by the container publisher, for the new container to function. If the required JDK is not available in the base image, this will need to be built in as layer while compiling the image with the planned Java app code. Once the assessment is complete, the container can be Compiled or built.
2. Compile
Once the microservice is successfully assessed for the varying scenarios (or use cases) that it must deliver to, it is ready to be compiled with requisite dependencies and binaries. The list of dependencies can be built based on testing scenarios and errors addressed. Tools from container platforms could be used to increase speed and reduce errors, for example, Cloud Build from Google can be used on Google Cloud Platform’s Google Container Engine GKE orchestrator.
2.1 Good practices while compiling
Best practice is to have one application in one container, because a container is designed to have the same lifecycle as the hosted application/microservice. This way when the container starts, the app starts and when the app stops, the container stops too. For example, a stack that consists of Apache/Java/MySQL for a Linux environment should be implemented as three containers - one for Apache, one for Java, and one for MySQL.
2.2 Pull the base container image
Select / ‘pull’ the most suited base container image from the image repository. All public Docker Images are available for inspection and download. For example, to build a Java App container, search the repository for ‘OpenJDK’ container. The Java app code can be added into the base container downloaded. If the required JDK was missing, this will need to be added too.
2.3 Dockerfile a fundamental container image building block
A Dockerfile is used when dockerizing a microservice/app. The Dockerfile is used to create container images. The Dockerfile is a text file consisting of CLI commands, used in conjunction with the ‘docker build’ CLI command.
2.4 Compiling the container image
Typical steps to compile a container starting from the base image would be to add-in the following actions into the Dockerfile
- Use the command to ‘pull/use’ base container image from repository
- Define the run environment, this will add OS related binaries as available in the repository which are needed for the final container to communicate through the orchestration layer
- Define additional environmental requirements to be pulled from the repository or copy from the developer’s libraries
- Set the default environment definitions that the container must use, including working directories, commands that will run in the container, communication ports to be opened
- Finally copy the microservice/ app source code
The above created Dockerfile is used to create a new container image by running the ‘docker build’ CLI.
2.5 Test the new container image
Typical steps to test a new container include
- Use the command to ‘run’ new container image
- Test new running application to see if the required outcomes are achieved
- Once tested, the container can be stopped and removed
The new container is now ready for deployment.
3. Deploy
The tested container is now ready to be put/deployed into a production environment. To deploy the new container image to be available for operations, the container image should be uploaded into the repository. The requisite CLI for the container platform, for example, ‘docker commit’ can be used to load the new container image into the repository, on the Docker Container Platform. With this the container is available for deploying the microservice or app in the selected computing environment.
The source code of the app or microservice planned to be deployed in a container should be isolated and tested for unit and functional dependencies. Once the app / microservice source code works as intended in the environments planned, deploying a container into production starts with creating the container image. A base image can be downloaded from the image repository hosted by the containerization platform. To the base image required environmental dependencies and binaries files are added. The allowed commands and communication ports/protocols are defined. The source code of the app or microservice is now added into the container image. The new container image is now compiled with all the added information. The new container image is then loaded and tested to ensure that it works as intended. Once the tests are done, the new container image is uploaded into the image repository. Now the new container is available to be called/pulled into a production environment.
