Simple Eiffel - Docker

[Liberty Lover]

Docker library is here:

  🐳 Announcing simple_docker v1.1.0 — Docker Container Management for Eiffel

  December 15, 2025

  We're excited to announce simple_docker, a new addition to the Simple Eiffel ecosystem that brings programmatic Docker container management to Eiffel applications.

  What is simple_docker?

  simple_docker enables Eiffel developers to build, run, and manage Docker containers directly from Eiffel code—no shell commands required. It communicates with the Docker Engine API through Windows named pipes, providing full Design by Contract guarantees.

  create client.make

  if client.ping then
      create spec.make ("alpine:latest")
      spec.set_name ("my-app")
          .add_port (80, 8080)
          .add_env ("DEBUG", "true")
          .set_memory_limit (512 * 1024 * 1024)
          .set_restart_policy ("unless-stopped").do_nothing

      if attached client.run_container (spec) as c then
          print ("Container running: " + c.short_id + "%N")
      end
  end

  Features

  | Category           | Capabilities                                                        |
  |--------------------|---------------------------------------------------------------------|
  | Containers         | Create, start, stop, pause, restart, kill, remove, logs, wait, exec |
  | Images             | List, pull, inspect, exists, remove                                 |
  | Networks           | Create, list, connect, disconnect, remove, prune                    |
  | Volumes            | Create, list, remove with driver configuration                      |
  | Dockerfile Builder | Fluent API for generating Dockerfiles with multi-stage support      |

  Technical Highlights

  - 4,291 lines of Eiffel source code across 9 classes
  - 38 tests passing including 10 "cookbook verification" tests that dogfood our documentation examples
  - Resilient IPC with rescue/retry logic—automatically retries on transient connection failures
  - Strong contracts with preconditions, postconditions, and invariants on all operations
  - IUARC 5-document standard documentation (Overview, User Guide, API Reference, Architecture, Cookbook)

  API Classes

  | Class              | Purpose                                      |
  |--------------------|----------------------------------------------|
  | DOCKER_CLIENT      | Main facade for all Docker operations        |
  | DOCKER_CONTAINER   | Container representation with state tracking |
  | DOCKER_IMAGE       | Image representation with tags and metadata  |
  | DOCKER_NETWORK     | Network operations and queries               |
  | DOCKER_VOLUME      | Volume management with driver support        |
  | CONTAINER_SPEC     | Fluent builder for container configuration   |
  | DOCKERFILE_BUILDER | Programmatic Dockerfile generation           |
  | CONTAINER_STATE    | State constants and transition queries       |
  | DOCKER_ERROR       | Error classification with retry detection    |

  Example: Multi-stage Dockerfile Generation

  create builder.make_multi_stage

  builder.from_image_as ("golang:1.21", "builder")
      .run ("go build -o /app main.go")
      .new_stage
      .from_image ("alpine:latest")
      .copy_from ("builder", "/app", "/app")
      .expose (8080)
      .cmd (<<"./app">>).do_nothing

  print (builder.build)
  -- Outputs valid multi-stage Dockerfile

  Dependencies

  - simple_ipc (v2.0.0+) — Named pipe communication
  - simple_json — JSON parsing
  - simple_file — File operations
  - simple_logger — Logging support

  Getting Started

  # Clone
  git clone https://github.com/simple-eiffel/simple_docker.git

  # Set environment
  export SIMPLE_DOCKER=/path/to/simple_docker

  # Add to your ECF
  <library name="simple_docker" location="$SIMPLE_DOCKER/simple_docker.ecf"/>

  ---
  📋 Progress & Roadmap

  ✅ Completed (v1.0 - v1.1)

  | Phase | Feature                                                       | Status  |
  |-------|---------------------------------------------------------------|---------|
  | P1    | Core container operations (create, start, stop, remove, logs) | ✅ Done |
  | P1    | Image management (list, pull, exists, remove)                 | ✅ Done |
  | P1    | Fluent builder API (CONTAINER_SPEC)                           | ✅ Done |
  | P1    | Error handling with DOCKER_ERROR                              | ✅ Done |
  | P2    | DOCKERFILE_BUILDER - Fluent Dockerfile generation             | ✅ Done |
  | P2    | DOCKER_NETWORK - Network operations                           | ✅ Done |
  | P2    | DOCKER_VOLUME - Volume operations                             | ✅ Done |
  | P2    | Exec operations in containers                                 | ✅ Done |
  | P2    | Resilient IPC with rescue/retry                               | ✅ Done |
  | P4    | IUARC 5-document standard documentation                       | ✅ Done |
  | P5    | 38 tests including cookbook verification                      | ✅ Done |

  🔜 Tomorrow: Phase 3 - Performance Optimization

  | Task                  | Description                                       |
  |-----------------------|---------------------------------------------------|
  | Streaming log support | Real-time log streaming instead of batch fetch    |
  | Connection pooling    | Reuse IPC connections across operations           |
  | Timeout handling      | Configurable timeouts for long-running operations |
  | Efficient tar context | Optimize build_image with simple_archive          |

  📅 Coming Soon: Phase 6 - Production Hardening

  | Feature                    | Description                                      |
  |----------------------------|--------------------------------------------------|
  | COMPOSE_BUILDER            | Fluent API for docker-compose.yaml generation    |
  | DOCKER_REGISTRY_AUTH       | Private registry authentication                  |
  | EIFFEL_CONTAINER_TEMPLATES | Pre-built templates for Eiffel apps              |
  | Unix socket support        | Linux/macOS via simple_ipc cross-platform        |
  | Image building             | build_image with tar context from simple_archive |

  🎯 Finish Line Criteria

  | Metric             | Target             | Current         |
  |--------------------|--------------------|-----------------|
  | Test coverage      | 50+ tests          | 38 ✅           |
  | All P1-P6 features | Complete           | P1-P2, P4-P5 ✅ |
  | Cross-platform     | Windows + Linux    | Windows ✅      |
  | Documentation      | IUARC 5-doc        | ✅ Done         |
  | Production apps    | 1+ real deployment | Pending         |

  ---
  Links

  - GitHub: https://github.com/simple-eiffel/simple_docker
  - Documentation: https://simple-eiffel.github.io/simple_docker/
  - Ecosystem: https://github.com/simple-eiffel (71 libraries)

  ---
  simple_docker is part of the Simple Eiffel ecosystem—a collection of 71 libraries bringing modern development capabilities to Eiffel with Design by Contract at the core.

  Built with Claude Code 🤖

[Ulrich Windl]

Sounds great, but is it actually "simple"? 😉
(I never used docker)

16.12.2025 05:47:35 Liberty Lover <rix....@gmail.com>:

> Docker library is here:
>
>   🐳 Announcing simple_docker[https://github.com/simple-eiffel/claude_eiffel_op_docs/blob/main/posts/simple_docker_v110_announcement.md] v1.1.0 — Docker Container Management for Eiffel

> --
> You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/9475df3a-8133-49ba-84e6-de23f650c2c5n%40googlegroups.com[https://groups.google.com/d/msgid/eiffel-users/9475df3a-8133-49ba-84e6-de23f650c2c5n%40googlegroups.com?utm_medium=email&utm_source=footer].

[Liberty Lover]

  Beyond P6: The Extended Vision

  1. simple_kubernetes

  "An official https://github.com/kubernetes-client/c exists, enabling future simple_kubernetes development."

  A natural evolution - container orchestration at scale.

  2. Remote Docker Host Support (TLS)

  -- Future: Remote Docker host with mutual TLS
  create client.make_with_tls (host, ca_cert, client_cert, client_key)

  | Port | Security                       |
  |------|--------------------------------|
  | 2375 | Insecure TCP (NOT recommended) |
  | 2376 | Mutual TLS                     |

  3. Windows Native Containers

  Phase 6 in original plan: "Windows native containers (not Linux-on-Windows)" - HIGH effort

  Windows Server containers with different base images (not WSL2/Linux containers).

  4. Full Streaming Support

  | Operation                    | Type                            |
  |------------------------------|---------------------------------|
  | GET /containers/{id}/logs    | Chunked stream                  |
  | POST /build                  | Chunked JSON stream             |
  | POST /containers/{id}/attach | Multiplexed stdin/stdout/stderr |
  | GET /events                  | Server-sent events (long-lived) |

  5. Cloud Registry Integration

  | Provider                            | Auth Method                               |
  |-------------------------------------|-------------------------------------------|
  | Docker Hub                          | OAuth 2.0 bearer tokens                   |
  | GitHub Container Registry (ghcr.io) | PAT or GITHUB_TOKEN                       |
  | AWS ECR                             | aws ecr get-login-password (12h validity) |
  | Azure ACR                           | az acr login (3h validity)                |
  | Google GCR                          | Service account JSON                      |

  6. CI/CD Integration (simple_ci)

  -- Build in container, capture result
  container := docker.run_container (
      create {CONTAINER_SPEC}.make_with_image ("eiffel/eiffel:latest")
          .with_volume (project_path, "/app")
          .with_command ("ec -config my_app.ecf -c_compile")
  )
  docker.wait_for (container)
  if container.exit_code = 0 then
      print ("Build succeeded%N")
  end

  7. Resource Tracking & Cleanup

  "RAII pattern with dispose + invariants" - automatic cleanup of containers/networks on errors

  ---
  The Full Journey

  | Phase | Status      | What                                        |
  |-------|-------------|---------------------------------------------|
  | P1    | ✅ Done     | Core containers & images                    |
  | P2    | ✅ Done     | Networks, volumes, exec, Dockerfile builder |
  | P3    | 🔜 Tomorrow | Performance (streaming, pooling, timeouts)  |
  | P4    | ✅ Done     | Documentation (IUARC)                       |
  | P5    | ✅ Done     | Tests (38 passing)                          |
  | P6    | 📅 Next     | COMPOSE_BUILDER, registry auth, templates   |
  | P7    | 🔮 Future   | Remote TLS, Windows native containers       |
  | P8    | 🔮 Future   | simple_kubernetes                           |
  | P9    | 🔮 Future   | Full CI/CD integration with simple_ci       |

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/9475df3a-8133-49ba-84e6-de23f650c2c5n%40googlegroups.com.

[Liberty Lover]

Actually simple? 🤣

Exactly what are you saying? I want to be sure I am understanding your concern correctly. Tell me specifically, what outcome are you actually looking for?

Best,

Larry

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/ed127c70-068b-4405-a66f-e10fed8e08de%40gmail.com.

[Liberty Lover]

To understand Docker's market strength, you have to distinguish between Docker the Developer Tool (which is absolutely dominant) and Docker the Production Runtime (which has largely been replaced).

Here is the breakdown of Docker's position relative to competing technologies as of late 2024/early 2025.

1. The Executive Summary

Docker is the "Interface King" but no longer the "Infrastructure King."

• In Development: Docker is unrivaled. It is the de facto standard for building and testing applications.¹ If a developer uses containers, they are almost certainly using the Docker CLI or Docker Desktop.

• In Production: Docker has lost the war for orchestration (to Kubernetes) and is slowly being phased out as the underlying runtime (by containerd and CRI-O).

---

2. Market Share & Adoption Data

Recent data highlights a massive split between "people using Docker tools" and "servers running Docker engine."

Metric
Stat
Source/Context
Developer Usage
71%
Stack Overflow Survey (2025). Docker usage actually jumped (up from ~54% the prior year), likely driven by AI/ML workflows requiring reproducible environments.
Production Runtime
Declining
Datadog Container Report. While Docker images are the standard, the engine running them in production is shifting to containerd (which runs under Kubernetes).
Orchestration
<5%
Docker Swarm (Docker's native orchestration) has negligible share compared to Kubernetes (K8s), which holds ~90%+ of the orchestration market.

---

3. Competitor Analysis by CategoryA. The "Direct" Competitor: Podman²

Podman (developed largely by Red Hat) is the only tool that tries to do exactly what Docker does: provide a command-line interface (CLI) to build and run containers.

• Docker's Strength: Massive ecosystem, ease of use, "it just works," Docker Desktop GUI.

• Podman's Strength: Daemonless & Rootless.³ Docker requires a background process (daemon) that often runs with "root" (admin) privileges, which is a security risk.⁴ Podman runs containers as standard user processes.⁵

• The Verdict: Podman is popular among Linux purists and security-hardened enterprises (e.g., government, banking), but it has failed to dent Docker's dominance in the general developer market.

B. The "Invisible" Competitor: containerd / CRI-O

For years, Kubernetes used Docker Engine to run containers. In 2020, Kubernetes deprecated the "Dockershim," meaning it stopped supporting Docker Engine directly.

• The Shift: Kubernetes now communicates directly with lighter-weight runtimes like containerd (which Docker actually created and donated to the CNCF) or CRI-O.⁶

• The Impact: You might build your app with Docker on your laptop, but when you push it to the cloud (AWS EKS, Google GKE, Azure AKS), it is likely containerd running it, not Docker.

• The Verdict: Docker the company accepted this; they pivoted to focusing on the "Developer Experience" (Docker Desktop, Hub, Scout) rather than fighting for the invisible plumbing layer.

C. The "Orchestration" Competitor: Kubernetes⁷

Early on, Docker tried to compete in managing clusters of containers with Docker Swarm.

• The Outcome: Kubernetes won completely.

• The Current Relationship: Docker and Kubernetes are now partners, not rivals. Docker Desktop now includes a setting to "Enable Kubernetes," allowing developers to test K8s clusters locally using Docker tools.

---

4. Strategic Strengths & Weaknesses
Feature
Docker's Position relative to Market
Brand Awareness
Dominant. "Docker" is a proprietary eponym for containers (like "Kleenex" or "Google").
Image Format
Standard. The "Docker Image" is actually an OCI (Open Container Initiative) image. Even if you use Podman or Kubernetes, you are likely using the format Docker popularized.
Monetization
Controversial. Docker Inc. introduced paid subscriptions for Docker Desktop for large companies. This annoyed many users and drove some to alternatives like Rancher Desktop or Podman Desktop, but the mass exodus many predicted did not happen.
Security
Weaker. Because of the root-daemon architecture, Docker is often viewed as less secure by default than Podman.Summary

If you are asking "Should I learn Docker?", the answer is Yes. It is the industry standard language for development.

If you are asking "Will my production servers run Docker?", the answer is increasingly No. They will run Kubernetes/containerd, but they will be running the images you built with Docker.

Next Step

Would you like me to generate a comparison table of commands between Docker and Podman so you can see how similar the workflows are?

[Liberty Lover]

Which is PRECISELY why simple_kubernetes is coming ... very soon.

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/26a162c5-6ec2-44c2-a1f2-764f237567e2n%40googlegroups.com.

[Ulrich Windl]

Larry,

I just meant to say: I never used docker before, because I don't think it's simple. So probably I miss a complete deployment scenario with a use case for your class, but maybe my view isn't important here.

Ulrich

16.12.2025 14:36:06 Liberty Lover <rix....@gmail.com>:

>>> To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com[eiffel-users%2Bunsu...@googlegroups.com].
>>> To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/9475df3a-8133-49ba-84e6-de23f650c2c5n%40googlegroups.com[https://groups.google.com/d/msgid/eiffel-users/9475df3a-8133-49ba-84e6-de23f650c2c5n%40googlegroups.com?utm_medium=email&utm_source=footer][https://groups.google.com/d/msgid/eiffel-users/9475df3a-8133-49ba-84e6-de23f650c2c5n%40googlegroups.com%5Bhttps://groups.google.com/d/msgid/eiffel-users/9475df3a-8133-49ba-84e6-de23f650c2c5n%40googlegroups.com?utm_medium=email&utm_source=footer]].

>>
>> --
>> You received this message because you are subscribed to the Google Groups "Eiffel Users" group.

>> To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com[eiffel-users%2Bunsu...@googlegroups.com].

>> To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/ed127c70-068b-4405-a66f-e10fed8e08de%40gmail.com.
>

> --
> You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/CA%2B3qnjeUeB1bWQ0Gs1Dtz3UmEZx3N1_bQEu3GHrTvK%2BkwRr9ig%40mail.gmail.com[https://groups.google.com/d/msgid/eiffel-users/CA%2B3qnjeUeB1bWQ0Gs1Dtz3UmEZx3N1_bQEu3GHrTvK%2BkwRr9ig%40mail.gmail.com?utm_medium=email&utm_source=footer].

[Liberty Lover]

Hey Ulrich,

No, it's important. You are the precise type of person in the cross-hairs. Now, it is true that Docker is NOT simple (regardless of Eiffel). I may need to do a better job of creating a high-level (or higher-level) API with "cookbook recipe" or mock examples of real-work applications. The other contextual point of view is for those who DO KNOW Docker and how to use it in competitor contexts (e.g. Python, Java, et al). From where they are sitting, the existing "Simple Docker" might take on a different semantic framing than yourself and others like you. So, I think the stretch is to now provide (if possible) an even higher-level API with mocks/demos/cookbook-recipes, et al.

Cheers,

Larry

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/13c25a8e-742f-4065-b8c1-ca71178718c1%40gmail.com.

[Liberty Lover]

Ulrich,

You've become the inspiration for the "I-don't-know-nuthin-bout-X" QUICK API classes to add to Simple Eiffel. There are a number of candidate simple_* libs needing this level of attention and code. ... it's coming!!!

On Tue, Dec 16, 2025 at 12:46 PM Ulrich Windl <u202...@gmail.com> wrote:

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/13c25a8e-742f-4065-b8c1-ca71178718c1%40gmail.com.

[Liberty Lover]

  Hi Ulrich,

  Your email hit the nail on the head - Docker is indeed intimidating for newcomers. The existing DOCKER_CLIENT API requires understanding containers, specs, ports, volumes, and the whole Docker mental model.

  Solution: SIMPLE_DOCKER_QUICK

  We've added a new class that reduces Docker to one-liners. No configuration, no specs, no ports to remember:

  local
      docker: SIMPLE_DOCKER_QUICK
  do
      create docker.make

      -- Run a web server (that's it!)
      docker.web_server ("C:\my_website", 8080)

      -- Run a database
      docker.postgres ("mypassword")

      -- Run a cache
      docker.redis

      -- Execute a shell script
      print (docker.run_script ("echo hello && date"))

      -- Clean up when done
      docker.cleanup
  end

  What it handles automatically:
  - Pulls images if not present locally
  - Configures default ports (postgres=5432, redis=6379, etc.)
  - Sets sensible resource limits
  - Tracks all containers for cleanup
  - Strips Docker's internal stream headers from output

  Available one-liners:
  | Category       | Methods                                         |
  |----------------|-------------------------------------------------|
  | Web Servers    | web_server, web_server_nginx, web_server_apache |
  | Databases      | postgres, mysql, mariadb, mongodb               |
  | Caches         | redis, memcached                                |
  | Message Queues | rabbitmq                                        |
  | Scripts        | run_script, run_python                          |
  | Management     | stop_all, cleanup, container_count              |

  For advanced needs, users can still access the full DOCKER_CLIENT:
  docker.client.list_containers (True)  -- Full control when needed

  Documentation:
  - https://simple-eiffel.github.io/simple_docker/what-is-docker.html - Beginner-friendly guide
  - https://simple-eiffel.github.io/simple_docker/user-guide.html#quick-api - Complete reference
  - https://github.com/simple-eiffel/simple_docker#beginner-api-simple_docker_quick - Overview

  Test coverage: 58 tests passing (9 new tests for SIMPLE_DOCKER_QUICK)

  The philosophy: "Don't know nuthin' 'bout Docker? Don't need to!"

On Tue, Dec 16, 2025 at 12:46 PM Ulrich Windl <u202...@gmail.com> wrote:

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/13c25a8e-742f-4065-b8c1-ca71178718c1%40gmail.com.

[Liberty Lover]

This is going to bring a whole QUICK API family to Simple Eiffel:


  Re: Other QUICK APIs - Good candidates based on configuration/connection overhead:
  - simple_sql - Database connections
  - simple_http - HTTP requests
  - simple_ai_client - AI API calls
  - simple_smtp - Email sending
  - simple_jwt - Token handling
  - simple_encryption - Password hashing
  - simple_mq - Message queues
  - simple_web - Web server setup

On Tue, Dec 16, 2025 at 12:46 PM Ulrich Windl <u202...@gmail.com> wrote:

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/13c25a8e-742f-4065-b8c1-ca71178718c1%40gmail.com.