Using a Docker container as a runtime environment

In the previous section, we built a Docker image to perform the testing. Particularly, in the TDD practice, the unit test cases and the code go through multiple changes. Consequently, the Docker image needs to be built over and over again, which is a daunting task. In this section, we will see an alternative approach in which the Docker container is built with a runtime environment, the development directory is mounted as a volume, and the test is performed inside the container.

During this TDD cycle, if an additional library or update to the existing library is required, then the container will be updated with the required libraries and the updated container will be committed as a new image. This approach gives the isolation and flexibility that any developer would dream of because the runtime and its dependency live within the container, and any misconfigured runtime environment can be discarded and a new runtime environment can be built from a previously working image. This also helps to preserve the sanity of the Docker host from the installation and uninstallation of libraries.

The following example is a step-by-step instruction on how to use the Docker container as a non-polluting yet very powerful runtime environment:

  1. We begin with launching the Python runtime interactive container, using the docker run subcommand:
      $ sudo docker run -it 
-v /home/peter/src/hitcount:/src
python:latest /bin/bash

Here, in this example, the /home/peter/src/hitcount Docker host directory is earmarked as the placeholder for the source code and test files. This directory is mounted in the container as /src.

  1. Now, on another Terminal of the Docker host, copy both the test_hitcount.py test file and the hitcount.py visitors count implementation to the /home/peter/src/hitcount directory.
  2. Switch to the Python runtime interactive container Terminal, change the current working directory to /src, and run the unit test:
      root@a8219ac7ed8e:~# cd /src
root@a8219ac7ed8e:/src# python3 -m unittest
E
=====================================================
=================

ERROR: test_hitcount
(unittest.loader.ModuleImportFailure)
. . . TRUNCATED OUTPUT . . .
File "/src/test_hitcount.py", line 4, in <module>
import mockredis
ImportError: No module named 'mockredis'
---------------------------------------------------------------

Ran 1 test in 0.001s

FAILED (errors=1)

Evidently, the test failed because it could not find the mockredis Python library.

  1. Proceed to install the mockredispy pip package because the previous step failed as it could not find the mockredis library in the runtime environment:
      root@a8219ac7ed8e:/src# pip install mockredispy
  1. Rerun the Python unit test:
      root@a8219ac7ed8e:/src# python3 -m unittest
E
=====================================================
============

ERROR: test_hitcount
(unittest.loader.ModuleImportFailure)
. . . TRUNCATED OUTPUT . . .
File "/src/hitcount.py", line 1, in <module>
import redis
ImportError: No module named 'redis'

Ran 1 test in 0.001s

FAILED (errors=1)

Again, the test failed because the redis driver is not yet installed.

  1. Continue to install the redis driver using the pip installer, as shown here:
      root@a8219ac7ed8e:/src# pip install redis
  1. Having successfully installed the redis driver, let's once again run the unit test:
      root@a8219ac7ed8e:/src# python3 -m unittest
.
---------------------------------------------------------------
--

Ran 1 test in 0.000s

OK

Apparently, this time the unit test passed with no warnings or error messages.

  1. Now we have a runtime environment that is good enough to run our test cases. It is better to commit these changes to a Docker image for reuse, using the docker commit subcommand:
      $ sudo docker commit a8219ac7ed8e   
python_rediswithmock

fcf27247ff5bb240a935ec4ba1bddbd8c90cd79cba66e52b21e1b48f984c7db2
  1. From now on, we can use the python_rediswithmock image to launch new containers for our TDD.

In this section, we vividly illustrated the approach on how to use the Docker container as a testing environment, and also at the same time, preserve the sanity and sanctity of the Docker host by isolating and limiting the runtime dependency within the container.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset