8i | 9i | 10g | 11g | 12c | 13c | 18c | 19c | 21c | 23c | Misc | PL/SQL | SQL | RAC | WebLogic | Linux

Home » Articles » Linux » Here

Docker : Writing Your First Dockerfile

This article covers some of the basics of writing and using a Dockerfile with worked examples. There are additional operations not included here, as well as multiple syntax variations for the operations that are included. The Dockerfile reference and Best practices for writing Dockerfiles documents are must reads if you want to understand all the possibilities.

Related articles.

Assumptions

This article makes the following assumptions.

Minimum

Create a location to hold all your Dockerfiles. In this case we will have a location called "~/dockerfiles", with a subdirectory for each individual image. The first image we will create will be called "ol7_slim", so we will create a subdirectory of the same name.

$ mkdir -p ~/dockerfiles/ol7_slim
$ cd ~/dockerfiles/ol7_slim

Now create a file called "Dockerfile" with the following contents. You should be able to see now why you need a separate subdirectory for each image.

# ------------------------------------------------------------------------------
# Dockerfile to build basic Oracle Linux container images
# Based on Oracle Linux 7 - Slim
# ------------------------------------------------------------------------------

# Set the base image to Oracle Linux 7 - Slim
FROM oraclelinux:7-slim

# File Author / Maintainer
# Use LABEL rather than deprecated MAINTAINER
# MAINTAINER Tim Hall (tim@oracle-base.com)
LABEL maintainer="tim@oracle-base.com"

# End

The FROM instruction identifies the image this image is based on. The LABEL is used to expose information about the image. This Dockerfile is a little pointless as it doesn't add anything to the "oraclelinux:7-slim" image, but it serves as a starting point.

Build the image using the BUILD command and this Dockerfile, giving it an image name "ol7_slim". A tag is used to give the image a version. In this case we will use a tag of "latest".

$ docker build -t ol7_slim:latest .

The image is now built, so we can run a container based on this image using the RUN command. There are a number of run options, but we will keep it simple for the moment and just detach from the container. We've included the --name option so we can refer to the container by a simple name of "ol7_slim_con", rather than a system generated name.

$ docker run -dit --name ol7_slim_con ol7_slim:latest

We can connect to the container by running the bash shell using the EXEC command. Once connected navigate around the container and check it out. When you have finished use exit to come out.

$ docker exec -it ol7_slim_con bash
bash-4.2# ls
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
bash-4.2# exit
exit
$

We can also run commands inside the container directly from the host machine. The following example lists the contents of the root file system inside the container.

$ docker exec -it ol7_slim_con ls
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
$

Remove the container using the RM command. The -v option cleans up any associated volumes and the -f option allows the container to be removed, even if the container is currently running.

$ docker rm -vf ol7_slim_con

RUN : Run Commands

The RUN instruction allows you to define commands that are run during the image build. You should try to string as many commands together as possible into a single call to RUN instruction to reduce the number of layers created. You could achieve this by running a setup script.

Overwrite the "Dockerfile" with the following contents. Notice the RUN operation is used to create two directories.

# ------------------------------------------------------------------------------
# Dockerfile to build basic Oracle Linux container images
# Based on Oracle Linux 7 - Slim
# ------------------------------------------------------------------------------

# Set the base image to Oracle Linux 7 - Slim
FROM oraclelinux:7-slim

# File Author / Maintainer
# Use LABEL rather than deprecated MAINTAINER
# MAINTAINER Tim Hall (tim@oracle-base.com)
LABEL maintainer="tim@oracle-base.com"

# ------------------------------------------------------------------------------
RUN mkdir -p /u01/app/oracle && \
    mkdir -p /u02/oradata
    
# End

The WORKDIR and USER instructions can be used to alter the base path the command is run from and the OS user that runs the command respectively.

Build the image, run a container based on it and check the root file system to see the extra directories. Notice the "u01" and "u02" directories have been created.

$ docker build -t ol7_slim:latest .
$ docker run -dit --name ol7_slim_con ol7_slim:latest
$ docker exec -it ol7_slim_con ls
bin   dev  home  lib64	mnt  proc  run	 srv  tmp  u02	var
boot  etc  lib	 media	opt  root  sbin  sys  u01  usr
$

Once you are happy the commands ran as expected remove the container.

$ docker rm -vf ol7_slim_con

ARG and ENV : Build Arguments and Environment Variables

