DEV Community: Prasad Bhalerao

Bob: Your AI Partner for Kubernetes Operator Development in Go

Prasad Bhalerao — Sat, 14 Mar 2026 18:16:34 +0000

Accelerating backend development velocity through intelligent code assistance, review automation, and architectural guidance

Introduction

Building Kubernetes operators in Go requires deep expertise across multiple domains: understanding the Kubernetes API machinery, implementing robust reconciliation logic, writing idiomatic Go code, and maintaining high code quality across frequent commits. As a backend developer working on operators, you're constantly context-switching between writing controllers, defining CRDs, debugging reconciliation loops, and ensuring your code meets production standards.

This is where Bob comes in an AI software engineering assistant specifically designed to amplify your development capabilities, catch issues before they reach production, and help you ship better operators faster.

Core Capabilities for Operator Development

1. Intelligent Code Review for Go Operators

Bob performs comprehensive code reviews that go beyond basic linting, analyzing your operator code across multiple dimensions:

Reconciliation Logic Analysis

When you raise a PR with changes to your reconciliation loop, Bob examines:

func (r *MyOperatorReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    instance := &myv1.MyResource{}
    if err := r.Get(ctx, req.NamespacedName, instance); err != nil {
        return ctrl.Result{}, client.IgnoreNotFound(err)
    }

    // Bob identifies: Missing status update before return
    if instance.Spec.Replicas == 0 {
        return ctrl.Result{}, nil
    }

    // Bob catches: Potential race condition in status updates
    instance.Status.Phase = "Processing"
    r.Status().Update(ctx, instance)
}

Bob's Review Findings:

Critical: Status update should use Status().Update() with proper error handling
High: Missing requeue logic for transient failures
Medium: No finalizer check for resource cleanup
Low: Consider adding metrics for reconciliation duration

Idiomatic Go Patterns

Bob ensures your operator code follows Go best practices:

// Before - Bob flags this
func (r *Reconciler) createDeployment(name string, replicas int32, image string) error {
    dep := &appsv1.Deployment{
        ObjectMeta: metav1.ObjectMeta{Name: name},
        Spec: appsv1.DeploymentSpec{
            Replicas: &replicas,
            // ... more fields
        },
    }
    return r.Create(context.Background(), dep)
}

// After - Bob suggests this
func (r *Reconciler) createDeployment(ctx context.Context, opts DeploymentOptions) error {
    dep := r.buildDeployment(opts)
    if err := ctrl.SetControllerReference(opts.Owner, dep, r.Scheme); err != nil {
        return fmt.Errorf("failed to set controller reference: %w", err)
    }
    return r.Create(ctx, dep)
}

Bob identifies:

Context should be passed as parameter, not hardcoded
Missing controller reference for garbage collection
Error wrapping for better debugging
Struct-based options pattern for better API design

2. Custom Resource Definition (CRD) Validation

Bob analyzes your CRD definitions and API types for common pitfalls:

// Bob reviews your API types
type MyResourceSpec struct {
    // Bob flags: Missing validation tags
    Replicas int32 `json:"replicas"`

    // Bob suggests: Add omitempty and validation
    Image string `json:"image,omitempty"`

    // Bob catches: Pointer types for optional fields
    Resources corev1.ResourceRequirements `json:"resources"`
}

type MyResourceStatus struct {
    // Bob warns: Status should track conditions
    Phase string `json:"phase,omitempty"`

    // Bob recommends: Use standard condition types
    Conditions []metav1.Condition `json:"conditions,omitempty"`
}

Bob's Recommendations:

type MyResourceSpec struct {
    // +kubebuilder:validation:Minimum=0
    // +kubebuilder:validation:Maximum=100
    Replicas int32 `json:"replicas"`

    // +kubebuilder:validation:Required
    // +kubebuilder:validation:Pattern=`^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*\/[a-z0-9]([-a-z0-9]*[a-z0-9])?$`
    Image string `json:"image"`

    // +optional
    Resources *corev1.ResourceRequirements `json:"resources,omitempty"`
}

3. Controller Pattern Implementation

Bob helps implement robust controller patterns with proper error handling and retry logic:

// Bob assists in implementing the full reconciliation pattern
func (r *MyOperatorReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    log := log.FromContext(ctx)

    // Fetch the resource
    instance := &myv1.MyResource{}
    if err := r.Get(ctx, req.NamespacedName, instance); err != nil {
        if apierrors.IsNotFound(err) {
            log.Info("Resource not found, likely deleted")
            return ctrl.Result{}, nil
        }
        return ctrl.Result{}, fmt.Errorf("failed to get resource: %w", err)
    }

    // Bob suggests: Handle deletion with finalizers
    if !instance.DeletionTimestamp.IsZero() {
        return r.handleDeletion(ctx, instance)
    }

    // Bob recommends: Add finalizer if not present
    if !controllerutil.ContainsFinalizer(instance, myFinalizer) {
        controllerutil.AddFinalizer(instance, myFinalizer)
        if err := r.Update(ctx, instance); err != nil {
            return ctrl.Result{}, fmt.Errorf("failed to add finalizer: %w", err)
        }
        return ctrl.Result{Requeue: true}, nil
    }

    // Bob ensures: Proper status condition management
    defer func() {
        if err := r.updateStatus(ctx, instance); err != nil {
            log.Error(err, "Failed to update status")
        }
    }()

    // Reconciliation logic
    if err := r.reconcileDeployment(ctx, instance); err != nil {
        r.setCondition(instance, "Ready", metav1.ConditionFalse, "ReconcileError", err.Error())
        return ctrl.Result{RequeueAfter: 30 * time.Second}, err
    }

    r.setCondition(instance, "Ready", metav1.ConditionTrue, "ReconcileSuccess", "All resources reconciled")
    return ctrl.Result{RequeueAfter: 5 * time.Minute}, nil
}

