Service

Definition

A service is an atomic unit of deployment. It is meant to package a business functionality as a unit, though, the user can define it as per their use case. A service is composed of components.

A service once created is immutable when released with a concrete version. If there is any change in service definition, then a new version needs to be released with that change.

Fields

Key	Value Type	Remarks
name	string	name of the service, service name cannot have _ (underscore) in the name as same is not support by helm
version	string	version of the service
team	string	name of your team
components	list	list of components

service name cannot have _ (underscore) in the name as same is not support by Helm - https://helm.sh/docs/chart_best_practices/conventions/#chart-names

Sample:

service-foo.json

{
  "name": "MyAuth",
  "version": "1.0.0",
  "team": "tech",
  "components": [
    {
      "type": "application",
      "name": "my-auth",
      "version": "1.0.0",
      "config": {
        "build_type": "java",
        "build_version": "8",
        "artifact_name": "profile",
        "artifact_version": "1.0.0-QA-SNAPSHOT"
      }
    },
    {
      "type": "cassandra",
      "name": "foo-cassandra",
      "version": "1.1.0"
    },
    {
      "type": "aerospike",
      "name": "foo-aerospike",
      "version": "1.2.0"
    }
  ]
}

Change in any component within a service will also require you to bump up a new version for the service definition as well.

Component config

Every component exposes specific configs that can be overridden while defining service definition. You can read more about that in component-type reference.

Special case for application component-type

Application component-type exposes application_name and application_version as config params enabling you to override default name and version in cases where they might not be same.

Odin will use application_name and application_version to fetch artifact from jfrog.

Access To Deployed Components

Once a service is deployed, the respective components can be found at below URL

$COMPONENT_NAME-$ENV_NAME..local

For RDS andPostgresQL you'll have different end points for reader and master

$COMPONENT_NAME-reader-$ENV_NAME.orgname-accountname.local

$COMPONENT_NAME-master-$ENV_NAME.orgName-AccountName.local

Validating via Health Check

You can validate your service via heath check request

curl --location --request GET 'http://SERVICE_NAME-{ENV_NAME}.orgName-AccountName.local/healthcheck'

Read more about deploying your service here - Deploy your service

List of teams

Here is the list of all the team onboarded on the platform for Dream11. You can use these team names for creating service while we are working to make it seamless experience for you.