Skip to main content
logoTetrate Service BridgeVersion: next

Introducing Configuration Profiles for Workloads

The Configuration Profiles for Workloads feature adds an enhanced configuration experience for larger-scale TSB deployments. Configuration Profiles provide a flexible, template-based approach to managing traffic and security settings in TSB. They address limitations of the traditional hierarchical model by decoupling configuration definition from application. Configuration Profiles are a powerful tool for managing configuration in a multi-level environment, where different teams are responsible for different parts of the configuration.

Want to know more?

To learn more about the Configuration Profiles for Workloads feature concepts, check the Concepts section.

Before you get started, make sure you:
✓ Familiarize yourself with TSB concepts, especially around Configuration Profiles.
✓ Install the TSB environment. You can use the TSB demo profile for quick install.
✓ Completed TSB usage quickstart.
✓ Are able to create multiple Tenants and Workspaces; and successfully deploy and use applications inside them.
✓ Are able to use tctl or know how to adjust the examples given here for TSB 'GitOps' mode.

Note: This document assumes you have a couple of applications deployed in multiple Workspaces and Tenants. This feature is specifically designed to be useful in larger scale environments. While it is possible to use configuration profiles using the demo environment with only the TSB usage quickstart artifacts, it will not properly demonstrate the power of configuration inheritance and templating provided by configuration profiles.

Using Configuration Profiles - a Walkthrough

The following steps explain how to effectively use Configuration Profiles for Workloads in a scalable, easy-to-manage manner.

  1. Create sets of configuration items with specific meaning

    While configuration profiles allow you to configure a very broad set of configuration items with respect to authentication, waf, wasm, extensions, and traffic settings; the power of profiles lies in grouping specific configuration values, that together have meaning, into a profile to support your intended service behaviors.

    As an example, we'll demonstrate 3 "topical" profiles dealing with HTTP Client settings for services doing calls to other services:

    • Basic HTTP Client Profile: low traffic, non mission-critical services.
    • Balanced HTTP Client Profile: moderate traffic, important but not critical services.
    • Aggressive HTTP Client Profile: high-traffic or mission-critical services.

    When creating profiles, the location on the hierarchy where you create them matters. If creating them at the organization level, it means the profiles will be available at all Tenants and Workspaces. If creating them at the Tenant level, they will be available for all Workspaces under the Tenant the profile was created, including the Tenant itself.

    In this example we will create the profiles under the Organization so they are available to be attached and used across all Tenants and Workspaces.

    Create a http-client-profiles.yaml file using the following content:

    apiVersion: profile.tsb.tetrate.io/v2
    kind: Profile
    metadata
    name: http-client-basic
    organization: tetrate
    spec:
    displayName: "Basic HTTP Client Profile"
    defaults:
    traffic:
    outbound:
    upstreamTrafficSettings:
    - hosts:
    - "*"
    settings:
    resilience:
    connectionPool:
    http:
    requestTimeout: 2s
    retries:
    attempts: 2
    retryOn: 5xx
    perTryTimeout: 0.2s
    circuitBreakerSensitivity: LOW
    ---
    apiVersion: profile.tsb.tetrate.io/v2
    kind: Profile
    metadata:
    name: http-client-balanced
    organization: tetrate
    spec:
    displayName: "Balanced HTTP Client Profile"
    defaults:
    traffic:
    outbound:
    upstreamTrafficSettings:
    - hosts:
    - "*"
    settings:
    resilience:
    connectionPool:
    http:
    requestTimeout: 5s
    retries:
    attempts: 4
    retryOn: 5xx,gateway-error,connect-failure
    perTryTimeout: 0.5s
    circuitBreakerSensitivity: MEDIUM
    ---
    apiVersion: profile.tsb.tetrate.io/v2
    kind: Profile
    metadata:
    name: http-client-aggresive
    organization: tetrate
    spec:
    displayName: "Aggresive HTTP Client Profile"
    defaults:
    traffic:
    outbound:
    upstreamTrafficSettings:
    - hosts:
    - "*"
    settings:
    resilience:
    connectionPool:
    http:
    requestTimeout: 1s
    retries:
    attempts: 7
    retryOn: 5xx,gateway-error,reset,connect-failure,retriable-status-codes
    perTryTimeout: 0.1s
    circuitBreakerSensitivity: HIGH

    Apply the profiles to TSB using tctl:

    tctl apply -f http-client-profiles.yaml

    You now have 3 http client profiles available for usage at the Organization, Tenant, Workspace, or Group level.

  2. Attach a template at a hierarchical resource

    To activate the configuration found in templates, you must "attach" them to a hierarchical resource like Organization, Tenant, Workspace, or Group. This can be done during the creation of such a resource or by updating an existing resource.

    apiVersion: api.tsb.tetrate.io/v2
    kind: Workspace
    metadata:
    name: biz-portal-blue
    organization: tetrate
    tenant: tetrate
    spec:
    displayName: BizPortal Blue
    namespaceSelector:
    names:
    - prod-us-east-cl12/biz-portal-blue-svc-*
    profiles:
    - organizations/tetrate/profiles/http-client-balanced

    Apply the Workspace with attached Profile to TSB using tctl:

    tctl apply -f ws-biz-portal-blue.yaml

    In the example above the Workspace biz-portal-blue has one of the earlier created HTTP Client profiles (http-client-balanced) attached to it. Take a look at the profile FQN; it shows the attached profile has been created directly under the Organization resource.

    It is also possible to create a Profile at a specific hierarchical node and attach it at that same node. For this you will first need the node to exist before you can create a profile underneath it and attach it. Now that the Workspace exists, a profile can be created underneath it. Let's assume the balanced http client profile fits best but we need a more aggressive request timeout. For this we create a profile at the applicable Workspace level:

    apiVersion: profile.tsb.tetrate.io/v2
    kind: Profile
    metadata:
    name: request-timeout-adjustment
    organization: tetrate
    tenant: tetrate
    workspace: biz-portal-blue
    spec:
    displayName: "Balanced HTTP Client Profile"
    defaults:
    traffic:
    outbound:
    upstreamTrafficSettings:
    - hosts:
    - "*"
    settings:
    resilience:
    connectionPool:
    http:
    requestTimeout: 3s

    Create the adjustment Profile at the Workspace level using tctl:

    tctl apply -f ws-biz-portal-blue.yaml

    Now we can attach the new adjustment profile to the Workspace itself, by listing it in the Workspace resource:

    apiVersion: api.tsb.tetrate.io/v2
    kind: Workspace
    metadata:
    name: biz-portal-blue
    organization: tetrate
    tenant: tetrate
    spec:
    displayName: BizPortal Blue
    namespaceSelector:
    names:
    - prod-us-east-cl12/biz-portal-blue-svc-*
    profiles:
    - organizations/tetrate/profiles/http-client-balanced
    - organizations/tetrate/tenants/b2b-channels/workspaces/biz-portal-blue/request-timeout-adjustment

    Note: the request-timeout-adjustment profile is listed after the http-client-balanced one. The order of profile attachment matters.

    Apply the updated Workspace with attached Profiles to TSB using tctl:

    tctl apply -f ws-biz-portal-blue.yaml
  3. Validate and Iterate

    Configuration Profiles are a very powerful tool. They help avoid duplicate configuration proliferation across similar resources. The danger is that a single profile can have a tremendous impact on many resources that directly or indirectly (through inheritance) use them. To use configuration profiles in a safe, understandable, and sustainable manner, TSB provides tools like blame view and impact analysis:

    Impact analysis

    The impact analysis tool, available both in the TSB UI as well as the TCTL command line tool, provides information about the impact of a profile and possible changes to it on TSB resources and ultimately your workloads. This allows a profile manager to assess the reach of the profile and the impact of proposed changes. By selecting specific properties found in the profile or profile draft, the impact of those selected properties can be assessed.

    As resource owner, impact analysis provides information on the impact of its attached profiles to lower hierarchical resources and ultimately the governed workloads. This allows a resource manager to assess the reach of the attached profiles and the impact of proposed changes in profile attachment and/or profile attachment order.

    tip

    For those customers that only provide read only rights to users for the TSB UI or TCTL, the Impact Analysis tool is fully functional in those setups, including the ability to assess changes to profiles or changes to profile attachments and orderings in hierarchical resources.

    Impact analysis provides a top-down view to profile managers of the impact of their profiles or to resource managers of the impact of the attached profiles to their resources.

    Blame view

    With configuration profiles the usage of configuration inheritance from organization, tenant, workspace, down to group will likely increase. When profiles are attached to the organization or tenant level by platform teams and/or tenant owners, an application team member tasked to configure their application workspace will be confronted with configuration defaults and mandates inherited into their workspace. Where defaults can simply be overridden, mandates stick. If the workspace manager has conflicting configuration it is good to understand where the inherited configuration originated from. The blame view tool provides a view into all configurations inherited from higher hierarchies, their values, and the configuration profiles they originate from. This allows them to know who to reach out to in case a mandate conflicts with what they are trying to achieve as well as have a good understanding of what the default settings are in case they do not override any configuration values.