Skip to content

Tag: docker

Private DNS for Native Windows Docker Container

Docker Windows containers have a number of shortcomings, particularly around networking. One showstopper is that it doesn’t use the DNS of its host server. The expected behaviour in (Linux) Docker containers is that the Docker engine creates a virtual DNS for containers. The Docker DNS resolves containers by name (for Docker Swarm / Docker Compose) or delegates to the host DNS configuration. There are options to override this behaviour if necessary.

Native Windows containers don’t do this. Docker for Windows will resolve container names from the Swarm and will then use the default external DNS (Google DNS on 8.8.8.8) to resolve external addresses. It will not use the host machine DNS settings nor can its behaviour be overridden with the --dns flag. This is a serious problem if your container depends on services within a private / corporate network.

This appears to be an issue with the Docker Windows images (nanoserver / windowservercore) rather than with the engine. Microsoft might get round to fixing it but given its half-hearted support for Docker, it might not.

Activate the Docker Maven plugin when Docker is present

The wonderful docker-maven-plugin from Spotify is a great way to build Docker images from Maven. If you bind it to Maven phases, it can be used to make a one-step build of a project artifact and its Docker image. For example, if you bind the Docker Maven plugin’s build goal to the Maven package phase, it will create your Docker image when you run a standard

mvn clean install

command. That’s neat, but the drawback is that the build will fail entirely if Docker is not available on the build machine. This somewhat goes against the Maven ideal of portable builds – we don’t want a build that works on my machine but not yours.

We can workaround this problem by making the Docker build optional and enabling only if Docker is available.

WebSocket push notifications with Node.js

The Node.js website describes it as having “an event-driven, non-blocking I/O model that makes it lightweight and efficient”. Sounds lovely, but what’s it actually for?

Modulus’s excellent blog post – An Absolute Beginner’s Guide to Node.js provides some rather tasty examples. After covering the trivial examples (Hello world! and simple file I/O), it gets to the meat of what we’re about – an HTTP server. The simple example demonstrates a trivial HTTP server in Node.js in 5 lines of code. Not 5 lines of code compiled to an executable or deployed into an existing web server. 5 lines of code that can be run from a simple command. It then goes on to describe the frameworks and libraries that let you do really useful stuff.

This looks just the thing for implementing a new feature in the Spanners demo app: push notifications to all logged-in users when a spanner is changed.

Docker Part 4: Composing an Environment Stack

This series of articles on Docker has so far covered a number of examples of creating and running individual Docker containers. We’ve also seen an example of how multiple Docker containers can be linked together using the –link  command line flag.

Best practice for containerization suggests that each container does exactly one job. A full environment stack for a complex application may comprise many components – databases, web applications, web/micro services – each requiring its own container. Setting up the full working environment stack may require several lines of docker run commands, run in the right order, with just the right flags and switches set.

An obvious way to manage this is with a startup script. A neater solution is to use Docker Compose. Docker Compose allows multi-container applications to be defined in a single file and then started from a single command.

Docker Part 3: Disposable Containers

The previous posts in this series on Docker have looked at using containers to run services, specifically a web server and database server. However, Docker allows containers to be created, run, stopped and destroyed so cheaply that they can be used to run a single job. This job could be a script or even a single command. Unlike a service, a job will stop running when it’s complete. A container running a short lived job can be set to automatically stop and remove itself once the job is complete. If the job needs to be run again, it is reasonably efficient for Docker to start up a brand new container as required.

Docker Part 1: Running Containers

Docker is a containerization technology that’s been getting quite a bit of attention over the last year or two. It offers a more lightweight, flexible and repeatable alternative to creating and running full Virtual Machines (VMs). In this, the first in a series of posts on Docker, I’ll look at how to run an application inside of a pre-built container image. In this series, I’ll look at:

  1. Running Containers (this post);
  2. Building Images: How to create a new container image, customized to your requirements;
  3. Disposable Containers: Using containers to run a short-lived job rather than a long-lived service;
  4. Composing an Environment Stack: Creating an environment composed of multiple linked containers.