Skip to main content
IT BIBLESign in

Blog / Hypervisor

Docker for Beginners: Pull, Clone and Build Your First Containers

This guide walks through three ways to get a container running: pulling a ready-made image from Docker Hub, using a project hosted on GitHub, and building an image yourself from a Dockerfile. By the e...

WizardTux
· 4 min read · Hypervisor
Docker for Beginners: Pull, Clone and Build Your First Containers

Photo by Matt Wang on Unsplash

This guide walks through three ways to get a container running: pulling a ready-made image from Docker Hub, using a project hosted on GitHub, and building an image yourself from a Dockerfile. By the end you will know the core commands and the difference between an image and a container.

What Docker gives you

Docker packages an application and its dependencies into an image. A running instance of that image is a container. The image is the template, and the container is the live process created from it. You can start many containers from one image.

Three terms come up constantly:

  • Image: a read-only template built in layers.
  • Container: a running (or stopped) instance of an image.
  • Registry: a server that stores images. Docker Hub is the default one, and GitHub offers its own, the GitHub Container Registry.

Containers share the host kernel, so they start quickly and use fewer resources than full virtual machines. They are also less isolated than VMs, which is worth remembering as you go deeper.

Before you start

Install Docker Engine (Linux) or Docker Desktop (Windows and macOS) by following the official instructions for your platform. Then confirm it works:

docker version
docker run hello-world

The second command pulls a tiny test image and runs it. If it prints a greeting, the client, daemon and registry connection are all working.

On Linux, you may need to run Docker commands with sudo unless your user is in the docker group. Be aware that membership in that group is effectively root-level access on the host.

You will also need Git for the GitHub example.

Example 1: Run an image from Docker Hub

Docker Hub is where most people start. We will use the official nginx web server image.

Pull the image:

docker pull nginx

With no tag specified, Docker uses latest. For anything you care about, pin a specific tag so your setup is repeatable.

Now run it:

docker run -d --name web -p 8080:80 nginx

What each part does:

  • -d runs the container in the background (detached).
  • --name web gives it a readable name instead of a random one.
  • -p 8080:80 maps port 8080 on your host to port 80 inside the container.

Test it:

curl http://localhost:8080

You should see the default nginx welcome page HTML. A few commands you will use daily:

docker ps            # list running containers
docker ps -a         # include stopped containers
docker logs web      # view output from the container
docker stop web      # stop it
docker rm web        # remove it

If port 8080 is already in use on your machine, pick a different host port, such as -p 8081:80.

Example 2: Use a project from GitHub

GitHub usually plays one of two roles with Docker. Either the project publishes a prebuilt image, or it ships source code with a Dockerfile that you build yourself.

Option A: Pull a published image

Some projects publish images to the GitHub Container Registry, whose addresses start with ghcr.io. The project's README normally gives the exact image name. The pattern looks like this:

docker pull ghcr.io/OWNER/IMAGE:TAG
docker run -d --name myapp -p 8080:80 ghcr.io/OWNER/IMAGE:TAG

Replace OWNER, IMAGE and TAG with the values from the project's documentation. Port numbers and required options vary by project, so read the README before running anything.

Option B: Clone and build

If the repository contains a Dockerfile, you can build the image locally:

git clone https://github.com/OWNER/REPO.git
cd REPO
ls
docker build -t repo-local .
docker run -d --name repo-test repo-local

The -t flag tags the image with a name. The trailing . tells Docker to use the current directory as the build context, which is where it looks for the Dockerfile and the files it copies.

Some projects use Docker Compose instead, with a compose.yaml or docker-compose.yml file. In that case the README will tell you to run docker compose up.

A note on trust: a Dockerfile and the image it produces can run arbitrary code. Skim the Dockerfile and check the project's reputation before you build and run something from an unfamiliar repository.

Example 3: Build your own image locally

Now build an image from scratch. We will serve a single HTML page with nginx.

Create a project directory and a page:

mkdir hello-site
cd hello-site
cat > index.html <<'EOF'
<h1>Hello from my first image</h1>
EOF

Create a file named Dockerfile (no extension) in the same directory:

FROM nginx:alpine
COPY index.html /usr/share/nginx/html/index.html

These two lines do all the work:

  • FROM picks the base image. The alpine variant is a smaller build of nginx.
  • COPY places your file inside the image, replacing the default page.

Build and tag the image:

docker build -t hello-site:1.0 .

Run a container from it:

docker run -d --name hello -p 8081:80 hello-site:1.0
curl http://localhost:8081

You should see your heading. Edit index.html, rebuild with a new tag such as hello-site:1.1, and run it again to see how the build-and-run cycle works.

List your images with:

docker images

You will see nginx, nginx:alpine, hello-site and any others you pulled or built. Docker caches layers, so rebuilds that change only the last step finish quickly.

Cleaning up

Test containers and images pile up. Remove what you created in this guide:

docker rm -f web hello repo-test
docker image rm hello-site:1.0 repo-local nginx

You can remove unused data in bulk with docker system prune, but read its confirmation prompt first. It deletes stopped containers and dangling images, and options like -a remove much more.

Next steps

You have now pulled an image from a registry, used a project from GitHub, and built your own image. From here, the most useful topics to learn are:

  1. Volumes, so data survives when a container is removed.
  2. Networks, so containers can talk to each other by name.
  3. Docker Compose, to define multi-container setups in one file.
  4. Environment variables, to configure containers without rebuilding images.

Pick a small service you already run at home, find its image, and move it into a container. That is the fastest way to make these commands stick.

Share

Sign in to comment.