Docker\Docker extends that
client with connection handling and wrappers for selected streaming endpoints.
Use Docker\Docker, not Docker\API\Client, for those wrappers.
Request models and nested configuration
JSON request bodies use generated models, rather than arbitrary PHP arrays. Construct the outer request model and the nested models it expects. Use arrays for lists and maps where the setter accepts an iterable. For example, container creation combinesContainersCreatePostBody,
HostConfig, PortBinding and Mount. See
Configure a container for a complete example.
Calling a setter marks that field as initialized. An unset field is different
from one explicitly set to null, an empty list or an empty object. Leave
optional fields unset unless you intend to send them. Nullable setters do not
mean that every Docker operation accepts null in every context.
Dockerās JSON shapes matter:
Use
new ArrayObject() when constructing an empty object in these examples;
an empty PHP array normally represents a JSON list. The generated normalizers
preserve the object shapes required by the API.
JSON-valued query parameters
Some query parameters are strings containing JSON, even though other query parameters use booleans, integers or arrays. Examples includefilters,
buildargs, labels on imageBuild(), and cachefrom.
urlencode() or
http_build_query(); the client performs query-string encoding. Pass an actual
boolean for all, not the string 'true'. Conversely, archive upload options
such as noOverwriteDirNonDir are declared as strings in this API line and
must be passed as strings.
The generated endpointās PHPDoc and options resolver are the authority for the
parameter types accepted by this version. A CLI flagās name or apparent type
is not enough to determine the PHP signature.
Response models and empty responses
The default fetch mode returns a generated response model, a list of models, a callback stream, a plain decoded object, ornull, depending on the endpoint.
Use getters on models; do not assume every result is an array.
Successful operations such as starting a container can have no response body.
A null result is therefore not a general failure indicator. Check the endpoint
contract, or use a raw response when you need the HTTP status. To make sure a
null never hides an error response, enable
unexpected status exceptions.
For absent or nullable response fields, use null checks or null-safe getters.
Some Docker counters and limits are unsigned 64-bit integers. Values above
PHP_INT_MAX, such as the pids_stats.limit Docker reports for a container
without a PID limit, are returned as PHP_INT_MAX.
Inspect responses and create request models serve different purposes; do not
send an entire inspect response back as a creation or update payload.
Raw responses and headers
UseexecuteRawEndpoint() with an endpoint object when you need the HTTP
status, headers, tar content or an unsupported streaming response:
FETCH_RESPONSE on the convenience methods is deprecated by Jane. Prefer
executeRawEndpoint() in new code. A response body is also a cursor: reading
it consumes bytes. Do not assume you can rewind a live socket body.
Error handling
There are three separate failure paths:- Local validation or serialization fails before the request is sent.
- A transport error or a documented HTTP API error occurs.
- An operation starts successfully but reports an error inside its progress stream, such as a pull, push or build failure after HTTP 200.
/info request and can fail before the try block
above. Include client creation in your applicationās outer connection/error
handling.
Unexpected error statuses
Generated exceptions cover the status codes and JSON responses listed in Dockerās API specification. Docker also returns errors the specification leaves out:containerUpdate() answers an invalid memory limit with HTTP 400,
networkCreate() answers a duplicate name with 409, and a proxy in front of
the daemon can return its own errors.
An error status of 400 or above that the endpoint does not handle throws
Docker\Exception\UnexpectedClientErrorException (4xx) or
UnexpectedServerErrorException (5xx). Both extend
Docker\Exception\UnexpectedStatusCodeException, which exposes the status
code, the request method and path, Dockerās error message and the response.
They also implement the generated ClientException and ServerException
interfaces, so existing catch blocks for those still match.
Success responses are unchanged: a 304 from starting a running container
still returns null, and raw responses (FETCH_RESPONSE) are never checked.
To return null for these responses instead, as 3.x did by default: