AGH2 Component: Core
Relevant source files
The following files were used as context for generating this wiki page:The Core component is a central backend module within the AGH2 system, as defined by the agh2 Helm chart. It provides essential functionalities and serves as an integration point for other services like Captain and Exploit-Manager. The component is containerized and designed to be deployed on Kubernetes.
This component relies on several external services for its operation, including a PostgreSQL database for persistence, Redis for caching, and Minio for object storage. It exposes a gRPC interface for communication with other parts of the AGH2 application. Its deployment and configuration are managed through the Helm chart, allowing for flexible setup and integration.
Sources: charts/agh2/values.yaml:400-403, charts/agh2/templates/core/core-deployment.yml
Architecture and Dependencies
The Core component is designed to run as a Kubernetes Deployment and is exposed internally via a Service. It depends on several other components within the cluster to function correctly.
This diagram illustrates the dependencies of the Core component.
The dependencies are established through environment variables and init containers within the core deployment, ensuring that services like PostgreSQL and Redis are available before the main application container starts.
Sources: charts/agh2/templates/core/core-deployment.yml:18-42, charts/agh2/templates/captain/captain-deployment.yml:62-64
Kubernetes Resources
The Core component is composed of a Kubernetes Deployment and a Service.
Deployment
The core Deployment manages the lifecycle of the Core application pods.
- Init Containers: The deployment specifies two init containers to ensure dependencies are ready before the main container starts.
core-init-redis: Waits for the Redis service to be available.core-init-postgresql: Waits for the PostgreSQL database to be ready by checking the connection usingpg_isready.
- Main Container: The primary
corecontainer runs the application.- Image:
leukocyte-lab/argushack2/core:v1.23.0(default) - Command:
./core - Ports: Exposes gRPC on container port
50005. - Resources: Requests
256Miof memory and500mof CPU.
- Image:
Sources: charts/agh2/templates/core/core-deployment.yml:1-96, charts/agh2/values.yaml:407-410
Service
A Service named core exposes the Core component's gRPC port within the cluster.
- Name:
core - Selector:
app: core - Port: Exposes port
50005, targeting thegrpcport on the pod.
This service allows other components, such as captain, to communicate with the Core service using the internal DNS name core.<namespace>.svc.cluster.local:50005.
Sources: charts/agh2/templates/core/core-service.yml:1-12, charts/agh2/templates/core/core-deployment.yml:71-72
Configuration
The Core component's behavior is configured through the core section of the values.yaml file.
| Parameter | Description | Default Value |
|---|---|---|
core.enabled | Enables or disables the deployment of the Core module. | true |
core.image.repository | The container image repository for the Core module. | leukocyte-lab/argushack2/core |
core.image.tag | The container image tag. | v1.23.0 |
core.secret.db.name | The name of the database used by the Core module. | core-db |
core.secret.db.user | The database user for the Core module. | agh-core |
core.secret.minio.user | The Minio user for the Core module. | core-minio-user |
core.service.redis.enabled | Enables Redis usage for the Core service. | true |
core.env.REGISTRY_URL | The URL of the container registry. | registry.lkc-lab.com |
Sources: charts/agh2/values.yaml:400-447, charts/agh2/README.md:223-247
Environment Variables
The core container is configured with several environment variables to connect to its dependencies and other services.
| Variable | Description | Value Source |
|---|---|---|
NAMESPACE | The Kubernetes namespace where the pod is running. | fieldRef: metadata.namespace |
ENV_REDIS_CONN | The connection string for Redis. | redis://redis.$(NAMESPACE).svc.cluster.local:6379/0 |
EXP_MGR_DB_Conn | The database connection string for the Exploit Manager. | Secret: exploitmgr.secret.db.secretName |
EXPLOITMGR_URL | The internal URL for the Exploit Manager service. | exploitmgr.$(NAMESPACE).svc.cluster.local:50005 |
MINIO_URL | The URL for the Minio service. | Secret: minio.secret.secretName |
MINIO_USER | The username for Minio access. | Secret: core.secret.minio.secretName |
MINIO_PASSWORD | The password for Minio access. | Secret: core.secret.minio.secretName |
DB_Conn | The database connection string for the Core service itself. | Secret: core.secret.db.secretName |
CORE_URL | The internal URL for the Core service itself. | core.$(NAMESPACE).svc.cluster.local:50005 |
REGISTRY_URL | The URL of the container image registry. | values.core.env.REGISTRY_URL or global.imageRegistry |
Sources: charts/agh2/templates/core/core-deployment.yml:51-81
Database Initialization
When using the internal PostgreSQL database (db.internal.enabled: true), a ConfigMap named db-init-scripts is created to initialize databases and roles for various AGH2 components, including Core.
The initialization script performs the following steps for the Core component:
- Creates a role named
agh-core. - Creates a database named
core-dbwithagh-coreas the owner. - If enabled, installs the
pgroongaextension in thecore-dbdatabase.
This flow ensures that the database schema is prepared before the Core service attempts to connect.
The following diagram shows the database initialization process for the Core module.
Inter-Service Communication
The Core component is a gRPC service that communicates with other modules within the AGH2 ecosystem.
- Inbound: The
captainmodule communicates with the Core module. Thecaptaindeployment includes an environment variableCORE_URLset tocore.$(NAMESPACE).svc.cluster.local:50005, which it uses to make gRPC calls to the Core service. - Outbound: The Core module communicates with the
exploitmgrmodule. Thecoredeployment has anEXPLOITMGR_URLenvironment variable set toexploitmgr.$(NAMESPACE).svc.cluster.local:50005.
The sequence diagram below illustrates a typical interaction where Captain requests a resource from Core.
Summary
The AGH2 Core component acts as a foundational service in the application architecture. It is deployed as a Kubernetes Deployment and exposed via a Service. Its configuration is highly customizable through the agh2 Helm chart, and it integrates tightly with other AGH2 modules like Captain and Exploit-Manager, as well as with backend data stores like PostgreSQL, Redis, and Minio. The deployment includes robust initialization logic to ensure all dependencies are met before the service starts, highlighting its central role in the system's operation.