Terraform Provider ZEDCloud

 
Disclaimer: Terraform Provider ZEDCloud is in the early customer testing phase and is not yet a fully supported feature. Please contact the ZEDEDA Customer Success team if you would like to try out the feature.
 

1. Introduction

Terraform Provider ZEDCloud (TPZ) module allows users to use Terraform to manage their ZEDCloud configuration. Terraform-Provider-ZEDCloud can be considered as yet another user agent, like ZedUI and ZCLI, written in Golang.
 
Use the ZEDCloud provider to interact with the many resources supported by ZEDEDA. You must configure the provider with the proper credentials before you can use it.
 
In the following diagram, you can see that Terraform core sends an execute action command to the ZEDCloud provider, and the ZEDCloud provider sends the response. The ZEDCloud provider interacts with ZEDCloud as well.
 
For more information on Terraform, see Introduction to Terraform. The rest of the document assumes that the user is familiar with Terraform. If not, see Installing Terraform and Initializing Terraform Working Directories.
 

1.1. Understanding ZEDCloud Objects and their Relationships:

The following diagram illustrates the dependencies between various ZEDCloud objects. For example, as shown in the diagram below, 'Edge App Instances' depend on 'Volume Instances', 'Edge App', 'Edge Node', and 'Network Instance'.
A_MGFjZjlkZDY2YjhlM2JmOSUiVKp2VlDafxKpf59pz-MVbDEFyEdaiCAV5uTscrZ2Z3Gr2veJ57CNVvBInLhyCtdJHWE0N4o2WASgGDahqYjWuYrtaYeKU_aKZw9K9KlF.png
 

1.2. Encoding Object Dependencies in Terraform Configuration Files

Users of Terraform-Provider-ZedCloud must understand the dependencies for each object. These dependencies must be specified in the Terraform configuration files (.tf files) for resources. These can be done as an explicit dependency (using the 'depends_on' block) or implicit dependency (using references to other data sources and resources). Wherever possible, using implicit dependencies is recommended. Specifying the dependencies for each resource correctly guarantees that Terraform configures the resources in the appropriate order.
 
See Create Resource Dependencies for more information on Terraform dependency support.
 
Example 1: Edge Node Dependencies
Edge Node (resource zedcloud_edgenode) depends on the following:
  • Network (resource zedcloud_network)
 
The following is an example of specifying such dependencies (implicit dependency):
 
resource "zedcloud_network" "Sample-Network1" {
name = "sample-network1"
<snip>
}
resource "zedcloud_network" "Sample-Network2" {
name = "sample-network2"
<snip>
}
resource "zedcloud_edgenode" "Sample-Device" {
<snip>
interface {
intfname = "eth0"
netname = zedcloud_network.Sample-Network1.name
<snip>
}
interface {
intfname = "eth1"
// This creates implicit dependency on zedcloud_network.Sample-Network2
netname = zedcloud_network.Sample-Network2.name
<snip>
}
}
 
Example 2: Edge Application Dependencies
Edge application depends on the following:
  • Image (zedcloud_image)
 
Since the required image is specified in the manifest file, Terraform doesn't recognize the implicit dependency. Hence an explicit dependency needs to be added. The following is an example of specifying such explicit dependencies:
 
resource "zedcloud_image" "Sample-Image1" {
name = "sample-image1"
<snip>
}
resource "zedcloud_edgeapp" "Sample-EdgeApp" {
<snip>
// Explicit dependency on Sample-Image1
depends_on = [
zedcloud_Image.Sample-Image1
]
}
 
Example 3: Edge Application Instance Dependencies
Edge application instances depend on:
  • Edge Node (zedcloud_edgenode)
  • Network Instance (zedcloud_network_instance)
  • Edge App (zedcloud_edgeapp)
 
The following is an example of adding these as implicit dependencies:
 
resource "zedcloud_edgenode" "Sample-EdgeNode1" {
name = "sample-edgenode1"
<snip>
}
resource "zedcloud_network_instance" "Sample-NetInst1" {
name = "sample-netinst1"
<snip>
}
resource "zedcloud_edgeapp" "Sample-EdgeApp1" {
name = "sample-edgeapp1"
<snip>
}
resource "zedcloud_edgeapp_instance" "Sample-EdgeAppInst1" {
name = "sample-edgeapp-inst1"
// This adds an implicit dependency on Sample-EdgeApp1
app_id = zedcloud_edgeapp.Sample-EdgeApp1.id
// This adds an implicit dependency on Sample-EdgeNode1
device_id = zedcloud_edgenode.Sample-EdgeNode1.id
interface {
intfname = "eth0"
// this adds implicit dependency on Sample-NetInst1
netinstname = zedcloud_network_instance.Sample-NetInst1.name
}
<snip>
}
 

1.3. Schema Documentation

You can access documentation for the schema, including descriptions for all the fields here.
 
  • Users must use either Terraform or ZEDCloud user-agents (ZedUI/ZCLI) to manage the configuration of ZEDCloud objects, but not both.
    • Using both to change the configuration of objects could result in the corruption of objects.
  • Terraform does not offer any monitoring capability. It is a configuration management tool.
    • Users will have to use ZCLI or ZedUI to monitor the Edge Infrastructure and see various states and reports.
  • To migrate objects already created in ZEDCloud to Terraform, see section 4.
    • After an object has been imported into Terraform, Terraform must be used exclusively to manage any further configuration of the object.

 

3. Authenticate ZEDCloud Provider

The following two authentication options are supported:
  • Token-based (recommended)
    • Click here for details on generating the token from ZEDCloud
  • Username/Password
 
Token and username/password are specified in the provider section of the configuration file. The Token is the preferred authentication method. Either Token or username/password must be specified, but not both.
 
Generally, secrets like API token or username/password are not specified directly in plain text in the .tf file. One way to specify such secrets in terraform is to use sensitive variables. Variables can be passed to terraform commands (plan/apply) using environment variables (TFVAR). If environment variables are not set, terraform plan / terraform applied will interactively ask for the values to be provided.
 

3.1. Token-Based Authentication

variable "zedcloud_token" {
description = "ZEDCloud API token. Set environment variable TF_VAR_zedcloud_token"
sensitive = true
type = string
}
provider "zedcloud" {
zedcloud_url = "https://zedcontrol.zededa.net"
token = var.zedcloud_token
}
 

3.2. Username/Password-Based Authentication

variable "username" {
description = "ZEDCloud username. Set environment variable TF_VAR_username"
sensitive = true
type = string
}
variable "password" {
description = "ZEDCloud password. Set environment variable TF_VAR_password"
sensitive = true
type = string
}
provider "zedcloud" {
zedcloud_url = "https://zedcontrol.zededa.net/"
username = var.username
password = var.password
}
 

4. Import Terraform Configuration for Resources

The terraform import command can be used to import the state of existing ZEDCloud objects into Terraform. Once imported, Terraform completely manages the resources for any further changes to the configuration. All ZEDCloud objects supported by Terraform-Provider-ZEDCloud also support terraform import command.
 
To import an existing ZEDCloud object into Terraform state:
  • Identify the ID of the object using ZedUI or ZCLI
  • Add a corresponding resource block for the object in the Terraform configuration (.tf file)
  • use the command 'terraform import <resource_type>.<resource-name> <id>'.
For example: terraform import zedcloud_edgenode.Sample-Device 99999999-bbbb-aaaa-1111-bbbbbbbbbbbb
 
Here is an example of the import command:
Macbook tfdir:$ terraform import zedcloud_edgenode.Sample-Device 3ab53292-ad51-4807-9ae7-d2882cc3c600
zedcloud_edgenode.Sample-Device: Importing from ID "3ab53292-ad51-4807-9ae7-d2882cc3c600"...
zedcloud_edgenode.Sample-Device: Import prepared!
Prepared zedcloud_edgenode for import
zedcloud_edgenode.Sample-Device: Refreshing state... [id=3ab53292-ad51-4807-9ae7-d2882cc3c600]

Import successful!


The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.

Macbook tfdir:$
 

5. Handling Secrets

Users are advised to use sensitive variables to pass secrets in the terraform configuration instead of storing them as plain text in the terraform configuration files. These are recommended for secrets like token, username, and password in the provider section, as well as other sections like Wifi Passwords, App Instance Custom configuration, etc.
 
The following example shows the username and password variables to be used in the provider block:
variable "username" {
description = "ZEDCloud username"
sensitive = true
type = string
}

variable "password" {
description = "ZEDCloud password"
sensitive = true
type = string
}

provider "zedcloud" {
zedcloud_url = "https://zedcontrol.zededa.net"
username = var.username
password = var.password
}
 
To pass the secrets, the user needs to set environment variables of type TF_VAR_<variable name>. Following is an example showing the same:
export TF_VAR_username=foo
export TF_VAR_password=foobar
 
The 'terraform plan' and 'terraform apply' pick up the values for the variables from the environment variables.
 

6. Example Usage Configurations

The following ZEDCloud objects are supported as both resources and data sources:
  • Networks
  • Images
  • Edge Node
  • Volume Instances
  • Edge Application
  • Network Instances
  • Edge Application Instance
 
The following ZEDCloud objects are supported only as data sources:
  • Datastore
 
Note: Datasources support only name as the key.
 
Note: Edge Node creation must be done through ZEDCloud, but can be subsequently managed using Terraform by importing state into Terraform. See the Edge Node section for more details.
 
The rest of the ZEDCloud objects, like projects, device models, users, etc, are not currently supported by Terraform. They have to be managed either through ZedUI or ZCLI. Support for the rest of the ZEDCloud objects will be considered for future releases.
 
Let's see in the following sections, how Terraform manages configuration for each of the above objects. The chronology of these sub-chapters is based on a recommended sequence of operations.
 

6.1. Networks

Network objects are used to configure network connectivity to the edge nodes. Click here to learn further details.
 
The following are some attributes of resource typezedcloud_network:
  • enterprise_default.
    • Set this to true to make this Network the default network for the project.
  • project_id
    • Specify the project ID for the network. If Project ID is not specified, the network object would be created in the default project for the enterprise.
  • kind
    • Specify if this is an IPV4 or IPV6 Network object.
  • ip
    • This block configures the IP address and related aspects of the interface.
    • DHCP
      • Configure the interface to use STATIC IP address or use DHCP Client
 

6.1.1. Configure IPv4 DHCP Client Network Object

The following is a simple Network that configures the edge node interface to be a DHCP Client.
 
resource "zedcloud_network" "TF-sample-network-ip-dhcp-client" {
name = "defaultIPv4-net"
title = "default-network"
description = "Simple IPv4 DHCP Client"
enterprise_default = false
kind = "NETWORK_KIND_V4"
ip {
dhcp = "NETWORK_DHCP_TYPE_CLIENT"
}
// Project ID. For Default project, set to empty string
project_id = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
}
 

6.1.2. Configure Network with Static IPv4 Address

The following is an example of configuring a Network object that would assign a static address to the interface configured with the network.
 
The following fields are the important ones to note:
 
  • dhcp = "NETWORK_DHCP_TYPE_STATIC"
    • This specifies that the Network should assign a static IP address
  • dhcp_range
    • This block specified the range of IP addresses to be used for Static assignment. ZEDCloud picks an IP address from this range to assign to each interface configured
  • subnet
    • A subnet of the IP address
  • dns
    • Specify a list of DNS servers to be used by the edge node
  • domain
    • Specify the Domain to be used
  • gateway
    • Gateway IP address
 
resource "zedcloud_network" "TF-sample-network-ip-sample" {
name = "defaultIPv4-net
title = "default-network
description = "Simple IPv4 DHCP Client"
kind = "NETWORK_KIND_V4"
ip {
// set dhcp to STATIC for Static IPv4 address
dhcp = "NETWORK_DHCP_TYPE_STATIC"
dhcp_range {
start = "172.25.24.1"
end = "172.25.24.25"
}
dns = [
"172.25.24.254"
]
domain = "testtf.com"
gateway = "172.25.24.254"
ntp = "216.239.35.0"
subnet = "172.25.24.0/22"
}
project_id = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
}
 

6.2. Images

zedcloud_image represents an image in ZEDCloud. The image can be an EVE-OS image or an application image. Images are supported as both resources and data sources. Image objects can be used to configure images but not upload the images to ZEDCloud.
 
EVE images used by the Edge Nodes are recommended to be configured as a data source. The data source can then be referenced from the edge node eve_image_version attribute.
 
Application Images are recommended to be configured as resources. An Application image refers to a DataStore, so ZEDCloud must have appropriate data stores already configured.
 
The following are some notable attributes in the zedcloud_image resource:
  • image_arch
    • The following image architectures are supported:
      • AMD64
      • ARM64
  • image_format
    • The following image formats are supported:
      • "RAW"
      • "QCOW"
      • "QCOW2"
      • "VHD"
      • "VMDK",
      • "OVA"
      • "VHDX"
      • "CONTAINER"
  • image_rel_url
    • URL of the image relative to DataStore base URL.
  • image_type
    • The following image types are supported
      • IMAGE_TYPE_EVE
      • IMAGE_TYPE_APPLICATION
 
The following is an example of images as a data source and resource.
data "zedcloud_image" "EVE-OS-6-8-2-kvm-amd64" {
name = "6.8.2-kvm-amd64"
}
resource "zedcloud_image" "TF-Sample-Application-Image" {
name = "TF-Sample-Application-Image"
datastore_id = "99999999-bbbb-aaaa-1111-bbbbbbbbbbbb"
description = "Sample Application Image"
image_arch = "AMD64"
image_format = "QCOW2"
image_rel_url = "tf-sample-app-image"
image_sha_256 = "9449F528B6EFF5EE953E61FA93DD6E3E7376DBAA4954B72B34212695E0FE7715"
image_size_bytes = "2405892096"
image_type = "IMAGE_TYPE_APPLICATION"
title = "TF-Sample-Application-Image"
}
 

6.3. Edge Node

The following diagram illustrates the interaction between Edge Node-related objects only.
A_MGFjZjlkZDY2YjhlM2JmOZbCLBGUHVKXdwLDuX00LNH1l-pmiRTAhmFVpqKh6yjLgqjd6fIDsNEWWwGXosmso3IQ6oM5UUkF7gtSvphIcVhQ_LaPxvE5VmqHAzBf1XeL.png
 

6.3.1. Importing Edge Nodes into Terraform State

The following is the command to import an edge node into Terraform state:
terraform import zedcloud_edgenode.<resource-name> <id of edge-node>
 

6.3.2 Creating Edge Node using Terraform

The following are some notable fields used for onboarding the Edge Node:
  • model_id – id of the model object for the Edge Node.
  • project_id – id of the project to which the Edge Node belongs.
  • serialno – serial number of the Edge Node as reported by EVE-OS.
  • eve_image_version – version of EVE-OS image to be used by the Edge Node. This must be specified when configuring an EdgeNode using Terraform.
 
The following is an example of creating an Edge Node using Terraform:
resource "zedcloud_edgenode" "Sample-Device" {
adminstate = "ADMIN_STATE_ACTIVE"
asset_id = "sample asset id"
config_items = {
// Add Desired Config Items here
"debug.disable.dhcp.all-ones.netmask" = "true"
"network.fallback.any.eth" = "disabled"
"timer.config.interval" = "100"
"timer.reboot.no.network" = "31536000"
}
cpu = 4
description = "Sample device Description"
eve_image_version = "6.8.2-kvm-amd64"
id = "aaa-ad51-4807-9ae7-d2882cc3c600"
memory = 8192
model_id = "99999999-bbbb-aaaa-1111-bbbbbbbbbbbb"
name = "sample edge node"
project_id = "99999999-bbbb-aaaa-1111-aaaaaaaaaaaa"
serialno = "Test Serial Num"
storage = 256
tags = {
"tag1" = "tag-value1"
"tag2" = "tag-value2"
}
thread = 2
title = "Sample Device Title Test"
utype = "AMD64"

dev_location {
city = "San Jose"
country = "USA"
hostname = "sample-device"
org = "Zededa Engineering"
postal = "95116"
region = "Alameda County"
underlay_ip = "10.1.1.1"
}

interface {
cost = 0
intf_usage = "ADAPTER_USAGE_MANAGEMENT"
intfname = "eth0"
tags = {}
}

interface {
cost = 0
intf_usage = "ADAPTER_USAGE_UNSPECIFIED"
intfname = "eth1"
tags = {}
}
}

 

6.3.3. Configuring EVE-OS Runtime Configuration Properties

ZEDCloud supports the following EVE-OS runtime configuration properties.
  • timer.config.interval
    • Configure how frequently Edge Node gets config
    • Value: Integer in seconds ( for example '100')
  • network.fallback.any.eth
    • if no connectivity, try any Ethernet, WiFi, or LTE
    • Value: 'enabled' or 'disabled'
  • debug.disable.dhcp.all-ones.netmask (true/false)
    • Disables the network mask /32 in DHCP configuration in Network Instances.
    • Value: Boolean ('true'/'false')
  • timer.reboot.no.network
    • Reboot the Edge Node if there is no connectivity to ZEDCloud for the specified time.
    • Value: Integer in seconds (for example '100')
  • timer.use.config.checkpoint
    • Use checkpointed config if the device has no cloud connectivity after reboot after the specified time.
    • Value: Integer in seconds (for example '100')

 

The config_itemsblock must be used to configure EVE-OS runtime configuration properties. The following is an example of using config_items.

resource "zedcloud_edgenode" "Sample-Device" {
name = "TF-Sample-Device"
<snip>
config_items = {
"timer.config.interval" = "100"
"debug.disable.dhcp.all-ones.netmask" = "true"
// Disable the network-fallback option
"network.fallback.any.eth" = "disabled"
// Set the reboot-on-no-network timer to 1 year
"timer.reboot.no.network" = "31536000"
// Set the config checkpoint timer to 1 year
"timer.use.config.checkpoint" = "31536000"
}
<snip>
}
 

6.3.4. Update EVE-OS Image

To update the EVE-OS image on the Edge Node, set the attributeeve_image_versionto the appropriate image version. The recommended workflow is as follows:
  • Verify if the required EVE-OS image is in the ZEDCloud. Either use ZCLI or ZedUI to verify the same.
  • Add the Image as a data source.
    • This guarantees that the image exists in ZEDCloud before Terraform attempts to update the Edge Node configuration.
  • Set theeve_image_versionattribute in the edge node resource block to the target EVE-OS version using the image data source from (2) above.
    • Using a reference to the image data source adds an implicit dependency for the Edge node on the Image object.
    • This ensures Terraform first verifies the image state before updating the Edge Node Configuration
  • The next terraform apply will update the edge note configuration with the new eve image version, along with any other changes in the configuration.
 
data "zedcloud_image" "6-8-2-kvm-amd64" {
name = "6.8.2-kvm-amd64"
}
resource "zedcloud_edgenode" "Sample-Device" {
name = "TF-Sample-Device"
<snip>
eve_image_version = data.zedcloud_image.6-8-2-kvm-amd64
<snip>
}
 

6.3.5. Configure Edge Node Interfaces

Use interface blocks to configure interfaces of an Edge Node, one block for each interface. Each interface used by an application or by EVE on the edge node must be specified in the EdgeNode configuration. The available interfaces are specified in the Device Model used by the device. The following are some notable attributes in the interface block:
  • intf_name
    • Mandatory attribute. Name of the interface.
  • intf_usage
    • The following are the different types of interface usage values
      • ADAPTER_USAGE_MANAGEMENT
        • The Interface is managed by EVE-OS but can be used by both Management and Application instances.
      • ADAPTER_USAGE_APP_DIRECT
        • The Interface is managed by the Application Instance using its own driver.
        • The Interface can be assigned to only one Application Instance at a time.
      • ADAPTER_USAGE_APP_SHARED
        • The Interface can be used by multiple Application Instances simultaneously, but not by EVE-OS.
      • ADAPTER_USAGE_DISABLED
        • Neither EVE nor Application Instances can use the interface. The interface is disabled.
  • netname
    • Name of the Network object to use for the interface if intf_usage is ADAPTER_USAGE_MANAGEMENT
    • if netname is not specified for management interfaces (usage=ADAPTER_USAGE_MANAGEMENT), the default network for the project is used.
  • tags
    • Specify tags to be used in policies.

 

resource "zedcloud_network" "Default-Network" {
name = "default-ipv4-network"
<snip>
}
resource "zedcloud_network" "dhcp-passthru-network" {
name = "default-ipv4-network"
<snip>
}
resource "zedcloud_edgenode" "Sample-Device" {
name = "TF-Sample-Device"
<snip>
interface {
intf_name = "eth0"
intf_usage = "ADAPTER_USAGE_MANAGEMENT"
tags = {
"intf-tag1" = "tag-value1"
"intf-tag2" = "tag-value2"
}
}
interface {
netname = zedcloud_network.Default-Network.name
intfname = "eth0"
intf_usage = "ADAPTER_USAGE_MANAGEMENT"
}
interface {
intfname = "eth1"
intf_usage = "ADAPTER_USAGE_DISABLED"
}
interface {
intfname = "USB1"
intf_usage = "ADAPTER_USAGE_APP_DIRECT"
},
interface {
intfname = "GPU"
intf_usage = "ADAPTER_USAGE_APP_DIRECT"
},
interface {
intfname = "GPU-Audio"
intf_usage = "ADAPTER_USAGE_APP_DIRECT"
},
interface {
intfname = "eth5"
intf_usage = "ADAPTER_USAGE_DISABLED"
},
interface {
intfname = "wlan0"
intf_usage = "ADAPTER_USAGE_DISABLED"
},
interface {
netname": "default-VZN-APN"
intfname = "wwan0"
intf_usage = "ADAPTER_USAGE_MANAGEMENT",
},
interface {
netname": zedcloud_network.dhcp-passthru-network.name
intfname = "eth1"
intf_usage = "ADAPTER_USAGE_APP_SHARED"
},
interface {
intfname = "VGA"
intf_usage = "ADAPTER_USAGE_APP_DIRECT"
},
<snip>
}
 

6.3.6. Configure Device Location

Optional Configuration. The location of the device can be specified using the dev_location block. The following is an example of usingdev_locationblocks.
 
resource "zedcloud_edgenode" "Sample-Device" {
name = "TF-Sample-Device"
<snip>
dev_location {
city = "San Jose"
country = "USA"
free_loc = ""
hostname = "sample-device"
latlong = ""
loc = ""
org = "Zededa Engineering"
postal = "95116"
region = "Alameda County"
underlay_ip = "10.1.1.1"
}
<snip>
}

 

6.4. Volume Instances

See Volume Instances for information on Volume Instance objects in ZEDCloud.
Volume Instance depends on the following objects:
  • Edge Node (zedcloud_edgenode)
  • Image (zedcloud_image)
 
The following are some notable attributes of(zedcloud_volume_instance):
  • accessmode
    • The following types of access modes are supported:
      • VOLUME_INSTANCE_ACCESS_MODE_READWRITE
      • VOLUME_INSTANCE_ACCESS_MODE_READONLY
      • VOLUME_INSTANCE_ACCESS_MODE_MULTIREAD_SINGLEWRITE
  • device_id
    • id of zedcloud_edgenode
    • It is recommended to use implicit dependency on a data source or resource of type zedcloud_edgenode
  • image
    • name of zedcloud_image
    • It is recommended to use implicit dependency on a data source or resource of type zedcloud_image
  • implicit
    • Create implicit volume if true
  • multiattach
    • Allow volume instance to be attached to. multiple Application Instances
  • type
    • The following Volume Instance Types are supported:
      • VOLUME_INSTANCE_TYPE_EMPTYDIR
      • VOLUME_INSTANCE_TYPE_BLOCKSTORAGE
      • VOLUME_INSTANCE_TYPE_HOSTFS
      • VOLUME_INSTANCE_TYPE_TMPFS
      • VOLUME_INSTANCE_TYPE_SECRET
      • VOLUME_INSTANCE_TYPE_NFS
      • VOLUME_INSTANCE_TYPE_AWS_BLOCK_STORAGE
      • VOLUME_INSTANCE_TYPE_CONTENT_TREE
         
resource "zedcloud_edgenode" "TF-sample-edgenode" {
name = "tf-sample-edgenode"
<snip>
}
resource "zedcloud_image" "TF-sample-image" {
name = "tf-sample-image"
<snip>
}
resource "zedcloud_volume_instance" "TF-sample-vol-inst-RO-content-tree" {
accessmode = "VOLUME_INSTANCE_ACCESS_MODE_READONLY"
description = "Immutable Volume"
device_id = zedcloud_edgenode.TF-sample-edgenode
image = zedcloud_image.name
implicit = true
multiattach = false
name = "sample-volinst-1"
project_id = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
size_bytes = "140443648"
title = "Sample Title"
type = "VOLUME_INSTANCE_TYPE_CONTENT_TREE"
}
 

6.5. Edge Application

See Edge Application Overview for an overview of ZEDCloud Edge Application support.
Edge Application object depends on Image Object (zedcloud_image)
The following diagram illustrates the interaction between edge application configuration-related objects only.
 
A_MGFjZjlkZDY2YjhlM2JmOdV7jlKYZZxn850UTZvHH7QkneIlc6aPpAbQQPt8incOT4uJwrbWf5xcqG3xk159d71eFGfLvvtoMdpBA6Yp_TmL_rDAapMsJlFfRedoWXYG.png
Terraform resource zedcloud_edgeapp has a notable difference from resource definitions for other ZEDCloud objects. The EdgeApp manifest is stored in an external file. The image used by the app is specified in the manifest file. There needs to be an explicit dependency on the image using the depends_on block.
 
The following are the notable attributes for zedcloud_edgeapp:
  • manifest
    • Inline Definition of the app-manifest. Only one manifest or manifest_file must be specified.
  • manifest_file
    • Location of the manifest file. Used when app-manifest is stored in a file instead of defining it inline in terraform. Only one manifest or manifest_file must be specified.
  • user_defined_version
    • The version of the application is specified by the user.
    • When changes are made to the manifest file, there should be a change to user_defined_version to trigger Terraform to re-process the manifest.

Example of Edge-App definition using the inline manifest definition:

resource "zedcloud_edgeapp" "ExampleApp" {
    name                 = "sampleName"
    title                = "Sample Title"
    description = "Sample Description"
    user_defined_version = "1.1"
    manifest {
        apptype         = "APP_TYPE_VM"
        deployment_type = "DEPLOYMENT_TYPE_STAND_ALONE"
        description     = "Sample Description"
        enablevnc       = true
        name            = "sampleName"
        vmmode          = "HV_HVM"

        configuration {
            custom_config {
                add                  = true
                allow_storage_resize = true
                field_delimiter      = "##"
                name                 = "cloud-init"
                override             = false
                template             = "Sample Template"

                variable_group {
                    name     = "Default Group 1"
                    required = true

                    variable {
                        default    = "www.example.com"
                        encode     = "FILE_ENCODING_UNSPECIFIED"
                        format     = "VARIABLE_FORMAT_TEXT"
                        label      = "SampleVariable"
                        max_length = "200"
                        name       = "myVar"
                        required   = true
                    }
                }
            }
        }
        image {
            cleartext   = false
            drvtype     = "HDD"
            ignorepurge = false
            imagename   = "SampleImage"
            maxsize     = 52428800
            preserve    = false
            readonly    = false
            target      = "Disk"
        }

        interface {
            directattach = false
            name         = "eth0"
            optional     = false
            privateip    = false

            acl {

                match {
                    type  = "ip"
                    value = "0.0.0.0/0"
                }
            }
        }
        interface {
            directattach = false
            name         = "eth1"
            optional     = false
            privateip    = false

            acl {

                match {
                    type  = "ip"
                    value = "0.0.0.0/0"
                }
            }
        }
        interface {
            directattach = false
            name         = "eth2"
            optional     = false
            privateip    = false

            acl {

                match {
                    type  = "ip"
                    value = "0.0.0.0/0"
                }
            }
        }
        interface {
            directattach = false
            name         = "eth3"
            optional     = false
            privateip    = false

            acl {

                match {
                    type  = "ip"
                    value = "0.0.0.0/0"
                }
            }
        }
        owner {
            company = "ZEDEDA Inc."
            email   = "sample@sample.com"
            user    = "Sample User"
            website = "www.zededa.com"
        }

        resource {
            name  = "resourceType"
            value = "Custom"
        }
        resource {
            name  = "cpus"
            value = "2"
        }
        resource {
            name  = "memory"
            value = "4194304.00"
        }
        resource {
            name  = "storage"
            value = "104857600.00"
        }
    }
}

Example of Edge-App definition using an external manifest file:

resource "zedcloud_edgeapp" "TF-sample-app" {
name = "TF-sample-app"
title = "TF-sample-app"
description = "TF-sample-app"
manifest_file = "./TF-sample-app-manifest.json"
user_defined_version = "1.0"
depends_on = [
zedcloud_image.TF-sample-image,
]
}

 

6.6. Network Instances

See Network Instances for a functionality overview of Network Instances.
 
Network Instance object depends on Edge Node (zedcloud_edgenode). The following are some of the notable fields in a Network Instance:
  • ip
    • Specify DHCP Server Configuration to be used by EVE to service DHCP client requests. It has the following attributes:
      • dhcp_range
        • This block specified the range of IP addresses to service DHCP client requests from App Instance.
      • dns
        • Specify a list of DNS servers to be sent in the used by the edge node
      • domain
        • Specify the Domain to be used in DHCP response.
      • gateway
        • Gateway IP address
      • ntp
        • NTP server address
      • subnet
        • The subnet of the IP address
  • kind
    • The following kinds of network instances are supported:
      • NETWORK_INSTANCE_KIND_SWITCH
      • NETWORK_INSTANCE_KIND_LOCAL
  • type
    • DHCP type The following values are supported:
      • NETWORK_INSTANCE_DHCP_TYPE_UNSPECIFIED
      • NETWORK_INSTANCE_DHCP_TYPE_V4
      • NETWORK_INSTANCE_DHCP_TYPE_V6
 

6.6.1 Configuring Local (NAT) Network Instance

The following is an example configuration for a LOCAL (NAT) Network Instance.
resource "zedcloud_network_instance" "TF-Sample-test-full" {
name = "TF-Sample-test-full"
title = "default-gcp-alpha-acme-kalyan-1"
description = "default-gcp-alpha-acme-kalyan-1"
kind = "NETWORK_INSTANCE_KIND_LOCAL"
type = "NETWORK_INSTANCE_DHCP_TYPE_V4"
device_id = zedcloud_edgenode.Sample-Device.id
// Configure DHCP parameters for the Network Instance.
ip {
dhcp_range {
end = "10.10.1.0"
start = "10.10.1.255"
}
dns = [
"www.tftestdns1.com",
"www.tftestdns2.com"
]
domain = "tftest.com"
gateway = "10.10.1.1"
ntp = "10.10.1.2"
subnet = "10.10.1.0/24"
}
}
 

6.6.2 Configuring Switch Network Instance

The following is an example configuration for a Switch Network Instance.
resource "zedcloud_network_instance" "TF-nwinst-switch-1" {
name = "sample-ni-switch-1"
description = "sample-ni-switch-1"
title = "sample-ni-switch-1"
device_id = data.zedcloud_edgenode.data-Sample-Device.id
kind = "NETWORK_INSTANCE_KIND_SWITCH"
type = "NETWORK_INSTANCE_DHCP_TYPE_V4"
}

 

6.7. Edge Application Instance

See Edge Application Instance Overview for an overview of ZEDCloud Edge Application Instances.
The following diagram illustrates the interaction between edge application instance configuration-related objects only.
 
A_MGFjZjlkZDY2YjhlM2JmOfcPMre12S8sCLtBNZADXtrr2k5d8XCa-2hu7nvHdYbUow4t3oEiAtb4DvcuO1EodGdaMr2-bXYDf7506ylECylxI4H85jqhAl7GHxo6uJja.png
As illustrated above, the Edge Application Instance depends on the following ZEDCloud objects:
  • Edge Node
  • Edge App
  • Network Instances
  • Volume Instances
The following are some notable attributes for Terraform Resourcezedcloud_application_instance.
  • activate
    • Used to activate (set to true)/deactivate (set to false) an Edge Application Instance. This MUST be set to true for the App instance to be active.
  • app_id
    • id of the Edge Application Object
  • app_type
    • Type of Application. The following application types are supported:
      • APP_TYPE_VM
        • Used to create a VM application
      • APP_TYPE_VM_RUNTIME
        • Used for Kubernetes Cluster modules.
      • APP_TYPE_CONTAINER
        • Used for Container Applications
      • APP_TYPE_MODULE
        • Used for modules like Azure IoT Edge
  • custom_config
    • configuration to customize the Edge Application Instance. This is passed to the cloud_init module of the application.
  • device_id
    • id of the Edge Node running the Edge Application Instance
  • interface
    • Configuration for the interfaces used by the Edge Application Instance.
  • remote_console
    • Enable (true) or Disable (false) remote console access to the Edge Application Instance.
 
 
 
 
 
 
 

6.7.1. Configuring Edge Application Instance Interfaces

Theinterfaceblock is used to configure the interfaces used by the Edge Application Instance. The following are some notable attributes of the interface block.
  • intfname
    • Environment Name of the Interface as specified in the Edge App Manifest
  • io
    • Physical adapter configuration. This is required if directattach is true
  • netinstname
    • Name of network instance to be used for the interface.
 
The following is an example Interface block:
interface {
intfname = "indirect"
netinstname = zedcloud_network_instance.default-nwinst.name
}
interface {
intfname = virtualNIC"
netinstname = "truck-oslc-h-5555-2-sw1"
}
interface = {
intfname = "GPU"
// NOTE - Since directattach = true here, it is required to set io block
io {
name = "GPU"
type = "IO_TYPE_OTHER"
}
}
interface {
intfname = "USB"
io {
name = "USB1",
type = "IO_TYPE_USB"
}
}
 
 

6.7.2. Virtual Machine type of Edge Application Instance

The following is an example of a configuration for an Edge Application Instance of type VM, with one interface:
 
resource "zedcloud_edgeapp_instance" "Sample-EdgeAppInstance" {
name = "TF-Sample-Resource-EdgeAppInstance"
activate = true
app_type = "APP_TYPE_VM"
app_id = zedcloud_edgeapp.TF-sample-app.id
description = "TerraForm Sample App Instance - TESTING Update"
device_id = zedcloud_edgenode.Sample-Device.id
interfaces {
intfname = "indirect"
netinstname = zedcloud_network_instance.default-nwinst.name
}
title = "TerraForm Sample App Instance"
remote_console = true
}
 

6.8. Datastore

Datastores are only supported as a data source. For more information on Datastores, click here. Following is an example of a Datastore as a data source:
 
data "zedcloud_datastore" "sample-datastore" {
name = "sample-datastore"
}
 

7. Error Handling

If there is an error in any of the operations, the provider returns an appropriate error for the operation. If the request to ZEDCloud fails, the error code, and any error strings returned by ZEDCloud, will be returned to Terraform.
 
When an operation fails, the user should look at the error reported by Terraform and take the necessary action. The errors provided byterraform apply will have the following information:
  • The Resource in the .tf file that ran into the error
with zedcloud_edgenode.Sample-Device,
on onedevice_oneappinst.tf line 31, in resource "zedcloud_edgenode" "Sample-Device":
31: resource "zedcloud_edgenode" "Sample-Device" {
  • The Error message provided by the provider
    • The error message should provide enough details for the user to understand and fix the error.
Error: [ERROR] 3ab53292-ad51-4807-9ae7-d2882cc3c600 Edge Node
( id: gcp-alpha-acme-kalyan-1) Update Failed. BaseOsImage Publish failed.
Err: Request FAILED. StatusCode: 400 Bad Request. Rsp Error Details:
Details: Entry not found, EC: BadReqBody
 
 
Was this article helpful?
0 out of 0 found this helpful

Articles in this section