# Entando Deployment Structure

This page provides a high level overview of the key Entando GitHub repositories along with a brief description of how those repositories are realized in a running Entando deployment. The descriptions provided here are meant as a guide for identifying opportunities to dig deeper into the architecture and how things are structured rather than a panacea for understanding the architecture.

# entando-operator

The Entando operator coordinates the installation and configuration of all of the components of an Entando Cluster. The operator can be installed once per Entando Cluster and used to coordinate the plugin lifecycle for multiple Entando applications across many namespaces.

# Customization

It is unlikely that the operator will be customized as part of an Entando implementation. It is not built to be extended inside the codebase. The most common pattern will be to use the existing custom resources that the operator knows how to deploy to extend the Entando platform.

# database init containers

During installation an Entando application needs to create several databases and also to initialize those databases with information when deploying from a backup in your images. At initialization the entando-k8s-dbjob will be run 5 times in total. Once for keycloak, twice for the entando application (port and serv dbs), once to populate the Entando application database, and once to create the Component Repository database.

The screenshot below highlights the init containers for the Entando application schema creation, db initialization, and component repository database.

Init Containers Screenshot

Many managed kubernetes instances like OpenShift won’t show init containers in their dashboards. So if you’re troubleshooting you may need to look deeper. When fetching logs for an init container using kubectl you must pass the container name as an argument to the call. For example,

    kubectl logs <pod> -c <container> -n <namespace>        
    kubectl logs quickstart-kc-db-preparation-job-ddbdbddb-a  -c quickstart-kc-db-schema-creation-job -n sprint1-rc

# Customization

It is unlikely that the init containers will be customized as part of an Entando project. The init containers will automatically restore a backup included in your application so that you can create custom images that include your application setup. See Backing Up and Restoring Your Environment.

# entando-de-app

The entando-de-app is a J2EE application and is an instance of the entando-core (see a description of the entando-core repo below). Reviewing the dependencies of this application in the pom.xml will reveal the dependencies on the entando-core, entando-engine, and admin-console which encompass the core functionality in versions of Entando prior to Entando 6. In a quickstart deployment the entando-de-app is deployed as part of the entando-composite-app multi container pod.

# Customization

The entando-de-app is very likely to be customized as part of an Entando implementation. This image can be customized with new APIs, legacy Entando plugins, new database tables, or other extensions to the entando-core. It is highly recommended that most extensions to the platform in Entando 6 occur in microservices. However, legacy integrations, extensions to the CMS, and migrations from earlier Entando versions may require changes to the entando-de-app.

# app-builder

The app-builder is the front end of the entando-de-app. It communicates with the entando-de-app via REST APIs. The app-builder is a React JS application and is served via node in the default deployment. In a quickstart deployment the app-builder container is deployed in the entando-composite-app multiple container pod. The app-builder also communicates with the Component Manager via REST API to fetch information about Entando bundles deployed to the Entando Component Repository (ECR).

# Customization

The app-builder is built to be customized and will be customized as part of many Entando implementations. The app-builder can be customized at runtime via micro frontends widget configuration. The app-builder can also be customized via the integration of custom modules that are added at build time.

# component-manager

The component-manager provides the link between the entando-de-app (or your custom core instance) and the Entando Component Repository (ECR). The component-manager queries the entando-k8s service to fetch available bundles that have been deployed as custom resources inside of an Entando cluster. The component-manager also manages the relationships between an Entando application and the installed plugins. This can be seen in the plugin link custom resources in Kubernetes.

# Customization

It is unlikely that the component-manager will be customized as part of an Entando implementation.

# entando-k8s-service

The entando-k8s-service acts as an abstraction layer to fetch data from kubernetes APIs. The primary functionality is in discovering and making available for installation Entando plugins. The entando-k8s-service is invoked by the component-manager.

# Customization

It is very unlikely that the entando-k8s-service will be customized as part of an Entando implementation.

# keycloak

The entando-keycloak project is an extension of the base Keycloak images. The extension provides the default themes for Entando, a customized realm and clients, and adds the Oracle ojdbc jars for connection to Oracle databases.

# Customization

The keycloak image will often be customized as part of an Entando implementation. Common extensions will include changing the theme, adding default connections, adding default social logins, adding default clients, or other changes.

# Other Key Repositories

# entando-core

The entando-core project is a J2EE application that exposes APIs for the Entando CMS, includes the legacy admin console, and includes the portal-ui project that performs the server side composition for pages rendered via an Entando application. Note that only the composition is performed server side. Javascript code is rendered on the client. The entando-core is realized via an instance that includes the WAR files generated from a core build as dependencies. In a default deployment this is the entando-de-app.

# Customization

For users familiar with versions prior to Entando 6 there will be cases where the entando-core is customized. In most cases these customizations will be delivered via WAR overlay in the instance project. Using WAR overlay is a functional approach for users already familiar with the process but it is highly recommended to extend the platform using microservices for new projects.

# entando-cms

The entando-cms project is the app-builder (React JS) side of the Entando WCMS. It is bundled into the app-builder at build time and will be included in the default deployment of the app-builder in almost all cases.

# Customization

In some cases the entando-cms may be customized if new custom features are added to CMS specific functionality. However, most cases will use the more general app-builder extension points noted above. The entando-cms does not expose any dedicated extension interfaces outside of those already provided by the app-builder.

# entando-components

The entando-components project is a collection of legacy plugins for Entando 5 and earlier. These plugins are deployed as WAR dependencies in an entando-core instance.

# Entando Kubernetes Controllers

There are a number of controllers that are available to the Entando operator to manage installations and components in an Entando Cluster. Those controllers are small and lightweight images that are executed as run to completion pods to manage the installation flow for different parts of the infrastructure. The controllers are implemented using Quarkus. For more information on the controllers, the Entando custom resources, and configuring your Entando deployment see also: Custom Resources.

GitHub:

DockerHub:

# Customization

It is unlikely that the controllers will be customized as part of an Entando implementation.

← Cluster Resource Limits →