Component C20 – Chart Store
By Raj Marni. March 23, 2025. Revisied. Version: 0.1.09
1. Overview
Chart Store (C20) is a central NoSQL repository (typically based on DynamoDB) that maintains Helm chart artifacts and the accompanying metadata. It plays a critical role in cataloging deployment configurations generated by the Manifestor (C12) and other processes, while also interfacing with multiple components in the Orbit Plane.
2. Internal Architecture
2.1 Core Modules
Data Model & Schema Engine
Purpose:
Structures and stores Helm chart artifacts and metadata using a schema optimized for quick lookups and scalable operations.
Features:
Defines partition and sort keys that facilitate efficient queries (e.g., by chart ID, version, or environment).
Supports flexible, schema-less design to accommodate evolving metadata requirements.
CRUD & Data Access API
Purpose:
Exposes endpoints for creating, reading, updating, and deleting chart artifacts.
Features:
Implements RESTful services for smooth integration with upstream and downstream components.
Ensures atomic operations for data integrity, making use of DynamoDB’s transaction capabilities.
Indexing & Query Optimization Module
Purpose:
Enhances data retrieval performance and supports complex query patterns.
Features:
Uses secondary indexes and caching strategies to achieve low-latency access.
Facilitates advanced queries required for auditing and monitoring deployments.
Data Consistency & Management Layer
Purpose:
Manages versioning, conflict resolution, and backup processes.
Features:
Enforces consistency across updates and ensures historical data is maintained for rollback or auditing.
May include background jobs for cleanup, archival, or re-indexing.
3. External Interactions & Surrounding Context
3.1 Upstream Interactions
From Manifestor (C12) – Connection C12C20-1
Function:
Receives newly generated Helm chart manifests along with user-provided metadata.
Mechanism:
Typically a synchronous API call where C12 sends a payload to be stored in C20, ensuring the chart and its configuration are captured immediately.
From Docker Image Build Process (C4) – Connection C4C20-1
Function:
May contribute additional build-related metadata or references that are correlated with the Helm charts.
Mechanism:
Utilizes RESTful calls or webhook notifications to update C20 with the relevant image build artifacts or statuses.
3.2 Downstream Interactions
To Helm Chart Artifact (C24) – Connection C20C24-1
Function:
Provides the concrete chart artifact that represents a deployable package.
Mechanism:
When a deployment is initiated, C20 supplies C24 with the finalized chart data for packaging and distribution.
To Kubernetes Kustomize (C28) – Connection C20C28-1
Function:
Supplies base chart data for further environment-specific customization.
Mechanism:
C28 retrieves chart information from C20 to overlay environment-specific changes, ensuring that deployments are tailored as required.
To Component C56 – Connection C20C56-1
Function:
This connection handles supplementary functions such as notifications, additional orchestration commands, and real-time monitoring enhancements with Component C56 - SyncMaster.
Mechanism:
Involve asynchronous messaging to trigger downstream workflows or real-time updates for various communication purposes.
Implemented as RESTful endpoints for synchronous interactions when immediate response is required.
4. Technology & Protocols
API Communication:
REST/HTTP endpoints are used for synchronous interactions, with JSON as the primary data format.
Asynchronous messaging leveraged for non-blocking updates and notifications.
Security Measures:
All data exchanges are secured via TLS.
Token-based authentication (JWT) is enforced for API calls to ensure that only authorized components can access or modify the data.
Scalability & Resilience:
Built on a scalable NoSQL database (DynamoDB), ensuring high availability and performance under heavy load.
Built-in mechanisms for data consistency, backup, and recovery maintain the reliability of stored artifacts.
Last updated