In previous chapters, we have been fiddling a lot with Docker commands to work with Docker images, containers, volumes, and networks. One of the hallmarks of Docker is the amazing user experience it provides through its easy-to-remember and well-structured commands. With a single Docker command, we can spin a very useful microservice or utility container. However, behind the scenes, the Docker client translates our request into multiple API calls in order to fulfill it. These APIs are called Docker Engine APIs, and they are designed using the REST paradigm.

The Docker Engine API is documented using the OpenAPI (formerly known as Swagger) specification. As a result, we can access API help through any standard OpenAPI editor. In this book, we are using an editor called Swagger Editor, and it is available at http://editor.swagger.io; however, you can use any OpenAPI editor of your choice. Swagger Editor has options such as Try it out and Execute, which can be used to generate curl commands with appropriate options. The following screenshot shows Swagger Editor with the Docker engine API document:

Here, we generated the Docker Engine API document from the swagger.yaml file available at https://docs.docker.com/engine/api/v1.35/swagger.yaml. Of course, you can also refer to the current, work-in-progress version of the API from https://raw.githubusercontent.com/moby/moby/master/api/swagger.yaml.

By default, the Docker engine listens on /var/run/docker.sock, a Unix domain socket, to communicate with its client. The Unix domain socket, also known as the inter-process communication socket, enables reliable communication within a host. Besides this, /var/run/docker.sock has read-write access for the user root and group docker; hence, the client application must either have root privilege or be a member of the docker group. In addition to the Unix socket, the Docker daemon supports two more socket types:

• fd: Systemd's socket activation. On Systemd-based systems such as Ubuntu 16.04, the Docker daemon listens on the fd socket, which internally gets mapped to the Unix socket /var/run/docker.sock using the systemd's socket activation feature.
• tcp: For remote connectivity. In recipe, Configuring the Docker daemon for remote connectivity, we will configure the Docker daemon to accept unencrypted communication from the client, and in recipe, Securing the Docker daemon's remote connectivity, we will configure the Docker daemon to use secure communication.

Docker also provides Software Development Kits (SDKs) for the Python and Go monogramming language. These SDKs internally use Docker engine REST APIs. In addition to these standard SDKs, there are many community-supported API bindings for other programming languages. Some of these API bindings are listed at https://docs.docker.com/develop/sdk/#unofficial-libraries. However, these libraries are not tested by Docker.

Throughout this chapter, we will use two tools, curl and jq:

• curl is a command-line tool for transferring data. We use curl to connect to our Docker daemon. Please ensure that you are running curl7.40 or above, because curl started supporting Unix sockets from version 7.40. You can find more details about curl at the official website at https://curl.haxx.se/.
• jq is a command line tool for processing JSON data. We use jq to manipulate the data we receive from the Docker daemon. You can find more details about jq at the official website at https://stedolan.github.io/jq/.

All the recipes in this chapter assume that the Docker is installed and running.