Odin
  • Introduction
  • Why Odin?
  • Key Concepts
    • Environment
      • Environment Type
    • Provisioning
      • Provisioning Config for Component Types
    • Component
      • Available Component Types
      • Component Type reference
        • Optimus Components
          • Aerospike [6.3.0.7-1.0.0]
    • Service
      • Know Your Service Definition
    • Versioning
      • Clearing the Confusion: A Simplified Guide to Artifact, Component, and Service Versions
    • Service Sets
    • Labels
  • Reference
    • CLI reference
  • Onboard Your Service
    • Installation
    • Configure
    • Odin -h
    • Getting Started
    • Create Environment
      • Operations on Environment
    • Service Definition
    • Provisioning Config
    • Deploy Service
    • Release Service
    • Optimus Datastore Operations
      • How to use Optimus Datastore in my service?
      • RDS Operations
      • Aerospike Operations
      • Kafka Operations
    • Operating Service & Components
      • Redeploy
        • In Place Deployment
        • Blue Green Deployment
      • Rolling Restart
      • Adding & removing components
      • Revert a deployment for application component
      • Downscaling a Passive Stack
      • Updating the no. of stacks of application component
    • Dev <> QA iteration
    • Frequently Asked Questions
    • Deploy Concrete Service
    • Undeploy Service
    • Delete Environment
    • Appendix
  • How To
    • Define error threshold for canary deployment
    • Add or Remove a component in an already deployed service
    • Integrate mono-repo(cronjobs) with Odin
    • Deploy crontab with Odin
    • Integrate Data pipeline with Odin
    • Push logs to log central
    • Build artifacts for multi module applications
    • Load test with Odin
    • Track Deployments against Commit Ids
    • Deploy Service on Production - Dream11
    • How and when images are created
    • Check logs for deployed infrastructure - Dream11
    • Onboard Stepfunction as a component
    • Onboard Serverless as a component
    • Login to Kubernetes clusters
  • Release Notes
    • 1.2.0-beta.2 - 11 August, 2022
    • Odin October Release
    • Odin 1.2.0 - Nov 9th 2022
    • Odin February Release
Powered by GitBook
On this page
  • Access To Deployed Components
  • Validating via Health Check
Export as PDF
  1. Onboard Your Service

Deploy Service

PreviousProvisioning ConfigNextRelease Service

Last updated 2 days ago

Before starting service deployment, ensure the application artifact is created and uploaded to the correct path in the Artifactory (JFrog). The deployment images require this artifact; otherwise, the deployment will fail

A service can be deployed in two ways:

  1. via definition.json

  2. named service and version

A service is always deployed in an environment, we'll use the environment created in the for this.

Let's deploy the defined service

odin deploy service --file /path/to/definition.json --provisioning /path/to/provisioning-dev.json --env ENV_NAME

A service definition file must always be accompanied by a provisioning file. Ensure that you provide the provisioning configuration for each component specified in the definition file.

The output will look something like this:

For Odin 1.x.x

If it's a new service or you have changes in your config store, use your service's config store branch to deploy service using the flag --d11-config-store-namespace

ex: odin deploy service --file definition.json --provisioning provisioning-dev.json --env ENV_NAME --d11-config-store-namespace CONFIG_BRANCH_NAME

Initiating service deployment: SERVICE_NAME@1.0.1-QA-SNAPSHOT in dev-2511
Validating profile@peri-dev-2511-c0548d-SNAPSHOT

Validation succeeded.

Creating images for the components...

Artifact for profile for container created successfully(25s)

All artifacts created successfully. Deploying service.

Initiating deployment in dev-2511

Adding service profile@perishable to dev-2511

Provisioning started for [profile@peri-dev-5004-c0548d-SNAPSHOT]

Service deployed successfully.

For Odin 2.0 and above

The --d11-config-store-namespace flag is now deprecated. Instead:

  • You can specify this information in the env_variables object of the provisioning file for the application component.

  • Use CONFIG_STORE_BRANCH as the key and set its value to the config store branch/tag you want to use.

  • Example Provisioning config

[

  {
    "component_name": "<component_name>",
    "deployment_type": "<deployment_type>",
    "env_variables": {
      "CONFIG_STORE_BRANCH": "<config store branch/tag to use>"
    }
  }
]
INFO[2025-05-20 15:30:08] Generated trace ID: 24ab22d0-a6ce-4e3e-a032-c6b2a0f5f787 
INFO[2025-05-20 15:30:12] Deploying Service...                         
INFO[2025-05-20 15:34:59] 
 Service: hulk-offers version: 1.0.2 action: DEPLOY status: SUCCESSFUL
 Component: offers action: DEPLOY status: SUCCESSFUL 

Access To Deployed Components

Once a service is deployed, the respective components can be found at below URL by default unless the user has provided custom routes for their component

${COMPONENT_NAME}-${ENV_NAME}.dream11${VPC_SUFFIX}.local

For Datastores such as RDS and PostgreSQL you'll have different end points for reader and master

${COMPONENT_NAME}-reader-${ENV_NAME}.dream11${VPC_SUFFIX}.local
${COMPONENT_NAME}-master-${ENV_NAME}.dream11${VPC_SUFFIX}.local

Validating via Health Check

curl --location --request GET 'http://SERVICE_NAME-{ENV_NAME}.your org details/healthcheck'

You can validate your service via heath check request -

previous step
Health Check Request