Introduction
This article is an overview of the storage options for managing and deploying images and files on an edge node.
Data Store
The data store in ZEDEDA is the file/image storage service interface. The ZEDEDA data store supports both cloud storage-based services and local storage-based services. The applications/images/files themselves are not used and stored anywhere in the ZEDEDA management platform; they are stored in your own file server, third-party cloud storage, or container service. As long as the edge nodes in your enterprise can reach your 3rd party storage locations, the images are directly downloaded from the storage service through the ZEDEDA data store interface. Multiple images can be hosted on a single service.
The following Cloud Storage Services are supported for the images/files:
- AWS S3
- Azure Blob Storage
- On-premises storage
The following services are supported for containers:
- Docker container registry
- Azure ACR
- GCP
- GitHub
- Your own private container registry
- On-premises storage
On-Premise/hosted file servers:
- Support HTTP/HTTPS based file servers
- SFTP based file servers
Vault storage for resources:
- Secret store
- Artifact store
Data store objects capture all the command attributes like access parameters, URLs, and additional resources required to reach the service. The specific details depend on the type of service.
Edge App Image and EVE-OS Image
The image object in ZEDEDA captures the metadata about an image. The image binary is not stored with ZEDEDA. It is referenced through the data store and stored in your own file server, third-party cloud storage, or container service. The image object captures the image name, which data store it is stored on, and the SHA256 checksum of the image if available. The Images are directly pulled from the Edge Node after it receives the metadata from the ZEDEDA Cloud. Each time a device downloads the image, it will always make sure the SHA256 checksum matches before using it.
Enterprise users can upload or uplink their Edge Application images into data stores and update them.
docker hub. Available EVE-OS images can be seen in the ZEDEDA GUI under Library > EVE-OS Images and updated from there.
Volume Instance
When you create an edge app, you define the drive (sometimes called a volume or a partition) details, such as: the drive type, size, mount path, and more. A volume instance is based on the drive definition. A volume instance manages the storage of data for an app instance running on the edge node. It can store image binary data or application runtime data. A volume instance can be persistent and independent of the edge applications using this volume instance for storage. A volume instance can also be transient and tied up with the lifecycle of an edge application that may be using it for storage.
This edge storage solution supports different use cases:
- An edge application may want to refresh its version while retaining the data contents.
- Multiple edge applications may want to share data (volumes instances) between them.
- An Enterprise may want to pre-load an Edge Application binary to a persistent volume before deploying the edge app itself. This allows the Edge Node not to download the image binary again and is helpful in deployment with low bandwidth availability. It also helps provide better control over how exactly the edge app is deployed.
- An Enterprise may want to backup and restore volumes periodically.
- An Enterprise will migrate its applications orchestrated by docker-compose or Kubernetes in a Data Center seamlessly to the edge. This volume instance supports 'volumes' as specified in a docker-compose.yaml, Kubernetes.yaml, helm chart, etc.
Storage Workflow
You don’t have to do it in exactly this order, but this is a good representation.
- You have already onboarded an edge node to ZEDEDA Cloud.
- You have already configured an adapter for management.
- You have already configured a network to connect your edge node to ZEDEDA Cloud.
- You have already configured a network instance to enable network connectivity for your edge apps, including enabling edge app instances on the same edge node to communicate with one another.
- You can create a volume instance and attach it to your edge node at this time if you need the following:
- Persistent storage on the node even after the app that uses it is deleted.
- To share data (volumes instances) between edge applications.
- To "pre-download" an edge app, so that you can deploy it later without downloading (in the case of latency or connectivity concerns).
- You have a standard app (for example, the standard NGINX container from Docker Hub) but you need to provide it some non-standard configuration or other files. You can put those in a separate volume instance and attach that volume instance to the standard app (mount it in the right place like with the docker run -v command). This way, you don't need to create and maintain your own version of the standard app but you still get to customize it.
- Create a data store:
- You have images/applications/files that you store in your own file server, third-party cloud storage, or container service.
- You create a data store in the ZEDEDA GUI to reference the interface of your file server, third-party cloud storage, or container service.
- You create an edge app image, which uses the data store interface you created to access your own file server, third-party cloud storage, or container service.
- You create a local edge app in the marketplace, which uses the edge app image you created (or import a global app).
- You deploy edge app instances to run that app on one or more edge nodes.
- Volume instances are created dynamically at this time (and/or also using the ones you created ahead of time).
Next Steps
- Read about the data store.
- Read about volume instances.