at main
3 folders
38 files
docker: Engine API client and server, first slice
New ocaml-docker package: the Docker Engine REST API on the host, in
pure OCaml. The IO-free `docker` library maps request and response
bodies to OCaml values with nox-json; `docker-client` (the `dockr` CLI)
and `docker-server` (the `dockrd` daemon) are thin Eio adapters over a
Unix socket, so the same definitions back the client, the server, and
the tests.
This first slice covers GET /version and GET /_ping (both also under a
/v<api> prefix) -- enough to exercise the whole stack (Unix-socket
transport, routing, headers, JSON codecs, client/server symmetry)
without a container runtime behind it.
The interop tests cover both directions. test/client drives a real
daemon and test/interop/dockerd replays committed real-daemon captures
(the oracle is contacted only at REGEN=1), validating our client against
a real server. test/server points the stock `docker` CLI at our server,
validating our server against a real client.
docker: Engine API client and server, first slice
New ocaml-docker package: the Docker Engine REST API on the host, in
pure OCaml. The IO-free `docker` library maps request and response
bodies to OCaml values with nox-json; `docker-client` (the `dockr` CLI)
and `docker-server` (the `dockrd` daemon) are thin Eio adapters over a
Unix socket, so the same definitions back the client, the server, and
the tests.
This first slice covers GET /version and GET /_ping (both also under a
/v<api> prefix) -- enough to exercise the whole stack (Unix-socket
transport, routing, headers, JSON codecs, client/server symmetry)
without a container runtime behind it.
The interop tests cover both directions. test/client drives a real
daemon and test/interop/dockerd replays committed real-daemon captures
(the oracle is contacted only at REGEN=1), validating our client against
a real server. test/server points the stock `docker` CLI at our server,
validating our server against a real client.
docker: container list/create/inspect over a runtime backend seam
Add the first container endpoints -- GET /containers/json, POST
/containers/create, GET /containers/{id}/json -- the point where the API
first needs a runtime underneath it.
The seam follows the Irmin Heap.Make pattern: docker-runner defines a
BACKEND module type (a container runtime: an in-memory store now, runc or
a VMM later) and an in-memory Memory backend; Server.Make (B : BACKEND)
builds the server over it, projecting the backend's containers to the
Engine API shapes. The static endpoints (/version, /_ping, /info) and the
container endpoints are all served, each also under a /v<api> prefix.
New docker types: Container.{Config,Create_response,Summary,Detail}.
Client gains container_create / container_list / container_inspect (named
after the Docker Go SDK). Errors are emitted as the {"message": ...} body
via Docker.Error.to_body.
The real docker 29.x CLI drives the lifecycle against dockrd end to end:
`docker create`, `docker ps -a`, `docker inspect` all work. A live bug it
surfaced -- the CLI sends null, not [], for empty Cmd/Env/Warnings arrays
-- is fixed with a null-tolerant list codec and a regression test.
docker: container list/create/inspect over a runtime backend seam
Add the first container endpoints -- GET /containers/json, POST
/containers/create, GET /containers/{id}/json -- the point where the API
first needs a runtime underneath it.
The seam follows the Irmin Heap.Make pattern: docker-runner defines a
BACKEND module type (a container runtime: an in-memory store now, runc or
a VMM later) and an in-memory Memory backend; Server.Make (B : BACKEND)
builds the server over it, projecting the backend's containers to the
Engine API shapes. The static endpoints (/version, /_ping, /info) and the
container endpoints are all served, each also under a /v<api> prefix.
New docker types: Container.{Config,Create_response,Summary,Detail}.
Client gains container_create / container_list / container_inspect (named
after the Docker Go SDK). Errors are emitted as the {"message": ...} body
via Docker.Error.to_body.
The real docker 29.x CLI drives the lifecycle against dockrd end to end:
`docker create`, `docker ps -a`, `docker inspect` all work. A live bug it
surfaced -- the CLI sends null, not [], for empty Cmd/Env/Warnings arrays
-- is fixed with a null-tolerant list codec and a regression test.
docker: images (list/pull/inspect/tag/remove)
Add the images resource. The backend keeps a metadata store; image_pull
registers an entry (no bytes moved) and the server streams back the
newline-delimited JSON progress the docker CLI expects, so `docker pull`
prints "Downloaded newer image for ..." and exits 0. Serves GET
/images/json, POST /images/create, GET /images/{name}/json, POST
/images/{name}/tag, DELETE /images/{name}; client gains Client.Image.{list,
pull,inspect,tag,remove}.
image_find tolerates the CLI's fully-qualified names (registry/namespace
prefix, implicit :latest) so `docker rmi alpine` resolves
docker.io/library/alpine:latest. Real docker pull/images/rmi round-trip.
docker: Engine API client and server, first slice
New ocaml-docker package: the Docker Engine REST API on the host, in
pure OCaml. The IO-free `docker` library maps request and response
bodies to OCaml values with nox-json; `docker-client` (the `dockr` CLI)
and `docker-server` (the `dockrd` daemon) are thin Eio adapters over a
Unix socket, so the same definitions back the client, the server, and
the tests.
This first slice covers GET /version and GET /_ping (both also under a
/v<api> prefix) -- enough to exercise the whole stack (Unix-socket
transport, routing, headers, JSON codecs, client/server symmetry)
without a container runtime behind it.
The interop tests cover both directions. test/client drives a real
daemon and test/interop/dockerd replays committed real-daemon captures
(the oracle is contacted only at REGEN=1), validating our client against
a real server. test/server points the stock `docker` CLI at our server,
validating our server against a real client.
docker: Engine API client and server, first slice
New ocaml-docker package: the Docker Engine REST API on the host, in
pure OCaml. The IO-free `docker` library maps request and response
bodies to OCaml values with nox-json; `docker-client` (the `dockr` CLI)
and `docker-server` (the `dockrd` daemon) are thin Eio adapters over a
Unix socket, so the same definitions back the client, the server, and
the tests.
This first slice covers GET /version and GET /_ping (both also under a
/v<api> prefix) -- enough to exercise the whole stack (Unix-socket
transport, routing, headers, JSON codecs, client/server symmetry)
without a container runtime behind it.
The interop tests cover both directions. test/client drives a real
daemon and test/interop/dockerd replays committed real-daemon captures
(the oracle is contacted only at REGEN=1), validating our client against
a real server. test/server points the stock `docker` CLI at our server,
validating our server against a real client.
docker: Engine API client and server, first slice
New ocaml-docker package: the Docker Engine REST API on the host, in
pure OCaml. The IO-free `docker` library maps request and response
bodies to OCaml values with nox-json; `docker-client` (the `dockr` CLI)
and `docker-server` (the `dockrd` daemon) are thin Eio adapters over a
Unix socket, so the same definitions back the client, the server, and
the tests.
This first slice covers GET /version and GET /_ping (both also under a
/v<api> prefix) -- enough to exercise the whole stack (Unix-socket
transport, routing, headers, JSON codecs, client/server symmetry)
without a container runtime behind it.
The interop tests cover both directions. test/client drives a real
daemon and test/interop/dockerd replays committed real-daemon captures
(the oracle is contacted only at REGEN=1), validating our client against
a real server. test/server points the stock `docker` CLI at our server,
validating our server against a real client.