The ARG instruction allows you to define "build arguments" for use by the Dockerfile. These are only visible during the build phase, not when the container based on the image is running. Arguments can have default values, which are overridden by --build-arg parameters from the build command. Each build using different build arguments will create a new image. This may not be what you want.

The ENV instruction allows you to define environment variables for use by the Dockerfile. These represent default values that can be overridden on the command line at runtime by passing -e parameters. The environment variables are persistent within the container when it is running.

In some cases, you want build arguments to be persisted, so their values are visible beyond the build phase. In this case you must set the default values of environment variables using build arguments, as shown below.

Overwrite the "Dockerfile" with the following contents. Notice the RUN is used to create two directories.

# ------------------------------------------------------------------------------
# Dockerfile to build basic Oracle Linux container images
# Based on Oracle Linux 7 - Slim
# ------------------------------------------------------------------------------

# Set the base image to Oracle Linux 7 - Slim
FROM oraclelinux:7-slim

# File Author / Maintainer
# Use LABEL rather than deprecated MAINTAINER
# MAINTAINER Tim Hall (tim@oracle-base.com)
LABEL maintainer="tim@oracle-base.com"

# ------------------------------------------------------------------------------
# Define the build arguments, setting default values.
ARG ORACLE_HOME=/u01/app/oracle/product/12.2.0.1/db_1
ARG DATA_LOCATION=/u02/oradata

# ------------------------------------------------------------------------------
# Define the environment variables, setting default values using the arguments.
ENV ORACLE_HOME=${ORACLE_HOME} \
    DATA_LOCATION=${DATA_LOCATION}
    
# ------------------------------------------------------------------------------
RUN mkdir -p ${ORACLE_HOME}    && \
    mkdir -p ${DATA_LOCATION}
    
# End

Build the image, run a container based on it and check the root file system to see the extra directories.

$ docker build -t ol7_slim:latest .
$ docker run -dit --name ol7_slim_con ol7_slim:latest
$ docker exec -it ol7_slim_con ls
bin   dev  home  lib64	mnt  proc  run	 srv  tmp  u02	var
boot  etc  lib	 media	opt  root  sbin  sys  u01  usr
$

Once you are happy the commands ran as expected remove the container.

$ docker rm -vf ol7_slim_con

Now build the image again, but alter the build arguments using the --build-arg parameter. Notice the "u03" and "u04" directories have now been created.

$ docker build -t ol7_slim:latest \
               --build-arg ORACLE_HOME=/u03/app/oracle/product/18.0.0.0/db_1 \
               --build-arg DATA_LOCATION=/u04/oradata \
               .

$ docker run -dit --name ol7_slim_con ol7_slim:latest

$ docker exec -it ol7_slim_con ls
bin   dev  home  lib64	mnt  proc  run	 srv  tmp  u04	var
boot  etc  lib	 media	opt  root  sbin  sys  u03  usr
$

The output of the build can look like the default values are being used, but check the results and you will see the build argument values were used.

Once you are happy the commands ran as expected remove the container.

$ docker rm -vf ol7_slim_con

Run a new container based on the previous image, but this time alter the environment variables at runtime. Notice the directories created match those specified in the last build, but the environment variables are now set differently.

$ docker run -dit --name ol7_slim_con \
             -e "ORACLE_HOME=/banana" \
             -e "DATA_LOCATION=/apple" \
             ol7_slim:latest

$ docker exec -it ol7_slim_con ls
bin   dev  home  lib64	mnt  proc  run	 srv  tmp  u04	var
boot  etc  lib	 media	opt  root  sbin  sys  u03  usr
$

$ docker exec -it ol7_slim_con env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=081a5e39a841
TERM=xterm
ORACLE_HOME=/banana
DATA_LOCATION=/apple
HOME=/root
$

Initially you may think build arguments should be used a lot, but in practice that may not be the case. In order to reduce the number of images created you should consider building generic images, then performing container-specific configuration on the first run of the container. For example, you could build a standard application server image, but configure the applications running on it based on the environment variables supplied at runtime on the first run of the container. Using this approach you may not need build arguments at all, since the only things that will vary will be supplied by environment variables at runtime. You will see this approach used by a number of Dockerfiles. It does of course mean the first run of a container will be slower than subsequent runs, since the configuration steps have to be performed.

ADD and COPY : Make External Files Available

The ADD and COPY instructions perform a similar task, copying files or directories from a source outside the image to a destination inside the image. The ADD instruction is a little more flexible as it can retrieve files from URLs and unpack them.

