Install FOLIO

Types of installations and deployments

Prerequisites

Eureka management modules

In comparison to the legacy Folio system, Eureka doesn’t have Okapi service. Services like Kong, Keycloak, management components, and a sidecar component are what will substitute Okapi.

In terms of deployment perspective, before deploying any of application, you need to make sure that eureka management components are up and running.

Kong

Github repository

Kong Gateway is a lightweight, fast, and flexible cloud-native API gateway written in Lua. An API gateway is a reverse proxy that lets manage, configure, and route requests to APIs. Kong Gateway runs in front of any RESTful API and can be extended through modules and plugins. It’s designed to run on decentralised architectures, including hybrid cloud and multicloud deployments.

Inside eureka kong Gateway provides basic API gateway functionality.

Kong managed by the utility called deck. Deck helps manage Kong Gateway’s configuration in a declarative fashion. This means that a developer can define the desired state of Kong Gateway or Konnect—services, routes, plugins, and more—and let decK handle implementation without needing to execute each step manually, as you would with the Kong Admin API.

See Kong documentation for more information.

Keycloak

Github repository

Keycloak is a single sign-on solution for web apps and RESTful web services. The goal of Keycloak is to make security simple so that it is easy for application developers to secure the apps and services they have deployed in their organisation.

In the Eureka platform, keycloak provides the following features:

• Single-Sign On and Single-Sign Out for browser applications.

• OpenID Connect support.

• OAuth 2.0 support.

• SAML support.

See Keycloak documentation for more information.

Sidecars

Github repository

In order to support module-to-module communication and the removal of OKAPI, Eureka introduces module sidecars into the platform architecture.  These sidecars run along with each module and have several responsibilities (authorization, tenant-entitlement, proxying requests, transaction logging, etc.)

Sidecars provide the following functionality:

• module independent, uses Okapi Module Descriptors for self-configuration

• Ingress request routing for underlying module (specified using environment variables)

• Egress request routing for module-to-module communication

Management components.

There are 3 management modules that are playing the following roles:

• Application Manager (Github repository)

  • (De-)Registration of applications 

  • Dependency check / platform integrity validation

• Manager tenant entitlements(Github repository)

  • Enabling/disabling of an application for a tenant (including dependencies)

• Manager tenants (Github repository)

  • Tenant management

  • Tenant CRUD

mod-*keycloak: TBD (@Ievgeniia Lymar we may need to cover those modules as well (https://eis.atlassian.net/wiki/spaces/TEUR/pages/201982853/Modules+and+Sidecars ))

information about mod-users-keycloak, mod-roles-keycloak, mod-login-keycloak, and mod-consortia-keycloak. (Eureka?)