Docker

Every call to a hosted LLM API sends your prompt to someone else’s server and bills you per token. Lose the network and it stops answering. Ollama takes both problems out of the loop: it pulls an open-weight model onto your machine and serves it over a REST API on localhost:11434. One binary is the model manager, the chat client, and the server. What Ollama actually does Ollama wraps llama.cpp and similar inference engines so you never touch a compiler flag or a CUDA library path. ollama pull llama3.2 fetches a quantized model file (GGUF format) from Ollama’s own registry rather than from Hugging Face, though it can import GGUF files from there too. Running the model hands those weights to a background server, which loads them into RAM (or VRAM, if it finds a compatible GPU), keeps them resident for a few minutes after your last request so the next one is fast, and unloads them once you stop asking. ...

docker build && docker push from your laptop works until someone else has to ship the same image, or it has to happen on every merge without you at the keyboard. GitHub Actions runs that build on GitHub’s runners, tags the image from whatever triggered the workflow, and pushes it to a registry your deploy step can pull from. Nothing runs locally. What it takes to build and push a Docker image from CI Five pieces have to be in place before a runner can push an image: ...

Where a container’s environment variables end up Start a container with -e DB_PASSWORD=hunter2 and run docker inspect on it: 1 2 docker run -d --name api -e DB_PASSWORD=hunter2 nginx:alpine docker inspect --format '{{json .Config.Env}}' api 1 ["DB_PASSWORD=hunter2","PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"] The password sits there in plain text, readable by anyone with access to the Docker socket, by docker exec api env, and by any process running inside the container. That is not a bug — it is what environment variables are for. The problem is using them for values that should never be that visible. ...

Why a Docker image ends up ten times bigger than the app A Node service with a few hundred kilobytes of source code ships as an image over 1 GB. That is the normal outcome of a working build, not a mistake anyone made on a particular line. The weight comes from a base image carrying a full OS, a build toolchain the running app never calls, and a package manager cache nobody told the build to delete. ...

What a bad Dockerfile costs you 1 2 3 4 5 6 FROM node:latest COPY . . RUN npm install CMD ["node", "server.js"] Four lines, and every one of them costs you something. docker build re-runs npm install on every code change, because COPY . . breaks the layer cache before the install step ever gets a chance to be reused. The final image carries the full Debian base, the entire node_modules tree including dev dependencies, and whatever build tools npm install pulled in to compile native modules. Nothing is discarded. The container runs as root, because nothing tells it not to, and node:latest means the base image can change under you between one build and the next, with no record of what you actually shipped. ...

Why two containers on the same host can’t reach each other by default Start Postgres and your API with plain docker run and the API cannot reach the database, even though both containers sit on the same machine. 1 2 docker run -d --name db postgres:16 docker run -d --name api myapp Both land on Docker’s default bridge network, where every Docker container goes unless you say otherwise. They get IP addresses. What they don’t get is any way to find each other by name, so the API would have to hardcode the database’s internal IP — an address that changes every time the container restarts. ...

The problem Compose solves A real application is rarely one container. A web API needs a database, the database needs a volume so its data survives a restart, and then you add a Redis cache and a background worker. That is four docker run commands, each with its own flags for ports, volumes, environment variables and a shared network. In the right order. Every time you sit down to work. ...

Docker and Podman run the same images with the same commands. What separates them is architecture: Podman has no background daemon and runs rootless by default, while Docker brings the mature tooling, Docker Desktop, and first-class Compose. Below, the differences that actually affect your work — daemon, root, Compose, and pods. What is Podman? Podman (Pod Manager) is a tool for managing containers and pods, developed by Red Hat as an open source alternative to Docker. Its main feature? It doesn’t need a daemon running. ...

Why a container loses its data when it restarts Write a row to a database running in a Docker container, stop the container, start it again: the row is gone. Every container gets its filesystem fresh from its image each time it starts. Anything the container itself writes — database files, uploads, logs — goes into a writable layer that is thrown away when the container is removed. A Docker volume is how you keep that data outside the container, where it survives. ...

What Docker actually does Docker is an open source platform that packages an application with everything it needs to run — code, libraries, runtime, configuration — into a container that behaves the same on any machine. Moving house makes the trade-off concrete. You have two options: Carry all your belongings loose, hoping they arrive intact Put everything in organized, labeled boxes that are easy to move Docker does exactly this with software applications: it “packages” them into containers that contain everything they need to run. ...