You should avoid bloating images by leaving large amounts of software in them. Once any software is installed, remember to clean down any unnecessary media.

Copy the latest Java 8 JDK (jdk-8u151-linux-x64.tar.gz) into the same directory as the Dockerfile. Replace the previous Dockerfile with the following.

# ------------------------------------------------------------------------------
# Dockerfile to build basic Oracle Linux container images
# Based on Oracle Linux 7 - Slim
# ------------------------------------------------------------------------------

# Set the base image to Oracle Linux 7 - Slim
FROM oraclelinux:7-slim

# File Author / Maintainer
# Use LABEL rather than deprecated MAINTAINER
# MAINTAINER Tim Hall (tim@oracle-base.com)
LABEL maintainer="tim@oracle-base.com"

# ------------------------------------------------------------------------------
# Download the latest Tomcat software into the image
ADD http://www.mirrorservice.org/sites/ftp.apache.org/tomcat/tomcat-8/v8.5.23/bin/apache-tomcat-8.5.23.tar.gz \
    /u01/software/apache-tomcat-8.5.23.tar.gz

# ------------------------------------------------------------------------------
# Copy the local file into the image
COPY jdk-8u151-linux-x64.tar.gz /u01/software/jdk-8u151-linux-x64.tar.gz
   
# End

Build the image, run it and list the contents of the "/u01/software" directory.

$ docker build -t ol7_slim:latest .
$ docker run -dit --name ol7_slim_con ol7_slim:latest
$ docker exec -it ol7_slim_con ls /u01/software
apache-tomcat-8.5.23.tar.gz  jdk-8u151-linux-x64.tar.gz
$

The Java and Tomcat files will now be part of the image and visible in the container in the "/u01/software" directory. Remember, the build should really perform the installation, then remove these files.

Once you are happy the commands ran as expected remove the container.

$ docker rm -vf ol7_slim_con

EXPOSE : Export Ports Outside Container

The EXPOSE operation defines which ports should be exposed to the world outside the container. The port exposed by the container is mapped to a physical port on the host machine, so multiple containers can expose the same port number, provided they are mapped to different physical ports.

Overwrite the "Dockerfile" with the following contents.

# ------------------------------------------------------------------------------
# Dockerfile to build basic Oracle Linux container images
# Based on Oracle Linux 7 - Slim
# ------------------------------------------------------------------------------

# Set the base image to Oracle Linux 7 - Slim
FROM oraclelinux:7-slim

# File Author / Maintainer
# Use LABEL rather than deprecated MAINTAINER
# MAINTAINER Tim Hall (tim@oracle-base.com)
LABEL maintainer="tim@oracle-base.com"

EXPOSE 8080 8443/TCP
    
# End

Build the image then run two containers based on the image. The -p option allows you to bind "host-port:container-port". In this example we run two containers, but bind the exposed ports from the container to different physical ports on the host.

$ docker build -t ol7_slim:latest .
$ docker run -dit --name ol7_slim_con_1 -p 8080:8080 -p 8443:8443 ol7_slim:latest
$ docker run -dit --name ol7_slim_con_2 -p 8081:8080 -p 8444:8443 ol7_slim:latest

Once you are happy the commands ran as expected, remove the containers.

$ docker rm -vf ol7_slim_con_1
$ docker rm -vf ol7_slim_con_2

CMD : Startup Command

The CMD operation defines a startup command or script that is called when the container starts. It should start any software that runs on the container, for example a database or application server.

It's difficult to show a working example of this without doing something meaningful on the container, but you could run a script on container startup by adding the following entry into the Dockerfile.

CMD exec /u01/scripts/start.sh

If you plan to configure the container on the first run, the script you call using the CMD operation should be capable of determining if this is the first run, and doing the necessary configuration.

If the startup script ever completes the container will stop, so it's important you end the script with some form of wait. You will often see containers tail a log file as a background process, then wait on that process. For a database instance you might do the following.

tail -f ${ORACLE_BASE}/diag/rdbms/${ORACLE_SID}/${ORACLE_SID}/trace/alert_${ORACLE_SID}.log &
bgPID=$!
wait $bgPID

HEALTHCHECK : Check Status of the Container

The HEALTHCHECK operation allows you to define a health check command or script that returns 0 if the container is running normally, or 1 if there is a problem. There are a number of options that affect how the health check works, with the most important being the --interval option, which specifies how often the check is run, and the --start-period option, which specifies how long to wait before the first check is run.

