Component

A Component is a building block of a service in Odin. Components represent individual pieces of infrastructure or application logic that work together to form a complete service.

What is a Component?

Components are the fundamental deployment units in Odin. They can represent:

Web Services: API servers, web applications, microservices
Databases: PostgreSQL, MySQL, MongoDB
Caches: Redis, Memcached
Message Queues: RabbitMQ, Kafka, SQS
Storage: S3 buckets, file systems
Any other infrastructure: Load balancers, DNS records, etc.

Component Definition

Components are defined within a service definition:

{
  "name": "api-server",
  "type": "webservice",
  "version": "2.1.0",
  "depends_on": ["database", "cache"],
  "config": {
    "port": 8080,
    "replicas": 3,
    "env": {
      "LOG_LEVEL": "info"
    }
  }
}

Component Properties

Property	Required	Description
`name`	Yes	Unique identifier within the service
`type`	Yes	Component type (registered in Odin)
`version`	Yes	Component version
`depends_on`	No	Array of component names this depends on
`config`	No	Component-specific configuration (JSON object)

Component Types

Components have types that determine how they’re deployed and managed. Common types include:

webservice: HTTP/gRPC services
postgres: PostgreSQL database
mysql: MySQL database
redis: Redis cache
mongodb: MongoDB database
rabbitmq: RabbitMQ message broker
kafka: Apache Kafka
s3: S3 bucket
lambda: AWS Lambda function

Component Dependencies

Components can depend on other components. Odin uses these dependencies to:

Determine deployment order: Deploy dependencies first
Validate configurations: Ensure all dependencies exist
Prevent unsafe operations: Can’t remove a component if others depend on it

Defining Dependencies

Use the depends_on field to specify dependencies:

{
  "components": [
    {
      "name": "api",
      "depends_on": ["database", "cache", "queue"]
    },
    {
      "name": "worker",
      "depends_on": ["database", "queue"]
    },
    {
      "name": "database",
      "depends_on": []
    },
    {
      "name": "cache",
      "depends_on": []
    },
    {
      "name": "queue",
      "depends_on": []
    }
  ]
}

Deployment Order:

database, cache, queue (parallel, no dependencies)
api, worker (parallel, after dependencies are ready)

Dependency Graph

Odin automatically creates a dependency graph and deploys in topologically sorted order:

database ──┐
           ├──> api
cache ─────┤
           │
queue ─────┼──> worker
           │

Component Lifecycle

Component States

Components transition through several states:

State	Description
`DEPLOYING`	Component is being deployed
`DEPLOYED`	Component successfully deployed
`FAILED`	Deployment failed
`UPDATING`	Component is being updated
`UNDEPLOYING`	Component is being removed
`UNDEPLOYED`	Component has been removed

Checking Component Status

Check component status within a service:

odin status env staging --service my-service

Get detailed information about a specific component:

odin describe env staging --service my-service --component database

Component Operations

Operating a Component

Execute operations on individual components:

odin operate component --name <component-name> \
  --service <service-name> \
  --env <env-name> \
  --operation <operation-type> \
  --options '{"key": "value"}'

Or use a file:

odin operate component --name <component-name> \
  --service <service-name> \
  --env <env-name> \
  --operation <operation-type> \
  --file operation.json

Common Component Operations

Scale a Component

Scale up/down replicas:

odin operate component --name api \
  --service user-api \
  --env production \
  --operation scale \
  --options '{"replicas": 5}'

Restart a Component

Restart a component (rolling restart):

odin operate component --name api \
  --service user-api \
  --env staging \
  --operation restart

Update Configuration

Update component configuration:

odin operate component --name api \
  --service user-api \
  --env staging \
  --operation update-config \
  --options '{
    "env": {
      "LOG_LEVEL": "debug",
      "CACHE_TTL": "3600"
    }
  }'

Adding Components

Add a new component to an existing service:

odin operate service --name user-api \
  --env staging \
  --operation ADD_COMPONENT \
  --file add-component.json

add-component.json:

{
  "component_definition": {
    "name": "new-cache",
    "type": "redis",
    "version": "7.0",
    "config": {
      "memory": "4Gi"
    }
  },
  "provisioning_config": {
    "component_name": "new-cache",
    "deployment_type": "elasticache-redis",
    "params": {
      "node_type": "cache.t3.medium",
      "num_nodes": 2
    }
  }
}

Removing Components

Remove a component from a service:

odin operate service --name user-api \
  --env staging \
  --operation REMOVE_COMPONENT \
  --options '{"component_name": "old-cache"}'

Safety Checks:

Component must exist in the service
Component must be in a terminal state (DEPLOYED or FAILED)
No other components can depend on it

Component Configuration

Components have a flexible config field for component-specific settings:

Web Service Configuration

{
  "name": "api",
  "type": "webservice",
  "config": {
    "port": 8080,
    "replicas": 3,
    "cpu": "500m",
    "memory": "1Gi",
    "env": {
      "LOG_LEVEL": "info",
      "DB_HOST": "database:5432",
      "CACHE_URL": "redis://cache:6379"
    },
    "healthcheck": {
      "path": "/health",
      "interval": 30
    }
  }
}

Database Configuration

{
  "name": "database",
  "type": "postgres",
  "config": {
    "storage": "100Gi",
    "instance_class": "db.r5.large",
    "multi_az": true,
    "backup_retention_days": 7,
    "parameters": {
      "max_connections": "200",
      "shared_buffers": "256MB"
    }
  }
}

Cache Configuration

{
  "name": "cache",
  "type": "redis",
  "config": {
    "memory": "4Gi",
    "eviction_policy": "allkeys-lru",
    "persistence": false,
    "replicas": 2
  }
}

Component Provisioning

Each component needs provisioning configuration that specifies how and where it’s deployed. See Provisioning for details.

Component Best Practices

Naming

Use clear, descriptive names:

api, web, server: For web services
database, db, postgres: For databases
cache, redis: For caches
queue, mq, broker: For message queues

Dependencies

Minimal Dependencies: Only depend on what you actually need
Order Matters: List dependencies in the order they’re needed
Avoid Cycles: Circular dependencies are not allowed

Configuration

Environment Variables: Use env for configuration that changes between environments
Defaults: Provide sensible defaults in the service definition
Secrets: Don’t put secrets in the service definition; use provisioning configs
Resource Limits: Always specify CPU and memory limits

Versioning

Pin Versions: Always specify exact component versions
Test Upgrades: Test component version upgrades in staging first
Compatibility: Ensure component versions are compatible with each other

Examples

Simple API Server

{
  "name": "api",
  "type": "webservice",
  "version": "1.0.0",
  "config": {
    "port": 8080,
    "replicas": 2
  }
}

Database with Backup

{
  "name": "main-db",
  "type": "postgres",
  "version": "14.5",
  "config": {
    "storage": "200Gi",
    "instance_class": "db.r5.xlarge",
    "multi_az": true,
    "backup_retention_days": 14,
    "backup_window": "03:00-04:00",
    "maintenance_window": "sun:04:00-sun:05:00"
  }
}

High-Availability Cache

{
  "name": "cache-cluster",
  "type": "redis",
  "version": "7.0",
  "config": {
    "memory": "8Gi",
    "replicas": 3,
    "persistence": true,
    "eviction_policy": "volatile-lru",
    "parameters": {
      "maxmemory-policy": "volatile-lru",
      "timeout": "300"
    }
  }
}

Service: Components are part of services
Provisioning: How components are deployed
Environment: Where components run
Versioning: Component version management