DEV Community: Samuele Agostinelli

Automate your Builds on Docker Hub by Writing a Build Hook Script!

Samuele Agostinelli — Mon, 06 Apr 2020 01:23:18 +0000

Docker Hub is like Github for Docker images, making all our lives way easier.

Yet, it can quickly become a nightmare to maintaining multiple docker images. We don’t want to build the images manually each time we make a change to the Dockerfile. Also, we might want to support multiple variations of the same Docker image. For example, to support multiple node versions.

So good thing you’ve found this tutorial!

In the next few minutes, we will see how we can automate our builds by connecting our Docker Hub repo to a Github repo for automated builds. Finally, we’ll go deeper on the subject by exploring advanced options such as writing a build script that will give us complete control on the building process.

And you will then ascend to Docker Godhood!

Connecting a Github Repo to Docker Hub

The simplest way to automate your builds is to connect a Github repo containing a Dockerfile to your Docker Hub repo.

Here you can see I created a Github repo with a simple Dockerfile.
https://github.com/SamueleA/docker-hub-auto-build-tutorial
(ignore the build folder for now I will explain soon)

Configuring automated builds is quick and easy

Now, that you have a Github repo go to Docker Hub, click on your repo and, in the build tab, click on Configure Automated Builds.

Then, select your repo, fill the form and…that’s it!

When you will push a commit to your Github repo, Docker Hub will detect the commit and build a new image from your Dockerfile.

But that is still limiting, isn’t it?

What about the situation in which I have this Dockerfile that depends on a node version and maybe I want to support ALL the node versions, not just one. Maybe we could specify the node version in the docker tag. Do I then need to create multiple Dockfile? It would be so much easier if there was a way to only modify one Dockerfile and have that Dockerfile generate all the images for all the node versions…

That’s where build hooks come in.

Hooks: Complete Control on the Build Process!

So our goal is simple. We’ll have one Dockerfile and we will want to have it specify the node version through the docker tag, then Docker Hub will generate all the builds based on the tags.

For instance, my-image:node-10 will use node 10, my-image:node-11 will use node 11 and my-image:latest will use the latest version available.

We will need a build hook for that. The build hook will replace Docker Hub’s build process with our own by running a bash script.

Let’s start by creating a folder called hooks and a file called build inside that folder, just like in my example repo. Then copy the following code in the build file:

#!/bin/bash

NODE_VERSION=$(echo $DOCKER_TAG | cut -d "-" -f2)

if [ $DOCKER_TAG == "latest" ]
then
  docker build . --build-arg NODE_VERSION=${DOCKER_TAG} -t ${IMAGE_NAME}
else
  docker build . --build-arg NODE_VERSION=${NODE_VERSION} -t ${IMAGE_NAME}
fi

Build is a script written in bash, hence the first line of code. It reads the environment variable DOCKER_TAG and figures out the node version specified (just like we said we would by formatting our Docker tag in the format my-image:node-VERSION).

This DOCKER_TAG variable is set by Docker Hub itself. You can find a list of all the other environment variables made available by Docker Hub here.

Then, there’s an if statement. Basically, it’s to deal with the case when the docker tag is latest. In that case, we’ll simply use the latest node version. In any case, depending on the docker tag, we are going to pass an argument to our build with the –build-arg flag.

Now, if you look at the Dockerfile in my Github repo:

ARG NODE_VERSION

FROM node:$NODE_VERSION

We are calling the variable NODE_VERSION which we’ve just set earlier with the docker build command inside our build script!

Now, in the build settings on Docker Hub, all I’ll have to do is to set the name of the Docker tags according to our convention and all my images will build automatically! I can support pretty much any node version without the headache of maintaining multiple Dockerfile!

And here is my Docker Hub repo, if you want to see the final builds: https://hub.docker.com/repository/docker/samueleago/auto-build-tutorial

As you can imagine, the limit is your imagination at this point. You can have your build script do whatever you envision it to do! And if you are an amazing Bash scripter… knock yourself out with the amazing control it gives you!!

Automate Away!

Hopefully, this tutorial was useful to you and you can now automate your Docker Images for your projects!

Automate! Automate! Automate!

PS:
Consult the original article on my blog!
https://codeclimbing.com/automate-your-builds-on-docker-hub-by-writing-a-build-hook-script/

Docker for Newbz: Create a Docker Image for Your App!

Samuele Agostinelli — Mon, 30 Mar 2020 12:54:33 +0000

NOTE: See the original article here!

Every programmer dreads the phrase: “But it works on my machine!!!” Our poor developer now knows that he must now figure out what’s wrong among a bazillion things. “Okay, so what’s your OS? I hope there’s not a quirk with the OS. What about your node version? Maybe the app only works with this specific node version. Etc…”

Just thinking about it wakes up my problem-solving PTSD developed from many wasted hours trying to figure out what’s wrong with a setup.

And that’s where Docker comes in. Docker sets a common environment that never changes for us to run our app into. If it works on my machine with the Docker image… it will work on yours!

In this tutorial, we’ll create a simple create-react-application and then we’ll run it in a Docker Container.

Container? Image? Are you confused? You’re at the right place because this tutorial is for newbz with a z at the end.

Let’s get started.

Docker Image vs Docker Container

Just to clarify this real quick. A docker container is an instance of a docker image. In the same manner that a built house (container) is an instance of the architect’s plans (image).

Simple, right?

NEXT!

Making our First Image

I just want to say that in this tutorial I am assuming you have everything installed already. You should have Node.js, create-react-app and Docker. You’re a big boy. I know you can do that without me. Install all that and come back.

So to start, we’ll create a simple React application.

npx create-react-app my-app
cd my-app

Cool now we got a React application. Our goal with this tutorial will be to run “npm run start” and then see our web page while it runs in the container.

Now, we want to create a Docker Image. How do we do that? We must specify instructions to give to Docker on how to build the image. This is done in a Dockerfile.
Create an empty file inside the React application and call it “Dockerfile”.

Now, let’s fill that Dockerfile. The comment on top of the line will explain what it does

# This is the base image. In this case, we are taking a Linux image with node 11. This image is pulled from Docker Hub. https://hub.docker.com/_/node/
FROM node:11

# This will be the directory in which commands such as COPY and RUN will be run.
WORKDIR /app

#This means we copy everything in the current folder (our React application) into the folder defined previously in WORKDIR
COPY . .

# RUN means we run commands in the command line during build time. In this case, we have npm, because it is included in the base docker image. If we didn't have it, we'd have to use RUN to run commands to install node.
RUN npm install

# CMD defines a run-time operation. In this case we want to start the webserver
CMD ["npm", "run", "start"]

Did we make a mistake while creating our Dockerfile? Let’s try building our image!

docker build . -t my-app

The command above builds the image from the content of the Dockerfile (since I am assuming the current directory is the one containing the app). The argument “-t my-app” means we want to give our image the tag “my-app”, which will let us refer to our image more easily. After letting the build run, the command line shows:

Successfully built 82322ef0e172
Successfully tagged my-app:latest

That means success! “82322ef0e172” is the image id and “my-app” is the tag we defined above in the build command.

Remember the difference between IMAGE and CONTAINER describe above? Right now we have an image, not a container. We got the plans of the house, we just need to build it so our app can live in it!

docker run -dit -p 3000:3000 --name my-app --rm my-app

Let’s dissect the command above.
-dit : This will run our container in detached mode running in the background after execution of the commands in the Dockerfile. Without -dit, the container wouldn’t still be running. It would stop as soon as all the commands are run.

-p 3000: 3000 : This maps port 3000 on our local machine to port 3000 on our docker container. 3000 is the port that the create-react-app web server runs on by default.

–name my-app: This is the name we want to give to our container

–rm: This means we wants to delete the container once it has stopped running.

my-app: The name of the image that will serve as basis for the container

Now do:

docker ps

This will list all the running containers. You should be able to see a container name my-app alongside other information such as the container id.

The last step is to admire our final result. Go to http://localhost:3000 and you will see your app running!

Have fun!

Docker is an important technology to know about so I hope this was useful to you! Also, here is a github with the react app and dockerfile used in this tutorial: https://github.com/SamueleA/docker-tutorial