This component enables the running and deployment of Docker containers, along with additional sub-components like a gateway, container registry, and service mesh. Components are registered in the Application Run-time using manifest files, describing their offerings and dependencies. The Application Run-time manages the execution of ZDMP Assets (zComponents or zApps) and includes key components. A web UI is used to manage capabilities and platform setup.
The Application Run-time utilizes standardized component descriptions stored in docker labels and manifest files. The Developer Tier, operating externally, creates platform-compliant containers for the Marketplace. These containers can be installed and accessed as services. ZDMP Assets must expose a RESTful API for control and configuration, registered with connections to Services and the Message Bus for data transfer.
Management and visibility of all components: One place to manage computing infrastructure and services
Extendable across cloud service: Allowing for versatile usage of cloud resources enabling computing to scale with a business
Cloud vendor agnostic: Allowing the choice of infrastructure provider, on-site, Amazon, Google, Microsoft, or alternative VPS (Virtual Private Server) providers
Scalability and versatility: Components and services can be scaled to meet user demands
Fully open source solution so no vendor locking: No tie-in to a single company with benefits from community driven software which is backed by businesses to reduce the integration problems of software deployment
Support: Critical infrastructure can be managed and supported by technical experts in the field
Customized charts simplify the deployment of applications by utilizing Helm Charts. Helm Charts are collections of files that describe Kubernetes resources, allowing for the deployment of various applications, from simple to complex. These charts, along with the applications, can be organized into catalogs and stored in repositories like GitLab or GitHub. Catalogs can be managed at different scopes, including global, cluster, or project levels.
The system provides an API that enables users to manage resources through HTTP calls or the UI. Authentication is performed using HTTP basic authentication and an API Key. The API Key can have access restrictions at the cluster or project level and can have an expiration date. Filtering of collections is possible using HTTP query parameters, and sorting can be done using common fields and query parameters for ascending or descending order. The API UI displays the appropriate requests for these operations.
Services in Kubernetes enable internal communication via internal ports. NodePort or Ingress can publish UIs and APIs to the data gateway. Kubernetes services are accessed through clusterIP, but NodePort allows external access within a port range. Ingress directs traffic to balance loads among pods. HTTPS employs CA-signed external certificates and internal certificates from the Secure Communication component.
The UI allows administrators to review various resources of a zApp, such as workloads, containers, pods, services, volumes, and ConfigMaps. This information helps assess zApp performance and identify and resolve any performance issues. The UI also enables direct editing of configurations, facilitating quick deployment and extraction of correct YAML for offline editing. Logs for each pod in the cluster are accessible for monitoring failures, and they can be downloaded for additional support purposes.
Read our easy to follow documentation to learn how to use the i4 Components.