Defining Components

How to Publish Components to Domains

Component List View allows Adding or Deleting

Use the Component List View accessible from the left hand Component menu option to manage your Components Base Version and Component Versions. Because each Environment has a row where the Component Base Version or Component Version has been deployed, there can be multiple entries for the same Component if it has been deployed to multiple Environments. A list of all Components is organized by the following:

List Column Description
Version The Component Base Version or Component Version number.
Domain The Domain to which the Component belongs.
Parent The Component Base Version from which the Component Version was created. This will be empty for the Component Base Version.
Environment The Environment to which the Component has been deployed. Each Environment will represent a different row in the List View table.
Last Deployment to Environment The Deployment Log number.
Completed The date and time of the last deployment to the listed Environment.
Results Success or Fail.

Note: If you have not defined any Components to Ortelius, you will see only the sample data.

You can also use the Filter bar, represented by a funnel icon, to reorder your Component List View:

  • Domain
  • Environment
  • Last Deployment
  • Parent
  • Result
  • Version

Additional Tabs from the Component List View

Tab Description
Refresh Refreshes the browser.
+Add Base Allows you to Add a new Component Base Version. You will select from one of three types: Container, Application File, Database
+Add Version Creates a copy of the selected Component.
Delete Deletes the selected item. However, you must delete the Components starting from the newest to the oldest. The Component Base Version would be deleted last. Sorting by “Version” gives you the order.
List Return to List View if in the Map View.
Map Displays a global Map of all Component versions, with their Application relationships.

Component Types

When adding new Components select the Component Type from the drop down list/:

Type Description
Container For Containers such as Docker.
Application File For binary files such as .jar, .war, .ear, .exe, .dll, Linux executable files, Oracle Forms, or similar artifacts.

How to View and Edit Components

Components are defined as Container, Application File, or Database. These are the different types of Components you may need from microservices to binaries. The Dashboard view displays all information related to a specific Component Base Version or Component Version. Depending on what type of Component you are defining, you will be presented with different data definition fields.

The following fields are common to all Components:

Field Description
Service Owner The owner of the Component, whose default value is the creator of the Component.
Service Owner Email The email of the owner. Important for knowing who to contact in the case of an anomaly.
Service Owner Phone The phone number of the owner.
PagerDuty Business Service URL Enter the address to the PagerDuty page that is associated to the business service for this Component.
PagerDuty Service URL Enter the address to the PagerDuty page that is associated to the Component itself.
Slack Channel Enter what Slack Channel that can be used to report issues about this Component.
Discord Channel Enter the Discord Invite Link you would like your consumers to use for this Component.
HipChat Channel Enter the HipChat Channel that can be used to report issues about this Component.
Full Domain The fully qualified path of the Domain that the Component is to be associated, showing all parent Domains.
Name The name of the Component.
Description A short text field with a description of the Component.
Component Type The kind of Component created, i..e. Container, Application File, or Database.
Endpoint Type Used to map the Component to Endpoints within an Environment at deployment. This allows Ortelius to map the Component to the correct Endpoint when moving across different environments. You can add your own Endpoint Types from the Customize Types menu or select from the default options.
Category Assigning a Category to an Object allows lists of Objects based on Categories to be used throughout Ortelius. Add a new Category in the entry field or use an existing Category displayed in the drop down.

A Container Component has the following optional attributes:

Field Description
Build Date The timestamp from when the last build job was run.
Build ID The internal identifier for the Build Engine.
Build URL The URL to the Build Engine.
Container Registry The Container registry where the Container is stored.
Container Digest The SHA number of the Container image.
Container Tag The tag that was assigned to the Container image.
Helm Chart The Helm Chart used to deploy the Component.
Helm Chart Namespace The sub-division of the Kubernetes cluster where your Component Container should run.
Helm Chart Repo URL Enter the URL to where the chart is located, for example: Bitnami, ArtifactHub, etc.
Helm Chart Version The Helm Chart Version from the Helm Repository.
Git Commit The Git SHA number. Populated when integrated into Continuous Delivery Pipelines.
Git Repo The Git Repository that triggered the build.Populated when integrated into Continuous Delivery Pipelines.
Git Tag The last tag for the Git Repository. Populated when integrated into Continuous Delivery Pipelines.
Git URL The URL for the Git Repository.Populated when integrated into Continuous Delivery Pipelines.

Application File Type Specific Data Definition

Field Description
Base Directory Base, or high level, directory where the file will be deployed. This value will be ignored if the Endpoint has a Base Directory defined. See Formatting Directories on the order of how the deployment directory is formatted.
Target Directory The directory under the Base Directory where the file will be deployed, or final “Target” Directory. See Formatting Directories on the order of how the deployment directory is formatted.
Build Job The Continuous Delivery Build Job that is used to build/compile the Component.
Last Build Number The number of the last Continuous Delivery (CD) Workflow that created the files referenced within the Component. This number will default to the Build ID if one is not set by the CD Workflow.
Build ID The internal identifier for the Build Engine.
Build URL The URL to the Build Engine.
Build Date The timestamp from when the last build job was run.

Component Readme

Give your users more information about your Container, Application File or Database Component. You can upload an external readme file to provide any information that you need to convey to your potential consumers. Use the ‘Upload’ option to select a file. It must be in text format. You can also automate the upload - see below.

Component Swagger

Publish your Swagger API definitions to provide further information about your restful APIs and the parameters needed. Ortelius takes your .json or .yaml file and renders it using Swagger. Use the ‘Upload’ option to associate your .json or .yaml file to that specific Component Version. You can also automate the upload - see below.

Component SBOM

Publish your Component’s SBOM to show packages and licenses your Component is consuming. SBOMs are required for populating the CVEs.

Component Vulnerabilities

Component vulnerabilities are based on your SBOM. Every thirty minutes, Ortelius updates the Component vulnerabilities based on OSV.Dev. For more information refer to OSV.Dev section of this documentation.

Component License

Report the license associated with your code base for your Component. Use the ‘Upload’ option to import your License file into Ortelius. The file must be in a text format.

Automate the Readme, SBOM, License, and Swagger Upload via Your Pipeline.

You can automatically upload you readme, SBOM, License, and Swagger data using the Command Line Interface (CLI) added to your pipeline. For more information review the CI/CD CLI details. You will find a complete list of parameters for collecting Swagger, SBOM and other tool reports and results. .

Audit Trail

The Audit Trail displays audit entries for any changes or deployments that impact this object. It includes all changes in the object including User date and time, and deployments with unique numbers.

For deployment audits, select a deployment number to see the details including:

Access Description
Log The output of the deployment.
Files Any files or objects deployed.
Step Duration Deployment Steps with time required to execute.
Feedback Loop Shows what was updated starting from Component.

You can also Subscribe or Comment to an Audit Entry.

  • Subscribe: Allows you to receive information about the selected deployment.

  • Comment: Click on ‘Comment’ to add information. There is a field above the list labeled “Say something about this Application” that can have comments placed into it, and files can be attached to the comment as well. Entering text into this field activates the Add Message button. Click to save the comment as a line in the list.

  • Add Files to Comments: Click on the paperclip icon to add a file to the message. Once done, click on the “Add Message” button. These attachments can later be retrieved by clicking on the paperclip icon which then displays the name of the file within a list. Choose the file to download it into the your default Download directory on your local computer.

Access

The Access Section allows Users within designated Groups to update or view the Component. To add a Group to one of the access lists, drag and drop the Group from the Available Groups list onto desired access list. All Users who belong to a Group that appear in one of the Access lists will be granted access to the Component:

Access Description
View This allows any User that belongs to any Group in this list to see the selected Component in the List View.
Change This allows any User that belongs to any Group in this list to make changes to the Component.

Publish a New Component Version Based on an Existing Component Version

Create Component Versions that are patterned after the Component Base Version or any Component Version. Check the box Component Base Version or Component Versions from which you want to base the new version. Select the New Version Tab to access the Component Dashboard and then edit the new Component Version. When you manually create a new Component Version the name will be auto generated with a new number. You may need to provide it a unique name based on your versioning patterns.

Publish New Component Versions automatically via Continuous Delivery

Configure a continuous delivery system to automatically update new Component Versions each time a new GitCommit triggers the workflow process. Add Ortelius to the workflow to perform the continuous versioning of new Components and their consuming Applications. For more information, see Using Ortelius with CI/CD.

Component Dependency Map

The Dependency Map provides a graphical view of all Applications that is consuming this Component. This will remain empty until your Component is used by an an Application.