hocker: Interact with the docker registry and generate nix build instructions

[ apache, library, program, utilities ] [ Propose Tags ]

hocker is a suite of command line utilities and a library for:

  • fetching a docker image

  • fetching a layer of an image

  • fetching an image's configuration

  • fetching a docker registry image manifest

  • generating nix build instructions from a registry image manifest

The motivation for this tool came from a need to fetch docker image artifacts from a docker registry without the stock docker tooling that is designed to only work with the docker daemon.

These tools only work with version 2 of the docker registry and docker version (>=) 1.10.

For a complete set of usage examples please see the project's README.md.

[Skip to Readme]


[Last Documentation]

  • Data
    • Docker
      • Image
        • Data.Docker.Image.AesonHelpers
        • Data.Docker.Image.Types
      • Data.Docker.Nix
        • Data.Docker.Nix.FetchDocker
        • Data.Docker.Nix.Lib
  • Hocker
    • Hocker.Lib
    • Hocker.Types
      • Hocker.Types.Exceptions
      • Hocker.Types.Hash
      • Hocker.Types.ImageName
      • Hocker.Types.ImageTag
      • Hocker.Types.URI
  • Network
    • Wreq
      • Docker
        • Network.Wreq.Docker.Image
          • Network.Wreq.Docker.Image.Lib
        • Network.Wreq.Docker.Registry
      • Network.Wreq.ErrorHandling


Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees


Versions [RSS] 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4, 1.0.5, 1.0.6
Change log CHANGELOG.md
Dependencies aeson (>=, aeson-pretty (>=0.8), async (>= && <2.3), base (>=4.9 && <5), bytestring (>=0.10), concurrentoutput (>=0.2), containers (>=0.5), cryptonite (>=0.13), data-fix (>=0.0.3), deepseq (>=1.4), directory (>=, exceptions (>=0.8), filepath (>=1.4), foldl (>=1.0), hnix (>=0.7.0), hocker, http-client (>=0.4), http-types (>=0.9.1), lens (>=4.0), lens-aeson (>=1.0), lifted-base (>=, megaparsec (>=7.0.0), memory (>=0.11), mtl (>=2.2), neat-interpolation (>=0.3.2), network (>=2.6), network-uri (>=2.6), nix-paths (>=1.0.1 && <1.1), optional-args, optparse-applicative (>=0.13), optparse-generic (>=1.2.0), pooled-io (>=0.0.2), prettyprinter (>=1.1.1), pureMD5 (>=2.1), scientific (>=0.3), tar (>=0.5), temporary (>=1.2), text (>=1.2), time (>=1.4), transformers (>=0.4), turtle (>=1.3.0 && <1.6), unordered-containers (>=0.2), uri-bytestring (>=0.2), vector (>=0.11), wreq (>=0.4), zlib (>=0.6) [details]
License Apache-2.0
Copyright 2016 Awake Security
Author Awake Security
Maintainer opensource@awakesecurity.com
Category Utilities
Home page https://github.com/awakesecurity/hocker#readme
Bug tracker https://github.com/awakesecurity/hocker/issues
Source repo head: git clone https://github.com/awakesecurity/hocker.git
Uploaded by ParnellSpringmeyer at 2020-08-17T16:27:18Z
Executables docker2nix, hocker-manifest, hocker-config, hocker-layer, hocker-image
Downloads 3721 total (30 in the last 30 days)
Rating (no votes yet) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs not available [build log]
All reported builds failed as of 2020-08-17 [all 2 reports]

Readme for hocker-1.0.6

[back to package description]


The hocker package provides a small set of utilities to fetch docker image artifacts from docker registries and produce Nix derivations marrying docker and Nix elegantly:

  • hocker-image for fetching a docker image
  • hocker-layer for fetching a docker image's layers
  • hocker-config for fetching a docker image's configuration JSON
  • hocker-manifest for fetching a docker registry image manifest
  • docker2nix for generating Nix expressions calling the fetchdocker derivations, given a docker registry image manifest

These tools only work with version 2 of the docker registry and docker (>=) v1.10.

The motivation for this tool came from a need to fetch docker image artifacts from a docker registry without the stock docker tooling designed to only work with the docker daemon.

Our use case (and the reason why this package exposes a docker2nix tool) is pulling docker images into a NixOS system's store and loading those images from the store into the docker daemon running on that same system.

We desired this for two critical reasons:

  1. The docker daemon no longer required an internet connection in order to load the docker images
  2. By virtue of fetching the docker images at build-time as opposed to run-time, failures from non-existent images or image tags are caught earlier

We strived to make this tool useful outside of the context of Nix and NixOS, therefore all of these tools are usable without Nix in the workflow.

For high-level documentation of each utility, please refer to the README's in their respective directories (links are in the above list).


Let's first retrieve a docker registry image manifest for the debian:jessie docker image (note that we need the library/ repository prefix because we are pulling from the official debian repository!):

$ hocker-manifest library/debian jessie
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
   "config": {
      "mediaType": "application/vnd.docker.container.image.v1+json",
      "size": 1528,
      "digest": "sha256:054abe38b1e6f863befa4258cbfaf127b1cc9440d2e2e349b15d22e676b591e7"
   "layers": [
         "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
         "size": 52550276,
         "digest": "sha256:cd0a524342efac6edff500c17e625735bbe479c926439b263bbe3c8518a0849c"

Next, we can easily generate a fetchdocker derivation using docker2nix:

$ hocker-manifest library/debian jessie | docker2nix library/debian jessie
{ fetchDockerConfig, fetchDockerLayer, fetchdocker }:
fetchdocker rec {
    name = "debian";
    registry = "https://registry-1.docker.io/v2/";
    repository = "library";
    imageName = "debian";
    tag = "jessie";
    imageConfig = fetchDockerConfig {
      inherit tag registry repository imageName;
      sha256 = "1rwinmvfc8jxn54y7qnj82acrc97y7xcnn22zaz67y76n4wbwjh5";
    imageLayers = let
      layer0 = fetchDockerLayer {
        inherit registry repository imageName;
        layerDigest = "cd0a524342efac6edff500c17e625735bbe479c926439b263bbe3c8518a0849c";
        sha256 = "1744l0c8ag5y7ck9nhr6r5wy9frmaxi7xh80ypgnxb7g891m42nd";
      in [ layer0 ];

Private registries

We developed these tools with private registries in-mind and they currently support three modes of authentication:

  1. Nothing at all (simply do not supply --token or --username and --password)
  2. Bearer token-based authentication, you should retrieve a token and then give it via the --token flag
  3. Basic authentication with --username and --password (most common with nginx proxied registries providing basic auth protection; you should be careful to ensure you're only sending requests to registries exposed via TLS or SSL!)

A caveat to #1 if you do not supply any authentication credential flags and you also do not supply a --registry flag then the tools assume you wish to make a request to the public docker hub registry, in which case they ask for a short-lived authentication token from the registry auth server and then make the request to the public docker hub registry.

How to build

Building (and developing a patch for) this project using cabal is straight-forward if we have Nix installed:

$ nix-shell
[nix-shell:]$ cabal --version
cabal-install version
compiled using version of the Cabal library

... cabal and all of the package dependencies will be in the shell environment so that we can then:

[nix-shell:]$ cabal build

Alternatively we can nix-build the project, this is not recommended for development because Nix will not build the project incrementally:

$ nix-build --attr hocker release.nix
these derivations will be built:
building path(s) ‘/nix/store/g16mrfhlmb1z3qkdzr0diaqn2dhl8bv6-hocker-’