Skip to content
AImpact
IT EN
AI infrastructure 6 min read

Docker and containers explained simply: a practical guide for IT and sysadmins

What a container is, why it beats a VM for deploying AI services, and how to use Docker in practice. With real-world examples: Ollama, Open WebUI, Portainer.

Published: June 3, 2025

A container is like an executable ZIP file. Inside you have the program, its dependencies, its configuration. Move it from one server to another and it works exactly the same. No more “but it worked on my machine” — either it works, or there’s a real problem to solve.

That’s the promise Docker has delivered on since 2013. In 2025, deploying an AI service in a company without containers is like installing software by copying folders by hand: you can do it, but you’re making life harder than it needs to be.

VMs vs containers: the difference that matters

A VM is a complete virtual computer: it has its own kernel, its own OS, its own drivers. It weighs gigabytes, takes minutes to boot, and consumes RAM even when it’s doing nothing. It’s the right choice when you need strong isolation — multi-tenant environments, different OSes on the same host, security of the “this process must not be able to do anything outside the VM” variety.

A container shares the host system’s kernel and runs only the process you need, with its dependencies packaged inside. It starts in seconds, weighs megabytes, and you can run dozens of them on the same server without them stepping on each other. For the vast majority of services — web apps, APIs, internal tools, AI models — containers are the better choice.

The 4 commands you use every day

docker run -d -p 8080:80 nginx          # start nginx in background, port 8080
docker ps                               # see what's running
docker logs container_name              # read the logs
docker compose up -d                    # start a stack from docker-compose.yml

docker run downloads the image if you don’t have it, creates the container, and starts it. The -d flag sends it to the background. -p 8080:80 maps port 80 of the container to port 8080 on your server.

docker ps shows you the active containers with IDs, images, ports, and status. docker logs is your first debugging tool — if something isn’t working, check there first.

docker compose up -d is what you’ll use almost always in production: it reads a docker-compose.yml file and starts the entire stack defined in it.

docker-compose.yml in practice: Ollama + Open WebUI

This is a real stack you can deploy right now:

services:
  ollama:
    image: ollama/ollama
    volumes:
      - ollama_data:/root/.ollama
    ports:
      - "11434:11434"
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    ports:
      - "3000:8080"
    depends_on:
      - ollama
volumes:
  ollama_data:

Line by line: ollama is the service that runs AI models — it uses the ollama_data volume to persist downloaded models across restarts. open-webui is the ChatGPT-style web interface — it receives the environment variable telling it where to find Ollama (http://ollama:11434, which works because the two containers are on the same Docker network). depends_on ensures Ollama has started before launching the UI. The ollama_data volume is created automatically by Docker if it doesn’t exist.

To start:

docker compose up -d

Open your browser at http://localhost:3000, create the first account, and you have your own private ChatGPT running. Then download a model:

docker exec -it ollama_container_name ollama pull qwen2.5:7b

Portainer: managing containers without a terminal

If you manage containers for a team and not everyone wants to work on the command line, Portainer is the answer. It’s a web interface that shows containers, stacks, volumes, logs — everything clickable.

docker run -d -p 9443:9443 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  portainer/portainer-ce

Open https://localhost:9443, create the admin user, and you have a complete dashboard. Portainer Community Edition is free.

When not to use Docker

Docker isn’t the answer to everything. Avoid it or proceed with caution in these cases:

Production databases on shared storage: containers are born stateless, databases are the exact opposite. PostgreSQL or MySQL in Docker work, but they add a layer of complexity for backups, failover, and performance tuning. It’s fine for small environments, but in heavy production setups consider managed instances or a dedicated VM.

Complex direct hardware access: some GPU configurations, specialized USB devices, or capture cards don’t pass through to containers easily. Proxmox LXC with explicit cgroup configuration resolves a lot, but not everything.

Teams unfamiliar with containers: Docker isn’t difficult, but it does require some basic training. If the team doesn’t know what Docker images, volumes, and networks are, deploying containers to production without proper preparation creates problems that are hard to debug at the worst possible moment.

What to do

  • Install Docker on a test server and spin up the Ollama + Open WebUI stack with the compose shown above — it takes 5 minutes and immediately gives you something concrete to show.
  • Add Portainer to the same server: it makes management accessible to the whole IT team, not just those comfortable with the terminal.
  • Before moving containers to production, establish a backup policy for volumes — it’s the only stateful part and the one you lose if nobody thinks about it.