Types of installations and deployments
Single-server deployment (Eureka)
Kubernetes deployment (Kitfox)
Kong fine-tuning
You can customize Kong's default behavior using environment variables. When the application starts, it uses environment variables to configure the personal Nginx web server and Kong itself. To set Nginx parameters, use environment variables with the prefix KONG_NGINX_. For Kong-specific configurations, define variables with the prefix KONG_.
Additional resources:
Kong configuration files
How to work with Kong environment variables
Configuration variable list
Prerequisites
Memory (PTF)
Infrastructure
PostgreSQL (keep as is)
OpenSearch or Elasticsearch (keep as is)
Kafka (keep as is)
Optional: MinIO or Amazon S3 (keep as is)
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
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
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
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?)