elek / docker-storj-extension Goto Github PK

Look like the extension is missing support for Arm platform.

 docker run --rm mplatform/mquery ghcr.io/elek/docker-storj-extension:20220728-2
Image: ghcr.io/elek/docker-storj-extension:20220728-2 (digest: sha256:d7e0edc4d1f90f36540028789a98b70b6c15e954f38cc7f0329d0a981ce44a57)
 * Manifest List: No (Image type: application/vnd.docker.distribution.manifest.v2+json)
 * Supports: linux/amd64

docker extension install ghcr.io/elek/docker-storj-extension:20220728-2
Extensions can install binaries, invoke commands and access files on your machine. 
Are you sure you want to continue? [y/N] y
Image not available locally, pulling ghcr.io/elek/docker-storj-extension:20220728-2...
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
installation could not be completed due to: executing 'docker --context default cp bed34b8b339e8218045e834489d25060422b02751c2da70d80566740bea70853:/metadata.json /var/folders/1v/ybkpsn791wbg5v5vgxlxky840000gn/T/-ext-install2256936921/metadata.json' : exit status 1: 
Error: No such container:path: bed34b8b339e8218045e834489d25060422b02751c2da70d80566740bea70853:/metadata.json

Backend calls good old CLI commands under the hood (see backend/service.go). If it fails, it returns with an error (including stdout).

But some of the commands (like docker push) are quite slow.

It would be better to start the command and continuously streaming the output to the frontend which would show new lines immediately.

In the current, very simple prototype, we just wait until the response is received.

The Hacktoberfest topic is written wrong on repository topics

Now:
hactoberfest

How should be:
hacktoberfest

• Add standard Github workflow commands in the CONTRIBUTING.md (opening issues, get assigned, fork, create clone, add, commit, creating PRs).
• It provides new potential project contributors with a short guide to how they can help with your project.

Some frontend pages already have a lightweight error handling. Like in Push.vue:

var push = function(name, tag) {
  error.value = ""
  message.value = ""
  Api.push(name, tag).then(function () {
    message.value = "Container has been pushed successfully"
  }, function (e) {
    error.value = e.response.data.error
  })
}

And the render:

  <p class="alert alert-danger" role="alert" v-if="error">{{ error }}</p>
  <p class="alert alert-success" role="alert" v-if="message" v-html="message"></p>

Would be nice to make it more generic: in case of any HTTP request the failure should be written out to warn the user, that sg. is wrong.

This is the biggest blocking problem with this extension, right now.

The MVP goal is to push/pull images with the help of a local registry (which is backed by StorjDCS).

This is equivalent with:

docker run -p 9999:5000 -e REGISTRY_STORAGE_STORJ_BUCKET=docker -e REGISTRY_STORAGE_STORJ_ACCESSGRANT=$(cat /tmp/grant) ghcr.io/elek/distribution:618d19fb
docker tag elek/herbstag localhost:9999/elek/herbstag
docker push localhost:9999/elek/herbstag

Unfortunately it's not so easy to start AND access the port of the container.
The port 9999 should be accessible:

• by the docker daemon itself (to push images)
• by the extension backend (to check the already uploaded images)

The approaches what we tried out until now:

• We started new docker instance from backend (docker run...) with forwarded port

  • This approach requires a free port on host
  • The port is accessible by the docker daemon but not by the extension (!!!)

• We started the registry inside the backend container as a new unix process

  • This makes it available for the backend (to check the already uploaded images)
  • But the port is not available for the docker daemon

There are two possible solution

1. We can try to expose the port of the backend container to the host. (maybe a change in the docker-compose?)
2. We can change the implementation of (Service).RemoteImages() in backend/service.go to directly check the Storj DCS bucket instead of checking the port of the docker registry. This would make it possible to use approach 1.