beluga-php / docker-php Goto Github PK

In my latest PR #66 I changed the action that was publishing the code coverage report because I thought the env variable CC_TEST_REPORTER_ID was somehow added to the CI builds of the master branch but I apparently is not.

Should we remove until someone is willing to configure code climate again?

I'm using Orbstack the majority of the time as a Docker Desktop for Mac replacement.

The test suite currently blocks on tests/DockerTest.php when reading the contents of the response to a request to /v1.43/info

Debugging through the HTTP client I can see an \Http\Message\Encoding\DechunkStream is being used for the response but for some reason although its buffer fills with the following, getContents() never returns:

{"ID":"cd6466c2-a9c2-4b2b-835a-970306beb8d8","Containers":0,"ContainersRunning":0,"ContainersPaused":0,"ContainersStopped":0,"Images":13,"Driver":"overlay2","DriverStatus":[["Backing Filesystem","btrfs"],["Supports d_type","true"],["Using metacopy","false"],["Native Overlay Diff","true"],["userxattr","false"]],"Plugins":{"Volume":["local"],"Network":["bridge","host","ipvlan","macvlan","null","overlay"],"Authorization":null,"Log":["awslogs","fluentd","gcplogs","gelf","journald","json-file","local","logentries","splunk","syslog"]},"MemoryLimit":true,"SwapLimit":true,"CpuCfsPeriod":true,"CpuCfsQuota":true,"CPUShares":true,"CPUSet":true,"PidsLimit":true,"IPv4Forwarding":true,"BridgeNfIptables":true,"BridgeNfIp6tables":true,"Debug":false,"NFd":26,"OomKillDisable":false,"NGoroutines":43,"SystemTime":"2024-03-18T17:42:19.196730961Z","LoggingDriver":"json-file","CgroupDriver":"cgroupfs","CgroupVersion":"2","NEventsListener":1,"KernelVersion":"6.5.13-orbstack-00121-ge428743e4e98","OperatingSystem":"OrbStack","OSVersion":"","OSType":"linux","Architecture":"aarch64","IndexServerAddress":"https://index.docker.io/v1/","RegistryConfig":{"AllowNondistributableArtifactsCIDRs":null,"AllowNondistributableArtifactsHostnames":null,"InsecureRegistryCIDRs":["127.0.0.0/8"],"IndexConfigs":{"docker.io":{"Name":"docker.io","Mirrors":[],"Secure":true,"Official":true}},"Mirrors":null},"NCPU":8,"MemTotal":12526673920,"GenericResources":null,"DockerRootDir":"/var/lib/docker","HttpProxy":"","HttpsProxy":"","NoProxy":"","Name":"orbstack","Labels":[],"ExperimentalBuild":false,"ServerVersion":"24.0.7","Runtimes":{"io.containerd.runc.v2":{"path":"runc"},"runc":{"path":"runc"}},"DefaultRuntime":"runc","Swarm":{"NodeID":"","NodeAddr":"","LocalNodeState":"inactive","ControlAvailable":false,"Error":"","RemoteManagers":null},"LiveRestoreEnabled":false,"Isolation":"","InitBinary":"docker-init","ContainerdCommit":{"ID":"8c087663b0233f6e6e2f4515cee61d49f14746a8","Expected":"8c087663b0233f6e6e2f4515cee61d49f14746a8"},"RuncCommit":{"ID":"82f18fe0e44a59034f3e1f45e475fa5636e539aa","Expected":"82f18fe0e44a59034f3e1f45e475fa5636e539aa"},"InitCommit":{"ID":"de40ad0","Expected":"de40ad0"},"SecurityOptions":["name=seccomp,profile=builtin","name=cgroupns"],"ProductLicense":"Community Engine","DefaultAddressPools":[{"Base":"192.168.215.0/24","Size":24},{"Base":"192.168.228.0/24","Size":24},{"Base":"192.168.247.0/24","Size":24},{"Base":"192.168.207.0/24","Size":24},{"Base":"192.168.167.0/24","Size":24},{"Base":"192.168.107.0/24","Size":24},{"Base":"192.168.237.0/24","Size":24},{"Base":"192.168.148.0/24","Size":24},{"Base":"192.168.214.0/24","Size":24},{"Base":"192.168.165.0/24","Size":24},{"Base":"192.168.227.0/24","Size":24},{"Base":"192.168.181.0/24","Size":24},{"Base":"192.168.158.0/24","Size":24},{"Base":"192.168.117.0/24","Size":24},{"Base":"192.168.155.0/24","Size":24},{"Base":"192.168.147.0/24","Size":24},{"Base":"192.168.229.0/24","Size":24},{"Base":"192.168.183.0/24","Size":24},{"Base":"192.168.156.0/24","Size":24},{"Base":"192.168.97.0/24","Size":24},{"Base":"192.168.171.0/24","Size":24},{"Base":"192.168.186.0/24","Size":24},{"Base":"192.168.216.0/24","Size":24},{"Base":"192.168.242.0/24","Size":24},{"Base":"192.168.166.0/24","Size":24},{"Base":"192.168.239.0/24","Size":24},{"Base":"192.168.223.0/24","Size":24},{"Base":"192.168.164.0/24","Size":24},{"Base":"192.168.163.0/24","Size":24},{"Base":"192.168.172.0/24","Size":24},{"Base":"172.17.0.0/16","Size":16},{"Base":"172.18.0.0/16","Size":16},{"Base":"172.19.0.0/16","Size":16},{"Base":"172.20.0.0/14","Size":16},{"Base":"172.24.0.0/14","Size":16},{"Base":"172.28.0.0/14","Size":16}],"Warnings":null}

It's possible Orbstack is behaving wrongly here (maybe never EOFing?) but I'm not sure how to proceed debugging the socket connection.

I have been trying to update to the latest 1.43 latest for some weeks but I couldn't due to some cryptic error on the socket when I tried to do an imageBuild.

[error]  An error occur when writing request to client (BROKEN EPIPE)
ERROR: fwrite(): Send of 8192 bytes failed with errno=32 Broken pipe
in /home/basin/vendor/php-http/socket-client/src/RequestWriter.php:97

After quite a lot of investigation updating docker-php commit by commit I found
c44e046

I don't know if that was an accidental removal since the commit message explains something else.
That commit makes many classes under the \Docker\Endpoint dead code except for ImagePush.
In the case of ImageBuild the wrapper endpoint is needed to send a proper tar stream to the socket.
Also I don't know if the other calls like containerLogs are broken too.

I believe the action plan would be to first restore those lines in Docker.php and then add some kind of end-to-end tests to ensure imageBuild won't be broken in the future.

When I run

docker run --name test busybox:latest echo hello

I can see the output in the logs with

docker logs test

but running

$logs = $docker->containerLogs('test', ['stdout' => true]);

never returns anything.

I did a bit of debugging of the ContainerLogs.php class and it seems it expects the body to be JSON but the is received as a string
https://github.com/beluga-php/docker-php-api/blob/main/src/Endpoint/ContainerLogs.php#L83

When using the current docker-php main branch, together with the current docker-php-api master, I have the problem that
$docker->containerCreate($containerConfig); returns null, but without any exception. The requested container was not created.

System:

• Debian 12
• Docker version 24.0.6
• php8.2

Code snippet with a simplified version of the usage:

$docker = Docker::create();
$containerConfig = new ContainersCreatePostBody();
$containerConfig->setImage($docker_image);

$hostConfig = new HostConfig();

$portBinding = [
  'HostIp' => env('CTF_DOCKER_HOST_BIND_IP', '0.0.0.0'),
  'HostPort' => '8000'
];
$portMap[$intern . '/tcp'] = [$portBinding];
$hostConfig->setPortBindings($portMap);

$exposedPorts = [];
foreach ($portMap as $key => $value) {
    $exposedPorts[$key] = new \ArrayObject([], \ArrayObject::ARRAY_AS_PROPS);
}
$containerConfig->setExposedPorts($exposedPorts);

$containerConfig->setHostConfig($hostConfig);

$containerCreateResult = $docker->containerCreate($containerConfig);
asserNull($containerCreateResult); // true

Any idea what's going wrong?

I have some PHP8 scripts that build images and I would want to keep all dependencies updated so I replaced
https://packagist.org/packages/romantomchak/docker-php
for this client and it seems that all run good.

What are the steps you consider are needed for a stable v3 release?

From there we can maybe contact the previous developer so this fork is recommended as the replacement

We recently made some changes to https://github.com/beluga-php/docker-php/blob/master/src/DockerClientFactory.php based on beluga-php/docker-php-api#14

There's a few issues around the return types, and discovery classes need to be updated to psr17/18.

However the main issue is around sockets, specifically Guzzle only supports sockets via curl opts, for example guzzle/guzzle#1962. However because we're using PluginClient there's no way to pass the options to guzzle.

In symfony/http-client it uses the bindto option to bind to a unix socket using the same curl_opt (https://github.com/symfony/http-client-contracts/blob/main/HttpClientInterface.php).

Unfortunately this makes Unix socket communication implementation specific and not something which could be supported using PluginClient.

Therefore we need to make a decision of whether to move back to php-http/socket-client or make our library slightly more opinionated and use a specific http client.

socket-client is going to be abandoned shortly, however forcing a http client is also not ideal as it may conflict with an existing client, or the user may have a different preference.

Taking everything into account, I think switching back to socket-client and either making a PR to fix the issues, or creating an issue with the maintainer there is probably the best way forward right now. However I'd definitely like to hear what others think?

@flavioheleno

I've been thinking for a while now on rewriting this library from ground-up and replace any auto-generated code with hand crafted code, to avoid the issues we see with the changes and weird behaviors of JanePHP.

I'd like to gauge interest/opinions around this, specially from users who have been interacting by submitting issues and PRs.

Shall we start a new library or keep things as they are?

Currently when you visit https://packagist.org/packages/beluga-php/docker-php it appears that v2.0.0 is the latest version.

This could be confusing, so I think we should remove this release from packagist.

@flavioheleno if you want to add me to the package, my username is the same as github.

The latest release of beluga-php/docker-php-api (6.1.41.1) pushed earlier today, changes the signature of imageBuild, imageCreate and execStart.
This is a BC, but as its version is currently locked to 6.1.41.0 (here) no one should be affected.
I'm looking at launching a stable version (see #1) as soon as possible, bumping JanePHP to its next major release (thus pushing Docker PHP API to 7.x line) and any other dependencies as well.