Lately I have been creating and debugging container images without having the possibility to check the corresponding Dockerfiles. What I will show you today is how we can modify the behaviour of an OCI Image and swap blobs with others. We will start by modifying a Docker Image similar to the one that I have shown here: we will change the entrypoint and then gain confidence for the next activity; in fact we will then create an OCI Image and change a blob....
Today we have supply chain artifacts that we didn’t have the last year: gitbom, sbom, claims etc. Today is possible we produce an artifact and that will come with 3x non-deployable artifacts alongside. How do you store them? Do you make up your own storage service ? Do you need to take in account additional costs to run the infrastructure for the storage (and retrieval) of these artifacts? What about OCI registries?...
Here are some notes about how I run a Spring Boot application on Kubernetes. This is the 2nd part of a series of articles about Spring Boot applications on Kubernetes. You can find the 1st part here. Running a JVM based application on Kubernetes seems a pretty easy task but there are a lot of things to take in consideration: Application containerization Startup Graceful shutdown JVM & Resource limits Application containerization In order to containerize a Spring Boot application I leverage the (not so) new layering feature: this allows to create a Docker Layer for each part of our application:...
In this post I will show you how to send Kubernetes logs to multiple outputs by using Fluentd but first, let’s do a recap. On the previous post I wrote about using Fluentd and FluentBit; in particular, I showed you how to use FluentBit for log collecting and forwarding and Fluentd for pushing these logs to a destination: Opensearch. Since Opensearch at the time didn’t have a Fluentd plugin, we had to craft our Dockerfile tailored for our use case by installing Ruby Gems and by specifing the latest Elasticsearch gem compatible with Opensearch....
This is the first post of a series of articles about multi-tenant metrics with Prometheus Agent; here you will read how to enable Prometheus Agent mode and how to ingest metrics to a central Prometheus instance but also the limitations of this setup. Let’s say you’re managing 5 - 10 to n Kubernetes clusters (or hopefully Vclusters) for your tenants and you want to provide metrics to the developers: cpu usage, memory usage, custom metrics etc....
We set up our Vcluster but now we want to give proper access to the developers by leveraging their existing ldap credentials. The idea is to use DEX as a federated openid provider and kubelogin as a plugin for oidc integration. Scenario We’re going to achieve something like this: the user issues a command targeting our vcluster’s api server (kubectl get pods, for example), kubelogin will open the default browser on the user’s machine and display a login page....
With the consistent increasing of projects we were experiencing a huge growth of Kubernetes clusters for dev and test environments; each project had its own cluster with its stack: Nginx, Prometheus, Opa Gatekeeper etc. Moreover, each cluster had a different Kubernetes version with legacy clusters still pinned to the 1.15.x version. This meant we had to manage a different set of stacks (Prometheus, Nginx etc) since the skew between versions were too big....
We built CI/CD pipelines so far which have Docker images as output but how we make sure about the provenance of the workload we run on Kubernetes? How can be sure that the containers we are running are run from images built from our pipelines? One way to ensure trust with Docker images is to sign these images. We can sign them during our CI pipeline and then verify the signature at runtime when deploying....
This is a series. You can find part 1 here and part 2 here. On this last post I am going to cover the monitoring (with Prometheus and Grafana) for OpenSearch and Fluentd. FluentD If you recall from part-1, we set up a specific configuration for Prometheus in Fluentd main-fluentd-conf.yaml kind: ConfigMap apiVersion: v1 metadata: name: fluentd-es-config namespace: logging labels: addonmanager.kubernetes.io/mode: Reconcile data: fluent.conf: |-<source> type forward bind 0.0.0.0 port 32000 </source> [....
This is a series. You can find part 1 here and part 3 here. We were left on part-1 with a fully functional log pipeline. As I said, we’re going to check how to achieve a single shared index in OpenSearch. Shared Index If you recall, on the previous part we set a field on each document we were indexing in OpenSearch by leveraging the FluentD record_transformer plugin. main-fluentd-conf.yaml kind: ConfigMap apiVersion: v1 metadata: name: fluentd-es-config namespace: logging labels: addonmanager....