View source: R/docker_client.R
docker_client | R Documentation |
Create a docker client object, which allows you to interact with
docker from R. The object has several methods that allow
interaction with the docker daemon (for this object they are all
"system" commands) and collections, which contains further
methods. The client is structured similarly to the docker command
line client, such that docker container create <args>
in
the command line becomes docker$container$create(...)
in R
(if the client is called R).
docker_client(
...,
api_version = NULL,
host = NULL,
cert_path = NULL,
tls_verify = NULL,
machine = NULL,
http_client_type = NULL,
data_frame = NULL,
quiet = FALSE,
debug = NULL,
ignore_environment = FALSE
)
... |
Reserved for future use. Passing in any unrecognised argument will throw an error. Part of the role of this argument is to force use of named arguments until the API is stabilised. |
api_version |
Version of the API to use when communicating
with the docker daemon. The default value, |
host |
The URL for the docker daemon. This can be a unix
socket (e.g., unix:///var/run/docker.sock) on macOS/Linux, a
named pipe (e.g., |
cert_path |
The path to a directory containing certificate
files. If using an |
tls_verify |
Logical, indicating if TLS should be verified.
This is only used if using an https connection (i.e., host is a
tcp/http/https url and |
machine |
Scalar character (if provided) indicating the name
of a "docker machine" instance to use. If this is provided then
|
http_client_type |
HTTP client type to use. The options are
(currently) "curl", which uses the |
data_frame |
Function, used to wrap data.frames returned.
This may make output easier to consume. You might use
|
quiet |
Suppress informational messages. |
debug |
Enable http debugging (supported by the curl http
driver only). Provide a connection object and http headers and
content will be sent to it. Using |
ignore_environment |
Logical, indicating if environment
variables ( |
stevedore
can connect to the docker daemon via a unix
socket (this is the default set-up on Linux and macOS), over a
named pipe (Windows 10 - see below) and https over a normal tcp
connection (this is especially useful with
docker-machine
.
If the machine
argument is given then
stevedore
queries docker-machine
for settings. If
that command fails (e.g., there is no machine,
docker-machine
not installed) then that will cause an
error. (Note that the docker-machine
output does not
include API version information so the api_version
argument is relevant, but host
, cert_path
and
tls_verify
will be silently ignored if provided).
The arguments host
overrides the environment variable
DOCKER_HOST
, cert_path
overrides
DOCKER_CERT_PATH
and tls_verify
overrides
DOCKER_TLS_VERIFY
. If ignore_environment
is
TRUE
then the environment variables are not used at all.
if code
is not provided by any of the above methods
(machine, argument or environment variable) it will fall back
on the default unix socket (var/run/docker.sock
) on
Linux/macOS or the default windows named pipe
(npipe:////./pipe/docker_engine
) on windows.
The API version is set by the api_version
argument, which
falls back on the environment variable DOCKER_API_VERSION
(this is the same as the docker command line client and the python
SDK). If neither are provided then stevedore
will detect
the API version being used by the daemon and match that (provided
it falls within the range of versions supported by the package).
if (stevedore::docker_available()) {
# Create a new client object:
client <- stevedore::docker_client()
# Version information for your docker daemon:
client$version()
# General information about your daemon:
client$info()
# Most of the interesting methods are within the collections.
# For example, to see a summary of running containers:
client$container$list()
# (see ?docker_container) for more information.
}
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.