Ortelius 101
Introduction
Ortelius' core Objects are Domains, Applications, Components, Environments and Endpoints. These Objects catalog, track, and version independently deployable objects, maps their relationships, and releases them to clusters, cloud, or physical data centers.
Domains are core to Ortelius' management of microservices. Domains are hierarchical and pass inheritance from parent to siblings. For this reason, Components can be shared across the Subdomains. The hierarchical structure of Domains provides a high-level of control and management over how microservices are shared and reused.
Other Objects include:
- Change Request
- Credentials
- Data Sources
- Date
- DropZone
- DropZone File
- Notifiers
- User
- UserGroup (DeployHub Pro Object)
These Objects can be referenced using Ortelius APIs or custom DMSCripts.
Following is a description of each Object and their attributes.
Application Object
Applications are a collection of Components that can be deployed as a single software solution. You define an Application by associating the Components it will consume. The first version is the Application Base Version. When you change this Application Base Version, you create a new Application Version. Applications are assigned and deployed to Environments. Applications are associated to a Domain.
-
Application Base Version : Defines the software product in terms of Components, Attributes, and assigned Environments.
-
Application Version : This represents any changes made in to the Base Versions.
An Application has the following properties:
| Property | Description |
|---|---|
| id | A unique identifier for the Application in the database. |
| name | Application name. |
| fqdomain | Fully qualified Domain name. |
| summary | Summary of the Domain. |
| owner | User or Group that owns it. |
| parent | The Base Application. |
| predecessor | Predecessor Application Version. |
| Release | Defines the Application Object with more than one Application. |
| Applications | Multiple Applications used to create a Release. |
| Components | The objects that the Application consumes. |
| approvals | Allows a control point for progressing a change within the pipeline process. |
| requests | The Change Request objects associated with this Application. |
| creator | The User or Group who created it. |
| modifier | The User or Group who last modified it. |
| ctime | The date/time it was created. |
| mtime | The date/time it was last modified. |
| KV Configurations | Key Value Pairs for managing associative arrays. |
Release Object
A Release is only available in DeployHub Pro. A Release is a collection of Applications that must be deployed together, sometimes referred to as a ‘Release Train.’
Change Request Object
The Change Request Object represents a change request record associated with either a Component or an Application. A Change Request is a DeployHub Pro feature.
The Change Request object has the following properties:
| Property | Description |
|---|---|
| id | The Change Request id. |
| name | The Change Request description. |
| status | The Change Request status. |
| api_url | A URL which, if passed to restful_get, will return an array containing the full details of the Change Request from the external change tracking system. Useful for getting more information than the id / description / status combination which is stored in Ortelius. |
| html_url | A URL which will direct a browser to the page describing the change request in the external change tracking system. |
Component Object
Ortelius manages microservices and other reusable objects as Components. These are assigned to an Application even though they are managed independently. By assigning Components to Applications you track a ‘logical’ view of your software solution. In a monolithic approach, this happened at the software compile and link step. In microservices though, they are loosely coupled and linked at run-time. Defining Components to Applications puts the Application back in the picture, even if it is only a ‘logical’ view.
If you are an API or microservice developer, this will be where you do most of your work. However, application developers may also define Components for a specific Application. Components are microservices (containers), Database updates, or other deployable objects. By tracking the low level deployment metadata for a Component, it can be easily shared and released in a consistent way across team.
Components change over time, and so Ortelius contains Component Base Versions and Component Versions like those of Application Base Versions and Application Versions. And like Applications, Components are associated to a Domain.
-
Component Base Version : Objects within Ortelius that contain the files and procedures deployed to Endpoints.
-
Component Version : A child of the Component Base Version that represents changes.
A Component Object has the following properties:
| Property | Description | |
|---|---|---|
| id | A unique identifier for the Component as used in the database. | |
| name | The name of the Component. | |
| fqdomain | Fully qualified Domain name. | |
| summary | Description of the Component. | |
| domain | Domain in which the Component is contained. | |
| owner | User or UserGroup that owns the Component. | |
| parent | The Base Component. | |
| predecessor | The version on which this is based. | |
| items | The items that make up this Component. | |
| servers | The Endpoints to which this Component has been deployed. | |
| requests | The change requests associated with this Component . | |
| lastbuild | The last build number for this Component, 0 if never built. | |
| creator | The User who created this Component. | |
| modifier | The User who last modified this Component. | |
| ctime | The date/time the Component was created. | |
| mtime | The date/time the Component was last modified. | |
| Key Value Configurations | Key Value Pairs for managing associative arrays. |
Component and Application Relationships
There is a many-to-many relationship between Applications and Components. An Application can contain many different Components, and a Component can be used across many different Applications. Components can be easily shared between Applications. Ortelius tracks and versions the Component relationships including to which Applications they have been assigned.
Component and Application Versioning
A backend versioning engine tracks all software deployment configurations. This is done within an Application. An Application consists of one or more Components. Versioning tracks all changes in both your Application and Component attributes. This includes all low level information such as the Action used to perform the installation, environment variables, and database schemas.
When you first define your Application, you create an Application Base Version. Over time, as you update your code and deliver new features, each change to the Application creates a new Application Version. Application Versions package all your Components in your entire software product. Like Application Versions, there is an initial Component Base Version and subsequent Component Versions, which represent any updates . An Application Base Version or Component Base Version is always the first one created, and it acts as a model for subsequent Application or Component Versions. Otherwise they are identical types of objects.
When a new Application Version is created from either an Application Base Version or another Application Version, it inherits all previous Components from its predecessor. That predecessor is determined when running a Create Version Task for an Application Version. You can specify whether the new Application Version inherits its Components from the original Application Base Version, the latest Application Version, or a specific Application Version.
Ortelius uses a simple versioning number schema starting at 1 and incrementing over time, for example Myapp;1, Myapp;2.
You can use your CI/CD process to include variance in your versioning number (base name, variant, version). See Component Versioning Schema.
Credential Object
The Credential Object contains the logon and password needed to access EndPoints and external repositories like Git or Quay.
The Credential Object has the following properties:
| Property | Description |
|---|---|
| id | A unique identifier for the Credential as used in the database. |
| name | The name of the Credential. |
| summary | Description. |
| fqdomain | Fully qualified Domain name that the Credential is associated with. |
| domain | Domain in which the Credential is associated. |
| owner | User or Group that owns the Credential. |
| username | Decrypted username. |
| password | Decrypted password. |
| b64auth | A string representing the decrypted username and password together, with a : separator and then base64 encoded. Used for Basic Authorization for web-based APIs. |
| creator | The User or Group who created this Credential. |
| modifier | The User or Group who last modified this Credential. |
| ctime | The date/time the Credential was created. |
| mtime | The date/time the Credential was last modified. |
| Type | Credential use. |
Data Source Objects
The Data Source object communicates with various sources of information such as databases, HTTP servers, FTP servers, etc., and can be used to connect to other DevOps tools as needed.
Date Object
Dates track the date/time of the creation, deletion, or update of an Object.
The Date has the following properties:
| Property | Description |
|---|---|
| to_int(secs) | Returns an integer representing the date as the number of seconds since midnight on January 1st 1970 (epoch). The secs parameter is optional. If needed, the specified number of seconds is added to the date/time before the new value is returned. |
| to_char(fmt) | Formats the date into a string given by the passed fmt string. The fmt string should contain characters as specified below. |
Domain Object
The Domain Object represents the highest order of organization for managing Applications, Components and Environments. Domains are hierarchical and can have Subdomains. Subdomains inherit the parents properties, Tasks and access.
Your microservices, a type of Component, are cataloged based on Domains and Subdomains which you define. Domains catalog microservices that solve the same ‘problem sets.’ In a similar way, Applications are assigned to their own Domain. Environments and Endpoints are associated to Domains that are managing Applications.
The highest level Domain is your Global Domain. With the SaaS version, your Global Domain name is defined based on your Company. With the on-premise installation, you will see a Domain called Global.
Domains also include Tasks. Tasks include Move, Approve, Version and Deploy. Tasks can be called by external solutions via APIs for integration into your Continuous Delivery Pipeline. Tasks are associated to any Domain and can be defined as Pre or Post. Tasks are normally defined to Life Cycle Subdomains and support continuous configuration management in your continuous delivery process.
Life Cycle Subdomains allow you to automate the push of your continuous deployments from development through production. Ortelius can be called by your Continuous Delivery engine (Jenkins, Bamboo, GitLab, CircleCI, Puppet Relay, Google CloudBuild or GitHub Actions) to perform the continuous deployment task across all states of your pipeline. If you are not using a Continuous Delivery orchestration engine, you can assign Tasks to your Life Cycle Subdomain to define a continuous deployment ‘promotion’ process within Ortelius.
The following properties can be accessed on the Domain object:
| Property | Description | |
|---|---|---|
| id | Domain id, as used in the database. | |
| name | Domain name. | |
| fqdomain | Fully qualified Domain name. | |
| summary | Summary text. | |
| domain | Higher level Domain to which it belongs. | |
| subdomains | List of Domain objects which are contained within it. | |
| Life Cycle | A Domain that includes a pipeline and the lowest level Subdomains. Life Cycle-domains cannot have Subdomains. | |
| Applications | The Application objects which are contained within it. | |
| Environments | The Environment objects which are contained within it. | |
| creator | The User or Group Object representing the user who created it. | |
| modifier | The User or Group Object representing the user who last modified it. | |
| ctime | Date Object representing the date/time it was created. | |
| mtime | Date Object representing the date/time it was last modified. | |
| owner | User or Group Objects that owns it. |
Dropzone Object
The DropZone Object represents a local area where deployment artifacts are manipulated before sent to the target Endpoints. A DropZone Object is also present on the stack during Pre and Post Action processing for a Component. For example, the content of the DropZone are the files checked out from the repository for the associated Component.
A DropZone Object has the following properties:
| Property | Description |
|---|---|
| name | DropZone name. |
| path | The full path of where the DropZone is located. Useful for passing to external scripts that may need to manipulate files in the DropZone. |
| files | An Array of DropZone Objects, each one of which represents a file in the DropZone. The array is keyed by the full path name of the file. |
DropZone File Object
The DropZone File Object represents a file in the DropZone.
The DropZone File Object has the following properties:
| Property | Description |
|---|---|
| dzpath | The relative path of the file in the DropZone. |
| repopath | The relative path of the file as located in the repository (this path is relative to the base directory of the repository). |
| size | The size of the file in bytes. |
| ctime | The creation time of the file. |
| mtime | The modified time of the file. |
Environment Object
The Environment Object represents a collection of Endpoints where an Application is deployed. Multiple Environments can represent your pipeline stages such as Development, Testing, and Production for a single Application. Your Application can have as many Envrionments as needed.
The following properties can be accessed for an Environment object:
| Property | Description |
|---|---|
| id | Unique identifier as used in the database. |
| name | Environment name. |
| fqdomain | Fully qualified Domain name. |
| summary | Description of the Environment. |
| domain | Domain in which it is contained. |
| owner | User or Group Objects that owns it. |
| basedir | Base directory for deployments. |
| Endpoints | The Endpoints assigned to it. |
| Applications | The Applications associated to it. |
| creator | The User or Group who created it. |
| modifier | The User or Group who last modified it. |
| ctime | The date/time it was created. |
| mtime | The date/time it was last modified. |
| parent | Parent Domain. |
Endpoint Object
The Endpoint Object (Local Helm Host, container, VM/Cloud Image) represents where a deployment will be sent. Endpoints are assigned to an Environment.
Endpoint Mapping
Each Component is assigned a Type attribute. You can specify which kind of Endpoint is needed. For example, a Database Component is installed onto an Endpoint with a corresponding Database Type definition. A Component is assigned a single Type, while an Endpoint can be assigned multiple Types. For example, if your single Endpoint needed to have both a database and your application binaries installed, it would be assigned both a ‘Database’ and a ‘Binary’ Type attribute.
To map a Component to Endpoints, assign one or more Component Types to each Endpoint. Then assign a single Type attribute to that Component. When an Application is deployed, each Component within the Application will be deployed to each Endpoint if the Component’s Type attribute matches one of the Endpoint’s Type attributes. Ortelius ships with standard Component and Endpoint Types and allows you to define custom Type attributes.
The Endpoint object has the following properties:
| Property | Description |
|---|---|
| id | A unique identifier as used in the database. |
| name | The Endpoint name. |
| fqdomain | Fully qualified Domain name. |
| summary | Description of the Endpoint. |
| domain | Domain in which it is contained. |
| owner | User or Group that owns it. |
| hostname | Hostname (if set) or name otherwise. |
| basedir | Base Directory for Deployments. |
| type | Endpoint Type, ie: cluster, windows, cloud, etc. |
| credential | The logon and password used to access this Endpoint. |
| Components | The Components currently installed on it. |
| creator | The User or Group who created it. |
| modifier | The User or Group who last modified it. |
| ctime | The date/time it was created. |
| mtime | The date/time it was last modified. |
| Key Value Configurations | Key Value Pairs for managing associative arrays. |
Notifier Objects
A Notifier is sent after a successful or failed deployment attempt. If these features are activated, they are also sent when deployed files have been changed, a Request Task has been used, or when an Endpoint is down, Ortelius can use SMTP (Simple Mail Transfer Protocol), Slack and HipChat for this purpose.
User Object
The User Object represents a User in Ortelius. It has the following properties:
| Property | Return Type | Description |
|---|---|---|
| id | Integer | User id, as used in the database. |
| name | String | User Name. |
| kind | String | Returns “user”. Used to differentiate between users and groups when retrieving an owner object. |
| fqdomain | String | Fully qualified Domain name. |
| realname | String | The User’s full name. |
| String | The User’s email address. | |
| phone | String | The User’s telephone number. |
| groups | Array | Array of Group Objects to which this User belongs. |
| lastlogin | Date | The date/time last logged into Ortelius. |
| creator | User | User or Group Object representing who created this User. |
| modifier | User | User or Group Object representing who last modified this User. |
| ctime | Date | Date Object representing the date/time the User was created. |
| mtime | Date | Date Object representing the date/time the User was last modified. |
| owner | Object | User or Group that owns the User |
Group Object
The Group Object represents a collection of Users with the same Domain and security access. (This is a DeployHub Pro Feature.)
The Group Object has the following properties:
| Property | Description |
|---|---|
| id | A unique identifier as used in the database. |
| name | Group Name. |
| kind | Identifies whether this is a User or a Group. |
| fqdomain | Fully qualified Domain name. |
| The Group’s email address. | |
| creator | User or Group Object representing who created this Group. |
| modifier | User or Group Object representing who last modified this Group. |
| ctime | Date Object representing the date/time it was created. |
| mtime | Date Object representing the date/time it was last modified. |
| owner | User or Group that owns the object. |