It's difficult to show a working example of this without doing something meaningful on the container, but you define a health check with the following type of entry in the Dockerfile.

HEALTHCHECK --interval=5m --start-period=10m \
  CMD /u01/scripts/healthcheck.sh || exit 1

For a database health check you might do something like the following.

RETVAL=`sqlplus -silent / as sysdba <<EOF
SET PAGESIZE 0 FEEDBACK OFF VERIFY OFF HEADING OFF ECHO OFF
SELECT 'Alive' FROM dual;
EXIT;
EOF`

if [ "${RETVAL}" = "Alive" ]; then
  exit 0;
else
  exit 1;
fi

The health of the container is visible in the STATUS column of the Docker PS command. You might see messages such as the following.

Up X minutes (health: starting)
Up X minutes (unhealthy)
Up About an hour (healthy) 

Volumes : Persistent Storage

The storage associated with a container is ephemeral, which can be a little confusing at first. This means changes to the contents of the file system associated with a container will survive a stop/start of a container, but if the container is removed and run again all changes will be lost and the file system contents will match that of the image the container is based on. Volumes allow you to create persistent storage that can survive a remove and new run of a container. There are several ways to work with persistent volumes, which will be shown briefly below.

Managed Volumes

The code below creates a new managed volume, lists all managed volumes and inspects the new volume. The removal of the volume is commented out because we will need it.

$ docker volume create test-vol
test-vol
$ docker volume ls
DRIVER              VOLUME NAME
local               test-vol
$ docker volume inspect test-vol
[
    {
        "Driver": "local",
        "Labels": {},
        "Mountpoint": "/var/lib/docker/volumes/test-vol/_data",
        "Name": "test-vol",
        "Options": {},
        "Scope": "local"
    }
]
$ #docker volume rm test-vol

Overwrite the "Dockerfile" with the following contents. This will create a basic container for us to use as a starting point.

# ------------------------------------------------------------------------------
# Dockerfile to build basic Oracle Linux container images
# Based on Oracle Linux 7 - Slim
# ------------------------------------------------------------------------------

# Set the base image to Oracle Linux 7 - Slim
FROM oraclelinux:7-slim

# File Author / Maintainer
# Use LABEL rather than deprecated MAINTAINER
# MAINTAINER Tim Hall (tim@oracle-base.com)
LABEL maintainer="tim@oracle-base.com"

# End

Build the image using no arguments. When you run a container based on the image, associate the managed volume to the container as a volume using the --mount or -v option. In this case we are associating the "test-vol" directory on the host machine with the "/u01/software" directory within the container. Four variations of the run command are shown below, but only use the first one for this example.

$ docker build -t ol7_slim:latest .

# Using --mount syntax for a read-write volume.
$ docker run -dit --name ol7_slim_con \
             --mount source=test-vol,destination=/u01/software \
             ol7_slim:latest

# Using --mount syntax for a read-only volume.
$ docker run -dit --name ol7_slim_con \
             --mount source=test-vol,destination=/u01/software,readonly \
             ol7_slim:latest

# Using -v syntax for a read-write volume.
$ docker run -dit --name ol7_slim_con \
             -v test-vol:/u01/software \
             ol7_slim:latest

# Using -v syntax for a read-only volume.
$ docker run -dit --name ol7_slim_con \
             -v test-vol:/u01/software,ro \
             ol7_slim:latest

Create two files, one in and one outside of the volume. You could connect using bash and do this manually, or just run the commands directly using the EXEC operation, as shown here.

$ docker exec -it ol7_slim_con touch /u01/software/test1.txt
$ docker exec -it ol7_slim_con touch /test2.txt

Stop and start the container, then check if the files are still present. Both will still be present.

$ docker stop ol7_slim_con
$ docker start ol7_slim_con
$ docker exec -it ol7_slim_con ls /u01/software/test1.txt
/u01/software/test1.txt
$ docker exec -it ol7_slim_con ls /test2.txt
/test2.txt
$

Remove and run the container, then check if the files are still present. The "test1.txt" file will still be present, but the "test2.txt" file will be missing.

$ docker rm -vf ol7_slim_con

$ docker run -dit --name ol7_slim_con \
             --mount source=test-vol,destination=/u01/software \
             ol7_slim:latest

$ docker exec -it ol7_slim_con ls /u01/software/test1.txt
/u01/software/test1.txt
$ docker exec -it ol7_slim_con ls /test2.txt
ls: cannot access /test2.txt: No such file or directory
$

