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.
Related
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.
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.
The one listed on https://hub.docker.com/_/tomcat is based on debian. Where can I get a rhel based image? Or is there a way I can create it by myself.
I am currently working on rhel 7.6 and have docker installed on my machine?
You have to build it yourself because RHEL is proprietary and therefore underrepresented in docker hub. You could go for a centos version though, which is almost identical.
Note: RHEL would be considered an extremely unusual choice for a container OS. Are you sure you're doing the right thing? If this is a rule given to you by your employer then it's wrong and you should go fix that instead -- it'll be easier than trying to build rhel containers.
You could take a look at this as a starting point for ideas on how to build it yourself: https://github.com/sclorg/rhscl-dockerfiles/blob/master/centos7.python27/Dockerfile.rhel7
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.
We are currently running Red Hat 5. But I saw documentation that says docker is only supported on Red Hat 7. So we have to upgrade to Red Hat 7 or we can't use docker at all on RHEL 5? Alternatively we can consider to switch to Ubuntu.
How do others solve the similar issue?
You will need to upgrade from RHEL5 to use Docker.
The official Docker release deprecated RHEL6 support from 1.7 (and inadvertently broke it in 1.7.0 but fixed in 1.7.1). Support for RHEL6 was dropped in Docker 1.8. Since then, a RHEL7 based distro with a 3.10+ kernel has been required.
There is a docker-io-1.7.1-2 package available on EPEL for RHEL6.5+ based distros. RHEL6 runs an older 2.6 kernel with back ported fixes so docker can work. This kernel must be at 2.6.32-431 or higher.
RHEL doesn't support AUFS which is the most commonly used Docker storage driver. By default RHEL uses a loopback storage driver which is not production ready. The EPEL packages provide docker-storage-setup to setup thin provisioned LVM. You need to do this setup manually if you want to run the docker.com packages.
Personally I would recommend going with a recent debian based distribution running the official docker packages for timely updates. If you are on EC2, Amazons AMI will do nicely though.