### Bash Example for Common Use Case

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/templates/service-config-guide-template.md

Provides an example bash command or configuration snippet for a common use case of the service.

```bash
kubectl apply -f deployment.yaml
```

--------------------------------

### Example Secret Configuration (INI)

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/templates/service-config-guide-template.md

Demonstrates an example of a secret configuration in INI format, often used for application-specific settings or external service credentials.

```ini
[database]
host = localhost
port = 5432
user = db_user
password = db_password
```

--------------------------------

### Example YAML Configuration Block

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/templates/service-config-guide-template.md

Illustrates an example configuration block for a service, often used in Kubernetes manifests. This block defines various settings and parameters for the service's operation.

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: example-config
data:
  setting1: "value1"
  setting2: |
    line1
    line2
```

--------------------------------

### LogQL Query Examples

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/loki-config-guide.md

Provides examples of LogQL queries for filtering and analyzing logs in Loki. Covers basic filtering, error log identification, rate calculations, and structured data extraction. Requires a Loki instance with logs.

```bash
# Query logs from specific namespace
{namespace="myapp"}

# Filter by log level
{namespace="myapp"} |= "ERROR"

# Rate query for error logs
rate({namespace="myapp"} |= "ERROR" [5m])

# Extract and count HTTP status codes
{job="nginx"} | json | __error__ = "" | line_format "{{.status}}" | unwrap status | rate[5m]
```

--------------------------------

### Example Application Credentials JSON

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/iac/README.md

This JSON object represents an example of application credentials generated after creation. It includes fields like `id`, `description`, `project_id`, `expires_at`, and `secret`. The `secret` field is redacted for security.

```json
{
  "id": "f07a1d5ff5254c0b9cda848353169891",
  "description": null,
  "project_id": "4c07654c099f59021ac0166a84648742",
  "expires_at": null,
  "secret": "REDACTED"
}
```

--------------------------------

### Query Loki Logs

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/loki-config-guide.md

Demonstrates how to query logs from Loki using its API. This example fetches the latest 10 logs for the 'kubernetes-pods' job. Requires curl and a running Loki instance.

```bash
# Query logs
curl -G -s "http://localhost:3100/loki/api/v1/query" \
  --data-urlencode 'query={job="kubernetes-pods"}' \
  --data-urlencode 'limit=10'
```

--------------------------------

### Query Tempo Traces (Bash)

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/tempo-config-guide.md

A bash command demonstrating how to query traces from Tempo using its API. It shows an example of searching for traces by service name and limiting the results.

```bash
# Query traces
curl -G -s "http://localhost:3200/api/search" \
  --data-urlencode 'q={service.name="myservice"}' \
  --data-urlencode 'limit=10'
```

--------------------------------

### TraceQL: Complex Query Example (Bash)

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/tempo-config-guide.md

A more complex TraceQL query combining multiple conditions, including service name, HTTP method, and duration. This demonstrates the power of TraceQL for detailed trace analysis.

```bash
# Complex query with multiple conditions
{service.name="frontend" && span.http.method="POST" && duration > 1s}
```

--------------------------------

### OpenTofu Implementation Example for Kube-VIP (HCL)

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/kube-vip-config-guide.md

An example of how Kube-VIP is configured within an OpenTofu (formerly Terraform) module for cluster deployment. It sets local variables for network configuration and Kube-VIP parameters, then passes them to the kubespray cluster module.

```hcl
locals {
  # Network configuration
  subnet_nodes          = "10.2.184.0/22"
  subnet_nodes_oct      = join(".", slice(split(".", split("/", local.subnet_nodes)[0]), 0, 3))
  
  # Reserve VIP outside allocation pool
  allocation_pool_start = "${local.subnet_nodes_oct}.50"
  allocation_pool_end   = "${local.subnet_nodes_oct}.254"
  vrrp_ip              = "${local.subnet_nodes_oct}.10"
  
  # Kube-VIP settings
  kube_vip_enabled     = true
  vrrp_enabled         = true
  use_octavia          = false
  
  # Network interface
  cni_iface            = "enp3s0"
  
  # API configuration
  k8s_api_port         = 443
}

module "kubespray-cluster" {
  source = "github.com/rackerlabs/openCenter.git//install/iac/kubespray?ref=main"
  
