Hi Aleks Thanks for your work on pushing the demo server to live. I have played around with the containers also and I add my feedback and ideas.
> - it would come in handy to have default Fineract CN Docker images published on Docker Hub I think this is a way to go. If we want to promote adoption of Fineract-CN then public images lower the burden to anyone to download and get going with the project. Does the CI server already exist that could potentially build the images? > - 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 Yes. Most of the Dockerfiles already exist here https://github.com/openMF/fineract-cn-containers But they logically belong to the application's own code base so I see no harm in adding all Dockerfiles to the app's own repository. - 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 If we plan to operate with docker-compose already (and run in two servers) then I, in my opinion, it wouldn't be much overhead to create a Swarm cluster. If I look at the instructions (https://docs.docker.com/get-started/part4/) it doesn't seem like a lot of work. Also if something happens then Swarm can detect and relaunch containers. But I'm no system administrator myself so I might be mistaken in terms of how much work it requires. > - to avoid code changes or Docker image rebuilds we should introduce > environment variables in the application.yml files of these microservice > projects; e. g.: > cassandra: > clusterName: staging_cluster /---/ > ... should look something like this: > cassandra: > clusterName: ${FINERACT_CUSTOMER_CASSANDRA_CLUSTER_NAME:staging_cluster} /---/ I think there is no need to change application.yml files. In docker-compose.yml you can overwrite any application.yml property in "environment" section like this: environment: - "cassandra.clusterName=${FINERACT_CUSTOMER_CASSANDRA_CLUSTER_NAME:staging_cluster}" Juhan Kontakt Aleksandar Vidakovic (<chee...@monkeysintown.com>) kirjutas kuupäeval N, 17. jaanuar 2019 kell 03:46: > 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 >
