Category: Containers

OpenShift and Kubernetes do a great job of working to make sure calls to your microservice are routed to the correct pods. After all, that’s one of the raison d’être for Kubernetes: routing and load balancing. What if, however, you want to customize the routing? What if you want to run two versions at the same time? How do Istio Route Rules handle this?

Node.js is based on the V8 JavaScript engine and allows you to write server-side JavaScript applications. Node.js joins the existing set of supported runtimes and offers developers an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

There has been a need for a simple, easy-to-use handler for writing tests and other code around containers that would implement helpful methods and utilities. For this we introduce conu, a low-level Python library.

This project has been driven from the start by the requirements of container maintainers and testers. In addition to basic image and container management methods, it provides other often used functions, such as container mount, shortcut methods for getting an IP address, exposed ports, logs, name, image extending using source-to-image, and many others.

One of the key metrics or performance indicator of a microservices software architecture and environment is lead time (the amount of time it takes to get from idea to production). Many things have an impact on lead time, such as decision-making time, how quickly the code can be implemented, testing, continuous integration, etc.

You might think containers seem like a pretty straightforward concept, so why do I need to read about container terminology? In my work as a container technology evangelist, I’ve encountered misuse of container terminology that causes people to stumble on the road to mastering containers. Terms like containers and images are used interchangeably, but there are important conceptual differences. In the world of containers, repository has a different meaning than what you’d expect. Additionally, the landscape for container technologies is larger than just docker. Without a good handle on the terminology, It can be difficult to grasp the key differences between docker and (pick your favorites, CRI-O, rkt, lxc/lxd) or understand what the Open Container Initiative is doing to standardize container technology.

Background

It is deceptively simple to get started with Linux Containers. It takes only a few minutes to install a container engine like docker and run your first commands. Within another few minutes, you are building your first container image and sharing it. Next, you begin the familiar process of architecting a production-like container environment, and have the epiphany that it’s necessary to understand a lot of terminology and technology behind the scenes. Worse, many of the following terms are used interchangeably… often causing quite a bit of confusion for newcomers.

Container

Image

Container Image

Image Layer

Registry

Repository

Tag

Base Image

Platform Image

Layer

Understanding the terminology laid out in this technical dictionary will provide you a deeper understanding of the underlying technologies. This will help you and your teams speak the same language and also provide insight into how to better architect your container environment for the goals you have. As an industry and wider community, this deeper understanding will enable us to build new architectures and solutions. Note, this technical dictionary assumes that the reader already has an understanding of how to run containers. If you need a primer, try starting with A Practical Introduction to Docker Containers on the Red Hat Developer Blog.

Red Hat now supports Microsoft SQL Server running on RHEL Server. However, Red Hat doesn’t provide an official docker image for MS SQL Server on RHEL. This post explains how to create a docker image for MS SQL Server on RHEL and run it on Red Hat OpenShift.

In DevOps projects, you are sometimes haunted by the practices inherited from the monolithic world. In a previous project, we were checking how to simply apply SQL updates and changes to a relational database management system (RDBMS) database in an OpenShift Cluster.

In this blog post series we will show a simple approach to implement the described patterns in your Continuous Integration and Continuous Delivery (CI/CD) pipelines on OpenShift. The series is split in two parts:

This post shows how to handle SQL update automation using Flyway, Dockerfiles, and Kubernetes on OpenShift.