DEV Community: Suleiman Dibirov

Docker Model Runner: Running AI Models Locally

Suleiman Dibirov — Sat, 12 Apr 2025 05:36:30 +0000

Docker has released an interesting new feature in beta that should interest anyone working with generative AI. Docker Model Runner allows you to load, run, and manage AI models directly on your local computer without the need to configure complex infrastructure.

What is Docker Model Runner and why do you need it?

Docker Model Runner is a plugin for Docker Desktop that significantly simplifies working with AI models.

The feature is currently in beta testing, available in Docker Desktop version 4.40 and above, and is currently only supported on Macs with Apple Silicon processors.

The plugin allows you to:

Download models from Docker Hub (from the 'ai' namespace)
Run AI models directly from the command line
Manage local models (add, view, remove)
Interact with models through specified prompts or in chat mode

One of the key advantages of Docker Model Runner is the optimization of resource usage. Models are downloaded from Docker Hub only on first use and stored locally. They are loaded into memory only during query execution and unloaded when not in use. Since modern AI models can be quite large, the initial download may take some time, but they are then cached locally for quick access.

Another important advantage is the support for OpenAI-compatible APIs, which significantly simplifies integration with existing applications.

Basic Docker Model Runner Commands

Checking status

$ docker model status
Docker Model Runner is running

Viewing available commands

$ docker model help
Usage:  docker model COMMAND

Docker Model Runner

Commands:
  inspect     Display detailed information on one model
  list        List the available models that can be run with the Docker Model Runner
  pull        Download a model
  rm          Remove a model downloaded from Docker Hub
  run         Run a model with the Docker Model Runner
  status      Check if the Docker Model Runner is running
  version     Show the Docker Model Runner version

Run 'docker model COMMAND --help' for more information on a command.

Downloading a model

$ docker model pull ai/smollm2
Downloaded: 0.00 MB
Model ai/smollm2 pulled successfully

During the download it shows the correct size, but after downloading it shows 0.00 MB, but as I mentioned above, this feature is still in beta testing.

Viewing local models

Example output:

$ docker model list
MODEL       PARAMETERS  QUANTIZATION    ARCHITECTURE  MODEL ID      CREATED      SIZE
ai/smollm2  361.82 M    IQ2_XXS/Q4_K_M  llama         354bf30d0aa3  2 weeks ago  256.35 MiB

Running a model

With a one-time prompt:

$ docker model run ai/smollm2 "Hello"

In dialogue mode:

$ docker model run ai/smollm2

Removing a model

$ docker model rm ai/smollm2

Integrating Docker Model Runner into your applications

Docker Model Runner provides OpenAI-compatible API endpoints, making it easy to integrate with existing applications. Here's an example of calling the chat/completions endpoint from a container:

#!/bin/sh

curl http://model-runner.docker.internal/engines/llama.cpp/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "ai/smollm2",
        "messages": [
            {
                "role": "system",
                "content": "You are a helpful assistant."
            },
            {
                "role": "user",
                "content": "Write 500 words about the fall of Rome."
            }
        ]
    }'

You can also use Docker Model Runner from the host via the Docker socket:

#!/bin/sh

curl --unix-socket $HOME/.docker/run/docker.sock \
    localhost/exp/vDD4.40/engines/llama.cpp/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "ai/smollm2",
        "messages": [
            {
                "role": "system",
                "content": "You are a helpful assistant."
            },
            {
                "role": "user",
                "content": "Write 500 words about the fall of Rome."
            }
        ]
    }'

Quick start with a GenAI application example

If you want to quickly try Docker Model Runner with a ready-made generative AI application, follow these steps:

Clone the example repository:

   $ git clone https://github.com/docker/hello-genai.git

In the terminal, navigate to the hello-genai directory.
Run run.sh to download the selected model and launch the application.
Open the application in your browser at the address specified in the repository's README.

Available API endpoints

After enabling Docker Model Runner, the following APIs are available:

Inside containers

http://model-runner.docker.internal/

# Model management
POST /models/create
GET /models
GET /models/{namespace}/{name}
DELETE /models/{namespace}/{name}

# OpenAI-compatible endpoints
GET /engines/llama.cpp/v1/models
GET /engines/llama.cpp/v1/models/{namespace}/{name}
POST /engines/llama.cpp/v1/chat/completions
POST /engines/llama.cpp/v1/completions
POST /engines/llama.cpp/v1/embeddings

Note: You can also omit llama.cpp.
For example, POST /engines/v1/chat/completions.

Inside or outside containers (on the host)

The same endpoints on /var/run/docker.sock

# While the feature is in beta
With the prefix /exp/vDD4.40

Known issues

The docker model command is not recognized

If you get the error:

docker: 'model' is not a docker command

This means that Docker cannot find the plugin. Solution:

$ ln -s /Applications/Docker.app/Contents/Resources/cli-plugins/docker-model ~/.docker/cli-plugins/docker-model

No protection against running excessively large models

Currently, Docker Model Runner does not include protection against running models that exceed available system resources. Attempting to run a model that is too large can lead to serious slowdowns or temporary system inoperability.

Errors with failed downloads

If the model download fails, the docker model run command may still launch the chat interface, although the model is actually unavailable. In this case, it is recommended to manually repeat the docker model pull command.

How to enable or disable the feature

Docker Model Runner is enabled by default in Docker Desktop. If you want to disable this feature:

Open Docker Desktop settings
Go to the Beta tab in the Features in development section
Uncheck Enable Docker Model Runner
Click Apply & restart

If you don't see the Enable Docker Model Runner checkbox, then enable experimental features.

Conclusion

Docker Model Runner provides a convenient way to work with AI models locally, which is especially useful for developers who want to experiment with generative AI without the need to connect to cloud APIs or configure complex infrastructure.

The feature is in beta, so some issues may arise, but Docker is actively working on fixing them and accepts feedback through the Give feedback link next to the Enable Docker Model Runner setting.

If you're working with generative AI or just want to try local models without unnecessary complications, Docker Model Runner is a great tool worth adding to your arsenal.

[Boost]

Suleiman Dibirov — Sat, 07 Dec 2024 10:58:48 +0000

A Beginner's Guide to Docker Health Checks and Container Monitoring

Suleiman Dibirov ・ Dec 7

#docker #devops #webdev #programming

A Beginner's Guide to Docker Health Checks and Container Monitoring

Suleiman Dibirov — Sat, 07 Dec 2024 10:55:13 +0000

Hey there! 👋 If you're new to Docker and wondering, "How do I know if my containers are running properly?", you're in the right place! Let's break down Docker health checks in a way that's easy to understand.

What is a Docker Health Check?

Think of a health check as a way to ask your container, "Hey, are you feeling okay?" It's like a regular checkup at the doctor's office but for your containers! Docker will periodically run a command you specify to check if your application is working correctly.

Why Do You Need Health Checks? 🎯

Imagine you're running a web application:

Your container might be running, but what if your app crashed inside it?
What if your app is running but can't connect to its database?
How would you know if something's wrong before your users do?