  kube_vip_enabled = local.kube_vip_enabled
  vrrp_ip          = local.vrrp_ip
  vrrp_enabled     = local.vrrp_enabled
  use_octavia      = local.use_octavia
  cni_iface        = local.cni_iface
  k8s_api_ip       = module.openstack-nova.k8s_api_ip
  k8s_api_port     = local.k8s_api_port
  
  # ... other configuration
}
```

--------------------------------

### Flux CD Bootstrap and Cluster Onboarding (Bash)

Source: https://context7.com/rackerlabs/opencenter-gitops-base/llms.txt

This section details how to bootstrap Flux CD on a new Kubernetes cluster using the Flux CLI. It covers installing the CLI, bootstrapping Flux with SSH authentication to a Git repository, and verifying the installation. It also includes commands for creating secrets for repository access and checking reconciliation status.

```bash
# Install Flux CLI
curl -s https://fluxcd.io/install.sh | sudo FLUX_VERSION=2.7.0 bash

# Bootstrap Flux with SSH authentication
GIT_REPO="your-org/your-cluster-overlay"
CLUSTER_NAME="prod-cluster"
flux bootstrap git \
  --url=ssh://git@github.com/${GIT_REPO}.git \
  --branch=main \
  --private-key-file=${HOME}/.ssh/${CLUSTER_NAME}_id_ed25519 \
  --path=applications/overlays/${CLUSTER_NAME}

# Verify Flux components
flux get all -A

# Create secret for base repository access
flux create secret git opencenter-base \
  --ssh-key-algorithm=ed25519 \
  --url=ssh://git@github.com/rackerlabs/openCenter-gitops-base.git \
  -n flux-system

# Check reconciliation status
kubectl get kustomization,gitrepositories,helmrepositories,helmreleases -A

# Force reconciliation of a specific resource
flux reconcile helmrelease cert-manager -n cert-manager --with-source
```

--------------------------------

### Create On-Demand Velero Backup (Bash)

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/velero-config-guide.md

Examples of creating on-demand backups using the Velero CLI. Covers backing up the entire cluster, specific namespaces, and setting a time-to-live (TTL) for the backup.

```bash
# Backup entire cluster
velero backup create full-backup

# Backup specific namespace
velero backup create app-backup --include-namespaces myapp

# Backup with TTL
velero backup create temp-backup --ttl 24h
```

--------------------------------

### Example Service Configuration Principles

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/templates/service-standards-template.md

Defines the core principles guiding the configuration of the service. These principles ensure consistency, maintainability, and adherence to best practices.

```text
- [Principle 1]: [Description and rationale]
- [Principle 2]: [Description and rationale]
- [Principle 3]: [Description and rationale]
```

--------------------------------

### Bash Commands for Verification and Troubleshooting

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/templates/service-config-guide-template.md

A collection of bash commands for verifying service status, configuration, testing functionality, and troubleshooting by checking logs.

```bash
# Check service status
kubectl get svc my-service

# Verify configuration
kubectl describe configmap my-config

# Test functionality
curl http://my-service-ip:port/health

# Check logs
kubectl logs -f deployment/my-app
```

--------------------------------

### Check Velero Installation Version (Bash)

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/velero-config-guide.md

Command to check the installed version of Velero. This is a basic verification step to ensure Velero is running and to identify the version for compatibility checks.

```bash
# Check Velero installation
velero version
```

--------------------------------

### Keycloak OIDC Client Configuration Example

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/applications/base/services/headlamp/README.md

Example configuration for setting up a client in Keycloak for Headlamp integration. This includes essential client settings like Client ID, Protocol, Access Type, and Redirect URIs.

```plaintext
Client ID: headlamp
Client Protocol: openid-connect
Access Type: confidential
Valid Redirect URIs: https://headlamp.example.com/oidc-callback
```

--------------------------------

### Example Service Configuration

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/templates/service-standards-template.md

A concrete example of a service's configuration, illustrating how to set up its parameters and options. This serves as a reference for developers and operators.

```yaml
[Service-specific configuration example]
```

--------------------------------

### Restore Velero Backup (Bash)

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/velero-config-guide.md

Examples of restoring data from Velero backups using the CLI. Demonstrates restoring an entire backup, specific namespaces, and restoring to a different namespace.

```bash
# List available backups
velero backup get

