docker-dev
v1.10.0
Published
A lightweight CLI utility that extends docker-compose with functionality that is particularly useful in a development environment.
Downloads
3
Readme
docker-dev
A lightweight CLI utility that extends docker-compose with functionality that is particularly useful in a development environment.
Installation
npm i -g docker-dev
Introduction
Over time, Docker has taken its place as a critical component of my development toolkit. It's powerful and allows for a tremendous degree of flexibility, but I find that it lacks some important "out of the box" features that are particularly important within the context of a development environment. This lightweight utility works in conjunction with docker-compose to fill in those missing gaps, which are detailed below.
Development Workflow
Describing the Image
When creating a new Docker service, my first steps include the creation of a new Git repository in which to store the project, along with a Dockerfile that describes the image / environment in which it will run.
The following Dockerfile
demonstrates the creation of a simple Node-based service that connects to a PostgreSQL database.
FROM mhart/alpine-node:6.9.2
RUN apk update &&
apk upgrade &&
apk add \
bash \
tzdata \
git \
openssh \
postgresql-client \
postgresql-contrib \
postgresql-dev
RUN cp /usr/share/zoneinfo/America/New_York /etc/localtime
RUN rm -rf /var/cache/apk/*
RUN npm i -g nodemon yarn grunt-cli
ENV TERM=xterm-256color
COPY package.json yarn.lock /opt/app/
WORKDIR /opt/app
RUN yarn
COPY . /opt/app
ENTRYPOINT node ./bin/index.js
EXPOSE 80
Describing the Development Environment
With my application's code and accompanying Dockerfile
committed, I now turn to the creation of a development environment in which I can manage this service and the others with which it interacts. This involves the creation of a docker-compose.yml
file that allows me to define and manage these services as a group, an example of which is shown below.
###
### Within my development environment, this file is located at:
###
### ~/workspace/docker-compose.yml
###
version: '3'
services:
# The app we created in the previous step
app:
build:
context: ./app
image: docker.private-registry.com/app:develop
volumes:
- ~/workspace/app:/opt/app
depends_on:
- db
# A PostgreSQL service with which our application can interact
db:
image: postgres:9.2.21
ports:
- "127.0.0.1:5432:5432"
environment:
- POSTGRES_USER=postgres
- POSTGRES_PASSWORD=postgres
- POSTGRES_DB=app
- PGDATA=/var/lib/postgresql/data/pgdata
volumes:
- /var/lib/postgresql/data/pgdata:/var/lib/postgresql/data/pgdata
Note: A description of the various options that are available via Docker's docker-compose
utility can be found here.
So far, we've done nothing that goes beyond the traditional Docker development process. Let's extend that process now with the creation of a new docker-dev.yml
file that we'll save in the same location as the docker-compose.yml
file that we just looked at.
###
### Within my development environment, this file is located at:
###
### ~/workspace/docker-dev.yml
###
repositories:
- url: https://github.com/tkambler/docker-example1.git
# The default branch to be checked out when the development environment is brought online
branch: master
# The location to which the repository should be cloned
dest: ./app
services:
# Corresponds to the 'app' service that we defined in docker-compose.yml
app:
export:
- /opt/app/node_modules:./app/node_modules
service-scripts:
# Commands to be run immediately after the service is started.
post-up:
- ["knex", "migrate:latest"]
- ["knex", "seed:run"]
hostnames:
- app.site
The various options that this file supports are outlined below.
repositories
An array of Git repositories. When our development environment is launched via the docker-dev up
command, any repositories that are defined here will first be cloned before any other steps occur.
services
Within our docker-dev.yml
file, we define services that correspond with those found in docker-compose.yml
. For each service, we can define a number of options:
export
Each entry within this list maps a file or folder that is located within our project's image to a location on our host's local filesystem. After our service's image has been built, but before its corresponding container is started, these files will be copied from the image to the host. This is important, in that it allows us to build this service's dependencies within the appropriate runtime environment.
In this example, our image's /opt/app/node_modules
folder is mapped to ~/workspace/app/node_modules
on our host.
host-scripts.post-up
An array of scripts to be executed on the host immediately after this service is brought on-line.
service-scripts.post-up
An array of scripts to be executed within the container immediately after this service is brought on-line.
hostnames
An array of hostnames. When our development environment is launched via the docker-dev up
command, the host's hosts
file will be updated such that each of the hostnames defined here map to the loopback address of 127.0.0.1
.
Commands
up
Bring up services:
$ docker-dev up
down
Bring services down with:
$ docker-dev down