That's where health checks come in! They help you catch these issues automatically.

Your First Health Check

Let's start with a super simple example. Say you have a Node.js web application:

FROM node:alpine

# Install curl for health checks
RUN apk add --no-cache curl

WORKDIR /app

COPY package*.json ./
RUN npm install

# Then copy the rest
COPY . .

EXPOSE 3000

HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD curl -f http://localhost:3000/health || exit 1

CMD ["npm", "start"]

Let's break down what this health check does:

--interval=30s: Checks every 30 seconds
--timeout=3s: Waits up to 3 seconds for a response
--retries=3: Tries 3 times before marking as unhealthy
curl -f http://localhost:3000/health: The actual check - tries to access your app
|| exit 1: If the curl fails, the health check fails

Checking Container Health Status

After you've added a health check, you can see how your container is doing:

# Start your container
docker run -d --name my-app my-node-app

# Check its health status
docker ps

# Get more detailed health info
docker inspect my-app | grep Health

You'll see one of these states:

starting: Your container is starting up
healthy: Everything's good!
unhealthy: Something's wrong

A Simple Health Check Endpoint

For a web application, you'll want to add a health check endpoint. Here's a super simple example in Node.js:

const express = require('express');
const app = express();

app.get('/', (req, res) => {
  res.send('Hello World!');
});

// Simple health check endpoint
app.get('/health', (req, res) => {
  res.json({ status: 'OK' });
});

const port = 3000;
app.listen(port, () => {
  console.log(`App listening at http://localhost:${port}`);
});

Then update your Dockerfile to use this endpoint:

HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD curl -f http://localhost:3000/health || exit 1

Using Docker Compose? It's Easy!

If you're using Docker Compose, you can add health checks like this:

services:
  web:
    build: .
    ports:
      - "3000:3000"
    healthcheck:
      test: curl -f http://localhost:3000/health || exit 1
      interval: 30s
      timeout: 3s
      retries: 3
      start_period: 40s

The start_period gives your app some time to start up before running health checks.

Basic Monitoring for Beginners

Want to see what your container is doing? Try these simple commands:

# See container resource usage
docker stats

# View container logs
docker logs my-app

# Follow logs in real-time
docker logs -f my-app

Tips for Getting Started

Start Simple
- Begin with basic HTTP checks
- Don't overcomplicate your health checks at first
Test Your Health Checks
- Try stopping your application inside the container
- Make sure the health check detects the problem
Common Gotchas
- Make sure curl is installed in your container
- Give your app enough time to start up
- Check the right port (container port, not host port)

Conclusion

Health checks don't have to be complicated! Start with these basics, and you'll be on your way to more reliable Docker containers. Remember, even a simple health check is better than no health check at all.

Happy Dockering! 🐳

Found this helpful? Follow me for more Docker tips and tricks! And don't forget to leave a ❤️ if you enjoyed this article.

A Beginner's Guide to Docker Compose for Developers

Suleiman Dibirov — Sun, 01 Dec 2024 10:08:56 +0000

If you're a developer who's been using Docker containers but finding yourself typing long docker run commands or managing multiple containers manually, it's time to level up your workflow with Docker Compose. This guide will walk you through the basics of Docker Compose and show you how to simplify your development environment setup.

What is Docker Compose?

Docker Compose is a tool that helps you define and share multi-container applications. With Compose, you use a YAML file to configure your application's services, networks, and volumes. Then, with a single command, you create and start all the services from your configuration.

Why Should You Use Docker Compose?

Simplified Configuration: Define your entire application stack in a single file
Reproducible Environments: Share your application setup with other developers
Easy Testing: Create isolated testing environments quickly
Version Control: Track changes to your application environment alongside your code

Getting Started

First, ensure you have both Docker and Docker Compose installed. Docker Desktop for Windows and Mac comes with Compose, but Linux users might need to install it separately.

The compose.yml File

The heart of Docker Compose is the compose.yml file (or docker-compose.yml for backward compatibility). Here's a simple example:

services:
  web:
    build: .
    ports:
      - "3000:3000"
    volumes:
      - .:/app
    environment:
      - NODE_ENV=development

  db:
    image: postgres:13
    environment:
      - POSTGRES_USER=myuser
      - POSTGRES_PASSWORD=mypassword
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

Let's break down each configuration element:

services: The top-level key that defines all your application's containers/services
- Each indented key under services (like web and db) is a service name you choose
- Service names are used for network aliases and container prefixes
build: Specifies the build configuration for creating a container image
- . means build from Dockerfile in the current directory
- Can also specify a path to a directory containing a Dockerfile
- Can be expanded to include build context and arguments:
```
 build:
   context: ./dir
   dockerfile: Dockerfile.dev
   args:
     ENV: development
```
ports: Maps container ports to host ports
- Format is "HOST_PORT:CONTAINER_PORT"
- Example: "3000:3000" maps container port 3000 to host port 3000
- Can specify multiple port mappings
- Can use port ranges: "3000-3005:3000-3005"
volumes: Defines mounted volumes for data persistence and file sharing
- Bind mounts: ./host/path:/container/path maps a host directory to container
- Named volumes: volume_name:/container/path uses a Docker-managed volume
- Anonymous volumes: /container/path creates an unnamed Docker-managed volume
- Can specify read-only volumes: ./host/path:/container/path:ro
environment: Sets environment variables inside the container
- Can be a list: - KEY=value
- Or a map:
```
 environment:
   NODE_ENV: development
   API_KEY: secret
```
image: Specifies a pre-built Docker image to use
- Can be from Docker Hub: postgres:13
- Or private registry: registry.example.com/image:tag
- Used when you don't need to build an image locally
Named volumes declaration:
- The top-level volumes key declares named volumes used in services
- These volumes persist even when containers are removed
- Can specify volume drivers and options:
```
 volumes:
   postgres_data:
     driver: local
     driver_opts:
       type: none
       device: /path/on/host
       o: bind
```

Common additional configurations you might need:

services:
  web:
    # Restart policy
    restart: always  # or 'no', 'on-failure', 'unless-stopped'

    # Dependencies
    depends_on:
      - db
      - redis

    # Custom container name
    container_name: myapp_web

    # Additional hosts entries
    extra_hosts:
      - "host.docker.internal:host-gateway"

    # Resource limits
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 512M

    # Health check
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000"]
      interval: 30s
      timeout: 10s
      retries: 3

These configurations allow you to define complex, multi-container applications in a declarative way. The compose file serves as both documentation and executable configuration, making it easier to share and maintain your application's infrastructure requirements.

Essential Commands

Here are the Docker Compose commands you'll use frequently:

# Start your services
docker compose up

# Run in detached mode
docker compose up -d

# Stop services (keeps containers)
docker compose stop

# Stop and remove containers, networks
docker compose down

# Stop and remove containers, networks, volumes
docker compose down -v

# View logs
docker compose logs

# View logs for specific service
docker compose logs service_name

# Follow logs
docker compose logs -f

