Deploying the AGH3 Chart
Relevant source files
The following files were used as context for generating this wiki page:
The agh3 Helm chart is a comprehensive package for deploying the ArgusHack3 application suite on a Kubernetes cluster. It is defined as an application type chart, meaning it bundles all necessary templates and dependencies to run the full application. The chart encapsulates various microservices, including captain, controller, ui, and report, along with their required backend services like databases and message queues.
Configuration and customization of the deployment are managed through the values.yaml file, which allows users to enable or disable components, configure internal and external services, set resource limits, and manage application secrets. This modular approach provides flexibility for different deployment environments, from all-in-one internal setups to integrations with existing external infrastructure.
Sources: charts/agh3/Chart.yaml:1-7, charts/agh3/README.md, charts/agh3/values.yaml
Chart Architecture
The AGH3 chart deploys a microservices-based architecture. The core application logic is divided into several modules that can be independently enabled and configured.
The following diagram illustrates the high-level architecture of the deployed components and their interactions.
This diagram shows the main user-facing components (UI, Captain) and the backend services they rely on.
Sources: charts/agh3/values.yaml:589-852, charts/agh3/templates/captain/captain-deployment.yml:132-181, charts/agh3/templates/report/report-deployment.yml:22-24
Dependencies
The agh3 chart manages its complex backend requirements by depending on other Helm charts. These dependencies are conditionally enabled based on settings in values.yaml, allowing a user to either deploy them as part of the agh3 release or connect to external, pre-existing services.
Sources: [charts/agh3/Chart.yaml:23-24]
The following diagram shows the conditional dependencies of the AGH3 chart.
This diagram illustrates that services like PostgreSQL and Minio are only installed if their respective *.internal.enabled flags are set to true.
Sources: [charts/agh3/Chart.yaml:25-61]
Dependency Summary
| Chart Name | Version | Repository | Condition for Deployment |
|---|---|---|---|
postgresql | 12.1.2 | https://charts.bitnami.com/bitnami | db.internal.enabled |
minio | 14.8.6 | https://charts.bitnami.com/bitnami | minio.internal.enabled |
rabbitmq | 13.0.0 | https://charts.bitnami.com/bitnami | rabbitmq.internal.enabled |
redis | 20.1.0 | https://charts.bitnami.com/bitnami | redis.enabled |
postfix | 0.1.4 | https://charts.lkc-lab.com | postfix.enabled |
grafana | 9.3.0 | https://grafana.github.io/helm-charts | grafana.enabled |
grafana-loki | 6.0.2 | https://charts.bitnami.com/bitnami | grafana-loki.enabled |
grafana-tempo | 4.0.14 | https://charts.bitnami.com/bitnami | grafana-tempo.enabled |
memcached | 7.9.4 | https://charts.bitnami.com/bitnami | memcached.enabled |
common | 2.19.1 | https://charts.bitnami.com/bitnami | (Always included) |
Sources: [charts/agh3/Chart.yaml:25-61]
Configuration
The deployment is configured using charts/agh3/values.yaml. Key configuration sections are detailed below.
Global Parameters
Global parameters apply to the chart and its sub-charts, providing a centralized way to configure aspects like the image registry and proxy settings.
| Parameter | Description | Default Value |
|---|---|---|
global.imageRegistry | Global Docker Image registry. | registry.lkc-lab.com |
global.imagePullSecrets | An array of secret names for pulling images. | ["lkc-registry"] |
global.proxy.enabled | Enables the use of a proxy for outbound connections. | false |
global.proxy.httpProxy | The HTTP proxy URL. | "" |
global.proxy.httpsProxy | The HTTPS proxy URL. | "" |
Sources: charts/agh3/values.yaml:8-23, [charts/agh3/README.md:15-28]
Backend Services Configuration
For services like PostgreSQL, Minio, and RabbitMQ, the chart supports two modes: internal and external.
internal: The chart deploys the service using its corresponding dependency chart.external: The chart connects to an existing service, and the user must provide connection details (host, port, credentials).
# Example for PostgreSQL
db:
connection:
# Set to 'internal' or 'external'
type: internal
# Required if type is 'external'
host: database.example.com
port: 5432
user: argushack
password: ""
internal:
# Enables the bitnami/postgresql sub-chart
enabled: true
Sources: [charts/agh3/values.yaml:110-132]
Database Initialization
If an internal PostgreSQL is used (db.internal.enabled: true), an initialization process can be triggered to create databases and roles for the various application modules. This is controlled by postgresql.primary.initdb.enabled.
The initialization logic, as seen in related chart templates, typically involves a ConfigMap containing SQL scripts that are executed by an init container in the PostgreSQL pod. These scripts iterate through the modules defined in values.yaml and create a corresponding database and user for each one that requires it.
Sources: charts/agh3/values.yaml:200-207, [charts/agh2/templates/db/postgres-init-configmap.yml:40-84]
Application Modules
The chart deploys several application modules, each as a separate Kubernetes Deployment.
AGH3-Captain
The captain module is a central component of the application. Its deployment includes init containers to ensure all its dependencies (PostgreSQL, Redis, Minio, RabbitMQ) are available before it starts.
The following diagram shows the startup sequence for the Captain pod.
This sequence ensures that Captain only starts after its critical backend services are reachable.
Sources: [charts/agh3/templates/captain/captain-deployment.yml:14-87]
Key environment variables for the Captain container include:
| Variable | Description | Source |
|---|---|---|
DB_Conn | Connection string for PostgreSQL. | From secret capt-db-secret |
REDIS_URL | URL for the Redis master. | redis-master.$(NAMESPACE).svc.cluster.local:6379 |
MINIO_URL | URL for the Minio service. | From secret minio-secret |
RABBITMQ_Conn | Connection string for RabbitMQ. | From secret agh-rabbitmq-secret-connection |
REPORT_URL | Internal URL for the Report service. | http://report.$(NAMESPACE).svc.cluster.local:80 |
SMTP_HOST | Internal host for the Postfix service. | postfix.$(NAMESPACE).svc.cluster.local |
Sources: charts/agh3/templates/captain/captain-deployment.yml:132-181, [charts/agh3/values.yaml:603-680]
AGH3-UI
The ui module provides the web-based user interface for the application. It is a standard Nginx-based frontend service. Its deployment is straightforward, primarily consisting of the container image definition.
# From charts/agh3/templates/ui/ui-deployment.yml
...
containers:
- name: ui
image: {{ include "ui.image" . }}
ports:
- name: web
containerPort: 80
imagePullPolicy: {{ .Values.ui.image.pullPolicy }}
...
Sources: charts/agh3/templates/ui/ui-deployment.yml:15-22, [charts/agh3/values.yaml:811-828]
AGH3-Report
The report module is responsible for report generation. It communicates with the captain module via an internal API endpoint to fetch data. This is configured via the API_ENDPOINT environment variable in its deployment.
# From charts/agh3/templates/report/report-deployment.yml
...
env:
- name: NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: API_ENDPOINT
value: "captain.$(NAMESPACE).svc.cluster.local:8080"
...
Sources: charts/agh3/templates/report/report-deployment.yml:19-24, [charts/agh3/values.yaml:835-852]
Observability
The chart includes an optional, disabled-by-default observability stack. When vector.enabled is set to true, a Vector agent is deployed as a sidecar container alongside modules like captain to collect logs and traces.
These are then forwarded to Grafana Loki (for logs) and Grafana Tempo (for traces), which can be enabled via grafana-loki.enabled and grafana-tempo.enabled respectively. Grafana itself (grafana.enabled) provides the visualization layer for this data.
Sources: charts/agh3/values.yaml:885-1065, [charts/agh3/templates/captain/captain-deployment.yml:102-115]
Conclusion
The agh3 Helm chart provides a robust and highly configurable mechanism for deploying the ArgusHack3 application. By leveraging conditional dependencies and a detailed values.yaml file, it allows operators to tailor the deployment to their specific needs, whether that involves a fully self-contained installation with all internal services or a hybrid model that integrates with existing external infrastructure. The modular design of the application components and the optional observability stack further enhance its flexibility and manageability in a production environment.