Our shell thinks its PID is 1?! What’s more, we can’t see the host’s process tree anymore. Root 2 0.0 0.0 17504 2096 ? R+ 22:34 0:00 ps created a new process namespace, poking around our chroot we’ll notice something a bit funny. USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND $ sudo unshare -p -f -mount-proc=$PWD/rootfs/proc \ In this case, we’ll create a PID namespace for the shell, then execute the chroot like the last example. The unshare command line tool gives us a nice wrapper around this syscall and lets us setup namespaces manually. Namespaces allow us to create restricted views of systems like the process tree, network interfaces, and mounts.Ĭreating namespace is super easy, just a single syscall with one argument, unshare. This is where we get to talk about namespaces. Root 24764 0.0 0.0 11132 948 ? S+ 22:29 0:00 grep topīetter yet, our chrooted shell is running as root, so it has no problem killing the top process. Sure enough, we can see the top invocation from inside the chroot. How isolated is this chrooted process? Let’s run a command on the host in another terminal. If you’re following along at home, you’ll be able to view everything the file server can see at Creating namespaces with unshare $ sudo chroot rootfs python -m SimpleHTTPServer Speaking of applications, instead of shell we can run one in our chroot. That interpreter depends on shared libraries and device files that have been intentionally included in the archive. When we execute the Python interpreter, we’re executing rootfs/usr/bin/python, not the host’s Python. Hello, container worth noting that this works because of all the things baked into the tarball. $ sudo chroot rootfs ls /īoot etc lib media opt root sbin sys which /usr/bin/python -c 'print "Hello, container world!"' Once we’re in there we can poke around, run commands, and do typical shell things. In this case, we’ll restrict our process to the “rootfs” directory then exec a shell. A thin wrapper around the similarly named syscall, it allows us to restrict a process' view of the file system. The first tool we’ll be working with is chroot. For an overview, I’d strongly recommend the excellent talk “Minimal Containers” by my coworker Brian Redbeard. There’s a bin directory with executables, an etc with system configuration, a lib with shared libraries, and so on.Īctually building this tarball is an interesting topic, but one we’ll be glossing over here. The resulting directory looks an awful lot like a Linux system. $ # tar needs sudo to create /dev files and setup file ownershipīin dev home lib64 mnt proc run srv tmp var The tarball holds something that looks like a Debian file system and will be our playground for isolating processes. The least magic part of a container are the files you interact with.įor this post I’ve build a simple tarball by stripping down a Docker image. So, let’s have a little fun and use those underlying technologies to build our own containers.Ĭontainer images, the thing you download from the internet, are literally just tarballs (or tarballs in tarballs if you’re fancy). That isolation leverages several underlying technologies built into the Linux kernel: namespaces, cgroups, chroots and lots of terms you’ve probably heard before. Often thought of as cheap VMs, containers are just isolated groups of processes running on a single host. The talk started with the self-imposed challenge “give an intro to containers without Docker or rkt." This is write up for talk I gave at CAT BarCamp, an awesome unconference at Portland State University.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |