Okapi integration with etcd in Kubernetes, a use-case:
Currently, making Okapi aware of what modules a Folio system is running is a very manual process:
When a module comes up, it does not make itself aware to Okapi
Need to issue curl POST commands to tell Okapi where and how your module is running
No way to initialize a module for a Tenant other than issuing curl POST, again a very manual process
When using an orchestration tool, most provide some sort of discovery mechanism. Kubernetes and Rancher RKE use etcd.
Documentation for Kubernetes API is here:
And etcd here:
In addition to using etcd for each module’s deployment-descriptor for Okapi to use, etcd’s key-value store could also be utilized for critical module metadata and module-descriptors.
Another reason is to store deployment and module descriptors in etcd is backup and disaster recovery. We should be able to rebuild a complete Folio cluster by restoring a backup of the etcd database.
Summary of our current process for standing up a vetted Folio quarterly release, where dependencies have been resolved for me:
Checkout or assemble Stripes platform and build
Build and run Okapi
Run back-end modules as Docker containers
POST running back-end module deployment-descriptors to Okapi
POST running back-end module module-descriptors to Okapi
POST back-end modules to enable for Tenant to Okapi
POST front-end module module-descriptors to Okapi
POST front-end modules to enable for Tenant to Okapi
Create superuser for Tenant
Load reference data and sample data
We handle these POSTs via a deployment script and files ran inside of a Job. However, this needs to be maintained and updated over time as Folio grows.
Integrating Okapi with etcd Discovery Service could eliminate the manual steps 4,5, and 9.
JIRA tickets related to these needs: