Infrastructure and Manifest Management Documentation

Overview

This document explains how to add a new manifest and summarizes the migration path from the legacy setup to the team-based microservice architecture.

How to add a new namespace

1. Select the environment

Before creating a manifest, decide where the service will run:

Staging: use the DigitalOcean (do) folder.
Production: use the AWS prod folder.
Prod support: use the AWS staging folder.
Both: use both cloud providers when required.

2. Choose the owning team

Identify the team that owns the service:

hh-cosmos: Admin Panel services
hh-syn: Partner Portal services
hh-end-user: services used by mobile and web applications
hh-vendor: vendor-related services

See Domain and Namespace List for the available domains and subdomains.

3. Create the directory structure

Create a folder for the new service using this structure:

manifest/overlays/{aws|do}/{staging|prod}/{server_name}

4. Add configuration files

Create a kustomization.yaml file. You can copy one from an existing service.

In resources, point to the correct base manifest.
Example path: ../../../../base-aws/prod/private
Keep the parent base manifest unchanged.

5. Add environment variables with `set_env`

Add a set_env file in the same folder.

Update the mapfile section with the current overlay path.
Example: ./manifest/overlays/aws/prod/hh-cosmos-private
Update the environment name and APM service name.

Use the public example for services with public-facing URLs. Use the private example for internal services not exposed to the internet.

Example for a public service:

["<ENVIRONMENT>"]="staging/production"
["<APM_SERVICE_NAME>"]="internal-api/partners-api/vendors-api"

Example for a private service (replace with actual service name, e.g., hh-cosmos-private):

["<ENVIRONMENT>"]="staging/production"
["<APM_SERVICE_NAME>"]="hh-cosmos-private"

6. Add OpenSearch configuration if needed

If the service requires OpenSearch, add a set_opensearch_env.sh script to the same directory. The file should export the required environment variables for OpenSearch connectivity:

export OPENSEARCH_HOST="<your-opensearch-endpoint>"
export OPENSEARCH_PORT="443"
export OPENSEARCH_USER="<username>"
export OPENSEARCH_PASSWORD="<retrieve from approved secret store>"
export OPENSEARCH_INDEX="<index-name>"

Replace each placeholder with the actual values for your service. Retrieve credentials from the approved secret store rather than hardcoding them.

7. Update CI/CD buildspec

Append the new service block to the bottom of the relevant buildspec file. Update the host name and paths to match the new service.

Example:

# Run manifest for <SERVICE_NAME>
      - chmod u+x ./manifest/overlays/aws/prod/<SERVICE_NAME>/set_opensearch_env.sh
      - ./manifest/overlays/aws/prod/<SERVICE_NAME>/set_opensearch_env.sh
      - kubectl kustomize manifest/overlays/aws/prod/<SERVICE_NAME> > manifest/overlays/aws/prod/<SERVICE_NAME>/final_manifest.yaml
      - chmod u+x ./manifest/overlays/aws/prod/<SERVICE_NAME>/set_env.sh
      - ./manifest/overlays/aws/prod/<SERVICE_NAME>/set_env.sh && kubectl apply -f manifest/overlays/aws/prod/<SERVICE_NAME>/final_manifest.yaml -n <SERVICE_NAME>
cache:

Architecture classification

We classify services into three scopes:

Category	Description	Example
Legacy	Consolidated namespace used by the old system	`hungryhub` namespace
Private	Internal services not exposed publicly	Sidekiq
Public	Services with a public-facing URL	Web and mobile APIs

Namespace and service mapping

Services are isolated by namespace:

Partner Portal uses hh-syn-public.
Admin Panel uses hh-cosmos-public.
Isolation ensures that if hh-cosmos goes down, order placement and the Partner Portal can continue running.

The goal of this microservice model is to make failures easier to isolate and resource usage easier to monitor.

Granular monitoring to identify the service causing an issue
Resource tracking per service
Better isolation so one service failure does not take down the entire platform

HungryHub Knowledge Base