In this article, you will learn how to deploy a Nexus Server on a Kubernetes cluster using the Nexus Operator. We assume that you’re familiar with Kubernetes’ basic concepts.
Sonatype Nexus is a well-known artifact repository, especially among Java developers, for its capability to manage and serve libraries for Maven projects.
Deploying services like Nexus in containerized environments can be tricky and lead to many operational tasks, such as updating the service to the latest version or restore the service to its desired state in a new zone.
Kubernetes Operators are specialized applications acting as a human operator to do such tasks. There are many operators out there provided by the community to help developers and administrators run their applications. …
Update: the article now reflects the changes on Kogito 1.x release
The Kogito documentation states that “Kogito is a cloud-native business automation technology for building cloud-ready business applications”. In other words, a developer toolkit to create a custom business automation application targeting cloud environments.
Kogito enables a developer to have a business process integrated with complex business decisions and rules. This process is converted into a microservice that can be deployed on a containerized environment, such as Kubernetes.
In the following sections you’ll learn step by step how you can deploy a custom Kogito service in a Kubernetes cluster using the Kogito Operator. …
OpenShift has the EFK stack for handling aggregate logging. Aggregate logging refers to logs of the OpenShift internal services and containers where your application is deployed. Hence it’s very important to keep an eye on this service to make sure everything is working as intended. In this article I’ll show you an alternative approach for monitoring the ElasticSearch (ES).
On Openshift 3.11 Prometheus was introduced implementing the services exporters (HAProxy, ElasticSearch and etc.) from the standard OpenShift installation. This way an operator could have the OpenShift internal services monitored by Prometheus.
Prior to 3.11 the only way to monitor the internal ES service was querying the health API directly…
When working with Minishift, the default installation will configure a self-signed server certificate for the router with the
*.router.default.svc.cluster.local hostname. Applications exposed by secured routes then will use this certificate unless you change them to use a custom one.
Some applications that would access your pods through the exposed secure routes might fail to pass on TLS hostname verification. I faced this problem while connecting to Keycloak OAuth2 endpoints through a Spring Cloud Gateway application:
Caused by: java.security.cert.CertificateException: No subject alternative names present
This error occurred because the Keycloak URL was something like:
And the hostname added to the default certificate (
*.router.default.svc.cluster.local) didn’t match with it. …