• Deploy
• Edge Orchestrator
• Edge Services

Azion Edge Services is an Edge Orchestrator product module that allows orchestrated services to be managed in your own 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.

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 Edge Application, Edge Firewall, and Edge Functions, using Azion Cells technology from Azion as its basis.

This way, you can build edge 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.

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 Edge 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 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:

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 nodes.

These values cannot be overwritten and can be used in resources using the {{ FACT_NAME }} tag. For example:
{{CLIENT_VERSION}}.

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.

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.

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.

Contributors