# Restore entire backup
velero restore create --from-backup full-backup

# Restore specific namespace
velero restore create --from-backup app-backup --include-namespaces myapp

# Restore to different namespace
velero restore create --from-backup app-backup --namespace-mappings myapp:myapp-restored
```

--------------------------------

### TraceQL: Filter Traces by Duration (Bash)

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/tempo-config-guide.md

An example TraceQL query to filter traces based on their duration. This allows users to identify slow-running operations within a service.

```bash
# Filter by duration
{service.name="myservice" && duration > 100ms}
```

--------------------------------

### TraceQL: Find Traces by Service Name (Bash)

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/tempo-config-guide.md

An example of a TraceQL query to find traces associated with a specific service name. This is a fundamental query for isolating trace data.

```bash
# Find traces by service name
{service.name="myservice"}
```

--------------------------------

### Push Image to Harbor using Docker CLI

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/harbor-config-guide.md

Demonstrates the bash commands required to tag a local Docker image, log in to Harbor, and push the image to the registry.

```bash
# Tag image for Harbor
docker tag myapp:latest harbor.example.com/library/myapp:latest

# Login to Harbor
docker login harbor.example.com

# Push image
docker push harbor.example.com/library/myapp:latest
```

--------------------------------

### Kubernetes Node Tolerations and Selectors Example

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/service-standards-and-lifecycle.md

An example Kubernetes manifest snippet demonstrating node tolerations and selectors. It includes tolerations for 'workload=system' and node selectors for 'workload: system', along with node affinity to match nodes with the 'storage' class.

```yaml
spec:
  tolerations:
    - key: workload
      operator: Equal
      value: system
      effect: NoSchedule
  nodeSelector:
    workload: system
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: class
                operator: In
                values: ["storage"]
```

--------------------------------

### TraceQL: Search by Span Attributes (Bash)

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/tempo-config-guide.md

An example TraceQL query to search for traces based on specific span attributes, such as an HTTP status code. This is useful for debugging errors or specific request types.

```bash
# Search by span attributes
{span.http.status_code=500}
```

--------------------------------

### Bootstrap Flux for GitOps

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/iac/README.md

Installs Flux and bootstraps it to manage the Kubernetes cluster based on a Git repository. This involves setting up SSH keys, configuring the KUBECONFIG environment variable, and running the Flux bootstrap command.

```bash
curl flux.sh | kubectl apply -f -
# flux bootstrap git --url=<your-git-repo-url> --branch=<your-branch> --ssh-key-file=<path-to-ssh-private-key>

```

--------------------------------

### Sample Service Configuration (YAML)

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/templates/service-standards-template.md

An example of a service configuration file, demonstrating key parameters and structure. This is used for defining service-specific settings and operational parameters.

```yaml
[example configuration relevant to this service]
```

--------------------------------

### Kubernetes Debugging Commands

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/templates/service-readme-template.md

Useful kubectl commands for debugging issues with the deployed service. Provides examples for general command execution, options, and describing resources.

```bash
# Debug command 1
kubectl [command] [options]

# Debug command 2
kubectl [command] [options]

# Check configuration
kubectl describe [resource] [name] -n [namespace]
```

--------------------------------

### Service Configuration Override Example

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/templates/service-readme-template.md

An example of a Kustomization patch file used to override service configurations. This typically involves creating or modifying a ConfigMap with specific key-value pairs for the service.

```yaml
# [service-name]-values.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: [service-name]-config
data:
  [key]: [value]
  [key2]: [value2]
```

--------------------------------

### Example HelmRelease for Tempo Service

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/service-standards-and-lifecycle.md

This HelmRelease manifest configures the deployment of the Tempo service using Flux. It specifies the Helm chart details, installation and upgrade remediation strategies, dependencies on other services (like Loki), and how to source custom values.

```yaml
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: tempo
  labels:
    app.kubernetes.io/name: tempo
    app.kubernetes.io/part-of: observability
spec:
  interval: 5m
  chart:
    spec:
      chart: tempo
      version: 1.2.3
      sourceRef:
        kind: HelmRepository
        name: grafana
  install:
    remediation:
      retries: 3
  upgrade:
    remediation:
      retries: 3
  dependsOn:
    - name: loki
  valuesFrom:
    - kind: Secret
      name: tempo-values
```

--------------------------------

### Describe Velero Node Agent DaemonSet (Bash)

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/velero-config-guide.md

Command to get detailed information about the Velero node agent DaemonSet. This helps in verifying its configuration, status, and any potential issues with its deployment across nodes.

```bash
# Verify node agent configuration
kubectl describe daemonset -n velero node-agent
```

--------------------------------

### Apply Terraform Configuration

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/iac/README.md

This command applies the Terraform configuration, creating or updating infrastructure resources as defined in the project. It should be run after a successful `terraform init`.

```bash
# terraform apply
```

--------------------------------

### Troubleshoot HelmRelease Installation Issues

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/adding-new-service.md

Provides commands to debug a HelmRelease that is stuck in an installing state. It involves describing the HelmRelease resource to view its status and events, and checking the logs of the helm-controller for detailed error messages.

```bash
kubectl describe helmrelease my-service -n my-service
kubectl logs -n flux-system deploy/helm-controller
```

--------------------------------

### Verify Cluster Policies (Bash)

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/kyverno-config-guide.md

Lists all ClusterPolicy resources in the Kubernetes cluster. This command helps in verifying that the intended policies have been applied and are recognized by Kyverno.

```bash
kubectl get clusterpolicy
```

--------------------------------

### Check Kyverno Pods (Bash)

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/kyverno-config-guide.md

Verifies that Kyverno pods are running correctly in the `kyverno` namespace. This is a fundamental check to ensure the Kyverno system is operational.

```bash
kubectl get pods -n kyverno
```

--------------------------------

### Example Node Selection Strategy (YAML)

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/templates/service-standards-template.md

Defines the strategy for selecting nodes where the service will be deployed, including tolerations and node selectors. This ensures the service runs on appropriate infrastructure.

```yaml
[Service-specific tolerations and node selectors]
```

--------------------------------

### Initialize OpenTofu Files for New Cluster

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/iac/README.md

This snippet demonstrates the manual copying of base Terraform (OpenTofu) files to initialize a new cluster's configuration. It involves copying the 'init' directory and creating necessary subdirectories for cluster management.

```bash
# cd /etc/openCenter
# cp -r infrastructure/init infrastructure/clusters/demo-cluster
# mkdir -p applications/overlays/demo-cluster/managed-services/calico/helm-values
# cd infrastructure/clusters/demo-cluster
```

--------------------------------

### Create Custom ServiceMonitor

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/kube-prometheus-stack-config-guide.md

Example of a Kubernetes ServiceMonitor resource definition. It specifies how Prometheus should discover and scrape metrics from a service identified by specific labels.

```yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: myapp-metrics
  namespace: observability
spec:
  selector:
    matchLabels:
      app: myapp
  endpoints:
  - port: metrics
    interval: 30s
    path: /metrics
```

--------------------------------

### Example Secret Configuration (YAML)

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/templates/service-config-guide-template.md

Defines the structure for a Kubernetes secret, including stringData for sensitive information. This is used to store and manage secrets securely.

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
stringData:
  username: "admin"
  password: "s3cr3tP@ssw0rd"
```

--------------------------------

### Create Grafana Admin Secret

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/kube-prometheus-stack-config-guide.md

Defines a Kubernetes Secret resource to store the Grafana admin password. This is required for initial Grafana setup and secure access.

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: grafana-admin
  namespace: observability
type: Opaque
stringData:
  admin-password: your-secure-password
```

--------------------------------

### Kubernetes Deployment Labels Example

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/service-standards-and-lifecycle.md

This YAML snippet demonstrates a set of standard Kubernetes metadata labels used for application deployment. These labels provide information about the application's name, instance, version, component, ownership, tier, data sensitivity, RTO/RPO, SLA, and backup profile.

```yaml
metadata:
  labels:
    app.kubernetes.io/name: loki
    app.kubernetes.io/instance: loki-prod
    app.kubernetes.io/version: "3.1.0"
    app.kubernetes.io/component: indexing
    app.kubernetes.io/part-of: observability
    app.kubernetes.io/managed-by: fluxcd
    opencenter.io/owner: sre@opencenter.io
    opencenter.io/tier: platform
    opencenter.io/data-sensitivity: internal
    opencenter.io/rto: 4h
    opencenter.io/rpo: 1h
    opencenter.io/sla: "99.9"
    opencenter.io/backup-profile: daily
```

--------------------------------

### Troubleshooting and Verification Commands for Flux CD and Kubernetes

Source: https://context7.com/rackerlabs/opencenter-gitops-base/llms.txt

A collection of common kubectl and flux commands for monitoring Flux reconciliation, debugging deployment issues, and verifying service health. Includes commands for checking resource status, viewing controller logs, describing HelmReleases, forcing reconciliation, checking secrets, verifying LoadBalancer services, checking policy violations, and validating kustomization builds.

```bash
# Check all Flux resources status
kubectl get kustomization,gitrepositories,helmrepositories,helmreleases -A

# View Flux controller logs
kubectl logs -n flux-system deploy/helm-controller --tail=100
kubectl logs -n flux-system deploy/kustomize-controller --tail=100
kubectl logs -n flux-system deploy/source-controller --tail=100

# Describe HelmRelease for detailed status
kubectl describe helmrelease cert-manager -n cert-manager

# Force reconciliation with source update
flux reconcile kustomization cert-manager-base -n flux-system --with-source
flux reconcile helmrelease cert-manager -n cert-manager

# Check secret contents (base64 decoded)
kubectl get secret cert-manager-values-base -n cert-manager -o jsonpath='{.data.hardened\.yaml}' | base64 -d

# Verify MetalLB LoadBalancer services
kubectl get svc --field-selector spec.type=LoadBalancer -A
kubectl get ipaddresspool,l2advertisement -n metallb-system

# Check Kyverno policy violations
kubectl get policyreport -A
kubectl get clusterpolicyreport

# Validate kustomization builds locally
kubectl kustomize applications/base/services/cert-manager

```

--------------------------------

### Test Harbor Connectivity and Docker Login

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/harbor-config-guide.md

Provides bash commands to test Harbor's API endpoint and verify Docker login credentials. It also shows how to check Harbor core logs for troubleshooting.

```bash
# Test Harbor connectivity
curl -k https://harbor.example.com/api/v2.0/systeminfo

# Test Docker login
docker login harbor.example.com

# Check Harbor core logs
kubectl logs -n harbor deployment/harbor-core
```

--------------------------------

### Get Velero Volume Snapshot Locations (Bash)

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/velero-config-guide.md

Command to retrieve information about configured volume snapshot locations in Velero. This helps verify that Velero can utilize the specified snapshot providers.

```bash
# Check volume snapshot location
velero snapshot-location get
```

--------------------------------

### Configure External Database for Harbor

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/harbor-config-guide.md

Configures Harbor to use an external PostgreSQL database for better scalability and isolation. This setup separates databases for core, notary server, and notary signer components.

```yaml
database:
  type: external
  external:
    host: postgres-cluster
    port: 5432
    username: harbor
    password: <password>
    coreDatabase: registry
    notaryServerDatabase: notaryserver
    notarySignerDatabase: notarysigner
```

--------------------------------

### Initialize Terraform Deployment

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/iac/README.md

This command initializes the Terraform project, downloading necessary modules. It mentions that modules in Git can be accessed using SSH keys (e.g., `git@github.com:rackerlabs/openCenter.git`) or a Git Token (`github.com/rackerlabs/openCenter.git`).

```bash
# terraform init
```

--------------------------------

### Verify Tempo Ingester Readiness (Bash)

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/tempo-config-guide.md

A bash command to verify the readiness of the Tempo ingester by executing a command within the ingester pod to check its ready status via a local HTTP request. This is part of troubleshooting storage backend issues.

```bash
# Verify storage configuration
kubectl exec -n observability deployment/tempo-querier -- \
  wget -qO- 'http://localhost:3200/ready'
```

--------------------------------

### Create Harbor Project via API

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/harbor-config-guide.md

Shows a bash command using curl to create a new project in Harbor via its API. It includes the necessary headers, authentication, and JSON payload for the request.

```bash
# Create new project
curl -X POST "https://harbor.example.com/api/v2.0/projects" \
  -H "Content-Type: application/json" \
  -u "admin:password" \
  -d '{
    "project_name": "myproject",
    "public": false,
    "storage_limit": -1
  }'
```

--------------------------------

### Secret for ACME Account Private Key

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/cert-manager-config-guide.md

Represents a Kubernetes Secret used to store the private key for the ACME account. While cert-manager can generate this automatically, pre-creating it allows for account portability and consistency across installations.

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: letsencrypt-prod
  namespace: cert-manager
type: Opaque
data:
  tls.key: <base64-encoded-private-key>
```

--------------------------------

### Ansible Playbook for Block Device Configuration

Source: https://context7.com/rackerlabs/opencenter-gitops-base/llms.txt

This Ansible playbook configures and mounts block devices on target hosts. It verifies device existence, formats filesystems with specified types and labels, and mounts them using their UUIDs. It relies on variables defined in `disk_config` and uses `community.general.filesystem` and `ansible.posix.mount` modules.

```yaml
- name: Configure and mount block devices
  hosts: all
  become: true
  tasks:
    - name: Verify devices exist
      ansible.builtin.stat:
        path: "{{ item.device }}"
      register: device_checks
      failed_when: not device_checks.stat.exists or not device_checks.stat.isblk
      loop: "{{ disk_config }}"

    - name: Format filesystems
      community.general.filesystem:
        fstype: "{{ item.item.filesystem }}"
        dev: "{{ item.item.device }}"
        opts: "-L {{ item.item.label }}"
        force: false
      loop: "{{ existing_labels.results }}"
      when: item.rc != 0 or item.stdout != item.item.label

    - name: Mount filesystems
      ansible.posix.mount:
        path: "{{ item.item.mountpoint }}"
        src: "UUID={{ item.stdout }}"
        fstype: "{{ item.item.filesystem }}"
        opts: defaults,nofail
        state: mounted
      loop: "{{ uuids.results }}"
```

--------------------------------

### Configure Encrypted StorageClass (Kubernetes YAML)

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/longhorn-config-guide.md

This YAML defines a StorageClass for Longhorn that enables volume encryption. It specifies the number of replicas and sets the 'encrypted' parameter to 'true'. Note that enabling encryption requires additional setup using tools like cryptsetup on the underlying nodes.

```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-encrypted
provisioner: driver.longhorn.io
parameters:
  numberOfReplicas: "3"
  encrypted: "true"
  # Encryption requires additional setup with cryptsetup
```

--------------------------------

### Test Tempo API Readiness (Bash)

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/tempo-config-guide.md

A bash command to test the readiness of the Tempo query frontend API. It port-forwards to the query frontend service and then sends a request to the /ready endpoint.

```bash
# Test Tempo API
kubectl port-forward -n observability svc/tempo-query-frontend 3200:3200
curl http://localhost:3200/ready
```

--------------------------------

### Deploy Calico CNI using Helm

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/iac/README.md

This command deploys the Calico Container Network Interface (CNI) using Helm. It adds the Calico Helm repository, upgrades or installs the `tigera-operator`, and specifies an override values file for custom configuration. The namespace `tigera-operator` is created if it doesn't exist.

```bash
# helm repo add projectcalico https://docs.tigera.io/calico/charts
# helm upgrade --install calico projectcalico/tigera-operator --namespace tigera-operator -f ../../../applications/overlays/dev-cluster/services/calico/helm-values/override_values.yaml --create-namespace
```

--------------------------------

### S3 Bucket Access Policy for OpenTofu State (JSON)

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/iac/README.md

An IAM policy defining permissions for accessing an S3 bucket used to store OpenTofu state files. It allows listing the bucket contents and performing GET, PUT, and DELETE operations on state files and lock files within a specific cluster's directory structure.

```json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::BUCKET_NAME"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject"
            ],
            "Resource": [
                "arn:aws:s3:::BUCKET_NAME/*/tfstate/terraform.tfstate"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::BUCKET_NAME/*/tfstate/terraform.tfstate.tflock"
            ]
        }
    ]
}
```

--------------------------------

### Sample Architecture Decision Record (ADR-001) (Markdown)

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/service-standards-and-lifecycle.md

An example of a completed Architecture Decision Record (ADR) using Markdown. This specific ADR, 'Use Redis for Session Caching', details the context, decision, consequences, and alternatives considered for adopting Redis.

```markdown
# ADR-001: Use Redis for Session Caching

- **Status:** Accepted (2025-09-29)
- **Context:** Need a distributed cache for user sessions. Options: in-process cache, Redis, Memcached.
- **Decision:** Adopt Redis for session storage to balance latency, HA, and operations.
- **Consequences:**
  - Redis offers clustering, persistence, and managed service support.
  - Adds external dependency; services must handle cache outages gracefully.
- **Alternatives:** In-process cache (lacked cross-instance coherence); Memcached (no persistence, fewer data structures).
```

--------------------------------

### List All Deployments in All Namespaces

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/service-standards-and-lifecycle.md

A command to list all deployments across all namespaces using kubectl. It outputs the namespace and name for each deployment, helpful for detecting workloads lacking placement rules.

```bash
kubectl get deploy -A -o=jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name} {end}'
```

--------------------------------

### Install Ansible Collection

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/adding-windows-nodes.md

This command installs the Ansible collections specified in the `requirements.yml` file. Ensure the `requirements.yml` file is correctly formatted and accessible.

```bash
ansible-galaxy collection install -r requirements.yml
```

--------------------------------

### Render Helm Manifests Locally

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/adding-new-service.md

Demonstrates how to use the `helm template` command to render the manifests for a Helm chart locally, using a specified values file. This is useful for inspecting the final Kubernetes resources before applying them to the cluster.

```bash
helm template my-service-repo/my-service --values /tmp/values.yaml
```

--------------------------------

### Set Up Trace Sampling Configuration

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/tempo-config-guide.md

Configures trace sampling within Tempo. This includes enabling the logging of received traces and setting global overrides for maximum traces per user and maximum bytes per trace to manage storage and performance.

```yaml
tempo:
  distributor:
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: 0.0.0.0:4317
    # Sampling configuration
    log_received_traces: true
  global_overrides:
    max_traces_per_user: 10000
    max_bytes_per_trace: 5000000  # 5MB
```

--------------------------------

### Verifying Kube-VIP Deployment (Bash)

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/kube-vip-config-guide.md

Provides bash commands to verify the Kube-VIP deployment. This includes checking for kube-vip pods, testing API server accessibility via curl, and identifying the active node holding the VIP.

```bash
# Check kube-vip pods on control plane nodes
kubectl get pods -n kube-system | grep kube-vip

# Verify VIP is responding
curl -k https://<vrrp_ip>:<k8s_api_port>/healthz

# Check which node is currently holding the VIP
ip addr show | grep <vrrp_ip>
```

--------------------------------

### Install Windows Worker Node Ansible Collection

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/adding-windows-nodes.md

This YAML file defines the Ansible collections required for configuring Windows nodes, specifically referencing the 'opencenter-windows' collection from GitHub. The subsequent bash command installs this collection using `ansible-galaxy`.

```yaml
---
collections:
  - name: https://github.com/rackerlabs/opencenter-windows.git
    type: git
    version: main
```

--------------------------------

### Flux Kustomization for Service Deployment (YAML)

Source: https://context7.com/rackerlabs/opencenter-gitops-base/llms.txt

This YAML defines Flux Kustomization resources for deploying services to Kubernetes clusters. It shows how to configure base Kustomizations that depend on Git repositories and overlays that can include SOPS decryption for secrets. These resources manage application deployments and ensure they align with the GitOps configuration.

```yaml
# applications/overlays/<cluster>/services/fluxcd/cert-manager.yaml
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: cert-manager-base
  namespace: flux-system
spec:
  dependsOn:
    - name: sources
      namespace: flux-system
  interval: 5m
  retryInterval: 1m
  timeout: 10m
  sourceRef:
    kind: GitRepository
    name: opencenter-cert-manager
    namespace: flux-system
  path: applications/base/services/cert-manager
  targetNamespace: cert-manager
  prune: true              # Remove resources not in Git
  healthChecks:
    - apiVersion: helm.toolkit.fluxcd.io/v2
      kind: HelmRelease
      name: cert-manager
      namespace: cert-manager
  commonMetadata:
    labels:
      app.kubernetes.io/part-of: cert-manager
      app.kubernetes.io/managed-by: flux
---
# Overlay with SOPS decryption for encrypted secrets
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: cert-manager-override
  namespace: flux-system
spec:
  dependsOn:
    - name: cert-manager-base
  decryption:
    provider: sops
    secretRef:
      name: sops-age      # Contains age private key
  sourceRef:
    kind: GitRepository
    name: flux-system
  path: ./applications/overlays/<cluster>/services/cert-manager
  targetNamespace: cert-manager
```

--------------------------------

### Kustomization for Consuming Base Manifests

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/templates/service-readme-template.md

Example Kustomization configuration to include the base manifests from a remote Git repository. It specifies the remote resource URL and a patch file for applying service-specific values.

```yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - https://github.com/[org]/[repo]//applications/base/services/[service-name]?ref=[version]

patchesStrategicMerge:
  - [service-name]-values.yaml
```

--------------------------------

### Get Kubernetes Nodes Status via Ansible

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/resize-controlplane-nodes.md

Uses Ansible to execute 'kubectl get nodes' on a specific control plane node ('prosys.dev.dfw3-cp0'). This verifies if the Kubernetes API server is accessible from a control plane node, which is crucial when troubleshooting cluster unresponsiveness.

```bash
# ansible prosys.dev.dfw3-cp0 --become -m shell -a 'kubectl get nodes'
prosys.dev.dfw3-cp0 | CHANGED | rc=0 >>
NAME                  STATUS   ROLES           AGE   VERSION
prosys.dev.dfw3-cp0   Ready    control-plane   13d   v1.32.8
prosys.dev.dfw3-cp1   Ready    control-plane   13d   v1.32.8
prosys.dev.dfw3-cp2   Ready    control-plane   13d   v1.32.8
prosys.dev.dfw3-wn0   Ready    <none>          13d   v1.32.8
prosys.dev.dfw3-wn1   Ready    <none>          13d   v1.32.8
prosys.dev.dfw3-wn2   Ready    <none>          13d   v1.32.8
prosys.dev.dfw3-wn3   Ready    <none>          13d   v1.32.8
```

--------------------------------

### Check Longhorn Backup Configuration and Logs

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/longhorn-config-guide.md

Employs kubectl commands to inspect Longhorn's backup target settings, list available backups, and retrieve logs related to backup operations. This helps in troubleshooting backup and restore failures.

```bash
# Check backup target settings
kubectl get setting -n longhorn-system backup-target

# List available backups
kubectl get backups -n longhorn-system

# Check backup job logs
kubectl logs -n longhorn-system -l app=longhorn-manager | grep backup
```

--------------------------------

### Example Service Architecture Description

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/templates/service-standards-template.md

A placeholder for describing the architecture of the service. This can include diagrams or textual descriptions of components and their interactions.

```text
[Architecture diagram or description]
```

--------------------------------

### Create and Apply a SealedSecret from Command Line

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/sealed-secrets-config-guide.md

This bash script demonstrates how to create a Kubernetes Secret, encrypt it using `kubeseal`, and then apply the resulting SealedSecret to the cluster. It pipes the secret definition to `kubeseal` for encryption and then uses `kubectl apply` to deploy it.

```bash
# Create secret and encrypt it
echo -n mypassword | kubectl create secret generic mysecret --dry-run=client --from-file=password=/dev/stdin -o yaml | kubeseal -o yaml > mysealedsecret.yaml

# Apply the sealed secret
kubectl apply -f mysealedsecret.yaml

# Verify secret was created
kubectl get secret mysecret
```

--------------------------------

### Check Instrumentation Status with kubectl

Source: https://github.com/rackerlabs/opencenter-gitops-base/blob/main/docs/opentelemetry-kube-stack-config-guide.md

Command to describe the 'default-instrumentation' resource, which helps in verifying the status and configuration of auto-instrumentation.

```bash
# Check instrumentation status
kubectl describe instrumentation default-instrumentation
```