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.
Related
I have the latest version of Windows Subsystem for Linux (WSL) installed, but when I run wsl from the command line I get the following error:
An error occurred mounting one of your file systems. Please run ‘dmesg’ for more details.
I hunted down a few possible explanations and one is the possibility that Docker is set as my default wsl. Sure enough, when I run wsl -l -v, the response is:
NAME | STATE | VERSION
* docker-desktop-data | Stopped | 2
docker-desktop | Stopped | 2
To correct this, I am told to change the default from Docker to something else with the command wsl -s distroName where “distroName” should be changed to … something.
So I have two questions:
What should I type instead of “distroName”?
Will Docker Desktop still perform as intended if I do this?
If you're not using WSL for anything other than Docker Desktop, then it really doesn't matter.
But since you attempted to run wsl, it sounds like you may want to try it out. In that case, you should definitely install a WSL distribution that is meant for interactive use.
The docker-desktop and docker-desktop-data distributions aren't really intended to be accessed directly by the user, but one of them will get set as default if you don't have any other distribution installed. There's a proposal to have a way for Docker to set these as "hidden" so that WSL wouldn't automatically set either as default.
What should I type instead of “distroName”?
First, install a user distribution. Which one you choose is up to you, but I typically recommend Ubuntu for first-time installs. When installing WSL on recent Windows releases, it should be the default.
It's installable via the Microsoft Store -- Just find the one that says "Ubuntu" (with no version number). It will install the latest release.
Then, in PowerShell;
wsl --set-default Ubuntu
Will Docker Desktop still perform as intended if I do this?
Absolutely -- It's really an error/corner-case/oversight that docker-desktop-data ever gets set as default anyway, which is why it's nice that the WSL team is considering a method to prevent this.
I have a bootable iso image (live cd) with Linux system that is pretty old. That distro doesn't have remote repo (all installations are done from cdrom and separate disk with packages). I wanted to turn it into a docker image. Reading through articles google gave me, I've found several ways to do that. The first one is to mount the iso and find filesystem.squashfs - only modern distros use that way, not my case. My distro doesn't have that file available. The second approach is to call debootstrap but it requires to specify the repo for the distro with dist directory available in it. My distro doesn't have a public repo. What can I do? Is it even possible? I think that should be possible by doing a lot of things manually but how?
I faced similar problems when I had to containerize an old build server (building natively for legacy systems), eventually I succeeded. This approach describes how to containerize some old Linux distro (kernel 2.6.27 in my case), in the present Linux kernel 5 era.
General steps
if necessary: boot the old OS (or Live CD image)
login to the old system as root (or use sudo)
create a tarball from the relevant folders present in root
cd / ; tar cfvz image.tar.gz --one-file-system --exclude=/var/log --exclude=/image.tar.gz /
the selection worked in my case; review for yourself which folders to include or exclude
transfer the tarball to the Docker host (step not shown here)
and import it:
docker import image.tar.gz
the previous command will print out some hash
if convenient, tag the imported image:
docker tag <import-hash> <your-label>
Legacy problem: unsupported system calls
The imported image contains a Linux distribution snapshot. Some binaries can be executed from Docker, eg.:
docker run --rm <your-label> bin/ls
may actually work.
Some important binaries initially did not work for me, most notably bash:
docker run -it --rm <your-label> bin/bash
was failing silently. (Also, running with strace was possible but gave no clear indication.)
As #hiranchaudhuri pointed out, this is likely due to an API discrepancy between the host's kernel and the container's user space code.
In my case the problem was solved by enabling the legacy vsyscall kernel API
for Windows WSL2, this is described here https://learn.microsoft.com/en-us/windows/wsl/wsl-config
for native Linux systems of today, I guess this can be set in the boot configuration, with the kernel command-line parameter vsyscall=emulate, if the present kernel supports this option
I seriously doubt you will succeed on that.
Be aware Docker is not a full virtualization like KVM or VirtualBox. The lightweight virtualization benefits from the docker containers running on the host's Linux kernel. Which means the kernel is the same inside and outside of the container.
If you now try to install some old distro inside the container you may end up with an incompatible combination. Patching the kernel may involve upgrading glibc, and patching that may involve recompiling the rest of the OS.
I am not sure why you want to stick to the old distro, but seriously I believe you are better off with real virtualization.
Docker hangs when I try to create a docker node
I am trying to set up a docker node as per step 4 of the instructions on docker.com. Unfortunately, Whenever I run the "create" command in the command prompt, the process hangs on
(testNode1) Waiting for host to start...
The instruction set is roughly as follows:
Enable HyperV (done)
Set up external network switch (done)
Reboot (done)
Create nodes (hangs)
The document explicitly states that step 3 is included to prevent exactly this error from happening. However, I have completed that step, and I still encounter this error.
Solutions I have tried
Other sources have suggested that I'm either targeting the wrong network switch, or that the one I've created is not set to "external". I have verified that the switch is set to "external" and that the correct network switch is being targeted, so that does not seem to be the problem.
I have also made sure to restart my machine a few times already, so I doubt another reboot on its own will help.
I also left it running for a day to see if it would eventually resolve itself, but it did not.
Additional details
The command I'm using is:
docker-machine create -d hyperv --hyperv-virtual-switch "VirtualSwitchName" testNode1
I am using Docker version 18.09
I am using Windows 10 Enterprise.
The node is hosted on Hyper-V
Make sure the Docker version is compatible with the Windows version
There are multiple versions of Docker Enterprise. Each successive version has improved functionality, but each version also requires a more up-to-date version of Windows 10.
For example, if you are trying to run Docker 18.09, then you need Windows 10 version 1809 or higher. Docker 18.09 is simply not compatible with earlier versions of Windows 10.
How to check for a compatible Docker version
There is a useful chart here detailing which versions of Docker are compatible with which operating systems. This will tell you what the highest version of Docker is that you can run based on your current OS.
To check your OS version, open your command prompt and type "winver". This will bring up a popup telling you what version of windows you are running (for example, Windows 10, Version 1709). Use this and the above chart to determine if your current version of Docker is compatible with your current OS.
I have been working with LXC containers, the basic tutorials and some networking and it seems to me that its a very straightforward and simple way to create a pure distribution on top of my host.
Current list of templates available does not however list the RHEL x.x distribution. There is CentOS.
I see that Red Hat has supported some efforts in LXC with the libvirt driver, however that shows as deprecated on the site and everything is pointing to their Atomic host which I am experimenting anyways, however, that seems more of a docker way. There might be some variations of docker which ultimately may give me a bare minimum container running a full distro.
I am OK getting more into docker but what I expect at this moment is to run as a simple LXC container with RHEL 6.x distro. Is there no way to run a RHEL LXC container ?
it is indeed unfortunate that redhat plans to discontinue libvirt support for lxc. even within rhel7, so that means rhel6 may be the last version where it will be supported for the lifetime of that release.
as an alternative, there are packages for lxc in epel: https://dl.fedoraproject.org/pub/epel/6/x86_64/repoview/lxc.html
they are even easier to use than libvirt-lxc
as for the template, in either case you should be able to use the centos template with little modification. all the packages are the same and really only the repo sources should point to redhat instead of centos.
I'm new to Docker (just started learning today).
I'm using docker 1.9.1 on MacOSX 10.10.5.
Apparently, there's this new "docker-machine" tool that replaces the deprecated "boot2docker". I'm not really sure what either are, but since docker-machine is so new, there doesn't seem to be a lot out there or people experiencing my specific set of issues.
Anyways, I'm at the point where I believe I created a VM using docker-machine:
docker-machine create -d virtualbox --engine-opt dns=8.8.8.8 my_machine
As far as I understand, I now have two docker virtual machines, the "default" one and a "my_machine".
(I thought Docker was different from vagrant in that it didn't use virtual machines but maybe that's a lesson for another day).
Under ~/.docker/machine/machines, I have both a default/ and my_machine/ folder
When I launch Kitematic (as a MacOSX app), I believe it's launching a view into the "default" virtual machine. The reasons I believe this are because
When I launch the Docker CLI from Kitematic and I echo $DOCKER_MACHINE_NAME in the CLI, it prints "default" as opposed to "my_machine"
Also, when I switch into "my_machine" (by typing eval "$(docker-machine env my_machine)") and create a new docker container (e.g. "docker build -t my_instance"), it doesn't show up in Kitematic.
So question is, how can I get Kitematic to "switch" to my newly created virtual machine.
Sorry, if what I'm saying doesn't make a whole lot of sense. I may not be using the right docker lingo at all. I'm happy to clarify and edit this post as I learn though.
I noticed in a similar post, someone was trying to switch to a different docker-machine from the Docker Quickstart Terminal app. Curious if there's a similar answer for switching the Kitematic app