Questions about the 'deploy configurations'

[DecaTec]

I'm referring here to the docs 'Deploy configurations': https://nextcloud.github.io/app_api/DeployConfigurations.html

Questions in bold.

---

When I got it right, the first (and easiest) configuration is 'NC and Docker on the same host' (see here):

• The Docker Socket Proxy is not needed in this case.
• Direct communications with Docker via /var/docker/docker.sock

I've configured this exactly as mentioned in the docs:

Daemon host: /var/run/docker.sock
HTTPS checkbox: not supported using docker socket
Network: host
HaProxy password: not supported using raw docker socket, should be empty

When testing the connection, this fails and I get following error in the NC logs:

ConnectException
cURL error 7: Failed to connect to localhost port 80 after 0 ms: Couldn't connect to server (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for http://localhost/v1.41/_ping
Could not connect to Docker daemon

Question 1: Why it tries to connect to localhost on port 80? Shouldn't it use the Docker socket directly (without HTTP communication)?

Question 2: Am I missing something here? Is the documentation lacking an important piece of information?

---

Using the Docker Socket Proxy, see "Suggested way to communicate with Docker via Docker Socket Proxy container" it works then using method A or B.

Question 3: What are the advantages/disadvantages between "direct communication via /var/run/docker.sock" and using the Docker Socket Proxy? Is there one recommended way when NC, Docker and ext. apps should run on the same system?

---

Thanks in advance!

[oleksandr-nc]

Question 1: Why it tries to connect to localhost on port 80? Shouldn't it use the Docker socket directly (without HTTP communication)?

Probably it have no access to the file(does te webuser can access docker socket file?), as file_exists function fails.

public function buildDockerUrl(DaemonConfig $daemonConfig): string {
		if (file_exists($daemonConfig->getHost())) {
			return 'http://localhost';
		}
		return $daemonConfig->getProtocol() . '://' . $daemonConfig->getHost();
	}

Question 3: What are the advantages/disadvantages between "direct communication via /var/run/docker.sock" and using the Docker Socket Proxy?

Security considerations; DockerSocketProxy restricts what commands can be send to the Docker and with what arguments.

Is there one recommended way when NC, Docker and ext. apps should run on the same system?

We always recomend from our side to use Docker-Socket-Proxy&

[DecaTec]

Thanks for the clarification!

Regarding "Direct communications with Docker via /var/docker/docker.sock": The webserver user not having access to the socket seems to be the problem here.

Suggestion 1: Wouldn't it be better to generate an error message here and not switching to local HTTP communication?

---

Using the Docker Socket Proxy seems to be the preferred way here (for security reasons).

**Suggestion 2: Maybe the should be more clear in the documentation, e.g. "always use Docker Socket Proxy, use direct communication only as last resort"?

---

And another question: When using the Docker Socket Proxy, the documentation says the "mount" the socket in the container:

-v /var/run/docker.sock:/var/run/docker.sock

Does the webserver user also needs access to the socket in this scenario? I guess not, because its also working with no modified access rights.

[R0Wi]

Suggestion 1: Wouldn't it be better to generate an error message here and not switching to local HTTP communication?

I guess there's a reason why this fallback has been implemented (even though I don't know it 😄 ). But what would definitely help here would logging a warning.

**Suggestion 2: Maybe the should be more clear in the documentation, e.g. "always use Docker Socket Proxy, use direct communication only as last resort"?

If you check https://docs.nextcloud.com/server/latest/admin_manual/exapps_management/DeployConfigurations.html#docker-deploy-daemon, the warning is pretty prominent IMHO 😃

Does the webserver user also needs access to the socket in this scenario? I guess not, because its also working with no modified access rights.

No, in case you're using the Docker Socket Proxy, the proxy is the only component which needs direct access to the Docker socket. What it does is (besides security, authentication, ...) it basically routes the Docker commands through it's http REST interface to the socket and returns the result. You can find a working solution here: https://apps.nextcloud.com/apps/workflow_ocr_backend . Depending on your setup you might only be interested in using the nextcloud-appapi-dsp service of the mentioned docker-compose file.

[oleksandr-nc]

Wouldn't it be better to generate an error message here and not switching to local HTTP communication?

yes, it is possible to do this (check whether the path starts with a slash, URL of DSP can't start with a slash) - someone need to make a PR for this.

[R0Wi]

I can prepare something if needed

[oleksandr-nc]

Feel free to do it, if you have time, we will be happy to review the PR.

[oleksandr-nc]

I think with the merged PR from R0Wi we can close it as resolved.