Red Hat Enterprise Linux (RHEL) 7.6 Beta was released a few days ago and one of the first new features I noticed is Podman. Podman complements Buildah and Skopeo by offering an experience similar to the Docker command line: allowing users to run standalone (non-orchestrated) containers. And Podman doesn’t require a daemon to run containers and pods, so we can easily say goodbye to big fat daemons.
Podman implements almost all the Docker CLI commands (apart from the ones related to Docker Swarm, of course). For container orchestration, I suggest you take a look at Kubernetes and Red Hat OpenShift.
Podman consists of just a single command to run on the command line. There are no daemons in the background doing stuff, and this means that Podman can be integrated into system services through
We’ll cover some real examples that show how easy it can be to transition from the Docker CLI to Podman.
Continue reading “Intro to Podman (Red Hat Enterprise Linux 7.6 Beta)”
If you aren’t following the OpenShift Blog, you might not be aware of the PodCTL podcast. It’s a free weekly tech podcast covering containers, kubernetes, and OpenShift hosted by Red Hat’s Brian Gracely (@bgracely) and Tyler Britten (@vmtyler). I’m reposting this episode here on the Red Hat Developer Blog because I think their realization is spot on—while early adopters might be deep into Kubernetes, many are just starting and could benefit from some insights.
The Kubernetes community now has 10 releases (2.5 yrs) of software and experience. We just finished KubeCon Copenhagen, OpenShift Commons Gathering, and Red Hat Summit and we heard lots of companies talk about their deployments and journeys. But many of them took a while (12–18) months to get to where they are today. This feels like the “early adopters” and we’re beginning to get to the “crossing the chasm” part of the market. So thought we’d discuss some of the basics, lessons learned, and other things people could use to “fast-track” what they need to be successful with Kubernetes.
The podcast will always be available on the Red Hat OpenShift blog (search: #PodCTL), as well as on RSS Feeds, iTunes, Google Play, Stitcher, TuneIn, and all your favorite podcast players.
Continue reading “A Beginner’s Guide to Kubernetes (PodCTL Podcast #38)”
[This article is cross-posted from the Eclipse Che Blog.]
Eclipse Che 6.6 Release Notes
Eclipse Che 6.6 is here! Since the release of Che 6.0, the community has added a number of new capabilities:
- Kubernetes support: Run Che on Kubernetes and deploy it using Helm.
- Hot server updates: Upgrade Che with zero downtime.
- C/C++ support: ClangD Language Server was added.
- Camel LS support: Apache Camel Language Server Protocol (LSP) support was added.
- <strong”>Eclipse Java Development Tools (JDT) Language Server (LS): Extended LS capabilities were added for Eclipse Che.
- Faster workspace loading: Images are pulled in parallel with the new UI.
Che is a cloud IDE and containerized workspace server. You can get started with Che by using the following links:
Continue reading “Eclipse Che 6.6 Release Notes”
This article shows how to take an existing Spring Boot standalone project that uses MySQL and deploy it on Red Hat OpenShift, In the process, we’ll create docker images which can be deployed to most container/cloud platforms. I’ll discuss creating a Dockerfile, pushing the container image to an OpenShift registry, and finally creating running pods with the Spring Boot app deployed.
To develop and test using OpenShift on my local machine, I used Red Hat Container Development Kit (CDK), which provides a single-node OpenShift cluster running in a Red Hat Enterprise Linux VM, based on minishift. You can run CDK on top of Windows, macOS, or Red Hat Enterprise Linux. For testing, I used Red Hat Enterprise Linux Workstation release 7.3. It should work on macOS too.
To create the Spring Boot app I used this article as a guide. I’m using an existing openshift/mysql-56-centos7 docker image to deploy MySQL to OpenShift.
Continue reading “Deploying a Spring Boot App with MySQL on OpenShift”
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.
Continue reading “Introducing conu – Scripting Containers Made Easier”
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.
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
- Image Layer
- Base Image
- Platform Image
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.
Continue reading “A Practical Introduction to Container Terminology”
If you are like me, you probably prefer to install new and exploratory software in a fresh virtual machine (VM) or container to insulate your laptop/desktop from software pollution (TM). Red Hat Container Development Kit (CDK) relies on virtualization to create a Red Hat Enterprise Linux (RHEL) virtual machine to run OpenShift (based on Kubernetes). Red Hat specifically supports installation of the CDK on Windows, macOS, and RHEL Server, but if you are running Fedora, RHEL Workstation, or even CentOS, you will run into trouble. If you are not running a supported desktop, you can always use a RHEL Server virtual machine, and this tutorial is for you.
Continue reading “Red Hat Container Development Kit (CDK) With Nested KVM”
Last week, Red Hat was present at the SnowCamp conference in Grenoble, France. The SnowCamp is a technical conference that includes a unique combination of deep dive sessions (universities), technical talks, and a final day on the ski slopes. With around 400 attendees and 70 sessions, this third edition of the SnowCamp was a great opportunity to meet the developers from the Grenoble area, in the most innovative city in the world (Source: Forbes and Mashable). Red Hatters presented 2 universities and 7 talks covering many projects and products, such as OpenShift, Infinispan, Monitoring, and Containers.
Let’s have a look to them.
Continue reading SnowCamp 2018 Trip Report
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.
Micro database schema evolution patterns are perfectly described by Edson Yanaga in his brilliant free book: Migrating to Microservice Databases: From Relational Monolith to Distributed Data. A video presentation of these patterns is also available on youtube.
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.
- A future post will showcase application migration patterns, including database migration stages using OpenShift Jenkins2 pipelines.
Continue reading “Containerizing SQL DB changes with Flyway, Kubernetes, and OpenShift”
Container images usually come with pre-defined tools or services with minimal or limited possibilities of further configuration. This brought us into a way of thinking of how to provide images that contain reasonable default settings but are, at the same time, easy to extend. And to make it more fun, this would be possible to achieve both on a single Linux host and in an orchestrated OpenShift environment.
Source-to-image (S2I) has been introduced three years ago to allow developers to build containerized applications by simply providing source code as an input. So why couldn’t we use it to make configuration files as an input instead? We can, of course!
Continue reading “Flexible Images or Using S2I for Image Configuration”