Once you are happy the commands ran as expected remove the container and the volume.

$ docker rm -vf ol7_slim_con
$ docker volume rm test-vol

Host Directories

We can associate a directory or file on the host machine with a path inside the container.

Overwrite the "Dockerfile" with the following contents. This will create a basic container for us to use as a starting point.

# ------------------------------------------------------------------------------
# Dockerfile to build basic Oracle Linux container images
# Based on Oracle Linux 7 - Slim
# ------------------------------------------------------------------------------

# Set the base image to Oracle Linux 7 - Slim
FROM oraclelinux:7-slim

# File Author / Maintainer
# Use LABEL rather than deprecated MAINTAINER
# MAINTAINER Tim Hall (tim@oracle-base.com)
LABEL maintainer="tim@oracle-base.com"

# End

Build the image using no arguments. When you run a container based on the image, associate a host directory to the container as a volume using the -v flag. In this case we are associating the "/media/sf_u01/software" directory on the host machine with the "/u01/software" directory within the container. There are two variations of the run command below, but only use one of the two. Check the contents of the volume.

$ docker build -t ol7_slim:latest .

# read-write volume.
$ docker run -dit --name ol7_slim_con \
             -v /media/sf_u01/software:/u01/software \
             ol7_slim:latest

# read-only volume.
$ docker run -dit --name ol7_slim_con \
             -v /media/sf_u01/software:/u01/software,ro \
             ol7_slim:latest

$ docker exec -it ol7_slim_con ls /u01/software
oracle	os  utils
$

Once you are happy the commands ran as expected remove the container.

$ docker rm -vf ol7_slim_con

Data Volume Containers

A container can be defined to manage volumes, which are then shared with one or more other containers. Create the test volume.

$ docker volume create test-vol

Overwrite the "Dockerfile" with the following contents. This will create a basic container for us to use as a starting point.

# ------------------------------------------------------------------------------
# Dockerfile to build basic Oracle Linux container images
# Based on Oracle Linux 7 - Slim
# ------------------------------------------------------------------------------

# Set the base image to Oracle Linux 7 - Slim
FROM oraclelinux:7-slim

# File Author / Maintainer
# Use LABEL rather than deprecated MAINTAINER
# MAINTAINER Tim Hall (tim@oracle-base.com)
LABEL maintainer="tim@oracle-base.com"

# End

Build the image using no arguments.

$ docker build -t ol7_slim:latest .

Create a container called "data_container" to manage the volume.

$ docker run -dit --name data_container \
             --mount source=test-vol,destination=/u01/software \
             ol7_slim:latest

Create a container called "ol7_slim_con" that uses the volumes from the "data_container" container.

$ docker run -dit --name ol7_slim_con \
             --volumes-from data_container \
             ol7_slim:latest

Copy a file into the volume on the "data_container" container and you will see it present in the same location in the "ol7_slim_con" container.

$ docker cp ./jdk-8u151-linux-x64.tar.gz data_container:/u01/software/jdk-8u151-linux-x64.tar.gz
$ docker exec -it ol7_slim_con ls /u01/software/
jdk-8u151-linux-x64.tar.gz
$

Once you are happy the commands ran as expected remove the containers and volume.

$ docker rm -vf ol7_slim_con
$ docker rm -vf data_container
$ docker volume rm test-vol

VOLUME Operation

The VOLUME operation defines a mount point as being an external volume. By default, a new external volume is implicitly created at runtime and the contents of the mount point in the image are copied to the external volume. Once the container is removed, the implicitly created volume is removed too, so this external volume is not truly persistent. If an explicitly created volume is mounted at runtime it will be used as a persistent store.

The automatic copy of the contents of the mount point only happens with managed volumes and data volume containers, not with host directories.

Overwrite the "Dockerfile" with the following contents.

# ------------------------------------------------------------------------------
# Dockerfile to build basic Oracle Linux container images
# Based on Oracle Linux 7 - Slim
# ------------------------------------------------------------------------------

# Set the base image to Oracle Linux 7 - Slim
FROM oraclelinux:7-slim

# File Author / Maintainer
# Use LABEL rather than deprecated MAINTAINER
# MAINTAINER Tim Hall (tim@oracle-base.com)
LABEL maintainer="tim@oracle-base.com"

RUN mkdir -p /u01/software && \
    echo "test1" > /u01/software/test1.txt

VOLUME ["/u01/software"]
    
# End

