Azion Edge Services
Azion Edge Services is a module for the Orchestrator product that allows orchestrated services to be managed within your own edge infrastructure.
Azion Edge Services is an Orchestrator product module that allows orchestrated services to be managed in your own Edge Nodes, enabling the resources registration and other configurations via Azion Console and the services creation and customization so that they can be orchestrated on the defined Edge Nodes.
You can configure the install, uninstall, and reload triggers and define the dependencies between the resources needed to run your service on your edge network.
Implementation
| Scope | Guide |
|---|---|
| Edge Services | Creating an Service |
How it works
By using Azion as your edge platform, you can create and customize services to run on private and hybrid edge networks. Azion Edge Services operates using triggers to install, uninstall, and reload. It defines dependencies between resources and natively implements a set of functions for Azion products, such as Applications, Firewall, and Functions, using Azion Cells technology from Azion as its basis.
This way, you can build applications for a wide variety of uses, such as hosting other applications, implementing AI, VR applications, and many others. To do so, you must activate Azion Cells and define the Edge Nodes that should host certain applications, all controlled by the Azion dashboard or APIs, in a centralized interface, and with different access controls.
Resources
To be able to orchestrate services on your device, you need to configure all the resources needed to install, uninstall, and reload your services.
A Text type resource indicates that the content will be copied as plain text to the device. These resource types are typically used for configuration files.
A Shell Script type resource indicates that the resource will be installed and ran according to the selected trigger. The Orchestrator agent uses the sh-bang entered in the content header for script execution. In the absence of one, the POSIX-compliant shell on the device (/bin/sh) is used.
Both resource types are compatible with the use of variables and facts, as long as the tag {{ VARNAME }} or {{ FACT_NAME }} is included.
All resources are executed using the Path referred to during the registration. The Path field refers to the absolute path of the directory. Relative paths won’t be accepted and aren’t supported.
Note: there is a known issue when using the {# syntax. If you use {# and do not use #} as a closure, the resource will not be processed and will not be provisioned in the edges. If you use {# and then use #}, the content inside the block is considered a comment. In this case, the file is processed and provisioned but without the content inside the comment. To provision a resource with {# my content #} you must use the following pattern:{{'{# my content #}'}}. Our engineering team is aware of this issue and is working to fix it.
Variables
Variables are dynamic values that affect the Edge Services that will be orchestrated and run on Edge Nodes. In other words, it is possible to orchestrate and run the same service, on different devices, with different values for the settings, such as configuring a service on port 3306 on one device, and on port 3307 on another device.
Variables can be used in the resource content if the tag{{VARNAME }} is used. For example: port = {{ PORT_HTTP }}
There are some special predefined variables that, as facts, cannot be overwritten. See the list in the table below:
| Variable | Description | Value | Note |
|---|---|---|---|
| CHANGESET_RM_PATH | Contains a path to a file that provides a list of paths to all files that have been removed or modified in the current manifest. | STRING | Only available while the manifest is being applied. Each line has a unique path. |
| CHANGESET_ADD_PATH | Contains a path to a file that provides a list of paths to all files that have been added or modified in the current manifest. | STRING | Only available while the manifest is being applied. Each line has a unique path. |
Facts
In addition to the defined variables, you can also use Facts which are available technical information about your node, such as architecture, client version, operating system, and operating system version. You can use these if you’re setting up multiple Edge Nodes.
These values cannot be overwritten and can be used in resources using the {{ FACT_NAME }} tag. For example:
{{CLIENT_VERSION}}.
| Facts | Description | Value | Notes |
|---|---|---|---|
| CLIENT_VERSION | Orchestrator agent version | MAJOR.MINOR.PATCH | For example: 1.10.3, where 1 is MAJOR, 10 is MINOR and 3 is PATCH |
| ARCH | Processor architecture | ARM or; AMD (x86), both with 32 or 64 bits | |
| OS_NAME | Operating System distribution name | macOS; Linux; FreeBSD; OpenBSD; DragonFlyBSD; NetBSD; or Solaris | |
| OS_DISTRO | Operating System distribution name, only for systems based on Linux | NAME + RELEASE | NAME: Debian; Ubuntu; openSUSE; Mint Linux; Gentoo; Fedora; CentOS; Arch Linux or; Kali Linux RELEASE: first obtaining via LSB Release, if there is no search in /etc/os-release the value of VERSION_ID or DISTRIB_RELEASE In the case of other Operating Systems the value will always be empty. |
| OS_VERSION | Version of the operating system, only for MacOS | MAJOR.MINOR | Example: 10.5. For other Operating Systems it will always be empty. |
| CPUS | Number of CPUs available | INTEGER | Example: 1, 2, 4. |
| RAM_SIZE | Total system memory | BYTES | Example: 1048576 |
Triggers
When configuring Shell Script type resources, you need to define which triggers will cause the resource to run.
The triggers are “Install”, “Reload” and “Uninstall” and each has a function and order of execution:
1) Install: this is the first to be run and must include the script needed to install the service.
2) Reload: when configured, this will be run at the end of the installation of all the resources and also whenever there is any change to the links between the Edge Service and Edge Node, such as a change to the values of the variables.
Uninstall
This is run every time the link between the Edge Services and Edge Node is broken. That means, whenever the service is deleted from the Edge Nodes for which it was provisioned.
Link to the Edge Node
All registered services can be orchestrated and run on one or more Edge Nodes on your private network.
Only active services will be available for orchestration on the Edge Node and, after it has been linked, you can change the value of existing variables or delete or add new services to the device.