I am trying to push to a private repository on dockerhub and am getting a strange error:
$ docker push myrepo/my-awesome-service:latest
The push refers to a repository [docker.io/myrepo/my-awesome-service] (len: 1)
cbf09022264b: Buffering to Disk
Error parsing HTTP response: invalid character '<' looking for beginning of value: "<html><body><h1>403 Forbidden</h1>\nRequest forbidden by administrative rules.\n</body></html>\n\n"
I have checked and made sure I have "admin" permissions on dockerhub. Any idea what could be causing this, or how I can fix it?
more info:
$ docker --version
Docker version 1.8.0, build 0d03096
This issue occurs in Docker 1.8.0.
Upgrading to the latest Docker (1.8.1 at time of posting) should resolve the issue.
Also, you may need to docker-machine upgrade <machine-name>
On debian based system just type:
$ sudo apt-get update
$ sudo apt-get upgrade
This will upgrade to 1.8.1 and solve the problem
Yes, must upgrade docker v1.8.1 (arm64),maybe something like API changed.
my docker version is now v1.8.1 built from source code ,and it can push the image to my public repository.
Related
I have a server with the old version of docker 17.06.1-ce and I've noticed that some images (built and pushed via new docker and docker buildx) cannot be pulled with the error, e.g.:
Error response from daemon: manifest for wodby/mariadb:10.3-3.24.0 not found
The image with this tag can be found on docker hub and docker pull works fine with newer docker.
The login to docker hub doesn't affect anything. I use the same architecture linux/amd64 on servers where it works and doesn't work.
Is this a known behaviour? Is there a way workaround for this? I guess the reason could be the deprecation of the old docker hub api.
UPD: according to https://www.docker.com/blog/registry-v1-api-deprecation/ docker 17.03+ are compatible with v2 registry API and should be working fine
It seems the issued caused by buildx version. I use GitHub Actions (docker/setup-buildx-action) to build images include the one that cannot be pulled. GitHub Actions has recently upgraded their build OS from Ubuntu 20.04 LTS to 22.04 LTS and with it they upgraded buildx from 0.9.1 to 0.10.0 and since then pull has stopped working. Most likely caused by SLSA provenance attestation https://github.com/docker/buildx/releases/tag/v0.10.0
I've resolved the pull issue by upgrading docker to at least 18.06+.
Ref https://forums.docker.com/t/docker-17-06-pull-returns-not-found-for-existing-image/134524/3
I set up a Windows GitLab runner that's supposed to download a Docker image from our Container Registry and then run a build script in the pipeline. Unfortunately the Docker container never launches due to the following error:
Running with gitlab-runner 15.1.0 (76984217)
on WindowsDockerRunner wZMWQZYi
Resolving secrets
Preparing the "docker-windows" executor
Using Docker executor with image mcr.microsoft.com/windows/servercore:ltsc2019 ...
Pulling docker image mcr.microsoft.com/windows/servercore:ltsc2019 ...
Using docker image sha256:e6b07227af5ca9303c2112b574f6f27f38135bbf9df29d829142410221967401 for mcr.microsoft.com/windows/servercore:ltsc2019 with digest mcr.microsoft.com/windows/servercore#sha256:26c6c296a4737ba478fe3c3e531b098f89b5562c40b416ba6fb8177ac462d1af ...
Preparing environment
Running on RUNNER-WZMWQZYI via
runner2...
ERROR: Job failed (system failure): prepare environment: Error response from daemon: invalid condition: "not-running". Check https://docs.gitlab.com/runner/shells/index.html#shell-profile-loading for more information
The error message doesn't clearly state what the cause of the problem is and the documentation that it references doesn't mention anything about "condition". Based on the link pointing to shell profiles I suspect it might have something to do with the shell that's being run, but when I run the Docker container locally it boots into PowerShell just fine.
Does anyone know how to solve this?
I came across this issue after installing Docker Engine using the Windows Server install script, which fetches docker.exe and dockerd.exe from https://master.dockerproject.org, These builds were last updated in March 2022, I found gitlab-runner 14.9 and earlier work okay with this version (released prior to March 2022), but 14.10 does not (released 2022-04-19) nor do any newer versions.
Installing Docker Desktop resolves this as it provides the latest version. However using Docker Desktop introduces licensing issues. An alternative is to manually install Docker Engine / update the version downloaded by the Microsoft script.
Docker Engine builds are provided on the Moby GitHub project to download from https://download.docker.com/win/static/stable/x86_64/ downloading the lastest version from here and replacing the docker executables in C:\Windows\System32 fixes the problem, working with the latest gitlab-runner.
An alternative is to use the docker-engine chocolatey package (which incidentally I maintain) which provides installation scripting for the above stable builds:
choco install docker-engine
There is also an open issue with the Windows-Containers team to move off (out of date) nightlies: https://github.com/microsoft/Windows-Containers/issues/256 which would provide a stable docker build, through the Microsoft recommended installation method.
Was finally able to solve this issue. We had the Docker Engine installed on our GitLab Runner, but that doesn't seem to be sufficient for GitLab CI/CD. After installing Docker Desktop on the runner the issue disappeared and we were able to run the pipeline.
After some trial and error I got it up and running.
I have another server running the gitlab-runner and docker without any issues (no docker desktop installed, which is not allowed because of licensing stuff).
The server I'm trying to setup right now is a 'redundancy' build server.
So to find out what was my problem, I started switching things from one build server to the other. Currently, it appears that simply downgrading to the gitlab-runner V13.4.0 was enough.
I did reregister the runner, since gitlab stated that the V15.x.x version was using executor "unknown".
Not sure what is going on there, but at least I can continue building now.
Thanks so much in advance for taking the time to read/provide any advice here.
So, I am trying to get an instance of MISP running through docker. The hardware I have it running on is a raspberry pi 4 running Ubuntu 20.04 (server edition).
I thought I installed all software dependencies, but being new to using docker, perhaps I haven't. I'm using this repository for the docker image: https://github.com/MISP/misp-docker
After running the command sudo docker-compose up after copying the .env file to the root directory, I get the error that I am going to post an image of below along with the text of the error for easy copy/pasting
ERROR: Service 'web' failed to build: The command '/bin/sh -c bash INSTALL_NODB.sh -A -u' returned a non-zero code: 1
ERROR MESSAGE SCREENSHOT
Once again, thank you all for any and all help! Please let me know if I can provide any more information!
Looks like this may be an issue that was closed in May of 2021 https://github.com/MISP/MISP/issues/7375. That Docker image has an INSTALL_NODB.sh that was initially committed in March 2021 https://github.com/MISP/misp-docker/commit/1e2f18f2c1211e382bd8df5371b1d3d718dad061. Since it was added before that fix the container may not include the fix for rpi that was added in the main repo. To verify, you can check if the output of uname -m is in this support map from the script used by the docker image https://github.com/MISP/misp-docker/blob/master/web/INSTALL_NODB.sh#L3070. If it isn't, then you would need this fix implemented in the docker image.
aarch64 isn't a supported architecture. There's a pull request on the repository that adds it, so you can add that change to your local repository like this (from a command line in the misp-docker repository):
git remote add fukusuket https://github.com/fukusuket/misp-docker.git
git fetch fukusuket
git merge fukusuket/hotfix/build-error-on-m1-mac -m "add aarch64 support"
Hopefully the pull request will be accepted soon and then you can go back to using the unaltered MISP git repository.
I'm trying to launch a Minikube cluster in my local machine with the latest version of Kubernetes (1.22.3 if I'm correct).
I run minikube start --kubernetes-version=v1.22.3 and the binaries are not found with error:
Failed to update cluster: downloading binaries: downloading kubeadm: Error downloading kubeadm v1.22.3: failed to download: failed to download to temp file: failed to create validator: failed to create validator: failed to download checksum file: received status code 404
I've tested to change the command and use an older version minikube start --kubernetes-version=v1.12.10 instead. This one works perfectly.
What am I doing wrong? If I'm correct that version (1.22.3) is already released. I've tested with versions in between, like around 1.19 and they are not working either.
Most probably you have an older version of the minikube installer binary. In order to check your version, run the following command:
minikube version
It should show you:
minikube version: v1.24.0
If it shows any older version, please go to minikube website and download the latest minikube installer binary for your OS. For Linux x86-64 architecture you can get and install it with the following commands:
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube
Then you can simply run:
minikube start
which will set up kubernetes cluster with its default version, which for the current latest version of Minikube happens to be v1.22.3, so exactly the version you need. Or you can specify this version explicitly:
minikube start --kubernetes-version=v1.22.3
which will also work.
I have downloaded docker binary version 1.8.2 and copied that to my backup server (centos server) which doesn't have internet connectivity. I have marked this as executable and started the docker daemon as mentioned in [https://docs.docker.com/engine/installation/binaries/][1]. But it doesn't seem to get installed as a docker service. For all the commands, I have to execute as sudo ./docker-1.8.2 {command}. Is there a way to install docker-engine as a service? Currently sudo docker version shows command not found. I'm a newbie to docker setup. Please advise.
Why not download the rpm package (there are also centos 6 packages), copy to USB stick and then to your server and simply install it with rpm command and that's it. That way you'd get the same installation as if you were to run yum.
Of course you may have some dependencies missing, but you could download all of these as well.
Firstly, if you're downloading bare binaries on an enterprise linux, you're probably doing things in a very bad way. Immediately, you're breaking updates and consistency, and leaving your system in a risky, messy state.
Try using yumdownloader --resolve to get the docker installable and anything it needs.
A better option may be to mirror the installation artifacts, and grab it from the local mirror, but that's beyond the scope if you don't do this already.