# Rebuild services
docker compose build

# Execute command in a running container
docker compose exec service_name command
# Example: docker compose exec web npm test

# Run a one-off command
docker compose run --rm service_name command
# Example: docker compose run --rm web npm install

# List running containers
docker compose ps

# Check service status
docker compose top

# Pull latest images
docker compose pull

Real-World Example: MERN Stack

Let's look at a practical example using a MERN (MongoDB, Express, React, Node.js) stack:

services:
  frontend:
    build:
      context: ./frontend
      dockerfile: Dockerfile
    ports:
      - "3000:3000"
    volumes:
      - ./frontend:/app
      - /app/node_modules
    environment:
      - REACT_APP_API_URL=http://localhost:5000
    depends_on:
      - backend

  backend:
    build:
      context: ./backend
      dockerfile: Dockerfile
    ports:
      - "5000:5000"
    volumes:
      - ./backend:/app
      - /app/node_modules
    environment:
      - MONGODB_URI=mongodb://mongodb:27017/myapp
    depends_on:
      - mongodb

  mongodb:
    image: mongo:latest
    ports:
      - "27017:27017"
    volumes:
      - mongodb_data:/data/db

volumes:
  mongodb_data:

Best Practices

Use Version Control: Always include your compose file in version control
Environment Variables: Use .env files for sensitive data:

services:
  web:
    env_file:
      - .env

Named Volumes: Use named volumes instead of bind mounts for databases:

volumes:
  - mongodb_data:/data/db  # Good
  - ./data:/data/db       # Not recommended for databases

Dependencies: Use depends_on to manage service startup order:

services:
  web:
    depends_on:
      - db
      - redis

Common Issues and Solutions

1. Port Conflicts

If you see "port is already allocated" errors:

Check for running containers using the same ports
Use docker compose ps to list running containers
Change the port mapping in your compose file

2. Volume Permissions

If you encounter permission issues:

Ensure proper ownership of mounted volumes
Consider using user directive in your service definition:

services:
  web:
    user: "1000:1000"

Conclusion

Docker Compose is an invaluable tool for modern development workflows. It simplifies container management, makes development environments reproducible, and helps teams work more efficiently. Start with simple configurations and gradually add more features as your needs grow.

Remember: the goal is to make development easier, not more complicated. Don't over-engineer your Compose files – keep them simple and focused on your immediate needs.

Happy containerizing! 🐳

Introducing Helm CEL: A More Expressive Way to Validate Your Helm Charts

Suleiman Dibirov — Sun, 17 Nov 2024 05:36:26 +0000

If you've worked with Helm charts, you're probably familiar with the challenge of validating values.yaml. While Helm's built-in JSON Schema validation works, it can be cumbersome and limiting. Today, I want to introduce you to Helm CEL, a plugin that brings the power of Google's Common Expression Language (CEL) to Helm chart validation.

What is CEL?

Before diving in, let's quickly cover what CEL is. Common Expression Language (CEL) is a simple expression language created by Google that lets you write concise, powerful validation rules. It's used in Kubernetes CRD validation, Istio configuration, and many other projects in the cloud-native ecosystem.

Why Use CEL Instead of JSON Schema?

More Expressive: CEL allows you to write complex validation rules in a more natural and readable way
Familiar Syntax: If you're coming from programming languages like Python or JavaScript, CEL's syntax will feel natural
Type-Safe: CEL provides strong type checking while remaining flexible
Built for Cloud Native: CEL is already used throughout the Kubernetes ecosystem

Getting Started

First, install the plugin:

helm plugin install https://github.com/idsulik/helm-cel

Instead of creating a values.schema.json, you'll create a values.cel.yaml file in your chart directory. Here's a simple example:

rules:
  - expr: "has(values.service) && has(values.service.port)"
    desc: "service port is required"

  - expr: "values.service.port >= 1 && values.service.port <= 65535"
    desc: "service port must be between 1 and 65535"

  - expr: "!(has(values.replicaCount)) || values.replicaCount >= 1"
    desc: "if replicaCount is set, it must be at least 1"

To validate your chart:

helm cel ./mychart

Real-World Examples

Let's look at some common validation patterns and how they're expressed in both JSON Schema and CEL.

1. Required Fields

JSON Schema:

{
  "required": ["service"],
  "properties": {
    "service": {
      "required": ["port"],
      "properties": {
        "port": {
          "type": "integer"
        }
      }
    }
  }
}

CEL:

rules:
  - expr: "has(values.service) && has(values.service.port)"
    desc: "service port is required"

2. Conditional Requirements

JSON Schema:

{
  "if": {
    "properties": {
      "persistence": {
        "const": true
      }
    }
  },
  "then": {
    "required": ["storageClass"]
  }
}

CEL:

rules:
  - expr: "!has(values.persistence) || !values.persistence || has(values.storageClass)"
    desc: "storageClass is required when persistence is enabled"

3. Complex Validations

JSON Schema can become quite verbose for complex validations. Here's a CEL example that would be much more complicated in JSON Schema:

rules:
  - expr: |
      !has(values.resources) || 
      (!has(values.resources.limits) && !has(values.resources.requests)) ||
      (has(values.resources.limits.memory) && has(values.resources.requests.memory) &&
       int(values.resources.requests.memory) <= int(values.resources.limits.memory))
    desc: "If resources are specified, memory request must not exceed memory limit"

Error Messages That Make Sense

One of the best features of Helm CEL is its clear error messages. When validation fails, you get helpful output like this:

❌ Validation failed: replica count must be at least 1
   Rule: values.replicaCount >= 1
   Path: replicaCount
   Current value: 0

Performance Considerations

CEL expressions are compiled and evaluated efficiently. The plugin adds minimal overhead to your Helm workflow, making it suitable for both development and CI/CD pipelines.

Next Steps

Install the plugin: helm plugin install https://github.com/idsulik/helm-cel
Check out the GitHub repository for more examples
Start writing your own validation rules!

Conclusion

Helm CEL brings a more expressive and maintainable way to validate your Helm charts. If you've ever found yourself fighting with JSON Schema or wanting more flexible validation rules, give it a try. The combination of familiar syntax, powerful expressions, and clear error messages makes it a valuable addition to any Helm user's toolkit.

What validation patterns would you like to see? Let me know in the comments below!

Docker ARG vs ENV: Understanding Build-time and Runtime Variables

Suleiman Dibirov — Wed, 13 Nov 2024 15:57:39 +0000

Are you confused about when to use ARG versus ENV in your Dockerfiles? You're not alone! This comprehensive guide will help you understand the key differences, use cases, and best practices for both build arguments (ARG) and environment variables (ENV) in Docker.

Quick Reference

Feature	ARG	ENV
Available during build	✅	✅
Available in running container	❌	✅
Can be set in Dockerfile	✅	✅
Can be overridden at build time	✅	❌
Persists in final image	❌	✅
Can be used in FROM instruction	✅	❌

Key Differences

The fundamental difference between ARG and ENV lies in their scope and persistence:

ARG is only available during the build process
ENV sets environment variables that persist in the running container

Understanding ARG

Build arguments (ARG) are variables that you can pass to Docker during the image build process using the --build-arg flag.

Basic ARG Syntax

# Declare the argument
ARG VERSION=latest

# Use the argument
FROM ubuntu:${VERSION}

Build command:

docker build --build-arg VERSION=20.04 -t my-ubuntu .

ARG Scoping Rules

ARGs declared before FROM are only available during FROM instruction
To use ARG after FROM, you need to redeclare it
Each FROM instruction clears all ARGs declared before it

# Global ARG
ARG BASE_IMAGE=ubuntu

# Available in FROM
FROM ${BASE_IMAGE}:latest

# Need to redeclare to use after FROM
ARG BASE_IMAGE
RUN echo "Building from ${BASE_IMAGE}"

Understanding ENV

Environment variables (ENV) are set in your image and are available both during build and when the container runs.

Basic ENV Syntax

# Set a single environment variable
ENV APP_VERSION=1.0.0

# Set multiple environment variables
ENV NODE_ENV=production \
    PORT=3000 \
    APP_HOME=/app

ENV Persistence

ENVs persist across build stages and in the final container:

# Stage 1: Build
FROM node:16 AS builder
ENV NODE_ENV=production
RUN echo "Building in ${NODE_ENV}"

# Stage 2: Runtime
FROM node:16-slim
# NODE_ENV needs to be redefined if needed in this stage
ENV NODE_ENV=production

Real-World Examples

1. Building Different Versions of an Application

# Build argument for version control
ARG NODE_VERSION=16

# Base image with specified version
FROM node:${NODE_VERSION}

# Environment variable for runtime configuration
ENV NODE_ENV=production

# Redeclare ARG if needed after FROM
ARG NODE_VERSION
RUN echo "Node.js version: ${NODE_VERSION}"

# Application setup
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .

# Runtime configuration
ENV PORT=3000 \
    APP_NAME=my-awesome-app

CMD ["npm", "start"]

2. Configurable Build Process

# Build-time configuration
ARG INSTALL_DEV_DEPS=false
ARG ENABLE_TESTING=false

FROM node:16

WORKDIR /app
COPY package*.json ./

# Redeclare ARGs after FROM
ARG INSTALL_DEV_DEPS
ARG ENABLE_TESTING

# Conditional installation of dependencies
RUN if [ "$INSTALL_DEV_DEPS" = "true" ]; then \
        npm install; \
    else \
        npm install --production; \
    fi

COPY . .

# Conditional testing
RUN if [ "$ENABLE_TESTING" = "true" ]; then \
        npm test; \
    fi

# Runtime configuration
ENV NODE_ENV=production \
    LOG_LEVEL=info

CMD ["npm", "start"]

Best Practices

Use ARG for Build Flexibility
- Version numbers
- Base image selection
- Build-time configuration
Use ENV for Runtime Configuration
- Application settings
- Service endpoints
- Feature flags
Default Values

   # Provide sensible defaults for ARGs
   ARG VERSION=latest
   ARG NODE_ENV=production

   # ENVs should also have defaults
   ENV PORT=3000 \
       LOG_LEVEL=info

Documentation

   # Document your build arguments
   # Required: VERSION - Specify the application version to build
   # Optional: NODE_ENV - Build environment (default: production)
   ARG VERSION
   ARG NODE_ENV=production

Security Considerations
- Never use ARG or ENV for secrets
- Use Docker secrets or environment files for sensitive data
- Remember that ENVs are visible in the image history

Common Pitfalls

ARG Scope Confusion

# Won't work as expected
ARG VERSION
FROM ubuntu:${VERSION}

# Need to redeclare
ARG VERSION
RUN echo ${VERSION}

Build-time vs Runtime Values

# Wrong: Using ARG for runtime configuration
ARG API_URL=http://api.example.com

# Correct: Use ENV for runtime configuration
ENV API_URL=http://api.example.com

Missing Defaults

# Risky: No default value
ARG VERSION

# Better: Include a default
ARG VERSION=latest

Advanced Usage

Combining ARG and ENV

# Build argument with default
ARG NODE_ENV=production

# Set ENV based on ARG
ENV NODE_ENV=${NODE_ENV}

# Now NODE_ENV persists in the container
# but can be configured at build time

Multiple Build Stages

# Build stage
FROM node:16 AS builder
ARG BUILD_MODE=production
ENV NODE_ENV=${BUILD_MODE}
RUN npm install && npm run build

# Production stage
FROM node:16-slim
ARG BUILD_MODE=production
ENV NODE_ENV=${BUILD_MODE}
COPY --from=builder /app/dist ./dist

Using Docker Compose

services:
  app:
    build:
      context: .
      args:
        - NODE_VERSION=16
        - BUILD_MODE=development
    environment:
      - NODE_ENV=development
      - PORT=3000

Conclusion

Understanding the difference between ARG and ENV is crucial for building flexible and maintainable Docker images. Use ARG for build-time configuration and ENV for runtime settings. Remember that ARGs are only available during build, while ENVs persist in the running container.

By following these guidelines and best practices, you can create more maintainable and configurable Docker images while avoiding common pitfalls.

Additional Resources

Docker CLI Tricks Every Developer Should Know

Suleiman Dibirov — Sat, 02 Nov 2024 06:30:00 +0000

The Docker CLI offers powerful commands that can significantly improve productivity, simplify workflows, and make managing containers more efficient. Here are some essential tricks and tips that every developer should know.

1. Inspecting Containers with `docker inspect`

#modern Docker client syntax
docker inspect --format='{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}'

#old Docker client syntax
docker inspect --format='{{.NetworkSettings.IPAddress}}' <container_name>

Tip: Use docker inspect to access detailed information about containers, images, and volumes, including IP addresses and mounted volumes. Use --format with docker inspect to extract specific fields:

2. Cleaning Up Unused Resources Quickly

docker system prune

#output example
WARNING! This will remove:
  - all stopped containers
  - all networks not used by at least one container
  - all dangling images
  - all dangling build cache

Are you sure you want to continue? [y/N]

Tip: Over time, unused containers, images, and volumes accumulate and take up disk space. docker system prune removes everything unused, or use docker image prune, docker container prune, and docker volume prune for selective cleanup.

3. Running One-Off Commands in Containers

Tip: Execute one-off commands within a running container without starting a new one, using docker exec. For example:
```
 docker exec -it my_container /bin/bash
```
Useful for debugging and checking runtime configurations inside containers.

4. Limiting Resource Usage on Containers

#command
docker run --memory <memory_limit> --cpus <cpu_limit>

#example
docker run --memory=512m --cpus=1 my_image

Tip: Prevent resource hogging by limiting memory and CPU usage for each container. This ensures fair resource allocation:

5. Checking Container Logs in Real-Time

Tip: The -f option shows real-time log output, useful for debugging running services. For instance:
```
 docker logs -f my_container
```
You can also add --tail to view only the most recent lines:
```
 docker logs -f --tail 50 my_container
```

