How to Build and Test Your Docker Images in the Cloud with Docker Hub

In of this series, we took a look at installing Docker Desktop, building images, configuring our b

In of this series, we took a look at installing Docker Desktop, building images, configuring our builds to use build arguments, running our application in containers, and finally, we took a look at how Docker Compose helps in this process.  In this article, we’ll walk through deploying our code to the cloud, how to use Docker Hub to build our images when we push to GitHub and how to use Docker Hub to automate running tests. Docker Hub is the easiest way to create, manage, and ship your team’s images to your cloud environments whether on-premises or into a public cloud. This first thing you will want to do is create a , if you do not already have one, and . Once you’re logged in, let’s create a couple of repos where we will push our images to. Click on “Repositories” in the main navigation bar and then click the “Create Repository” button at the top of the screen. You should now see the “Create Repository” screen. You can create repositories for your account or for an organization. Choose your Docker ID from the dropdown. This will create the repository for your Docker ID. Now let’s give our repository a name and description. Type in the name field and a short description such as: We also have the ability to make the repository Public or Private. Let’s keep the repository Public for now. We can also connect your repository to a source control system. You have the option to choose GitHub or Bitbucket but we’ll be doing this later in the article. So, for now, do not connect to a source control system.  Go ahead and click the “Create” button to create a new repository. Your repository will be created and you will be taken to the General tab of your new repository. This is the repository screen where we can manage tags, builds, collaborators, webhooks, and visibility settings. Click on the Tags tab. As expected, we do not have any tags at this time because we have not pushed an image to our repository yet. We also need a repository for your services application. Follow the previous steps and create a new repository for the application. Use the following settings to do so: Repository name: Description: Visibility: Build Settings: Excellent. We now have two Docker Hub Repositories setup. For simplicity in part 1 of this series, we only had one git repository. For this article, I refactored our project and broke them into two different git repositories to more align with today’s microservices world. Now let’s build our images and push them to the repos we created above. Open your favorite browser and navigate to the repository. Create a copy of the repo in your GitHub account by clicking the “Fork” button in the top right corner. Repeat the processes for the repository. Open a terminal on your local development machine and navigate to wherever you work on your source code. Let’s create a directory where we will clone our repos and do all our work in. Now let’s clone the two repositories you just forked above. Back in your browser click the green “Clone or download” button and copy the URL. Use these URLs to clone the repo to your local machine. (Remember to substitute your GitHub ID for in the above commands) If you have SSH keys set up for your github account, you can use the SSH URLs instead. Let’s take a look at the list of Docker images we have locally on our machine. Run the following command to see a list of images. You can see that I have the , and images on my machine. If you do not see the above images, that’s okay, we are going to recreate them now. Let’s first remove and images. We’ll use the remove image (rmi) command. You can skip this step if you do not have the and on your local machine. If you get the following or similar error: This means that the image you are trying to remove is being used by a container and can not be removed. You need to and (remove) the container before you can remove the image. To do so, run the following commands. First, find the running container: Here we can see that the container named is using the image which we are trying to remove.  Let’s stop and remove this container. We can do this at the same time by using the option to the command.  If we tried to remove the container by using without first stopping it, we would get the following error: So we’ll use the option to tell Docker to send a to the container and then remove it. Do the same for the UI container, if it is still running. Now that we stopped and removed the containers, we can now remove the images. Let’s list our images again. Now you should see that the and images are gone. Let’s build our images for the UI and Services projects now. Run the following commands: If you would like a more in-depth discussion around building images and Dockerfiles, refer back to of this series. Okay, now that we have our images built, let’s take a look at pushing them to Docker Hub. If you look back at the beginning of the post where we set up our Docker Hub repositories, you’ll see that we created the repositories in our Docker ID namespace. Before we can push our images to Hub, we’ll need to tag them using this namespace. Open your favorite browser and navigate to and let’s review real quick. Login to Hub, if you’ve not already done so, and take a look at the dashboard. You should see a list of images. Choose your Docker ID from the dropdown to only show images associated with your Docker ID. Click on the row for the repository.  Towards the top right of the window, you should see a docker command highlighting in grey. This is the Docker Push command followed by the image name. You’ll see that this command uses your Docker ID followed by a slash followed by the image name and tag, separated by a colon. You can read more about to repositories and images in our documentation. Let’s tag our local images to match the Docker Hub Repository. Run the following commands anywhere in your terminal. (Remember to substitute your Docker ID for in the above commands) Now list your local images and see the newly tagged images. Okay, now that we have our images tagged correctly, let’s push our images to Hub. The first thing we need to do is make sure we logged into Docker Hub on the terminal. Although the repositories we created earlier are “public”, only the owner of the repository can push by default. If you would like to allow folks on your team to be able to push images and manage repositories. Take a look at and Teams in Hub. Enter your username (Docker ID) and password. Now we can push our images. Open your favorite browser and navigate to , select one of the repositories we created earlier and then click the “Tags” tab. You will now see the images and tag we just pushed. That was pretty straightforward but we had to run a lot of manual commands. What if we wanted to build an image, run tests and publish to a repository so we could deploy our latest changes? We might be tempted to write a shell script and have everybody on the team run it after they completed a feature. But this wouldn’t be very efficient.  What we want is a continuous integration (CI) pipeline. Docker Hub provides these features using and Docker Hub can be connected to GitHub and Bitbucket to listen to push notifications so it can trigger AutoBuilds. I’ve already connected my Hub account to my GitHub account. To connect your own Hub account to your version control system follow these simple steps in our . Let’s set up AutoBuilds for our two repositories. The steps are the same for both repositories so I’ll only walk you through one of them. Open in your browser, and navigate to the detail page for the repository. Click on the “Builds” tab and then click the “Link to GitHub” button in the middle of the page. Now in the Build Configuration screen. Select your organization and repository from the dropdowns. Once you select a repository, the screen will expand with more options. Leave the AUTOTEST setting to Off and the REPOSITORY LINKS to Off also. The next thing we can configure is Build Rules. Docker Hub automatically configures the first BUILD RULE using the master branch of our repo. But we can configure more. We have a couple of options we can set for build rules.  The first is Source Type which can either be a Branch or a Tag.  Then we can set the Source, this is referring to either the Branch you want to watch or the Tag name you would like to watch. You can enter a string literal or a RegExp that will be used for matching. Next, we’ll set the Docker Tag that we want to use when the image is built and tagged. We can also tell Hub what Dockerfile to use and where the Build Context is located. The next option turns off or on the Build Rule. We also have the option to use the Build Cache. We’ll leave the default Build Rule that Hub added for us. Click the “Save and Build” button. Our Build options will be saved and an AutoBuild will be kicked off. You can watch this build run on the “Builds” tab of your image page. To view the build logs, click on the build that is in progress and you will be taken to the build details page where you can view the logs. Once the build is complete, you can view the newly created image by clicking on the “Tags” tab. There you will see that our image was built and tagged with “latest”. Follow the same steps to set up the repository.  Now that we see that our image is being built, let’s make a change to our project and trigger it from command. Open the file in your favorite editor and add the following code snippet anywhere before the line at the bottom of the file. Save the file and commit the changes locally. Now, if we push the changes to GitHub, GitHub will trigger a webhook to Docker Hub which will in turn trigger a new build of our image. Let’s do that now. Navigate over to Hub in your browser and scroll down. You should see that a build was just triggered. After the build finishes, navigate to the “Tags” tab and see that the image was updated. Excellent! We now have both our images building when we push to our source control repo. But this is just step one in our CI process. We should only push new images to the repository if all tests pass. Docker Hub will automatically run tests if you have a file that defines a service. Let’s create this now and run our tests. Open the project in your editor and create a new file name: and add the following yaml. Commit the changes and push to GitHub. Now navigate back to Hub and the repo. Once the build finishes, click on the build link and scroll to the bottom of the build logs. There you can see that the tests were run and the image was pushed to the repo. If the build fails, you will see that the status turns to FAILURE and you will be able to see the error in the build logs. In part 2 of this series, we showed you how is one of the easiest ways to automatically build your images and run tests without having to use a separate CI system. If you’d like to go further you can take a look at: