2  Project Portal

2.1 Overview

The Project Portal Service will provide a solution designed to support the needs of projects by providing a project website upon request. The portal, structured on a predefined base template, will offer the flexibility to further customize the overall user experience. Beyond the initial theming options, the service incorporates a Drupal Content Management System (CMS), empowering project members to perform advanced customizations and efficiently manage portal content.

The instantiated project portal will have the option to work in synergy with other services offered within APEx. This collaborative approach enables projects to extend their portal by instantiating other APEx services such as a STAC catalogue, a dashboard, a user forum, and more, and linking them to the main project portal, resulting in a dedicated, streamlined project ecosystem.

2.2 Showcase Scenarios

The project portal can bring a lot of value to projects, including:

  • Efficient project dissemination and community engagement: Facilitates the rapid and broad dissemination of project information, ensuring that updates, results, and important announcements reach the intended audience quickly and effectively.
  • Professional branding with customization possibilities: The portal comes with polished, consistent branding out of the box, enhancing the project’s credibility and professionalism and fostering trust among stakeholders and the public. Additionally, project teams can tailor the portal’s appearance to align with specific branding guidelines or aesthetic preferences, creating a unique and engaging user experience that reflects the project’s identity.
  • Content management and moderation: The portal’s robust content management capabilities enable teams to streamline the creation, moderation, and updating of content. Advanced features like content moderation workflows and version control ensure that all shared information is accurate, current, and meets our high-quality standards. The system supports various roles and permissions, including administrators and content creators, fostering a self-regulated environment. This empowerment allows project teams to manage their content and user access autonomously, thereby enhancing operational efficiency.

2.3 User Stories

2.3.1 As an ESA Project Owner

  • I want to request the deployment of a new Drupal website for a specific project so that the project can have a dedicated web portal.
  • I want to configure initial settings for my Drupal website (e.g., site name, admin user, theme) so that it meets my project’s needs.
  • I want to manage the content and menu structures of the Drupal website.
  • I want to access analytics for my Drupal website so that I can track user engagement and website performance.
  • I want to view statistics on the uptime and the resource usage (CPU, memory, storage) of my project portal.
  • I want to be able to request the APEx team to restore backups.
  • I want to be notified if thresholds on the resources have been reached.

2.3.2 As an APEx Operators

  • I want to automate the deployment process of Drupal websites so that new instances can be created efficiently and with minimal manual intervention.
  • I want to implement security measures and compliance checks for Drupal websites so that they are secure and meet organizational standards, in a cost-effective manner.
  • I want to view and manage all project websites so that I can oversee their status and perform maintenance tasks.
  • I want to view statistics on the uptime and the resource usage (CPU, memory, storage) of all instantiated project portals.
  • I want to impose/define limits on usage, to make sure that costs stay within the foreseen bounds, and to be notified when a project requires an upgrade to a larger package.

2.4 Business Model

The project portal will initially adopt a straightforward model, offering the following tiers:

  • Tier 1 (normal website)
    • Simple setup (1 nginx Pod, 1 Drupal Pod, 1 database on managed MariaDB service).
    • Pod resources:
      • CPU: 1
      • RAM: 1GB
  • Tier 2 (critical website):
    • Same as Tier 1 but all Pods are replicated on different nodes.
  • Tier 3 (high volume website):
    • Same as Tier 2 but the Drupal caches are stored in a managed Redis server. Every project portal has its own Redis database.

The project portal service aims to provide robust support through available online channels:

  • APEx online documentation and user forum for common documentation.
  • Drupal online documentation fora for Drupal-specific documentation.

Additionally, the project portal aims to offer access to custom development packages, which are useful when projects require specialized features or integrations. These can be provided either at a flat rate or through support packages with a fixed number of hours.

2.5 Technical Architecture

Project Portal - Infrastructure Diagram

This infrastructure is designed to host Drupal websites for multiple projects, each within its own Kubernetes namespace. The setup ensures isolation, scalability, and efficient management of resources. The main components include an ingress controller, various services and pods within project namespaces, a MariaDB managed service, an OpenID Connect Identity Provider, and NFS storage.

The overall architecture is defined by the following components:

  • Ingress: This component is responsible for routing external traffic to the appropriate project namespace based on the URL. It uses rules to direct traffic to project-x.esa.int.
  • Namespace: Each project (e.g., project-a.esa.int and project-b.esa.int) has its own namespace for resource isolation. Each instantiated namespace will spawn the following components:
    • nginx: This service balances the load across multiple nginx pods within the namespace. Each nginx pod which handles HTTP requests and forwards them to the appropriate Drupal service using FastCGI (FPM).
    • Drupal: This service balances the load across multiple Drupal pods within the namespace. Each pod contains the Drupal application running with PHP-FPM (FastCGI Process Manager), which processes PHP scripts.
  • MariaDB Managed Service: This is a centralized managed database service. Each project namespace has its own database instance within this service.
  • OpenID Connect Identity Provider: This component handles user authentication via the OpenID Connect protocol, ensuring secure access to the Drupal websites. It communicates with the Drupal pods over HTTPS.
  • NFS: Provides persistent storage for the Drupal applications and nginx pods, allowing them to store and share files. This is essential for storing user-uploaded content, configuration files, and other persistent data.

2.6 Operational Management

The project portal operates within a Kubernetes environment shared across all APEx Instantiation Services. Based on prior experiences, each project portal will receive sufficient resources for hosting a basic website. The initial setup anticipates minimal scaling needs, as the basic configuration will meet the requirements of most projects.

However, throughout the project lifecycle, the team will explore optional enhancements to operational management, including:

  • Implementing redundant Drupal nodes to ensure high availability.
  • Enhancing performance by integrating Redis components for Drupal caching.

Continuous monitoring of the Kubernetes cluster ensures optimal performance and availability of the instantiated project portals. Automated maintenance tasks, such as updates and backups, are conducted to minimize downtime and uphold data integrity. This approach establishes a robust and dependable environment for users.

2.7 Request Procedure

The project portal should be requested through the following procedure:

  1. The APEx team is contacted by a project owner to instantiate a new project portal.
  2. After approval by ESA, an APEx operator spins up a new instance for the project portal.
  3. The APEx operator applies the basic configuration of the project portal, such as the title and initial admin account.
  4. The APEx operator configures the public URL of the project portal. This can either be a domain bought and managed by the project or a subdomain of a fixed URL (e.g., project-x.esa.com).
  5. The APEx operator sends an email to the project owner with the access information for the project portal.

This procedure can be further automated by integrating step 3 into a service marketplace, if available. This would allow a project owner to instantiate a project portal after it has been enabled by an APEx operator.