containers

KeyDB is a multithreading, drop-in alternative to Redis. The Keydb-operator can easily create either a standalone instance (1 replica) or a multimaster setup (3 replicas) of the KeyDB in-memory database. When KeyDB is in multimaster mode, it is possible to have more than one master, allowing for read/write operations across all of them. This capability enhances high availability and fault tolerance. This operator is part of the Kubernetes operators and tools developed by Krestomatio, a managed service for Moodle™ instances [Read More]

NFS Operator creates NFSv4 ganesha servers in Kubernetes, allowing to set ownership/permissions of their NFS export directory; to autoexpand their PVC; and to enable RWX storage from them: It can set ownership and permissions for export parent directory of the (NFS) Ganesha server. It is able to expand/adjust the PVC size of the (NFS) Ganesha server automatically, as it grows. It could autogenerate an StorageClass that uses the (NFS) Ganesha server for RWX storage. [Read More]

Now that Rocky Linux is GA, here is a repo for a minimal container image for Rocky Linux. Its size is around ~37 MB (compressed). It is based on Fedora Minimal and UBI8 minimal from Red Hat. You can download it from Quay or build it, following the instructions in the repo. You could also generate a new rootfs yourself before building the image, again, following the short instructions in the repo. [Read More]

Is there something easy when deploying and configuring the database layer? Aspects of Data integrity and reliable/safe operations add up to complexity, which only increases when tradicional SQL, high availability, fault tolerance, scalability and high levels of concurrency, are required. It is a sensitive layer, no doubt. Consequently, if there is something easy there, it would be to screw everything up. Do not fear, go test, screw up and learn. I mean, just not in production. [Read More]

I have heard about podman (Pod Manager tool) more and more often now. Whether it is that I have come closer to its developing environment or that it has come to mine, I’m not sure. It’s both, I guess. I use Ansible a lot for automating baremetal and virtual infrastructure: for its definition, deployment, configuration, operation, among other things. In the recent years, I have being using more and more containers, particularly in the developing stages. [Read More]

Many systems are deployed in a multienvironment context, for example: production, stage, and dev. These environments often share variables and artifacts. In Ansible, there are different methods to work in this context. For example, separate directory layout and soft links. However, it can end with a considerable amount of data and duplicate files between environments, exposing variables to all hosts or adding much more complexity to playbooks. Demo multienv tests a stackable multienvironment directory layout for Ansible, using multienv Ansible role. [Read More]