Component

Understanding Odin components and their lifecycle

What is a 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.

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

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:

1. Determine deployment order: Deploy dependencies first
2. Validate configurations: Ensure all dependencies exist
3. 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:

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

Component Lifecycle

Component States

Components transition through several states:

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"}'

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

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"
    }
  }
}

Explore Available Components

Check out the Odin Components Repository to explore production-grade infrastructure components following the Odin Component Interface (OCI) specification. You can also track new components currently in development.

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

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

Configuration

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

Related Concepts

• Service: Components are part of services
• Provisioning: How components are deployed
• Environment: Where components run