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
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
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'
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.
Last updated