Although containers and Kubernetes and microservices seem to come up in every conversation, there’s a big chasm between talking about, demonstrating, and actually using a technology in production. Anyone can discuss containers, many people can demo them, but far fewer are successfully using containers and Kubernetes in a microservices architecture.
Why? There are likely many reasons, but a simple one may be that developers don’t know where to start.
Consider this series of articles your starting point. Relax, read on, and get ready to enter the exciting world of containers, Kubernetes, and microservices.
Continue reading “Containers, Kubernetes, and microservices: Start here”
With Kubernetes evolving at supersonic speed and seeing a lot of adoption in the enterprise world, the developer community is now looking for solutions to common Kubernetes problems, such as patterns. In this article, I will explore a new Kubernetes pattern using Init Containers.
Let’s start with the use case that gave birth to this problem: Quarkus—Supersonic and Subatomic Java—has excited the Java developer community with its amazing speed and all new native build artifact for Java applications. As one of those excited developers, I want to quickly build and deploy a Quarkus application on to Kubernetes.
Continue reading “Init Container Build Pattern: Knative build with plain old Kubernetes deployment”
The OpenShift 4.0 Developer Preview is available for Amazon Web Services (AWS), and if you’re anything like me, you want to be among the first to get your hands on it.
The starting point is try.openshift.com, where you’ll find overview information and that important “Get Started” button. Click it and you’re off to the big show.
Continue reading “OpenShift 4.0 Developer Preview on AWS is up and running”
A Java runtime environment should be able to run compiled source code, whereas a development kit, for example, OpenJDK, would include all the libraries/binaries to compile and run the source code. Essentially the latter is a superset of the runtime environment. More details on OpenJDK support and lifecycle can be found here.
Red Hat ships and supports container images with OpenJDK for both Java 8 and 11. More details are here. If you are using Red Hat Middleware, the s2i images shipped are also useful to deploy, for example, on Red Hat Openshift Container Platform.
Note that Red Hat only provides OpenJDK-based Java 8 and 11 images. With that said, there will certainly be situations where developers would like to create their own Java runtime images. For example, there could be reasons such as minimizing storage to run a runtime image. On the other hand, a lot of manual work around libraries such as Jolokio or Hawkular and even security parameters would need to be set up as well. If you’d prefer not to get into those details, I would recommend using the container images for OpenJDK shipped by Red Hat.
In this article we will:
- Build an image with Docker as well as Buildah.
- We will run that image with Docker as well as Podman on localhost.
- We will push our image to Quay.
- Finally, we will run our app by importing a stream into OpenShift.
This article was written for both OpenShift 3.11 and 4.0 beta. Let’s jump right into it.
Continue reading “Creating and deploying a Java 8 runtime container image”
I was asked recently on Twitter to better explain Podman and Buildah for someone familiar with Docker. Though there are many blogs and tutorials out there, which I will list later, we in the community have not centralized an explanation of how Docker users move from Docker to Podman and Buildah. Also what role does Buildah play? Is Podman deficient in some way that we need both Podman and Buildah to replace Docker?
This article answers those questions and shows how to migrate to Podman.
Continue reading “Podman and Buildah for Docker users”
Red Hat CodeReady Workspaces provide developers with containerized development environments hosted on OpenShift/Kubernetes. DevOps teams can now use a hosted development environment that’s pre-built for their chosen stack and customized for their project.
CodeReady Workspaces can help you rapidly onboard developers for your project as everything they need to develop is running in a containerized workspace. In this post, we’re going to use CodeReady Workspaces to get up and running quickly with an existing open source project, Peak. Peak is a multi-container Kubernetes application for performance testing web services, and it allows you to create distributed performance tests using the Kubernetes Batch API for test orchestration. We’ll make some modifications to Peak’s Flask front end, a stateless web interface that interacts with a Falcon RESTful API to return data about performance tests. You won’t need the complete Peak application deployed, though if you like, you can find steps to deploy it to OpenShift here.
To follow along you’ll need a Red Hat OpenShift Container Platform 3.11 environment. You can use the Red Hat Container Development Kit on your Windows, macOS, or Linux laptop or a hosted Red Hat OpenShift instance to do it on online.
Continue reading “Creating a containerized Python/Flask development environment with Red Hat CodeReady Workspaces”
Usually, we think about IoT applications as something very special made for low power devices that have limited capabilities. For this reason, we tend to use completely different technologies for IoT application development than the technology we use for creating a datacenter’s services.
This article is part 1 of a two-part series. In it, we’ll explore some techniques that may give you a chance to use containers as a medium for application builds—techniques that enable the portability of containers across different environments. Through these techniques, you may be able to use the same language, framework, or tool used in your datacenter straight to the “edge,” even with different CPU architectures!
We usually use “edge” to refer to the geographic distribution of computing nodes in a network of IoT devices that are at the “edge” of an enterprise. The “edge” could be a remote datacenter or maybe multiple geo-distributed factories, ships, oil plants, and so on.
Continue reading “IoT edge development and deployment with containers through OpenShift: Part 1”
This is the finale of a series on whether Kubernetes is the new Application Server. In this part I discuss the choice between Kubernetes, a traditional application server, and alternatives. Such alternatives can be referred to as “Just enough Application Server”, like Thorntail. There are several articles on Thorntail (previously known as Wildfly Swarm) on the Red Hat Developer blog. A good introduction to Thorntail is in the 2.2 product announcement.
Continue reading Curse you choices! Kubernetes or Application Servers? (Part 3)
Configuring Kubernetes is an exercise in defining objects in YAML files. While not required, it is nice to have an editor that can at least understand YAML, and it’s even better if it knows the Kubernetes language. Kubernetes YAML is descriptive and powerful. We love the modeling of the desired state in a declarative language. That said, if you are used to something simple like
podman run, the transition to YAML descriptions can be a bitter pill to swallow.
As the development of Podman has continued, we have had more discussions focused on developer use cases and developer workflows. These conversations are fueled by user feedback on our various principles, and it seems clear that the proliferation of container runtimes and technologies has some users scratching their heads. One of these recent conversations was centered around orchestration and specifically, local orchestration. Then Scott McCarty tossed out an idea: “What I would really like to do is help users get from Podman to orchestrating their containers with Kubernetes.” And just like that, the proverbial light bulb went on.
A recent pull request to libpod has started to deliver on that very idea. Read on to learn more.
Continue reading “Podman can now ease the transition to Kubernetes and CRI-O”
Developing Apache Camel and Red Hat Fuse applications inside VS Code is improving! In my previous articles, I’ve mentioned that Camel URI completion is available in VS Code for XML and Java DSL. By leveraging several VS Code extensions, it is now possible to have an end-to-end development experience. The Camel tooling currently available in VS Code is primarily targeting Spring Boot– based Camel applications. The tooling covers the development process from creating a Camel project, testing, and debugging it locally, to automatically-rebuilding and redeploying it on your local OpenShift/Kubernetes instance when you make changes.
There are several ways to leverage the VS Code tooling. I will show the process which I believe is the easiest one to get started with.
Continue reading “Using VS Code to develop Spring Boot-based Camel and Red Hat Fuse projects”