by into-docker

into-docker /clj-docker-client

An idiomatic, data-driven, REPL friendly Clojure Docker client

148 Stars 12 Forks Last release: 4 months ago (1.0.1) GNU Lesser General Public License v3.0 134 Commits 27 Releases

Available items

No Items, yet!

The developer of this repository has not created any items for sale yet. Need a bug fixed? Help with integration? A different license? Create a request here:


License: LGPL v3 Clojars Project

cljdoc badge Dependencies Status Downloads

project chat

An idiomatic, data-driven, REPL friendly Clojure Docker client inspired from Cognitect's AWS client.

See this for documentation for versions before 0.4.0.

The README here is for the current master branch and may not reflect the released version.

Please raise issues here for any new feature requests!



[lispyclouds/clj-docker-client "1.0.1"]

Clojure CLI/deps.edn

{lispyclouds/clj-docker-client {:mvn/version "1.0.1"}}


compile 'lispyclouds:clj-docker-client:1.0.1'




Build Requirements

  • Leiningen 2.8+
  • JDK 1.8+

Running tests locally

  • Install leiningen
  • Install Docker
  • lein kaocha
    to run all tests. (needs Docker and working internet)

Auto generated code docs can be found here

Developing with Cognitect REBL

Since this is fully data driven, using REBL is really beneficial as it allows us to walk through the output from Docker, see potential errors and be more productive with instant visual feedback.

This assumes Java 11+: - Download and unzip the REBL jar to a known location. - Start the leiningen REPL with:

REBL_PATH= lein with-profile +rebl repl
. - Connect your editor of choice to this REPL or start using the REBL/REPL directly. - Evaluate
to fire up the REBL UI. - Then repeat after me 3 times: ALL HAIL THE DATA! 🙏🏽

The Docker API

This uses Docker's HTTP REST API to run. See the API version matrix to find the corresponding API version for the Docker daemon you're running.

clj-docker-client works by parsing the Swagger 2.0 YAMLs from the docker client API and vendors it in this directory. This defaults to using the latest version available there if no versions are pinned. It is recommended to use a pinned version to have consistent behavior across different engine versions.

See the page about the docker REST API to learn more about the usage and params to pass.


(require '[clj-docker-client.core :as docker])

This library aims to be a as thin layer as possible between you and Docker. This consists of following public functions:


Lists the categories of operations supported. Can be bound to an API version. ```clojure (docker/categories) ; Latest version

(docker/categories "v1.40") ; Locked to v1.40

_=> #{:system

#### client

Connect to the docker daemon's UNIX socket and create a client scoped to the operations of a given category. Can be bound to an API version.

```clojure (def images (docker/client {:category :images :conn {:uri "unix:///var/run/docker.sock"}})) ; Latest version

(def containers (docker/client {:category :containers :conn {:uri "unix:///var/run/docker.sock"} :api-version "v1.40"})) ; Container client for v1.40

Using a timeout for the connections. Thanks olymk2 for the suggestion. Docker actions can take quite a long time so set the timeout accordingly. When you don't provide timeouts then there will be no timeout on the client side.

(def ping (docker/client {:category :_ping
                          :conn     {:uri      "unix:///var/run/docker.sock"
                                     :timeouts {:connect-timeout 10
                                                :read-timeout    30000
                                                :write-timeout   30000
                                                :call-timeout    30000}}}))
Alternatively if connecting to a remote docker daemon over TCP supply the
are the currently supported protocols.


Lists the supported ops by a client. ```clojure (docker/ops images)

_=> (:ImageList

#### doc
Returns the doc of an operation in a client.
(docker/doc images :ImageList)

#_=> {:doc "List Images\nReturns a list of images on the server. Note that it uses a different, smaller representation of an image than inspecting a single image.", :params ({:name "all", :type "boolean"} {:name "filters", :type "string"} {:name "digests", :type "boolean"})}


Invokes an operation via the client and a given operation map and returns the result data. ```clojure ; Pulls the busybox:musl image from Docker hub (docker/invoke images {:op :ImageCreate :params {:fromImage "busybox:musl"}})

; Creates a container named conny from it (docker/invoke containers {:op :ContainerCreate :params {:name "conny" :body {:Image "busybox:musl" :Cmd "ls"}}}) ```

The operation map is of the following structure:

{:op     :NameOfOp
 :params {:param-1 "value1"
          :param-2 true}}
Takes an optional key
. Defaults to
. Returns an InputStream if passed as
, the raw underlying network socket if passed as
is useful for streaming responses like logs, events etc, which run till the container is up.
is useful for events when bidirectional streams are returned by docker in operations like
{:op     :NameOfOp
 :params {:param-1 "value1"
          :param-2 true}
 :as     :stream}

Takes another optional key

. Defaults to
. If set to true will throw an exception for exceptional status codes from the Docker API i.e.
status >= 400
. Throws an
with the message.
{:op               :NameOfOp
 :throw-exception? true}

General guidelines

  • Head over to the Docker API docs to get more info on the type of parameters you should be sending. eg: this page for
    API docs.
  • The type
    is mapped to
    and when the API needs a stream as an input, send an InputStream. When it returns a stream, the call can possibly block till the container or source is up and its recommended to pass the
    param as
    to the invoke call and read it asynchronously. See this section for more info.

Sample code for common scenarios

Pulling an image

(def images (docker/client {:category :images
                            :conn     {:uri "unix:///var/run/docker.sock"}}))

(docker/invoke images {:op :ImageCreate :params {:fromImage "busybox:musl"}})

Creating a container

(def containers (docker/client {:category :containers
                                :conn     {:uri "unix:///var/run/docker.sock"}}))

(docker/invoke containers {:op :ContainerCreate :params {:name "conny" :body {:Image "busybox:musl" :Cmd ["sh" "-c" "i=1; while :; do echo $i; sleep 1; i=$((i+1)); done"]}}})

Starting a container

(docker/invoke containers {:op     :ContainerStart
                           :params {:id "conny"}})

Streaming logs

; fn to react when data is available
(defn react-to-stream
  [stream reaction-fn]
    (with-open [rdr ( stream)]
      (loop [r ( rdr)]
        (when-let [line (.readLine r)]
          (reaction-fn line)
          (recur r))))))

(def log-stream (docker/invoke containers {:op :ContainerLogs :params {:id "conny" :follow true :stdout true} :as :stream}))

(react-to-stream log-stream println) ; prints the logs line by line when they come.

Attach to a container and send data to stdin

;; This is a raw bidirectional, so both reads and writes are possible.
;; conny-reader has been started with: docker run -d -i --name conny-reader alpine:latest sh -c "cat - >/out"
(def sock (docker/invoke containers {:op     :ContainerAttach
                                     :params {:id     "conny-reader"
                                              :stream true
                                              :stdin  true}
                                     :as     :socket}))

( "hello" (.getOutputStream sock))

(.close sock) ; Important for freeing up resources.

Not so common scenarios

Accessing undocumented/experimental Docker APIs

There are some cases where you may need access to an API that is either experimental or is not in the swagger docs. Docker checkpoint is one such example. Thanks @mk for bringing it up!

Since this uses the published APIs from the swagger spec, the way to access them is to use the lower level fn

from the
ns. The caveat is the response will be totally raw(data, stream or the socket itself).

fetch takes the following params as a map: - conn: the connection to the daemon. Required. - url: the relative path to the operation. Required. - method: the method of the HTTP request as a keyword. Default:

. - query: the map of key-values to be passed as query params. - path: the map of key-values to be passed as path params. Needed for interpolated path values like
. Pass
{:id "conny"}
here. - header: the map of key-values to be passed as HEADER params. - body: the stream or map(will be converted to JSON) to be passed as body. - as: takes the kind of response expected. One of :stream, :socket or :data. Same as
. Default:
(require '[clj-docker-client.requests :as req])
(require '[clj-docker-client.core :as docker])

;; This is the undocumented API in the Docker Daemon. ;; See (req/fetch {:conn (req/connect* {:uri "unix:///var/run/docker.sock"}) :url "/v1.40/containers/conny/checkpoints"})

More examples of low level calls: ```clojure ;; Ping the server (req/fetch {:conn (req/connect* {:uri "unix:///var/run/docker.sock"}) :url "/v1.40/_ping"})

;; Copy a folder to a container (req/fetch {:conn (req/connect* {:uri "unix:///var/run/docker.sock"}) :url "/v1.40/containers/conny/archive" :method :put :query {:path "/root/src"} :body (-> "src.tar.gz" io/file io/input-stream)}) ```

And anything else is possible!


Copyright © 2020 Rahul De and contributors.

Distributed under the LGPLv3+ License. See LICENSE.

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.