Good, now the alpine Linux puzzle on the macOS was solved that time.
Docker for mac software#
So it meant that to solve the cgroups and namespaces puzzle on the macOS in the "native" way, the docker guys used the xhyve (derived from bhyve) and the native macOS Hypervisor framework, bravo another example of the elegance and power of the free open source software \m/. So what is the bhyve then, answer comes from its official page " bhyve, pronounced beehive is a hypervisor/virtual machine manager for FreeBSD that supports most Intel and AMD processors that report the POPCNT (POPulation Count) processor feature in dmesg(8)".
It is built on top of amework in OS X 10.10 Yosemite and higher, runs entirely in user-space, and has no other dependencies". As per the xhyve GitHub page " The xhyve hypervisor is a port of bhyve to OS X. Now came in the picture two hyves xhyve and bhyve. So naturally being a restless explorer, the burning desire that time was to explore how this whole alpine based Linux VM business was being carried out by the docker? Ooh, that meant if there was no bug in the docker then we were still running in an alpine Linux based VM even in the case of Docker for Mac. To my surprise, this info also indicated that the docker is running on alpine Linux OS with 2GB of memory.
Docker for mac for mac#
Yes, there is no typo in the previous line and it was the same reaction from me running docker natively on macOS and alpine Linux messages were emitted, come on! It was 16GB MBP and there was tonnes of RAM already available, so first lazy thoughts were "was it some bug in docker for mac which indicates alpine Linux" or some Linux kinds of "logical assumptions" about the "so called native" way the docker runs on macOS? Next step done was to dump from docker info command and filtering for OS Name/Type, Kernel Version, CPU's, Total Memory etc. One fine day while running 50-100 containers for testing the scaling limits for docker, there was an interesting failures scenario where containers couldn't be created and the errors indicated that alpine Linux ran out of memory while creating containers. Ok, after some brief general background about docker and non-Linux OSes, now here is the interesting story which prompted me to look deeper into how Docker for Mac was achieving its containerization goals. So the new solution introduced for the macOS was Docker for Mac which was a "so called native" way to run docker on non-Linux XNU kernel. The docker folks started working on a more native solution for macOS after boot2docker started getting popular and widely used. A complete tooling to run docker on macOS for me was boot2docker which was a lightweight Linux distribution based on Tiny Core Linux made specifically to run Docker containers. The first way to run docker on the non-Linux OSes was to use virtual machine(s) running some GNU/Linux distribution and then doing the whole container business within those VM(s). It means that these Linux kernel features were required on other operating systems too in case the docker had to be true Build Once, Run Anywhere solution which it promised to be.
So technically speaking, now the Linux Kernel works like hypervisor to create isolated and self-contained user space instances encapsulating applications and their libraries dependencies. It has its roots in Linux kernel features cgroups and namespaces which provide Resources allocation control and Isolation in the user space, respectively. This article was overdue but its better late then never :-).ĭocker is one of the most groundbreaking technologies/frameworks released in last few years. So here is the tell all when tried to join various pieces that time. I explored something interesting about Docker for Mac while using it first time last year.
0 kommentar(er)
