Hi Aleksandar, I can work with you on migrating the Fineract services from Docker compose to Docker Swarm. Then pushing the Fineract images to Docker Hub so it's easily accessible.
I think that will require Ed to create a Docker Hub account for Mifos/Fineract. Thanks, Courage. On Sat, Jan 19, 2019 at 1:49 PM Aleksandar Vidakovic < [email protected]> wrote: > Hi Juan, > > ... thanks for chiming in... and thanks for the pointer to the Git > repository with the Dockerfiles; that makes life already a lot easier. > > You are right, once you have the docker-compose.yml files lined up it's not > a big stretch to setup a Swarm cluster. After running such a cluster for a > client of mine I just want to add: > > - a Swarm cluster with less than 3 nodes will not run very stable; I'm > saying this, because at the moment we have 2 servers at our disposal (I > think) > - colleagues told me that Swarm cluster worked less reliable for them than > other solutions; I don't think for a demo system that is too much of a > concern, but again I had one running in a production environment and had no > major problems > > If you want then let's connect ([email protected]) and figure out how we > can > proceed with this... before the next GSoC season begins ;-) > > Cheers > > > On Sat, Jan 19, 2019 at 4:03 PM Juhan Aasaru <[email protected]> wrote: > > > 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 (<[email protected]>) 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 > > > > > >
