Hi everyone,
... hope you all enjoyed the holidays and had a good start into the new
year :-)
I have to appologize for my radio silence concerning the demo server, but I
got a bit steam rolled by work in the last 6 months.
Anyway, I just wanted to get this effort going again and would like to
discuss it with anyone interested.
The current status:
- we have 2 (quite big) servers provided by the Apache Foundation to run
the demo setup
- initially I tried to get it running on one, but was not enough (even
with 32GB of RAM and some swap configuration tricks)
- I've used the demo server module with some minor modifications to turn
off non-essential components (thanks Myrle)
Trying all of this took quite some time... even on the beefy machine from
Apache it took (as far as I remember) 30-40min until the demo server
startup would ultimately fail.
Instead of going down that route again I'd like to propose a different
strategy:
- I am assuming that we **don't** want to go all the way to setup a
Kubernetes (or even a Docker Swarm) cluster; the goal is to just have a set
of docker-compose.yml files to start the system
- it would come in handy to have default Fineract CN Docker images
published on Docker Hub
- I suggest to add a Dockerfile in every microservice Git repository (e.
g. fineract-cn-customer, fineract-cn-teller, fineract-cn-payroll) and let a
CI server build and publish Docker images of these
- to avoid code changes or Docker image rebuilds we should introduce
environment variables in the application.yml files of these microservice
projects; e. g.:
[code]
...
cassandra:
clusterName: staging_cluster
contactPoints: 127.0.0.1:9042,127.0.0.2:9042,127.0.0.3:9042
keyspace: seshat
cl:
read: LOCAL_QUORUM
write: LOCAL_QUORUM
delete: LOCAL_QUORUM
...
[/code]
... should look something like this:
[code]
...
cassandra:
clusterName: ${FINERACT_CUSTOMER_CASSANDRA_CLUSTER_NAME:staging_cluster}
contactPoints: ${FINERACT_CUSTOMER_CASSANDRA_CONTACT_ENDPOINTS:
127.0.0.1:9042,127.0.0.2:9042,127.0.0.3:9042}
keyspace: ${FINERACT_CUSTOMER_CASSANDRA_KEYSPACE:seshat}
cl:
read: LOCAL_QUORUM
write: LOCAL_QUORUM
delete: LOCAL_QUORUM
...
[/config]
- with the above changes we could then define docker-compose.yml files
like this (pseudo file for customer microservice):
[code]
version: '3.6'
services:
customer:
image: nexus.pelotoninnovations.com/rspndr/server-in-memory:latest
depends_on:
- mongo
env_file:
- ./customer.env
ports:
- "10000:10000"
command: sh -c "java -Xmx1024m -Duser.timezone=UTC
-Dlogging.config=./logback.xml -jar -Djava.net.preferIPv4Stack=true
fineract-cn-customer.jar"
[/code]
... and the customer.env file would contain something like this:
[code]
FINERACT_CUSTOMER_CASSANDRA_CLUSTER_NAME=prod_cluster
FINERACT_CUSTOMER_CASSANDRA_CONTACT_ENDPOINTS=server1:9042,server2:9042,server3:9042
FINERACT_CUSTOMER_CASSANDRA_KEYSPACE=seshat
[/code]
- we would provide templates for those env files (e. g.
"customer.env.template"); custom configurations (e. g. "customer.env")
should not be checked into Git
- if no environment variables are provided then the defaults in the
application.yml config files kick in with reasonable values for a local dev
machine deployment (given the required resources unlikely for most devs)
Advantages:
- ready to consume Fineract CN Docker images
- no lengthy builds
- no re-build (Gradle, Docker) for configuration changes
- no requirement to do cluster (Swarm, Kubernetes) setup
- the Docker images could still be used as the basic building blocks of
more complex architectures (Kubernetes)
- every service can be started/stopped separately which makes life a lot
easier when we have to figure out the right configuration for the demo
setup (I guess it would make it also easier for others that would like to
setup their own environments)
I am using most (if not all) of the required bits and pieces for this setup
on a daily basis and I think it should be not too complicated to get this
working. And it would not interfere (too much) with the existing Git
repositories.
Please let me know what you think...
Cheers,
Aleks
