Docker-Client
view release on metacpan or search on metacpan
share/specs/v1.36.yaml view on Meta::CPAN
- "text/plain"
basePath: "/v1.36"
info:
title: "Docker Engine API"
version: "1.36"
x-logo:
url: "https://docs.docker.com/images/logo-docker-main.png"
description: |
The Engine API is an HTTP API served by Docker Engine. It is the API the Docker client uses to communicate with the Engine, so everything the Docker client can do can be done with the API.
Most of the client's commands map directly to API endpoints (e.g. `docker ps` is `GET /containers/json`). The notable exception is running containers, which consists of several API calls.
# Errors
The API uses standard HTTP status codes to indicate the success or failure of the API call. The body of the response will be JSON in the following format:
```
{
"message": "page not found"
}
```
# Versioning
The API is usually changed in each release, so API calls are versioned to
ensure that clients don't break. To lock to a specific version of the API,
you prefix the URL with its version, for example, call `/v1.30/info` to use
the v1.30 version of the `/info` endpoint. If the API version specified in
the URL is not supported by the daemon, a HTTP `400 Bad Request` error message
is returned.
If you omit the version-prefix, the current version of the API (v1.36) is used.
For example, calling `/info` is the same as calling `/v1.36/info`. Using the
API without a version-prefix is deprecated and will be removed in a future release.
Engine releases in the near future should support this version of the API,
so your client will continue to work even if it is talking to a newer Engine.
The API uses an open schema model, which means server may add extra properties
to responses. Likewise, the server will ignore any extra query parameters and
request body properties. When you write clients, you need to ignore additional
properties in responses to ensure they do not break when talking to newer
daemons.
# Authentication
Authentication for registries is handled client side. The client has to send authentication details to various endpoints that need to communicate with registries, such as `POST /images/(name)/push`. These are sent as `X-Registry-Auth` header as a...
```
{
"username": "string",
"password": "string",
"email": "string",
"serveraddress": "string"
}
```
The `serveraddress` is a domain/IP without a protocol. Throughout this structure, double quotes are required.
If you have already got an identity token from the [`/auth` endpoint](#operation/SystemAuth), you can just pass this instead of credentials:
```
{
"identitytoken": "9cbaf023786cd7..."
}
```
# The tags on paths define the menu sections in the ReDoc documentation, so
# the usage of tags must make sense for that:
# - They should be singular, not plural.
# - There should not be too many tags, or the menu becomes unwieldy. For
# example, it is preferable to add a path to the "System" tag instead of
# creating a tag with a single path in it.
# - The order of tags in this list defines the order in the menu.
tags:
# Primary objects
- name: "Container"
x-displayName: "Containers"
description: |
Create and manage containers.
- name: "Image"
x-displayName: "Images"
- name: "Network"
x-displayName: "Networks"
description: |
Networks are user-defined networks that containers can be attached to. See the [networking documentation](https://docs.docker.com/engine/userguide/networking/) for more information.
- name: "Volume"
x-displayName: "Volumes"
description: |
Create and manage persistent storage that can be attached to containers.
- name: "Exec"
x-displayName: "Exec"
description: |
Run new commands inside running containers. See the [command-line reference](https://docs.docker.com/engine/reference/commandline/exec/) for more information.
To exec a command in a container, you first need to create an exec instance, then start it. These two API endpoints are wrapped up in a single command-line command, `docker exec`.
# Swarm things
- name: "Swarm"
x-displayName: "Swarm"
description: |
Engines can be clustered together in a swarm. See [the swarm mode documentation](https://docs.docker.com/engine/swarm/) for more information.
- name: "Node"
x-displayName: "Nodes"
description: |
Nodes are instances of the Engine participating in a swarm. Swarm mode must be enabled for these endpoints to work.
- name: "Service"
x-displayName: "Services"
description: |
Services are the definitions of tasks to run on a swarm. Swarm mode must be enabled for these endpoints to work.
- name: "Task"
x-displayName: "Tasks"
description: |
A task is a container running on a swarm. It is the atomic scheduling unit of swarm. Swarm mode must be enabled for these endpoints to work.
- name: "Secret"
x-displayName: "Secrets"
description: |
Secrets are sensitive data that can be used by services. Swarm mode must be enabled for these endpoints to work.
- name: "Config"
x-displayName: "Configs"
description: |
share/specs/v1.36.yaml view on Meta::CPAN
in: "query"
description: "Term to search"
type: "string"
required: true
- name: "limit"
in: "query"
description: "Maximum number of results to return"
type: "integer"
- name: "filters"
in: "query"
description: |
A JSON encoded value of the filters (a `map[string][]string`) to process on the images list. Available filters:
- `is-automated=(true|false)`
- `is-official=(true|false)`
- `stars=<number>` Matches images that has at least 'number' stars.
type: "string"
tags: ["Image"]
/images/prune:
post:
summary: "Delete unused images"
produces:
- "application/json"
operationId: "ImagePrune"
parameters:
- name: "filters"
in: "query"
description: |
Filters to process on the prune list, encoded as JSON (a `map[string][]string`). Available filters:
- `dangling=<boolean>` When set to `true` (or `1`), prune only
unused *and* untagged images. When set to `false`
(or `0`), all unused images are pruned.
- `until=<string>` Prune images created before this timestamp. The `<timestamp>` can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the daemon machine’s time.
- `label` (`label=<key>`, `label=<key>=<value>`, `label!=<key>`, or `label!=<key>=<value>`) Prune images with (or without, in case `label!=...` is used) the specified labels.
type: "string"
responses:
200:
description: "No error"
schema:
type: "object"
title: "ImagePruneResponse"
properties:
ImagesDeleted:
description: "Images that were deleted"
type: "array"
items:
$ref: "#/definitions/ImageDeleteResponseItem"
SpaceReclaimed:
description: "Disk space reclaimed in bytes"
type: "integer"
format: "int64"
500:
description: "Server error"
schema:
$ref: "#/definitions/ErrorResponse"
tags: ["Image"]
/auth:
post:
summary: "Check auth configuration"
description: "Validate credentials for a registry and, if available, get an identity token for accessing the registry without password."
operationId: "SystemAuth"
consumes: ["application/json"]
produces: ["application/json"]
responses:
200:
description: "An identity token was generated successfully."
schema:
type: "object"
title: "SystemAuthResponse"
required: [Status]
properties:
Status:
description: "The status of the authentication"
type: "string"
x-nullable: false
IdentityToken:
description: "An opaque token used to authenticate a user after a successful login"
type: "string"
x-nullable: false
examples:
application/json:
Status: "Login Succeeded"
IdentityToken: "9cbaf023786cd7..."
204:
description: "No error"
500:
description: "Server error"
schema:
$ref: "#/definitions/ErrorResponse"
parameters:
- name: "authConfig"
in: "body"
description: "Authentication to check"
schema:
$ref: "#/definitions/AuthConfig"
tags: ["System"]
/info:
get:
summary: "Get system information"
operationId: "SystemInfo"
produces:
- "application/json"
responses:
200:
description: "No error"
schema:
$ref: "#/definitions/SystemInfo"
500:
description: "Server error"
schema:
$ref: "#/definitions/ErrorResponse"
tags: ["System"]
/version:
get:
summary: "Get version"
description: "Returns the version of Docker that is running and various information about the system that Docker is running on."
operationId: "SystemVersion"
produces: ["application/json"]
responses:
200:
share/specs/v1.36.yaml view on Meta::CPAN
$ref: "#/definitions/ErrorResponse"
503:
description: "node is not part of a swarm"
schema:
$ref: "#/definitions/ErrorResponse"
parameters:
- name: "id"
in: "path"
description: "ID or name of service."
required: true
type: "string"
- name: "body"
in: "body"
required: true
schema:
allOf:
- $ref: "#/definitions/ServiceSpec"
- type: "object"
example:
Name: "top"
TaskTemplate:
ContainerSpec:
Image: "busybox"
Args:
- "top"
Resources:
Limits: {}
Reservations: {}
RestartPolicy:
Condition: "any"
MaxAttempts: 0
Placement: {}
ForceUpdate: 0
Mode:
Replicated:
Replicas: 1
UpdateConfig:
Parallelism: 2
Delay: 1000000000
FailureAction: "pause"
Monitor: 15000000000
MaxFailureRatio: 0.15
RollbackConfig:
Parallelism: 1
Delay: 1000000000
FailureAction: "pause"
Monitor: 15000000000
MaxFailureRatio: 0.15
EndpointSpec:
Mode: "vip"
- name: "version"
in: "query"
description: "The version number of the service object being updated. This is required to avoid conflicting writes."
required: true
type: "integer"
- name: "registryAuthFrom"
in: "query"
type: "string"
description: "If the X-Registry-Auth header is not specified, this
parameter indicates where to find registry authorization credentials. The
valid values are `spec` and `previous-spec`."
default: "spec"
- name: "rollback"
in: "query"
type: "string"
description: "Set to this parameter to `previous` to cause a
server-side rollback to the previous service spec. The supplied spec will be
ignored in this case."
- name: "X-Registry-Auth"
in: "header"
description: "A base64-encoded auth configuration for pulling from private registries. [See the authentication section for details.](#section/Authentication)"
type: "string"
tags: ["Service"]
/services/{id}/logs:
get:
summary: "Get service logs"
description: |
Get `stdout` and `stderr` logs from a service.
**Note**: This endpoint works only for services with the `json-file` or `journald` logging drivers.
operationId: "ServiceLogs"
produces:
- "application/vnd.docker.raw-stream"
- "application/json"
responses:
101:
description: "logs returned as a stream"
schema:
type: "string"
format: "binary"
200:
description: "logs returned as a string in response body"
schema:
type: "string"
404:
description: "no such service"
schema:
$ref: "#/definitions/ErrorResponse"
examples:
application/json:
message: "No such service: c2ada9df5af8"
500:
description: "server error"
schema:
$ref: "#/definitions/ErrorResponse"
503:
description: "node is not part of a swarm"
schema:
$ref: "#/definitions/ErrorResponse"
parameters:
- name: "id"
in: "path"
required: true
description: "ID or name of the service"
type: "string"
- name: "details"
in: "query"
description: "Show service context and extra details provided to logs."
type: "boolean"
( run in 1.740 second using v1.01-cache-2.11-cpan-39bf76dae61 )