Over a million developers have joined DZone.

Abstract Docker Images

DZone's Guide to

Abstract Docker Images

Here we're going to talk about Abstract Images, images that have mostly regular functionality, but are not runnable. Check out my use-case and perhaps it will be useful for you too.

· Cloud Zone
Free Resource

Download the Essential Cloud Buyer’s Guide to learn important factors to consider before selecting a provider as well as buying criteria to help you make the best decision for your infrastructure needs, brought to you in partnership with Internap.

I want to share an idea I have with you. It's a simple one, so it won't take long.

When I'm explaining to a colleague the idea of Containers and Docker (when they don't have any previous knowledge), I often use programming terminology—it's easier for me to explain it like that. So, images are like classes and containers are like objects. I can inherit from an image to create a new image, and logically, it's like extending a Java class.

Similarly, I may want to introduce the "Abstract Image" term—an image that includes most of the functionality, but is not runnable. This image will be used to create new runnable images.

Why do I need it? Well, I guess I can solve my problems in many ways, but I found this one fits my needs. Who knows, it might serve you as well.

I have a backend RESTful server that is deployed on many customers' sites. Each deployment has different configuration files to control the server behavior, the set of features that are enabled, and possibly even the data model.

Now, we want to move to Docker. So, I built an abstract image of my server software without any configurations, and I'm using that to create an image per distinct customer. These images are super lightweight–they only contain the configuration files.

The way to build an abstract image is to use the combination of the ONBUILD and the ENTRYPOINT Dockerfile instructions. I didn't find an example of such a combination in the Dockerfile documentation, but it works!

ONBUILD is a Dockerfile instruction that performs the following instruction in the file only when using the image as a base to create a new image.

Using this instruction with the ENTRYPOINT instruction causes the entry point to execute only in the new derived image creation.  

So, if I have the Dockerfile, and I build the "base_app" image from it:

# base_image:2.34
FROM centos_6_java8:1.1

WORKDIR /opt/myapp

# adding the softwar, environment variables and a run.sh script to run the software
# ...

USER myappuser


Now, I can use this image as a base for a new customer specific runnable images:

# customer_specific_image
FROM base_app:2.34

ADD customer_specific_configurations.tar

And, that's it. I don't need to repeat the running environment and parameter for each image—it's all there from the base_app image. Now, each container created from the project specific image will run the script from the base_image.

The Cloud Zone is brought to you in partnership with Internap. Read Bare-Metal Cloud 101 to learn about bare-metal cloud and how it has emerged as a way to complement virtualized services.

docker ,docker images ,containers ,deployment ,object oriented

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}