Oracle Linux - private build your docker images

In our examples we are running a Docker engine on an Oracle Linux host which we use to explain how you can work with Docker and containers. In this example post we do have the need to privately build our docker images and containers. The request for this is not that uncommon. As docker is used for a large part in enterprises the need to ensure a safe way of building your internal docker images loaded with your own code deployments is seen often. In our example case we will use github.com as the source repo as well as a local file and we will depend on certain images available on hub.docker.com however when you deploy a full private environment you should use your own git implementation and your own Docker registry.

Building with github
when we build based upon a Dockerfile in github we have to provide "docker build" with the location of the Dockerfile. Alternatively, if your Dockerfile is in the root of your project you can call it without the explicit reference to the Dockerfile. In the below example we use the explicit calling of the Dockerfile which is not always the best way of doing it.

We use the below command in our example:

docker build --no-cache=true --rm -t databases/mongodb:latest https://raw.githubusercontent.com/louwersj/docker_mongodb_ol6/master/mongodb_3.4/OL6.9/Dockerfile

This will result in the download of the the Dockerfile from github and the start of the build, as you can see we call it .raw. in the url to ensure we get the raw file. Additionally we use a couple of flags for the build:

--no-cache=true
this is used to ensure we do not use any cache. In some cases it can be useful to use the cache of previous builds, in cases you want to be a hunderd percent sure you use the latest of everything you should prevent the use of cache by using this flag.

--rm
This flag will ensure that all temporary data is removed after the build. If not you will find a lot of directories under /tmp which hold old build data. To ensure the system stays clean you should include this flag during the build operation.

-t databases/mongodb:latest
This is used to provide the right tagging to the newly build image. As you can see we indicate that this is part of the databases set and is a MongoDB tagged as latest.

As soon as the build has completed you can check the list of images within Docker to see if it is available, this is shown in the example below:

[root@localhost tmp]# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED              SIZE
databases/mongodb   latest              185f6f594f9e        About a minute ago   251.4 MB
[root@localhost tmp]# 

Testing the new build 
Now we have build a new image we would like to test this image. This can be done in the same way as that you would normally create a container from an image.

[root@localhost tmp]# docker run --name mongodb_node_0 -d -p 27017 databases/mongodb:latest
154b9b82e43186411c614ebdc45cdd1c7cc98ec8c6b7af525474f880a8356d52
[root@localhost tmp]# 

If we would now check the running containers we will find the newly created container with the name mongdb_node_0 up and running

[root@localhost tmp]# docker ps
CONTAINER ID        IMAGE                      COMMAND             CREATED             STATUS              PORTS                      NAMES
154b9b82e431        databases/mongodb:latest   "/usr/bin/mongod"   34 seconds ago      Up 34 seconds       0.0.0.0:32771->27017/tcp   mongodb_node_0
[root@localhost tmp]# 

As you can see from the above example, we now have the container running, we could take a look by using the exec command on bash to be extra sure

[root@localhost tmp]#
[root@localhost tmp]# docker exec -it 154b9b82e431 /bin/bash
[root@154b9b82e431 /]# ps -ef|grep mongo
root         1     0  0 19:17 ?        00:00:01 /usr/bin/mongod
root        35    24  0 19:19 ?        00:00:00 grep mongo
[root@154b9b82e431 /]# 
[root@154b9b82e431 /]# exit
exit
[root@localhost tmp]#
[root@localhost tmp]# 

Building with a local file
For a local file based build we have placed the Dockerfile in /tmp/build_test/ we can use the same manner to build a docker image as we did for the github example however now we have to state the location of the Dockerfile on the local file system. You have to be sure you state the location and not the file itself to prevent an error as shown below:

[root@localhost /]# docker build --no-cache=true --rm -t localbuild/mongodb:latest /tmp/build_test/Dockerfile
unable to prepare context: context must be a directory: /tmp/build_test/Dockerfile
[root@localhost /]#

As you can see, calling the file will give an issue, if we call the location the build will happen without any issues:

[root@localhost /]# docker build --no-cache=true --rm -t localbuild/mongodb:latest /tmp/build_test/
Sending build context to Docker daemon 4.096 kB
Step 1 : FROM oraclelinux:6.9
 ---> 7a4a8c404142
Step 2 : MAINTAINER Johan Louwers 
 ---> Running in e7df0ce9533b
 ---> 6bd403a6a188
Removing intermediate container e7df0ce9533b
Step 3 : LABEL maintainer "louwersj@gmail.com"
 ---> Running in 5dbe161c94c3
 ---> c1ccf03f5aaa
Removing intermediate container 5dbe161c94c3
Step 4 : ARG VERSION
 ---> Running in 70f75e234ec3
 ---> 8789acea412c
Removing intermediate container 70f75e234ec3
Step 5 : ARG VCS_URL
 ---> Running in a6fcb917dab0
 ---> 5ec17fc93bd5
Removing intermediate container a6fcb917dab0
Step 6 : ARG VCS_REF
 ---> Running in 8581b2273afb
 ---> f38bd895e43e
Removing intermediate container 8581b2273afb
Step 7 : ARG BUILD_DATE
 ---> Running in 3b10331e2f96
.......................ETC ETC ETC...........

A check on the images available right now will show we now have a new image named localbuild/mongodb:latest as shown below:

[root@localhost /]# docker images
REPOSITORY           TAG                 IMAGE ID            CREATED              SIZE
localbuild/mongodb   latest              ac7816da045f        About a minute ago   251.4 MB
[root@localhost /]# 

Using a local file (which can be pulled from a local git repository) can be very valuable, especially if you need to mix the build of your image with artifacts from other builds. For example, if you want to include the war files from a maven build to provide a microservice from within a container concept. In case you want to build very specific containers who contain specific business functionality the use of the local file option is a possible route.