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.
Related
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.
I am trying to execute the test network on hyperledger Fabric.
I have installed the following prerequisites:
curl version 7.68.0
docker version 20.10.12
docker-compose version 1.25.0
go version 1.13.8
node version 10.19.0
npm version 6.14.4
python version (3.8.10 and 2.7.18)
I'm using Ubuntu 20.04.
In the folder fabric-sample/test-network: I run
./network.sh down
and then ./network.sh up
then I tested
docker ps-a
It shows 2 fabric-peers and one orderer.
Now I'm trying to create a channel with ./network.sh createChannel but I got this error how to solve it??
Error: Post "https://localhost:7053/participation/v1/channels": EOF Channel creation failed
Make sure you having the same version of fabric docker images, fabric binaries and fabric samples. Checkout to specific tags in fabric samples repo if required. Latest version of fabric works with the main branch of samples.
I have downloaded the latest fabric version which is 2.2.0 using the following command from hyperledger documentation website
curl -sSL https://raw.githubusercontent.com/hyperledger/fabric/master/scripts/bootstrap.sh | bash -s
But when it comes to run a test network using its network.sh file using the following command as directed by the hyperledger documentation website
./network.sh up
I get the following error
Starting nodes with CLI timeout of '5' tries and CLI delay of '3' seconds and using database 'leveldb' with crypto from 'cryptogen'
2020-08-26 05:55:40.852 UTC [main] main -> INFO 001 Exiting.....
LOCAL_VERSION=2.2.0
DOCKER_IMAGE_VERSION=1.1.0
=================== WARNING ===================
Local fabric binaries and docker images are
out of sync. This may cause problems.
===============================================
ERROR! Fabric Docker image version of 1.1.0 does not match the versions supported by the test network.
and the screenshot is following:
I want docker image version which is 1.1.0 to be same or align with local fabric version which is 2.2.0. I saw previous stackoverflow questions but they asked to downgrade local fabric version from 2.2.0 to 1.1.0 and that solved the problem but I want to work on newest hyperledger fabric version which is 2.2.0. So I want to know how to upgrade docker image version from 1.1.0 to 2.2.0 so that it can work with local fabric.
Use network.sh --help command to check how to use various options available with it.
Below is the snippet from ./network.sh --help
-i <imagetag> - the tag to be used to launch the network (defaults to "latest")
Use network.sh up -i 2.2 to run docker on v2.2 images.
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.
EDIT: A huge thank you #mattmoor for helping me debug the issue. After I had to create a new docker-machine. There was a problem with the docker daemon that must've arisen due to the first machine not being created correctly.
I am having trouble pulling images from another computer, both of which are running OSX Yosemite. Both machines have the docker daemon running, and have successfully authenticated with the desired project to pull from with
gcloud auth login
On my computer I am able to run:
gcloud docker pull gcr.io/projectid/image-tag without any issues.
However when I try to repeat this on another machine, I get a large error message that begins with:
Error pulling image (tag-here) from gcr.io/projectid/image-tag, endpoint: https://gcr.io/v1/, Untar exit status 2 unexpected fault address 0xc208ce5d04
fatal error: faultr downloading dependent layers
[signal 0xb code=0x1 addr=0xc208ce5d04 pc=0x94109e]
Followed by a goroutine 1 stack trace.
The docker version on both machines is 1.6.2, the client and server api version is 1.18, both Go versions are go1.4.2
The Google Cloud SDK version on both machines is 0.9.67, and both have the following components installed:
bq 2.0.18
bq-nix 2.0.18
core 2015.06.30
core-nix 2015.06.02
gcloud 2015.06.30
gcutil-msg 2015.06.09
gsutil 4.13
gsutil-nix 4.12
preview 2015.06.30
and the machine that works also has these extra components installed:
alpha 2015.06.30
beta 2015.06.30
kubectl
kubectl-darwin-x86_64 0.18.1
Any help would be greatly appreciated, I'm truly baffled as to why I can't pull from the gcr registry on the other machine.
I'm baffled too, this looks like Docker dying trying to untar the blob, and I haven't seen that before.
Would you mind starting a thread with gcr-contact#google.com, as this may take a little debugging, and email will be a bit easier for the back-and-forth.
We can update this with what we find, if that works for you?