Category Archives: PaaS
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.
Getting Started with etcd etcd is an open-source distributed key value store that provides shared configuration and service discovery for CoreOS clusters. etcd runs on each machine in a cluster and gracefully handles master election during network partitions and the loss of the current master. Application containers running on your cluster can read and write data into etcd. Common examples are storing database connection details, cache settings, feature flags, and more. This guide will walk you through a
Source: Getting Started with etcd on CoreOS
Today I got a better understanding of how to use the etcd tool for CoreOS. As soon as I read the description of the component I though “not another zoo keeper!”. Well, I am happy to say this is a much easier tool to use than zoo keeper. The use is the same – storage of key/value pairs.
I followed the tutorial and learned how to set, get, remove and watch a variable. There was really no effort needed to figure out how to use this across the three node cluster we have.
In one window I logged into core-01 and in another window, core-02. I executed a set “etcdctl set /message Hello” on core-01. This sets the value pair in the shared directory service for the cluster. From core-02 I issued “etcdctl get /message” and “Hello” was returned. Very neat and easy. Essentially etcdctl is a shortcut to using curl with all its switches and values. Makes using curl much simpler for this very specific purpose.
One of the more advanced uses of etcdctl is watching a key for a change and then taking some action based upon it. Once again, very easy. On core-01 issue:
etcdctl exec-watch --recursive /foo-service -- sh -c 'echo "\"$ETCD_WATCH_KEY\" key was updated to \"$ETCD_WATCH_VALUE\" value by \"$ETCD_WATCH_ACTION\" action"'
On core-02:
etcdctl set /foo-service/container3 localhost:2222You will see on core-01, instantly, the message:
“/foo-service/container2” key was updated to “localhost:2222” value by “set” action
Couple etcdctl with systemd via fleet and now you have an interactive cluster that can take action based on values set like parameters indicating increased load or slow response time from an app. The possibilities are endless.
Next I want to get to rkt (rocket).
Launching Containers with fleet fleet is a cluster manager that controls systemd at the cluster level. To run your services in the cluster, you must submit regular systemd units combined with a few fleet-specific properties. If you’re not familiar with systemd units, check out our Getting Started with systemd guide. This guide assumes you’re running fleetctl locally from a CoreOS machine that’s part of a CoreOS cluster. You can also control your cluster remotely. All of the units referenced in this blog
Source: Launching Containers with fleet
Here is the second in the series of gearing up for kubernetes. I wanted to learn how systemd and fleet work together to get container spread throughout a cluster. If you understand how containers run in docker (required reading) then you should see the power of this simple toolset.
First we build a service file (a unit). The service file is essentially a case statement with pre-reqs and conditionals. If you have ever started or stopped a service on a linux client, then its easy to link what this service file does. It is essentially building a linux service. Instead of the service running other binaries (which it can do also), it executes docker commands (kill, rm, pull, run).
When you are finished writing a service, you use fleet to distribute it. Either you ask fleet to spawn 1 or more of the service anywhere it likes, or you can instruct fleet to filter where it runs based on metadata retrieved from the machines that are in the CoreOS cluster. In addition to this control feature, you can create a global service and when run it will spread out onto each of the machines in the cluster; providing high availability.
Neat, simple and powerful. I am going to move onto playing with rkt (rocket) next. Stay tuned.
“Deploy, Scale, and Manage Your PHP, Ruby, & Node.js Applications”
via Engine Yard Trial.
“The relationship between central IT and developers is being re-defined as the world adopts cloud technologies. The ultimate challenge is making central it feel secure while simultaneously giving developers freedom. IT wants to be able to control the deployment of applications so that there is consistency and adherence to policy. The policy could be related to PII or even the size of the VM that will host the application. There could also be cost considerations as well as monitoring and performance. Developers want to focus on their applications, their code. Developers don’t want to worry about public versus private cloud or with finding exactly their app should be installed.”
Docker is red hot at Red Hat | DevOps.comDevOps.com.
Great news for early adopters of RedHat’s OpenShift. Docker will allow portability of an app from start of engineering to full-scale production. Great concept that continues to repeat itself over time.
Pivotal, IBM to work with community to further develop the Cloud Foundry platform and establish open governance model for Cloud Foundry; Project to help developers drive open, collaborative innovation for cloud-based apps