Using Makefiles to improve Docker image build experience

Makefile is a building tool that's been around forever; and while some of us may remember it from building our first couple projects (and may hate those times and the struggle); But I believe it's an awesome tool that by just adding a single file to our project It can speed / easy up our daily work flow on: how we build, run locally, etc our 'Dockerized' projects.

TLDR Github project:

Lets suppose that in our project we want:

  • Build our docker images
  • We have at least 2 environments: production and development
  • We want to version our images, we will use Git's commit hashes and environment name: {GITHASH}-{ENVIRNONMENTNAME}.

I like going straight to the point, so lets look at the files we need:

├── docker-compose.yml
├── docker-compose.development.yml
├── docker-compose.production.yml
├── .env
└── Makefile

Nothing special here, a base docker-composer, and the other two to customize/extend each of our environments.

So let's look at our Makefile, you can split it in three points:

  1. We include our .env file and then we use some sed magic to export all variables as env (that way those variables will be available to all sub-commands ran by make)
  2. Create another env variable, by looking at the current git commit and use it hash.
  3. Define all target(make commands) we want to use.
# Include env vars
include .env

# Export them all
export $(shell sed 's/#.*//g; /^$/d; s/=.*//' .env)

# For versioning
TAG_VERSION ?= $(shell git log --format="%h" -n 1)

# Pattern rule to build environment-specific containers
	docker compose -f docker-compose.yml -f docker-compose.$(ENVIRONMENT).yml build 

# Target to start environment-specific images
	docker compose -f docker-compose.yml -f docker-compose.$(ENVIRONMENT).yml up -d

	docker compose -f docker-compose.yml -f docker-compose.$(ENVIRONMENT).yml down

	docker compose -f docker-compose.yml -f docker-compose.$(ENVIRONMENT).yml logs -f


	docker push ${DOCKER_REPOSITORY}/${PROJECT_NAME}:latest

Now we have access to these commands:

# Build our image and tags it with: {GITHASH-ENVIRONMENTNAME}
$ make build

# Bings it up
$ make up

# ... and down
$ make down

# Shows log outup
$ make logs

# Push the current tag built by 'build'
$ make push

# Pushes a new tag 'latest' from our current built
$ make release

This was just a simple example on how you could optimize a little bit how you build your projects!

Here is a full project to try it out:

Note: Included a NodeJS project (just printing Hello-World) just to demonstrate a full project building flow

Related Posts
  • Fancy words in Tech Episode II: GraphQL

    It's been around for many years, and like other buzz-words many companies choose the tech just because "certain FANG company uses", then It must be good for my solution. Here i will try to summarize the most important key points of this technology, when and where is intended to be used and what a developer does when working on a project like this.

  • The SOLID Programming Principles OOP(s)!

    We can think of these as a general guide. There are many more, here are the ones I come up often, they are five and go by the acronym of S.O.L.I.D. The good thing about SOLID is that helps you decouple/breaking apart your code. Giving our modules independence of each other and make our code more maintainable, scalable, reusable and testable.

  • Working with Docker it's EASY!

    I haven't post in a while, and it's gonna be a good rant.... I mean, content! For the past decade we've been bombarded by new tech specially in the development area.... and lots; LOTSSSS of new fancy words to describe technology that came to this world to make our development lives easier, NOT HARD.

The comments are closed on this section.
Hire me!

I'm currently open for new projects or join pretty much any project i may fit in, let me know!

Read about what I do, or contact me for details.