{"id":168784,"date":"2026-05-21T14:17:22","date_gmt":"2026-05-21T14:17:22","guid":{"rendered":"https:\/\/mycryptomania.com\/?p=168784"},"modified":"2026-05-21T14:17:22","modified_gmt":"2026-05-21T14:17:22","slug":"docker-in-2026-from-zero-to-production-ready-containers","status":"publish","type":"post","link":"https:\/\/mycryptomania.com\/?p=168784","title":{"rendered":"Docker in 2026: From Zero to Production-Ready Containers"},"content":{"rendered":"

A complete, no-fluff guide to containers, images, Dockerfiles, Compose, volumes, and networking with real Go + Gin + PostgreSQL examples.<\/strong><\/p>\n

Reading time:<\/em><\/strong> ~22 minutes <\/em>Level:<\/em><\/strong> Developer who knows Go, new to Docker <\/em>Stack used:<\/em><\/strong> Go (Gin framework) + PostgreSQL +\u00a0pgAdmin<\/em><\/p>\n

Table of\u00a0contents<\/h3>\n

Why Docker exists the problem it\u00a0solvesImages vs containers the distinction that\u00a0mattersDocker commands cheatsheetWriting your first DockerfileDocker Compose managing multiple containersVolumes and data persistenceDocker networkingPutting it all together your complete\u00a0project<\/p>\n

1. Why Docker exists the problem it\u00a0solves<\/h3>\n

Every Go developer has lived this moment: you write an API on your MacBook, it compiles and runs perfectly, you push to GitHub, and your teammate pulls it on their Linux workstation. go run main.go\u00a0panics.<\/p>\n

The database connection string that worked on your machine fails on theirs. The libc version is different. The environment variable you set in your\u00a0.zshrc six months ago and forgot about it’s not on their machine. The exact libpq version your PostgreSQL driver expects?\u00a0Wrong.<\/p>\n

Here is why this happens. When you build a Go application, it silently accumulates a set of environmental dependencies:<\/p>\n

A specific version of the Go toolchain (1.21, not 1.20, and definitely not\u00a01.19)The gcc compiler for CGO-dependent packagesSystem CA certificates for HTTPS calls to external\u00a0APIsEnvironment variables configured only in your local shell\u00a0profileThe exact libpq version your PostgreSQL driver\u00a0expects<\/p>\n

None of these are in your go.mod. They live invisibly on your\u00a0machine.<\/p>\n

Docker solves this by packaging your application together with its entire environment into a single portable unit called a container.<\/strong><\/p>\n

Instead of saying \u201chere is my code, good luck running it\u201d, you now ship: code + Go runtime + system libraries + configuration<\/em>, all bundled. Wherever that bundle runs your laptop, your teammate\u2019s Windows machine, a CI\/CD pipeline, a production server on AWS the behavior is identical.<\/p>\n

This is especially valuable in teams where onboarding a new developer used to mean half a day of \u201cinstall Go, configure PostgreSQL, set environment variables, hope glibc versions match.” With Docker, it becomes: docker compose up.\u00a0Done.<\/p>\n

2. Images vs containers\u200a\u2014\u200athe distinction that\u00a0matters<\/h3>\n

This is where most beginners get confused. Docker has two core entities and understanding their relationship is the foundation of everything else.<\/p>\n

Docker image<\/h3>\n

A Docker image is a read-only, static snapshot<\/strong> of what an environment should look like. It is not a running process. Think of it exactly like a struct definition in Go it holds the blueprint but does not allocate any runtime resources by\u00a0itself.<\/p>\n

Images are built from a file called a Dockerfile (covered in section 4). Once built, an image can be shared, versioned with tags, and stored in a registry like Docker\u00a0Hub.<\/p>\n

Docker container<\/h3>\n

A container is a running instance created from an image<\/strong>. Just as you instantiate a struct in Go, you instantiate containers from images. A single image can produce many containers simultaneously, each isolated from the\u00a0others.<\/p>\n

Image \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u25ba Container 1 (running)
\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u25ba Container 2 (running)
\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u25ba Container 3 (stopped)<\/p>\n

Key differences at a\u00a0glance<\/h3>\n

Property Image Container State Static, read-only Dynamic, has runtime state Resources No CPU\/RAM consumed Consumes CPU and RAM Mutability Immutable after build Writable layer on top of image Sharing Pushed\/pulled from registries Not directly shareable Go analogy struct type definition struct instance in\u00a0memory<\/p>\n

Image layers<\/h3>\n

Every image is composed of stacked, immutable layers. When Docker builds an image, each instruction in the Dockerfile creates a new layer. This layered architecture has a critical performance benefit: layers are cached and\u00a0shared<\/strong>.<\/p>\n

If you have two images both based on golang:1.21-alpine, Docker only stores that base layer once on your machine. When you pull the second image, it reuses the cached layer instead of downloading it again. This is why pulling a second Go-based image shows “Already exists” for several layers\u200a\u2014\u200athose layers are\u00a0shared.<\/p>\n

3. Docker commands cheatsheet<\/h3>\n

Before writing any Dockerfiles, you need to be fluent in the core CLI. Here is a complete reference with explanations for every\u00a0command.<\/p>\n

Working with\u00a0images<\/h3>\n

# Pull an image from Docker Hub
docker pull golang:1.21-alpine<\/p>\n

docker pull fetches an image from a registry to your local machine. The format is image_name:tag. If you omit the tag, Docker defaults to latest which can be unpredictable. Always specify a version tag for reproducibility.<\/p>\n

# List all locally available images
docker images<\/p>\n

Shows every image on your machine repository name, tag, image ID, creation date, and size. Watch the SIZE column: a Go binary built with multi-stage builds (section 4) drops from ~350 MB to ~25\u00a0MB.<\/p>\n

# Remove an image
docker rmi golang:1.21-alpine<\/p>\n

Deletes an image. Will fail if a container (even a stopped one) is still using it remove the container first.<\/p>\n

# Remove all dangling (untagged) images
docker image prune<\/p>\n

Cleans up <none>:<none> images left behind from failed or replaced builds. Run this periodically to reclaim disk\u00a0space.<\/p>\n

Working with containers<\/h3>\n

# Create and start a container from an image
docker run golang:1.21-alpine<\/p>\n

The most fundamental command. It pulls the image if not available locally, creates a container, and runs the default command. For golang:1.21-alpine, that default is go version the container prints it and exits immediately.<\/p>\n

# Run a container in detached (background) mode
docker run -d golang:1.21-alpine sleep 3600<\/p>\n

The -d flag detaches the container so it runs in the background. The sleep 3600 keeps it alive for an hour so you can inspect\u00a0it.<\/p>\n

# Run a container interactively with a shell
docker run -it golang:1.21-alpine sh<\/p>\n

-i keeps stdin open; -t allocates a pseudo-TTY. Together, -it gives you an interactive shell inside the container. Inside, try go version and cat \/etc\/os-release to see the isolated environment.<\/p>\n

# Run with port binding
docker run -d -p 8080:8080 my-gin-app<\/p>\n

-p host_port:container_port maps a port on your machine to a port inside the container. Without this, your Gin app running on port 8080 inside the container would be completely unreachable from your browser or\u00a0curl.<\/p>\n

# Run with an environment variable
docker run -d
-e DATABASE_URL=”host=localhost user=admin password=secret dbname=appdb port=5432 sslmode=disable”
my-gin-app<\/p>\n

-e sets an environment variable inside the container at runtime. Go applications read these with os.Getenv(). This is how you inject secrets and configuration without hardcoding them into the\u00a0image.<\/p>\n

# Give the container a human-readable name
docker run -d –name gin-api my-gin-app<\/p>\n

By default, Docker assigns a random name like peaceful_darwin. Using –name makes subsequent commands much\u00a0easier.<\/p>\n

# List running containers
docker ps# List ALL containers (including stopped)
docker ps -a# Stop a running container (graceful SIGTERM, then SIGKILL after 10s)
docker stop gin-api# Start a stopped container
docker start gin-api# Remove a stopped container
docker rm gin-api# Force-remove a running container
docker rm -f gin-api<\/p>\n

Inspecting and debugging<\/h3>\n

# View logs of a container
docker logs gin-api# Follow logs in real time
docker logs -f gin-api<\/p>\n

docker logs is your first stop when a container misbehaves. It captures everything the process wrote to stdout and stderr. For Gin, this includes HTTP request logs and panic stack\u00a0traces.<\/p>\n

# Execute a command inside a running container
docker exec -it gin-api sh<\/p>\n

docker exec runs an additional command inside an already running<\/strong> container you are not creating a new container, you are attaching to an existing one. Try env to see all environment variables, or cat \/etc\/resolv.conf to see DNS configuration.<\/p>\n

# Inspect detailed container metadata
docker inspect gin-api | jq ‘.[0].NetworkSettings’<\/p>\n

Returns a JSON payload covering network settings, volume mounts, environment variables, resource limits. Pipe through jq for readable\u00a0output.<\/p>\n

# Display real-time resource usage (CPU, memory, network I\/O)
docker stats<\/p>\n

Managing networks and\u00a0volumes<\/h3>\n

# List all Docker networks
docker network ls# Create a custom network
docker network create app-network# Remove a network
docker network rm app-network# List all volumes
docker volume ls# Create a named volume
docker volume create pg-data# Remove unused volumes
docker volume prune<\/p>\n

4. Writing your first Dockerfile<\/h3>\n

A Dockerfile is a plain text file containing instructions that Docker executes top-to-bottom to build your image. Each instruction creates a new\u00a0layer.<\/p>\n

The application we are dockerizing<\/h3>\n

A minimal Gin REST API that stores and retrieves users from PostgreSQL.<\/p>\n

main.go<\/strong><\/p>\n

package mainimport (
“net\/http”
“os”
“time” “github.com\/gin-gonic\/gin”
“gorm.io\/driver\/postgres”
“gorm.io\/gorm”
)type User struct {
ID uint `json:”id” gorm:”primaryKey”`
Name string `json:”name”`
Email string `json:”email”`
CreatedAt time.Time `json:”created_at”`
}var DB *gorm.DBfunc initDB() {
dsn := os.Getenv(“DATABASE_URL”)
if dsn == “” {
dsn = “host=localhost user=admin password=secret dbname=appdb port=5432 sslmode=disable”
}
var err error
DB, err = gorm.Open(postgres.Open(dsn), &gorm.Config{})
if err != nil {
panic(“failed to connect database: ” + err.Error())
}
DB.AutoMigrate(&User{})
}func main() {
initDB()
r := gin.Default() r.GET(“\/users”, func(c *gin.Context) {
var users []User
DB.Find(&users)
c.JSON(http.StatusOK, users)
}) r.POST(“\/users”, func(c *gin.Context) {
var user User
if err := c.ShouldBindJSON(&user); err != nil {
c.JSON(http.StatusBadRequest, gin.H{“error”: err.Error()})
return
}
DB.Create(&user)
c.JSON(http.StatusCreated, user)
}) r.Run(“:8080”)
}<\/p>\n

go.mod<\/strong><\/p>\n

module gin-docker-demogo 1.21require (
github.com\/gin-gonic\/gin v1.9.1
gorm.io\/driver\/postgres v1.5.4
gorm.io\/gorm v1.25.5
)<\/p>\n

The Dockerfile\u200a\u2014\u200awith multi-stage builds<\/h3>\n

Multi-stage builds are the most important Go-specific Docker technique. The core idea: use one stage to compile<\/em> the binary (needs the full Go toolchain), and a second stage to run<\/em> it (needs almost nothing). The final image only ships the compiled\u00a0binary.<\/p>\n

# \u2500\u2500 Stage 1: Build stage \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500
FROM golang:1.21-alpine AS builder<\/p>\n

FROM\u00a0… AS builder names this stage. golang:1.21-alpine is the official Go 1.21 image based on Alpine Linux (~350 MB). The AS builder alias lets us reference this stage’s filesystem in stage\u00a02.<\/p>\n

# Install build dependencies
RUN apk add –no-cache git ca-certificates<\/p>\n

Alpine uses apk as its package manager. –no-cache prevents storing the package index in the layer. git is needed for fetching some Go modules; ca-certificates enables HTTPS validation during go mod download.<\/p>\n

WORKDIR \/app<\/p>\n

Sets the working directory for all subsequent instructions. Think of it as cd \/app if the directory doesn’t exist, Docker creates\u00a0it.<\/p>\n

# Copy dependency files first \u2014 critical for layer caching
COPY go.mod go.sum .\/<\/p>\n

We copy go.mod and go.sum before<\/em> the source code. This is deliberate. Docker caches each layer if go.mod hasn’t changed, the next go mod download step will be served entirely from cache, saving 30-60 seconds on every\u00a0build.<\/p>\n

RUN go mod download<\/p>\n

Downloads all modules into the local module cache. Because this layer is cached, subsequent builds where only\u00a0.go files changed skip this step entirely.<\/p>\n

COPY . .<\/p>\n

Now we copy the application source. Changing\u00a0.go files only invalidates this layer and below not the expensive go mod download step\u00a0above.<\/p>\n

# Compile a fully static binary
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o main .<\/p>\n

This is the key compilation step for Go containers:<\/p>\n

CGO_ENABLED=0 disables CGO, producing a fully static binary<\/strong> with zero dynamic library dependenciesGOOS=linux targets Linux regardless of the build machine’s OS (important if you’re building on\u00a0macOS)-aforces rebuilding all packages for a clean static\u00a0result-installsuffix cgo keeps the build cache separate from CGO\u00a0builds-o mainoutputs the binary named\u00a0main<\/p>\n

The result: a single executable that runs anywhere without any runtime dependencies.<\/p>\n

# \u2500\u2500 Stage 2: Final minimal image \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500
FROM alpine:latest<\/p>\n

We start fresh from alpine:latest (~5 MB). No Go toolchain. No source code. No module cache. The final image will only contain what’s needed to run<\/em> the\u00a0binary.<\/p>\n

RUN apk –no-cache add ca-certificates
WORKDIR \/root\/<\/p>\n

Even a minimal image needs CA certificates for outbound HTTPS calls (payment APIs, webhooks, auth services).<\/p>\n

# Pull the compiled binary from stage 1
COPY –from=builder \/app\/main .<\/p>\n

–from=builder reaches into the filesystem of stage 1 and copies exactly one file the compiled main binary. That’s it. No source, no compiler, no temporary files.<\/p>\n

EXPOSE 8080
CMD [“.\/main”]<\/p>\n

EXPOSE 8080 documents which port the application listens on. CMD in exec form (JSON array) makes your binary PID 1 directly it receives OS signals correctly, enabling graceful shutdown when Docker sends\u00a0SIGTERM.<\/p>\n

Full Dockerfile<\/h3>\n

# Stage 1 \u2014 Build
FROM golang:1.21-alpine AS builder
RUN apk add –no-cache git ca-certificates
WORKDIR \/app
COPY go.mod go.sum .\/
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o main .# Stage 2 \u2014 Run
FROM alpine:latest
RUN apk –no-cache add ca-certificates
WORKDIR \/root\/
COPY –from=builder \/app\/main .
EXPOSE 8080
CMD [“.\/main”]<\/p>\n

Build and verify the size difference<\/h3>\n

# Build the image
docker build -t gin-app:1.0 .# See the dramatic size difference
docker images
# REPOSITORY TAG SIZE
# gin-app 1.0 ~25MB \u2190 multi-stage: tiny
# golang 1.21 ~350MB \u2190 full image: huge# Run a container
docker run -d
-p 8080:8080
-e DATABASE_URL=”host=localhost user=admin password=secret dbname=appdb port=5432 sslmode=disable”
–name gin-api
gin-app:1.0<\/p>\n

.dockerignore<\/h3>\n

# .dockerignore
*.md
.git\/
.env
.env.example
tmp\/
vendor\/<\/p>\n

Without this, Docker sends your entire project directory to the build daemon as the build context, slowing every build. With it, only the files Docker actually needs are transferred.<\/p>\n

5. Docker Compose\u200a\u2014\u200amanaging multiple containers<\/h3>\n

Running a single container with docker run is manageable. But a real application has multiple services a Go API, a PostgreSQL database, a monitoring UI. Running each with a long docker run command, keeping them on the same network, managing startup order this becomes painful\u00a0fast.<\/p>\n

Meet Rahul, a backend engineer who just joined your team. On his first day, he clones the repository and runs docker compose up -d. Three minutes later, he has a fully working local environment: the Gin API on port 8080, PostgreSQL on port 5432, pgAdmin on port 8081. No “install PostgreSQL” guide. No “configure your local environment” wiki page. One\u00a0command.<\/p>\n

Docker Compose<\/strong> makes this possible by letting you define your entire multi-container application in a single YAML\u00a0file.<\/p>\n

The docker-compose.yml file<\/h3>\n

services: # \u2500\u2500 Go\/Gin API \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500
api:
build: .
container_name: gin-api
ports:
– “8080:8080”
environment:
– DATABASE_URL=host=postgres user=admin password=secret dbname=appdb port=5432 sslmode=disable
– GIN_MODE=release
depends_on:
postgres:
condition: service_healthy # Wait until Postgres healthcheck passes
networks:
– app-network
restart: unless-stopped # \u2500\u2500 PostgreSQL database \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500
postgres:
image: postgres:15-alpine
container_name: pg-db
environment:
– POSTGRES_DB=appdb
– POSTGRES_USER=admin
– POSTGRES_PASSWORD=secret
ports:
– “5432:5432”
volumes:
– pg-data:\/var\/lib\/postgresql\/data
– .\/init.sql:\/docker-entrypoint-initdb.d\/init.sql
networks:
– app-network
healthcheck:
test: [“CMD-SHELL”, “pg_isready -U admin -d appdb”]
interval: 5s
timeout: 5s
retries: 5 # \u2500\u2500 pgAdmin (database UI) \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500
pgadmin:
image: dpage\/pgadmin4
container_name: pg-admin
environment:
– PGADMIN_DEFAULT_EMAIL=admin@admin.com
– PGADMIN_DEFAULT_PASSWORD=admin
ports:
– “8081:80”
networks:
– app-network
depends_on:
– postgresnetworks:
app-network:
driver: bridgevolumes:
pg-data:<\/p>\n

Breaking down the key\u00a0concepts<\/h3>\n

Service names as hostnames<\/strong> The key postgres under services automatically becomes a DNS hostname inside the Docker network. This is why DATABASE_URL uses host=postgresCompose resolves postgres to that container’s internal IP address. No hardcoded IPs\u00a0needed.<\/p>\n

depends_on with <\/strong>condition: service_healthy<\/strong> The plain depends_on only guarantees startup order<\/em>. With condition: service_healthy, Compose actually waits until the healthcheck on the postgres service passes before starting the api. This prevents the Go app from panicking on startup because the database isn’t ready\u00a0yet.<\/p>\n

healthcheck on postgres<\/strong>pg_isready -U admin -d appdb probes whether PostgreSQL is actually accepting connections, not just whether the process is running. It retries every 5 seconds up to 5\u00a0times.<\/p>\n

restart: unless-stopped<\/strong> If the api container crashes (e.g., a panic before the database is ready on a very slow machine), Docker restarts it automatically. Combined with the healthcheck condition, this makes the startup bulletproof.<\/p>\n

init.sql mount<\/strong> The official PostgreSQL image runs every\u00a0.sql file in \/docker-entrypoint-initdb.d\/ on first initialization. Mount your schema file there and your tables are created automatically.<\/p>\n

Core Compose\u00a0commands<\/h3>\n

# Start all services \u2014 builds images if needed
docker compose up -d# Show running services and their status
docker compose ps# Follow logs across all services
docker compose logs -f# Follow logs for a specific service only
docker compose logs -f api# Open a psql shell inside the running postgres container
docker compose exec postgres psql -U admin -d appdb# Rebuild the api image after code changes
docker compose up -d –build api# Stop services (containers preserved)
docker compose stop# Stop and remove containers + networks (volumes preserved)
docker compose down# Stop, remove containers + networks + volumes
docker compose down -v<\/p>\n

Environment variables and\u00a0.env\u00a0files<\/h3>\n

# .env \u2014 never committed to Git
POSTGRES_PASSWORD=my_strong_password
PGADMIN_PASSWORD=admin_password
DATABASE_URL=host=postgres user=admin password=my_strong_password dbname=appdb port=5432 sslmode=disable# .env.example \u2014 committed to Git, no real values
POSTGRES_PASSWORD=
PGADMIN_PASSWORD=
DATABASE_URL=host=postgres user=admin password= dbname=appdb port=5432 sslmode=disable# docker-compose.yml \u2014 references variables, not values
postgres:
environment:
– POSTGRES_PASSWORD=${POSTGRES_PASSWORD}<\/p>\n

New team members run cp\u00a0.env.example\u00a0.env, fill in their own values, and docker compose up -d. Clean, secure, repeatable.<\/p>\n

6. Volumes and data persistence<\/h3>\n

By default, a Docker container has a writable layer on top of its image. Any files your application writes database rows, uploaded files, logs live in this layer. The problem: when you remove the container with docker rm, that writable layer is permanently deleted. Every restart of your PostgreSQL container means an empty database.<\/p>\n

Volumes are Docker\u2019s solution to data persistence.<\/strong> They exist independently of any container\u2019s lifecycle.<\/p>\n

The three types of volume\u00a0mounts<\/h3>\n

1. Named volumes<\/strong>\u200a\u2014\u200arecommended for databases<\/p>\n

volumes:
– pg-data:\/var\/lib\/postgresql\/data<\/p>\n

Docker manages the storage location internally. You reference it by name. Named volumes are the preferred approach for persistent data because Docker handles creation, cleanup, and lifecycle you never need to know the exact host\u00a0path.<\/p>\n

docker volume create pg-data
docker volume inspect pg-data
# Shows the actual path: \/var\/lib\/docker\/volumes\/pg-data\/_data<\/p>\n

2. Bind mounts<\/strong>\u200a\u2014\u200arecommended for development<\/p>\n

volumes:
– .\/api:\/app<\/p>\n

Binds a host directory directly into the container. Changes on either side are instantly reflected on the other. Ideal during development edit a\u00a0.go file in your editor, and a tool like air (Go live reload) picks it up inside the container without rebuilding the\u00a0image.<\/p>\n

docker run -d
-v $(pwd)\/api:\/app
-p 8080:8080
gin-app:1.0<\/p>\n

3. Anonymous volumes<\/strong>\u200a\u2014\u200aephemeral temporary storage<\/p>\n

volumes:
– \/app\/tmp<\/p>\n

Docker assigns a random hex name. Removed when the container is removed. Used when you need temporary isolated storage that should not\u00a0persist.<\/p>\n

Verifying persistence<\/h3>\n

# Start the stack
docker compose up -d# Insert a user
curl -X POST http:\/\/localhost:8080\/users<\/a>
-H “Content-Type: application\/json”
-d ‘{“name”: “Alice”, “email”: “alice@example.com”}’# Verify
curl http:\/\/localhost:8080\/users<\/a>
# [{“id”:1,”name”:”Alice”,”email”:”alice@example.com”,”created_at”:”2026-05-20T10:30:00Z”}]# Tear down containers \u2014 volumes are preserved
docker compose down# Bring everything back up
docker compose up -d# Alice is still there
curl http:\/\/localhost:8080\/users<\/a>
# [{“id”:1,”name”:”Alice”,”email”:”alice@example.com”,”created_at”:”2026-05-20T10:30:00Z”}]<\/p>\n

Without the named volume, the second query returns an empty array. With it, Alice survives container deletion.<\/p>\n

# Clean up unused volumes
docker volume prune# Nuclear option \u2014 remove containers AND volumes
docker compose down -v<\/p>\n

7. Docker networking<\/h3>\n

Every container you run gets connected to a Docker network. Networking governs how containers communicate with each other, with your host machine, and with the outside\u00a0world.<\/p>\n

Default networks Docker\u00a0creates<\/h3>\n

docker network ls
# NETWORK ID NAME DRIVER SCOPE
# abc123 bridge bridge local
# def456 host host local
# ghi789 none null local<\/p>\n

bridge (default)<\/strong> Every container without an explicit network joins this. Containers can communicate by IP address but not<\/em> by name there is no automatic DNS. Always create custom bridge networks\u00a0instead.<\/p>\n

host<\/strong>The container shares the host’s network stack directly. No isolation the container’s port 8080 is<\/em> the host’s port 8080, no -p mapping needed. Useful for performance-sensitive scenarios but sacrifices isolation.<\/p>\n

none<\/strong>Complete isolation. No network interfaces except loopback. Used for batch containers that should have zero network\u00a0access.<\/p>\n

Custom bridge networks\u200a\u2014\u200aalways use\u00a0these<\/h3>\n

When containers share a custom bridge network, Docker provides automatic DNS resolution. Containers reach each other by service\u00a0name.<\/p>\n

# Create a custom network
docker network create app-network# Run postgres on it
docker run -d
–name postgres
–network app-network
-e POSTGRES_PASSWORD=secret
postgres:15-alpine# Run Gin app on the same network
# It reaches postgres using the hostname “postgres”
docker run -d
–name gin-api
–network app-network
-p 8080:8080
-e DATABASE_URL=”host=postgres user=admin password=secret dbname=appdb port=5432 sslmode=disable”
gin-app:1.0<\/p>\n

Container ports are internal by default. A Gin app on port 8080 inside a container is unreachable from your browser without explicit\u00a0binding.<\/p>\n

docker run -p 8080:8080 gin-app:1.0
# ^ ^
# host container# Bind a different host port if 8080 is taken
docker run -p 9090:8080 gin-app:1.0<\/p>\n

Critical rule:<\/strong> Two containers cannot bind the same host port. Starting a second container on port 8080 when one is already using it throws a \u201cport already allocated\u201d error. Each container needs a unique host port, even when their internal container ports are the\u00a0same.<\/p>\n

Inspecting networking<\/h3>\n

# See all containers on a network and their IPs
docker network inspect app-network# See which networks a container is on
docker inspect gin-api | jq ‘.[0].NetworkSettings.Networks’# Add a running container to an additional network
docker network connect app-network my-other-container# Remove it
docker network disconnect app-network my-other-container<\/p>\n

How Compose handles networking automatically<\/h3>\n

Compose creates a default bridge network named <project-name>_default and connects every service automatically. Service names become resolvable hostnames with no extra configuration.<\/p>\n

Declaring a custom network explicitly (as in section 5) is still recommended it gives a predictable name, makes intent clear, and lets you run docker network inspect app-network to debug connectivity issues.<\/p>\n

8. Putting it all together\u200a\u2014\u200ayour complete\u00a0project<\/h3>\n

After working through all seven sections, your project should be organized like\u00a0this:<\/p>\n

gin-docker-demo\/
\u251c\u2500\u2500 main.go
\u251c\u2500\u2500 go.mod
\u251c\u2500\u2500 go.sum
\u251c\u2500\u2500 Dockerfile
\u251c\u2500\u2500 docker-compose.yml
\u251c\u2500\u2500 .env \u2190 not committed to Git
\u251c\u2500\u2500 .env.example \u2190 template for new developers
\u251c\u2500\u2500 .dockerignore
\u2514\u2500\u2500 init.sql \u2190 database initialization script<\/p>\n

init.sql<\/strong><\/p>\n

CREATE TABLE IF NOT EXISTS users (
id SERIAL PRIMARY KEY,
name VARCHAR(100) NOT NULL,
email VARCHAR(255) UNIQUE NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);<\/p>\n

Mounted into docker-entrypoint-initdb.d\/, PostgreSQL runs this automatically on first startup. Your schema is always ready before the Go app connects.<\/p>\n

The complete developer workflow<\/h3>\n

# Clone on any machine
git clone https:\/\/github.com\/you\/gin-docker-demo
cd gin-docker-demo# Set up environment variables
cp .env.example .env
# Fill in POSTGRES_PASSWORD and DATABASE_URL in .env# Build images and start everything
docker compose up -d –build# Verify all services are healthy
docker compose ps# Watch the Go app logs \u2014 confirm it connected to PostgreSQL
docker compose logs -f api
# [GIN-debug] Listening and serving HTTP on :8080
# [GIN] 200 | GET \/users# Test the API
curl http:\/\/localhost:8080\/users<\/a># Open pgAdmin
# http:\/\/localhost:8081<\/a>
# Login: admin@admin.com \/ admin
# Add server: host=postgres, port=5432, user=admin, password=<from .env># Rebuild after code changes (only the api service)
docker compose up -d –build api# Done for the day
docker compose stop# Full cleanup \u2014 containers and networks removed, volumes preserved
docker compose down<\/p>\n

Quick reference card<\/h3>\n

Final thoughts<\/h3>\n

Docker has gone from a niche DevOps tool to a baseline expectation in professional software development. The mental model shift it demands from \u201csoftware installed on a machine\u201d to \u201csoftware packaged with its environment\u201d is the only real hurdle. Once that clicks, the rest follows naturally.<\/p>\n

The five principles to internalize:<\/strong><\/p>\n

Images are blueprints. Containers are instances.<\/strong> One image, many containers just like a struct type and its instances.Layers are your cache.<\/strong> Order Dockerfile instructions from least to most frequently changed. Dependencies before source code,\u00a0always.Multi-stage builds are non-negotiable for Go.<\/strong> CGO_ENABLED=0 + a scratch or alpine final stage takes you from 350 MB to 25\u00a0MB.Networks are how containers talk.<\/strong> Always use custom bridge networks. Service names resolve automatically in\u00a0Compose.Volumes are how data survives.<\/strong> Named volumes for databases, bind mounts for development hot-reload.<\/p>\n

Master these five principles and you have everything you need to containerize any Go application, eliminate \u201cworks on my machine\u201d incidents, and hand your project to any pipeline CI\/CD, staging, or production with confidence.<\/p>\n

Found this useful? Share it with a Go developer who is still manually installing PostgreSQL. They will thank\u00a0you.<\/em><\/p>\n

Docker in 2026: From Zero to Production-Ready Containers<\/a> was originally published in Coinmonks<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>","protected":false},"excerpt":{"rendered":"

A complete, no-fluff guide to containers, images, Dockerfiles, Compose, volumes, and networking with real Go + Gin + PostgreSQL examples. Reading time: ~22 minutes Level: Developer who knows Go, new to Docker Stack used: Go (Gin framework) + PostgreSQL +\u00a0pgAdmin Table of\u00a0contents Why Docker exists the problem it\u00a0solvesImages vs containers the distinction that\u00a0mattersDocker commands cheatsheetWriting […]<\/p>\n","protected":false},"author":0,"featured_media":168785,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-168784","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-interesting"],"_links":{"self":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/168784"}],"collection":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=168784"}],"version-history":[{"count":0,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/168784\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/media\/168785"}],"wp:attachment":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=168784"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=168784"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=168784"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}