I have a local setup of three raspberry pi's and followed the tutorial on here.
I managed to get my microk8s cluster running. Next I wanted to deploy Jenkins.
Whenever I execute the first command:
kubectl create -f jenkins-deployment.yaml -n jenkins
I get the following error:
standard_init_linux.go:219: exec user process caused: exec format error
Some other searches suggest installing docker. However in the tutorial there is nothing about installing docker. Any ideas what is happening here?
Docker vs. containerd
Regarding your suggestion about the docker.
From Version 1.14.0 of MicroK8s (released 25 March 2019) containerd replaced dockerd.
Starting from version 1.14.0 containerd automatically ships with MicroK8S installation So, you don't need dockerd as CRI.
Below you can find modules MicroK8S set up during installation:
The following systemd services will be running in your system:
snap.microk8s.daemon-apiserver, is the kube-apiserver daemon started using the arguments in ${SNAP_DATA}/args/kube-apiserver
snap.microk8s.daemon-controller-manager, is the kube-controller-manager daemon started using the arguments in ${SNAP_DATA}/args/kube-controller-manager
snap.microk8s.daemon-scheduler, is the kube-scheduler daemon started using the arguments in ${SNAP_DATA}/args/kube-scheduler
snap.microk8s.daemon-kubelet, is the kubelet daemon started using the arguments in ${SNAP_DATA}/args/kubelet
snap.microk8s.daemon-proxy, is the kube-proxy daemon started using the arguments in ${SNAP_DATA}/args/kube-proxy
snap.microk8s.daemon-containerd, is the containerd daemon started using the configuration in ${SNAP_DATA}/args/containerd and ${SNAP_DATA}/args/containerd-template.toml.
snap.microk8s.daemon-etcd, is the etcd daemon started using the arguments in ${SNAP_DATA}/args/etcd
ARM architecture
Next, Raspberry Pi and, as mentioned previously by community, ARM.
You can not use regular amd64-based images for ARM architecture.
Possible solutions
To solve a problem, I recommend you 2 options below.
Use already prepared ARM-based image of Jenkins for ARM architecture. Also you can search images for Raspberry Pi with filters. Just select which architecture you would like to use: ARM, ARM64, etc.
Some images have been ported for other architectures, and many of these are officially supported (to various degrees).
ARMv6 32-bit (arm32v6): https://hub.docker.com/u/arm32v6/
ARMv7 32-bit (arm32v7): https://hub.docker.com/u/arm32v7/
ARMv8 64-bit (arm64v8): https://hub.docker.com/u/arm64v8/
Prepare your own image for ARM using buildx
References:
Multi-arch build and images, the simple way
Cross building ARM images on Docker Desktop
Related
my environment :
MacOS M1 chip
VSCode version 1.66.2 arm64
local installed docker version : 20.10.22
I have situations that docker is not working in VSCode.
I already installed docker in local. But when I'm trying to connect docker in VSCode, repeatedly asking install docker extensions. (but I do have docker already ). and if I do reinstall with following the VSCode, the docker version was broken (changed to intel chip docker).
Does anybody know what's wrong?
Docker Extensions for VS Code have nothing to do with the Docker engine itself. They are like an additional layer of tools and commands over the installed Docker. E.g. they provide IntelliSense for editing Docker-related files, you can run Docker commands from F1 drop-down, etc. But you should be able to do all the required tasks even without Docker Extensions, e.g. from the Terminal in VS Code, but for this the path to Docker CLI (command line interface) should be added to PATH environment variable.
If you are getting failed to connect error then maybe Docker engine is not running. Please refer to https://docs.docker.com/desktop/install/mac-install/ and https://docs.docker.com/desktop/troubleshoot/overview/ about how to check if the engine is running and how to troubleshoot the issues.
If that doesn't help, please provide some specific error and steps, which led to it, then we'll try to find out.
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.
While attempting to install, in VS Code, the Fabric samples and binaries through the curl command :
I've encountered the following error, as soon as Fabric docker images are pulled :
The command 'docker' could not be found in this WSL1 distro. We recommend to convert this distro into
WSL 2 and activate the WSL integration in Docker Desktop settings.
N.B: Docker version 20.10.0-beta1
Thus any relevant feedback, not impacting the usage of the IBM Blockchain Platform v.1.0.39 (e.g. prerequisites installed), would highly be appreciated.
Best
See the Docker Desktop WSL 2 backend guide.
Specifically, you need to convert your Ubuntu distribution to WSL2 (it is currently WSL1). To do so, see Step 6 in the Install section:
To upgrade your existing Linux distro to v2, run:
wsl.exe --set-version Ubuntu 2
Either that, or create a new WSL instance by backing up the WSL1 version (wsl --export) and then importing it into a new copy (wsl --import). See wsl --help for the parameters needed.
Then proceed with the rest of the Docker installation instructions.
in my case, resolved by enabling the WSL2 distro option in the docker settings.
As the log says (in your qusetion)
We recommend to convert this distro into WSL 2 and activate the WSL integration in Docker Desktop settings.
in Docker Settings
go Resources
go WSL INTEGRATION
check Enable integration with my default WSL distro
Apply & Restart
I faced the same issue and solved it by navigating to: docker desktop > Resources > wsl integration then choose the right distro for integrating docker with.
I am very new to docker. I have installed docker desktop on my mac. When i execute docker version it is showing OS/Arch:linux/amd64 under server docker engine. I am assuming this means that docker installed linux kernel on top of my mac OS using hypervisor to manage linux based containers. if this linux kernel got updated, will it going break the functionalities of existing images?
Why am I asking this question?
Recently after updating my mac OS to 10.15.2, things started breaking because of openssl and ruby-2.3.x compatibility issues. And I was told, we could solve these type of issues using docker since it is independent of host OS?
But docker itself has own linux kernel, Will i be going to face this issue if linux kernel got updated?
Thanks in advance
You got those errors because you were depending software libraries available on the machine. They are not related to kernel. Any such software dependencies should be bundled with the docker image. Linux kernel upgrades never break user space.
I installed Docker on a Red Hat Enterprise Linux Server 7.5 (Maipo) system:
docker version
Version: 1.13.1
API version: 1.26
Package version: docker-1.13.1-58.git87f2fab.e17.x86_64
OS/Arch: linux/amd64
Now if I try to run a docker image, I get errors similar to this:
docker run docker.io/jupyter/datascience-notebook
tini: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
I have searched for help and have already taken a multitude of possible actions:
libraries seem to be linked correctly
all libraries are up to date
Hello-World example works
I also came across information saying that running containers from docker.io / hub.docker.com under RHEL is not supported - which I don't really get, as main purpose of docker is to enable running programs independent from their OS...?
https://access.redhat.com/solutions/1408853 Does this mean using docker under RHEL does not really provide me with the possibility of easily deploying/sharing a docker-image with non-RHEL users?
Also, does this mean I can only access and use official RHEL-docker images?
https://access.redhat.com/containers/?start=90#/search/
As I wanted to use docker to have ready-to-go environments with R-Python/Jupyter/H2o (and similar), I'm disappointed because I could not find suitable images for RHEL there.
So, my questions would be:
Is it possible to run docker.io / hub.docker.com images under RHEL7.5?
if not, could I share my own created docker images under RHEL7.5 to other users with different OS versions?
Are there other projects / sites to share docker-images for data science purposes on RHEL?
Would you agree that my next step would be: building my own docker-image, adding R/Python/jupyter step by step?
Best regards,
workah0lic
This error message
tini: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
comes from within the container image. It could be a corrupted container image, but the message is also printed when the glibc dynamic linker determines that the kernel features are not sufficient for loading libc.so.6. I looked at the image (digest is sha256:79f929bd0e58fa9cb238dceda48b0c8360e748d09b476b429216c93dac0bd783), and it appears to require kernel 3.2, so the Red Hat Enterprise Linux 7 kernel version of 3.10 should be sufficient.
In fact, I cannot reproduce this problem with kernel-3.10.0-862.6.3.el7.x86_64 and docker-1.13.1-58.git87f2fab.el7.x86_64. You could try to run this command to obtain additional information about dynamic linker behavior:
docker run -e LD_DEBUG=all docker.io/jupyter/datascience-notebook