Skip to main content

Map your Infrastructure

OpenContext allows you to map and describe your infrastructure by creating a Platform Component.

Gather information

To add this additional data, you'll need to answer a few questions.

Who's responsible for the PlatformComponent?

You'll need the OpenContext entity name for the responsible person or team. See Map your Organization on how to find this information.

What components are associated with the PlatformComponent?

For each associated component, you'll need to get the OpenContext entity reference.

To find these, be sure to consider:

  • What components depend on this PlatformComponent?
  • Is this PlatformComponent a dependency of some other component?
  • Is this PlatformComponent part of a Service?
  • Is this PlatformComponent part of a Datacenter?

What is the Lifecycle / Environment for the PlatformComponent?

Usually, the lifecycle is the environment the PlatformComponent is in, such as production.

What is the URI for the PlatformComponent?

What is the Priority for the PlatformComponent?

What is the SLA for the PlatformComponent?

Is PagerDuty associated with this PlatformComponent?

If so, what is the PagerDuty service-id or Events API V2 integration key?

Are there tags you want associated with the component?

Are there external links you want associated with the component?

Examples

The following examples will show how to map your infrastructure from Kubernetes, Terraform, and the Cloud Console (GCP) to OpenContext Platform Component YAML.

Since Kubernetes YAML templates are very similar to OpenContext YAML templates, it should be relatively easy to map one to the other.

Kubernetes example

Let's take the following Kubernetes Ingress definition for our example:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: colors-ingress
labels:
app.kubernetes.io/name: colors
annotations:
kubernetes.io/ingress.class: traefik
spec:
rules:
- host: 'colors.nip.io'
http:
paths:
- path: /
backend:
serviceName: colors
servicePort: 80

For this example, you also know the following information:

  • lifecycle/env -> production
  • owner -> eng-squirrel
  • service -> k8-colors
  • datacenter -> kubernetes-1
  • dependency of -> code-component:colors
  • depends on -> datacenter:kubernetes-1
  • pagerduty integration key
  • priority -> 3
  • SLA -> 24x5
  • tags -> java
  • links -> https://colors.my-monitor.com and https://slack.com

Mapping

With this information, you could map your Kubernetes and other collected info to OpenContext in this way:

Kubernetes YAML Field / Collected InfoOpenContext YAML FieldNote
kindspec.type
metadata.namemetadata.nameMust be unique for PlatformComponent!
human readable name for the resourcemetadata.title
description of the resourcemetadata.description
metadata.labels or anything in Kubernetes that doesn't map directly to a specmetadata.labels
spec.rules.host or anything in Kubernetes that results in an URIspec.uri
lifecycle/envspec.lifecycle
ownerspec.owner
servicespec.service
datacenterspec.datacenter
dependency ofspec.dependencyOf
depends onspec.dependsOn
pagerduty integration keymetadata.annotations.pagerduty.com/integration-key
priorityspec.priority
slaspec.sla
tagsmetadata.tags
linksmetadata.links

Resulting OpenContext YAML

apiVersion: opencontext.com/v1alpha1
kind: PlatformComponent
metadata:
name: colors-ingress
title: Colors Traefik Ingress
description: Ingress for K8 colors
annotations:
pagerduty.com/integration-key: 'e0efde5a1somethingorother'
labels:
app.kubernetes.io/name: colors
kubernetes.io/ingress.class: traefik
tags:
- java
links:
- url: https://colors.my-monitor.com
title: Monitoring for K8 Colors
icon: dashboard
- url: https://slack.com
title: Slack
icon: chat
spec:
type: ingress
lifecycle: production
owner: [eng-squirrel]
service: k8-colors
datacenter: [kubernetes-1]
dependsOn: [datacenter:kubernetes-1]
dependencyOf: [code-component:colors]
uri: http://colors.nip.io
priority: 3
sla: 24x5