Daily Archives: February 29, 2016
What is BusyBox? The Swiss Army Knife of Embedded Linux Coming in somewhere between 1 and 5 Mb in on-disk size (depending on the variant), BusyBox is a very good ingredient to craft space-efficient distributions. BusyBox combines tiny versions of many common UNIX utilities into a single small executable. It provides replacements for most of the utilities you usually find in GNU fileutils, shellutils, etc. The utilities in BusyBox generally have fewer options than their full-featured GNU cousins; however, t
During the creation of the preceding posts on kubernetes, coreos, and docker, I have encountered something called ‘BusyBox’
Many sites assume you know what this is. Let me explain just in case your not entirely sure.
Wouldn’t it be great to have a Linux box that fits inside a single executable and is less than 5mb in size? That’s BusyBox.
The beautiful thing about where we are in container education is we found an even easier and more consistent way to get, use and extend BusyBox… watch carefully…
docker run -it –rm busybox
Thats it – your dropped into a ‘shell’ and can run most linux commands (limited subset of switches for some). It sure beats downloading cygwin for quick and dirty jobs.
Guestbook ExampleThis example shows how to build a simple multi-tier web application using Kubernetes and Docker. The application consists of a web front-end, Redis master for storage, and replicated set of Redis slaves, all for which we will create Kubernetes replication controllers, pods, and services.If you are running a cluster in Google Container Engine (GKE), instead see the Guestbook Example for Google Container Engine.
Source: Guestbook Example
Its been a long time since I wished to work with Kubernetes. But the time has passed. I got my hands on instructions to build out a local kubernetes cluster and then load redis and an app onto it.
Very cool stuff. I was impressed with the simplicity of the controller and service definitions. I don’t fully understand it all yet but it was very easy to put the concepts and their relationships together.
You start out with an empty kubernetes cluster. Its essentially build atop fedora with saltstack as its delivery mechanism for all components. It was nice to see plenty of python and cherrypy (an old friend).
As with any saltstack deployment you have a master and a minion with secured keys exchanged. I had 3 nodes appear in my virtualbox (e1, c1, w1). That was an etcd node (for key/value pairs), a controller and a worker. I think the master was pushed out onto the controller and the minion was the worker? Not sure of the mappings yet. I think the controller is more or less what they call ‘flannel’.
Getting kubernetes installed was difficult due to a bug whereby saltstack couldn’t be found via curl. I found the answer to this in a forum – replace the curl statement in the provision-master and provision-minion scripts and re-run kube-up.sh.
Then, following the demo I found a missing instruction. To bring this up on a localhost you need to forward an IP from your local host to the guest app pod. This might be wrong, but it was the only way I could get access to the guest app from a browser.
Kubernetes claims they are inherently more secure than docker. I don’t completely understand that claim yet (other than through documentation they offer). I plan to find out soon.
One of the items I am not fully understanding here is how to serve up content from an external file system/mount. I need to work on this because I use apache from time-to-time and I like having mounted content. The problem I am seeing with kubernetes is “how does the content in a path get shared amongst pods/members?” I will have to test this out more.
All-in-all, very cool technology. I am enjoying experimenting with it.