4. Testing Strategy and Implementation

Bob helps you write comprehensive tests for your operators:

// Bob suggests table-driven tests for reconciliation scenarios
func TestReconcile(t *testing.T) {
    tests := []struct {
        name           string
        existingObjs   []client.Object
        resource       *myv1.MyResource
        expectedResult ctrl.Result
        expectedError  bool
        validate       func(t *testing.T, c client.Client)
    }{
        {
            name: "creates deployment when missing",
            resource: &myv1.MyResource{
                ObjectMeta: metav1.ObjectMeta{Name: "test", Namespace: "default"},
                Spec: myv1.MyResourceSpec{Replicas: 3, Image: "nginx:latest"},
            },
            expectedResult: ctrl.Result{},
            expectedError:  false,
            validate: func(t *testing.T, c client.Client) {
                dep := &appsv1.Deployment{}
                err := c.Get(context.Background(), types.NamespacedName{
                    Name: "test", Namespace: "default",
                }, dep)
                assert.NoError(t, err)
                assert.Equal(t, int32(3), *dep.Spec.Replicas)
            },
        },
        // Bob helps add more test cases
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            // Test implementation with envtest
        })
    }
}

Bob also suggests:

Integration tests using envtest
Mock client tests for unit testing
E2E tests with real Kubernetes clusters
Chaos testing for reconciliation resilience

5. Git Workflow Optimization

For developers making frequent commits and PRs, Bob streamlines the workflow:

Pre-Commit Analysis

Before you commit, Bob can analyze your changes:

# Bob examines your git diff
$ git diff HEAD

# Bob identifies:
- 3 files with potential issues
- 2 missing unit tests for new functions
- 1 breaking API change in CRD
- 4 opportunities for code simplification

Pull Request Description Generation

Bob automatically generates comprehensive PR descriptions:

## Changes
- Implemented retry logic in reconciliation loop with exponential backoff
- Added finalizer handling for proper resource cleanup
- Updated CRD with validation webhooks for spec fields
- Refactored deployment creation logic into separate function

## Technical Details
- Modified `Reconcile()` to handle transient API server errors
- Added `handleDeletion()` method with proper finalizer removal
- Implemented `SetupWebhookWithManager()` for admission control
- Extracted deployment logic to improve testability

## Testing
- Added unit tests for reconciliation scenarios (coverage: 87%)
- Verified finalizer behavior with integration tests
- Tested webhook validation with invalid resource specs

## Breaking Changes
None

## Migration Notes
Existing resources will be automatically updated with finalizers on next reconciliation

Commit Message Suggestions

Bob helps write meaningful commit messages following conventional commits:

feat(controller): add exponential backoff for reconciliation retries

- Implement retry logic with configurable max attempts
- Add jitter to prevent thundering herd
- Update metrics to track retry counts

Fixes #123

6. Debugging Assistance

When your operator misbehaves in production, Bob helps debug:

// Bob analyzes logs and suggests debugging improvements
log.Info("Reconciling resource", "name", req.Name)

// Bob recommends adding structured logging:
log.Info("Reconciling resource",
    "name", req.Name,
    "namespace", req.Namespace,
    "generation", instance.Generation,
    "resourceVersion", instance.ResourceVersion,
)

// Bob identifies missing error context:
if err := r.Create(ctx, deployment); err != nil {
    return ctrl.Result{}, err  // Bob flags: Add context
}

// Bob suggests:
if err := r.Create(ctx, deployment); err != nil {
    return ctrl.Result{}, fmt.Errorf("failed to create deployment %s/%s: %w",
        deployment.Namespace, deployment.Name, err)
}

7. Performance Optimization

Bob identifies performance bottlenecks in operator code:

// Bob flags: Inefficient list operations
func (r *Reconciler) cleanupOrphanedResources(ctx context.Context) error {
    deployments := &appsv1.DeploymentList{}
    if err := r.List(ctx, deployments); err != nil {  // Lists ALL deployments
        return err
    }
    // Process deployments...
}

// Bob suggests: Use label selectors
func (r *Reconciler) cleanupOrphanedResources(ctx context.Context, owner *myv1.MyResource) error {
    deployments := &appsv1.DeploymentList{}
    if err := r.List(ctx, deployments, 
        client.InNamespace(owner.Namespace),
        client.MatchingLabels{"app.kubernetes.io/managed-by": "myoperator"},
    ); err != nil {
        return err
    }
    // Process only relevant deployments
}

Bob also identifies:

Unnecessary API calls in reconciliation loops
Missing caching strategies
Inefficient watch predicates
Resource leak in goroutines

8. Security Best Practices

Bob ensures your operator follows security best practices:

// Bob catches security issues
func (r *Reconciler) reconcileSecret(ctx context.Context, instance *myv1.MyResource) error {
    secret := &corev1.Secret{
        ObjectMeta: metav1.ObjectMeta{
            Name: instance.Name + "-secret",
            Namespace: instance.Namespace,
        },
        StringData: map[string]string{
            "password": "hardcoded-password",  // Bob flags: CRITICAL security issue
        },
    }
    return r.Create(ctx, secret)
}

// Bob recommends
func (r *Reconciler) reconcileSecret(ctx context.Context, instance *myv1.MyResource) error {
    // Generate secure random password
    password, err := generateSecurePassword(32)
    if err != nil {
        return fmt.Errorf("failed to generate password: %w", err)
    }

    secret := &corev1.Secret{
        ObjectMeta: metav1.ObjectMeta{
            Name: instance.Name + "-secret",
            Namespace: instance.Namespace,
        },
        StringData: map[string]string{
            "password": password,
        },
    }

    if err := ctrl.SetControllerReference(instance, secret, r.Scheme); err != nil {
        return err
    }

    return r.Create(ctx, secret)
}

9. Architectural Guidance

Bob provides architectural recommendations for complex operators:

Multi-Controller Architecture:

// Bob suggests splitting complex operators into multiple controllers

// Primary controller for main resource
type MyResourceReconciler struct {
    client.Client
    Scheme *runtime.Scheme
}

// Separate controller for child resource management
type DeploymentReconciler struct {
    client.Client
    Scheme *runtime.Scheme
}

// Bob recommends: Use owner references for automatic cleanup
// Bob suggests: Implement proper RBAC for each controller
// Bob advises: Consider using controller-runtime's predicate filters

Event-Driven Reconciliation:

// Bob helps implement efficient watch predicates
func (r *MyResourceReconciler) SetupWithManager(mgr ctrl.Manager) error {
    return ctrl.NewControllerManagedBy(mgr).
        For(&myv1.MyResource{}).
        Owns(&appsv1.Deployment{}).
        WithEventFilter(predicate.Funcs{
            UpdateFunc: func(e event.UpdateEvent) bool {
                // Bob suggests: Only reconcile on spec changes
                oldObj := e.ObjectOld.(*myv1.MyResource)
                newObj := e.ObjectNew.(*myv1.MyResource)
                return !reflect.DeepEqual(oldObj.Spec, newObj.Spec)
            },
        }).
        Complete(r)
}

Real-World Impact: Development Velocity Metrics

Backend developers using Bob for operator development report:

40% reduction in code review cycle time
60% fewer production bugs related to reconciliation logic
3x faster implementation of new CRDs and controllers
50% improvement in test coverage
Zero hardcoded credentials reaching production
Consistent code quality across frequent commits

Integration with Development Workflow

During Development

Write code with Bob suggesting idiomatic patterns
Run local tests with Bob identifying edge cases
Commit changes with Bob validating commit messages
Push to remote with confidence

During Code Review

Create PR with Bob-generated description
Automated review by Bob identifies issues
Address findings with Bob's suggested fixes
Merge with confidence knowing code quality is maintained

During Debugging

Analyze logs with Bob identifying patterns
Examine reconciliation with Bob suggesting improvements
Test fixes with Bob recommending test cases
Deploy confidently with Bob's validation

Advanced Features for Operator Development

Kubebuilder Integration

Bob understands Kubebuilder markers and helps maintain them:

// Bob ensures proper RBAC markers
//+kubebuilder:rbac:groups=mygroup.example.com,resources=myresources,verbs=get;list;watch;create;update;patch;delete
//+kubebuilder:rbac:groups=mygroup.example.com,resources=myresources/status,verbs=get;update;patch
//+kubebuilder:rbac:groups=mygroup.example.com,resources=myresources/finalizers,verbs=update
//+kubebuilder:rbac:groups=apps,resources=deployments,verbs=get;list;watch;create;update;patch;delete

// Bob validates webhook markers
//+kubebuilder:webhook:path=/validate-mygroup-example-com-v1-myresource,mutating=false,failurePolicy=fail,groups=mygroup.example.com,resources=myresources,verbs=create;update,versions=v1,name=vmyresource.kb.io,sideEffects=None,admissionReviewVersions=v1

Operator SDK Compatibility

Bob works seamlessly with Operator SDK patterns:

// Bob helps implement Operator SDK patterns
func (r *MyResourceReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    // Bob suggests using the SDK's reconcile helpers
    result, err := r.reconcileResource(ctx, req)
    if err != nil {
        // Bob recommends proper error handling with SDK patterns
        return reconcile.Result{}, err
    }
    return result, nil
}

Metrics and Observability

Bob helps implement comprehensive metrics:

// Bob suggests adding Prometheus metrics
var (
    reconcileCounter = prometheus.NewCounterVec(
        prometheus.CounterOpts{
            Name: "myoperator_reconcile_total",
            Help: "Total number of reconciliations",
        },
        []string{"resource", "result"},
    )

    reconcileDuration = prometheus.NewHistogramVec(
        prometheus.HistogramOpts{
            Name: "myoperator_reconcile_duration_seconds",
            Help: "Duration of reconciliation",
        },
        []string{"resource"},
    )
)

// Bob helps instrument your code
func (r *MyResourceReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    start := time.Now()
    defer func() {
        reconcileDuration.WithLabelValues(req.Name).Observe(time.Since(start).Seconds())
    }()

    // Reconciliation logic...

    reconcileCounter.WithLabelValues(req.Name, "success").Inc()
    return ctrl.Result{}, nil
}

Conclusion

Building production-grade Kubernetes operators in Go requires expertise across multiple domains from understanding the Kubernetes API machinery to implementing robust reconciliation logic, maintaining code quality, and ensuring security. Bob serves as your AI pair programmer, bringing deep knowledge of operator patterns, Go best practices, and Kubernetes internals to every commit and pull request.

Whether you're implementing a new CRD, debugging a reconciliation loop, optimizing performance, or ensuring your operator follows security best practices, Bob provides intelligent assistance that accelerates development velocity while maintaining high code quality. For backend developers working on operators who make frequent commits and raise regular pull requests, Bob becomes an indispensable part of the development workflow catching issues early, suggesting improvements, and helping ship better operators faster.

The result? More time focusing on business logic, less time debugging production issues, and confidence that every commit meets production standards.

Meet Bob: Your AI-Powered Software Engineering Partner

Prasad Bhalerao — Sat, 14 Mar 2026 17:59:55 +0000

Introduction

Hello! I'm Bob, a highly skilled AI software engineer designed to be your collaborative coding companion. I'm not just another chatbot I'm a sophisticated development assistant with deep knowledge across programming languages, frameworks, design patterns, and industry best practices.

What Makes Me Different

🎯 Task-Oriented Approach

I don't engage in endless conversations. When you give me a task, I break it down into clear, actionable steps and work through them methodically. My goal is to accomplish your objectives efficiently, not to chat.

🛠️ Powerful Tool Arsenal

I have access to a comprehensive suite of development tools that allow me to:

Read and analyze code across your entire project
Write and modify files with surgical precision using targeted diffs
Execute commands directly in your terminal
Search codebases using regex patterns to find specific implementations
Navigate file structures to understand project organization
Create pull requests and analyze GitHub issues
Review code and identify potential issues across multiple categories

🧠 Deep Technical Knowledge

I possess extensive expertise in:

Multiple programming languages (Python, JavaScript, TypeScript, Go, Rust, Java, C++, and more)
Modern frameworks and libraries (React, Vue, Angular, Django, Flask, Express, Next.js, etc.)
Design patterns and architectural principles
DevOps practices and CI/CD workflows
Database design and optimization
Security best practices
Performance optimization techniques

How I Work

Step-by-Step Execution

I approach every task iteratively:

Analyze your requirements and the project context
Plan the necessary steps to accomplish the goal
Execute each step using the appropriate tools
Verify success before moving to the next step
Complete the task and present the results

Context-Aware Development

Before making any changes, I:

Examine your project's file structure
Understand existing code patterns and conventions
Consider dependencies and relationships between components
Ensure compatibility with your development environment

Multiple Modes of Operation

I operate in different modes optimized for specific tasks:

💻 Code Mode: For writing, modifying, and refactoring code
🛠️ Advanced Mode: Code mode with additional tools like MCP and Browser access
📝 Plan Mode: For designing architecture and strategizing before implementation
❓ Ask Mode: For explanations, documentation, and technical questions
🔀 Orchestrator Mode: For complex, multi-step projects requiring coordination

What I Can Do For You

Code Development

Implement new features from scratch
Refactor existing code for better maintainability
Fix bugs and resolve issues
Optimize performance bottlenecks
Add comprehensive error handling

Code Review

I can analyze your code and identify issues across multiple categories:

Maintainability: Magic numbers, naming conventions, code complexity
Security: Hardcoded credentials, input validation, dependency vulnerabilities
Performance: Inefficient algorithms, memory leaks, blocking operations
Functionality: Edge cases, error handling, race conditions
Style: Formatting consistency, documentation quality

Project Management

Create and manage TODO lists for complex tasks
Generate pull request descriptions from code diffs
Analyze GitHub issues and align changes with requirements
Coordinate multi-step workflows

System Operations

Execute CLI commands
Set up development environments
Configure build tools and deployment pipelines
Manage dependencies and packages

My Principles

🎯 Efficiency First

I use the most appropriate tool for each task. For example, I prefer list_files over running ls commands, and I use targeted diffs instead of rewriting entire files when possible.

📊 Transparency

I explain what I'm doing and why. Every command, every file change, every decision is communicated clearly so you understand the process.

✅ Verification

I never assume success. After each operation, I wait for confirmation before proceeding to ensure everything works as expected.

🔒 Safety

I follow best practices for security, never hardcode sensitive information, and always consider the implications of changes across your codebase.

📚 Completeness

When I create or modify files, I provide complete, working code no placeholders, no "rest of code unchanged" comments. What you see is what you get.

Working With Me

Clear Communication

I respond directly and technically. You won't hear "Great!" or "Certainly!" just clear, actionable information about what I'm doing.

Minimal Questions

I use available tools to gather information rather than asking you unnecessary questions. When I do need clarification, I provide specific, actionable suggestions to choose from.

Final Results

When I complete a task, I present the results clearly without ending with questions or offers for further assistance. The task is done.

Limitations and Boundaries

I'm powerful, but I have constraints:

I operate from your current workspace directory
I can't browse the internet in standard Code mode (only in Advanced mode)
I process tasks sequentially, one tool at a time
I require confirmation after each operation before proceeding
Some modes restrict which files I can edit

Conclusion

I'm Bob your AI software engineering partner built for serious development work. I combine deep technical knowledge with practical tools to help you build, maintain, and improve software projects efficiently. I'm not here for small talk; I'm here to get things done.

Ready to work together? Give me a task, and let's build something great.

Supercharging Your Docker Workflow with Ask Gordon, Docker's AI Assistant 🚀

Prasad Bhalerao — Sat, 08 Feb 2025 05:17:56 +0000

The Struggle of Managing Docker Efficiently 😅

Working with Docker can be a breeze—but let’s be honest, it also comes with its fair share of challenges. Whether it’s troubleshooting a stubborn container, optimizing your Dockerfiles, or figuring out the best way to run an image, you often find yourself sifting through documentation, Stack Overflow, and random GitHub issues.

Wouldn’t it be great if Docker had an AI-powered assistant built right into your workflow? 🤔

Meet Ask Gordon – Your AI Assistant for Docker 🌟

Docker has introduced Ask Gordon, an AI-powered assistant embedded directly into Docker Desktop and the Docker CLI. Think of it as your personal Docker guru, ready to help troubleshoot issues, optimize configurations, and streamline your workflow—all without leaving your terminal or Docker UI.

✅ Need help fixing a crashed container? Ask Gordon!

✅ Want to improve your Dockerfile? Gordon’s got suggestions.

✅ Not sure how to run an image properly? Gordon can guide you.

Let’s dive into how Ask Gordon can supercharge your Docker workflow. 🚀

🔍 What Is Ask Gordon?

Ask Gordon is a suite of AI-driven features designed to make Docker easier and more intuitive. It integrates directly with Docker tools, understanding your local setup—including your source code, containers, and images—so that its responses are practical and tailored to your environment.

This AI-powered assistant is currently in Beta and not enabled by default, but once activated, it becomes a powerful ally in your Docker journey.

What Can Ask Gordon Do?

🔹 Provide contextual help for errors and troubleshooting

🔹 Optimize Dockerfiles for performance and security

🔹 Offer best practices for running and managing containers

🔹 Analyze your images and suggest improvements

🚀 Getting Started with Ask Gordon

Requires: Docker Desktop 4.38.0 or later

Step 1: Enable Ask Gordon in Docker Desktop

Ask Gordon isn’t enabled by default, so you’ll need to activate it manually:

1️⃣ Sign in to Docker Desktop

Open Docker Desktop and click Sign in.
Complete the authentication process in your browser.

2️⃣ Enable the Feature

Navigate to Settings > Features in Development.
Check the Enable Docker AI box.
Accept the terms and click Apply & Restart.

Step 2: Using Ask Gordon in Docker Desktop

Once enabled, Ask Gordon will be accessible via:

The Ask Gordon chat window in Docker Desktop
Various parts of the UI (whenever you see the ✨ sparkles icon)

Clicking the sparkles icon provides context-aware assistance, offering real-time insights and fixes based on your current view.

Step 3: Using Ask Gordon in the CLI

Prefer working in the terminal? No problem! You can use Ask Gordon directly from the command line:

$ docker ai "Can you optimize my Dockerfile?"

🛠️ Example Workflows with Ask Gordon

📌 Troubleshooting a Crashed Container

Ever had a container fail to start with a cryptic error message? Instead of Googling for hours, just ask Gordon!

Running PostgreSQL Without a Password

$ docker run postgres
Error: Database is uninitialized and superuser password is not specified.
       You must specify POSTGRES_PASSWORD to a non-empty value.

👀 Open Docker Desktop, go to the Containers view, and click the ✨ Ask Gordon icon next to the failed container. Gordon will analyze the error and suggest the proper fix:

$ docker run -e POSTGRES_PASSWORD=securepassword postgres

💡 Final Thoughts: Why You Should Try Ask Gordon Today 🚀

Docker’s Ask Gordon AI assistant takes the guesswork out of container management. Whether you’re troubleshooting errors, optimizing Dockerfiles, or just getting started with a new image, Gordon streamlines your workflow and saves you valuable time.

Why It’s a Game-Changer

✅ Saves time – No more endless Googling for answers.

✅ Context-aware – Gordon understands your Docker setup.

✅ Enhances productivity – Focus on coding, not debugging.

✅ Integrated into Docker Desktop & CLI – No extra tools needed.

Ask Gordon is still in Beta, but it’s already proving to be an invaluable tool for Docker users. Give it a try today and supercharge your Docker workflow! ⚡

Happy coding! 🚀

Docker-in-Docker (DinD): Run Containers Inside Containers Like a Pro! 😏

Prasad Bhalerao — Fri, 24 Jan 2025 08:58:36 +0000

Ever wondered if you could run containers inside other containers? Welcome to Docker-in-Docker (DinD)—where containers go full-on Inception mode! 🚀

What is Docker-in-Docker (DinD)?

Docker-in-Docker (DinD) is a powerful technique that enables you to run Docker inside a Docker container. Think of it like Russian nesting dolls—containers within containers, each with its own isolated environment.

This approach is invaluable for:

✔️ Building and testing Docker images in a clean, controlled setup

✔️ Running CI/CD pipelines inside containers

✔️ Deploying containerized workloads in Kubernetes

✔️ GPU-powered applications with NVIDIA Docker support

Let’s explore how DinD can supercharge your development workflow! 🚀

Why Use Docker-in-Docker (DinD)?

DinD isn’t just a cool concept—it solves real-world problems! Here’s why developers love it:

1️⃣ Effortless Testing & Building

Run Docker inside a container for consistent, reproducible builds—eliminating the dreaded "It works on my machine" issue.

2️⃣ Seamless CI/CD Pipelines

Integrate Docker-in-Docker into your DevOps workflow to streamline builds and deployments across environments.

3️⃣ Kubernetes Compatibility

Need containers inside Kubernetes pods? With DinD, you can launch nested Docker environments inside Kubernetes clusters.

4️⃣ NVIDIA GPU Support for AI & ML

Run GPU workloads inside DinD using NVIDIA’s Container Toolkit, unlocking AI/ML training within nested containers.

How to Set Up Docker-in-Docker (DinD) on Ubuntu

Setting up DinD is quick and easy! Follow this step-by-step guide to get started.

Step 1: Install Docker

If Docker isn’t installed yet, install it with this one-liner:

curl -fsSL https://get.docker.com | sh

Step 2: Create a Dockerfile for Docker-in-Docker

Here’s a Dockerfile to set up a DinD container with NVIDIA GPU support:

# Base image: Ubuntu 24.04  
FROM ubuntu:24.04  

# Install required dependencies  
RUN apt-get update \
    && apt-get install -y --no-install-recommends \
    ca-certificates \
    curl \
    gnupg \
    iptables \
    supervisor  

# Install Docker  
RUN curl -fsSL https://get.docker.com | sh  

# Install NVIDIA Container Toolkit for GPU support  
RUN curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \
    && curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
    sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
    tee /etc/apt/sources.list.d/nvidia-container-toolkit.list \
    && apt-get update \
    && apt-get install -y nvidia-container-toolkit \
    && nvidia-ctk runtime configure --runtime=docker \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*  

# Copy necessary files  
COPY entrypoint.sh /usr/local/bin/  
COPY supervisor/ /etc/supervisor/conf.d/  

# Grant execution permission  
RUN chmod +x /usr/local/bin/entrypoint.sh  

# Set up Docker volume  
VOLUME /var/lib/docker  

# Entrypoint script  
ENTRYPOINT ["/usr/local/bin/entrypoint.sh"]  

# Default command  
CMD ["bash"]

Step 3: Entrypoint Script

Every container needs a startup guide. Here’s the entrypoint script for DinD:

#!/bin/bash  

function wait_for_process() {
    local max_time_wait=30  
    local process_name="$1"  
    local waited_sec=0  

    while ! pgrep "$process_name" >/dev/null && ((waited_sec < max_time_wait)); do  
        echo "Waiting for $process_name to start..."  
        sleep 1  
        ((waited_sec++))  
        if ((waited_sec >= max_time_wait)); then  
            return 1  
        fi  
    done  
    return 0  
}  

echo "Starting Supervisor..."  
supervisord -n >> /dev/null 2>&1 &  

echo "Waiting for Docker Daemon (dockerd)..."  
wait_for_process dockerd  
if [ $? -ne 0 ]; then  
    echo "Error: dockerd did not start in time"  
    exit 1  
fi  

exec "$@"

Step 4: Supervisor Configuration

This Supervisor config file keeps dockerd running inside the container:

[program:dockerd]  
command=/usr/bin/dockerd  
autostart=true  
autorestart=true  
stderr_logfile=/var/log/dockerd.err.log  
stdout_logfile=/var/log/dockerd.out.log

Run Docker-in-Docker (DinD) in a Container

You’re all set! Build and run your DinD container with these commands:

docker build -t dind-magic .  
docker run -it --privileged --gpus all --name dind-magic dind-magic

Too Busy to Set It Up? We’ve Got You Covered!

Skip the setup and run our prebuilt DinD container with one command:

docker run -it --rm --privileged ghcr.io/prasad89/dind-ubuntu-nvidia

🔥 No installation, no hassle—just pure Docker-in-Docker magic!

🔗 Check out our GitHub repo for more:

👉 DinD Ubuntu NVIDIA Repository

Final Thoughts

Docker-in-Docker unlocks new levels of flexibility for testing, CI/CD, Kubernetes, and GPU workloads. Whether you’re a DevOps engineer or an AI researcher, DinD provides a powerful, scalable solution for your containerized needs.

Ready to experiment? Try DinD today and let your containers nest within containers—creating a world of infinite possibilities! 🌎🐳

How to Publish a Python Package on PyPI Without Exposing Your Source Code 😉

Prasad Bhalerao — Thu, 23 Jan 2025 12:03:41 +0000

So, you've got a super-secret Python package that you want to share with the world—but without exposing your source code. The good news? You can publish your package on PyPI while keeping your code hidden. This guide will show you how to use Cython and Poetry to protect your code like a ninja in the shadows.

Why Hide Your Source Code?

There are many reasons why developers might want to conceal their Python source code:

Prevent reverse engineering of proprietary algorithms.
Protect intellectual property from competitors.
Ensure security by keeping sensitive implementation details private.
Reduce code tampering risks in production environments.

While Python is an interpreted language and usually exposes source code, we can use Cython to convert .py files into compiled binary files, making the original code inaccessible.

Step 1: Setting Up Cython for Source Code Protection

Cython is a tool that compiles Python code into C and then generates a binary (.so or .pyd) file. This means that instead of distributing .py files, you share compiled binaries.

To get started, install Cython in your development environment:

poetry add --dev Cython

Then, configure Poetry to use a custom build script instead of generating a default setup.py file.

Modify `pyproject.toml` for Custom Builds

Add the following to your pyproject.toml file:

[tool.poetry.build]
script = "build.py"
generate-setup-file = false

Now, let's create build.py, our custom script that will compile Python files into binary form.

Step 2: Writing the `build.py` Script

This script automates the conversion of Python files into C extensions:

import multiprocessing
from pathlib import Path
from typing import List
from setuptools import Extension, Distribution
from Cython.Build import cythonize
from Cython.Distutils.build_ext import new_build_ext as cython_build_ext

SOURCE_DIR = Path("SRC")  # Replace with your source directory
BUILD_DIR = Path("BUILD")

def get_extension_modules() -> List[Extension]:
    return [
        Extension(
            name=str(py_file.with_suffix("")).replace("/", "."),
            sources=[str(py_file)]
        )
        for py_file in SOURCE_DIR.rglob("*.py")
    ]

def cythonize_helper(extension_modules: List[Extension]) -> List[Extension]:
    return cythonize(
        module_list=extension_modules,
        build_dir=BUILD_DIR,
        nthreads=multiprocessing.cpu_count() * 2,
        compiler_directives={"language_level": "3"}
    )

extension_modules = cythonize_helper(get_extension_modules())
distribution = Distribution({"ext_modules": extension_modules, "cmdclass": {"build_ext": cython_build_ext}})

build_ext_cmd = distribution.get_command_obj("build_ext")
build_ext_cmd.ensure_finalized()
build_ext_cmd.inplace = 1
build_ext_cmd.run()

This script:

Finds all .py files in the source directory.
Converts them into compiled binaries using Cython.
Prepares them for distribution via Poetry.

Step 3: Exclude Source Code from Distribution

By default, Poetry includes all files in your source directory. To prevent .py files from being uploaded to PyPI, modify pyproject.toml:

[tool.poetry]
exclude = ["SRC/**/*.py"]  # Replace SRC with your actual source directory
include = ["SRC/**/*.so"]  # Include compiled files

This ensures that only compiled binaries are included in the final package.

Step 4: Building & Publishing the Secure Package

Now that everything is set up, build your package using Poetry:

poetry build --format wheel

Verify that the package contains only .so files (or .pyd for Windows) by extracting the .whl file:

unzip dist/*.whl -d check_package
ls check_package

If everything looks good, publish your package to PyPI:

poetry publish --build

Note: Do not publish an sdist (source distribution) package, as it includes uncompiled source code. Stick to wheel packages (.whl).

Step 5: Supporting Multiple Platforms & Python Versions

Wheel packages contain pre-compiled code, so you must build different versions for different Python versions and OS platforms. Popular projects like TensorFlow use this approach.

To automate this, use GitHub Actions or another CI/CD pipeline with a build matrix:

Build Linux, Windows, and macOS versions.
Compile for Python 3.7, 3.8, 3.9, 3.10, and 3.11.

A simple GitHub Actions workflow example:

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: ["3.7", "3.8", "3.9", "3.10", "3.11"]
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-python@v2
        with:
          python-version: ${{ matrix.python-version }}
      - run: poetry install
      - run: poetry build --format wheel

This generates multiple wheels for different Python versions, ready to be uploaded to PyPI.

Final Thoughts & Resources

By following this guide, you've successfully:
✅ Protected your Python source code using Cython.

✅ Configured Poetry to exclude uncompiled .py files.

✅ Created a custom build process using build.py.

✅ Published your package securely on PyPI.

Need a working example? Check out the sample repository: GitHub - prasad89/pypi-publish-secure. If you have questions or need help, feel free to open an issue there!

If this guide helped you, share it with fellow Python developers! 🚀

Supercharging Multi-Architecture - Docker Builds with Docker Build Cloud in GitHub Actions 🚀

Prasad Bhalerao — Thu, 23 Jan 2025 05:35:41 +0000

The Struggle of Multi-Architecture Builds in GitHub Actions 😅

Building multi-architecture Docker images (linux/amd64, linux/arm64, etc.) in GitHub Actions can be frustrating. You might have struggled with buildx, faced challenges with QEMU virtualization, and encountered timeouts because of runner limitations. Managing multi-stage Dockerfiles, optimizing caching, and ensuring seamless builds across different platforms can be complex and time-consuming.

And let’s be honest—missing a flag or platform, only to have your build fail after an hour, is beyond frustrating. 😬

Enter Docker Build Cloud 🌥️ – The Game-Changer for Multi-Arch Builds

Docker Build Cloud simplifies multi-architecture Docker builds by offloading the process to the cloud. Say goodbye to QEMU setup headaches, runner limitations, and long build times. Here’s what Docker Build Cloud offers:

✅ Effortless multi-architecture builds (linux/amd64, linux/arm64, etc.)

✅ No manual QEMU configuration for cross-platform builds

✅ Faster builds with scalable cloud resources—no timeouts!

✅ Direct image push to Docker Hub or GitHub Container Registry (GHCR)

Ready to streamline GitHub Actions automation for Docker builds? Let’s dive in! 🚀

Step 1: Prerequisites

Before configuring Docker Build Cloud in GitHub Actions, ensure you have:

A Docker Account: Sign up for Docker Build Cloud.
GitHub Secrets Setup: Add your Docker Hub username and Personal Access Token (PAT) as secrets in GitHub.
Docker Build Cloud Builder: Create a builder instance and note the endpoint URL.

Step 2: Configure GitHub Actions Workflow for Multi-Architecture Builds

Create a GitHub Actions workflow in .github/workflows/build.yml to leverage Docker Build Cloud.

Key Steps in the Workflow:

Trigger on push events to the main branch.
Set up Docker Buildx with the cloud driver.
Build and push the multi-architecture image to a container registry.

Here’s the optimized GitHub Actions YAML configuration:

name: Multi-Arch Docker Build in the Cloud 🌥️

on:
  push:
    branches:
      - "main"

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}
  IMAGE_TAG: latest

jobs:
  build_and_push:
    runs-on: ubuntu-24.04
    permissions:
      contents: read
      packages: write

    steps:
      - name: Log in to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USER }}
          password: ${{ secrets.DOCKER_PAT }}

      - name: Log into GitHub Container Registry
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Checkout Repository Code
        uses: actions/checkout@v4

      - name: Set up Docker Buildx for Cloud
        uses: docker/setup-buildx-action@v3
        with:
          driver: cloud
          endpoint: "ORG/default"  # Replace with your Docker Build Cloud endpoint
          install: true

      - name: Build and Push Multi-Arch Docker Image
        uses: docker/build-push-action@v6
        with:
          context: .
          platforms: linux/amd64,linux/arm64  # Define target architectures
          tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ env.IMAGE_TAG }}
          push: true

      - name: Image Pushed Successfully ✅
        run: echo "Docker image ${REGISTRY}/${IMAGE_NAME}:${IMAGE_TAG} pushed successfully!"

Step 3: Configure GitHub Secrets

Before pushing your build, set up GitHub Secrets for authentication:

Navigate to Repository Settings > Secrets.
Add the following secrets:
- DOCKER_USER: Your Docker Hub username.
- DOCKER_PAT: Your Docker Hub Personal Access Token.
- GITHUB_TOKEN: Automatically provided by GitHub (no need to set manually).

Step 4: Push and Automate Multi-Architecture Builds

Once you push your changes to the main branch, GitHub Actions triggers the workflow automatically. You can monitor the build process in the Actions tab.

If everything works correctly, you should see:

Docker image ghcr.io/your-org/your-repo:latest pushed successfully!

Boom! 🎉 You’ve just automated multi-architecture Docker builds in GitHub Actions using Docker Build Cloud! 🚀

Why Use Docker Build Cloud for Multi-Arch Builds?

🔥 Faster Builds: Cloud-native builds scale horizontally, reducing wait times.

🛠️ Simplified Configuration: No need for manual QEMU setup or local dependencies.

⚡ Automatic Build Caching: Avoids unnecessary rebuilds and speeds up CI/CD workflows.

🔗 Seamless GitHub Actions Integration: Easily integrates with existing CI/CD pipelines.

Conclusion: Automate Multi-Architecture Docker Builds with Ease 🚀

Integrating Docker Build Cloud with GitHub Actions eliminates the complexity of multi-architecture builds. It optimizes Docker image building, speeds up CI/CD pipelines, and removes manual overhead.

No more struggling with runner limitations, QEMU setups, or long build times. Docker Build Cloud does the heavy lifting so you can focus on shipping great software. 🚀