Build the image using no arguments, then run a container and list the contents of the "/u01/software" directory.

$ docker build -t ol7_slim:latest .
$ docker run -dit --name ol7_slim_con ol7_slim:latest
$ docker exec -it ol7_slim_con ls /u01/software
test1.txt
$

Alter the name of the file.

$ docker exec -it ol7_slim_con mv /u01/software/test1.txt /u01/software/test2.txt
$ docker exec -it ol7_slim_con ls /u01/software
test2.txt
$

Remove and run the container, then check the contents of the "/u01/software" directory. The "test1.txt" file is back again because the file is reset to the state it was in at the end of the build.

$ docker rm -vf ol7_slim_con
$ docker run -dit --name ol7_slim_con ol7_slim:latest
$ docker exec -it ol7_slim_con ls /u01/software
test1.txt
$

Remove the container, create a test volume, run the container using the test volume mounted to "/u01/software" and check the contents of the "/u01/software" directory.

$ docker rm -vf ol7_slim_con
$ docker volume create test-vol

$ docker run -dit --name ol7_slim_con \
             --mount source=test-vol,destination=/u01/software \
             ol7_slim:latest

$ docker exec -it ol7_slim_con ls /u01/software
test1.txt
$

It's the first time a persistent volume has been used, so the "test1.txt" file is present.

Alter the name of the file.

$ docker exec -it ol7_slim_con mv /u01/software/test1.txt /u01/software/test2.txt
$ docker exec -it ol7_slim_con ls /u01/software
test2.txt
$

Remove and run the container and check the contents of the "/u01/software" directory. The "test2.txt" file has survived the new run of the container.

$ docker rm -vf ol7_slim_con

$ docker run -dit --name ol7_slim_con \
             --mount source=test-vol,destination=/u01/software \
             ol7_slim:latest

$ docker exec -it ol7_slim_con ls /u01/software
test2.txt
$

Once you are happy the commands ran as expected remove the container and volume.

$ docker rm -vf ol7_slim_con
$ docker volume rm test-vol

Networks

We've seen how to expose container ports to the outside world, but containers don't need to expose ports to communicate with each other. This can be achieved by defining a Docker network. Create a network called "mynetwork", list the available networks and inspect the new network.

$ docker network create mynetwork
$ docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
a51a8b12381d        bridge              bridge              local
d55e4dbed845        host                host                local
f9db787759d4        mynetwork           bridge              local
2ca9284ce62a        none                null                local
$ docker network inspect mynetwork
[
    {
        "Name": "mynetwork",
        "Id": "f9db787759d408bdc169c4aab0736031fcaff23056020d2cb503ed08d9aebb18",
        "Created": "2017-11-04T15:59:30.851387813Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {},
        "Options": {},
        "Labels": {}
    }
]
$ #docker network rm mynetwork

Start two containers using the same network.

$ docker run -dit --name ol7_slim_con_1 \
             --network=mynetwork \
             ol7_slim:latest

$ docker run -dit --name ol7_slim_con_2 \
             --network=mynetwork \
             ol7_slim:latest

If you inspect the network again you will see both containers are connected to it.

$ docker network inspect mynetwork
[
    {
        "Name": "mynetwork",
        "Id": "f9db787759d408bdc169c4aab0736031fcaff23056020d2cb503ed08d9aebb18",
        "Created": "2017-11-04T15:59:30.851387813Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "8e035ddc7501a111334ec5ed61807f143b4976232c7d3b541ea40cdf2cfd410d": {
                "Name": "ol7_slim_con_2",
                "EndpointID": "ebff5379c4bef5e191e58f7ce5f354fbda06d19099528d930e6e43ab70d2eb68",
                "MacAddress": "02:42:ac:12:00:03",
                "IPv4Address": "172.18.0.3/16",
                "IPv6Address": ""
            },
            "da042e9abdda55205d21f0f9a1977c1c7e115bc288aa36390badd14fdb019b34": {
                "Name": "ol7_slim_con_1",
                "EndpointID": "650c51c732adfa8e1bce20f42d70d437801e16c355b098f0ac877ca592e7f630",
                "MacAddress": "02:42:ac:12:00:02",
                "IPv4Address": "172.18.0.2/16",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {}
    }
]
$

Remove the containers and the network.

$ docker rm -vf ol7_slim_con_1
$ docker rm -vf ol7_slim_con_2
$ docker network rm mynetwork

For more information see:

Hope this helps. Regards Tim...

Back to the Top.