Facilitating Containerization with Docker & JBoss for Seamless Deployment

Listen in as Audrey Kabel interviews Open Source Architect JBoss expert and consultant, Robert Greathouse on the best uses of Docker & JBoss in facilitating containerization for seamless deployment.


Facilitating Containerization with Docker & JBoss for Seamless Deployment

Facilitating Containerization with Docker & JBoss for Seamless Deployment

Project About

Audrey?: Hello everyone and thanks for listening in! This is Audrey speaking on behalf of “Open Source Architect” where we speak Open Source! Let’s get started with introducing our guest for today’s show. He’s new to our OSA podcast routine ­but you might recognize him from our recent videos on Continuous Deployment to OpenShift with Cloudbees Jenkins Platform, and Enhancing Continuous Integration with Application Performance Monitoring. Everyone welcome Open Source Architect’s System and Data Architect, Robert Greathouse!

Robert: Thank you for having me Audrey.. Glad my videos were well received.

Audrey: Well that’s actually why I wanted to have you on. There has been a lot of interest in your educational videos and we wanted to discuss some of the tools you used in both videos, but it didn’t cover much Docker, and JBoss. Will you take a minute and tell us about how Docker fits in?

Robert: Sure. Docker, and its underlying philosophy, DevOps is taking over the IT industry. Major players such as RedHat and Pivotal are completely redesigning their existing products and releasing whole new product lines to let customers take advantage of this revolution. And for many, it can be very intimidating. Just when everyone got comfortable adopting Agile development, we have a new methodology. But actually, DevOps is what we’ve been striving for for decades. Seamless integration of development and infrastructure efforts. And Docker, or Containerization in general is facilitating that.

Audrey: The DevOps philosophy is something I’d like to cover in another episode. Could you tell us more about the technology that goes into Docker?

Robert: Of course. Docker is actually based on features introduced to the Linux kernel about 9 years ago, Namespaces, and Control Groups. Control Groups allow you to allocate an segregate system resources like memory, processing time, and network access. And Namespaces allow you to isolate, and virtualize system resources for processes. Basically, this is similar to the virtual machine revolution decades ago. We have an even more flexible, and lightweight virtualization solution for the OS, just as we have with hardware.

Audrey: That’s a pretty bold statement. Virtual machines are an industry standard now. You almost have to justify NOT using virtual machines these days. VMs are the foundation of several programming languages. Do you really think containerization is going to take over in the same way?

Robert: I stand by it. Just as hardware virtualization allowed us to commoditize hardware resources, so that we can take advantage of consolidating those resources. Containerization allows us to commoditize OS resources in the same way. We already see major players in the industry adopting it. RedHat Atomic is designed to leverage containers. JBoss is releasing canonical containers for the majority their products. Several are already released. Cloudbees provides a containerized version of their Jenkins platform. Amazon and Google already have container hosting services available. And PaaS solutions like Cloud Foundry and OpenShift are rolling out some of the largest enterprises. That’s why it’s important for us, as an industry, to make sure that we apply what we’ve learned in other areas to this new capability.

Audrey: That gets us to the reason why I asked you here. What are some of the best practices we should be implementing in our JBoss containerized solutions, specifically, anything that can apply to Docker?

Robert: I feel the first thing to remember when including containers and Docker specifically into your development and deployment process is that while new, all the standards we use everywhere else still apply. Reproducible builds are a perfect example. When I’m developing an application in any language, I want to design it, and use build tools that make it portable. Another developer should be able to get my code, and build configuration and reproduce my build. That’s why he have Ant, Maven, and Gradle. That’s why Ruby and Go include dependency management internally.

Audrey: So how should we apply that to Docker builds?

Robert: I’ve seen a lot of projects online where the Docker builds, I mean the scripting in the Dockerfile, will use tools like curl to retrieve their build artifacts, like the EAP zip file. This should be used with care. Do we really want to overload what is effectively a compilation tool in this case. And do we want to retrieve the artifacts from a supposedly canonical source? In the case of vendor supplied infrastructure artifacts, like JBoss this is probably perfectly fine. But even then, I don’t think it’s something to trouble Docker with. This is why, just like we use Maven to handle retrieving our dependencies, we should use shell scripting, or an automation engine like Cloudbees Jenkins Platform to gather our artifacts, and simply place them in the Docker build context. That way, our build is completely portable, and modular. I, as a developer can simply insert the dependencies I want to use. Essentially, treat Docker as a compiler, and provide it the artifact it needs to compile your image.

Audrey: Build tools commonly come with their own quirks, and best practices to address them. Is there anything in Docker we should be aware of?

Robert: Possibly the most important thing is how Docker handles it’s filesystem. The Union File System, or UFS works as read only files that are layered on top of each other to create the file system we see inside our container. Each of these layers is read only. Whenever we write a file inside our container it exists in a layers of it’s own. And anything we do only effects that layer. And each directive in our Dockerfile is an independent layer. So if I use the Docker COPY directive to put a file inside my container, that’s one layer. Locked down, read only now. If I later use the RUN directive to extract that file, and then delete the original, I haven’t actually deleted the file. It still exists in the previous layer. All I’ve done is delete my access to that file in my current layer.

Audrey: Well, I think that should be plenty for our audience to mull over when designing their own projects. Any final advice for our audience?.

Robert: Just to keep in mind that new tools give us new ways to utilize what we’ve learned. We just may need to adjust them for the specific tool.

Audrey: Well it sounds like you know the ins and outs of DevOps and Docker! You were the right choice for this podcast! What’s the easiest way for our listeners to learn more about what they heard on this podcast?

Robert: Well I appreciate it Audrey, and you are too kind! One of the best ways for folks to learn more about DevOps, JBOSS + Docker best practices would be to contact our fantastic and helpful account managers.

Audrey: Sure Robert and thank you so much for sharing some of your expertise with us today.

Robert: No problem and I look forward to the next podcast!

Audrey: For all you listeners out there, if you want Devops advice, contact us for more information! You can go to opensourcearchitect.co or give our fantastic account mangers a call at 972-559-4OSA that’s 972-559-4672. You’re listening to Audrey at Open Source Architect, where we speak open source, until next time!

It's only fair to share...Share on FacebookTweet about this on TwitterShare on LinkedIn


June 26, 2016

Similar Projects

Two thumbs up

Red Hat Learning Subscription Standard (LS220) with Scott Stewart

It's only fair to share...

John Ryan smiling

John Ryan from Ansible discusses Dev-Ops

It's only fair to share...

Man and woman discussing a whiteboard flow chart

OpenShift: Your Golden Ticket to Streamlining, Automating, & Communicating!

It's only fair to share...