Overview of Ortelius Objects and Concepts

Understanding Core Objects and Concepts.

Introduction

Ortelius' core objects are Domains, Applications, and Components. Components are the the objects that are cataloged, versioned and mapped across software supply chain. Environments and Endpoints are used to track releases to your clusters, cloud, or physical data centers and are referenced during your pipeline deployments for inventory control.

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.

Example of Domains, Applications, Components and Environments

Other Objects include:

  • Date
  • User
  • UserGroup (Admin or User)

These Objects can be referenced using Ortelius APIs.

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.
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.

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.

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.

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.

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.

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.
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.

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.
email 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

You can have two Groups which users can be assigned: Users and Administrators.

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.
email 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.
Last modified December 7, 2022: Added Swagger (69cbe9a)