What’s actually happening is that Docker for Mac is spinning up a virtual machine. You can clearly see that the kernel isn’t the same. Well, that’s not what we were looking for. > docker run -rm -entrypoint="uname" alpine -a When running Docker on macOS, if we try to look up the kernel, we get the following: > uname -aĭarwin myhost 17.6.0 Darwin Kernel Version 17.6.0: Tue May 8 15:22: root:xnu-4570.61.1~1/RELEASE_X86_64 x86_64 You can actually ping this IP address or reach the open port (172.17.0.2:80) in your web browser without having to do any port forwarding. This device has the same MAC address as the one assigned to the Docker container, as well as the same IP address. When you look at your network interfaces, you’ll see your normal loopback and ethernet, but you’ll also notice a veth device that wasn’t there before. I stripped out a lot of extraneous information but kept in the important bits. Link/ether f2:b3:ec:e8:43:4a brd ff:ff:ff:ff:ff:ff link-netnsid 0 "SandboxKey": "/var/run/docker/netns/adf503ce4580",Ģ0: mtu 1500 qdisc noqueue master docker0 state UP group default Let’s also take a look at the network stack. But it still shows us that the kernel that your application thinks its running on is actually the kernel of the host machine. The second line is just a weird quirk of the entrypoint option (read more here). $ docker run -rm -entrypoint="uname" alpine -a You can prove this by running the following: $ uname -a Natively, Docker runs on Linux, taking advantage of direct access of the host Linux kernel. Before I start delving further into Docker tutorials, I feel that I should go over the differences between Docker running natively on Linux versus running Docker on virtual machines on Mac and Windows.
0 kommentar(er)