6. Exporting and Importing Images

#export
docker save -o <filename.tar> <image_name>

#import
docker load -i <filename.tar>

Tip: Export and import images between machines without re-downloading them. Ideal for offline setups or environments with network restrictions.

7. Checking Running Container Stats

docker stats

Tip: Use docker stats to monitor real-time metrics for CPU, memory, and network usage. It helps diagnose performance issues and visualize resource utilization for each container.

8. Binding Ports Dynamically

docker run -P <image_name>

Tip: With -P, Docker maps exposed container ports to random available host ports. To see mapped ports, use:
```
 docker port <container_name>
```
Alternatively, specify specific host ports using -p (e.g., docker run -p 8080:80 my_image).

9. Quickly Build and Run Containers with `docker-compose`

docker-compose up -d

Tip: For multi-container applications, docker-compose simplifies setup. The -d flag runs services in the background, and docker-compose up recreates only modified containers, speeding up development.

10. Viewing Disk Usage with `docker system df`

docker system df

#output example
TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              11                  6                   2.866GB             1.171GB (40%)
Containers          17                  13                  3.4MB               2.145MB (63%)
Local Volumes       9                   5                   849.5MB             315.1MB (37%)
Build Cache         0                   0                   0B                  0B

Tip: See how much disk space Docker resources (images, containers, volumes) occupy. This command provides an overview of storage use, which is helpful for resource management.

Conclusion

Mastering these Docker CLI tricks can make a noticeable difference in your workflow, from managing resources efficiently to quickly debugging applications.

Managing Container Lifecycles with Docker Compose Lifecycle Hooks

Suleiman Dibirov — Fri, 01 Nov 2024 10:05:08 +0000

Docker Compose v2.30.0 has introduced lifecycle hooks, making it easier to manage actions tied to container start and stop events. This feature lets developers handle key tasks more flexibly while keeping applications clean and secure.

Lifecycle hooks in Docker Compose provide a powerful way to execute commands at specific points in a container's lifecycle. Features like post-start and pre-stop hooks can handle privileged tasks (like changing file permissions) without running the entire container with elevated permissions. Let's explore how these hooks work and how they can benefit your containerized applications.

Why Use Lifecycle Hooks in Docker Compose?

Traditionally, Docker Compose manages a container's lifecycle through the ENTRYPOINT and COMMAND options. While effective, these fields can make managing start and stop tasks less flexible, especially if you need different tasks to execute at different points.

Lifecycle hooks allow for tasks that require higher privileges (such as a root user) to be isolated from the main application logic. They let you:

Handle privileged actions without compromising container security
Streamline processes like file permissions, cleanup scripts, or backup routines
Avoid bloating ENTRYPOINT or COMMAND with logic that's only needed on start or stop
Execute multiple tasks in a defined order during container startup or shutdown

Post-Start Hooks: Running Tasks After the Container Starts

What Is a Post-Start Hook?

A post-start hook is a command that runs after the container starts. These hooks are useful for tasks that need to be done right after the container is up and running but are not dependent on precise timing.

Execution Environment:

Hooks run within the context of the running container
They have access to the container's environment variables
They can interact with the container's filesystem and services
Multiple hooks execute in the order they are defined
Each hook must complete before the next one starts
If any hook fails, subsequent hooks are not executed

Example: Changing Volume Ownership with a Post-Start Hook

When Docker volumes are created, they are assigned root ownership by default. If you need a non-root user to access volume files, a post-start hook can change the file ownership accordingly.

Here's a complete docker-compose.yml file that uses post-start hooks to set up proper volume permissions:

version: '3.8'
services:
  app:
    image: backend
    user: 1001
    volumes:
      - data:/data    
    post_start:
      - command: ["chown", "-R", "1001:1001", "/data"]
        user: root
      - command: ["chmod", "-R", "755", "/data"]
        user: root

volumes:
  data:
    driver: local

How It Works:

Volume Initialization: Docker creates the data volume with root ownership
Container Starts: The container runs with user: 1001
Permission Setup: Two post-start hooks execute sequentially:
- First hook changes ownership to user 1001
- Second hook sets appropriate read/write permissions
Application Runs: The application can now access the volume with proper permissions

Note on Permissions:

By specifying user: root in the post-start hooks, the commands run with root privileges within the container. This allows the hooks to perform necessary privileged actions without granting root permissions to the main container process, enhancing security.

Pre-Stop Hooks: Executing Commands Before the Container Stops

What Is a Pre-Stop Hook?

A pre-stop hook is a command that runs inside the container before Docker stops it. These hooks are invaluable for executing cleanup or backup tasks, ensuring data consistency before shutdown.

Execution Environment:

Hooks execute inside the running container
They have access to the container's full environment
They run only during graceful shutdowns (not during force stops)
Multiple hooks execute in sequence
Each hook must complete before proceeding to the next

Example: Running a Cleanup Script with a Pre-Stop Hook

Here's an example showing how to implement pre-stop hooks for proper application shutdown:

version: '3.8'
services:
  app:
    image: backend
    pre_stop:
      - command: ["./scripts/flush_cache.sh"]
      - command: ["./scripts/backup_data.sh"]
      - command: ["curl", "-X", "POST", "http://monitoring.example.com/notify_shutdown"]

How It Works:

Shutdown Initiated: Container receives shutdown signal (e.g., docker compose down)
Pre-Stop Sequence: Hooks execute in order:
- Flush application cache
- Backup important data
- Notify monitoring system
Container Stops: After hooks complete, container proceeds with shutdown

Practical Use Cases for Lifecycle Hooks

Post-Start Tasks

Database Migration Example:

services:
  web:
    image: myapp
    post_start:
      - command: ["python", "manage.py", "migrate"]
      - command: ["python", "manage.py", "collectstatic", "--noinput"]

Service Health Check:

services:
  app:
    image: backend
    post_start:
      - command: ["./scripts/wait-for-db.sh"]
      - command: ["./scripts/initialize-cache.sh"]

Pre-Stop Tasks

Graceful Shutdown Example:

services:
  worker:
    image: worker-service
    pre_stop:
      - command: ["./scripts/finish_pending_jobs.sh"]
      - command: ["./scripts/save_metrics.sh"]

Cleanup Process:

services:
  cache:
    image: redis
    pre_stop:
      - command: ["redis-cli", "save"]
      - command: ["./backup-redis.sh"]

Best Practices and Tips

Error Handling:
- Always include error checking in hook scripts
- Log hook execution results for debugging
- Consider setting appropriate timeouts
Security Considerations:
- Use root privileges only when necessary
- Keep privileged operations in hooks rather than main container
- Validate and sanitize any external input used in hooks
Performance:
- Keep hooks lightweight and efficient
- Avoid long-running operations in hooks
- Consider parallel execution when possible

Version Compatibility

Lifecycle hooks require Docker Compose v2.30.0 or newer. Before implementing hooks, ensure your environment meets these requirements:

docker compose version  # Should show 2.30.0 or higher

Conclusion

Docker Compose lifecycle hooks provide a powerful and secure way to manage container lifecycle events. By separating privileged operations and lifecycle-specific tasks into hooks, developers can create more maintainable and secure containerized applications. The ability to execute specific commands during start and stop events, combined with flexible permission handling, makes hooks an essential tool in modern container orchestration.

References

Container Anti-Patterns: Common Docker Mistakes and How to Avoid Them.

Suleiman Dibirov — Tue, 29 Oct 2024 09:21:40 +0000

Containerization has transformed how developers package and deploy applications. While Docker simplifies this process, many developers unknowingly adopt patterns that reduce efficiency, security, or scalability. Let’s explore some common Docker anti-patterns and how to sidestep them for optimized, secure containers.

1. Using a Large Base Image Unnecessarily

The Problem: Larger base images, like ubuntu or centos, are tempting for their flexibility but can lead to bloated containers. This slows down image pull and deploy times and increases attack surface.
Solution: Opt for lightweight images like alpine or distro-less images if they meet your needs. Start with the smallest image that provides necessary dependencies.

2. Building Containers as Root

The Problem: Running containers as root exposes the host system to vulnerabilities if attackers manage to access a container.
Solution: Use Docker’s USER instruction to define a non-root user within your Dockerfile. This reduces the container’s permissions, minimizing potential security risks.

3. Failing to Optimize Layers in Dockerfiles

The Problem: Poorly structured Dockerfile commands can create extra layers, slowing down builds and consuming more storage.
Solution: Consolidate related commands and use multi-stage builds where possible. For instance, combining RUN apt-get update and RUN apt-get install into a single RUN command minimizes layers.

4. Not Clearing Cache and Unnecessary Files

The Problem: Leaving unnecessary files, like build dependencies, in your image inflates size and introduces security risks.
Solution: Remove temporary files, caches, and build dependencies after installation. Use rm -rf to delete anything unnecessary right after it’s used in a RUN command.

5. Hardcoding Secrets and Credentials in Dockerfiles

The Problem: Hardcoding secrets like API keys or database credentials in Dockerfiles exposes sensitive data and can be disastrous if the image is publicly shared.
Solution: Use Docker’s secrets management (or environment variables securely passed during runtime) for handling credentials. Avoid embedding secrets directly in Dockerfiles.

6. Skipping Multi-Stage Builds for Production Images

The Problem: Including build tools or source code in production images results in larger, less secure containers.
Solution: Use multi-stage builds to keep only the required runtime dependencies in your final image. This technique drastically reduces image size and removes unnecessary tools.

7. Neglecting Health Checks

The Problem: Without defined health checks, Docker and orchestration tools (like Kubernetes) can’t detect if a container is unresponsive or in a bad state.
Solution: Use HEALTHCHECK to define commands that validate the container’s health. Set it to run periodically, alerting you if the container fails and allowing for automatic restarts.

8. Overusing Privileged Containers

The Problem: Running containers in privileged mode (--privileged) grants them extensive host permissions, which is dangerous and rarely necessary.
Solution: Avoid --privileged unless absolutely required, and instead grant only specific capabilities using --cap-add for a safer, more restricted container environment.

9. Not Leveraging Caching Efficiently

The Problem: Inefficient use of caching leads to slower builds, especially if commands like RUN apt-get update run every time.
Solution: Place less frequently changing commands at the beginning of the Dockerfile to make better use of layer caching. For package installs, combine them in a way that retains cached layers whenever possible.

10. Forgetting to Set Resource Limits

The Problem: Containers without CPU or memory limits can overconsume resources, leading to instability in a production environment.
Solution: Use --memory and --cpus flags to restrict resource usage for each container. These limits prevent a single container from impacting the host system’s performance.

Conclusion

Avoiding these Docker anti-patterns enhances your container’s performance, security, and scalability. By adopting best practices, you can ensure your containers run lean, secure, and smoothly integrated into any infrastructure. Implement these strategies to take your Docker expertise to the next level, enabling faster and safer deployments.

Dockerfile Best Practices: How to Create Efficient Containers

Suleiman Dibirov — Sat, 05 Oct 2024 11:24:00 +0000

Introduction

In the era of microservices and cloud computing, Docker has become an indispensable tool for application development and deployment. Containerization allows developers to package applications and their dependencies into a single, portable unit, ensuring predictability, scalability, and rapid deployment. However, the efficiency of your containers largely depends on how optimally your Dockerfile is written.

In this article, we'll explore best practices for creating Dockerfiles that help you build lightweight, fast, and secure containers.

Dockerfile Basics

What Is a Dockerfile?

A Dockerfile is a text document containing a set of instructions to assemble a Docker image. Each instruction performs a specific action, such as installing packages, copying files, or defining startup commands. Proper use of Dockerfile instructions is crucial for building efficient containers.

Key Dockerfile Instructions

FROM: Sets the base image for your new image.
RUN: Executes a command in a new layer on top of the current image and commits the result.
CMD: Specifies the default command to run when a container is started.
COPY: Copies files and directories from the build context into the container filesystem.
ADD: Similar to COPY but with additional features like extracting archives.
ENV: Sets environment variables.
EXPOSE: Informs Docker which ports the container listens on at runtime.
ENTRYPOINT: Configures a container to run as an executable.
VOLUME: Creates a mount point for external storage volumes.
WORKDIR: Sets the working directory for subsequent instructions.

Best Practices for Writing Dockerfiles

Use Minimal Base Images

The base image serves as the foundation for your Docker image. Choosing a lightweight base image can significantly reduce the final image size and minimize the attack surface.

Alpine Linux: A popular minimal image around 5 MB in size.

  FROM alpine:latest

Pros: Small size, security, fast downloads.

Cons: May require additional configuration; some packages might be missing or behave differently due to using musl instead of glibc.

Scratch: An empty image ideal for languages that can compile static binaries (Go, Rust).

  FROM scratch
  COPY myapp /myapp
  CMD ["/myapp"]

Reduce Layers

Each RUN, COPY, and ADD instruction adds a new layer to your image. Combining commands helps reduce the number of layers and the overall image size.

Inefficient:

RUN apt-get update
RUN apt-get install -y python
RUN apt-get install -y pip

Efficient:

