Running Docker from Grunt
Tags: 100daysofcode, node, grunt, docker
Published: 2017-01-13 12:37:10

---
title: Running Docker from Grunt
published: true
description: 
cover_image: 
tags: 100daysofcode, node, grunt, docker
---

After a recent post on here, and feedback to it, I'm playing with Node again. And this time, I've tackled my problem of having databases set up for development and verification test runs. As I mentioned before, in my Java world I always have embedded - or psuedo-embedded in some cases - databases that start up as part of the application startup so that the dev runs or the verification test runs will be as self contained as possible. In Node this isn't really very easy to achieve.

Enter Docker.

More specifically, enter [Docker Compose](https://docs.docker.com/compose/), [Grunt](http://gruntjs.com/), and [Grunt-Shell](https://github.com/sindresorhus/grunt-shell). I've managed to cobble together a solution that spawns Docker Compose, then runs the rest of the build, and then at the end of it all shuts down the Docker containers. This means that I can run "grunt start" or "grunt verify", have everything start up, and know that afterwards it's all shut down cleanly.

The important part, of course, is how. Here we go. Note that I'm also using the awesome [Task-Master](https://www.npmjs.com/package/task-master) module to help make my Grunt configuration cleaner. This makes no difference to anything except for what you see here.

Firstly, I wrote some Docker Compose files. I've got one for Dev and one for Test. In this case I'm using Neo4J, but you can use pretty much anything at all that has a Docker Image, including your own home-grown ones if you so desire. I've personally created a `docker` directory in which I've got a `dev.yml` and a `test.yml` file. For this cobbled together implementation that doesn't really matter. This is my `dev.yml` file:

```yaml
version: '2'
services:
    neo4jdev:
        image: neo4j:3.1.0
        ports:
            - "7474:7474"
            - "7687:7687"
        environment:
            - NEO4J_AUTH=none
```

Starting that will give me an environment with Neo4J running, which I can access the Web Admin UI on "http://localhost:7474" and the Bolt API (from Node) on http://localhost:7687". 

Next is actually running it. This is done using Grunt-Shell, the config of which is:

```es6
const execSync = require('child_process').execSync;
const grunt = require('grunt');

function buildDockerCommand(env, cmd) {
    return `docker-compose -p testing${env} -f docker/${env}.yml ${cmd}`;
}

module.exports = {
    'command': (env) => {
        process.on('exit', () => {
            grunt.log.ok('Killing docker');
            execSync(buildDockerCommand(env, 'down'));
            if (env === 'test') {
                grunt.log.ok('Removing docker containers');
                execSync(buildDockerCommand(env, 'rm -f'));
            }
        });
        return buildDockerCommand(env, 'up -d');
    }
};
```

Literally what this does is:
* Sets up a Process Exit hook to stop the containers, and if the environment is "test" to remove them
* Start the containers up

My aliases in Grunt then are:

```json
{
  "start": [
    "build",
    "shell:docker:dev:up",
    "express:dev"
  ],

  "verify": [
    "build",
    "build:verify",
    "shell:docker:test:up",
    "express:verify",
    "mochaTest:verify"
  ]
}
```

Simple as that. The "grunt start" command will now spawn the "dev" Docker environment, and then run my application against it. The "grunt verify" command will spawn the "test" Docker environment, run my application against it, and then run the verification tests against this running application. And after Grunt finishes in both cases - either by the tests finishing or by hitting Ctrl-C - the Docker environment gets shut down.

It does take time to do this, but not a lot. (My verification run is about 10 seconds at present, from start to finish. That doesn't include any UI tests yet though.) The first time you run them on a new machine it will have to download all of the Docker images, but apart from some CI setups that should be a one-off.