I'm writing an API client for docker and the registry API is difficult to work with. I'm trying to delete an image from the registry however I keep getting this error
[ { code: 'UNSUPPORTED', message: 'The operation is unsupported.' } ]
My steps to get this are as follows,
> GET http://localhost:5000/v2/
> registry/2.0
> registry/2.0
> GET http://localhost:5000/v2/_catalog/
> { repositories: [ 'alpine' ] }
> GET http://localhost:5000/v2/alpine/tags/list
> { name: 'alpine', tags: [ 'latest' ] }
> HEAD http://localhost:5000/v2/alpine/manifests/latest
> sha256:df73ed0973f15f40496c148330f9b559f0a5583c03f6ac8d26adadf6f4690aff
> DELETE http://localhost:5000/v2/alpine/manifests/sha256:df73ed0973f15f40496c148330f9b559f0a5583c03f6ac8d26adadf6f4690aff
[ { code: 'UNSUPPORTED', message: 'The operation is unsupported.' } ]
EDIT
I'm updating my question since I found the REGISTRY_STORAGE_DELETE_ENABLED variable.
I now run the registry container like so,
docker run -d -p 5000:5000 -e REGISTRY_STORAGE_DELETE_ENABLED=true --name registry2 registry
Which produces a new error,
[ { code: 'MANIFEST_UNKNOWN', message: 'manifest unknown' } ]
Clearly the UNSUPPORTED error, really meant that the particular feature was disabled.
However everything I read says that deleting the manifest's entity reference (the digest from the HEAD request) should remove the repository. I just want to make a repository in my private registry unreachable, I consider that deleted.
How do I delete an image from a private registry, such that it may not be pulled?
Even if this is an old question: The solution is simple.
DELETE http://localhost:5000/v2/alpine/manifests/sha256:df73ed0973f15f40496c148330f9b559f0a5583c03f6ac8d26adadf6f4690aff
is wrong because the digest is prefixed with sha256:. Simple remove the prefix and then a delete is possible:
DELETE http://localhost:5000/v2/alpine/manifests/df73ed0973f15f40496c148330f9b559f0a5583c03f6ac8d26adadf6f4690aff
Related
I ran this code to check and delete the imagestreams in Openshift
openshift.withCluster("${CLUSTER_NAME}") {
openshift.withProject("${DEV_ENV}") {
if (openshift.selector('imagestreams', '${imagestream_name}').exists()) {
openshift.selector('imagestreams', '${imagestream_name}').delete()
then I ran this
openshift.withCluster("${CLUSTER_NAME}") {
openshift.withProject("${DEV_ENV}") {
openshift.apply(openshift.raw("create -f '${imagestream_name}'.yaml"))
to create new imagestream from local yaml file but it end up with this error
ERROR: raw command [create -f 'imagestream-test'.yaml] returned an error;
{err=Error from server (AlreadyExists): error when creating "imagestream-test.yaml": imagestreams.image.openshift.io "testimagestream" already exists
Is there anyway to check if the imagestream is already in openshift ?
How about using apply instead of create? oc apply will create a resource if it doesn't exist or update if it does.
openshift.withCluster("${CLUSTER_NAME}") {
openshift.withProject("${DEV_ENV}") {
openshift.apply(openshift.raw("apply -f '${imagestream_name}'.yaml"))
I want to use buildah from gitlab-ci, in order to build an image, run a container from it and do some tests against it.
My current gitlab-ci is:
tests:
tags:
- docker
image: quay.io/buildah/stable
stage: test
variables:
STORAGE_DRIVER: "vfs"
BUILDAH_FORMAT: "docker"
BUILDAH_ISOLATION: "rootless"
only:
refs:
- merge_requests
changes:
- **/*
script:
- buildah info --debug
- buildah unshare docker/test/run.sh
My runner is private gitlab runner, I don't want to change its configuration (to not break other CI).
The content of run.sh is:
#!/usr/bin/env bash
set -euo pipefail
container=$(buildah --ulimit nofile=8192 --name my-container from phusion/baseimage:bionic-1.0.0-amd64)
The error is:
level=warning msg="error reading allowed ID mappings: error reading subuid mappings for user \"root\" and subgid mappings for group \"root\": No subuid ranges found for user \"root\" in /etc/subuid" level=warning msg="Found no UID ranges set aside for user \"root\" in /etc/subuid." level=warning msg="Found no GID ranges set aside for user \"root\" in /etc/subgid." No buildah sali-container already exists... Package Sali Creating sali-container Completed short name "phusion/baseimage" with unqualified-search registries (origin: /etc/containers/registries.conf) Getting image source signatures Copying blob
sha256:36505266dcc64eeb1010bd2112e6f73981e1a8246e4f6d4e287763b57f101b0b Copying blob
sha256:1907967438a7f3c5ff54c8002847fe52ed596a9cc250c0987f1e2205a7005ff9 Copying blob
sha256:23884877105a7ff84a910895cd044061a4561385ff6c36480ee080b76ec0e771 Copying blob
sha256:2910811b6c4227c2f42aaea9a3dd5f53b1d469f67e2cf7e601f631b119b61ff7 Copying blob
sha256:bc38caa0f5b94141276220daaf428892096e4afd24b05668cd188311e00a635f Copying blob
sha256:53c90fd859186b7b770d65adcb6ae577d4c61133f033e628530b1fd8dc0af643 Copying blob
sha256:d039079bb3a9bf1acf69e7c00db0e6559a86148c906ba5dab06b67c694bbe87c Copying config
sha256:32c929dd2961004079c1e35f8eb5ef25b9dd23f32bc58ac7eccd72b4aa19f262 Writing manifest to image destination Storing signatures level=error msg="Error while applying layer: ApplyLayer
exit status 1 stdout: stderr: potentially insufficient UIDs or GIDs available in user namespace (requested 0:42 for /etc/gshadow): Check /etc/subuid and /etc/subgid: lchown /etc/gshadow: invalid argument" 4 errors occurred while pulling:
* Error initializing source docker://registry.fedoraproject.org/phusion/baseimage:bionic-1.0.0-amd64: Error reading manifest bionic-1.0.0-amd64 in registry.fedoraproject.org/phusion/baseimage: manifest unknown: manifest unknown
* Error initializing source docker://registry.access.redhat.com/phusion/baseimage:bionic-1.0.0-amd64: Error reading manifest bionic-1.0.0-amd64 in registry.access.redhat.com/phusion/baseimage: name unknown: Repo not found
* Error initializing source docker://registry.centos.org/phusion/baseimage:bionic-1.0.0-amd64: Error reading manifest bionic-1.0.0-amd64 in registry.centos.org/phusion/baseimage: manifest unknown: manifest unknown
* Error committing the finished image: error adding layer with blob "sha256:23884877105a7ff84a910895cd044061a4561385ff6c36480ee080b76ec0e771": ApplyLayer exit status 1 stdout: stderr: potentially insufficient UIDs or GIDs available in user namespace (requested 0:42 for /etc/gshadow): Check /etc/subuid and /etc/subgid: lchown /etc/gshadow: invalid argument level=error msg="exit status 125" level=error msg="exit status 125"
The result of buildah info --debug:
{
"debug": {
"buildah version": "1.18.0",
"compiler": "gc",
"git commit": "",
"go version": "go1.15.2"
},
"host": {
"CgroupVersion": "v1",
"Distribution": {
"distribution": "fedora",
"version": "33"
},
"MemFree": 9021378560,
"MemTotal": 15768850432,
"OCIRuntime": "runc",
"SwapFree": 0,
"SwapTotal": 0,
"arch": "amd64",
"cpus": 4,
"hostname": "runner-cvBUQadt-project-2197143-concurrent-0",
"kernel": "4.14.83+",
"os": "linux",
"rootless": false,
"uptime": "6391h 28m 15.45s (Approximately 266.29 days)"
},
"store": {
"ContainerStore": {
"number": 0
},
"GraphDriverName": "vfs",
"GraphOptions": [
"vfs.imagestore=/var/lib/shared"
],
"GraphRoot": "/var/lib/containers/storage",
"GraphStatus": {},
"ImageStore": {
"number": 0
},
"RunRoot": "/var/run/containers/storage"
}
}
I read other posts about the errors I had and came to this configuration, which is not enough. I choose buildah by thinking it would be easy to use from a CI as it is supposed to run rootless, but this is a real nightmare... I am poor lonesome developer and not a sysadmin, I don't understand how to setup linux for buildah... Can somebody help me?
Buildah is going to need to run as root or within a user namespace with sufficent UIDs to install files with different UID.
This looks like for some reason buildah thought it should run within a user namespace and then did not find root listed within the user namespace. This usually happens when you did not run with enough privileges.
I needed a custom centos image with docker installed. So I built it using centos image and tagged it custom (shown below).
$ docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
centos custom 84766562f881 4 hours ago 664MB
centos/systemd latest 05d3c1e2d0c1 7 weeks ago 202MB
I am trying to deploy couple of containers using Terraform on my local machine, each with a unique name that comes from another file. The docker images are on local machine. Here's the TF code.
$ cat main.tf
provider "docker" {
}
resource "docker_image" "centos" {
name = "centos:custom"
}
resource "docker_container" "app_swarm" {
image = "${docker_image.centos.custom}"
count = "${length(var.docker_cont)}"
name = "${element(var.docker_cont, count.index)}"
}
When I run terraform apply, I get this error which I am not sure how to fix. Can someone point me in the right direction please?
Error: Error running plan: 1 error(s) occurred:
* docker_container.app_swarm: 3 error(s) occurred:
* docker_container.app_swarm[0]: Resource 'docker_image.centos' does not have attribute 'custom' for variable 'docker_image.centos.custom'
* docker_container.app_swarm[1]: Resource 'docker_image.centos' does not have attribute 'custom' for variable 'docker_image.centos.custom'
* docker_container.app_swarm[2]: Resource 'docker_image.centos' does not have attribute 'custom' for variable 'docker_image.centos.custom'
Yes, the other file exists with names, its a simple list.
EDIT:
Thanks David, tried your suggestion and amended the code to look like-
provider "docker" {
}
resource "docker_image" "centos" {
name = "centos:custom"
}
resource "docker_container" "app_swarm" {
image = "${docker_image.centos.latest}"
count = "${length(var.docker_cont)}"
name = "${element(var.docker_cont, count.index)}"
}
But now I get this error.
Error: Error applying plan:
1 error(s) occurred:
* docker_image.centos: 1 error(s) occurred:
* docker_image.centos: Unable to read Docker image into resource: Unable to pull image centos:custom: error pulling image centos:custom: Error response from daemon: manifest for centos:custom not found
I guess I will have to setup a local Docker repository to get this working but I am not sure?
You can only use the specific fields listed in the docker_image resource documentation in the ${docker_image.centos...} interpolation. In particular, even though you don't use the tag :latest, you need a .latest property reference:
image = "${docker_image.centos.latest}"
(If the image actually is one you've built locally, you may also want to specify the keep_locally option on your docker_image resource so that terraform destroy won't delete it.)
While trying to build an awx image (Ansible works) for ppc64le, the following comes up:
TASK [image_build : Build AWX distribution using container] ***************************************************************************************************************************************************
fatal: [localhost -> localhost]: FAILED! => {"changed": false, "msg": "Error creating container: 400 Client Error: Bad Request (\"invalid reference format\")"}
to retry, use: --limit #/root/awx/installer/install.retry
PLAY RECAP ****************************************************************************************************************************************************************************************************
localhost : ok=10 changed=3 unreachable=0 failed=1
How can I see what really happens in the background? Any verbose docker logs that I can look at? The message itself is somewhat useless to me. I already set Ansible to verbose but this also was of no help.
Docker image names can only consist of lowercase (a-z) characters.
Either you are giving a un-supported image name or the variable(or paths) passed to the buid(or the container) cannot be resolved.
To enable debug logs, add "--debug" to docker daemon (/etc/systemd/system/multi-user.target.wants/docker.service for systemd based linux env)
For reference: https://docs.docker.com/config/daemon/#configure-the-docker-daemon
I'm new to EB and AWS, and my docker images build fine but fail to run on Elastic Beanstalk. My suspicion is that they are not connecting to the database correctly, however, I'm not getting anything useful when I run "eb logs" from the commandline. Here are the errors:
{
"status": "FAILURE",
"api_version": "1.0",
"results": [
{
"status": "FAILURE",
"msg": "(TRUNCATED)...rrun.aws.json: No such file or directory
73927c49adff622a1a229d9369bdd80674d96d20f3eb99a9cdea786f4411a368
Docker container quit unexpectedly after launch: Docker container quit unexpectedly on Wed May 20 17:15:02 UTC 2015:.
Check snapshot logs for details.
Hook /opt/elasticbeanstalk/hooks/appdeploy/pre/04run.sh failed.
For more detail, check /var/log/eb-activity.log using console or EB CLI",
"returncode": 1,
"events": [
{
"msg": "Successfully pulled node:0.12.2-slim",
"severity": "TRACE",
"timestamp": 1432142064
},
{
"msg": "Successfully built aws_beanstalk/staging-app",
"severity": "TRACE",
"timestamp": 1432142094
},
{
"msg": "Docker container quit unexpectedly after launch: Docker container quit unexpectedly on Wed May 20 17:15:02 UTC 2015:. Check snapshot logs for details.",
"severity": "ERROR",
"timestamp": 1432142102
}
]
}
],
"truncated": "true"
}
And after the build completes:
[2015-05-20T17:15:02.694Z] INFO [8603] - [CMD-AppDeploy/AppDeployStage0/AppDeployPreHook/04run.sh] : Activity execution failed, because: cat: /var/app/current/Dockerrun.aws.json: No such file or directory
cat: /var/app/current/Dockerrun.aws.json: No such file or directory
73927c49adff622a1a229d9369bdd80674d96d20f3eb99a9cdea786f4411a368
Docker container quit unexpectedly after launch: Docker container quit unexpectedly on Wed May 20 17:15:02 UTC 2015:. Check snapshot logs for details. (ElasticBeanstalk::ExternalInvocationError)
caused by: cat: /var/app/current/Dockerrun.aws.json: No such file or directory
cat: /var/app/current/Dockerrun.aws.json: No such file or directory
73927c49adff622a1a229d9369bdd80674d96d20f3eb99a9cdea786f4411a368
Docker container quit unexpectedly after launch: Docker container quit unexpectedly on Wed May 20 17:15:02 UTC 2015:. Check snapshot logs for details. (Executor::NonZeroExitStatus)
The docker containers work locally, so what else can I do to figure out what's going wrong? I keep hearing about "snapshot logs" but where do I check these snapshot logs? Are they the output of what I'm already running "eb logs"?
I had this issue for a day or two. I managed to see the logs by going AWS Console > Elastic Beanstalk > Environment > ${YOUR_APPLICATION_ENV}
On the left pane;
Log > Request Logs > Download > Open in any text editor.
/var/log/eb-docker/containers/eb-current-app/
Follow the path and you will see the what causing the error and can fix it.
Assuming you have SSH access to the EC2 instance running your container, these are a few log files useful for debugging single container Docker instances in Beanstalk:
/tmp/docker_build.log
/tmp/docker_pull.log
/tmp/docker_run.log
In order to look at the error logs for the running process, first read the
/tmp/docker_run.log file. This file contains the Docker process id. Something like this:
c6ae58e4ad77e926f6a8230237acf95771c6b5d80d48fb1bc20591f964fd690c
The first few characters should match the process listed from the command docker ps. Use this value to find the corresponding log file in the following directory:
/var/log/eb-docker/containers/eb-current-app/
The format of the file name is eb-docker-ps-id-stdouterr.log
I had this issue when my containers were crashing because there was no traffic allowed between EBS and RDS. If you use any database try curling it. Also, you might want to try sudo docker logs CONTAINER_ID a try catching something useful. What might help also is trying to launch container manually from the instance. There's slight possibility something will come up.