| What do we want to achieve this year ? |
| - This may influence the question of how often we will meet "synchronously" (weekly - bi-weekly - on-demand)
Ingolf: We should definitely talk about our sessions at WolfCon in Hamburg in August/September. Should involve the GBV/VZG for this. FOLIO at WOLFcon - Community Council - FOLIO Wiki Who plans to attend ? Tentative: Ingolf, Tod, Phil, Jason, Ian Notes: What do we want to achieve this year: - Simplicity in Deployment
- How to get address SysOps concerns addressed that have been sitting for last 4 years
- make it easier to spin up "minimal" FOLIO
- make it easier to build apps for FOLIO, easier to select what to deploy
- Security needs to align - look at as a whole, not an afterthought
- TAMU workflow engine. PoC Spring FOLIO Modules. Adjacent to FOLIO instances. Make them inherent to the platform.
at WOLFcon: - need more concrete structure,
|
| Approaching a platform-minimum set of modules. Deployment with Kubernetes, starting with the Helm charts | Ian & Jeremy | Notes from Jan 21: Walls: Two levels of modularity, modules and apps. Apps are user-facing, and need to be independantindependent. Tharp: Want a minimal system that allows people to spin up an instance of FOLIO, needs to be more modular and easy to do so that we can get more people involved in FOLIO. Would be good to try to work on this in a tangible way and then take to.. TC?.. when this is impossible. Has been always a problem in the past to get anyone to do anything about this. We need to be able to start talking before concepts are completely defined, or we never start. Olson: would Would acknowledge that there are pulls in different directions, want modularity but also want deep interconnections. Contradictory pulling that we are dealing with: Integration & deep intertwining vs. wish of the independent modules. Tharp: Need to get buy-in that these concepts of modularity, etc. are valuable to pursue. Usually would start with a working app and break into microservices, but we started by breaking it up first. SysOps does not write code, but still need to get concerns addressed. Brandon: The Vagrant Box stuff is completely unmaintainable.
Jason: Let's start with Helm charts.
Brandon: Docker-compose first.
Ian: I will put efforts in Helm charts.
Skipping Docker and Kubernetes.
It needs to be able to run in the cloud and on premise. Notes from last week's meeting (Jan 14): Ingolf (question): Stanislaw did a great demo of Terraform deplyoment to us, but Stanislaw left the project. Is the Terrafrom deployment being maintained still for the current releases (Juniper, Kiwi) ? This will be of great interest for the platform-minimum approach, too.
Anton: Terraform is being used in development environments.
Each development team has its own test system.
- open AWS account
- take scripts , deploys
Terraform allows you to deploy anywhere (not only AWS)
TAMU does it with VMWare
Terraform is for heavy lifting to get Rancher set up. Make things to do in Rancher easier.
Brandon: we would like to start with the Helm charts. Terraform is a little platform specific.
Jermey: On Stanford we are using Terraform with AWS, but no Rancher.
Brandon: Terraform is very specific in how you configure: VMWare, AWS
In dev environment: Sets up Resources in AWS. Sets up Rancher.
Devs only have to mess with Helm charts.
Ian: We could have a Helm chart.
Anton: Deploy all the prerequisites like Kafka etc. Devs are not supposed to be writing code. Rancher has "projects". Each project is a separate environment, but it shares hardware and AWS resources.
Instead of deploying snapshot , they deploy branch.
Anton: There is a repo for Helm charts. It should have a documentation.
I wish it would be more widely adopted. You can use VMWare or bare metal servers.
As a SysOps SIG we should come to a unified support. EBSCO has a different approach.
Ian : Get a Kubernetes cluster. Is this an exercise left to the reader ?
Anton: You can deploy everything in container, or you can use AWS services. Kafka, ES, ... they can all be container based.
Brandon: You are either talking Docker or Kubernetes. I was looking at Rancher Desktop. You can run moby (the docker demon), or the Kubernetes cluster.
The management tool is better for Kubernetes. First decision: Docker or Kubernetes.
Elasticsearch, Kafka, Postgres. At A&M we run Helm charts. Helm charts don't care where they run.
Then you can install FOLIO. It might be RDS, it might be a Kafka instance
Anton: This will replace the Single Server install.
Ian: We could use Docker Compose, but we will do Kubernetes. We should have a documentation in the Documentation Working Group.
Ingolf: Look at the Demo of Stanislaw and post it. Ingolf: We should - as SysOps SIG - write a documentation for deployment with Kubernetes, starting with the Helm charts. This documentation should be placed here: docs/content/en/docs/Getting started/Installation at iris · folio-org/docs (github.com)
Jeremy: My role is the second person in that role.
Anton: I will talk to dev ops; most of them are EPAM dev ops. There are three of them. Ingolf: How to build your own Docker images for modules ?
Brandon: https://dev.folio.org/faqs/how-to-get-started-with-rancher/
https://github.com/folio-org/folio-install/tree/tamu-r2-2021/alternative-install/kubernetes-rancher/TAMU
https://github.com/folio-org/folio-install/blob/tamu-r2-2021/alternative-install/kubernetes-rancher/TAMU/folio_setup.md
DevOps also use ANSIBLE.
Ian: How can a person off the street get a least users and inventory up. With Helm charts. There will have to be code changes to break up the interconnections.
Anton: It is coming from different directions: There is a subgroup of PC. There should be a more felxible way for FOLIO deployment which does not rely on "3 times a year".
It needs architectural changes.
Anton: Moved to Webpack 5. This allows each UI module could be deployed separately. You don't need to rebuild the whole thing. |