Skip to end of banner
Go to start of banner

2024-09-26 WolfCon 2024 Sys Ops & Management SIG Session

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Current »


Translator



Translator


Place, date and time

London, 16-17 BST

https://openlibraryfoundation.zoom.us/j/88324827133?pwd=Zox250QB8qbYSkRZcBVpmfLAK4bVzb.1

Topics

Self Hosting in a New Architectural Platform

Addressing deployment concerns when moving from the Okapi to the Eureka platform architecture. Discussion of experiences, observations and challenges.

Attendees

Remote attendees:

TimeItemWhoNotes




--



Meeting NotesIngolf

Michelle: FES work focused on operational concerns.Tested critical deployment tasks like tenant provisioning, major release upgrades.

    Tested migration and deployment of Eureka clusters.

    Tested configuration options of Keycloak. Roles are to give the user a system role. FOLIO modules remain at the core of the platform.
Eldliiar: Eureka Development in Rancher
    Historically, Okapi was single point of failure. On Eureka, things will change.
    Keycloak and Kong can serve multiple clusters, as opposed to Okapi.
Florian: Which parts of the UI are visible ? How does that intersect with Stripes ?
Eldiiar: There are small adjustments on top of Stripes file.
    Once we have built UI, we do not need to rebuild it anymore. All (configurations) are permanent. And configurable via the Keycloak API.
    There is a graphical user interface.
Florian K.: We have a Reshare model. How much work will it be to adjust to the new platform ?
Eldiiar: It is just one commit and several lines. You will gain another opportunity. Everything will work like a charme.
Craig: Nothing to add.
Eldiiar: If Okapi is down, the system is not accessible. In Eureka, if Kong is down, backend modules are still able to communicate via Sidecars.
Florian K. : But you have the problem when Keycloak goes down.
Eldiiar: So far we have never had problems with Keycloak and Kong.
    Clusterisation of Okapi was hard to achvieve. You had to deal with Hazelcast. With Kong and sidecars it is already clustered.
    Everything works like a charm.
   - modern and fast app gateway (Kong)
   - Envionment provisioning duration decreases from ~45 to ~30 minutes.
   - sidecars supports default log level
Mark: "It (Kong) takes two cups of coffee per hour instead of one" (laughter)
Jason: How many URLs do you provide ?
Eldiiar: We just provide a single Kong URL for the whole process.
    Kong is just an application gateway. Everything happens under the hood (of Sidecars).
Jason: In Hazelcast, ...
Craig: The modules are unaware of ...; Everything is handled by the sidecars.
Mark: Kafka used Hazelcast; we have replaced Zookeeper by Graft.
Denis Mönch: ... (question about logging)
Answer: Sidecar logging is disctinct from ...
Uwe Reh: Are sidecars and modules combined in a pod ?
Edliiar: Yes. So, it doesn't double the number of pods.
    The demo links (on the last slide) run on the same Kubernetes cluster on the same namespace.
    They are being destroyed on daily basis.
Tobias: Direct module to module communication. Was that written inhouse ? I do not understand the purpose of Quarkus.
Craig: Module to module communication has been provided by the platform. It is part of the business logic.
Tobias: What makes available the specific module code ? Is that Quarkus or what is the purpose of Quarkus ?
Craig: The module needs to call another module. It takes its requests to the sidecar. The sidecar routes the request.
Eldiiar: The sidecar pulls down all communication out of discovery and keeps it in memory. So, even if Kong is not available, the information is there. The sidecar      does the routing and communication.
Owen: What about timeouts ? This is handled at the Okapi level at the moment.
Craig: Sidecars are built on Quarkus, a java framework.
Eldiiar: With the sidecars, we can configure our environment more granuarly.
    Next link is to our public available Helm charts. folio-org/folio-helm-v2
    Pipeline example: https://shorturl.at/aNXyq
Uwe/ Josh: single server installations ...
Mark: Thank you Hong Wei et. al.

End of presentation 16:42 o'clock


Questions, Discussion


Jason: I am still digesting.

Ingolf: Is there a value in going through the eureka-platform-bootstrap example if one plans to use Kubernetes for deployment ? Likewise for Okapi deployment, years ago, we first went through the single server example at then, with that experience, started deploying on Kubernetes. Do you recommend going through this example ? It is based on docker-compose.

Craig : https://github.com/folio-org/eureka-platform-bootstrap
Craig: The platform-bootstrap example was conceived in order to save AWS costs for the development environments. Going through the eureka-platform example (as a system administrator) is not a requirement.
Ian Walls: is there a level minimum ...

Uwe: Is there any documentation about common pitfalls ?
Josh: Keycloak in a single namespace ? A seperate Keylcoak in another namespace ?

Eldiinar: You can utilise your existing Keycloak.

Tobias: A private Repository for AWS. Where to find docuemntation about building the manager applications, for example. Will you provide it on folio-org ?
Answer: This is the first time that I heard about problems with building.
Eldiiar: Yes, we will have the images on Dockerhub. They will be prebuilt.




Chat Log

Tobias Stumpp (ZDV with BSZ) 17:01
We can, yes!

Craig an Alle 17:43
https://github.com/folio-org/eureka-platform-bootstrap

Eldiiar Duishenaliev an Alle 17:44
Local dev env: folio-org/eureka-setup: Repository to manage deployment code to run Eureka platform (github.com)

Tobias Stumpp (ZDV with BSZ) 17:45 (Bearbeitet)
Links repeated for Chat from the presentations' last slide:

- https://folio-etesting-snapshot-diku.ci.folio.org (diku_admin\admin) - automatically re-created on daily basis | NonECS
- https://folio-etesting-snapshot-consortium.ci.folio.org (consortium_admin\admin) - automatically re-created on daily basis | ECS
- Helm Chart for FOLIO platform: https://github.com/folio-org/folio-helm-v2 | EUREKA support is configurable
- https://github.com/folio-org/folio-helm-v2?tab=readme-ov-file#eureka-deployment-parameters
- Pipeline example: https://shorturl.at/aNXyq







Action items

  • Type your task here, using "@" to assign to a user and "//" to select a due date
  • No labels