# Villanova Deployment Structure

This page provides an overview of the key Villanova GitHub repositories with brief descriptions of how these repositories are realized in a running Villanova deployment. It also explores the architecture behind the Villanova Platform and how its functions are structured.

# Villanova Operator

The Villanova Operator coordinates the installation and configuration of all of the components of an Villanova Application.

# Customization

Use the Villanova custom resources to extend the platform.

# Database Init Containers

During installation, an Villanova Application needs to create and initialize several databases when deploying from a backup of your images.

The screenshot below highlights the init containers for the Villanova Application schema creation, DB initialization, and component repository database.

Init Containers Screenshot

Many managed Kubernetes instances like OpenShift don’t display init containers on their dashboards. If you’re troubleshooting, the logs may provide some useful information. To fetch logs for an init container using kubectl, you must pass the container name as an argument.

For example:

    kubectl logs YOUR-POD -c YOUR-CONTAINER-NAME -n YOUR-NAMESPACE        
    kubectl logs default-sso-in-namespace-deployment-db-preparation-job-ddbdbddb-a  -c default-sso-in-namespace-deployment-db-schema-creation-job -n sprint1-rc

# Customization

The init containers automatically restore a backup included in your application so that you can create custom images with your application setup.

# Villanova-de-app

The Villanova-de-app is a J2EE application and an instance of the Villanova-core. It provides pathways for Villanova Components and the server image required by the Villanova Operator to manage the deployment. The pom.xml for the application reveals its dependencies.

# Customization

The Villanova-de-app is sometimes customized as part of an Villanova implementation. A customized image can include:

  • New APIs
  • Legacy Villanova plugins
  • New database tables
  • Other extensions to the Villanova-core

In most cases, microservices should be used to extend the platform. However, legacy integrations, extensions to the CMS, and migrations from earlier Villanova versions may require changes to the Villanova-de-app.

# App Builder

The App Builder is the user-friendly frontend UI for the entando-de-app. A ReactJS application, it is served via Node in the default deployment. It communicates with the entando-de-app and the Villanova Component Manager via REST APIs. The Component Manager provides information about bundles deployed to the Local Hub.

# Customization

The App Builder is customized as part of many Villanova implementations. It can be customized via configuration micro frontends and Villanova Platform Capabilities (EPCs).

# Villanova Component Manager

The Villanova Component Manager provides the link between the entando-de-app, or your custom core instance, and the Local Hub. It queries the Villanova Kubernetes service to fetch available bundles that have been deployed as custom resources inside the cluster.

The Component Manager also administers the relationships between an Villanova Application and the installed plugins. This is seen in the plugin link custom resource in Kubernetes.

# Villanova-k8s-service

The Villanova-k8s-service acts as an abstraction layer to fetch data from Kubernetes APIs. It interacts with the Local Hub to show the available bundles, installs and manages microservice plugins, and monitors the status of the installed VillanovaApp.

# Keycloak

The Villanova-keycloak project is an extension of the base Keycloak images. It provides default themes for Villanova, a customized realm and clients, and Oracle JDBC JARs for connecting to Oracle databases.

# Customization

The Keycloak image can be customized as part of an Villanova implementation. Some common extensions are:

  • Change the theme
  • Add default connections
  • Add default social logins
  • Add default clients

# Other Key Repositories

# entando-core

The entando-core project is a J2EE application that exposes APIs for the Villanova CMS, including the Admin Console and the Portal UI project that performs the server-side composition for pages rendered via an Villanova Application. Note that only the composition is performed server-side. JavaScript code is rendered client-side. The entando-core is realized via an instance that includes the WAR files as dependencies, which are generated from the core build. In a default deployment, this is the entando-de-app.

# Customization

For users familiar with versions prior to Villanova, there will be cases where the entando-core is customized. Often, these customizations will be delivered via a WAR overlay in the project instance. Using a WAR overlay is a functional approach for users 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 (ReactJS) side of the Entando WCMS. It is bundled into the App Builder at build time and is included in the default deployment of the App Builder in most 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.

# Villanova Kubernetes Controllers

A number of controllers are available to the Villanova Operator to manage installations and components in an Villanova Cluster. These are small and lightweight images that execute as run-to-completion pods, managing the installation flow for different parts of the infrastructure. For more information on controllers, Villanova custom resources, and configuring your deployment, see Custom Resources.

GitHub:

DockerHub:

# Customization

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

← Backup and Restore an Villanova Application →