WebSphere Liberty on IBM Containers: Part 1

May 16th, 2016

Getting Started

I wanted write a few blog posts as I explored deploying our WebSphere Liberty Docker image on to third-party cloud platforms but this didn’t really feel fair given that I haven’t written anything here about the options using IBM’s cloud platform! So, to kick things off, here’s a series of posts on using Liberty with the IBM Containers service in Bluemix. In this post I’m going to focus on using the web UI to get a simple Liberty container up and running. In subsequent posts I’ll cover topics such as deploying an application, scaling applications and using the command line.

I’m also going to use the new console for the instructions/screenshots in this post. If you don’t already have an account, use the sign-up button at the top right of the console to get a free 30-day trial.

You can use WebSphere in a number of different ways in Bluemix: web applications deployed as Cloud Foundry applications will use the Liberty runtime and it’s also possible to stand-up WAS ND topologies for both Liberty and the traditional application server in VMs. Here we’re going to focus on containers.

Once logged in, select the Compute icon and then the Containers tab. Then click the + icon top-right to create a new container. You should find that the private registry associated with your account is already populated with a number of IBM-provided images as shown in the following screen shot. Select the ibmliberty image. This image adds a few layers on top of the websphere-liberty image from Docker Hub to make it run more cleanly in IBM Containers (see the Dockerfile in the docs for full details).

Select container image

You will now see a drop-down on the left which allows you to select the image tag to use. By default the latest tag will give you the full Java EE7 profile image. Select the webProfile7 tag to get a lighter-weight image. Beneath the tag you’ll an area entitled Vulnerability Assessment which, if we’ve been doing our properly, should say Safe to Deploy. Assessments are updated regularly as new CVEs are announced and we therefore regularly refresh the image to make sure that it stays clean.

Vulnerabilty Advisor

At the top of the page, you’ll see that the Single option is selected to create just a single container instance, we’ll return later to see how the Scalable option works. Give the container a name. Leave the container size at Micro but select the option to Request and Bind Public IP.  All containers get an IP address on a private network and are accessible by other containers in the same space but to be accessible externally they must be assigned a public IP.

Create a container

Now click the Create button at the bottom of the page. After a minute or two the status of the container should change to Running.

Container running

Switch to the Monitoring and Logs tab. The container level metrics around CPU/memory/network usually take some time to appear but if you select the Logging tab you should be able to see the messages output by Liberty as the container started. Tip: you can use the ADVANCED VIEW button on these tabs to open up Grafana and Kibana views on to these metrics and logs respectively if you want to do more detailed analysis.

Container logs

Finally, switch back to the Overview tab. If you scroll down to the Container details section, you’ll find a list of ports. If you click on 9080, this will open a new browser tab using that port and the public IP address assigned to the container. With the default image, that should show the Liberty welcome page.

Liberty welcome page

Congratulations – you have run WebSphere Liberty on IBM Containers! The astute among you will, however, have noticed that it’s not running any application. That’ll be the subject of the next blog post…

Two Days with Uncle Bob

May 13th, 2016

I’ve been lucky enough to spend the past two days in the presence of Robert C. Martin a.k.a. Uncle Bob for his Clean Code workshop at Skills Matter in London. I arrived at the very last-minute having decided to try out a Santander Cycle for the first time, only to discover that the promised docking station next to Code Node has disappeared under road works.

The workshop got off to a slow start as we spent over an hour going round the room indicating how long we’d been programming and what languages we’d used. This seemed to be just so that we could observe that, as well as a fair smattering of those in the first 5-10 years, there were many of us beyond our first flush of youth! That, and so that Bob could provide a potted history of various programming languages. This was a general theme for the course with Bob prefixing each module with an interlude on some aspect or other of astro or nuclear physics!

As a consequence of the above, if attendees were expecting to learn all of the content of the Clean Code book during the workshop then they’d leave disappointed. (Although a copy of the book was included in the exorbitant course fee.) What you did get was a good understanding of the values that underlie the practices covered by the book, the opportunity to watch the master at work refactoring and plenty of opportunity to ask questions first-hand.

I shan’t attempt to repeat the material but there were two main a-ha moments for me. The first was that, as a result of not doing test-first development, we’ve ended up with unit tests focused on each individual method. This has made them extremely fragile to refactoring which, in turn, means that either the tests quickly fall by the wayside or that refactoring just doesn’t happen. And that leads to the second learning point: to refactor mercilessly, extracting functions until every function does just one thing. I had fallen in to the trap of seeing the myriad of small methods as adding to the complexity. Bob’s argument is that, well-named, the methods allow you to quickly gained an understanding of what the code is doing at every level of abstraction. Based on the one exercise that we did during the workshop, I’d say that pairing is immensely helpful in determining what makes a good name. Anyway, lots to share back with my colleagues!

As an aside: I can heartily recommend the Hawksmoor Seven Dials if you are a fan of steak (although it has to be said that the corporate expense limit would have just about covered the meat on my plate!).

British Birthday

May 4th, 2016

Christine @ Brown Clee British ChampsFor the Bank Holiday weekend we headed to the British Orienteering Champs at Brown Clee in Shropshire. We arrived in glorious sunshine on Saturday morning but this soon turned to hail as we climbed up the hill to the assembly area. We were very grateful that a club mate had already erected the club tent as the hail came and went for most of the afternoon.

I had an early start and it has to be said that I had a pretty poor run in my first year at M40. Although 7th place in the results doesn’t sound too bad, I was over half an hour behind Georgie Best with ten minutes of that loss being attributable to just two controls. (With 27 controls in 9.2k there was plenty of opportunity for losing time!) Christine failed to repeat her W16 win at Brown Clee, faring marginally better than me but still ending up ten minutes down on her course winner. Emma had the best result of the day, coming third on the white course in a time that would have netted her a win on W10B if she had the confidence to go out on her own.

With rain forecast for most of Sunday, Christine and I returned for the relays without the children. I’m glad to say that we both had better runs. Christine returned first on the Women’s Short just as I set out on first leg on the Men’s Short. I ran alone for much of the course being caught just at the end and finishing just a few seconds down in second place. The commentary team had been primed to wish me a Happy Birthday as I came down the run-in! My team finished in fifth place whilst Christine, sadly, did not have a complete team.

On the Monday Emma ran again, completing the hilly 2km at Devauden XC races in 11:16. Christine and I were happy to sit the 10k out this year and watch her Mum run instead!

Active Weekend

April 24th, 2016

Emma RunningDuncan RunningIt’s been an active weekend in the Currie household. On Saturday morning we made the trek over to Staunton Country Park for the second in SOC’s Solent Summer Series. Buoyed by just receiving the SOC Junior Women’s trophy for 2015 (although she was quick to point out that she didn’t have much competition, Emma was happy to go out on the yellow with Christine and a grumpy Duncan in tow. I went out on the light green which was more than a little muddy in places. Rob Finch managed to turn the tables from Fleming Park pipping me to first place by 14 seconds.

Christine after half marathonFrom there we headed in to Southampton for the ABP Southampton Fun Run. Christine set off on the 1 mile course with both children but Duncan got a stitch and Emma ran off and left them towards the end. The field was smaller than I had expected given the potential catchment area for the race. Christine then ran again in the half marathon on Sunday finishing in a chip time of 1:40:54. Not bad given the lack of training she’s done due to injury.

ES2015 in Production

April 21st, 2016

Bård Hovde gave tonight’s Developer South Coast presentation on the subject of “ES2015 in Production” (or “ES6 in Production” if you must). You can find the slides here with the source for the presentation over on Bård’s GitHub account. He did a great job of making the subject matter entertaining. Beyond being able to say goodbye to all of that boilerplate, my main takeaway was the use of Babel for transpiling ES2015 into ES5, so no excuses about waiting for browser compatibility! The Babel site also has a nice overview of ECMAScript 2015 features.

docker logs and stderr

April 12th, 2016

As part of a script that I was writing today I was attempting to count the number of times that a containerised Liberty server had started. I started with the following command:

docker logs test | grep "CWWKF0011I" | wc -l

(where CWWKF0011I is the code for Liberty’s “ready to run a smarter planet” message) but it was giving me an answer one greater than I anticipated. Stripping off the line count at the end quickly showed why: in addition to the messages that I was expecting, grep also appeared to be returning an error message from the logs. It took me a little while longer to get my head around what was going on. grep wasn’t passing the error at all. Indeed, the error wasn’t even getting as far as grep. Instead, docker logs was trying to be helpful and recreating the stdout and stderr streams from the container; stdout was getting piped to grep, and stderr, where Liberty was outputting its error message, was just going straight to the console. This was also going to cause me a headache elsewhere when I was actually trying to grep for errors.

When I first learnt bash, 2>&1 was the way to redirect stderr to stdout but, just to prove that you can teach an old dog new tricks, here’s the working version of my original command using the Bash 4 syntactic sugar to merge stderr in to a pipe:

docker logs test |& grep "CWWKF0011I" | wc -l

As a further aside (which certainly added to my confusion when trying to debug this), if you allocate a TTY to a container via the -t flag on the run command, stderr will be merged in to stdout before it hits the logs so you won’t see this behaviour at all!

Book Review: Docker Containers: Build and Deploy with Kubernetes, Flannel, Cockpit, and Atomic

April 11th, 2016

I’m slowly working my way through the list of Docker publications that I stacked my tablet with when IBM restarted its subscription to Safari Books Online. One of these was Docker Containers: Build and Deploy with Kubernetes, Flannel, Cockpit, and Atomic by Christopher Negus. The last two projects in the title are a clue to the underlying theme of the book. Cockpit and Atomic being Red Hat projects, this is really a guide to doing containers the Red Hat way. This I was expecting – they do employ the author after all. What really disappointed me was that the four technologies cited in the title occupied so little of the book’s content. Of the 18 chapters, there was one on Super Privileged Containers (an Atomic concept), one on Cockpit, two on Kubernetes, and one paragraph on Flannel. Hardly comprehensive coverage!

The first part of the book covers the basic concepts, setting up an OS and a private registry. This reminded me of one key fact that I’d forgotten: that Red Hat ships its own Docker distribution. One of the Red Hat specific features is the ability to specify multiple default registries (with Red Hat placing their own registry ahead of Docker Hub in the default search order). This is at odds with Docker’s view that the image name (including registry host) should be a unique identifier. Personally, I would side with Red Hat on this one. I suspect many customers will be using their own private registries and would prefer to be able to specify ‘myimage’ and have it resolve against the correct image in the local registry for the environment.

The bulk of the content is in the second part that covers building, running and working with individual containers. There were a few errors that crept in to this section. For example, the author suggests that setting the environment variable HOST on a container somehow magically mount the host filesystem (it’s actually used to tell Atomic where the host filesystem is mounted). He also states incorrectly more than once that removing files introduced in one layer in a subsequent layer will reduce the size of the image. In general though, it provides a good coverage of working with containers. I picked up a few interesting command options that I wasn’t aware of. For example, ‘-a’ on a ‘pull’ to retrieve all of the images for a repository, the fact that you can use ‘inspect’ on images as well as containers, and a couple of commands that had previously escaped me completely: ‘rename’ and ‘wait’. There was also some useful information on the use of Docker with SELinux.

The third part covers Super Privileged Containers in Atomic (the way in which Atomic extends the basic capability of the OS via containerized tools) and management of Docker hosts and containers through the Cockpit browser based administration tool. The fourth part then covers the basic concepts of Kubernetes and the steps for setting up an ‘all-in-one’ environment and a cluster. These steps seem destined to be out-of-date before the ink is dried and the space would have been better spent covering the concepts in more depth and talking about usage scenarios.

The final part seems a little out of place. One chapter covers best practices for developing containers. The cynic in me suspects this may have just been an opportunity to introduce some OpenShift content. It certainly glosses over the entirety of Machine, Compose and Swarm in just a single section. Then there is a closing chapter looking at some example Dockerfiles.

All-in-all, the book offers a good introduction to the topic of Docker, particularly if you are looking to deploy on Fedora, RHEL or CentOS. Look elsewhere though if you really want to get to grips with Kubernetes.

Docker for Mac Beta

April 10th, 2016

I was excited to see Docker announce a beta for ‘native’ support for Docker on Windows and Mac where ‘native’ means that Docker appears as a native application utilising built-in virtualisation technology (Hyper-V on Windows and a project called xhyve on Mac) rather than requiring Virtual Box. Sadly this isn’t much use to me at work where I run the corporate standard Windows 7 on my laptop and Linux on my desktop. (The Register had an article indicating that, although Windows 7 is declining in the enterprise, its market share is still 45%+ so I hope Docker don’t do anything rash like ceasing to develop Docker Toolbox.) I do have a Mac at home though so I signed up for an invite.

The install went very smoothly although the promised migration of images and containers from my existing default Docker Toolbox image failed to happen. My best guess was that this was because the VM was back-level from the version of the client that the native app had installed although I’m only guessing. Docker Machine and the native app sit happily alongside one another although obviously I then needed to upgrade the VM to match the newer client version.

Needless to say, the first thing I tried to run was the websphere-liberty image. This started flawlessly and, having mapped port 9080 to 9080, I was then able to access the Liberty welcome page at docker.local:9080. So far so good.

WebSphere Liberty under Docker for Mac Beta

Having been out on vacation at the time, I went back and listened to the online meetup covering the beta. Given that we have websphere-liberty images for PPC and z/Linux, I was particularly intrigued to see that it promised the ability to run images for multiple architectures. The example given in the meetup worked like a charm:

$ docker run justincormack/ppc64le-debian uname -a
Linux 9a41dded6970 4.4.6 #1 SMP Mon Apr 4 15:12:22 UTC 2016 ppc64le GNU/Linux

Unfortunately trying to run anything against other images such as ppc64le/ubuntu resulted in a ‘command not found’ from Docker so I need to do some more digging to see what’s going on here.

Whilst browsing the beta forums, a common complaint was the speed of the file system mounts which has also been a problem with the Virtual Box approach. I decided to test this out by trying to use the maven image to compile our DayTrader sample. To keep things ‘fair’, my maven cache was pre-populated and, when running the image, I mounted the cache.

Natively on the host a ‘mvn compile’ takes around 12 seconds. With Docker running in a Docker Machine VM using the following command, the time was surprisingly close, typically of the order of 14 seconds.

$ docker run -v $HOME/.m2:/root/.m2 -v $(pwd):/usr/src -w /usr/src \
    maven mvn compile

Running the same command against the beta unfortunately took over 30 seconds. Whether that’s down to the file system driver I can’t say. It’s certainly an appreciable difference but, hey, this is a beta so there’s still plenty of hope for the future!

One tip that I picked up on the way: ‘docker-machine env’ has an  ‘–unset’ option which means that, if you want to switch back to the native Docker install after using Machine, then you can use the following command:

$ eval $(docker-machine env -u)