# Entando Architecture Concepts
This document explores the architecture of the Entando Platform and some notable runtime characteristics.
Note: A portal, website, web app, or mobile app built with Entando is called an Entando Application. An Entando Application is an assembly of out-of-the-box and/or custom-built components running on the Entando Platform. Entando components can be widgets, micro frontends, microservices, page templates, WCMS content or WCMS content types.
# Key Entando Concepts
# Entando App Builder
The Entando App Builder is the frontend of the Entando Platform with which an Entando Application is created and customized. It hosts the Entando WCMS and provides a feature-rich, low-code user interface to configure and interact with components, design and create pages, manage content, and build modular applications.
See also: Widget Tutorial
# Entando App Engine
The Entando App Engine is the core runtime engine responsible for the primary out-of-the-box services required to develop Entando Applications. It exposes the backend APIs used to deliver the page and content management interface of an Entando Application, assembles and coordinates components within the Entando App Builder, and provides the data access layer to persist pages and application design.
See also: APIs tutorial
# Entando Component Generator
The Entando Component Generator implements a JHipster (opens new window) blueprint to quickly and efficiently generate the skeleton of an Entando project using automation and templating. The generator provides advanced data modeling capabilities, including object relational mapping, and the autogeneration of micro frontends and microservices. The Entando Blueprint fast-tracks development by creating the folders, files and infrastructure required by a project.
See also: Component Generation Technologies
# Entando Identity Management System
Entando Identity Management System is Entando's Keycloak (opens new window)-based user management and authentication system. It applies Single Sign On capabilities across multiple domains to connect service providers with identity providers.
See also: Entando Authentication
# Entando Local Hub
The Entando Local Hub is the component repository of an Entando App Builder. The Entando Bundles available to the Entando Application are represented and can be deployed, installed, updated or versioned using the App Builder UI.
# Entando WCMS
The Entando Web Content Management System (WCMS) is a lightweight content and digital asset management system. It manages widgets, HTML fragments, and other content types used in an Entando Application.
See also: Content Types, Content Templates and Digital Assets
# Entando Cluster Elements
The following is an overview of the elements comprising an Entando Cluster.
# Architecture - Members of the Cluster
Below is a diagram of an Entando Cluster and depicts how the various elements interact with one another. Entando deploys this infrastructure on Kubernetes using the Entando Operator and controllers. Each element is associated with a custom resource definition (CRD) file, if applicable.
The EntandoApp is comprised of the Entando App Builder, the Entando App Engine and the Entando Component Manager. Keycloak-based authorization and authentication enable these to interact with each other and other cluster elements.
# Entando Component Manager
The purpose of the Entando Component Manager is to:
- Provide the functionality to deploy and install micro frontends and widgets
- Manage the connections between an application and the installed microservices
It integrates the Local Hub into the App Builder to list the Entando Bundles accessible from the EntandoApp, provisioning bundle management services such as install, uninstall, upgrade, downgrade and versioning. The Entando Kubernetes integration service communicates with the cluster to supply these bundle services and is the only service, other than the Entando Operator, that can interact with the cluster and custom resources.
# Entando Kubernetes Service
The Entando Kubernetes integration service (
entando-k8s-service) is a function of the Entando Cluster infrastructure custom resource, providing an abstraction layer between Entando microservices and the APIs exposed by Kubernetes. It supplies access points to several custom resources defined by Entando, in particular Entando Applications, Entando Plugins, Entando Bundles and Entando links.
entando-k8s-service is used to:
- Provide a list of the available Entando Bundles to the Entando Component Manager
- Deploy a microservice, or expose an already available microservice, during the installation of a bundle
- Create a link between an EntandoApp and an EntandoPlugin to expose microservice APIs to the EntandoApp and micro frontends
# Entando Bundle
An Entando Bundle is a packaged set of components and resources created for the Entando Platform. The Entando Component Manager identifies the bundles and can install their components to extend the functionality of an Entando Application.
See also: Local Hub Overview
# Entando Plugin
An Entando Plugin is a microservice that exposes APIs reusable by one or more Entando Applications. Plugin services are commonly accessible from micro frontends and can be quickly generated with the Entando Blueprint. A blueprint-generated project can be used as-is in an Entando environment and provides Keycloak integration, a set of default micro frontends, and microservices exposed by the bundle.
Keycloak is responsible for authorization and authentication on Entando. All members of an Entando Cluster interact with Keycloak to verify user and service authorization.
# Entando Ingresses
An ingress is a Kubernetes resource that exposes HTTP and HTTPS paths from outside an Entando Cluster to services within it. Traffic routing is controlled by rules defined on the ingress resource.
When deploying a cluster, ingresses are generated for the resources that must be exposed to external services. The Entando Operator and custom resource controllers create the ingresses and set the correct paths and certificates. Entando implements Keycloak and EntandoApp ingresses.
# Keycloak Ingress
A dedicated ingress is created for Keycloak to expose authentication and authorization functionalities. This is required to guarantee that both token issuing and validation work correctly, even when the services using the Keycloak instance are in different namespaces.
# EntandoApp Ingress
The EntandoApp ingress is automatically created to expose the App Builder, App Engine and Component Manager. The three containers are served under the same domain, which allows them to interact without cross-origin issues.
The EntandoApp ingress is also used to link a microservice with an EntandoApp when a bundle containing the microservice is installed via the Local Hub.
# Default Ingress HTTP Paths
The table below lists the default paths exposed for each ingress.
|Ingress||Ingress Http route||Application|
Entando Component Manager
Entando Plugin linked to the application
Note: The Entando Plugin variable
ingressPathis defined in the plugin custom resource under the
specelement and used to expose the plugin within the EntandoApp domain. See also: Microservice Specifications.
# Exposing Microservices in the EntandoApp Domain
A microservice under the same domain (ingress) as the EntandoApp is exposed using the
EntandoAppPluginLink custom resource and the corresponding controller.
Once the link between the EntandoApp and the microservice is created, the controller reads the link specification. It then automatically creates HTTP paths in the EntandoApp to expose the microservice in the same domain as the App Builder, App Engine and Component Manager. This allows micro frontend developers to reference the microservice using relative URLs.
See also: Entando Deployment Structure and Check Ingresses