November 3, 2015 | Software Consultancy
My JavaOne experience was rather busy this year, what with three talks presented in a single day! The first of these talks “Debugging Java Apps in Containers: No Heavy Welding Gear Required” was delivered with my regular co-presenter Steve Poole, from IBM, and we shared our combined experiences of working with Java and Docker over the past year.
After a brief introduction to the talk, Steve and I provided an overview of our experiences of working with Java and Docker. Over the past year Steve has been looking at rolling out an internal large-scale container-based platform within IBM. Accordingly, he has approached the topic of Java and Docker from the ‘bottom up’ perspective, gathering requirements and analysing what is required of such a platform.
Within the same time period I have been approaching the combination of Java and Docker from a ‘top-down’ perspective, as many of our clients at OpenCredo have been experimenting with the combination of these technologies. Therefore, I’ve had a front-row seat (alongside my OpenCredo colleagues) in the early adoption of Java applications within Docker, and the opportunities and challenges of working with container technology.
As with many of the talks that Steve and I have presented, our experiences are often nicely complementary, and the preparation for this presentation led to some interesting conversations and insight for us both (and hopefully you too!)
Steve kicked-off the talk by introducing core Docker concepts, such as Dockerfiles and ‘docker run’, and then covered basic Java debugging techniques, using ‘mvn exec:java’ and IntelliJ IDEA debug support. We also introduced ‘docker ps’ and the ever-useful ‘docker exec -it’ command, which can be used to attach to a running container and execute arbitrary commands.
Steve is a big fan of the Kitematic GUI Docker container-management application, which is part of the Docker Toolbox, and he demonstrated how this tool can be used to attach to running containers in order to execute debugging utilities without the need for docker exec. We also covered the basics of remote debugging with Java and Docker, and referencing the great instructions from Patrick McCarthy, we highlighted the gotchas that have troubled us.
Finally in this introductory part of the talk we covered the basics of Java command line debug tooling, such as jps, jstat and jstack (all links here are for the JDK 8 version of the tools), as I have found these useful for getting access to key metrics and hints as to what is going on within a JVM without attaching a profiler or debugger.
In part two of the talk Steve attempted to banish misconceptions of Docker that he has heard from developers new to the technology, and I added my thoughts about cloud technology and some of the similar challenges this can also bring. There are typically restrictions in terms of minimal operating systems, limited resource (often with contention), and applications or platforms that don’t fully respect the Docker resource encapsulation model (for example, some parts of the /proc filesystem are not cgroup aware). This can make debugging even more challenging as the problem space has now been increased, and as we all know, the key part of debugging is locating the issue!
A series of real-world case studies were presented in the third part of the talk, and rather than duplicate the information that is already contained within the slides below, I’ll simply summarise the issues here that I’ve commonly encountered when working with Java and Docker:
Steve and I summarised the talk by providing an insight into our key learnings working with Java and Docker over the past year:
Both Steve and I believe that debugging is still an essential skill, even in the age of TDD, disposable microservices and ephemeral containers. Maybe, just maybe, with the potential rise in system complexity, it is a more important skill than ever before?
Finding, isolating and replicating any issues is a vital approach to systematically locating and fixing a bug. Debugging Java applications that are running within a container doesn’t require a massive shift in mindset, as a lot of the old tooling and approaches still work. However, container and cloud technology do add some additional challenges to the debugging process, but knowledge is your friend, and we recommend building your ‘debugging toolbox’ with the information contained within this presentation.
Finally monitoring, logging and alerting are essential components of container operation and debugging, regardless of programming language choice.
I’ve uploaded the slides that Steve and I created to SlideShare, and you can find a preview here:
At OpenCredo we are early adopters of many technologies, including container and cluster management technology, and so please do get in touch if you require information or guidance in your organisation. Although we are passionate about exploring emerging technology, we are also pragmatic, and we won’t recommend containers (or indeed any technology) unless we believe it is a good fit for your situation. Contact me at @danielbryantuk or email@example.com
This blog is written exclusively by the OpenCredo team. We do not accept external contributions.