Why I Started Using Docker
I don’t remember which Docker version I started with. What I do remember is the appeal of being able to put a project’s services and settings in a file I could come back to later. With web projects, I wanted to spend the evening working on the site instead of remembering which packages and ports I’d set up the last time.
Vagrant is useful when I need a whole Linux machine to work with. Docker appealed to me for a smaller job. If all I need is a web server for a static site, I can define the image, choose a local port, and point it at a directory of files. When a project grows to need another service, I can describe how those services fit together in Compose.
A small example of what sold me on it
With Docker and the Compose plugin installed, make a new project directory with this layout:
docker-web-lab/
compose.yaml
site/
index.html
Put any short HTML page in site/index.html. Save this as compose.yaml:
services:
web:
image: nginx:alpine
ports:
- "127.0.0.1:8080:80"
volumes:
- ./site:/usr/share/nginx/html:ro
From the project directory, start the service and request the page:
docker compose up -d
curl --fail http://127.0.0.1:8080/
You should see the contents of your HTML file. Edit the file and run curl again. Nginx reads it from the mounted directory, so a change to the page does not require rebuilding the image. The port binding limits this example to the local machine. If port 8080 is busy, change the host-side port in the mapping and use the same port in curl.
If the request fails, run docker compose ps to see whether the service started and docker compose logs web to read its logs. When you’re done, docker compose down removes the example container and its Compose network. The HTML stays in your local site directory.
That little setup explains why I kept coming back to Docker. I can open the project later and see where the server comes from, what it serves, and how to start it. For a shared project, I’d pin a specific image version or digest so a fresh pull uses the intended build.