balancer

Description

Venue	Equivalent Concept(s)
	Application Load Balancer (ELBv2 ALB)
	Application Gateway

A balancer allows you to design your service delivery for automated scale-out, non-disruptive upgrades, secure web service multiplexing, and more. To use a balancer, you must first declare at least one networking.service, then add a route to the service in the balancer, and finally add the service to one or more compute.nic as a provider.

A balancer has front-end and back-end networking components that depend on the venue. On Azure we will automatically create one subnet (size /24) for all of the balancers in a virtual network. On AWS we will automatically create one subnet per balancer per availability zone (size /28), with a minimum of two zones. Targets in new zones will cause additional front-end subnets to be provisioned, and unnecessary front-end subnets that we create will be cleaned up automatically.

You can control the network range that is used for automatic front-end subnet creation by setting the range property.

You can register the balancer in a DNS domain (public or private) - see the dns property for details.

Features

Back-End

Feature	AWS	Azure
HTTP	✔️	✔️
HTTPS	✔️	✔️
HTTPS Authentication
Health Check Controls	✔️	✔️
Sticky Session Control
Target VM NIC Subinterfaces
Target VM Primary NICs	✔️	✔️
Target VM Secondary NICs		✔️

Balancer Types

Feature	AWS	Azure
Application (Layer 7)	✔️	✔️
Network (Layer 4)

Front-End

Feature	AWS	Azure
DNS Registration	✔️	✔️
HTTP	✔️	✔️
HTTP/2 Protocol Control
HTTPS	✔️	✔️
HTTPS Authentication
HTTPS Security Policy	✔️	✔️
IPv6
Private and Public Facing
Private-Facing	✔️
Public-Facing	✔️	✔️
Static IP Addressing
WAF

Routing

Feature	AWS	Azure
Redirect to Different Host/Port	✔️	✔️
Route to Container
Route to Dynamic Scale Set
Route to FQDN
Route to IP
Route to Lambda/Serverless
Route to Virtual Machine	✔️	✔️
URL Rewrite (Path, Query)

Required Properties

scope (string)

Determines whether the balancer is public or private. Balancers will create and manage their own front-end subnets as needed on each venue. A public balancer will be available with public ip addresses, and a private balancer will only be reachable within the network containing it.

A private scope balancer on Azure will use the Standard SKU, and a public scope balancer on Azure will use the Standard_v2 SKU.

Allowed Values:

• public

• private

Optional Properties

dns (dict)

The DNS configuration for this load balancer. By registering the balancer in DNS, bootstrapping other systems becomes easier because you do not need to know the ip address of the balancer to configure them.

On AWS this will cause the given hostname to be added to the domain as an A record ALIAS. This means if the balancer has any dynamic address changes over time, they are updated automatically in DNS.

On Azure this will do the same for public DNS zones, however on Azure a private DNS zone is not capable of using an ALIAS, therefore we add a regular A record there.

domain (▶ networking.dns)

The DNS domain where the DNS entry will be added or updated. If the balancer has a private scope then the dns domain must also be private.

hostname (string)

The hostname for the DNS entry for this balancer.

network (▶ networking.network)

The network that this balancer belongs to. All of the routes must lead to targets in the same network.

purpose (string)

If a balancer is used for testing purposes some cost optimizations can be made in some venues.

On Azure for a private scope balancer, we use the Standard SKU, therefore a testing purposed balancer will use the Small size and have an instance count of 1. A production purposed balancer will use the Medium size and have an instance count of 4.

There are no current cost optimizations performed on AWS based on this property.

Allowed Values:

• production

• testing

The default value if not specified is production.

range (cidr)

One or more CIDR that define the usable network range(s) of the front-end (listening side) of the balancer. This allows you to control the internal address assigned to the balancer. If this property is omitted, we will reverse-scan your virtual network for available ranges as needed and automatically allocate them. This range must be within the network range.

Example(s):

• 10.0.254.0/24

routes (list of dict)

Define the traffic routes through the balancer. See the documentation for networking.service for additional requirements on supported protocols.

from (▶ networking.service)

Inbound traffic that matches this service will get handled by this route.

to (▶ networking.service)

The service that will handle the inbound traffic.

Common Properties

count (integer)

Indicates how many of this balancer should exist. When count is specified the name of the given resource will have a hyphen and numeric suffix added automatically, unless the count variable is referenced in the blueprint object name.

depends_on (⏩ any)

This property can be used to declare a dependency from this balancer to any other object in the blueprint. This is not necessary for dependencies generated normally by the schema.

folder (▶ location.folder)

The folder containing this balancer. If this is not specified and there is only one folder defined, that folder is used automatically.

name (string)

The name of this balancer. The name can be different than the blueprint object name. When the name property is not present we apply automatic naming strategies to make resources easier to identify in each venue's management console. When the name property is specified we will use it exactly as specified.

readonly (boolean)

Indicates whether or not this balancer is read-only. If so, we verify only the existence and correctness of this balancer to its specification rather than creating or modifying it.

The default value if not specified is false.

tags (dict)

The tags to place on this balancer. Tags are metadata stored in (key = value, ...) form. Consumers are not allowed to use tags that begin with _tuono as those are reserved.

Discovered Properties

These properties are populated and available in the inventory following a successful apply.

id (string)

The venue-specific identifier of this balancer.

nics (⏩ compute.nic)

The connectivity of the balancer is described through nics that are modeled as part of provisioning. Due to differences in networking, there may be a different number of nics on each venue and for each balancer, depending on the targets.

subnets (⏩ networking.subnet)

The front-end subnets created for this balancer. You can control the range of the subnets using the range property. This list of subnets may be a different length depending on the venue and balancer target configuration. On Azure there is always one front-end subnet, and on AWS there are always at least two. This field is discovered.

zones (list)

The availability zones that the balancer is using. These are selected automatically based on the configuration of the back-end service handlers.

Examples

Define a simple balancer for https traffic with a DNS update:

location:
  folder:
    example-folder:
      region: example-region
  region:
    example-region:
      area: west
      country: USA
networking:
  balancer:
    example-balancer:
      dns:
        domain: example-private-dns
        hostname: balancer
      network: example-network
      routes:
        - from: external-http
          to: external-https
        - from: external-https
          to: internal-http-dev
      scope: public
  dns:
    example-private-dns:
      fqdn: dev.example.local
  network:
    example-network:
      range: 10.0.0.0/8
      scope: public
  service:
    external-http:
      port: 80
      protocol: http
    external-https:
      certificate: my-existing-cert
      port: 443
      protocol: https
      security_policy:
        aws: ELBSecurityPolicy-TLS-1-2-Ext-2018-06
        azure: AppGwSslPolicy20170401S
    internal-http-dev:
      health_check:
        healthy_attempts: 3
        healthy_responses: 200-202,302,303 - 304, 388, 399
        interval: 20
        path: /about.php
        timeout: 5
        unhealthy_attempts: 3
      port: 8080
      protocol: http
security:
  certificate:
    my-existing-cert:
      name: www.mycert.com
      readonly: true
      venue:
        azure:
          key_vault_name: MyKeyVault