Learn Edge Compute Terms

A stack is a container of one or more StackPath services, such as CDN, WAF, DNS, and more.

Everything in a stack shares the same:

• Combined analytics of included sites
• Service Allocation
• Invoice

StackPath utilizes the concept of stacks to simplify the management of multiple sites, based on technical requirements, as well as to help with track billing. 

A workload is a container or virtual machine image that is deployed to one or many locations.

A workload defines the specifications of its instances, including where to run. 

A workload can be updated at any time to change specifications or targets.

An instance is a grouping of cores, memory, and storage that determines the workload performance.

An instance can deploy as a virtual machine or container. 

A virtual machine is a full software emulation of a physical computer that can perform all operating system tasks. 

Each virtual machine runs a full operating system and is allocated with virtualized system hardware.

A container packages application code, dependencies, and configurations into a single object that can be deployed in any environment.

Containers are created from container images.

A slug is a workload identifier that is:

• Stack-unique
• Immutable
• Human readable
• Stable 

A sidecar container is an additional container added to the main container in an instance.

Root disk is ephemeral storage used to power a virtual machine's operating system or a container's storage needs.  

• IP addresses are sticky, which means that as long as the instance is intact, the instance will retain the same IP addresses.
• If an instance is removed or deleted, then there is no guarantee of IP allocation if the instance is recreated.  

• An instance name (also known as a hostname) is created by combining the following components:
  • The workload's slug
  • Target name
  • Deployment city
  • An ordinal starting from zero.
    • Instances within a deployment are always created in sequential ordinal order, and removed in decreasing ordinal order upon a scaling event.
• Review the following example where the instance name is test123-eu-1hr-0.
  
  • The workload slug is test123. 
  • The target name is eu. 
  • The city code is 1hr.
  • The ordinal is 0. 

• You can create one or more containers within the same isolated environment.
• To isolate instances for container-based workloads, create a lightweight virtual machine which the containers are created within. 
• The only processes running in an isolated environment will be any process launched by the containers specified in the workload. This implies that no SSH server or other typical operating system processes will be running. 

A single virtual machine runs an operating system distribution based on your specifications, such as CentOS, Ubuntu, or Debian.

A virtual machine will have a full set of OS processes running, which will include an SSH server.

• This type of instance may be more familiar to users who do not use container-based technologies.

When you create a virtual machine, you must provide an image that contains the desired operating system.

• StackPath maintains a set of images that you may use, or you can capture an image from an existing virtual machine to create additional instances.
• Currently, you cannot import images. 

• An OCI compatible image such as those found on Docker Hub is required when creating a container. 
• If the image requires authentication to access, credentials can be provided via Image Pull Credentials on the workload.
• Images are pulled directly from their registries, are not held in an intermediate cache, and not guaranteed to be cached on any host in the fleet.

• Exposed to containers as OS Environment Variables, enabling applications to be provided configuration that may be workload specific.
• Used to provide configuration values such as DNS Discovery addresses, log levels, and application specific values to containers when they start.
• An environment variable can obtain its value from either a value field, or a secretValue field. When providing a value via the secretValue field, it will be encrypted on our platform up to the point of being provided to the container, and will be masked in API responses with the value of [REDACTED]. 

• Each container can mount the same volume at the same or different paths. If mounting at the same path, each container will see changes made by other containers. This can be useful for one container emitting logs, and another collecting them to ship to a central store.

• StackPath maintains a set of images that customers may use to create their VMs. In the near future, customers will be able to capture their own images from existing instances, and use them when creating new workloads.
• Note: When updating the value of an image on a workload, only new instances will be impacted by the setting change.

• User Data is a mechanism to provide cloud-init configuration settings for instance initialization.

• Volumes mounted to virtual machines are formatted with a filesystem and mounted to the operating system via cloud-init.

To leverage SRV queries in the DNS Discovery feature, ports must be defined to provide a name to be used in the SRV query.

• To learn more, see Edge Compute DNS Discovery, specifically the Service Discovery section. 

Each port will define the network port number which it will listen on, and the protocol for which it will answer (TCP or UDP).

• Probes are HTTP or TCP actions which the platform will repeatedly execute against an instance.
• There are two types of probes:
  • If a liveness probe fails, then the platform will restart the container or virtual machine with the failing probe.
  • If a readiness probe fails, then the instance will not be considered ready, and will not be added to Anycast announcements.
• An HTTP probe will fail if the target returns a non-200 response (or is not available).
• A TCP probe will fail if it is unable to establish a TCP connection.
• Each probe can be configured with settings such as failure and success thresholds, initial delays, and intervals.
  • To learn more, see Edge Computing: Liveness and Readiness Probes.

• There are 2 types of resources currently available, CPU and memory.
  • To learn more about available configurations available, visit the Edge Compute section of the StackPath site.  
• CPU is the number of cores to allocate per container or VM
• Memory is the amount of memory to allocate per container or VM.

• Volume mounts reference a volume claim template by slug, and specify which path to mount the volume to within the container or virtual machine.

• A volume claim template is used to specify additional, persistent storage that should be attached to each instance.
• Volumes can be sized between 1GiB and 1TiB
• Each instance receives a volume, they are not shared.
• If instances are removed due to scaling events, their corresponding volumes will be removed as well.

• This annotation is provided when the workload is created. 
• When specified, an Anycast IP address will be allocated for the workload and will direct traffic to the appropriate instance of a workload for an incoming connection.
• The value format should be "true".
• After you create a workload, you cannot update, add, or remove this value. 

• This annotation is provided when the workload is created.
• This annotation is required for virtual machine-based workloads, which will configure a virtual machine to permit SSH access to clients with the appropriate corresponding private key.
• The value format should be a newline delimited set of public SSH keys.
• After you create a workload, you can still update the value; however, the update will only take place for newly created instances. 

• This annotation can be enabled or disabled on a workload at any time. 
• When set to "true", the remote management capabilities for the instance will be enabled. 
  • To learn more, see Enable Remote Access and Connect to a Container or Enable Remote Access and Connect to a Virtual Machine.
• The value format should be either "true" or "false".

• This annotation is provided when the workload is created.
• When specified, unicast IP will not be allocated to any instance in the workload. 
• The value format should be "true".
• After you create a workload, you cannot update, add, or remove this value. 

Selectors are filters that let the platform know where a workload's instances should exist by defining constraints on label values.

For locations where workload instances can run, the platform exposes a cityCode label that can be used in a deployment's selector by specifying that the label value should contain certain strings, such as DFW, LHR, HKG, or any cityCode value returned by the Locations API call. 

• To learn more, see Get Locations API.

Workload deployments can be configured to automatically add and remove instances when the observed values of a metric exceed or fall under a specified threshold.

Currently, the only metric available is cpu. 

The deployment scope indicates number of instances (minimum / maximum) that should be in the deployment.

Additionally, the deployment scope influences where individual deployments should be created by specifying the name of a label that exists on locations capable of deploying compute.

For each location matched by the deployment selectors, a unique list of the specified label's values is recorded. For each unique value of the label, a deployment will be created and instances will be created on any location with that value.

Currently, the only valid label for a deployment scope is cityCode.  

• In the future, there will be additional scopes, such as continent, country, and region. This will enable users to define workloads that are more flexible on where they run.
  • As an example of future capabilities, if the selectors are defined to match the cityCode label values of SJC, DFW, SJC, LHR, FRA, CDG, HKG, SIN, MEL and the deployment scope is set to continent, then 4 deployments will be created, one for each continent that would place instances in any of the cities that matched the selectors.