Rig.dev it's an open source application platform to simplify developers experience with Kubernetes
Rig.dev offers an open-source application platform for Kubernetes as a free self-hosted solution or as a paid managed platform. The source code is available in their Github repositories and it's licensed under Apache 2.0 license.
The purpose is to help developers to work in their own environments with elevated application abstractions, while still leveraging Kubernetes's reliability, portability, and scalability.
One of the key features is a developer-friendly deployment engine, which simplifies the process of rolling out, managing, debugging and scaling applications. Also, it has a foundational APIs for user management, authentication, storage, and database integrations.
All of the above can be managed through a Dashboard, CLI, also has several CI/CD pipelines which integrate Rig.dev with GitHub Actions almost natively.
The logic is structured under "Capsules", described as:
A Capsule contains a bundle of resources which will be deployed as a unit. Those resources are
- A Docker image
- Environment variables
- Networking configuration (load balancer/ingress)
- Networking middleware to handle e.g. authentication
- Number of replicas
If you are familiar with Kubernetes, Capsules can be thought of as containing everything (deployment, service, ingress, etc.) needed to run and manage your application.
Read the docs, or just try it our using a local KinD cluster using their script:
#!/usr/bin/env bash
set -e
parent_path=$( cd "$(dirname "${BASH_SOURCE[0]}")" ; pwd -P )
KIND="${KIND:=kind}"
KUBECT="${KUBECTL:=kubectl --context kind-rig}"
HELM="${HELM:=helm --kube-context kind-rig}"
# Create kind cluster
${KIND} get clusters | grep "^rig$" || \
cat <<EOF | ${KIND} create cluster --name rig --config=-
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
extraPortMappings:
- containerPort: 30000
hostPort: 30000
listenAddress: "127.0.0.1"
protocol: TCP
EOF
# Ensure rig-system namespace exists
${KUBECTL} get namespace rig-system || \
${KUBECTL} create namespace rig-system
# Install docker registry in rig-system namespace
${KUBECTL} apply -n rig-system \
-f "${parent_path}/../../cmd/rig/cmd/dev/kind/registry.yaml"
# Ensure required repositories are available
${HELM} repo list | grep '^jetstack\s*https://charts.jetstack.io\s*$' || \
${HELM} repo add jetstack https://charts.jetstack.io
${HELM} repo list | grep '^metrics-server\s*https://kubernetes-sigs.github.io/metrics-server\s*$' || \
${HELM} repo add metrics-server https://kubernetes-sigs.github.io/metrics-server
${HELM} repo update
# Install cert-manager
${HELM} upgrade --install cert-manager jetstack/cert-manager \
--namespace cert-manager \
--create-namespace \
--version v1.13.0 \
--set installCRDs=true
# Install metrics-server
${HELM} upgrade --install metrics-server metrics-server/metrics-server \
--namespace kube-system \
--set args={--kubelet-insecure-tls}

Related content
High severity Github Actions exploit: hackerbot-claw uses your ci/cd as a "pwn-as-a-service" platform
overview It turns out that automating your workflows also makes it incredibly easy for attackers to automate your demise. An autonomous attack campaign, tracked as "hackerbot-claw," is currently prowling public repositories. Its mission? Finding insecure GitHub Actions workflows and turning them into gateways for arbitrary code execution and
Read the full post →
Mission Center: A new and great app for monitoring your Linux desktop
Let’s face it: top is for the masochists, and htop is for the people who want to feel like they’re in The Matrix. But sometimes, you just want to see your CPU melting in high definition without squinting at an ASCII bar chart. Enter Mission Center, a modern,