i run the following command to deploy a new cluster:
docker run --net=host -t -e LICENSE=accept -v "$(pwd)":/installer/cluster ibmcom/icp-inception:2.1.0.2-ee install
and i get this response:
Unable to find image 'ibmcom/icp-inception:2.1.0.2-ee' locally
docker: Error response from daemon: manifest for ibmcom/icp-inception:2.1.0.2-ee not found.
See 'docker run --help'.
This happened about a couple of weeks ago, and when i did nothing other than wait a few days and tried again, the command worked. It is as if the tag, 2.1.0.2-ee is not accessible. indeed, when i go to docker hub, i don't see that tag listed. But then i'm a newbie with docker hub so I'm not sure if i'm interpreting this correctly.
is it me, or is ee not available to all? i could do a docker pull with ce, no problem.
Thanks
It isn't you! ibmcom/icp-inception:2.1.0.2-ee points to the paid-for version of IBM Cloud Private and is not distributed through DockerHub. We distribute our community edition, ibmcom/icp-inception:2.1.0.2-ce, (which is free to use) via DockerHub, which is why you are not having any issues with ce.
The only difference you will find between Community Edition and Enterprise Edition is that multi-master deployments and production are not enabled in Community Edition.
Let me know if you have any further questions.
Thanks everyone on slack and stack overflow.
My mistake was that the snapshot that i took just prior to deploying the cluster successfully was not what i thought.
i think i must have checkpointed prior to loading ee into docker rather than just before running icp-inception.
It makes sense that icp ee is not publicly downloadable.
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 watching a course on Hyperledger Composer development online. I installed all the required prerequisites, docker, docker-compose, nodejs, golang. After cloning the fabric-samples repository from github. There is a file called byfn.sh inside a folder called first-network. On running the command ./byfn.sh up, it's giving the following error:
If, someone has experience working on it, please help. Any help would be appreciated. Thank you.
I think the first thing you should do is stop looking at or trying to use Hyperledger Composer. It is end of life now and some of it's components will have problems even if you install the exact required versions (for example the rest server fails to launch now on node 8 but changing to a newer version of node may break other parts of Composer).
As you had planned to use it with hyperledger fabric I would suggest that you just invest your time in Hyperledger fabric, see https://hyperledger-fabric.readthedocs.io/en/latest/
Regarding your problem with docker, I suspect you tried to install docker through the apt command in your wsl window ? I'm guessing that you are using WSL2, but if you are using WSL1 then docker will never work in a WSL1 environment. If it was WSL2 then the docker daemon doesn't automatically start in that environment you need to start it yourself first. I think the command is service docker start. The important thing here is to make sure you are using WSL2 and not WSL1 (see hyperledger fabric link later which provides guidance on making sure you are using WSL2).
An alternative to installing docker into WSL2 directly would be to install Docker Desktop for Windows and follow the hyperledger fabric instructions here https://hyperledger-fabric.readthedocs.io/en/latest/prereqs.html#wsl2
This is the question regarding running Docker from within WSL, without Docker Desktop. It is doable for WSL2, so the focus of this question is on WSL1 specifically. Of my researches,
Some says "the Docker daemon cannot run directly on WSL", while
Another article says Docker can be run "seamlessly in Windows Subsystem Linux", with the help of Docker Community Edition 17.09.0, as "A crucial change was made to the WSL kernel that enables the usage of cgroups which Docker needs to manage your system’s resources into containers."
My docker is 20.10.5 under debian bullseye. Would it be still good?
I tried it, and got:
iptables can't initialize iptables table `nat': Table does not exist
and the answer to Iptables v1.6.1 can't initialize iptables table `filter' Ubuntu 18.04 Bash Windows is that,
According to the Microsoft WSL page on github.com, iptables isn't supported.
https://github.com/Microsoft/WSL/issues/767
But that's more than 4 years ago, and since it has been possible later in year 2019, I'm wondering what the latest status is.
WSL1 - The little engine that could (link included since that reference may only be understood by a limited audience).
Unfortunately, in the case of Docker, the WSL1 engine seems to have run out of steam. In reading that blog post that you reference, and the corresponding Github thread, I'm pretty amazed at just how far along folks did get with running Docker. I had never seen that before.
However, if you read the full comments on the Github thread, it appears that the results were fairly limited. Placing these excerpts in order:
[2018-04-23] I'm glad to say Docker daemon finally runs on WSL. I'm testing on build 17134. ... The last docker-ce version that works right now on build 17134 is 17.09.0. Anything after that fails on extracting the docker images.
Note that it had to (and still has to) be run in a WSL1 instance running as a Windows admin.
[2018-0612] Unfortunately, docker-compose still doesn't work.... There is a problem with iptables which is not fully supported via WSL yet.
(Which you've run into, although I didn't see that. Perhaps the "admin" thing?)
[2018-07-09] Yeah, I recently mentioned it on Twitter and got a major "we aren't supporting this, we highly advise against it" message from our former WSL PM.
[2018-11-13] WSL PM here. As mentioned in the above comment, we have improved Docker support in recent builds of WSL. Most (if not all) versions of docker-ce work with WSL. We're working on a large set of changes for WSL currently. As part of those changes, we are looking at adding native Docker support in WSL. I will add to this thread and other issues on Docker support when I have additional updates to share
It doesn't seem like this ever progressed, since the PM never posted again in the thread, at least.
[2019-04-18] Like others have pointed out, running docker 17.09 works. Anything later fails with different errors. It might be that newer docker versions are using other syscalls not yet implemented by WSL.
There are some other messages scattered in here about running with --network host (for the client) or --iptables=false (for the daemon).
[2019-08-04] Windows Insider Fast Ring build (>=18917) via WSL2, latest docker/docker-compose is running native in WSL Linux.
And in late 2020, the thread died off.
In a test WSL1 Ubuntu 20.04 instance, I was able to get hello-world running, but nothing more. Running a busybox or ubuntu image (with or without an interactive terminal) failed with:
Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: waiting for init preliminary setup: EOF: unknown.
Once the focused shifted to WSL2 and the real kernel, it doesn't appear to me that the WSL team has made any more progress advancing WSL1's pseudo-kernel syscall translation layer.
So we downloaded this docker image that we need to run on the machines of me and a friend. I am on a mac and he is on a linux box. We are not techie people so please forgive this naive question :)
When running the docker using docker build -t app-name/site.com . we were running into some very cryptic G++ errors which sent us on a wild goose chase and a vicious circle of googling and debugging. In the end we figured out that my friend's machine was Linux 18.04, but in the Dockerfile it said FROM ubuntu:16.04. So when we updated this to FROM ubuntu:18.04 his docker build was successful and he was able to launch the app.
So now we are trying to figure out how to get this running in my mac. Does anyone know what update we should do to this line to get it running in mac? I am running macOS Catalina.
Any help is much appreciated!
Docker is originally developed for Linux community. Then it is ok for Mac.
Here is one example of how to make your mac get a Linux container. Run this
docker pull ubuntu
This means you are able to construct a Ubuntu env on your mac machine.
FYI, you can release your docker image on docker's website then fetch it on your mac.
Refer to: https://ropenscilabs.github.io/r-docker-tutorial/04-Dockerhub.html
I am trying to run some tests in Travis CI using Docker (and docker-compose).
A search on "run docker in Travis" does yield several how-to-do results, but none of these seem to be running remotely on Travis CI (travis-ci.com), instead I assume are on local Travis.
The answers to the closest question I found, Can travis-ci run docker? , have not helped me so far.
The problem I encounter is that Travis CI runs Ubuntu 12.04 on an outdated kernel and installing Docker requires updating the kernel and rebooting - but 'sudo reboot' will cause the virtual machine to be destroyed and leads to an infinite cycle of [install kernel -> reboot -> install_kernel ...]
Just wanted to drop in a quick note that Docker support for Travis CI is now official: http://blog.travis-ci.com/2015-08-19-using-docker-on-travis-ci/
It's support Docker and Docker-compose.
https://github.com/moul/travis-docker claims support for Docker in Travis. It apparently uses User Mode Linux to achieve this. I haven't tried this yet.
I know it does not help you with travis-ci but I build my docker image on circle-ci. Also Circle-CI just upgraded to docker 1.6.2.
My build file can be found here:
https://github.com/blacklabelops/jenkins/blob/master/circle.yml