DEV Community: Philip Miglinci

Glasskube is now part of the CNCF Landscape

Philip Miglinci — Thu, 08 Feb 2024 17:12:53 +0000

🧊 Glasskube is the missing Package Manager for Kubernetes 📦

Featuring a GUI and a CLI. Glasskube packages are dependency aware, GitOps ready and can get automatic updates via a central public package repository.

Support us by leaving a star on GitHub: ⭐ glasskube/glasskube ⭐

We got accepted into the CNCF Landscape

Glasskube is now visible next other relevant projects in the cloud native ecosystem landscape like Helm or Backstage.

The goal of the cloud-native landscape is to gather and categorize projects that are relevant to the cloud native developers,
offering a comprehensive overview of the existing ecosystem.

By exploring this landscape, project teams can make informed decisions about tooling, technology stack selection, and best practices.
Moreover, it facilitates access to emerging innovations, fosters community collaboration, and ensures compatibility and interoperability,
all of which are critical for the success of Kubernetes deployments.

Glasskube is part of the Application Definition & Image Build category

Application definition and image build tools encompass developer-focused and operations-focused functionalities,
aiming to simplify Kubernetes deployment and app management.
They address challenges of complexity in containerized environments, offering solutions for reproducible image creation,
standardized app deployment, and simplifying developer and operator experiences. Tools include Helm for deploying third-party apps,
the Operator Framework for building and deploying operators, and Cloud Native Buildpacks for containerizing application code.
These tools help streamline Kubernetes development and operations, offering diverse solutions for various use cases.

Accepted in just 7 days after the launch

The pull request #3735 got accepted just 7 days after the released of our first technical preview of Glasskube.

Glasskube was accepted into the CNCF landscape category due to its ability to effectively address the critical challenges
within application definition and image build, underscoring its importance in streamlining Package Management on Kubernetes.

View Glasskube in the CNCF Landscape

Glasskubes entry in the CNCF landscape

Try out Glasskube yourself

You can already get your hands on Glasskube and install the first available packages.
You can find the correct installation instruction for your operating system: https://glasskube.dev/docs/getting-started/install/

Get involved

The easiest way to get involved is to tackle one of our open issues.
You are also welcome to join our Discord.

If you are a cloud native developer, please submit your package.

As Glasskube is still in its very early days, your feedback is highly appreciated.

Let us know what you think, we would love to hear from you or support us by leaving a star:

⭐ glasskube/glasskube ⭐

Introducing Glasskube🧊 — The Missing Package Manager For Kubernetes 📦

Philip Miglinci — Fri, 02 Feb 2024 10:19:10 +0000

The aim of this post is to share our technical preview of how a cloud native package manager could work and what challenges need to be solved.

Glasskube is fully open-source. Support us by leaving a star: ⭐ glasskube/glasskube ⭐

We Want Your Feedback! 🫶

Share your thoughts in the comments below! Let us know what topics you'd like more content on. If this guide helps, click on the cat and leave a star to support us in creating more developer-centric content. Your feedback matters!

Introducing Glasskube — The Missing Package Manager For Kubernetes

Package Management on Kubernetes is one of the most pressing issues in the Cloud Native community. A concept which is widely known from other ecosystems like desktop and mobile computing has yet not been realized for cloud computing. For example on Android and iOS, millions of developers publish their packages in the Play Store or App Store to reach their users.

The package manager also makes sure all users receive the latest version published by the developer and the developer receives crash reports and user feedback as a return to improve their applications, but as a cloud native developer there is no package manager you can rely on — yet.

Our first release (v0.0.1) already features a working prototype that can install basic packages, but a lot of challenges still need to be solved.

A cloud native architecture

Glasskube itself is designed as a cloud native application. Featuring an easy to install client that comes with a graphical user interface and autocompletion for your favorite shell.

At the heart of the Glasskube package ecosystem lies our central package registry which holds the package manifests. In a future version we also plan to support 3rd party registries and the possibility to use multiple registries in a cluster.

The Glasskube package operator syncs the latest manifest into the cluster and makes sure it will be updated as soon as a new manifest is available.

Challenges that need to be solved

We already covered some our upcoming features in our public roadmap, but I would also like to take this opportunity to shortly speak about broader challenges.

Kubernetes version compatibility

Kubernetes releases minor versions every 4 months, which often come with new API versions. Package authors need to adapt their packages to these changes. In Kubernetes, a particular release might include more than one API version of a resource, so that packages can be compatible with a broader range of Kubernetes versions.

These compatible versions are often only documented in the package distributors' changelog. Glasskube aims to incorporate this kind of metadata in combination with automatic checks from tools like kube-no-trouble or Pluto.

The user should not be required to drudgingly check all packages for compatibility and package developers should get feedback if their package is not compatible with the latest API versions.

Package dependencies

Cloud native applications often interoperate and there are some packages that can be found in almost every Kubernetes cluster. For example: cert-manager, Ingress controllers or database operators. Due to the lack of a package manager and ecosystem these dependencies are still often only documented in the Getting started section of an application.

In an ideal world a package author could simply specify a dependency of their package and the package manager ensures that all these prerequisites are fulfilled.

Testing

In order to support multiple Kubernetes versions, dependencies and packages Glasskube needs to build massive automated testing infrastructure for all packages in its central package registry.

Feedback and package quality

As seen in other package managers like the arch user repository or the Play Store and App Store users' feedback and reviews help other users to decide between different packages. Also, application developer will incorporate users' feedback to gain popularity and better ratings in the package manager.

Glasskube and Helm

Glasskube is no replacement for Helm. Helm has its strengths in configuring releases through templating and having the ability to perform upgrades and rollbacks.

Glasskube is laser focused on the administrator who needs to only install and kustomize (pun intended 😉) a single application, but who also needs to make sure multiple
packages are kept up-to-date and secure throughout multiple Kubernetes version upgrades and adapting to inevitable breaking changes.

Getting started

Follow our Getting Started guide if you want to try Glasskube for yourself and install your first package.

Release Notes

All release notes can be found on GitHub: https://github.com/glasskube/glasskube/releases/tag/v0.0.1

Get involved

The easiest way to get involved is to tackle one of our open issues.
You are also welcome to join our Discord.

If you are a cloud native developer, please submit your package.

As Glasskube is still in its very early days, your feedback is highly appreciated.
Let us know what you think, we would love to hear from you.

Star Glasskube:

`glasskube/glasskube`

🔥 Kubernetes Enterprise: Rancher vs OpenShift vs Tanzu - Features, Evaluation & Comparison ✅

Philip Miglinci — Wed, 10 Jan 2024 12:53:18 +0000

TL;DR 🔍

The article provides an introduction to enterprise Kubernetes solutions, focusing on Rancher, OpenShift, and VMware Tanzu.

Rancher is praised for its multi-cluster management, supporting various Kubernetes distributions.

OpenShift extends Kubernetes with enterprise features but requires a subscription.

VMware Tanzu specializes in centralized management across clusters and clouds.

The comparison emphasizes deployment and management capabilities, security features, and operational complexities.

Each platform's ecosystem, integrations, and potential vendor lock-in are discussed.

Organizations are advised to align their choice with specific needs and DevOps workflows, considering factors like deployment strategies, day-to-day management, and potential vendor lock-in.

The article concludes by highlighting key offerings from each platform, urging hands-on experience for a comprehensive evaluation.

We Want Your Feedback! 🫶

Introduction to Enterprise Kubernetes Solutions

Kubernetes is now recognized as the main standard for container orchestration, playing a critical role in automating container management. Enterprises selecting a Kubernetes platform must consider their unique requirements to empower their DevOps and Kubernetes developers. Let's explore the features of Rancher, OpenShift, and VMware Tanzu in the context of container orchestration and management.

Rancher: A Kubernetes management platform acclaimed for multi-cluster management (Rancher vs. OpenShift). It supports a variety of Kubernetes distributions, like RKE and K3s. Rancher simplifies managing multiple Kubernetes clusters, which is key for orchestrating a single application across various clusters. (SpectroCloud)
OpenShift: Extends Kubernetes, offering additional enterprise features like developer tools, an integrated container registry, and advanced security. It does require a subscription for full functionality (OpenShift Pricing, Red Hat OpenShift).
VMware Tanzu: Specializes in delivering a single control point for managing applications across multiple clusters and clouds. It provides cluster lifecycle management, diagnostics, and data protection (VMware Tanzu Mission Control).

The effectiveness of Kubernetes can partially be measured through specific metrics like CPU usage, memory usage, network traffic, and disk usage (Aqua Security).

In terms of security, best practices include enabling Kubernetes Role-Based Access Control (RBAC), using third-party authentication, protecting etcd with TLS, firewall, and encryption (Aqua Security).

Regarding market share and adoption, Kubernetes boasts 92% of the market among container orchestration tools, with over half of Fortune 100 companies and 78% of SMEs using it (Humalect).

Rancher's capabilities in multi-cluster management do not currently have a quantitative comparison in terms of the number of supported clusters or operational efficiency metrics (Rancher Docs).

When looking at enterprise subscription costs for OpenShift, you'll find various options with different features and price points, such as the Red Hat OpenShift Container Platform and additional features like OpenShift Data Foundation Essentials and Red Hat Quay (Red Hat Subscription Guide).

Community and official support for Rancher, OpenShift, and Tanzu offer a range of options, with varying response times and satisfaction rates based mainly on user experiences (Kubevious).

In conclusion, whether you prefer Rancher's multi-cluster flexibility, OpenShift's enterprise-oriented features, or Tanzu's centralized management approach, your choice will align with your organization's container management strategies and objectives.

Key Features of Rancher, OpenShift, and Tanzu

In the dynamic realm of Kubernetes management, the comparison of Rancher vs OpenShift offers a glimpse into diverse strategies catering to multi-cloud environments. Rancher has firmly established itself with a strong feature set that includes centralized authentication and access control, easily deploying and securing clusters consistently across any location. Notable unique capabilities of Rancher include:

Infrastructure orchestration across various environments.
Enhanced container orchestration via Kubernetes integration.
Comprehensive application catalog with Helm charts and templates.
The unified multi-cluster management interface for consistent cluster deployment.
Its offerings, such as RKE and K3s, do not necessitate a SUSE subscription for use.

For users with a SUSE subscription, additional benefits are accessible, such as priority support and regular security patches. Rancher Capabilities and SUSE Subscription Benefits

Red Hat OpenShift is distinguished for its integrated approach towards hybrid multi-cloud deployments and edge environments. It emphasizes automation, scalability, security, and developer experience, offering:

Support for hybrid, multi-cloud, and edge architectures.
Streamlined processes with tool integrations.
Enhanced developer tools for an improved user experience.
Scalable application deployment and management.
Automated installations and upgrades across varied cloud environments.
Inherent security features for cloud applications.