RUN apt-get update && apt-get install -y \
    python \
    pip \
 && rm -rf /var/lib/apt/lists/*

Optimize Layer Caching

Docker uses layer caching to speed up builds. The order of instructions affects caching efficiency.

Copy Dependency Files First: Copy files that change less frequently (like package.json or requirements.txt) before copying the rest of the source code.

  COPY package.json .
  RUN npm install
  COPY . .

Minimize Changes in Early Layers: Changes in early layers invalidate the cache for all subsequent layers.

Install Dependencies Wisely

Remove temporary files and caches after installing packages to reduce image size.

RUN pip install --no-cache-dir -r requirements.txt

Manage Secrets Carefully

Never include sensitive data (passwords, API keys) in your Dockerfile. Instead:

Use BuildKit's secret mounting for build-time secrets:

# Mount secret during build
RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecret

Use Docker Compose secrets for runtime secrets:

services:
  app:
    build:
      context: .
      secrets:
        - mysecret
secrets:
  mysecret:
    file: ./mysecret.txt

Environment variables for non-sensitive configuration:

ENV APP_PORT=3000

External secret managers for production:
HashiCorp Vault
AWS Secrets Manager
Azure Key Vault
Docker Swarm secrets (if using Swarm mode)

Best practice: Keep secrets out of image layers and inject them at runtime.

Optimize Image Size

Delete Unnecessary Files: Clean up caches, logs, and temporary files within the same RUN command as the installation. This ensures that these temporary files do not persist in any intermediate layers, effectively reducing the final image size.

  RUN apt-get update && apt-get install -y --no-install-recommends package \
      && apt-get clean && rm -rf /var/lib/apt/lists/*

Minimize Installed Packages: Install only the packages you need by using flags like --no-install-recommends. This avoids pulling in unnecessary dependencies, further slimming down the image.

  RUN apt-get install -y --no-install-recommends package

Note: To maximize image size reduction, combine this installation with cleanup commands in the same RUN statement as shown above.

Use Optimization Tools: Utilize tools like Docker Slim which can automatically analyze and optimize your Docker images by removing unnecessary components and reducing their size without altering functionality.

Utilize .dockerignore

A .dockerignore file lets you exclude files and directories from the build context, reducing the amount of data sent to the Docker daemon and protecting sensitive information.

Example .dockerignore:

.git
node_modules
Dockerfile
.dockerignore

Employ Multi-Stage Builds

Multi-stage builds allow you to use intermediate images and copy only the necessary artifacts into the final image.

Example for a Go Application:

# Build Stage
FROM golang:1.16-alpine AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp

# Final Image
FROM alpine:latest
WORKDIR /app
COPY --from=builder /app/myapp .
CMD ["./myapp"]

Run as Non-Root User

For enhanced security, avoid running applications as the root user.

RUN adduser -D appuser
USER appuser

Scan for Vulnerabilities

Use Scanning Tools: Tools like Trivy, Anchore, or Clair can help identify known vulnerabilities.
Regularly Update Images: Keep your base images and dependencies up to date.

Logging and Monitoring

Direct Logs to STDOUT/STDERR: This allows for easier log collection and analysis.
Integrate with Monitoring Systems: Use tools like Prometheus or the ELK Stack to monitor container health.

Examples and Recommendations

Optimized Dockerfile Example for a Node.js Application

# Use the official Node.js image based on Alpine Linux
FROM node:14-alpine

# Set the working directory
WORKDIR /app

# Copy package files and install dependencies
COPY package*.json ./
RUN npm ci --only=production

# Copy the rest of the application code
COPY . .

# Create a non-root user and switch to it
RUN addgroup appgroup && adduser -S appuser -G appgroup
USER appuser

# Expose the application port
EXPOSE 3000

# Define the command to run the app
CMD ["node", "app.js"]

Additional Recommendations

Pin Versions: Use specific versions of base images and packages to ensure build reproducibility.

  FROM node:14.17.0-alpine

Stay Updated: Regularly update dependencies and base images to include security patches.
Use Metadata: Add LABEL instructions to provide image metadata.

  LABEL maintainer="yourname@example.com"

Set Proper Permissions: Ensure files and directories have appropriate permissions.
Avoid Using Root: Always switch to a non-root user for running applications.

Conclusion

Creating efficient Docker images is both an art and a science. By following best practices when writing your Dockerfile, you can significantly improve the performance, security, and manageability of your containers. Continuously update your knowledge and stay informed about new tools and methodologies in the containerization ecosystem. Remember, optimization is an ongoing process, and there's always room for improvement.

Introducing Swama: A CLI Tool for Swagger/OpenAPI Interactions

Suleiman Dibirov — Mon, 16 Sep 2024 09:52:19 +0000

APIs have become a critical part of software development. However, working with Swagger or OpenAPI specifications can sometimes feel like a manual and repetitive process. Wouldn't it be great if you could easily interact with these API specifications directly from your terminal?

That's where Swama comes in. Swama is a CLI tool built for developers who work with Swagger/OpenAPI specifications. It allows you to effortlessly explore, manipulate, and convert API definitions from the command line.

In this post, I’ll walk you through Swama’s features, how to install it, and how to use it to streamline your API development process.

What is Swama?

Swama is a command-line interface (CLI) tool designed to help developers interact with Swagger/OpenAPI definitions. It provides a simple way to list API endpoints, view detailed endpoint information, convert endpoints into curl or fetch commands, and more.

If you are tired of manually browsing through large API definitions or testing endpoints via Swagger UI, Swama is the perfect solution to boost your productivity.

Why Use Swama?

No More Swagger UI: Browse and explore APIs directly from the command line.
Endpoint Conversion: Quickly convert API endpoints into curl or fetch commands for easy testing.
Filtering & Grouping: Filter and group endpoints by method, tags, or paths.
Binaries for All Platforms: Pre-built binaries are available for Linux, macOS, and Windows.

Key Features

Here’s a rundown of some of Swama’s key features:

1. List API Endpoints

Swama allows you to list all available API endpoints in a Swagger or OpenAPI file. You can filter endpoints by HTTP method, tags, or specific paths using wildcard matching.

swama endpoints list --method GET --tag user

This command lists all GET endpoints tagged with user in the specified Swagger file.

2. View Endpoint Details

Want to know more about a specific endpoint? Swama allows you to view detailed information about any endpoint in the API specification.

swama endpoints view --endpoint /user --method GET

The above command will show detailed information about the /user endpoint, including its summary, request body, and response details.

3. Convert Endpoints to `curl` or `fetch`

Testing an API endpoint often involves writing curl or fetch commands. Swama simplifies this process by allowing you to instantly convert an API endpoint into one of these commands.

swama endpoints convert --file swagger.yaml --endpoint /api/users --method POST --type curl

This command converts the POST /api/users endpoint into a curl command that you can use in your terminal.

4. Explore Tags

APIs often use tags to categorize endpoints. Swama lets you list all tags in the API specification:

swama tags list --file swagger.yaml

With this command, you can easily see how the API is structured and what each tag represents.

5. List Servers

Many APIs are deployed across multiple servers (staging, production, etc.). Swama makes it easy to view all the servers listed in your API definition:

swama servers list --file swagger.yaml

This command gives you a quick overview of the environments your API is running in.

Installation

You can install Swama using the pre-built binaries available on the GitHub releases page. Follow these steps to get started:

Download the latest release for your platform (Linux, macOS, or Windows) from GitHub Releases.

Move the binary to your $PATH:

On Linux/macOS:

 sudo mv swama /usr/local/bin/
 sudo chmod +x /usr/local/bin/swama

On Windows: Add the binary to your system’s PATH to run it globally.

Alternatively, you can build Swama from source:

git clone https://github.com/idsulik/swama
cd swama
go build -o swama

Once installed, run the following to verify the installation:

swama --help

Getting Started with Swama

Let’s walk through a few example commands that will get you up and running with Swama.

1. Listing All Endpoints

Want to list all the endpoints in your API definition? Use the list command:

swama endpoints list --file swagger.yaml

This will output all the API endpoints defined in the swagger.yaml file.

2. Viewing Endpoint Details

To view the details of a specific API endpoint, including methods, request bodies, and responses, use the view command:

swama endpoints view --file swagger.yaml --endpoint /api/users --method GET

3. Convert Endpoints to Testable Commands

One of Swama’s most powerful features is its ability to convert API endpoints into curl or fetch commands. For example, to convert an endpoint to a curl command:

swama endpoints convert --file swagger.yaml --endpoint /api/users --method POST --type curl

This command converts the POST /api/users endpoint into a curl command, making it super easy to test the API from the terminal.

Autocompletion for Faster Workflows

Swama supports autocompletion for various shells like Bash and Zsh. You can enable autocompletion for faster and more efficient workflows.

To generate the autocompletion script for your shell, run:

swama completion bash > /etc/bash_completion.d/swama

For Zsh:

swama completion zsh > ~/.zsh/completion/_swama

This allows you to quickly navigate through Swama commands and subcommands with autocompletion.

Final Thoughts

Swama brings the convenience of working with Swagger/OpenAPI definitions directly into your terminal. Whether you're listing endpoints, converting them to curl or fetch, or exploring tags and servers, Swama makes interacting with APIs seamless.

I built Swama to solve my own frustrations with manually browsing through Swagger files and converting API endpoints for testing. I hope it makes your development experience smoother as well.

By following these steps, you can simplify your interaction with API specifications, reduce manual work, and boost your productivity.

A Beginner’s Guide to Docker Image for Developers

Suleiman Dibirov — Fri, 13 Sep 2024 09:11:00 +0000

Docker has become an essential tool for developers, simplifying the process of building, testing, and deploying applications. One of the core concepts in Docker is the Docker image, a lightweight, standalone, and executable package that includes everything needed to run a piece of software. This guide will help beginners understand Docker images, how to create them, and why they are fundamental in modern development workflows.

What is a Docker Image?
How Docker Images Work
Docker Images vs Containers
Pulling and Running Images from Docker Hub
Creating Your Own Docker Image
Managing Docker Images
Conclusion

1. What is a Docker Image?

A Docker image is essentially a blueprint for a container. It contains all the necessary components such as the application code, libraries, environment variables, configuration files, and even the operating system needed to run the application.

Think of it as a snapshot or template that can be used to run containers. Once you have an image, you can use it to run one or multiple instances of a container, ensuring that your application behaves the same across different environments (development, testing, production, etc.).

2. How Docker Images Work

Docker images are built layer by layer, where each layer represents a step in the process of building the image. Each layer is cached, so if a layer doesn't change, Docker can reuse it in future builds, significantly speeding up the process.

For example, if you update just the application code but not the base OS or dependencies, Docker will only rebuild the layers that have changed. This is key to Docker's efficiency.

Here’s a simple breakdown of how layers work:

Base Layer: This is typically a lightweight Linux distribution like Alpine or Ubuntu.
Application Layer: This includes the libraries and dependencies your application needs.
Custom Layers: Any specific configurations, environment variables, or additional tools your app requires.

3. Docker Images vs Containers

A common point of confusion for beginners is the distinction between Docker images and containers. To make the concept clearer, you can think of Docker images and containers as similar to object-oriented programming concepts:

Docker Image: This is like a class in programming. A class defines the structure and behavior (methods and properties) but doesn't actually do anything until you create an instance of it. Similarly, a Docker image is a static blueprint that contains the instructions and dependencies for running an application, but it's not actively running by itself.

Example: A Car class might define attributes like color, model, and speed, but it's not an actual car until you create an instance.

Docker Container: This is like an instance of a class. When you instantiate (run) a class, you get a live object that can interact with the world. Similarly, when you run a Docker image, it becomes a live Docker container that executes the application in an isolated environment.

Example: If you create an instance of the Car class, say a red sports car, you now have a live object that you can drive. Similarly, running a Docker image creates a running container that performs actions based on the instructions in the image.

This analogy helps visualize the difference: the Docker image is the design (class), and the Docker container is the working, running application (instance).

One more way to visualize this is to think of an image as the recipe, and the container as the actual dish created from that recipe.

4. Pulling and Running Images from Docker Hub

Docker Hub is a public registry where developers can share images. You can easily pull existing images from Docker Hub to run in your environment.

For example, to run an Nginx web server, you can pull and run the official Nginx image with just a few commands:

# Pull the Nginx image from Docker Hub
docker pull nginx

# Run the Nginx image as a container
docker run -d -p 8080:80 nginx

In this example:

docker pull nginx: Downloads the latest Nginx image from Docker Hub.
docker run -d -p 8080:80 nginx: Runs the container in detached mode (-d), exposing port 80 in the container to port 8080 on the host.

Now, if you visit http://localhost:8080, you should see the Nginx welcome page.

5. Creating Your Own Docker Image

While pulling images from Docker Hub is useful, developers often need to create custom images. This is where the Dockerfile comes in. A Dockerfile is a script containing a series of instructions on how to build a Docker image.

Here’s an example Dockerfile for a basic Go application:

# Start with a base image
FROM golang:1.18

# Set the working directory inside the container
WORKDIR /app

# Copy the Go module files
COPY go.mod ./
COPY go.sum ./

# Download dependencies
RUN go mod download

# Copy the source code
COPY . .

# Build the application
RUN go build -o myapp

# Command to run the application
CMD ["./myapp"]

Building the Docker Image

Once you have your Dockerfile ready, you can build your Docker image using the following command:

docker build -t my-go-app .

This command tells Docker to build the image from the Dockerfile in the current directory (.) and tag it as my-go-app.

Running the Docker Image

To run the image you just built as a container:

docker run -d -p 8080:8080 my-go-app

This command starts a container from the my-go-app image and maps port 8080 of the container to port 8080 on the host.

6. Managing Docker Images

Docker provides several commands to help manage your images.

Listing images: To see a list of all Docker images on your system, run:

  docker images

Removing images: If you no longer need an image, you can remove it with:

  docker rmi <image-id>

Pruning unused images: Docker also provides a way to clean up unused images:

  docker image prune

This command will remove dangling images (images that are not tagged or associated with any container).

7. Conclusion

Docker images are a fundamental part of the Docker ecosystem, serving as the blueprint for containers. As a developer, understanding how to pull, create, and manage Docker images is crucial for building and shipping applications in a reliable and efficient manner.

Whether you're pulling official images from Docker Hub or creating custom ones using a Dockerfile, Docker images help ensure that your applications run consistently across different environments. With this guide, you should have a solid foundation to start working with Docker images in your development workflow.