ConSol is an IT consulting company. Enthusiasm for coding and hacking is what unites us. ConSol Labs is a technical playing field where we can share our Open Source involvement. We use this site to blog about our area of personal interest, from the daily business at work and from our spare time projects.
The first version of RabbitMQ has been released in 2007. Back in these days, the goal was to provide a complete open source implementation of Advanced Message Queuing Protocol (AMQP), aiming at modern messaging needs such as high availability, high performance, scalability and security.
Nowadays, RabbitMQ is one of the most popular message brokers and can be found in several domains.
This article lights up core concepts and compares it with ActiveMQ Artemis and AWS SQS.
Last summer I watched the Red Hat master course about Kafka from Sébastien Blanc. The Kafka setup in Kubernetes presented in the course looked pretty easy. The Kafka client implementation for Java seemed to be easy as well. Furthermore, I wanted to use Kafka for a long time, so I got the idea to extend my Istio example. Each time a service is called, a message is sent to a topic. The service (implemented in Quarkus), as well as the Kafka cluster should be in an Istio Service Mesh and secured with mTLS. I found descriptions of Joel Takvorian that Kafka works with Istio, so I knew (or at least hoped) that my plan should work.
This article will describe the overall architecture of the example and which obstacles I encountered during deployment.
AWS Comprehend is a great tool when you want to extract information from textual data. As a managed service it is really easy to setup and can be used with next to no prior knowledge of machine learning. But there is one minor thing that bugs me about Comprehend: The Output.
TL;TR output.tar.gz bad, flat json file good.
See python code below for transformation.
Automatic integration tests as part of the development life cycle can save a lot of time and money. Not only when dealing with other service APIs or offering some, also if the application uses a database or other infrastructure services.
We at Consol made a lot of good experience to develop the integration tests as part of the life cycle from the beginning of a project. Therefor the Citrus framework is often a good choice to do it automated.
But there are other frameworks and libraries which can be useful. In this article, we’ll have a look at Testcontainers. By using a sample microservice, we will show how Testcontainers can be used and what chances it provides.
So you have this nifty web application deployed on your OpenShift cluster and you want to make it accessible by the whole world with HTTPS under the name
coolapp.<mydomain>. Unfortunately you face several issues:
Exposing the service to your web application leaves you with a route using the self-signed certificate that was generated during setup of the cluster. None of the browsers in the wild will trust this certificate.
The self-signed certificate dictates URLS of the form
https://<appname>.apps.<clustername>.<mydomain> (or whatever domain suffix you configured). Not very nice.
You might mitigate the previous issues by getting an official certificate signed by a generally trusted institution. But you will have to pay for it.
And you will have to pay for it not only once but every year (latest every 389 days) thanks to recently tightened certificate policies installed by all major browser vendors.
Worst of it all: You must not (by any means) forget to apply for a new certificate in a timely manner and replace the certificate in your route before the old expires. Otherwise some people might get pretty angry about you.
Let’s Encrypt to the rescue!
During a discussion with a customer, we talked about which steps are necessary to add an application to a services mesh. Which should be no big deal. Unfortunately, there is not a simple guideline how to do that for the Red Hat OpenShift Service Mesh. Furthermore, I was not sure how the requests for the application would look like in Jaeger. To clarify these points, I created a small application. Which I then deployed on OpenShift and added it to a service mesh control plane. This is the documentation of the steps that I have done.
During this year’s Red Hat Summit I had the chance to get a glimpse of the latest version of Kiali. This version had some nice features, like the traffic flow of the application graph during a time period (Graph replay). It also contains wizards to create destination rules and virtual services. This demo has struck my curiosity to get the hands on this Kiali version. One obstacle for me was that my Kiali is running in Red Hat OpenShift Service Mesh and is controlled by the Kiali operator. Currently, it is using version 1.12. The version that I wanted to try was the latest release version (1.17). The Red Hat OpenShift Service Mesh does not support this version. This article describes what we need to do in order to replace the Kiali version of an Red Hat OpenShift Service Mesh with the latest version of Kiali.
Some time ago, I did a webinar about the RedHat Service Mesh, which is based on Istio. For this webinar, I prepared a demo application. Among other things, I wanted to show how to do the authentication with JWT token in general and, more specific, with Keycloak. This article will describe how to configure Keycloak. In the second article, I will show you what problems I encountered running the application in Istio and how I figured out what was wrong in my configuration. You can find the article here
In the article, I’m going to describe what we can do, if we configured our application to use Istio, but it is not working like intended. Originally, I wanted to give a detailed description what problems I encountered during the creation of my webinar and how I fixed them. However, I came to a point where this would be a very long one. I hope that you don’t mind that I shortened it and just describe which tools are available to
debug the Istio configuration. In my previous article I described how to configure Keycloak for my webinar. So without further ado, let’s start.
In this article, I will show you how to install Red Hat OpenShift Container Platform 4.3 (OCP) on VMware vSphere with static IPs addresses using the openshift installer in UPI mode and terraform. In contrast to the official OpenShift 4.3 install documentation, we will not use DHCP for the nodes and will not setup the nodes manually - instead we will use static IP addresses and terraform to setup the virtual machines in our vCenter.