OpenShift adapts Kubernetes for enterprise-ready deployments in a hybrid multi-cloud strategy. OpenShift Hybrid Multi-Cloud Integration

In parallel, VMware Tanzu Mission Control equips IT teams with flexible control for Kubernetes management. Tanzu Mission Control is designed to simplify and unify cluster lifecycle management and policy governance across multiple clouds, ensuring strong Kubernetes architecture governance with features such as unified policy management, templating, resource grouping, and centralized access management. These capabilities are pivotal for organizations prioritizing strong governance of their Kubernetes setup. VMware Tanzu Mission Control Governance Features

Comparing Deployment and Management Capabilities

DevOps engineers comparing Rancher, OpenShift, and Tanzu encounter distinct feature sets that influence DevOps workflows for Kubernetes deployment and management. Here's how these platforms match up:

Rancher:
- Provides multi-cluster management enhancing multitenancy support.
- Simplifies container deployment processes, crucial for teams operating containers in production.
- Features a significant user base, indicative of its ease of deployment and management (Rancher's popularity).

Specific management features that contribute to Rancher's popularity include:

Simplified cluster management, access control, and application deployment.
Integration with Helm for predefined app templates.
Single dashboard management for all Kubernetes clusters.
Advanced security features and built-in tools for managing multitenancy (Rancher vs. OpenShift).
- OpenShift:
Integrates Kubernetes orchestration with developer tools in a hybrid cloud environment.
Offers an automated, cohesive platform designed to enhance scalability and automate operations.
Provides additional features over Kubernetes for improved scalability, flexibility, developer experience, and automated upgrades (OpenShift features).

OpenShift's security features stand out with:

Robust RBAC capabilities and secure execution policies.
Compliance tools woven into the platform (Comparison of Security Policies).

Automated operations that align with modern DevOps practices include:

Streamlining deployments via automated installation.
Enhancing security with integrated monitoring.
Facilitating CI/CD processes for swift development to production transitions (Automated Operations in OpenShift).
- VMware Tanzu:
Supports cluster operations including creation, deletion, resizing, and upgrades.
Prioritizes operational resilience with robust data protection capabilities (Tanzu’s data protection).

Cluster lifecycle management in Tanzu caters to different cloud providers with:
Custom features for AWS, Azure, and vSphere.
Global cluster management across multiple cloud environments (Cluster Lifecycle Management Features).

To orchestrate containers efficiently in a hybrid cloud, each platform brings its strengths to the table:

Rancher: Known for its user-friendly interface and extended multitenancy support, making it a top choice for container management (Rancher Management Features).
OpenShift: Stands out for integrated CI/CD pipelines, security enhancements, and a web console for application management. It simplifies both architecture and DevOps operations (Why OpenShift is better than Kubernetes).
VMware Tanzu: Focuses on managing the cluster lifecycle, ensuring data protection and flexibility across cloud providers (Tanzu VMware).

To illustrate their direct impact on operational choices, the automation and multitenancy of OpenShift play a pivotal role in enhancing productivity and security within DevOps practices. In contrast, Rancher is often chosen for its simplicity and powerful management of multitenant Kubernetes environments. Meanwhile, VMware Tanzu's approach to hybrid clouds and its container orchestration appeal by optimizing lifecycle operations for diverse cloud infrastructures (Tanzu vs. OpenShift).

To facilitate efficient container orchestration and deployment, while ensuring robust multitenancy and hybrid cloud compatibility, teams should consider the nuanced differences in DevOps workflows offered by each of these platforms.

Evaluating Ecosystems and Integrations

When considering Kubernetes management solutions, it is key to compare the ecosystems of various platforms like Red Hat OpenShift, Rancher, and VMware Tanzu. Each offers a different approach to integration, flexibility, and potential vendor lock-in.

Red Hat OpenShift

Red Hat OpenShift is a comprehensive container platform that enhances Kubernetes functionalities.
It is powered by OKD, the Open Source community distribution Kubernetes.
OpenShift provides scalability, flexibility, and adherence to open-source standards, which are essential for many enterprise-grade applications (Red Hat OpenShift Features).
Notable benefits include built-in security, automated installation, and enhanced developer experiences, along with an integrated open-source community (OpenShift Benefits).

Key open source community projects enhancing OpenShift's ecosystem include:

Kubernetes for container orchestration.
Tekton that provides CI/CD pipelines automation.
OperatorHub delivering pre-configured applications.
OKD (OpenShift Origin) as the foundational upstream project.
OCI containers enabling industry-standard image portability.
Certification by the CNCF for Kubernetes compatibility (Community Projects).

Rancher vs OpenShift

The Rancher platform prioritizes reducing lock-in with its cluster manager, which supports CNCF-certified clusters from various infrastructures.
Rancher's host operating system support is broader than OpenShift's, which mainly focuses on Red Hat-based systems like RHEL, CentOS, or Fedora, enhancing interoperability and user choice (Rancher vs OpenShift).

VMware Tanzu

VMware Tanzu is renowned for its versatility, allowing for multi-cluster management across different clouds, giving administrators the power to create, delete, resize, and upgrade clusters with ease.
Tanzu's management capabilities dramatically improve resilience and scalability, two metrics that are quantitatively beneficial compared to industry standards.

Metric	Tanzu Impact
Resilience	Increases with centralized management for multi-cloud provider clusters
Scalability	Streamlined with efficient provisioning and lifecycle management capabilities

(Source: Tanzu Mission Control)

In summary, each platform has its unique set of partnerships and third-party support integral to the ecosystem which determines the ease of workflow integration, tool availability, and future scalability. The value derived from these platforms grows as support and partnerships within their ecosystems expand, maintaining the agility required for modern cloud computing.

Operational Complexity and Vendor Lock-in

When selecting a Kubernetes management platform, it's crucial for DevOps teams to balance the ease of use with concerns about vendor lock-in. A comparison between Rancher and OpenShift illustrates this point clearly. Rancher offers an open and flexible approach to Kubernetes, enabling workflows with RKE and K3s that don't require a SUSE subscription, thus simplifying DevOps workflows and reducing lock-in risks (Rancher vs. OpenShift: The Guide).

In contrast, OpenShift from Red Hat offers a more integrated ecosystem, which could lead to vendor lock-in, especially when utilizing their subscription services. OpenShift simplifies development workflows with features like S2I, allowing developers to create containerized applications efficiently (Compare Rancher vs OpenShift). For businesses deeply embedded within the Red Hat infrastructure, the benefits of this integration may outweigh lock-in concerns.

VMware Tanzu provides a suite that includes several multi-cloud management features. With tools like Tanzu Kubernetes Grid and Mission Control, Tanzu offers a moderate level of complexity alongside consistent management across cloud and on-premises setups (TechTarget - Compare Rancher vs. OpenShift vs. Tanzu). However, this portfolio may lead to a dependence on VMware's infrastructure, representing a potential lock-in scenario.

A comparative analysis outlines how operational complexity and the threat of vendor lock-in significantly influence enterprise decisions. To circumvent lock-in, organizations might use open-source tools, steer clear of proprietary APIs, or choose platforms fostering infrastructure portability.

Adopting a multi-cloud strategy serves as a key method for mitigating vendor lock-in risks while capitalizing on these platforms' operational efficiency. Multicloud Kubernetes usage allows running clusters across different public and private clouds, offering true portability and avoiding reliance on a single provider (What is Kubernetes hybrid cloud multi-cloud?). Assessing trade-offs on each platform leads to maintaining simplicity and reducing dependence on a single provider.

To offer insights into the technical demands and complexities of implementing Kubernetes platforms like Rancher, OpenShift, and Tanzu, here's a comparative table:

Platform	Technical Requirements	Complexity
Rancher	- Role-based access control (RBAC) - Multi-tenancy support - Cluster isolation capabilities - Secure secret management - Support for standard operating systems - Rancher UI and CLI for management	Moderate
OpenShift	- RBAC policies - Built-in CI/CD workflows - Integration with Red Hat security tools - Provisioning on various clouds - Full installer for deployment - Integration with different Red Hat tools	Complex
Tanzu	- High availability across environments - Tanzu Kubernetes Grid for management - Support for running on vSphere and bare-metal - Consistent management across all infrastructures	Moderate

Source: TechTarget - Compare Rancher vs. OpenShift vs. Tanzu

Furthermore, notable enterprises are deploying multi-cloud strategies to avoid vendor lock-in. For example, OpenShift provides pre-configured tools for a variety of deployment models, while VMware Tanzu TKGI incorporates a range of technologies for flexible Kubernetes management (Avoiding cloud lock-in).

In conclusion, evaluating each Kubernetes platform in light of your organization’s unique DevOps workflows and your stance on vendor lock-in will lead to a solution that offers agility without undue constraint.

Conclusion: Choosing the Right Enterprise Kubernetes Platform

In selecting the right enterprise Kubernetes platform, it's essential to align with the specific needs of your enterprise, as this choice significantly impacts DevOps workflows. Let's delve into how this decision affects various aspects:

Deployment: The chosen platform dictates the deployment strategies.
Management: Day-to-day operations hinge on the platform's ease of use.
Vendor Lock-in: Opting for fully integrated ecosystems may limit flexibility.

Exploring key offerings from prominent players in the market:

VMware Tanzu: A standout for enterprises seeking comprehensive multi-cloud management and enterprise support, VMware Tanzu offers robust capabilities, including advanced monitoring, observability, and enhanced enterprise security features (Compare Rancher Labs vs VMware Tanzu Mission Control). Tanzu is a suite of services that extends Kubernetes with new tools for maintaining cloud-native apps and additional management capabilities across clouds and data centers Cyfuture Blog: Is Tanzu the Same as Kubernetes?].
Rancher: Flexible and adaptable, Rancher excels as a Kubernetes cluster manager. It allows enterprises to implement centralized authentication, enterprise security, and even integrate non-standard solutions, making it suitable for a diversified IT infrastructure (Rancher vs. Openshift: The Guide). Rancher extends Kubernetes by allowing efficient management of multiple Kubernetes clusters Dsstream: Kubernetes vs. Rancher or Kubernetes and Rancher?.
OpenShift: OpenShift presents an integrated ecosystem designed for developers. While it can lead to a higher likelihood of vendor lock-in, it also provides a strong set of tools for consistent application delivery across various platforms. OpenShift offers a container platform that is more secure by default and is designed to be enterprise-ready Dynatrace Blog: OpenShift vs. Kubernetes.

When selecting a platform, avoid the complexity and potential constraints by consulting a detailed comparison guide to understand key considerations (WP-Buyer's Guide to Enterprise Kubernetes Solutions). To truly determine a platform's suitability, nothing beats hands-on experience. DevOps teams should engage in trials and testing to ensure their operational needs align with the platform's offerings.

Star Glasskube:

`glasskube/glasskube`

🔥Matomo 5 UPGRADE - A step-by-step GUIDE 🤌

Philip Miglinci — Thu, 04 Jan 2024 12:40:27 +0000

TL;DR 🔍

Matomo just released their major v5 upgrade with following key improvements:

A transition to the frontend framework Vue.js which most notably brings a fresh new icon set
Improved query performance for faster reports
Support the latest PHP version including 8.1, 8.2 and 8.3

In total the Matomo team and contributors closed 270 tickets. All changes can be found in this diff from "Fossies".

But Upgrading Matomo - especially in a containerized environment - can be quite challenging.
We recently implemented Matomo 5 support into Glasskube and are happy to share our learnings.

We already wrote a guide about Installing Matomo on Kubernetes. This guide takes care about how to upgrade Matomo.

We Want Your Feedback! 🫶

Matomo upgrade methods

One-Click Matomo Update (Auto Update)

If Matomo is installed and operated on a single VM Matomos auto update feature can be used and the update can be triggered via the user interface. After the initial upgrade also a database migration can be performed via the UI.
Make sure to update the file permissions before starting the upgrade and revert these permission after the successful upgrade.

If Matomo is installed via Docker or in a Kubernetes cluster the update process might be a little more tricky.

Matomo Docker Upgrade

After switching to the latest Docker image make sure to use the docker exec command to open a shell inside the container and execute ./console core:update. This will start the upgrade process for a Docker based deployment.

Matomo upgrade dependencies

When upgrading Matomo it is always important to make sure that dependencies are also up-to-date. Matomo recommends the latest PHP 8.x release to improve memory efficiency and benefit from the latest security improvements.
Also, the latest version of a MySQL or MariaDB is highly recommended to increase upgrade speed by supporting index renaming and many more features.
In addition to the runtime and database it is also recommended to keep the webserver (Apache2 or NGINX) up to date - and of course all other packages and operating system itself.

When running Matomo in a dockerized environment, virtualization takes care about the runtime dependencies as the latest matomo image is based upon the php:8.2-apache base image.

Matomo upgrade errors and resolutions

After upgrading Matomo different errors can occur that need immediate resolution as your Matomo instance might not be available at the moment.

Matomo upgrade failed: File integrity check failed

The file integrity check can either be a warning inside the system check section of Matomo itself or can lead to more severe errors like Matomo not starting or throwing different Exceptions.

The root cause of this issue is that Matomo doesn't work if other files are in the working directory. If a new release of Matomo was just copied into the Matomo working directory without deleting the old files this error might occur.
The Matomo docker image uses following entrypoint script to overwrite the working directory with latest Matomo release downloaded into the /usr/src/matomo directory.

The full script can be found in GitHub matomo/docker docker-entrypoint.sh.

Matomo upgrade failed: Console not working

If the Matomo console does not produce any output your Matomo installation is corrupt. This can have multiple reasons, but most likely your there are some .php files in the working directory that do not belong to the latest release.

Make sure to clean the Matomo directory before installing the latest release.

Warning

Make sure to back up your Matomo configuration located in config/config.ini.php as it holds your configurations for example database and caching credentials.

Matomo upgrade failed: Uncaught exception

If Matomo be opened in the web browser, but an Exceptions appears in the server logs your Matomo installation is also corrupt. Again, the most likely reason for this error to occur is that the working directory is not clean.

An example stack trace can look like this:

Uncaught exception in /var/www/html/plugins/Goals/Commands/CalculateConversionPages.php line 34:
Call to undefined method Piwik\Plugins\Goals\Commands\CalculateConversionPages::addOptionalValueOption()
ERROR [2024-01-01 17:04:10] 7  Uncaught exception: Error: Call to undefined method Piwik\Plugins\Goals\Commands\CalculateConversionPages::addOptionalValueOption() in /var/www/html/plugins/Goals/Commands/CalculateConversionPages.php:34
Stack trace:
#0 /var/www/html/vendor/symfony/console/Symfony/Component/Console/Command/Command.php(65): Piwik\Plugins\Goals\Commands\CalculateConversionPages->configure()
#1 /var/www/html/core/Console.php(171): Symfony\Component\Console\Command\Command->__construct()
#2 /var/www/html/core/Console.php(133): Piwik\Console->addCommandIfExists('Piwik\\Plugins\\G...')
#3 /var/www/html/core/Console.php(87): Piwik\Console->doRunImpl(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#4 /var/www/html/vendor/symfony/console/Symfony/Component/Console/Application.php(126): Piwik\Console->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#5 /var/www/html/console(32): Symfony\Component\Console\Application->run()
#6 {main}

Matomo 5 Plugin compatibility

Before upgrading to version 5 make sure that your plugins already support the latest Matomo release.

The best way to check plugin compatibility is their Matomo On-Premise Marketplace

If a plugin is not compatible it is recommended to deactivate it before the upgrade via the console:

./console plugin:deactivate ProblematicPlugin

Matomo 5 Upgrade via the Glasskube Kubernetes Operator

If Matomo was installed in Kubernetes via the Glasskube Kubernetes Operator your current custom resource definition probably looks similar to:

Matomo.yaml

yaml apiVersion: glasskube.eu/v1alpha1 kind: Matomo metadata: name: matomo spec: host: stats.mycompany.eu

Warning

Before upgrading to the latest Matomo version make sure that at least Glasskube Operator v0.13.10 is installed as it introduced Matomo 5 Support.

An explicit version needs to be added in order to upgrade to the latest version.

Matomo.yaml

yaml apiVersion: glasskube.eu/v1alpha1 kind: Matomo metadata: name: matomo spec: version: 5.0.0 # Checkout https://github.com/glasskube/images/releases for the latest release host: stats.mycompany.eu

After changing your custom resource you need to execute kubectl apply -f Matomo.yaml. The Glasskube operator will automatically perform the upgrade and all database migrations.

What happens under the hood during the Matomo 5 upgrade on Kubernetes?

Glasskube uses init containers to perform all the tasks that would have needed manual interactions like:

Making sure necessary plugins are installed or unnecessary plugins are removed
Syncing the latest Matomo release into the working directory and making sure to not remove your geo ip database und /tmp folder
Perform a database upgrade if needed
Installs an initial site if no site is yet installed
Convert your database to utf8mb4 if it was not yet correctly initialized
Create needed security files

The exact commands can be found in our install.sh file will be executed as in init container.

Matomo System Check

Always make sure that the Matomo system check is green and doesn't report any warnings or errors.

The system check can either be viewed as an administrator in the settings page or via the console

./console diagnostics:run

The desired state will look like:

Installing Matomo via Glasskube will help you to reach the desired system check state that no errors or warnings are present.

Conclusion

Running the latest version of Matomo can require some heavy plumbing especially if you need to take care about dependencies, backups and database upgrades, but utilizing the latest features and security features will definitely make it worth.

🛠️ Ready to Launch: Our TOP 11 OPEN SOURCE Tools to START your business! 💻✨

Philip Miglinci — Wed, 20 Dec 2023 10:25:42 +0000

TL;DR 🔍

Embarking on your startup adventure? Discover essential open source tools straight from our experience! From streamlining operations and managing data to fostering collaboration and ensuring security, we've got your back. Dive in and set the stage for a smooth and successful venture with these must-have tools at your fingertips.

We Want Your Feedback! 🫶

Odoo: The Open Source Swiss Army Knife 🛠️

odoo / odoo

Odoo. Open Source Apps To Grow Your Business.

Odoo

Odoo is a suite of web based open source business apps.

The main Odoo Apps include an Open Source CRM, Website Builder, eCommerce, Warehouse Management, Project Management, Billing & Accounting, Point of Sale, Human Resources, Marketing, Manufacturing, ...

Odoo Apps can be used as stand-alone applications, but they also integrate seamlessly so you get a full-featured Open Source ERP when you install several Apps.

Getting started with Odoo

For a standard installation please follow the Setup instructions from the documentation.

To learn the software, we recommend the Odoo eLearning, or Scale-up, the business game. Developers can start with the developer tutorials.

Security

If you believe you have found a security issue, check our Responsible Disclosure page for details and get in touch with us via email.

View on GitHub

When it comes to versatility in the open-source realm, Odoo stands out as the ultimate Swiss army knife for startups. Picture this: a single platform that seamlessly integrates Customer Relationship Management (CRM), Time Tracking, Employee Management, and Accounting. It might not boast the flashiness of some other tools, but don't let that fool you—Odoo is all about crazy functionality for nearly every aspect of your business.

Need a reliable CRM system to nurture those client relationships? Check. Looking for a straightforward way to track time and manage your team's schedules? Odoo's got you covered. How about simplifying employee management tasks or handling complex accounting processes? Odoo does it all, making it the go-to tool for startups ready to streamline their operations with efficiency and finesse. Stay tuned as we unravel more open source gems to fuel your startup journey!

Matomo: Your Ultimate Analytics Powerhouse Beyond Google!

matomo-org / matomo

Empowering People Ethically 🚀 — Matomo is hiring! Join us → https://matomo.org/jobs Matomo is the leading open-source alternative to Google Analytics, giving you complete control and built-in privacy. Easily collect, visualise, and analyse data from websites & apps. Star us on GitHub ⭐️ – Pull Requests welcome!

Matomo (formerly Piwik) - matomo.org

Code Status

Description

Matomo is the leading Free/Libre open analytics platform.

Matomo is a full-featured PHP MySQL software program that you download and install on your own webserver. At the end of the five-minute installation process, you will be given a JavaScript code. Simply copy and paste this tag on websites you wish to track and access your analytics reports in real-time.

Matomo aims to be a Free software alternative to Google Analytics and is already used on more than 1,400,000 websites. Privacy is built-in!

Mission Statement

« To create, as a community, the leading international open source digital analytics platform, that gives every user full control of their data, to empower better decisions. »

Our purpose is to:

« Empower People Ethically »

License

Matomo is released under the GPL v3 (or later) license, see LICENSE.

Requirements

PHP 7.2.5 or greater
MySQL version…

View on GitHub

Step aside, Google Analytics—Matomo is not just an alternative; it's a game-changer. Why settle for less when Matomo not only prioritizes user privacy but also goes above and beyond by offering Server-Side tracking and cookieless tracking options?

In the ever-evolving landscape of analytics, Matomo stands tall, allowing you to gather comprehensive insights without compromising on ethical data practices. Whether you're keen on server-side tracking for a deeper understanding of user interactions or opting for cookieless tracking for a consent-driven experience, Matomo gives you the flexibility and control you've always wanted.

Glasskube: Navigating the Kubernetes Universe with Ease! 🚀🔍

glasskube / operator

🧊 Glasskube Apps Operator

Kubernetes Operator

Open Source Tools on autopilot

Getting started »

Explore our website »

GitHub Docker Hub Artifact Hub . LinkedIn

⭐️ Why Glasskube?

Turn on autopilot and deploy and manage Open Source Tools fully automated on Kubernetes. Our Open Source Glasskube Operator is the simplest and fastest way to manage all your favorite Open Source Tools and the related infrastructure components like databases, caches, and keep them up to date without manual hassle.

✨ Features

👌 Easy installation with little to no configuration
✅ Automatic setup of databases and caches
🔄 Automate and schedule version updates and patches
🗓️ Scheduled database backups
⚙️ Interface for simple SMTP configuration

🗄️ Table Of Contents

🚀 Quick Start

The Glasskube operator is simply deployed via Helm. To install the Open Source Tool simply apply the Custom…

View on GitHub

Enter the world of seamless Kubernetes deployment of you favourite Open Source tools with Glasskube. If Kubernetes seems like a complex galaxy, Glasskube is your trusty navigation system, making deployment a breeze.

Picture this: With Glasskube, you can effortlessly deploy, manage, and scale your favourite Open Source Tools on Kubernetes and automaticlly keep them up-to-date without breaking a sweat. It's the tool that transforms the intricacies of Kubernetes into a user-friendly experience, allowing even Kubernetes newcomers to harness its power. 🌐🛠️

Plane: Soaring Through Agile Software Development Without the Jira Jumble! ✈️🛠️

makeplane / plane

🔥🔥🔥 Open-source Jira, Linear, Monday, and ClickUp alternative. Plane is a modern project management platform to manage tasks, sprints, docs, and triage.

Modern project management for all teams

Website • Releases • Twitter • Documentation

Meet Plane, an open-source project management tool to track issues, run ~~sprints~~ cycles, and manage product roadmaps without the chaos of managing the tool itself. 🧘‍♀️

Plane is evolving every day. Your suggestions, ideas, and reported bugs help us immensely. Do not hesitate to join in the conversation on Discord or raise a GitHub issue. We read everything and respond to most.

🚀 Installation

Getting started with Plane is simple. Choose the setup that works best for you:

Plane Cloud Sign up for a free account on Plane Cloud—it's the fastest way to get up and running without worrying about infrastructure.
Self-host Plane Prefer full control over your data and infrastructure? Install and run Plane on your own servers. Follow our detailed deployment guides to get started.

Installation methods	Docs link
Docker
Kubernetes

Instance admins…

View on GitHub

Say farewell to the Jira jumble and welcome Plane—a streamlined solution for Agile Software Development that keeps your team soaring high. Designed with simplicity in mind, Plane offers a refreshing alternative to the often complex and overwhelming world of project management tools.

Imagine a tool that aligns perfectly with Agile principles, allowing your team to plan sprints (or how they call it "cycles"), track tasks ("issues"), and collaborate seamlessly—all without the unnecessary complications. Plane is your ticket to efficient project management, offering a user-friendly interface that doesn't sacrifice functionality.

Whether you're a seasoned Agile enthusiast or a newcomer looking for a straightforward way to manage software development, Plane takes the stress out of the process. As it is still quite a young company, there are still a few bugs, but we are already excited about the progress and future development.

Penpot: Unleashing Creative Freedom—Your Open Source Figma Alternative! 🖌️✨

penpot / penpot

Penpot: The open-source design tool for design and code collaboration

Website • User Guide • Learning Center • Community

Youtube • Peertube • Linkedin • Instagram • Mastodon • Bluesky • X

Penpot_OpenYourEyes_.mp4

Penpot is the first open-source design tool for design and code collaboration. Designers can create stunning designs, interactive prototypes, design systems at scale, while developers enjoy ready-to-use code and make their workflow easy and fast. And all of this with no handoff drama.

Available on browser or self-hosted, Penpot works with open standards like SVG, CSS, HTML and JSON, and it’s free!

The latest updates take Penpot even further. It’s the first design tool to integrate native design tokens—a single source of truth to improve efficiency and collaboration between product design and development With the huge 2.0 release, Penpot took the platform to a whole new level. This update introduces the ground-breaking CSS Grid Layout feature, a complete UI redesign, a new Components system,…

View on GitHub

Enter the world of design innovation with Penpot—the open-source maestro that gives Figma a run for its money. If you're tired of design tools with hefty price tags and closed-source limitations, Penpot is here to redefine your creative journey.

Imagine a tool that blends the best of collaborative design, prototyping, and user interface creation—all while embracing the principles of open source. Penpot is your canvas for unleashing creative freedom, allowing teams to seamlessly collaborate on design projects without the constraints of proprietary software.

Whether you're a solo designer or part of a collaborative powerhouse, Penpot empowers you to bring your ideas to life, share them effortlessly, and iterate with ease.

Cal.com: Streamlining Your Schedule Hassle-Free! 🗓️🚀

calcom / cal.com

Scheduling infrastructure for absolutely everyone.

Cal.com

The open-source Calendly successor
Learn more »

Discussions · Website · Issues · Roadmap

About the Project

Scheduling infrastructure for absolutely everyone

The open source Calendly successor. You are in charge of your own data, workflow, and appearance.

Calendly and other scheduling tools are awesome. It made our lives massively easier. We're using it for business meetings, seminars, yoga classes, and even calls with our families. However, most tools are very limited in terms of control and customization.

That's where Cal.com comes in. Self-hosted or hosted by us. White-label by design. API-driven and ready to be deployed on your own domain. Full control of your events and data.

Recognition

Hacker News

Product Hunt

This project is tested with browserstack

Built With

Contact us

Meet our sales team for any commercial inquiries.

Stay Up-to-Date

Cal.com officially launched as v.1.0 on the 15th of…

View on GitHub

Tired of scheduling headaches? Enter Cal.com—an open-source marvel that streamlines appointment scheduling. Share your availability, let clients or colleagues pick a slot hassle-free, and wave goodbye to email ping-pong. With seamless calendar integration, it's your go-to for efficient and stress-free calendar management. Embed it on your homepage and say hello to time saved scheduling calls with customers, partners, investors, and more.

NextCloud: Your Reliable Self-Hosted File Storage with a Dash of Cool! ☁️🔒

nextcloud / server

☁️ Nextcloud server, a safe home for all your data

Nextcloud Server ☁

A safe home for all your data.

Why is this so awesome? 🤩

📁 Access your Data You can store your files, contacts, calendars, and more on a server of your choosing.
🔄 Sync your Data You keep your files, contacts, calendars, and more synchronized amongst your devices.
🙌 Share your Data …by giving others access to the stuff you want them to see or to collaborate with.
🚀 Expandable with hundreds of Apps ...like Calendar, Contacts, Mail, Video Chat and all those you can discover in our App Store
🔒 Security with our encryption mechanisms, HackerOne bounty program and two-factor authentication.

Do you want to learn more about how you can use Nextcloud to access, share, and protect your files, calendars, contacts, communication & more at home and in your organization? Learn about all our Features.

Get your Nextcloud 🚚

☑️ Simply…

View on GitHub

Meet NextCloud—a no-nonsense, down-to-earth solution for self-hosted file storage. It goes beyond the basics, offering cool features like end-to-end encryption and integrated office tools. Keep your files secure, collaborate effortlessly, and enjoy the simplicity of having your own cloud storage solution.

Metabase: Simplify Your Reporting Process with Ease! 📊

metabase / metabase

The easy-to-use open source Business Intelligence and Embedded Analytics tool that lets everyone work with data 📊

Metabase

Metabase is the easy, open-source way for everyone in your company to ask questions and learn from data.

Get started

The easiest way to get started with Metabase is to sign up for a free trial of Metabase Cloud. You get support, backups, upgrades, an SMTP server, SSL certificate, SoC2 Type 2 security auditing, and more (plus your money goes toward improving Metabase). Check out our quick overview of cloud vs self-hosting. If you need to, you can always switch to self-hosting Metabase at any time (or vice versa).

Key Features

Set up in five minutes (we're not kidding).
Let anyone on your team ask questions without knowing SQL.
Use the SQL editor for more complex queries.
Build handsome, interactive dashboards with filters, auto-refresh, fullscreen, and custom click behavior.
Create models that clean up, annotate, and/or combine raw tables.
Define canonical segments and metrics for your team…

View on GitHub

Metabase is your go-to open-source tool for hassle-free reporting. Say goodbye to complex data handling and hello to straightforward insights. Whether you're a data enthusiast or a business professional, Metabase empowers you to create insightful reports without the need for extensive training. It's all about connecting your data source, exploring possibilities, and effortlessly generating reports. From interactive dashboards to easy sharing options, Metabase streamlines your reporting journey. Ready to simplify how you handle and present your data? Dive into Metabase for a straightforward reporting experience. 📊🔍

Gitea: A Cool Option for Resource-Efficient Version Control in Small Teams! 🚀🛠️

go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD

Gitea

繁體中文 | 简体中文

Purpose

The goal of this project is to make the easiest, fastest, and most painless way of setting up a self-hosted Git service.

As Gitea is written in Go, it works across all the platforms and architectures that are supported by Go, including Linux, macOS, and Windows on x86, amd64, ARM and PowerPC architectures This project has been forked from Gogs since November of 2016, but a lot has changed.

For online demonstrations, you can visit demo.gitea.com.

For accessing free Gitea service (with a limited number of repositories), you can visit gitea.com.

To quickly deploy your own dedicated Gitea instance on Gitea Cloud, you can start a free trial at cloud.gitea.com.

Documentation

You can find comprehensive documentation on our official documentation website.

It includes installation, administration, usage, development, contributing guides, and more to help you get started and explore all features effectively.

…

View on GitHub

In the realm of version control, Gitea emerges as a cool and pragmatic choice, especially for smaller teams. This open-source platform offers a refreshing alternative to larger counterparts like GitLab, providing essential functionalities without the resource footprint.

With Gitea, the emphasis is on simplicity and efficiency. Managing repositories, tracking issues, and collaborating seamlessly become straightforward tasks, making it an excellent fit for teams that prefer a nimble and focused approach to version control.

If you're navigating the landscape of version control tools and aiming for a solution that effortlessly caters to the needs of a smaller team, Gitea stands out as a cool option worth exploring. Give it a try and experience version control without unnecessary complexities. 🛠️👥

Mattermost: Your Secure Slack Alternative with Powerful Chat and Jitsi Integration! 💬🔒

mattermost / mattermost

Mattermost is an open source platform for secure collaboration across the entire software development lifecycle..

Mattermost is an open core, self-hosted collaboration platform that offers chat, workflow automation, voice calling, screen sharing, and AI integration. This repo is the primary source for core development on the Mattermost platform; it's written in Go and React, runs as a single Linux binary, and relies on PostgreSQL. A new compiled version is released under an MIT license every month on the 16th.

Deploy Mattermost on-premises, or try it for free in the cloud.

Learn more about the following use cases with Mattermost:

Other useful resources:

Download and Install Mattermost - Install, setup, and configure your own Mattermost instance.
Product documentation - Learn how to run a Mattermost instance and take advantage of all the features.
Developer documentation - Contribute code to Mattermost or build an integration via APIs, Webhooks, slash commands, Apps, and plugins.

Install Mattermost
Native…

View on GitHub

Discover Mattermost, the open-source Slack alternative that prioritizes secure team communication. With robust chat functionalities, file sharing, and the added bonus of seamless Jitsi integration, Mattermost creates a private and efficient collaboration space for your team.

Strapi: The Cool Choice for Flexible and Customizable Content Management! 🚀📝

strapi / strapi

🚀 Strapi is the leading open-source headless CMS. It’s 100% JavaScript/TypeScript, fully customizable, and developer-first.

Open-source headless CMS, self-hosted or Cloud you’re in control.

The leading open-source headless CMS, 100% JavaScript/TypeScript, flexible and fully customizable.

Cloud · Try live demo

Strapi Community Edition is a free and open-source headless CMS enabling you to manage any content, anywhere.

Self-hosted or Cloud: You can host and scale Strapi projects the way you want. You can save time by deploying to Strapi Cloud or deploy to the hosting platform you want**: AWS, Azure, Google Cloud, DigitalOcean.
Modern Admin Panel: Elegant, entirely customizable and a fully extensible admin panel.
Multi-database support: You can choose the database you prefer: PostgreSQL, MySQL, MariaDB, and SQLite.
Customizable: You can quickly build your logic by fully customizing APIs, routes, or plugins to fit your needs perfectly.
Blazing Fast and Robust: Built on top of Node.js and TypeScript, Strapi delivers reliable and solid performance.
Front-end Agnostic: Use any…

View on GitHub

For those in search of a content management system that's both flexible and customizable, Strapi stands out as a cool option worth exploring. This open-source headless CMS puts you in control, allowing developers and content creators alike to shape and manage digital content effortlessly.

With a user-friendly interface and customizable APIs, Strapi offers a refreshing alternative for those seeking a dynamic approach to content management. It's the kind of tool that understands the importance of flexibility, giving you the freedom to design and structure your content according to your vision.

If you're after a cool and adaptable solution that breaks away from the traditional CMS mold, consider giving Strapi a spin. It might just be the key to unlocking a new level of creativity and efficiency in managing your digital content.

Conclusion

To sum up, the realm of open-source tools not only provides cost-effective solutions for emerging businesses but often comes with the added benefits of being usually free when self-hosted, privacy-friendly, and scalable. These established tools showcased here have proven themselves as reliable options for various business needs—from project management to analytics, collaboration, and beyond. Their open-source nature fosters a sense of transparency and community-driven development.

In the spirit of constant improvement and discovery, if there's an open-source gem that we haven't covered, we invite you to share your insights in the comments below. Here's to the ever-growing world of open-source possibilities! 🌐🛠️

Star Glasskube:

`glasskube/glasskube`

🔥Our TOP 13 DEPLOYMENT & TEMPLATING tools for KUBERNETES 🚀

Philip Miglinci — Thu, 14 Dec 2023 14:51:22 +0000

TL;DR 🔍

Feeling a bit lost in the Kubernetes deployment and packaging tool jungle? Don't worry!
We've got your back with a comprehensive cheat sheet. Dive into our curated list, breaking down each tool, its purpose, and a user-friendliness rating to make your Kubernetes journey a breeze.
Say goodbye to overwhelm and hello to clarity with our go-to guide! 🌐🚀

We Want Your Feedback! 🫶

Tool	Lizenz	GitHub Stars	Ease of Use	UI	Commercial Support	Templating	Deployment
cdk8s	Apache 2.0	3.9k	⭐⭐⭐⭐	❌	✅	✅	❌
kubectl	Apache 2.0	2.6k	⭐⭐⭐⭐	❌	❌	❌	✅
Glasskube	LGPL.v3	152	⭐⭐⭐⭐	✅	✅	✅	✅
Helm	Apache 2.0	25.3k	⭐⭐⭐	❌	❌	✅	✅
Kustomize	Apache 2.0	10.2k	⭐⭐⭐⭐	❌	❌	✅	✅
Flux	Apache 2.0	5.5k	⭐⭐⭐	✅	✅	❌	✅
Argo CD	Apache 2.0	14.9k	⭐⭐⭐⭐	✅	❌	❌	✅
Timoni	Apache 2.0	981	⭐⭐⭐⭐⭐	❌	❌	✅	❌
Carvel	Apache 2.0	325	⭐⭐⭐	❌	❌	✅	❌
Pulumi	Apache 2.0	18.4k	⭐⭐⭐⭐	❌	✅	✅	❌
Terraform	BSL	39.8k	⭐	✅	✅	✅	✅
Tanka with Jsonnet	MIT	2.1k	⭐⭐	❌	❌	✅	❌
Dhall	Apache 2.0	600	⭐⭐⭐	❌	❌	✅	❌

cdk8s: Where Kubernetes Meets Familiar Programming Languages

cdk8s-team / cdk8s

Define Kubernetes native apps and abstractions using object-oriented programming

Cloud Development Kit for Kubernetes

cdk8s is an open-source software development framework for defining Kubernetes applications and reusable abstractions using familiar programming languages and rich object-oriented APIs. cdk8s apps synthesize into standard Kubernetes manifests which can be applied to any Kubernetes cluster.

cdk8s is a Cloud Native Computing Foundation Sandbox Project, built with ❤️ at AWS. We encourage you to try it out, leave feedback, and jump in to help!

Contents:

Repositories

This project consists of multiple packages, maintained and released via the following repositories:

cdk8s - Core library. For historical reasons note that the cdk8s package is maintained in the cdk8s-team/cdk8s-core repository.
cdk8s-cli - Command-Line interface.
cdk8s-plus - High-Level constructs for Kubernetes core.

The current repository acts as an umbrella repository for cross module concerns, as well as the deployment of…

View on GitHub

What it is: Cloud Development Kit for Kubernetes (cdk8s) lets you write Kubernetes Manifests / Helm-charts in an object orientated way.
You can easily extend existing classes, use interfaces and make sure you don't have to repeat yourself.
All your code will get compiled to yaml resources which than can easily deployed to your cluster.

Strengths: Beginner-friendly, object-oriented APIs, integrates with AWS CDK.

Ease of Use: ⭐⭐⭐⭐

kubectl: The Swiss Army Knife for Kubernetes Deployments

kubernetes / kubectl

Issue tracker and mirror of kubectl code

⚠️ This is an automatically published staged repository for Kubernetes.
Pull requests, should be made to the main Kubernetes repository: https://github.com/kubernetes/kubernetes.
This repository is read-only for importing, and not used for direct contributions.
See CONTRIBUTING.md for more details.

Kubectl

The k8s.io/kubectl repo is used to track issues for the kubectl cli distributed with k8s.io/kubernetes. It also contains packages intended for use by client programs. E.g. these packages are vendored into k8s.io/kubernetes for use in the kubectl cli client. That client will eventually move here too.

Contribution Requirements

Full unit-test coverage.
Go tools compliant (go get, go test, etc.). It needs to be vendorable somewhere else.
No dependence on k8s.io/kubernetes. Dependence on other repositories is fine.
Code must be usefully commented Not only for developers on the project, but also for external users of these packages.
When reviewing PRs, you are encouraged to…

View on GitHub

What it is: Meet the command-line hero! kubectl is Kubernetes' official command-line interface.
It's your go-to tool for applying configurations, managing clusters, and handling everything Kubernetes from the terminal.
Using kubectl edit you can even directly edit and modify resources. (NOT RECOMMENDED)

Strengths: Standard, versatile, direct control over resources.

Ease of Use: ⭐⭐⭐⭐

Glasskube: The simple Path to Kubernetes Deployment

glasskube / operator

🧊 Glasskube Apps Operator

Kubernetes Operator

Open Source Tools on autopilot

Getting started »

Explore our website »

GitHub Docker Hub Artifact Hub . LinkedIn

⭐️ Why Glasskube?

✨ Features

👌 Easy installation with little to no configuration
✅ Automatic setup of databases and caches
🔄 Automate and schedule version updates and patches
🗓️ Scheduled database backups
⚙️ Interface for simple SMTP configuration

🗄️ Table Of Contents

🚀 Quick Start

The Glasskube operator is simply deployed via Helm. To install the Open Source Tool simply apply the Custom…

View on GitHub

What it is: Glasskube is your window into transparent Kubernetes deployments.
It pre-packages popular open-source apps and components and abstracts them via custom resources.
Glasskube utilizes a Kubernetes operator to install components in the correct namespaces and directly make sure apps and components are probably connected and configured.

Strengths: User-friendly, transparent deployment, emphasis on simplicity.

Ease of Use: ⭐⭐⭐⭐

Helm: Kubernetes Package Manager

helm / helm

The Kubernetes Package Manager

Helm

Helm is a tool for managing Charts. Charts are packages of pre-configured Kubernetes resources.

Use Helm to:

Find and use popular software packaged as Helm Charts to run in Kubernetes
Share your own applications as Helm Charts
Create reproducible builds of your Kubernetes applications
Intelligently manage your Kubernetes manifest files
Manage releases of Helm packages

Helm in a Handbasket

Helm is a tool that streamlines installing and managing Kubernetes applications Think of it like apt/yum/homebrew for Kubernetes.

Helm renders your templates and communicates with the Kubernetes API
Helm runs on your laptop, CI/CD, or wherever you want it to run.
Charts are Helm packages that contain at least two things:
- A description of the package (Chart.yaml)
- One or more templates, which contain Kubernetes manifest files
Charts can be stored on disk, or fetched from remote chart repositories (like Debian or RedHat packages)

Helm Development and Stable Versions

…

View on GitHub

What it is: Helm is a common package manager for Kubernetes.
It simplifies complex app deployments by packaging them into "charts" that can be shared and deployed.

Strengths: Package management, community charts, versioning.

Ease of Use: ⭐⭐⭐

Kustomize: Tailoring Kubernetes Configurations Like a Pro

kubernetes-sigs / kustomize

Customization of kubernetes YAML configurations

kustomize

kustomize lets you customize raw, template-free YAML files for multiple purposes, leaving the original YAML untouched and usable as is.

kustomize targets kubernetes; it understands and can patch kubernetes style API objects. It's like make, in that what it does is declared in a file and it's like sed, in that it emits edited text.

This tool is sponsored by sig-cli (KEP).

kubectl integration

To find the kustomize version embedded in recent versions of kubectl, run kubectl version:

> kubectl version --client
Client Version: v1.31.0
Kustomize Version: v5.4.2

The kustomize build flow at v2.0.3 was added to kubectl v1.14. The kustomize flow in kubectl remained frozen at v2.0.3 until kubectl v1.21, which updated it to v4.0.5. It will be updated on a regular basis going forward, and such updates will be reflected in the Kubernetes release notes.

…

View on GitHub

What it is: Kustomize is part of kubectl and helps you to not duplicate your Kubernetes manifests.
You can reuse the same resources in multiple kustomizations and apply patches to modify only specific values.
You can also create reusable components to better organize your kustomize projects.

Strengths: Config customization, simplicity, integrates with GitOps.

Ease of Use: ⭐⭐⭐⭐

Flux: GitOps Magic for Continuous Delivery

fluxcd / flux2

Open and extensible continuous delivery solution for Kubernetes. Powered by GitOps Toolkit.

Flux version 2

Flux is a tool for keeping Kubernetes clusters in sync with sources of configuration (like Git repositories and OCI artifacts) and automating updates to configuration when there is new code to deploy.

Flux version 2 ("v2") is built from the ground up to use Kubernetes' API extension system, and to integrate with Prometheus and other core components of the Kubernetes ecosystem. In version 2, Flux supports multi-tenancy and support for syncing an arbitrary number of Git repositories, among other long-requested features.

Flux v2 is constructed with the GitOps Toolkit, a set of composable APIs and specialized tools for building Continuous Delivery on top of Kubernetes.

Flux is a Cloud Native Computing Foundation (CNCF) graduated project, used in production by various organisations and cloud providers.

Quickstart and documentation

To get started check out this guide on how to bootstrap Flux on Kubernetes and deploy…

View on GitHub

What it is: Flux is a complete CD solution for Kubernetes.
It syncs your Kubernetes cluster with Manifests stored in a git repository.
It also has controllers for kustomizations and helm repositories which interact with the Kubernetes api by packaging helm in helm-controller.
With weaveworks there is also an UI and commercial support available.

Strengths: GitOps, automated syncing, continuous delivery.

Ease of Use: ⭐⭐⭐

Argo CD: The Maestro of GitOps

argoproj / argo-cd

Declarative Continuous Deployment for Kubernetes

Releases:

Code:

Social:

Argo CD - Declarative Continuous Delivery for Kubernetes

What is Argo CD?

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes.

Why Argo CD?

Application definitions, configurations, and environments should be declarative and version controlled.
Application deployment and lifecycle management should be automated, auditable, and easy to understand.

Who uses Argo CD?

Official Argo CD user list

Documentation

To learn more about Argo CD go to the complete documentation. Check live demo at https://cd.apps.argoproj.io/.

Community

Contribution, Discussion and Support

You can reach the Argo CD community and developers via the following channels:

Q & A : Github Discussions
Chat : The #argo-cd Slack channel
Contributors Office Hours: Every Thursday | Agenda
User Community meeting: First Wednesday of the month | Agenda

Participation in the Argo CD project is governed by the CNCF Code of Conduct

Blogs and Presentations

Awesome-Argo: A Curated List of…

View on GitHub

What it is: Argo CD is an alternative to flux with a stronger focus on a user interface to sync your manifests to your cluster.
It also follows the declarative approach where manifests should be stored in a git repository.

Strengths: GitOps, continuous delivery, declarative configuration.

Ease of Use: ⭐⭐⭐⭐

Timoni: Simplicity in Kubernetes Deployment

stefanprodan / timoni

Timoni is a package manager for Kubernetes, powered by CUE and inspired by Helm.

timoni

Timoni is a package manager for Kubernetes powered by CUE and inspired by Helm.

The Timoni project strives to improve the UX of authoring Kubernetes configs Instead of mingling Go templates with YAML like Helm, or layering YAML on top of each-other like Kustomize, Timoni relies on cuelang's type safety, code generation and data validation features to offer a better experience of creating, packaging and delivering apps to Kubernetes.

Important

Note that Timoni in under active development and is still in its infancy. The APIs and command-line interface may change in a backwards incompatible manner.

Get Started

To get started with Timoni please visit the documentation website at timoni.sh.

Concepts

Module - App definition containing Kubernetes CUE templates and configuration schema, distributed as OCI artifacts.
Instance - App instantiation referencing the module and workloads deployed on a Kubernetes cluster.
Bundle - App composition bundling multiple modules and…

View on GitHub

What it is: Timoni is an alternative to helm that.
It uses the nomenclature "bundle" to package applications. It also aims to manage the life cycle of applications and its CRDs.
It uses the CUE data validation language.

Strengths: User-friendly, streamlined deployment, minimal learning curve.

Ease of Use: ⭐⭐⭐⭐⭐

Carvel: The Swiss Army Knife for Kubernetes Configuration

carvel-dev / carvel

Carvel provides a set of reliable, single-purpose, composable tools that aid in your application building, configuration, and deployment to Kubernetes. This repo contains information regarding the Carvel open-source community.

Carvel

Carvel provides a set of reliable, single-purpose, composable tools that aid in your application building, configuration, and deployment to Kubernetes.

This is a list of repos associated with the Carvel project.

ytt - Template and overlay Kubernetes configuration via YAML structures, not text documents
kapp - Install, upgrade, and delete multiple Kubernetes resources as one "application"
kbld - Build or reference container images in Kubernetes configuration in an immutable way
imgpkg - Bundle and relocate application configuration (with images) via Docker registries
kapp-controller - Capture application deployment workflow in App CRD. Reliable GitOps experience powered by kapp.
vendir - Declaratively state what files should be in a directory.
secretgen-controller - Provides CRDs to specify what secrets need to be on a cluster (generated or not).

Experimental:

Installation:

Plugins:

Examples:

See what's planned in our backlog.

Join

…

View on GitHub

What it is: Carvel is your all-in-one toolkit for managing Kubernetes configurations. It offers a suite of tools, including ytt for templating and kapp for deploying applications.
Think of it as a Swiss Army Knife for fine-tuning your Kubernetes setup.

Strengths: Comprehensive toolkit, powerful templating, configuration management.

Ease of Use: ⭐⭐⭐⭐

Pulumi: Kubernetes Deployments with a Dash of Code

pulumi / pulumi

Pulumi - Infrastructure as Code in any programming language 🚀

Infrastructure as Code in any Programming Language

Pulumi Infrastructure as Code is the easiest way to build and deploy infrastructure, of any architecture and on any cloud, using programming languages that you already know and love. Code and ship infrastructure faster with your favorite languages and tools, and embed IaC anywhere with Automation API.

Simply write code in your favorite language and Pulumi automatically provisions and manages your resources on AWS Azure Google Cloud Platform, Kubernetes, and 120+ providers using an infrastructure-as-code approach. Skip the YAML, and use standard language features like loops, functions, classes, and package management that you already know and love.

For example, create three web servers:

const aws = require("@pulumi/aws");
const sg = new aws.ec2.SecurityGroup("web-sg", {
    ingress: [{ protocol: "tcp", fromPort: 80, toPort:

…

View on GitHub

What it is: Pulumi brings a unique twist to Kubernetes deployments by allowing you to define infrastructure as code using your favorite programming languages.
It can we used as an alternative to cdk8s.

Strengths: Infrastructure as code, multi-language support, easy to integrate.

Ease of Use: ⭐⭐⭐⭐

Terraform: Infrastructure as Code for Kubernetes

hashicorp / terraform

Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.

Terraform

Website: https://developer.hashicorp.com/terraform
Forums: HashiCorp Discuss
Documentation: https://developer.hashicorp.com/terraform/docs
Tutorials: HashiCorp's Learn Platform
Certification Exam: HashiCorp Certified: Terraform Associate

Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. Terraform can manage existing and popular service providers as well as custom in-house solutions.

The key features of Terraform are:

Infrastructure as Code: Infrastructure is described using a high-level configuration syntax. This allows a blueprint of your datacenter to be versioned and treated as you would any other code. Additionally, infrastructure can be shared and re-used.
Execution Plans: Terraform has a "planning" step where it generates an execution plan. The execution plan shows what Terraform will do when you call apply. This lets you avoid any surprises when Terraform manipulates infrastructure.
Resource Graph: Terraform builds a graph of all your resources, and parallelizes the creation and modification of any non-dependent resources. Because of this, Terraform builds…

View on GitHub

What it is: Terraform is the seasoned veteran in the infrastructure-as-code realm.
It extends its prowess to Kubernetes, providing a declarative way to manage infrastructure.
If you're comfortable with HashiCorp's templating language hcl it can be valid alternative to using kustomize.

Strengths: Infrastructure as code, robust ecosystem, widely adopted.

Ease of Use: ⭐

Grafana Tanka with Jsonnet: Templating Magic for Kubernetes Configurations

grafana / tanka

Flexible, reusable and concise configuration for Kubernetes

Website · Installation · Tutorial

Grafana Tanka

The clean, concise and super flexible alternative to YAML for your Kubernetes cluster

💥 Clean: The Jsonnet language expresses your apps more obviously than YAML ever did
📚 Reusable: Build libraries, import them anytime and even share them on GitHub!
📌 Concise: Using the Kubernetes library and abstraction, you will never see boilerplate again!
🎯 Confidence: Stop guessing and use tk diff to see what exactly will happen
🔭 Helm: Vendor in, modify, and export Helm charts reproducibly
🚀 Production ready: Tanka deploys Grafana Cloud and many more production setups

Let's kill some YAML together ▶

🚀 Getting started

To get started, install Tanka first, and then follow the tutorial. This should get you on track quickly.

👥 Community

There are several places to connect with the Tanka community:

GitHub Discussions: Primary support channel
#tanka…

View on GitHub

What it is: Grafana Tanka is another alternative to kustomize using the Jsonnet templating to create more powerful and extensible libraries of Kubernetes manifests

Strengths: Templating, reliability, dynamic configurations.

Ease of Use: ⭐⭐

Dhall: Functional Purity in Kubernetes Configuration

dhall-lang / dhall-kubernetes

Typecheck, template and modularize your Kubernetes definitions with Dhall

`dhall-kubernetes`

dhall-kubernetes contains Dhall bindings to Kubernetes so you can generate Kubernetes objects definitions from Dhall expressions This will let you easily typecheck, template and modularize your Kubernetes definitions.

Why do I need this

Once you build a slightly non-trivial Kubernetes setup, with many objects floating around, you'll encounter several issues:

Writing the definitions in YAML is really verbose, and the actually important things don't stand out that much
Ok I have a bunch of objects that'll need to be configured together, how do I share data?
I'd like to reuse an object for different environments, but I cannot make it parametric..
In general, I'd really love to reuse parts of some definitions in other definitions
Oh no, I typoed a key and I had to wait until I pushed to the cluster to get an error back :(

The natural tendency is to reach for a templating language…

View on GitHub

What it is: Dhall brings functional programming goodness to Kubernetes configuration as an alternative to kustomize and tanka with jsonnet.
It offers a declarative language that's both human-readable and type-safe.

Strengths: Functional programming, type safety, human-readable syntax.

Ease of Use: ⭐⭐⭐

Conclusion

In conclusion, the Kubernetes deployment landscape is undoubtedly vast, but armed with our comprehensive cheat sheet, you're now equipped to navigate it like a seasoned explorer.
From the simplicity of cdk8s to the coding magic of Pulumi, the Swiss Army finesse of Carvel, the templating sorcery of Jsonnet, and the functional purity of Dhall, each tool offers a unique journey in the realm of Kubernetes.
With user-friendliness ratings as your compass, embark on your deployment adventure with confidence.
Say goodbye to overwhelm and hello to clarity – you're now ready to conquer the Kubernetes universe! 🚀🌐✨

👋 Why we say GOODBYE to HELM 👋

Philip Miglinci — Mon, 11 Dec 2023 09:47:59 +0000

TL;DR 🔍

In this blog post, we address our issues withwith Helm, a popular Kubernetes deployment tool, discussing shortcomings like Custom Resource Definition upgrades, dependency management, user-unfriendly chart creation, values.yaml complexity, and the inability to interact with the Kubernetes API post-installation.

We Want Your Feedback! 🫶

5 reasons we are trying to build the next generation of deployment automation for Kubernetes.

Do you want to follow our journey? Star Glasskube on GitHub: glasskube/glasskube

As a seasoned DevOps engineer, I found that Helm, the popular Kubernetes deployment tool, has some shocking shortcomings.
In this post I want to discuss some of those which, in my opinion, require a new vision of a more modern deployment solution.
If you never heard about Helm before, in a nutshell it is:

A framework for packaging Kubernetes resources (apps) to charts, publish them and let them easily be installed via a command line interface.

The goal of this post is not to hate on the smart and talented people who built Helm, but maybe we can kindle a productive and healthy discussion about where we need to go as the DevOps industry to stay relevent in the coming years. But to fully undestand the following, I think it is important to understand what developments lead us to where we are today.
So, before we start, let's quickly dive into the history of Helm.

In 2015, a company called Deis created Helm, a package manager for Kubernetes.
Deis is now part of Azure Kubernetes Service but the original project still exists as Helm Classic. At the same time, Google had a project called Kubernetes Deployment Manager, which was similar to Google Deployment Manager but for kubernetes resources, rather than GCS resources.

At the beginning of 2016, the two projects decided to merge, which resulted in the release of Helm v2 later that year.
Helm v2 consists of a client and server component (helm and tiller, respectively), where the latter was the continuation of the original Kubernetes Deployment Manager project.
Tiller was designed to handle deployment states to make it easier for multiple users to use Helm without interfering with each other.

In 2018, Helm launched the Helm Hub as a central place to discover charts which are otherwise found in distributed repositories.
Helm Hub was rebranded to Artifact Hub in 2020.

With the release of Kubernetes 1.6, which had Role Based Access Control (RBAC) enabled by default, production deployments of Helm became more difficult, because of the many security policies that were required by tiller.
So, people started to experiment with a new approach that could do the same thing without requiring a server component, which resulted in the release of Helm v3 in 2019.

As you can see, Helm has a very rich history. It became the gold-standard of packaging apps for Kubernetes and is used by DevOps engineers all over the world. But just because Helm is the biggest player on the field, it doesn't mean that it is without flaws. So then, why say goodbye to Helm?

1. Helm doesn't provide a mechanism for upgrading Custom Resource Definitions

helm does provide a method of packaging Custom Resource Definitions (CRDs) by placing them in a dedicated crds directory, but these are ignored during upgrades!
This is intentional and designed to prevent accidental data loss.
Therefore, upgrading a chart does not automatically upgrade it's associated CRDs, which is unexpected for many engineers and leads to more manually involved and error-prone upgrade procedures and other anti-patterns.

To combat this major design flaw, chart developers have come up with several strategies, the most popular of which are:

Putting the CRDs into the chart's template directory
Creating separate sub-charts just for CRDs

An alternative way to overcome this shortcoming is to not invoke Helm commands directly, but rather use a CI/CD solution, like Flux.
Flux provides a setting to automatically update CRDs during a Helm upgrade, but it is off by default.

2. Helm dependency management

The way to specify a dependency in a Helm chart is to reference it as a sub-chart.
This method can work great for tightly coupled dependencies that you might want to install separately or as part of another chart, but it has some weaknesses that are important to understand:

Sub-charts are always installed in the same namespace as the primary release and there is no way to change this.
There exists no mechanism to share a dependency between two releases.

For example, our Glasskube Operator Helm Chart depends on kube-prometheus-stack, velero and a bunch of other dependencies, some of which are already installed in many Kubernetes clusters.
To provide an installation experience that is as simple as possible, the chart references all those dependencies as sub-charts, but using this approach, all those dependencies are bundled in the Glasskube Operator release and can not be changed or updated separately.
Additionally, there is no way to check whether a dependency is already installed, so a user might end up with two separate installations of the same Helm chart!

Ideal tooling would allow chart developers to specify external dependencies and simply ensure that those are present in a cluster before a chart can be installed.
This way, dependencies could be shared among consumers.
This is how package managers for operating systems work since forever. Why does Kubernetes need to be different?

3. Helm chart creation is not user-friendly

So far, we discussed problems that affect you as a chart user.
But what does the situation look like for chart developers?

Well, let's start by creating a new chart.
This can be achieved by calling helm create your-chart.
I invite you to quickly open a terminal, run this command and go through all the files it creates.
As I'm sure you will agree, it's… a lot.
I still remember the moment when I wanted to create my first Helm chart and saw the results of this command thinking, “this can't be right.”

.:
total 8,0K
drwxr-xr-x. 2 kosmoz kosmoz   40  7. Dez 13:23 charts/
-rw-r--r--. 1 kosmoz kosmoz 1,2K  7. Dez 13:23 Chart.yaml
drwxr-xr-x. 3 kosmoz kosmoz  200  7. Dez 13:23 templates/
-rw-r--r--. 1 kosmoz kosmoz 1,9K  7. Dez 13:23 values.yaml

./charts:
total 0

./templates:
total 28K
-rw-r--r--. 1 kosmoz kosmoz 1,9K  7. Dez 13:23 deployment.yaml
-rw-r--r--. 1 kosmoz kosmoz 1,8K  7. Dez 13:23 _helpers.tpl
-rw-r--r--. 1 kosmoz kosmoz  925  7. Dez 13:23 hpa.yaml
-rw-r--r--. 1 kosmoz kosmoz 2,1K  7. Dez 13:23 ingress.yaml
-rw-r--r--. 1 kosmoz kosmoz 1,8K  7. Dez 13:23 NOTES.txt
-rw-r--r--. 1 kosmoz kosmoz  326  7. Dez 13:23 serviceaccount.yaml
-rw-r--r--. 1 kosmoz kosmoz  370  7. Dez 13:23 service.yaml
drwxr-xr-x. 2 kosmoz kosmoz   60  7. Dez 13:23 tests/

./templates/tests:
total 4,0K
-rw-r--r--. 1 kosmoz kosmoz 388  7. Dez 13:23 test-connection.yaml

In total, helm create generates 10 files in different sub-directories and it is not immediately apparent which ones of those are actually essential for a chart and which ones are just example code.
I once complained about this to a DevOps engineer who had already created dozens of charts and they laughed and said:

“The first step in creating a chart is running helm create. The second is deleting 90% of the results.”

Really? That's the best we can do?
Okay, let's accept that and say you figured out the structure of your new chart.
Now, you probably want to add some resources.
Of course you can just drop your existing YAML files into the chart's templates directory, but you're probably interested in using some parameters from your values.yaml in your resources.
After all, that would kind of be the point of creating a Helm chart in the first place.
To look at an example, go back to your terminal (where, previously, you created your Helm chart) and check out the file templates/serviceaccount.yaml:

{{- if .Values.serviceAccount.create -}}
apiVersion: v1
kind: ServiceAccount
metadata:
  name: {{ include "your-chart.serviceAccountName" . }}
  labels:
    {{- include "your-chart.labels" . | nindent 4 }}
  {{- with .Values.serviceAccount.annotations }}
  annotations:
    {{- toYaml . | nindent 4 }}
  {{- end }}
{{- end }}

Now, I know what you're thinking:

That doesn't look like the YAML I know!
What is ' include, toYaml and nindent and what's up with all the - and {{ and |?

It's true, although Helm template files use the file name extension for YAML, they are actually just templates.
Helm templates are based on the Go template language which is very flexible and powerful but doesn't really know anything about YAML or Kubernetes.
That's why it's necessary to call lots of these conversion functions inside the template files.

As a result many popular charts end up with template files that contain more template language stuff than actual YAML.
This makes them hard to read and maintain, especially as someone who wasn't involved in it's creation.

4. The `values.yaml` file is an antipattern

Now, let's go back to something that's a little more tangible for you as a Helm user.
As a Kubernetes application developer who writes resources as YAML files, you are probably used to having rich support in your development environment, including strict schema validation and super comprehensive autocomplete.
Creating a values.yaml file for a chart release is a little different.
See, there is no general schema for what goes and doesn't go inside a values.yaml file.
Thus, your development environment cannot help you beyond basic YAML syntax highlighting.
The only way to verify if your values.yaml file is valid is to run it through Helm and see what happens.
Using helm template allows the you to render these Helm templates which detects possible errors in the configuration file.

A lot of chart developers want to give users the possibility to fine tune most aspects of final deployment.
As a result, the number of possibilities for configuration is often unreasonably large and complicated, mimicking the actual resources they want to create, but without any schema validation!

5. Inability to interact with the Kubernetes API

We already discussed 4 shortcomings of Helm, but in my opinion the biggest downside of Helm is this:
A Helm release is strictly a one-shot operation.
Once a Helm release is successfully installed, Helm's job is done.
But here's the thing: Installing an application is usually not the hard part, maintaining an installation and keeping it running is.
Unfortunately, Helm doesn't really help you with that.

After finishing installation of a release, Helm can not perform any additional changes due to it's design as a strictly client-side application.
This inability to interact with the release during later stages of a release's life-cycle means that helm as a deployment method inherently static, but modern software deployments are often required to be very dynamic.

Detecting the cloud environment:

private val dynamicCloudProvider
    get() = when {
        kubernetesClient.configMaps().inNamespace("kube-system").withName("shoot-info")
            .get()?.data?.get("extensions")?.contains("shoot-dns-service") == true ->
            CloudProvider.gardener

        kubernetesClient.nodes().withLabel("eks.amazonaws.com/nodegroup").list().items.isNotEmpty() ->
            CloudProvider.aws

        kubernetesClient.nodes().withLabel("csi.hetzner.cloud/location").list().items.isNotEmpty() ->
            CloudProvider.hcloud

        else ->
            CloudProvider.generic
    }

Applying configurations based on the environment:

protected val defaultIngressClassName: String?
    get() = when (configService.cloudProvider) {
        CloudProvider.aws -> "alb"
        else -> configService.ingressClassName
    }

protected fun getDefaultAnnotations(primary: P, context: Context<P>): Map<String, String> =
    configService.getCommonIngressAnnotations(primary) +
        when (configService.cloudProvider) {
            CloudProvider.aws -> awsDefaultAnnotations
            CloudProvider.gardener -> gardenerDefaultAnnotations
            else -> getCertManagerDefaultAnnotations(context) + ingressNginxDefaultAnnotations
        }

Conclusion

Although many developers are a bit scared of Helm at first, it's simple design gave Helm the lead it currently holds in the space of Kubernetes deployment methods.
Helm is currently the de-facto standard for managing complex application deployments, but that doesn't mean we shouldn't challenge it's design and point out shortcomings.
New requirements for applications will require more dynamic deployment methods and we DevOps engineers and application developers must be prepared.

This is why we started Glasskube: An easier way to deploy applications and infrastructure on Kubernetes. If you want to follow our progress make sure to star: glasskube/glasskube

🚀 GITLAB ON KUBERNETES: The Ultimate Deployment Guide! 🌟

Philip Miglinci — Wed, 29 Nov 2023 16:43:06 +0000

TL;DR 🔍

Explore the step-by-step guide to deploying GitLab on Kubernetes, focusing on the Omnibus package configuration. Learn to set up PostgreSQL, SMTP, Container Registry, Sidekiq, Prometheus metrics, and backups. Discover an alternative with the Glasskube GitLab Kubernetes Operator, simplifying the process and reducing setup time to just 5 minutes.

We Want Your Feedback! 🫶

Let´s get started 🏌️

GitLab is an open source DevSecOps platform for software engineering teams.

There are two flavors available for deploying GitLab on your Kubernetes Cluster:

GitLab Cloud native hybrid
GitLab package (Omnibus)

GitLab Cloud native hybrid

Deploying the GitLab Cloud native hybrid architecture makes only sense in query specific use-cases. For example - as seen in the GitLab decision tree - if the GitLab instance need to serve at least 3,000 users. For this kind of deployment the GitLab components will be installed separately and in different docker containers. Resulting in minimum requirements of 10 nodes with a total of 19 vCPUs and 60 GB memory, which will result in a couple of thousand dollars cloud costs a month.

So in most cases GitLab Cloud native is not needed and overly complex.

So, how to deploy GitLab Omnibus on Kubernetes?

GitLab Omnibus on Kubernetes

Using the name “omnibus”, GitLab also publishes all-in-one packages, which are available as docker images hub.docker.com/r/gitlab/gitlab-ce, that can be easily configured via environment variables. Doing the configuration right makes it easy to deploy GitLab on Kubernetes.

Following important components should be configured correctly in order to archive a reasonable Kubernetes setup:

PostgreSQL database
SMTP configuration
GitLab container registry on Kubernetes
Sidekiq, Gitaly & Puma configuration
Prometheus metrics
GitLab backups on Kubernetes

GitLab on Kubernetes: Configure an external PostgreSQL database

Creating a PostgreSQL database can be done with the CloudNativePG PostgreSQL Operator. After the installation of the operator a new Postgres cluster can be deployed by applying a Kubernetes CR:

kind: Cluster
apiVersion: postgresql.cnpg.io/v1
metadata:
  name: gitlab
spec:
  enableSuperuserAccess: false
  instances: 2
  bootstrap:
    initdb:
      database: gitlabhq_production
      owner: gitlab
  storage:
    size: 20Gi

It is important that the database is called gitlabhq_production and the configured gitlab database user is the owner of the database. In this case, we created a cluster consisting of two PostgreSQL replicas to ensure that the database remains available, even in case the node running the primary replica fails. This is called high availability (HA).
Now, that we created our very own PostgreSQL cluster, the database included in the omnibus image must be disabled in the gitlab.rb file.

postgresql['enable'] = false

gitlab_rails['db_adapter'] = 'postgresql'
gitlab_rails['db_encoding'] = 'unicode'
gitlab_rails['db_host'] = 'gitlab-pg-rw'
gitlab_rails['db_password'] = '<your-password>'

Nice, we already have cloud native database for our GitLab installation.

GitLab on Kubernetes: Configure SMTP credentials

In order to make sure your GitLab instance is able to send emails, you need to configure an SMTP server. This also can be done in the gitlab.rb file.

gitlab_rails['smtp_enable'] = ...
gitlab_rails['smtp_address'] = ...
gitlab_rails['smtp_port'] = ...
gitlab_rails['smtp_user_name'] = ...
gitlab_rails['smtp_password'] = ...
gitlab_rails['smtp_tls'] = ...
gitlab_rails['gitlab_email_from'] = ...

A free smtp server for transactional emails can be created for example on the Brevo platform.

GitLab on Kubernetes: Container registry

Among it's many features, GitLab supports serving as a container registry. This is achieved by bundling the reference implementation of the docker container registry, but it is disabled by default as it is quite a hassle to set it up correctly.

Important
It is important to understand that all requests in the GitLab omnibus container will first be processed by an internal nginx server and then distributed to components.

The container registry only works with TLS-encrypted connections, so we need to disable TLS termination by the ingress load balancer and send encrypted traffic directly to the GitLab container. If the NGINX ingress controller is used, this can be done by adding the following annotation to the ingress: nginx.ingress.kubernetes.io/ssl-passthrough: true.

After that, the following gitlab.rb configurations must be applied:

registry['enable'] = true
gitlab_rails['registry_enabled'] = true
registry['token_realm'] = "https://" + ENV['GITLAB_HOST']
gitlab_rails['registry_enabled'] = true
gitlab_rails['registry_host'] = ENV['GITLAB_REGISTRY_HOST']
gitlab_rails['registry_api_url'] = "http://localhost:5000"

registry_external_url 'https://' + ENV['GITLAB_REGISTRY_HOST']
registry_nginx['redirect_http_to_https'] = true
registry_nginx['listen_port'] = 5443
registry_nginx['ssl_certificate'] = "/etc/gitlab/ssl/tls.crt"
registry_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/tls.key"
registry_nginx['real_ip_trusted_addresses'] = ['10.0.0.0/8', '172.16.0.0/12', '192.168.0.0/16']
registry_nginx['server_names_hash_bucket_size'] = 128

Additionally, an S3 bucket (or compatible cloud storage endpoint can be configured so all image layers will not be stored inside a volume, but in a scalable S3

GitLab on Kubernetes: Sidekiq, Gitaly & Puma configuration

Puma (HTTP server for ruby), Sidekiq (job scheduler) and Gitaly (GitLabs Git bridge) can all be started with a custom amount of workers / threads. The best configuration heavily depends on your use-case and the amount of users that need to be supported. A reasonable minimal configuration would be:

puma['worker_processes'] = 2
sidekiq['max_concurrency'] = 9

GitLab on Kubernetes: Prometheus Metrics

The GitLab omnibus package ships with its own prometheus instance inside the image. As a prometheus instance is already present in most Kubernetes clusters the included prometheus can safely be disabled.

prometheus_monitoring['enable'] = false

A ServiceMonitor can be used to tell a running Prometheus instance to monitor the exposed metrics endpoints of GitLabs component on the following ports:

8082 (sidekiq)
9168 (gitlab)
9236 (gitaly)

GitLab on Kubernetes: Backups

Well, backing up GitLab on Kubernetes could be tech guide on its own. The easiest way would be to back up the complete namespace using a backup solution like Velero.

Glasskube GitLab Kubernetes Operator

Meet the Glasskube GitLab Kubernetes Operator - a product of our developer team's frustration with the tedious configuration process, time-consuming setup, and constant troubleshooting associated with GitLab deployment. In response to these challenges, we crafted a solution that simplifies the entire experience. The Glasskube GitLab Kubernetes Operator deploys a fully configured GitLab instance with all features neatly abstracted through a Custom Resource Definition (CRD). Thanks to the Operator, the days of spending excessive time on setup and updates are over. Now, you can effortlessly spin up new GitLab instances within a mere 5 minutes. Try it out and give us feedback!

Install the Glasskube operator

The first step is to install Glasskube via its helm chart:

helm repo add glasskube https://charts.glasskube.eu/
helm repo update
helm install my-glasskube-operator glasskube/glasskube-operator

The full documentation can be found in our Getting started documentation.

Deploy GitLab

Important
A DNS entry must be set on the LoadBalancer or the Ingress Host. SSL certificates are
automatically generated by LoadBalancer or cert-manager if a ClusterIssuer is configured.

gitlab.yaml

apiVersion: "v1"
kind: "Secret"
metadata:
  name: "gitlab-smtp"
stringData:
  username: "..."
  password: "..."
---
apiVersion: v1
kind: Secret
metadata:
  name: gitlab-registry-secret
stringData:
  accessKey: "..."
  secretKey: "..."
---
apiVersion: "glasskube.eu/v1alpha1"
kind: "Gitlab"
metadata:
  name: "gitlab"
spec:
  host: "gitlab.mycompany.eu"
  sshEnabled: true
  sshHost: "ssh.gitlab.mycompany.eu"
  smtp:
    host: "..."
    port: 465
    fromAddress: "noreply+gitlab@mycompany.eu"
    authSecret:
      name: "gitlab-smtp"
    tlsEnabled: true
  registry:
    host: "registry.gitlab.mycompany.eu"
    storage:
      s3:
        bucket: gitlab-registry
        accessKeySecret:
          name: gitlab-registry-secret
          key: accessKey
        secretKeySecret:
          name: gitlab-registry-secret
          key: secretKey
        region: ...

kubectl apply -f gitlab.yaml

That's it!
The complete custom resource documentation can be found in the Glasskube documentation
about GitLab

Deploy GitLab Runner on Kubernetes

Runners on GitLab are execution agents that power continuous integration and continuous delivery (CI/CD) pipelines.
They're responsible for running jobs, which are the individual steps or tasks within a pipeline.

The Glasskube Gitlab Kubernetes Operator makes it as simple as it gets to add runners to your Gitlab. First a new runner needs to be created via https://{{host}}/admin/runners/new. After that these runner tokens can just be added to gitlab.yaml spec and the Glasskube Kubernetes Operator will automatically spawn and connect these runners with the Gitlab instance.

  runners:
    - token: glrt-xxxxXX-xxxxxXXXXX # can be generated at https://{{host}}/admin/runners/new

The complete custom resource documentation can be found in the Glasskube documentation about GitLab runner

Now the installation is complete. Updates to the Kubernetes operator will automatically update GitLab.

Conclusion

Deploying a GitLab instance on Kubernetes for less than a thousand users shouldn't be done with GitLabs cloud native hybrid helm charts but rather with a special purposed installation of the GitLab Omnibus package in combination with cloud native infrastructure. The Glasskube Kubernetes operator takes care of that.

Star Glasskube: