Article Category:#Code
Docker - Overview. Docker is a container management service. The keywords of Docker are develop, ship and run anywhere. The whole idea of Docker is for developers to easily develop applications, ship them into containers which can then be deployed anywhere. There are differences between nsenter and docker exec; namely, nsenter doesn't enter the cgroups, and therefore evades resource limitations. The potential benefit of this would be debugging and external audit, but for remote access, docker exec is the current recommended approach.
Posted on
.Updates
Hello. How are you? Thanks for stopping by.
It used to be tricky to get Docker working on OS X, which is why I wrote this here blog post. With the release of Docker 1.8, it just got way easier. Now there's a new thing, Docker Toolbox, that makes it super easy. You should install that instead of reading this post. Or you can read it if you want, I think it's a pretty good blog post and you'll learn some stuff. No pressure, though.
Have you heard of Docker? You probably have—everybody’s talking about it. It’s the new hotness. Even my dad’s like, “what’s Docker? I saw someone twitter about it on the Facebook. You should call your mom.”
Docker is a program that makes running and managing containers super easy. It has the potential to change all aspects of server-side applications, from development and testing to deployment and scaling. It’s pretty cool.
Recently, I’ve been working through The Docker Book. It’s a top notch book and I highly recommend it, but I’ve had some problems running the examples on OS X. After a certain point, the book assumes you’re using Linux and skips some of the extra configuration required to make the examples work on OS X. This isn’t the book’s fault; rather, it speaks to underlying issues with how Docker works on OS X.
This post is a walkthrough of the issues you’ll face running Docker on OS X and the workarounds to deal with them. It’s not meant to be a tutorial on Docker itself, but I encourage you to follow along and type in all the commands. You’ll get a better understanding of how Docker works in general and on OS X specifically. Plus, if you decide to dig deeper into Docker on your Mac, you’ll be saved hours of troubleshooting. Don’t say I never gave you nothing.
First, let’s talk about how Docker works and why running it on OS X no work so good.
How Docker Works
Docker is a client-server application. The Docker server is a daemon that does all the heavy lifting: building and downloading images, starting and stopping containers, and the like. It exposes a REST API for remote management.
The Docker client is a command line program that communicates with the Docker server using the REST API. You will interact with Docker by using the client to send commands to the server.
The machine running the Docker server is called the Docker host. The host can be any machine—your laptop, a server in the Cloud™, etc—but, because Docker uses features only available to Linux, that machine must be running Linux (more specifically, the Linux kernel).
Docker on Linux
Suppose we want to run containers directly on our Linux laptop. Here’s how it looks:
Docking on Linux
The laptop is running both the client and the server, thus making it the Docker host. Easy.
Docker on OS X
Here’s the thing about OS X: it’s not Linux. It doesn’t have the kernel features required to run Docker containers natively. We still need to have Linux running somewhere.
Enter boot2docker. boot2docker is a “lightweight Linux distribution made specifically to run Docker containers.” Spoiler alert: you’re going to run it in a VM on your Mac.
Here’s a diagram of how we’ll use boot2docker:
Docking on OS X
We’ll run the Docker client natively on OS X, but the Docker server will run inside our boot2docker VM. This also means boot2docker, not OS X, is the Docker host, not OS X.
Make sense? Let’s install dat software.
Installation
Step 1: Install VirtualBox
Go here and do it. You don’t need my help with that.
Step 2: Install Docker and boot2docker
You have two choices: the offical package from the Docker site or homebrew. I prefer homebrew because I like to manage my environment from the command line. The choice is yours.
Step 3: Initialize and start boot2docker
First, we need to initialize boot2docker (we only have to do this once):
Next, we can start up the VM. Do like it says:
Step 4: Set the DOCKER_HOST environment variable
The Docker client assumes the Docker host is the current machine. We need to tell it to use our boot2docker VM by setting the DOCKER_HOST environment variable:
☞Your VM might have a different IP address—use whatever boot2docker up told you to use. You probably want to add that environment variable to your shell config.
Step 5: Profit
Let’s test it out:
Great success. To recap: we’ve set up a VirtualBox VM running boot2docker. The VM runs the Docker server, and we’re communicating with it using the Docker client on OS X.
Bueno. Let’s do some containers.
Common Problems
We have a “working” Docker installation. Let’s see where it falls apart and how we can fix it.
Problem #1: Port Forwarding
The Problem: Docker forwards ports from the container to the host, which is boot2docker, not OS X.
Let’s start a container running nginx:
This command starts a new container as a daemon (-d), automatically forwards the ports specified in the image (-P), gives it the name ‘web’ (--name web), and uses the nginx image. Our new container has the unique identifier 0092c03e1eba....
Verify the container is running:
Under the PORTS heading, we can see our container exposes port 80, and Docker has forwarded this port from the container to a random port, 49153, on the host.
Let’s curl our new site:
It didn’t work. Why?
Remember, Docker is mapping port 80 to port 49153 on the Docker host. If we were on Linux, our Docker host would be localhost, but we aren’t, so it’s not. It’s our VM.
The Solution: Use the VM’s IP address.
boot2docker comes with a command to get the IP address of the VM:
Let’s plug that into our curl command:
Success! Sort of. We got the web page, but we got The VM’s Host only interface IP address is:, too. What’s the deal with that nonsense.
Turns out, boot2docker ip outputs the IP address to standard output and The VM's Host only interface IP address is: to standard error. The $(boot2docker ip) subcommand captures standard output but not standard error, which still goes to the terminal. Scumbag boot2docker.
This is annoying. I am annoyed. Here’s a bash function to fix it:
Stick that in your shell config, then use it like so:
Groovy. This gives us a reference for the IP address in the terminal, but it would be nice to have something similar for other apps, like the browser. Let’s add a dockerhost entry to the /etc/hosts file:
Now we can use it everywhere:
Great success. Make sure to stop and remove the container before continuing:
☞VirtualBox assigns IP addresses using DHCP, meaning the IP address could change. If you’re only using one VM, it should always get the same IP, but if you’re VMing on the reg, it could change. Fair warning.
Bonus Alternate Solution: Forward all of Docker’s ports from the VM to localhost.
If you really want to access your Docker containers via localhost, you can forward all of the ports in Docker’s port range from the VM to localhost. Here’s a bash script, taken from here, to do that:
By doing this, Docker will forward port 80 to, say, port 49153 on the VM, and VirtualBox will forward port 49153 from the VM to localhost. Soon, inception. You should really just use the VM’s IP address mmkay.
Problem #2: Mounting Volumes
The Problem: Docker mounts volumes from the boot2docker VM, not from OS X.
Docker supports volumes: you can mount a directory from the host into your container. Volumes are one way to give your container access to resources in the outside world. For example, we could start an nginx container that serves files from the host using a volume. Let’s try it out.
First, let’s create a new directory and add an index.html:
(Make sure to replace /Users/Chris with your own path).
Next, we’ll start another nginx container, this time mounting our new directory inside the container at nginx’s web root:
We need the port number for port 80 on our container:
Let’s try to curl our new page:
Well, that didn’t work. The problem, again, is our VM. Docker is trying to mount /Users/Chris/web from the host into our container, but the host is boot2docker, not OS X. boot2docker doesn’t know anything about files on OS X.
The Solution: Mount OS X’s /Users directory into the VM.
By mounting /Users into our VM, boot2docker gains a /Users volume that points to the same directory on OS X. Referencing /Users/Chris/web inside boot2docker now points directly to /Users/Chris/web on OS X, and we can mount any path starting with /Users into our container. Pretty neat.
boot2docker doesn’t support the VirtualBox Guest Additions that allow us to make this work. Fortunately, a very smart person has solved this problem for us with a custom build of boot2docker containing the Guest Additions and the configuration to make this all work. We just have to install it.
First, let’s remove the web container and shut down our VM:
Next, we’ll download the custom build:
Finally, we share the /Users directory with our VM and start it up again:
☞Replacing the boot2docker image won’t erase any of the data in your VM, so don’t worry about losing any of your containers. Good guy boot2docker.
Let’s try this again:
Great success! Let’s verify that we’re using a volume by creating a new file on OS X and seeing if nginx serves it up:
Sweet damn. Make sure to stop and remove the container:
☞If you update index.html and curl it, you won’t see your changes. This is because nginx ships with sendfile turned on, which doesn’t play well with VirtualBox. The solution is simple—turn off sendfile in the nginx config file—but outside the scope of this post.
Problem #3: Getting Inside a Container
The Problem: How do I get in there?
So you’ve got your shiny new container running. The ports are forwarding and the volumes are ... voluming. Everything’s cool, until you realize something’s totally uncool. You’d really like to start a shell in there and poke around.
The Solution: Linux Magic
Enter nsenter. nsenter is a program that allows you to run commands inside a kernel namespace. Since a container is just a process running inside its own kernel namespace, this is exactly what we need to start a shell inside our container. Let’s make it so.
☞This part deals with shells running in three different places. Trés confusing. I’ll use a different prompt to distinguish each:
>for OS X$for the boot2docker VM%for inside a Docker container
First, let’s SSH into the boot2docker VM:
Next, install nsenter:
(How does that install it? jpetazzo/nsenter is a Docker image configured to build nsenter from source. When we start a container from this image, it builds nsenter and installs it to /target, which we’ve set to be a volume pointing to /var/lib/boot2docker in our VM.
In other words, we start a prepackaged build environment for nsenter, which compiles and installs it to our VM using a volume. How awesome is that? Seriously, how awesome? Answer me!)
Finally, we need to add /var/lib/boot2docker to the docker user’s PATH inside the VM:
We should now be able to use the installed binary:
Let’s start our nginx container again and see how it works (remember, we’re still SSH’d into our VM):
Time to get inside that thing. nsenter needs the pid of the running container. Let’s get it:
The moment of truth:
Great success! Let’s confirm we’re inside our container by listing the running processes (we have to install ps first):
We can see two nginx processes, our shell, and ps. How cool is that?
Getting the pid and feeding it to nsenter is kind of a pain. jpetazzo/nsenter includes docker-enter, a shell script that does it for you:
The default command is sh, but we can run any command we want by passing it as arguments:
This is totally awesome. It would be more totally awesomer if we could do it directly from OS X. jpetazzo’s got us covered there, too (that guy thinks of everything), with a bash script we can install on OS X. Below is the same script, but with a minor change to default to bash, because that’s how I roll.
Just stick this bro anywhere in your OS X PATH (and chmod +x it, natch) and you’re all set:
Let’s test it out:
Yes. YES. Cue guitar solo.
Don’t forget to stop and remove your container (nag nag nag):
The End
Docker For Mac Center For Technology
You now have a Docker environment running on OS X that does all the things you’d expect. You’ve also hopefully learned a little about how Docker works and how to use it. We’ve had some laughs, and we’ve learned a lot, too. I’m glad we’re friends.
If you’re ready to learn more about Docker, check out The Docker Book. I can’t recommend it enough. Throw some money at that guy.
The Future Soon
Docker might be the new kid on the block, but we’re already thinking about ways to add it to our workflow. Stay tuned for great justice.
Was this post helpful? How are you using Docker? Let me know down there in the comments box. Have a great. Call your mom.
Did you know that Docker for Mac is now in general beta?
What is Docker for Mac?
Docker for Mac is a native Mac application architected from scratch, with a native user interface and auto-update capability, deeply integrated with OS X native virtualization
Docker For Mac Center For Computer
If you are using Docker Machine, then you can ssh to the machine using docker-machine ssh command and find the logs at /var/log/docker. As Docker for Mac provide a native integration with Mac, the logs
also can be found using the natural tools.
Docker Daemon Logs Mac Console
Console is a utility available in Applications -> Utilities. log viewer included with macOS. It allows users to search through all of the system’s logged messages, and can alert the user when certain types of messages are logged. The console allows you to read the system logs, help find certain ones, monitor them, and filter their contents.
File -> New System Log Query…
Give the query a name and set Sender to docker. Click on OK to save the query:
Now the daemon logs can be easily seen here.
Now Console Log Query can be used to search logs, filter the results in various ways, and create reports.
Docker Daemon Log Using CLI
If you are not a GUI-type person and prefer a CLI approach instead, then use syslog CLI. The command to see Docker logs on Mac is:
syslog -k Sender Docker
And it shows the output as: