garethr-docker: Docker Community Edition `docker daemon` is not supported on Linux.

Hello, facing this issue too, easy solution (waiting for the PR to be merged), if you’re using Hiera:

docker::service::docker_command: 'dockerd'
docker::service::daemon_subcommand: ''

This works perfectly with docker 17.06 under CentOS7

Quick warning: while setting docker::service::docker_command: in Hiera will work for new installs, it’s not bullet proof.

Anyone who’s run into this problem in frustration and thus doesn’t have a running copy of docker wont be able to get back and running this way, as the module itself tries to run docker before applying the service-overrides.conf file and thus will never get to the step of updating the file.

Thus you will be forced to update it manually or with some in-file puppet magic.

Honestly I think the “process” is backwards in the module. all settings should be set before starting/restarting the service, which removes this “the module sets it back but the service is still running” scenario.

@LongLiveCHIEF Nope, I’m overriding only the docker::service class, not the base docker class, it works perfectly, I’m running container and pulling images through puppet without any issue

@LongLiveCHIEF go for it.

In my PR, there is no assumption that dockerd is installed. The way the fact works is you either get a nil value for $dockerd_binary, as you would in the case of running an older version of docker, or you would get a string value containing the path to the dockerd binary. Here’s the details on Facter::Core::Execution#which (http://www.rubydoc.info/gems/facter/2.4.6/Facter/Core/Execution#which-class_method)

In the unit file templates, (https://github.com/garethr/garethr-docker/pull/704/files#diff-7dae3e5d9fd27c34844a4d6e0485e2e0L8) and (https://github.com/garethr/garethr-docker/pull/704/files#diff-1ae24078d52aa1e01fa570dd84a1efddR5) there’s a boolean check for the binary. If $dockerd_binary is nil then we’ll use the older docker daemon command.

Yep, already got that one. Here’s what I’ve done so far.

The challenge I’m working through as we speak is the dual nature of docker_command usage in the module.

In the manifests/run.pp, manifests/image.pp, manifests/exec.pp, etc… docker_command is used as a client library. I can’t just change up docker_command = 'dockerd'.

The approach I’m taking right now, is to have 3 parameters (with defaults given):

$docker_command = 'docker'
$daemon_command = 'dockerd'
$daemon_subcommand = undef

Using daemon_subcommand will output a deprecation warning, and shim the correct usage of docker daemon vs dockerd.

This will allow compatibility with any existing downstream manifests while enabling the latest versions of docker to run.