A couple of months back, my laptop died. I recall the day I brought it home for the first time; still in college, making a big decision to go with the top model at the time, thinking, “Well, it should last at least 5 years.” — it lasted 7 years. 7 years later, a certified Apple repair person told me, “Well, you should just buy a new laptop than trying to fix this one.” So I did.
Now I have a new laptop, which is currently placed on a pedestal. How fast applications open and close on this laptop makes me cry with tears of joy. The future has arrived. I keep telling myself, “No, I will not f*** this one up this time. I will never install “software” on this laptop ever!” I am in denial of the fact that this pure awesomeness will inevitably start decaying at an exponential rate in relation to the number of new software installed and run on the laptop [Disclaimer: there exist no supporting data, but paranoia].
This is when I tried this Docker thing, in a desperate search of finding the promise land of “install no software.”
The noticeable difference in using Docker, which utilizes Linux containers, vs. using direct virtual machines approach is the speed.
Both options provide the ability to isolate software’s running environment away from the base operating system, thus delivering ever-desirable “build once and run everywhere” paradigm and addressing my paranoia that the system that provides the base OS must remain minimal and untouched. However, what makes Docker stand out from the classic VM approach is that now the cloud application (a virtual image + installed software) will run within milliseconds. Try to compare that to the pre-historic requirement of taking “minutes” of time to boot a virtual instance.
How significant does this difference make?
Docker removes a big chunk of mental roadblock for developers. With Docker, there exists no perceptual distinction between running applications on the base OS and on a virtual image (a virtual container, to be more precise) because the developers will not be able to tell the difference when it comes to the response time. It’s not only the response time, but the biggest differentiator comes from the fact that Docker strips away the tedious procedures of booting VM instances and managing the instance’s life cycle, which is not the forte of the developers. Unlike other VM-centric approaches, Docker embraces its application-centric design principal. For instance, Docker’s CLI below asks the user two simple questions:
1. Which image to use?
2. Which command to run?
docker run [options] <image> <command>
Using Docker, I can just type away a single line command to run a cloud application, as I would with any other Linux commands, then I will have my database servers running, web servers running, API servers running, file servers running. etc — all be done in single lines. The entire distributed web-stack can now be running on my laptop within seconds. The best part of all this? When I’m done, there will be no trace left on my laptop — as if they never existed. The pure awesomeness prevails.
Running Eucalyptus Console on Docker
For those who want to check out Eucalyptus Console to access Amazon Web Services, here are the steps to launch Eucalyptus Console using Docker on OS X.
Step 1. Install Docker on your laptop
Here is a great link that walks you through how to install Docker on OS X:
http://docs.docker.com/installation/mac/
Step 2. Pull Eucalyptus Console Docker image repository
Run the command below to pull Eucalyptus Console Docker images (it will take some time to download about 1.5 G image files):
docker pull kyolee310/eucaconsole
Run the command below to verify that the eucaconsole images have been pulled:
docker images
For those who want to build the images from scratch, here is the link to the Dockerfile used:
https://github.com/eucalyptus/dockereuca
Step 3. Update Docker VM’s clock
One issue that I faced while running Docker on OS X was that the clock wasn’t sync’ed properly, which was problematic for some applications. In order to fix this issue, you will need to log into the Docker VM and sync the clock manually.
You can SSH into Docker VM using the command below:
boot2docker ssh
Once logged in, run the command below to sync the clock:
sudo ntpclient -s -h pool.ntp.org
Run the command below to verify that the clock has been sync’ed
date
One more patching work to do is to create an empty “/etc/localtime” file so that you can link your OS X’s localtime file to Docker VM’s localtime file at runtime:
sudo touch /etc/localtime
Exit the SSH session:
exit
This issue is being tracked here:
https://github.com/boot2docker/boot2docker/issues/476
Step 4. Launch Eucalyptus Console via Docker
Run the command below to launch Eucalyptus Console on Docker:
docker run -i -t -v /etc/localtime:/etc/localtime:ro -p 8888:8888 kyolee310/eucaconsole:package-4.0 bash
It’s a shame, but running a live “bash” session is not Docker’s way of doing things, but excuse me for the moment until I figure out how to run Eucalyptus Console properly without using the “service” command.
The command above will open a bash shell session for the eucaconsole image, then run the command below to launch Eucalyptus Console:
service eucaconsole start
Step 5. Open Eucalyptus Console on a browser
Run the command below to find out the IP of Docker VM:
boot2docker ip
, whose output would look like:
The VM’s Host only interface IP address is: 192.168.59.103
Using the IP above, access Eucalyptus Console at port 8888:
ex. http://192.168.59.103:8888/
In order to access AWS, you will need to obtain your AWS access key and secret key. Here is the link by AWS on howto:
http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSGettingStartedGuide/AWSCredentials.html
Step 6. Log into AWS using Eucalyptus Console
