Re: Setup on Containers

[Juhan Aasaru]

Hi,

I found the code Courage was referring to from here:
https://github.com/Anh3h/fineract-cn-provisioner/commit/2ff842b551a6459e14c8aa1d0aa2a6e85bc622bc
based on this code I just added the needed log statements
to ProvisionerServiceConfig (it already had log statement for timestamp).
Then I built the new provisioner jar, ran demo-server, copied the
public/private key info from logs, added it to start-up.sh like this:

docker run --name provisioner-ms --env
eureka.instance.hostname=172.16.238.2 --env ribbon.listOfServers=
172.16.238.2:9090 \
  --env eureka.client.serviceUrl.defaultZone=http://172.16.238.2:8761/eureka
--env activemq.brokerUrl=tcp://172.16.238.3:61616 \
  --env cassandra.contactPoints=172.16.238.5:9042 --env
mariadb.host=172.16.238.4 --network externaltools_app_net \
  --env system.publicKey.timestamp=2019-01-07T08_10_29 \
  --env system.publicKey.exponent=65537 \
  --env system.publicKey.modulus=17...91 \
  --env system.privateKey.modulus=17..91 \
  --env system.privateKey.exponent=14..73 \
  --ip 172.16.238.6 provisioner:latest

the good thing is that it all worked but it would be however helpful to
understand what is exactly happening behind the scenes.
Also, I haven't yet figured out if these keys were hardcoded into the demo
app (wouldn't be secure to use) or were they generated.

Juhan


Kontakt Courage Angeh () kirjutas kuupäeval L, 5.
jaanuar 2019 kell 17:43:

> Hi Juhan,
>
> I updated provisioner microservice to expose the security keys to its log
> file. And the startup script shares those details amongst the other running
> microservices. I havent tested the script in MacOS but it should not be too
> different.
>
> Thanks,
> Courage.
>
> On Sat, Jan 5, 2019, 9:55 AM Juhan Aasaru 
> > Hi again!
> >
> > Now I got to the same point where Patrick got in his initial email but I
> > didn't find an actual answer from this thread.
> > When running provisioner the system says the following properties may not
> > be null:
> > system.privateKey.exponent
> > system.publicKey.exponent
> > system.publicKey.modulus
> > system.publicKey.timestamp
> > system.privateKey.modulus
> >
> > I found out from Patrick's email that I probably need to generate a RSA
> key
> > pair and extract these values from there and pass them to provisioner
> like
> > other properties. Patrick, if I may ask, what kind of external tool did
> you
> > use for this?
> >
> > Eventually I think readme of provisioner should be updated with the info
> > about the need of suplying these parameters
> > so I started the process of getting this info together using command
> line.
> >
> > I did some research and managed to
> > 1) generate rsa key pair (I chose the length to be 4096)
> > 2) convert public key to pem format
> > 3) and print out decimal exponent value and modulus value (as hex string)
> > 4) convert modulus hex value into decimal value
> >
> > I also learned that modulus of private and public key should be the same.
> > What I didn't manage to do:
> >
> > 5) find out where to take the timestamps from
> > 6) get the exponent of the private key (didn't find any working
> > instructions)
> >
> > Here are the statements that I ran for steps that worked:
> >
> > 1) ssh-keygen -t rsa -b 4096 (answered "key" to filename prompt, left
> > password blank)
> > 2) ssh-keygen -f key.pub -e -m pkcs8 > pem.pub
> > 3) openssl rsa -pubin -text -noout -in pem.pub
> > 4) I took the Modulus, removed all colons, spaces and newlines, got
> > something like 00c9...d0d7
> > then turned it into uppercase: 00C9...D0D7
> > and then converted it into decimal:
> > echo 'ibase=16; 00C9...D0D7' | BC > modulus.txt
> >
> > Thanks
> > Juhan
> >
> >
> > Kontakt Juhan Aasaru () kirjutas kuupäeval L, 5.
> jaanuar
> > 2019 kell 09:39:
> >
> > > Hi Courage,
> > >
> > > I found that the problem with the network name is backwards
> > > incompatibility with docker-compose for directories
> > > having a dash ("-") inside the directory name.
> > >
> > > New docker-compose versions keep the dash while old ones remove it when
> > > creating a network name.
> > > One fix would be to remove the dash from the folder name and replace it
> > > with underscore.
> > > So external-tools would be renamed to external_tools.
> > >
> > > More info about the incompatibility:
> > > https://github.com/hyperledger/caliper/issues/198
> > >
> > > Your workaround of creating the network manually seems to work on my
> > > machine.
> > >
> > > Juhan
> > >
> > >
> > > Kontakt Courage Angeh () kirjutas kuupäeval L,
> > 5.
> > > jaanuar 2019 kell 03:50:
> > >
> > >> Hi Juhan and Patrick,
> > >>
> > >> Juhan,
> > >> Thanks for the feedback on the start-up script. I tried your changes
> and
> > >> the new network name fails on my system. So I added a command to
> create
> > >> the
> > >> network on the start-up script and used the network in the compose
> > files.
> > >> Please try it to verify that it works for you and let me know. If it
> > >> doesn't work please can you create a 

Re: Setup on Containers

[Courage Angeh]

Hi Juhan and Patrick,

Juhan,
Thanks for the feedback on the start-up script. I tried your changes and
the new network name fails on my system. So I added a command to create the
network on the start-up script and used the network in the compose files.
Please try it to verify that it works for you and let me know. If it
doesn't work please can you create a start-up script compatible with Mac-OS
and share with the community (via a PR)?
To that please add the improvements you did on the migration script.

If we let Docker assign IP addresses to the Fineract services then we will
have to use Docker to get the IP used by the provisioner script, which is
additional processing time. But you can do the change if you feel
comfortable with that.

Actually, the provision script makes API calls. But to talk to an API we
need the IP address or domain name.

Patrick, I tried using the docker service names in my provisioner shell
script and my shell didn't recognize the service names.

Thanks,
Courage.

On Fri, Jan 4, 2019 at 2:08 PM Patrick Finken 
wrote:

> Be careful, spinning all the containers at the same time required some
> resources.
> First of all check the CPU and the memory you allocated to docker. I think
> by default it is 2GB of ram. it's not enough for all the containers. You
> might want to increase it.
> I suggest you start with just identity and provisioner services to test the
> process.
>
> Patrick
>
> On Fri, Jan 4, 2019 at 1:39 PM Juhan Aasaru  wrote:
>
> > Hi Patrick,
> >
> > thanks for the step-by-step instructions. Here are the results:
> >
> > When I ran "docker-compose up" inside "external-tools" and then "docker
> > network ls" in another terminal I got:
> >
> > 5271e3e6a6ebexternal-tools_app_net   bridge
> >   local
> > 29fa4ca2bf83external-tools_default   bridge
> >   local
> >
> > So the dash ("-") inside the folder name propagates into the network name
> > as well (at least in my mac).
> > To comply with this I changed "externaltools_app_net" to
> > "external-tools_app_net" in start-up.sh and
> > last row of docker-compose.yml in main directory (other option would have
> > been renaming directory "external-tools" to "externaltools").
> >
> > When I ran "docker-compose up" in the main directory I first got an error
> > with a missing jar in ledger-ms, but I discovered that migration-script
> was
> > missing "accounting", I fixed that and created a pull request together
> with
> > adding dash to network name.
> > Courage, would you mind taking a look at the pull request:
> >
> >
> https://github.com/openMF/fineract-cn-containers/pull/7/commits/465dfd21aa516cf2c7a363b7bc30d4346c2316c2
> >
> > After that the "docker-compose up" in the main directory ran until the
> > output was:
> >
> > Attaching to identity-ms, deposit-ms, portfolio-ms, report-ms, ledger-ms,
> > customer-ms, office-ms, rhythm-ms, teller-ms
> >
> > And then it halted.
> >
> > When I run "docker-compose down" and then "docker-compose --verbose up"
> > then I got a bit more info:
> >
> > Attaching to identity-ms, deposit-ms, portfolio-ms, report-ms, ledger-ms,
> > customer-ms, office-ms, rhythm-ms, teller-ms
> > compose.cli.verbose_proxy.proxy_callable: docker events <-
> > (filters={'label': ['com.docker.compose.project=fineract-cn-containers',
> > 'com.docker.compose.oneoff=False']}, decode=True)
> > urllib3.connectionpool._make_request: http://localhost:None "GET
> >
> >
> /v1.25/events?filters=%7B%22label%22%3A+%5B%22com.docker.compose.project%3Dfineract-cn-containers%22%2C+%22com.docker.compose.oneoff%3DFalse%22%5D%7D
> > HTTP/1.1" 200 None
> > compose.cli.verbose_proxy.proxy_callable: docker events ->
> > 
> >
> > I don't quite understand what it means.
> >
> > It seems like it completely freezes Docker as in another terminal even
> > running "docker ps" doesn't repsond anything.
> > Just in case I will now reinstall Docker in my local computer and try
> > again.
> >
> > Juhan
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Kontakt Patrick Finken () kirjutas kuupäeval
> R,
> > 4. jaanuar 2019 kell 18:06:
> >
> > > Hey Juan,
> > >
> > > You should first run the external service before running the main
> > services.
> > >
> > > Basically, run the command "docker-compose up" inside the
> external_tools
> > > folder, or specify the docker-compose file: "docker-compose up -f
> > > ./external-toools/docker-compose.yml".
> > > It will spin up cassandra, activemq and maria db. And it will also
> create
> > > the network *"externaltools_app_net". *You can make sure it is the
> > correct
> > > name by running the command "docker network ls". If it's not, for
> > example,
> > > if the folder has a different name,  you should update the main
> > > docker-compose.yml file with the correct network name.
> > >
> > > Then inside the main folder, in a different terminal, run the command
> > > "docker-compose up" to start the main services.
> > >
> > > In the start-up script, since 

Re: Setup on Containers

[Patrick Finken]

Be careful, spinning all the containers at the same time required some
resources.
First of all check the CPU and the memory you allocated to docker. I think
by default it is 2GB of ram. it's not enough for all the containers. You
might want to increase it.
I suggest you start with just identity and provisioner services to test the
process.

Patrick

On Fri, Jan 4, 2019 at 1:39 PM Juhan Aasaru  wrote:

> Hi Patrick,
>
> thanks for the step-by-step instructions. Here are the results:
>
> When I ran "docker-compose up" inside "external-tools" and then "docker
> network ls" in another terminal I got:
>
> 5271e3e6a6ebexternal-tools_app_net   bridge
>   local
> 29fa4ca2bf83external-tools_default   bridge
>   local
>
> So the dash ("-") inside the folder name propagates into the network name
> as well (at least in my mac).
> To comply with this I changed "externaltools_app_net" to
> "external-tools_app_net" in start-up.sh and
> last row of docker-compose.yml in main directory (other option would have
> been renaming directory "external-tools" to "externaltools").
>
> When I ran "docker-compose up" in the main directory I first got an error
> with a missing jar in ledger-ms, but I discovered that migration-script was
> missing "accounting", I fixed that and created a pull request together with
> adding dash to network name.
> Courage, would you mind taking a look at the pull request:
>
> https://github.com/openMF/fineract-cn-containers/pull/7/commits/465dfd21aa516cf2c7a363b7bc30d4346c2316c2
>
> After that the "docker-compose up" in the main directory ran until the
> output was:
>
> Attaching to identity-ms, deposit-ms, portfolio-ms, report-ms, ledger-ms,
> customer-ms, office-ms, rhythm-ms, teller-ms
>
> And then it halted.
>
> When I run "docker-compose down" and then "docker-compose --verbose up"
> then I got a bit more info:
>
> Attaching to identity-ms, deposit-ms, portfolio-ms, report-ms, ledger-ms,
> customer-ms, office-ms, rhythm-ms, teller-ms
> compose.cli.verbose_proxy.proxy_callable: docker events <-
> (filters={'label': ['com.docker.compose.project=fineract-cn-containers',
> 'com.docker.compose.oneoff=False']}, decode=True)
> urllib3.connectionpool._make_request: http://localhost:None "GET
>
> /v1.25/events?filters=%7B%22label%22%3A+%5B%22com.docker.compose.project%3Dfineract-cn-containers%22%2C+%22com.docker.compose.oneoff%3DFalse%22%5D%7D
> HTTP/1.1" 200 None
> compose.cli.verbose_proxy.proxy_callable: docker events ->
> 
>
> I don't quite understand what it means.
>
> It seems like it completely freezes Docker as in another terminal even
> running "docker ps" doesn't repsond anything.
> Just in case I will now reinstall Docker in my local computer and try
> again.
>
> Juhan
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Kontakt Patrick Finken () kirjutas kuupäeval R,
> 4. jaanuar 2019 kell 18:06:
>
> > Hey Juan,
> >
> > You should first run the external service before running the main
> services.
> >
> > Basically, run the command "docker-compose up" inside the external_tools
> > folder, or specify the docker-compose file: "docker-compose up -f
> > ./external-toools/docker-compose.yml".
> > It will spin up cassandra, activemq and maria db. And it will also create
> > the network *"externaltools_app_net". *You can make sure it is the
> correct
> > name by running the command "docker network ls". If it's not, for
> example,
> > if the folder has a different name,  you should update the main
> > docker-compose.yml file with the correct network name.
> >
> > Then inside the main folder, in a different terminal, run the command
> > "docker-compose up" to start the main services.
> >
> > In the start-up script, since the IPs are not hardcoded anymore, you
> should
> > also replace the IP with the service name. Also, make sure the network
> name
> > is correct. It should be the same as the previous step.
> >
> > Let me know if it works.
> >
> > Patrick
> >
> > On Thu, Jan 3, 2019 at 6:03 PM Juhan Aasaru  wrote:
> >
> > > Hi!
> > >
> > > Courage and Patrick, thanks for explaining to me about the IP addresses
> > > pointing me at the correct repo. Courage, thanks for the recent work on
> > the
> > > repo and for replacing the static IP-s with the service names inside
> > > docker-compose files, I think this increases the readability a lot.
> > >
> > > I tried to run it locally (I didn't yet replace static IP-s with the
> > > service names) and these are my observations.
> > >
> > > When previously I had a problem with static IP-s being not found when
> > > running in Mac then
> > > now I only had to change one thing :
> > > in start-up.sh script I changed this line:
> > >
> > > while ! nc -z 172.16.238.5 9042; do
> > >
> > > to refer to localhost like this:
> > >
> > > while ! nc -z 127.0.0.1 9042; do
> > >
> > > Because in Mac host system doesn't know anything about Docker IP-s.
> > >
> > > But I got stuck with this line of start-up.sh script:
> > >
> > > docker run -d --name 

Re: Setup on Containers

[Juhan Aasaru]

Hi Patrick,

thanks for the step-by-step instructions. Here are the results:

When I ran "docker-compose up" inside "external-tools" and then "docker
network ls" in another terminal I got:

5271e3e6a6ebexternal-tools_app_net   bridge
  local
29fa4ca2bf83external-tools_default   bridge
  local

So the dash ("-") inside the folder name propagates into the network name
as well (at least in my mac).
To comply with this I changed "externaltools_app_net" to
"external-tools_app_net" in start-up.sh and
last row of docker-compose.yml in main directory (other option would have
been renaming directory "external-tools" to "externaltools").

When I ran "docker-compose up" in the main directory I first got an error
with a missing jar in ledger-ms, but I discovered that migration-script was
missing "accounting", I fixed that and created a pull request together with
adding dash to network name.
Courage, would you mind taking a look at the pull request:
https://github.com/openMF/fineract-cn-containers/pull/7/commits/465dfd21aa516cf2c7a363b7bc30d4346c2316c2

After that the "docker-compose up" in the main directory ran until the
output was:

Attaching to identity-ms, deposit-ms, portfolio-ms, report-ms, ledger-ms,
customer-ms, office-ms, rhythm-ms, teller-ms

And then it halted.

When I run "docker-compose down" and then "docker-compose --verbose up"
then I got a bit more info:

Attaching to identity-ms, deposit-ms, portfolio-ms, report-ms, ledger-ms,
customer-ms, office-ms, rhythm-ms, teller-ms
compose.cli.verbose_proxy.proxy_callable: docker events <-
(filters={'label': ['com.docker.compose.project=fineract-cn-containers',
'com.docker.compose.oneoff=False']}, decode=True)
urllib3.connectionpool._make_request: http://localhost:None "GET
/v1.25/events?filters=%7B%22label%22%3A+%5B%22com.docker.compose.project%3Dfineract-cn-containers%22%2C+%22com.docker.compose.oneoff%3DFalse%22%5D%7D
HTTP/1.1" 200 None
compose.cli.verbose_proxy.proxy_callable: docker events ->


I don't quite understand what it means.

It seems like it completely freezes Docker as in another terminal even
running "docker ps" doesn't repsond anything.
Just in case I will now reinstall Docker in my local computer and try again.

Juhan















Kontakt Patrick Finken () kirjutas kuupäeval R,
4. jaanuar 2019 kell 18:06:

> Hey Juan,
>
> You should first run the external service before running the main services.
>
> Basically, run the command "docker-compose up" inside the external_tools
> folder, or specify the docker-compose file: "docker-compose up -f
> ./external-toools/docker-compose.yml".
> It will spin up cassandra, activemq and maria db. And it will also create
> the network *"externaltools_app_net". *You can make sure it is the correct
> name by running the command "docker network ls". If it's not, for example,
> if the folder has a different name,  you should update the main
> docker-compose.yml file with the correct network name.
>
> Then inside the main folder, in a different terminal, run the command
> "docker-compose up" to start the main services.
>
> In the start-up script, since the IPs are not hardcoded anymore, you should
> also replace the IP with the service name. Also, make sure the network name
> is correct. It should be the same as the previous step.
>
> Let me know if it works.
>
> Patrick
>
> On Thu, Jan 3, 2019 at 6:03 PM Juhan Aasaru  wrote:
>
> > Hi!
> >
> > Courage and Patrick, thanks for explaining to me about the IP addresses
> > pointing me at the correct repo. Courage, thanks for the recent work on
> the
> > repo and for replacing the static IP-s with the service names inside
> > docker-compose files, I think this increases the readability a lot.
> >
> > I tried to run it locally (I didn't yet replace static IP-s with the
> > service names) and these are my observations.
> >
> > When previously I had a problem with static IP-s being not found when
> > running in Mac then
> > now I only had to change one thing :
> > in start-up.sh script I changed this line:
> >
> > while ! nc -z 172.16.238.5 9042; do
> >
> > to refer to localhost like this:
> >
> > while ! nc -z 127.0.0.1 9042; do
> >
> > Because in Mac host system doesn't know anything about Docker IP-s.
> >
> > But I got stuck with this line of start-up.sh script:
> >
> > docker run -d --name provisioner-ms --env
> > eureka.instance.hostname=172.16.238.2 --env ribbon.listOfServers=
> > 172.16.238.2:9090 \
> >   --env eureka.client.serviceUrl.defaultZone=
> > http://172.16.238.2:8761/eureka
> > --env  activemq.brokerUrl=tcp://
> > 172.16.238.3:61616 \
> >   --env cassandra.contactPoints=172.16.238.5:9042 --env
> > mariadb.host=172.16.238.4 --network externaltools_app_net \
> >   --ip 172.16.238.6 provisioner:latest
> >
> > It gets an error:
> >
> > docker: Error response from daemon: network externaltools_app_net not
> > found.
> >
> > Which kind of makes sense because it is declared in the 

Re: Setup on Containers

[Patrick Finken]

Hey Juan,

You should first run the external service before running the main services.

Basically, run the command "docker-compose up" inside the external_tools
folder, or specify the docker-compose file: "docker-compose up -f
./external-toools/docker-compose.yml".
It will spin up cassandra, activemq and maria db. And it will also create
the network *"externaltools_app_net". *You can make sure it is the correct
name by running the command "docker network ls". If it's not, for example,
if the folder has a different name,  you should update the main
docker-compose.yml file with the correct network name.

Then inside the main folder, in a different terminal, run the command
"docker-compose up" to start the main services.

In the start-up script, since the IPs are not hardcoded anymore, you should
also replace the IP with the service name. Also, make sure the network name
is correct. It should be the same as the previous step.

Let me know if it works.

Patrick

On Thu, Jan 3, 2019 at 6:03 PM Juhan Aasaru  wrote:

> Hi!
>
> Courage and Patrick, thanks for explaining to me about the IP addresses
> pointing me at the correct repo. Courage, thanks for the recent work on the
> repo and for replacing the static IP-s with the service names inside
> docker-compose files, I think this increases the readability a lot.
>
> I tried to run it locally (I didn't yet replace static IP-s with the
> service names) and these are my observations.
>
> When previously I had a problem with static IP-s being not found when
> running in Mac then
> now I only had to change one thing :
> in start-up.sh script I changed this line:
>
> while ! nc -z 172.16.238.5 9042; do
>
> to refer to localhost like this:
>
> while ! nc -z 127.0.0.1 9042; do
>
> Because in Mac host system doesn't know anything about Docker IP-s.
>
> But I got stuck with this line of start-up.sh script:
>
> docker run -d --name provisioner-ms --env
> eureka.instance.hostname=172.16.238.2 --env ribbon.listOfServers=
> 172.16.238.2:9090 \
>   --env eureka.client.serviceUrl.defaultZone=
> http://172.16.238.2:8761/eureka
> --env  activemq.brokerUrl=tcp://
> 172.16.238.3:61616 \
>   --env cassandra.contactPoints=172.16.238.5:9042 --env
> mariadb.host=172.16.238.4 --network externaltools_app_net \
>   --ip 172.16.238.6 provisioner:latest
>
> It gets an error:
>
> docker: Error response from daemon: network externaltools_app_net not
> found.
>
> Which kind of makes sense because it is declared in the root docker-compose
> file that is started only later by the same script.
> I tried copying this network declaration from root docker-compose.yml to
> external-tools/docker-compose.yml but no luck.
> When I completely removed ip and network flags from docker-run command then
> the provisioner couldn't find cassandra
> This error, however, can be something to do with my own environment.
>
> Courage, could you please explain the idea with the different networks
> ("externaltools_app_net" declared and "default" referred in root
> docker-compose.yml and app_net declared and used in
> external-tools/docker-compose.yml). If all the services are in the same
> network then could we maybe just use one network?
>
> While I was writing this the new emails arrived about maybe not needing the
> static ip-s at all.
> If the provisioner script needs to know the IP-s then one way would be to
> let docker assign the ip-s itself
> but then to look them up:
>
> https://stackoverflow.com/questions/17157721/how-to-get-a-docker-containers-ip-address-from-the-host
> This wouldn't still work in mac, however.
> Or if provisioning can be done via API maybe the provisioner script could
> be solved using similar approach?
>
> Kind regards
> Juhan
>
>
>
> Kontakt Ed Cable () kirjutas kuupäeval N, 3. jaanuar
> 2019 kell 18:46:
>
> > I want to thank everyone for their valuable and transparent discussion on
> > helping improve the deployability of Fineract CN in the cloud.
> >
> > The mailing list is the perfect place for an open, back-and-forth
> > discussion and debate and of course some aspects might get lost in
> > translation but I don't want anybody to hesitate from sharing their
> inputs
> > and rationale. I encourage others in the community have experience in
> this
> > domain to participate in the discussion as well.
> >
> > Hopefully at the end of this discuss we can document and summarize our
> > findings in the wiki as the conclusive documentation that we've landed
> > upon.
> >
> > Cheers,
> >
> > Ed
> >
> > On Thu, Jan 3, 2019 at 9:28 AM Courage Angeh 
> > wrote:
> >
> > > Hi Patrick,
> > >
> > > Thanks for the explanation. The hardcoded IP addresses are necessary.
> The
> > > is a provisioner script that uses these addresses to provision the
> system
> > > after startup. Starting the Fineract CN services is just one part of
> the
> > > set-up process.
> > > If you read the README you will realize that.
> > >
> > > I think it would have been better for you to 

Re: Setup on Containers

[Juhan Aasaru]

Hi!

Courage and Patrick, thanks for explaining to me about the IP addresses
pointing me at the correct repo. Courage, thanks for the recent work on the
repo and for replacing the static IP-s with the service names inside
docker-compose files, I think this increases the readability a lot.

I tried to run it locally (I didn't yet replace static IP-s with the
service names) and these are my observations.

When previously I had a problem with static IP-s being not found when
running in Mac then
now I only had to change one thing :
in start-up.sh script I changed this line:

while ! nc -z 172.16.238.5 9042; do

to refer to localhost like this:

while ! nc -z 127.0.0.1 9042; do

Because in Mac host system doesn't know anything about Docker IP-s.

But I got stuck with this line of start-up.sh script:

docker run -d --name provisioner-ms --env
eureka.instance.hostname=172.16.238.2 --env ribbon.listOfServers=
172.16.238.2:9090 \
  --env eureka.client.serviceUrl.defaultZone=http://172.16.238.2:8761/eureka
--env activemq.brokerUrl=tcp://172.16.238.3:61616 \
  --env cassandra.contactPoints=172.16.238.5:9042 --env
mariadb.host=172.16.238.4 --network externaltools_app_net \
  --ip 172.16.238.6 provisioner:latest

It gets an error:

docker: Error response from daemon: network externaltools_app_net not found.

Which kind of makes sense because it is declared in the root docker-compose
file that is started only later by the same script.
I tried copying this network declaration from root docker-compose.yml to
external-tools/docker-compose.yml but no luck.
When I completely removed ip and network flags from docker-run command then
the provisioner couldn't find cassandra
This error, however, can be something to do with my own environment.

Courage, could you please explain the idea with the different networks
("externaltools_app_net" declared and "default" referred in root
docker-compose.yml and app_net declared and used in
external-tools/docker-compose.yml). If all the services are in the same
network then could we maybe just use one network?

While I was writing this the new emails arrived about maybe not needing the
static ip-s at all.
If the provisioner script needs to know the IP-s then one way would be to
let docker assign the ip-s itself
but then to look them up:
https://stackoverflow.com/questions/17157721/how-to-get-a-docker-containers-ip-address-from-the-host
This wouldn't still work in mac, however.
Or if provisioning can be done via API maybe the provisioner script could
be solved using similar approach?

Kind regards
Juhan



Kontakt Ed Cable () kirjutas kuupäeval N, 3. jaanuar
2019 kell 18:46:

> I want to thank everyone for their valuable and transparent discussion on
> helping improve the deployability of Fineract CN in the cloud.
>
> The mailing list is the perfect place for an open, back-and-forth
> discussion and debate and of course some aspects might get lost in
> translation but I don't want anybody to hesitate from sharing their inputs
> and rationale. I encourage others in the community have experience in this
> domain to participate in the discussion as well.
>
> Hopefully at the end of this discuss we can document and summarize our
> findings in the wiki as the conclusive documentation that we've landed
> upon.
>
> Cheers,
>
> Ed
>
> On Thu, Jan 3, 2019 at 9:28 AM Courage Angeh 
> wrote:
>
> > Hi Patrick,
> >
> > Thanks for the explanation. The hardcoded IP addresses are necessary. The
> > is a provisioner script that uses these addresses to provision the system
> > after startup. Starting the Fineract CN services is just one part of the
> > set-up process.
> > If you read the README you will realize that.
> >
> > I think it would have been better for you to ask me why I hardcoded the
> IP
> > address and/or you explain why you think it's not necessary and we all
> > agree on that before you conclude that it not necessary and tell another
> > person that it is not. Don't you think so?
> >
> > Nevertheless, Thanks for your contribution and please keep it flowing.
> >
> > Thanks,
> > Courage.
> >
> > On Thu, Jan 3, 2019 at 10:59 AM Patrick Finken  >
> > wrote:
> >
> > > Hello Juan,
> > > I used the scripts from this repo:
> > > https://github.com/openMF/fineract-cn-containers which seems to be the
> > > more
> > > updated.
> > >
> > > You don't need to add all the services to a network because they are
> > > automatically added to the same network as the external services.
> > > If you look a the end of the docker-compose.yml, you will see this :
> > > networks:
> > > default:
> > > external:
> > > name: externaltools_app_net
> > >
> > > That is the network that is created when you run "docker-compose up" in
> > the
> > > external_tools folder.
> > > This is why you are able to use the hostname (ex: cassandra:9090). All
> > > containers are within the same network.
> > >
> > > Actually, all the "networks" section with the hardcoded IP address
> should
> > > be removed from all services. The network 

Re: Setup on Containers

[Courage Angeh]

Hi Patrick,

Thanks for the explanation and I see your point and I think you are right.
Please, can you create a PR on that?

Thanks,
Courage.

On Thu, Jan 3, 2019 at 5:34 PM Patrick Finken 
wrote:

> Hello Ange,
>
> That's what I did. I explained that since the containers are within the
> same network, they could be referenced by their hostname instead of the
> IP addresses.
> But you right, changing it will break the provision script. Actually, I
> didn't use that script (because I'm on a windows machine) instead I used
> postman to call directly the API thanks to
> https://github.com/senacor/fineract-setup/tree/master/scripts/postman
>
> Adapting the config.txt file and replacing the hardcoded IP address by the
> hostname will fix it. For example cassandra.contactPoints=cassandra:9090
> instead of cassandra.contactPoints=172.16.238.5:9090.
>
> I understand why you hardcoded the IP address, but IMHO, letting docker
> assign automatically the IP address and using the hostname it's more simple
> and less verbose.
>
> Kind regards,
> Patrick
>
> On Thu, Jan 3, 2019 at 12:28 PM Courage Angeh 
> wrote:
>
> > Hi Patrick,
> >
> > Thanks for the explanation. The hardcoded IP addresses are necessary. The
> > is a provisioner script that uses these addresses to provision the system
> > after startup. Starting the Fineract CN services is just one part of the
> > set-up process.
> > If you read the README you will realize that.
> >
> > I think it would have been better for you to ask me why I hardcoded the
> IP
> > address and/or you explain why you think it's not necessary and we all
> > agree on that before you conclude that it not necessary and tell another
> > person that it is not. Don't you think so?
> >
> > Nevertheless, Thanks for your contribution and please keep it flowing.
> >
> > Thanks,
> > Courage.
> >
> > On Thu, Jan 3, 2019 at 10:59 AM Patrick Finken  >
> > wrote:
> >
> > > Hello Juan,
> > > I used the scripts from this repo:
> > > https://github.com/openMF/fineract-cn-containers which seems to be the
> > > more
> > > updated.
> > >
> > > You don't need to add all the services to a network because they are
> > > automatically added to the same network as the external services.
> > > If you look a the end of the docker-compose.yml, you will see this :
> > > networks:
> > > default:
> > > external:
> > > name: externaltools_app_net
> > >
> > > That is the network that is created when you run "docker-compose up" in
> > the
> > > external_tools folder.
> > > This is why you are able to use the hostname (ex: cassandra:9090). All
> > > containers are within the same network.
> > >
> > > Actually, all the "networks" section with the hardcoded IP address
> should
> > > be removed from all services. The network section at the end of the
> file
> > is
> > > enough.
> > >
> > > Patrick
> > >
> > > On Tue, Jan 1, 2019 at 3:26 PM Juhan Aasaru  wrote:
> > >
> > > > Hi Patrick and Courage!
> > > >
> > > > Patrick, thanks for sharing the tip how to get the docker-compose
> > version
> > > > of services working without configuring static IP addresses.
> > > > After adding Fineract microservices to "app_net" network I was
> > > > successful using this approach (with one micro service for now - I
> plan
> > > to
> > > > test with more later).
> > > >
> > > > Courage, thanks for explaining the logic. I still think that having
> > > > hardcoded IP addresses is not a good idea because (as I understand
> > > Docker)
> > > > then if you run containers then several copies of the same
> microservice
> > > > might be started to handle the load and make the service fail proof.
> I
> > > > don't think this can work well with hardcoded IP addresses as you can
> > > only
> > > > assign one IP to one specific instance.
> > > >
> > > > I proposed a fix (I added to the pull request mentioned before), also
> > > > visible here:
> > > >
> > > >
> > >
> >
> https://github.com/Anh3h/fineract-cn-docker-scripts/pull/1/commits/c4c4c8ee3e4ccfa1eda9c38fecb018952d488df1
> > > >
> > > > One of the reasons why you might have used static IP addresses is to
> > > refer
> > > > to external tools (cassandra, activemq, etc)
> > > > from the Fineract microservices. They don't know about each other
> since
> > > > they are declared in two different docker-compose files.
> > > > To overcome this I added all the Fineract microservices to "app_net"
> > > > network as I wrote above. This way I managed to start rythm-ms
> > > > and it started up with no errors.
> > > >
> > > > Patrick suggested replacing IP addresses with service names but in
> > order
> > > to
> > > > follow a similar approach to networking and static IP addresses
> > > > I used network aliases instead ("cassandra.service", "rythm.service",
> > > etc).
> > > >
> > > > The downside is that start-up.sh script cannot now use IP to refer to
> > > > Cassandra service. I don't yet know how to solve that
> > > > so you could also just ignore my pull request, Courage. It is more to
> > > > 

Re: Setup on Containers

[Patrick Finken]

Hello Ange,

That's what I did. I explained that since the containers are within the
same network, they could be referenced by their hostname instead of the
IP addresses.
But you right, changing it will break the provision script. Actually, I
didn't use that script (because I'm on a windows machine) instead I used
postman to call directly the API thanks to
https://github.com/senacor/fineract-setup/tree/master/scripts/postman

Adapting the config.txt file and replacing the hardcoded IP address by the
hostname will fix it. For example cassandra.contactPoints=cassandra:9090
instead of cassandra.contactPoints=172.16.238.5:9090.

I understand why you hardcoded the IP address, but IMHO, letting docker
assign automatically the IP address and using the hostname it's more simple
and less verbose.

Kind regards,
Patrick

On Thu, Jan 3, 2019 at 12:28 PM Courage Angeh 
wrote:

> Hi Patrick,
>
> Thanks for the explanation. The hardcoded IP addresses are necessary. The
> is a provisioner script that uses these addresses to provision the system
> after startup. Starting the Fineract CN services is just one part of the
> set-up process.
> If you read the README you will realize that.
>
> I think it would have been better for you to ask me why I hardcoded the IP
> address and/or you explain why you think it's not necessary and we all
> agree on that before you conclude that it not necessary and tell another
> person that it is not. Don't you think so?
>
> Nevertheless, Thanks for your contribution and please keep it flowing.
>
> Thanks,
> Courage.
>
> On Thu, Jan 3, 2019 at 10:59 AM Patrick Finken 
> wrote:
>
> > Hello Juan,
> > I used the scripts from this repo:
> > https://github.com/openMF/fineract-cn-containers which seems to be the
> > more
> > updated.
> >
> > You don't need to add all the services to a network because they are
> > automatically added to the same network as the external services.
> > If you look a the end of the docker-compose.yml, you will see this :
> > networks:
> > default:
> > external:
> > name: externaltools_app_net
> >
> > That is the network that is created when you run "docker-compose up" in
> the
> > external_tools folder.
> > This is why you are able to use the hostname (ex: cassandra:9090). All
> > containers are within the same network.
> >
> > Actually, all the "networks" section with the hardcoded IP address should
> > be removed from all services. The network section at the end of the file
> is
> > enough.
> >
> > Patrick
> >
> > On Tue, Jan 1, 2019 at 3:26 PM Juhan Aasaru  wrote:
> >
> > > Hi Patrick and Courage!
> > >
> > > Patrick, thanks for sharing the tip how to get the docker-compose
> version
> > > of services working without configuring static IP addresses.
> > > After adding Fineract microservices to "app_net" network I was
> > > successful using this approach (with one micro service for now - I plan
> > to
> > > test with more later).
> > >
> > > Courage, thanks for explaining the logic. I still think that having
> > > hardcoded IP addresses is not a good idea because (as I understand
> > Docker)
> > > then if you run containers then several copies of the same microservice
> > > might be started to handle the load and make the service fail proof. I
> > > don't think this can work well with hardcoded IP addresses as you can
> > only
> > > assign one IP to one specific instance.
> > >
> > > I proposed a fix (I added to the pull request mentioned before), also
> > > visible here:
> > >
> > >
> >
> https://github.com/Anh3h/fineract-cn-docker-scripts/pull/1/commits/c4c4c8ee3e4ccfa1eda9c38fecb018952d488df1
> > >
> > > One of the reasons why you might have used static IP addresses is to
> > refer
> > > to external tools (cassandra, activemq, etc)
> > > from the Fineract microservices. They don't know about each other since
> > > they are declared in two different docker-compose files.
> > > To overcome this I added all the Fineract microservices to "app_net"
> > > network as I wrote above. This way I managed to start rythm-ms
> > > and it started up with no errors.
> > >
> > > Patrick suggested replacing IP addresses with service names but in
> order
> > to
> > > follow a similar approach to networking and static IP addresses
> > > I used network aliases instead ("cassandra.service", "rythm.service",
> > etc).
> > >
> > > The downside is that start-up.sh script cannot now use IP to refer to
> > > Cassandra service. I don't yet know how to solve that
> > > so you could also just ignore my pull request, Courage. It is more to
> > > demonstrate how static IP-s could be removed from docker-compose.
> > >
> > > Kind regards
> > > Juhan Aasaru
> > >
> > >
> > >
> > >
> > > Kontakt Courage Angeh () kirjutas kuupäeval E,
> > 31.
> > > detsember 2018 kell 01:25:
> > >
> > > > Hi Patrick,
> > > >
> > > > Yea, since they are on the same network you can use the hostname
> > instead.
> > > > But the docker-compose file is different so you would want to check
> > that
> > > > out.
> > > >
> > 

Re: Setup on Containers

[Ed Cable]

I want to thank everyone for their valuable and transparent discussion on
helping improve the deployability of Fineract CN in the cloud.

The mailing list is the perfect place for an open, back-and-forth
discussion and debate and of course some aspects might get lost in
translation but I don't want anybody to hesitate from sharing their inputs
and rationale. I encourage others in the community have experience in this
domain to participate in the discussion as well.

Hopefully at the end of this discuss we can document and summarize our
findings in the wiki as the conclusive documentation that we've landed upon.

Cheers,

Ed

On Thu, Jan 3, 2019 at 9:28 AM Courage Angeh  wrote:

> Hi Patrick,
>
> Thanks for the explanation. The hardcoded IP addresses are necessary. The
> is a provisioner script that uses these addresses to provision the system
> after startup. Starting the Fineract CN services is just one part of the
> set-up process.
> If you read the README you will realize that.
>
> I think it would have been better for you to ask me why I hardcoded the IP
> address and/or you explain why you think it's not necessary and we all
> agree on that before you conclude that it not necessary and tell another
> person that it is not. Don't you think so?
>
> Nevertheless, Thanks for your contribution and please keep it flowing.
>
> Thanks,
> Courage.
>
> On Thu, Jan 3, 2019 at 10:59 AM Patrick Finken 
> wrote:
>
> > Hello Juan,
> > I used the scripts from this repo:
> > https://github.com/openMF/fineract-cn-containers which seems to be the
> > more
> > updated.
> >
> > You don't need to add all the services to a network because they are
> > automatically added to the same network as the external services.
> > If you look a the end of the docker-compose.yml, you will see this :
> > networks:
> > default:
> > external:
> > name: externaltools_app_net
> >
> > That is the network that is created when you run "docker-compose up" in
> the
> > external_tools folder.
> > This is why you are able to use the hostname (ex: cassandra:9090). All
> > containers are within the same network.
> >
> > Actually, all the "networks" section with the hardcoded IP address should
> > be removed from all services. The network section at the end of the file
> is
> > enough.
> >
> > Patrick
> >
> > On Tue, Jan 1, 2019 at 3:26 PM Juhan Aasaru  wrote:
> >
> > > Hi Patrick and Courage!
> > >
> > > Patrick, thanks for sharing the tip how to get the docker-compose
> version
> > > of services working without configuring static IP addresses.
> > > After adding Fineract microservices to "app_net" network I was
> > > successful using this approach (with one micro service for now - I plan
> > to
> > > test with more later).
> > >
> > > Courage, thanks for explaining the logic. I still think that having
> > > hardcoded IP addresses is not a good idea because (as I understand
> > Docker)
> > > then if you run containers then several copies of the same microservice
> > > might be started to handle the load and make the service fail proof. I
> > > don't think this can work well with hardcoded IP addresses as you can
> > only
> > > assign one IP to one specific instance.
> > >
> > > I proposed a fix (I added to the pull request mentioned before), also
> > > visible here:
> > >
> > >
> >
> https://github.com/Anh3h/fineract-cn-docker-scripts/pull/1/commits/c4c4c8ee3e4ccfa1eda9c38fecb018952d488df1
> > >
> > > One of the reasons why you might have used static IP addresses is to
> > refer
> > > to external tools (cassandra, activemq, etc)
> > > from the Fineract microservices. They don't know about each other since
> > > they are declared in two different docker-compose files.
> > > To overcome this I added all the Fineract microservices to "app_net"
> > > network as I wrote above. This way I managed to start rythm-ms
> > > and it started up with no errors.
> > >
> > > Patrick suggested replacing IP addresses with service names but in
> order
> > to
> > > follow a similar approach to networking and static IP addresses
> > > I used network aliases instead ("cassandra.service", "rythm.service",
> > etc).
> > >
> > > The downside is that start-up.sh script cannot now use IP to refer to
> > > Cassandra service. I don't yet know how to solve that
> > > so you could also just ignore my pull request, Courage. It is more to
> > > demonstrate how static IP-s could be removed from docker-compose.
> > >
> > > Kind regards
> > > Juhan Aasaru
> > >
> > >
> > >
> > >
> > > Kontakt Courage Angeh () kirjutas kuupäeval E,
> > 31.
> > > detsember 2018 kell 01:25:
> > >
> > > > Hi Patrick,
> > > >
> > > > Yea, since they are on the same network you can use the hostname
> > instead.
> > > > But the docker-compose file is different so you would want to check
> > that
> > > > out.
> > > >
> > > > Thanks,
> > > > Courage.
> > > >
> > > > On Sun, Dec 30, 2018 at 1:16 PM Patrick Finken <
> > patr...@finksolutions.ca
> > > >
> > > > wrote:
> > > >
> > > > > Hey Juhan,
> > > > >
> > > 

Re: Setup on Containers

[Courage Angeh]

Hi Patrick,

Thanks for the explanation. The hardcoded IP addresses are necessary. The
is a provisioner script that uses these addresses to provision the system
after startup. Starting the Fineract CN services is just one part of the
set-up process.
If you read the README you will realize that.

I think it would have been better for you to ask me why I hardcoded the IP
address and/or you explain why you think it's not necessary and we all
agree on that before you conclude that it not necessary and tell another
person that it is not. Don't you think so?

Nevertheless, Thanks for your contribution and please keep it flowing.

Thanks,
Courage.

On Thu, Jan 3, 2019 at 10:59 AM Patrick Finken 
wrote:

> Hello Juan,
> I used the scripts from this repo:
> https://github.com/openMF/fineract-cn-containers which seems to be the
> more
> updated.
>
> You don't need to add all the services to a network because they are
> automatically added to the same network as the external services.
> If you look a the end of the docker-compose.yml, you will see this :
> networks:
> default:
> external:
> name: externaltools_app_net
>
> That is the network that is created when you run "docker-compose up" in the
> external_tools folder.
> This is why you are able to use the hostname (ex: cassandra:9090). All
> containers are within the same network.
>
> Actually, all the "networks" section with the hardcoded IP address should
> be removed from all services. The network section at the end of the file is
> enough.
>
> Patrick
>
> On Tue, Jan 1, 2019 at 3:26 PM Juhan Aasaru  wrote:
>
> > Hi Patrick and Courage!
> >
> > Patrick, thanks for sharing the tip how to get the docker-compose version
> > of services working without configuring static IP addresses.
> > After adding Fineract microservices to "app_net" network I was
> > successful using this approach (with one micro service for now - I plan
> to
> > test with more later).
> >
> > Courage, thanks for explaining the logic. I still think that having
> > hardcoded IP addresses is not a good idea because (as I understand
> Docker)
> > then if you run containers then several copies of the same microservice
> > might be started to handle the load and make the service fail proof. I
> > don't think this can work well with hardcoded IP addresses as you can
> only
> > assign one IP to one specific instance.
> >
> > I proposed a fix (I added to the pull request mentioned before), also
> > visible here:
> >
> >
> https://github.com/Anh3h/fineract-cn-docker-scripts/pull/1/commits/c4c4c8ee3e4ccfa1eda9c38fecb018952d488df1
> >
> > One of the reasons why you might have used static IP addresses is to
> refer
> > to external tools (cassandra, activemq, etc)
> > from the Fineract microservices. They don't know about each other since
> > they are declared in two different docker-compose files.
> > To overcome this I added all the Fineract microservices to "app_net"
> > network as I wrote above. This way I managed to start rythm-ms
> > and it started up with no errors.
> >
> > Patrick suggested replacing IP addresses with service names but in order
> to
> > follow a similar approach to networking and static IP addresses
> > I used network aliases instead ("cassandra.service", "rythm.service",
> etc).
> >
> > The downside is that start-up.sh script cannot now use IP to refer to
> > Cassandra service. I don't yet know how to solve that
> > so you could also just ignore my pull request, Courage. It is more to
> > demonstrate how static IP-s could be removed from docker-compose.
> >
> > Kind regards
> > Juhan Aasaru
> >
> >
> >
> >
> > Kontakt Courage Angeh () kirjutas kuupäeval E,
> 31.
> > detsember 2018 kell 01:25:
> >
> > > Hi Patrick,
> > >
> > > Yea, since they are on the same network you can use the hostname
> instead.
> > > But the docker-compose file is different so you would want to check
> that
> > > out.
> > >
> > > Thanks,
> > > Courage.
> > >
> > > On Sun, Dec 30, 2018 at 1:16 PM Patrick Finken <
> patr...@finksolutions.ca
> > >
> > > wrote:
> > >
> > > > Hey Juhan,
> > > >
> > > > I manage to deploy on docker using the script here:
> > > > https://github.com/openMF/fineract-cn-containers. It seems to be the
> > > same.
> > > > Since the containers are part of the same network, actually you don't
> > > have
> > > > to use the IP addresses. You can directly use the container hostname.
> > > > for example instead of this:
> > > >
> > > > identity-ms:
> > > > build:
> > > > context: ./identity-ms-scripts
> > > > dockerfile: Dockerfile
> > > > container_name: identity-ms
> > > > environment:
> > > > eureka.instance.hostname: 172.16.238.2
> > > > ribbon.listOfServers: 172.16.238.2:9090
> > > > eureka.client.serviceUrl.defaultZone:
> http://172.16.238.2:8761/eureka
> > > > activemq.brokerUrl: tcp://172.16.238.3:61616
> > > > cassandra.contactPoints: 172.16.238.5:9042
> > > > mariadb.host: 172.16.238.4
> > > > system.publicKey.timestamp: 2018-10-10T01_01_15
> > > > system.publicKey.modulus:
> > > >

Re: Setup on Containers

[Patrick Finken]

Hello Juan,
I used the scripts from this repo:
https://github.com/openMF/fineract-cn-containers which seems to be the more
updated.

You don't need to add all the services to a network because they are
automatically added to the same network as the external services.
If you look a the end of the docker-compose.yml, you will see this :
networks:
default:
external:
name: externaltools_app_net

That is the network that is created when you run "docker-compose up" in the
external_tools folder.
This is why you are able to use the hostname (ex: cassandra:9090). All
containers are within the same network.

Actually, all the "networks" section with the hardcoded IP address should
be removed from all services. The network section at the end of the file is
enough.

Patrick

On Tue, Jan 1, 2019 at 3:26 PM Juhan Aasaru  wrote:

> Hi Patrick and Courage!
>
> Patrick, thanks for sharing the tip how to get the docker-compose version
> of services working without configuring static IP addresses.
> After adding Fineract microservices to "app_net" network I was
> successful using this approach (with one micro service for now - I plan to
> test with more later).
>
> Courage, thanks for explaining the logic. I still think that having
> hardcoded IP addresses is not a good idea because (as I understand Docker)
> then if you run containers then several copies of the same microservice
> might be started to handle the load and make the service fail proof. I
> don't think this can work well with hardcoded IP addresses as you can only
> assign one IP to one specific instance.
>
> I proposed a fix (I added to the pull request mentioned before), also
> visible here:
>
> https://github.com/Anh3h/fineract-cn-docker-scripts/pull/1/commits/c4c4c8ee3e4ccfa1eda9c38fecb018952d488df1
>
> One of the reasons why you might have used static IP addresses is to refer
> to external tools (cassandra, activemq, etc)
> from the Fineract microservices. They don't know about each other since
> they are declared in two different docker-compose files.
> To overcome this I added all the Fineract microservices to "app_net"
> network as I wrote above. This way I managed to start rythm-ms
> and it started up with no errors.
>
> Patrick suggested replacing IP addresses with service names but in order to
> follow a similar approach to networking and static IP addresses
> I used network aliases instead ("cassandra.service", "rythm.service", etc).
>
> The downside is that start-up.sh script cannot now use IP to refer to
> Cassandra service. I don't yet know how to solve that
> so you could also just ignore my pull request, Courage. It is more to
> demonstrate how static IP-s could be removed from docker-compose.
>
> Kind regards
> Juhan Aasaru
>
>
>
>
> Kontakt Courage Angeh () kirjutas kuupäeval E, 31.
> detsember 2018 kell 01:25:
>
> > Hi Patrick,
> >
> > Yea, since they are on the same network you can use the hostname instead.
> > But the docker-compose file is different so you would want to check that
> > out.
> >
> > Thanks,
> > Courage.
> >
> > On Sun, Dec 30, 2018 at 1:16 PM Patrick Finken  >
> > wrote:
> >
> > > Hey Juhan,
> > >
> > > I manage to deploy on docker using the script here:
> > > https://github.com/openMF/fineract-cn-containers. It seems to be the
> > same.
> > > Since the containers are part of the same network, actually you don't
> > have
> > > to use the IP addresses. You can directly use the container hostname.
> > > for example instead of this:
> > >
> > > identity-ms:
> > > build:
> > > context: ./identity-ms-scripts
> > > dockerfile: Dockerfile
> > > container_name: identity-ms
> > > environment:
> > > eureka.instance.hostname: 172.16.238.2
> > > ribbon.listOfServers: 172.16.238.2:9090
> > > eureka.client.serviceUrl.defaultZone: http://172.16.238.2:8761/eureka
> > > activemq.brokerUrl: tcp://172.16.238.3:61616
> > > cassandra.contactPoints: 172.16.238.5:9042
> > > mariadb.host: 172.16.238.4
> > > system.publicKey.timestamp: 2018-10-10T01_01_15
> > > system.publicKey.modulus:
> > >
> > >
> >
> 1883041786550475466359665792116998138861360861811418125773023262600704610420506961056363406020789918942408991582198166392986508224137096115149674870487774825939045982918659434183601760851901070083290045061183781395325356196386657242031040052351165736982976641680336316849188641479977582074875649920309364739063695984175215564568556116274218897796169400570444034761551339328498932206771964154905729331995766717016919830551072377438556698145065425621548591770335875306907551370265528935629966530892656985959818205610297140283766405889374249542201561470010250064433930099114538970547846267201625038851781585379046349
> > > system.publicKey.exponent: 65537
> > > networks:
> > > default:
> > > ipv4_address: 172.16.238.7
> > >
> > > you can use this :
> > >
> > > identity-ms:
> > > build:
> > > context: ./identity-ms-scripts
> > > dockerfile: Dockerfile
> > > container_name: identity-ms
> > > environment:
> > > eureka.instance.hostname: eureka
> > > 

Re: Setup on Containers

[Courage Angeh]

Hi Juhan,

Happy New Year. Hope this email finds you well.

On Tue, Jan 1, 2019 at 3:26 PM Juhan Aasaru  wrote:

> Hi Patrick and Courage!
>
> Patrick, thanks for sharing the tip how to get the docker-compose version
> of services working without configuring static IP addresses.
> After adding Fineract microservices to "app_net" network I was
> successful using this approach (with one micro service for now - I plan to
> test with more later).
>
> Courage, thanks for explaining the logic. I still think that having
> hardcoded IP addresses is not a good idea because (as I understand Docker)
> then if you run containers then several copies of the same microservice
> might be started to handle the load and make the service fail proof. I
> don't think this can work well with hardcoded IP addresses as you can only
> assign one IP to one specific instance.
>

If the instances are to scale to manage the workload, they share thesame ip
address, and a user's request is forwarded to an instance based on the
workload of the instance. If an instance scales to a thousand instance,
that doesn't mean the different instance have different ip addresses. If I
am not to "hardcode" the ip address as you say, I will think you are
talking of the fact that I am manually configuraing the IP address, that's
not a problem really but you can use dynamic address if you want, and you
would complement that with an IPAM from a service provider (that's for
dynamic IP addresses).

>
> I proposed a fix (I added to the pull request mentioned before), also
> visible here:
>
> https://github.com/Anh3h/fineract-cn-docker-scripts/pull/1/commits/c4c4c8ee3e4ccfa1eda9c38fecb018952d488df1


You are refering to an outdated code base. Due to the confusion I have
pushed the most recent code base to OpenMF
https://github.com/openMF/fineract-cn-containers


>
> One of the reasons why you might have used static IP addresses is to refer
> to external tools (cassandra, activemq, etc)
> from the Fineract microservices. They don't know about each other since
> they are declared in two different docker-compose files.
> To overcome this I added all the Fineract microservices to "app_net"
> network as I wrote above. This way I managed to start rythm-ms
> and it started up with no errors.
>

All fineract services (Provisioner, Identity ...) and the tools (Cassandra,
MariaDB ...) used by the services share thesame network.


> Patrick suggested replacing IP addresses with service names but in order to
> follow a similar approach to networking and static IP addresses
> I used network aliases instead ("cassandra.service", "rythm.service", etc).
>
>
I am sure what you mean, but please checkout out this link for the most
recent code base. https://github.com/openMF/fineract-cn-containers
To make easier to manage the IP address used by the external tool, I went
with Patrick's idea. I have done that for identity only but you could
explain your  idea and  make a an appropriate PR

The downside is that start-up.sh script cannot now use IP to refer to
> Cassandra service. I don't yet know how to solve that
> so you could also just ignore my pull request, Courage. It is more to
> demonstrate how static IP-s could be removed from docker-compose.
>
> Kind regards
> Juhan Aasaru
>
>
>
>
> Kontakt Courage Angeh () kirjutas kuupäeval E, 31.
> detsember 2018 kell 01:25:
>
I hope it's alot clearer, if not just check the link and ask again and I
will be happy to answer your questions.

Thanks for your contribution to the Fineract CN project Patrick and Aasaru.
Please keep the ideas flowing. :-)

Thanks,
Courage.

>
> > Hi Patrick,
> >
> > Yea, since they are on the same network you can use the hostname instead.
> > But the docker-compose file is different so you would want to check that
> > out.
> >
> > Thanks,
> > Courage.
> >
> > On Sun, Dec 30, 2018 at 1:16 PM Patrick Finken  >
> > wrote:
> >
> > > Hey Juhan,
> > >
> > > I manage to deploy on docker using the script here:
> > > https://github.com/openMF/fineract-cn-containers. It seems to be the
> > same.
> > > Since the containers are part of the same network, actually you don't
> > have
> > > to use the IP addresses. You can directly use the container hostname.
> > > for example instead of this:
> > >
> > > identity-ms:
> > > build:
> > > context: ./identity-ms-scripts
> > > dockerfile: Dockerfile
> > > container_name: identity-ms
> > > environment:
> > > eureka.instance.hostname: 172.16.238.2
> > > ribbon.listOfServers: 172.16.238.2:9090
> > > eureka.client.serviceUrl.defaultZone: http://172.16.238.2:8761/eureka
> > > activemq.brokerUrl: tcp://172.16.238.3:61616
> > > cassandra.contactPoints: 172.16.238.5:9042
> > > mariadb.host: 172.16.238.4
> > > system.publicKey.timestamp: 2018-10-10T01_01_15
> > > system.publicKey.modulus:
> > >
> > >
> >
> 

Re: Setup on Containers

[Juhan Aasaru]

Hi Patrick and Courage!

Patrick, thanks for sharing the tip how to get the docker-compose version
of services working without configuring static IP addresses.
After adding Fineract microservices to "app_net" network I was
successful using this approach (with one micro service for now - I plan to
test with more later).

Courage, thanks for explaining the logic. I still think that having
hardcoded IP addresses is not a good idea because (as I understand Docker)
then if you run containers then several copies of the same microservice
might be started to handle the load and make the service fail proof. I
don't think this can work well with hardcoded IP addresses as you can only
assign one IP to one specific instance.

I proposed a fix (I added to the pull request mentioned before), also
visible here:
https://github.com/Anh3h/fineract-cn-docker-scripts/pull/1/commits/c4c4c8ee3e4ccfa1eda9c38fecb018952d488df1

One of the reasons why you might have used static IP addresses is to refer
to external tools (cassandra, activemq, etc)
from the Fineract microservices. They don't know about each other since
they are declared in two different docker-compose files.
To overcome this I added all the Fineract microservices to "app_net"
network as I wrote above. This way I managed to start rythm-ms
and it started up with no errors.

Patrick suggested replacing IP addresses with service names but in order to
follow a similar approach to networking and static IP addresses
I used network aliases instead ("cassandra.service", "rythm.service", etc).

The downside is that start-up.sh script cannot now use IP to refer to
Cassandra service. I don't yet know how to solve that
so you could also just ignore my pull request, Courage. It is more to
demonstrate how static IP-s could be removed from docker-compose.

Kind regards
Juhan Aasaru




Kontakt Courage Angeh () kirjutas kuupäeval E, 31.
detsember 2018 kell 01:25:

> Hi Patrick,
>
> Yea, since they are on the same network you can use the hostname instead.
> But the docker-compose file is different so you would want to check that
> out.
>
> Thanks,
> Courage.
>
> On Sun, Dec 30, 2018 at 1:16 PM Patrick Finken 
> wrote:
>
> > Hey Juhan,
> >
> > I manage to deploy on docker using the script here:
> > https://github.com/openMF/fineract-cn-containers. It seems to be the
> same.
> > Since the containers are part of the same network, actually you don't
> have
> > to use the IP addresses. You can directly use the container hostname.
> > for example instead of this:
> >
> > identity-ms:
> > build:
> > context: ./identity-ms-scripts
> > dockerfile: Dockerfile
> > container_name: identity-ms
> > environment:
> > eureka.instance.hostname: 172.16.238.2
> > ribbon.listOfServers: 172.16.238.2:9090
> > eureka.client.serviceUrl.defaultZone: http://172.16.238.2:8761/eureka
> > activemq.brokerUrl: tcp://172.16.238.3:61616
> > cassandra.contactPoints: 172.16.238.5:9042
> > mariadb.host: 172.16.238.4
> > system.publicKey.timestamp: 2018-10-10T01_01_15
> > system.publicKey.modulus:
> >
> >
> 1883041786550475466359665792116998138861360861811418125773023262600704610420506961056363406020789918942408991582198166392986508224137096115149674870487774825939045982918659434183601760851901070083290045061183781395325356196386657242031040052351165736982976641680336316849188641479977582074875649920309364739063695984175215564568556116274218897796169400570444034761551339328498932206771964154905729331995766717016919830551072377438556698145065425621548591770335875306907551370265528935629966530892656985959818205610297140283766405889374249542201561470010250064433930099114538970547846267201625038851781585379046349
> > system.publicKey.exponent: 65537
> > networks:
> > default:
> > ipv4_address: 172.16.238.7
> >
> > you can use this :
> >
> > identity-ms:
> > build:
> > context: ./identity-ms-scripts
> > dockerfile: Dockerfile
> > container_name: identity-ms
> > environment:
> > eureka.instance.hostname: eureka
> > ribbon.listOfServers: eureka:9090
> > eureka.client.serviceUrl.defaultZone: http://eureka:8761/eureka
> > activemq.brokerUrl: tcp://activemq:61616
> > cassandra.contactPoints: cassandra:9042
> > mariadb.host: mariadb
> > system.publicKey.timestamp: 2018-10-10T01_01_15
> > system.publicKey.modulus:
> >
> >
> 1883041786550475466359665792116998138861360861811418125773023262600704610420506961056363406020789918942408991582198166392986508224137096115149674870487774825939045982918659434183601760851901070083290045061183781395325356196386657242031040052351165736982976641680336316849188641479977582074875649920309364739063695984175215564568556116274218897796169400570444034761551339328498932206771964154905729331995766717016919830551072377438556698145065425621548591770335875306907551370265528935629966530892656985959818205610297140283766405889374249542201561470010250064433930099114538970547846267201625038851781585379046349
> > system.publicKey.exponent: 6553
> >
> > I will create a PR to adjust it.
> > Hope it will help 

Re: Setup on Containers

[Courage Angeh]

Hi Patrick,

Yea, since they are on the same network you can use the hostname instead.
But the docker-compose file is different so you would want to check that
out.

Thanks,
Courage.

On Sun, Dec 30, 2018 at 1:16 PM Patrick Finken 
wrote:

> Hey Juhan,
>
> I manage to deploy on docker using the script here:
> https://github.com/openMF/fineract-cn-containers. It seems to be the same.
> Since the containers are part of the same network, actually you don't have
> to use the IP addresses. You can directly use the container hostname.
> for example instead of this:
>
> identity-ms:
> build:
> context: ./identity-ms-scripts
> dockerfile: Dockerfile
> container_name: identity-ms
> environment:
> eureka.instance.hostname: 172.16.238.2
> ribbon.listOfServers: 172.16.238.2:9090
> eureka.client.serviceUrl.defaultZone: http://172.16.238.2:8761/eureka
> activemq.brokerUrl: tcp://172.16.238.3:61616
> cassandra.contactPoints: 172.16.238.5:9042
> mariadb.host: 172.16.238.4
> system.publicKey.timestamp: 2018-10-10T01_01_15
> system.publicKey.modulus:
>
> 1883041786550475466359665792116998138861360861811418125773023262600704610420506961056363406020789918942408991582198166392986508224137096115149674870487774825939045982918659434183601760851901070083290045061183781395325356196386657242031040052351165736982976641680336316849188641479977582074875649920309364739063695984175215564568556116274218897796169400570444034761551339328498932206771964154905729331995766717016919830551072377438556698145065425621548591770335875306907551370265528935629966530892656985959818205610297140283766405889374249542201561470010250064433930099114538970547846267201625038851781585379046349
> system.publicKey.exponent: 65537
> networks:
> default:
> ipv4_address: 172.16.238.7
>
> you can use this :
>
> identity-ms:
> build:
> context: ./identity-ms-scripts
> dockerfile: Dockerfile
> container_name: identity-ms
> environment:
> eureka.instance.hostname: eureka
> ribbon.listOfServers: eureka:9090
> eureka.client.serviceUrl.defaultZone: http://eureka:8761/eureka
> activemq.brokerUrl: tcp://activemq:61616
> cassandra.contactPoints: cassandra:9042
> mariadb.host: mariadb
> system.publicKey.timestamp: 2018-10-10T01_01_15
> system.publicKey.modulus:
>
> 1883041786550475466359665792116998138861360861811418125773023262600704610420506961056363406020789918942408991582198166392986508224137096115149674870487774825939045982918659434183601760851901070083290045061183781395325356196386657242031040052351165736982976641680336316849188641479977582074875649920309364739063695984175215564568556116274218897796169400570444034761551339328498932206771964154905729331995766717016919830551072377438556698145065425621548591770335875306907551370265528935629966530892656985959818205610297140283766405889374249542201561470010250064433930099114538970547846267201625038851781585379046349
> system.publicKey.exponent: 6553
>
> I will create a PR to adjust it.
> Hope it will help you.
>
> Patrick
>
>
> On Sun, Dec 30, 2018 at 11:14 AM Juhan Aasaru  wrote:
>
> > Hi Courage,
> >
> > I also checked out the work you have done on containers as I also plan to
> > deploy the Fineract CN services to the cloud. Would you mind explaining a
> > few things for me:
> >
> > 1. I tried running the scripts (taken from your GitHub fork) locally (I
> > always find I need to be able to run anything locally first before
> > deploying to anywhere else).
> > I tried out both the Kubernetes scripts (with Minikube) and the
> > docker-compose scripts. I didn't manage to get them running because of
> the
> > hardcoded IP addresses (there is no easy method in mac to have several
> > static IP addresses at the same time). I don't have much experience with
> > deploying container-based
> > systems so if you could elaborate on the topic a bit and if it would make
> > sense to
> > to replace IP addresses with service names or aliases.
> >
> > 2. The docker-compose.yml in root directory has all of the services
> besides
> > rythm-ms commented out. Can one just comment other services back in or is
> > there some work that needs to be done first?
> >
> > 3. I think I found a typo in external-scripts/docker-compose.yml
> > You have mapped Cassandra port 9042 to port 9142 for the outside world
> but
> > I think it should be still 9042. I created a pull request for you repo to
> > fix this.
> >
> > I hope you have a chance to help me with my questions.
> >
> > Thanks
> > Juhan Aasaru
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Kontakt Courage Angeh () kirjutas kuupäeval K,
> 26.
> > detsember 2018 kell 17:29:
> >
> > > Hi Patrick,
> > >
> > > Could you check this out instead?
> > > https://github.com/Anh3h/fineract-cn-docker-scripts
> > > I am still to merge that into the Mifos codebase
> > > That should work.
> > >
> > > Thanks,
> > > Courage.
> > >
> > > On Tue, Dec 25, 2018 at 6:04 PM Patrick Finken <
> patr...@finksolutions.ca
> > >
> > > wrote:
> > >
> > > > Hello Courage,
> > > >
> > > > Actually, the script is from
> > > > 

Re: Setup on Containers

[Courage Angeh]

Hi Juhan,

The Kubernetes scripts should not work correctly 'cause I am still to work
on them,  I am moving to a different cloud platform, for some reason, it's
delaying.
Also, you should run the applications locally and they should run
successfully, NOTE THAT I UPDATED THE CODE ON PROVISIONER ONLY, so you
would only need my code for provisioner. I won't say the IP addresses are
hard coded, I just decided to use those IP addresses, you could configure
different IP addresses. Another good idea will be to configure the IP
addresses at a much higher so that it will be easier to manage changes
whenever we need to use a different IP address.

Also, rhythm is not commented out, just payroll is commented out and that
was done on purpose. I plan to use it to help me optimize the scripts so
that adding a new service would not need a lot of configuration as it does
now.

That should be a typo, I would check out your PR thanks. It's different on
my PC so sorry about that.

I hope I answered your questions. If you have any other questions
please feel free.

Thanks,
Courage.

On Sun, Dec 30, 2018 at 11:14 AM Juhan Aasaru  wrote:

> Hi Courage,
>
> I also checked out the work you have done on containers as I also plan to
> deploy the Fineract CN services to the cloud. Would you mind explaining a
> few things for me:
>
> 1. I tried running the scripts (taken from your GitHub fork) locally (I
> always find I need to be able to run anything locally first before
> deploying to anywhere else).
> I tried out both the Kubernetes scripts (with Minikube) and the
> docker-compose scripts. I didn't manage to get them running because of the
> hardcoded IP addresses (there is no easy method in mac to have several
> static IP addresses at the same time). I don't have much experience with
> deploying container-based
> systems so if you could elaborate on the topic a bit and if it would make
> sense to
> to replace IP addresses with service names or aliases.
>
> 2. The docker-compose.yml in root directory has all of the services besides
> rythm-ms commented out. Can one just comment other services back in or is
> there some work that needs to be done first?
>
> 3. I think I found a typo in external-scripts/docker-compose.yml
> You have mapped Cassandra port 9042 to port 9142 for the outside world but
> I think it should be still 9042. I created a pull request for you repo to
> fix this.
>
> I hope you have a chance to help me with my questions.
>
> Thanks
> Juhan Aasaru
>
>
>
>
>
>
>
>
>
> Kontakt Courage Angeh () kirjutas kuupäeval K, 26.
> detsember 2018 kell 17:29:
>
> > Hi Patrick,
> >
> > Could you check this out instead?
> > https://github.com/Anh3h/fineract-cn-docker-scripts
> > I am still to merge that into the Mifos codebase
> > That should work.
> >
> > Thanks,
> > Courage.
> >
> > On Tue, Dec 25, 2018 at 6:04 PM Patrick Finken  >
> > wrote:
> >
> > > Hello Courage,
> > >
> > > Actually, the script is from
> > > https://github.com/openMF/fineract-cn-containers. The problem is that
> > the
> > > provisioner is expecting two properties that are not specified in the
> > > Dockerfile.
> > >
> > > provisioner| ***
> > > provisioner| APPLICATION FAILED TO START
> > > provisioner| ***
> > >
> > > provisioner| Description:
> > > provisioner|
> > > provisioner| Binding to target
> > > org.apache.fineract.cn.provisioner.config.SystemProperties@72443081
> > > failed:
> > > provisioner|
> > > provisioner| Property: system.privateKey.modulus
> > > provisioner| Value: null
> > > provisioner| Reason: may not be null
> > > provisioner|
> > > provisioner| Property: system.privateKey.exponent
> > > provisioner| Value: null
> > > provisioner| Reason: may not be null
> > >
> > > But I kind of figured out the solution. I used a tool online to
> generate
> > a
> > > RSA key.
> > > I'm all set now. The platform is running. Thanks
> > >
> > > Merry Christmas
> > > Patrick
> > >
> > > On Tue, Dec 25, 2018 at 6:43 AM Courage Angeh 
> > > wrote:
> > >
> > > > Hi Patrick,
> > > >
> > > > You wouldn't want to deactivate it 'cause its needed for
> > authentication.
> > > > I containerized Fineract CN as a summer of code project, that should
> > help
> > > > you out.
> > > > https://github.com/openMF/fineract-cn-containers
> > > >
> > > > Merry Christmas,
> > > > Courage.
> > > >
> > > > On Tue, Dec 25, 2018 at 1:22 AM Patrick Finken <
> > patr...@finksolutions.ca
> > > >
> > > > wrote:
> > > >
> > > > > Hello Everyone,
> > > > >
> > > > > I'm Patrick. I've recently discovered Fineract CN and I might be
> > > > interested
> > > > > to use as a backend system for a financial application I'm
> building.
> > > > > I succeed to build and launch the demo-server on my local machine,
> > but
> > > > I'm
> > > > > stuck when I try to run it inside containers.
> > > > > I used the script from the repo "apache/fineract-cn-provisioner",
> 

Re: Setup on Containers

[Patrick Finken]

Hey Juhan,

I manage to deploy on docker using the script here:
https://github.com/openMF/fineract-cn-containers. It seems to be the same.
Since the containers are part of the same network, actually you don't have
to use the IP addresses. You can directly use the container hostname.
for example instead of this:

identity-ms:
build:
context: ./identity-ms-scripts
dockerfile: Dockerfile
container_name: identity-ms
environment:
eureka.instance.hostname: 172.16.238.2
ribbon.listOfServers: 172.16.238.2:9090
eureka.client.serviceUrl.defaultZone: http://172.16.238.2:8761/eureka
activemq.brokerUrl: tcp://172.16.238.3:61616
cassandra.contactPoints: 172.16.238.5:9042
mariadb.host: 172.16.238.4
system.publicKey.timestamp: 2018-10-10T01_01_15
system.publicKey.modulus:
1883041786550475466359665792116998138861360861811418125773023262600704610420506961056363406020789918942408991582198166392986508224137096115149674870487774825939045982918659434183601760851901070083290045061183781395325356196386657242031040052351165736982976641680336316849188641479977582074875649920309364739063695984175215564568556116274218897796169400570444034761551339328498932206771964154905729331995766717016919830551072377438556698145065425621548591770335875306907551370265528935629966530892656985959818205610297140283766405889374249542201561470010250064433930099114538970547846267201625038851781585379046349
system.publicKey.exponent: 65537
networks:
default:
ipv4_address: 172.16.238.7

you can use this :

identity-ms:
build:
context: ./identity-ms-scripts
dockerfile: Dockerfile
container_name: identity-ms
environment:
eureka.instance.hostname: eureka
ribbon.listOfServers: eureka:9090
eureka.client.serviceUrl.defaultZone: http://eureka:8761/eureka
activemq.brokerUrl: tcp://activemq:61616
cassandra.contactPoints: cassandra:9042
mariadb.host: mariadb
system.publicKey.timestamp: 2018-10-10T01_01_15
system.publicKey.modulus:
1883041786550475466359665792116998138861360861811418125773023262600704610420506961056363406020789918942408991582198166392986508224137096115149674870487774825939045982918659434183601760851901070083290045061183781395325356196386657242031040052351165736982976641680336316849188641479977582074875649920309364739063695984175215564568556116274218897796169400570444034761551339328498932206771964154905729331995766717016919830551072377438556698145065425621548591770335875306907551370265528935629966530892656985959818205610297140283766405889374249542201561470010250064433930099114538970547846267201625038851781585379046349
system.publicKey.exponent: 6553

I will create a PR to adjust it.
Hope it will help you.

Patrick


On Sun, Dec 30, 2018 at 11:14 AM Juhan Aasaru  wrote:

> Hi Courage,
>
> I also checked out the work you have done on containers as I also plan to
> deploy the Fineract CN services to the cloud. Would you mind explaining a
> few things for me:
>
> 1. I tried running the scripts (taken from your GitHub fork) locally (I
> always find I need to be able to run anything locally first before
> deploying to anywhere else).
> I tried out both the Kubernetes scripts (with Minikube) and the
> docker-compose scripts. I didn't manage to get them running because of the
> hardcoded IP addresses (there is no easy method in mac to have several
> static IP addresses at the same time). I don't have much experience with
> deploying container-based
> systems so if you could elaborate on the topic a bit and if it would make
> sense to
> to replace IP addresses with service names or aliases.
>
> 2. The docker-compose.yml in root directory has all of the services besides
> rythm-ms commented out. Can one just comment other services back in or is
> there some work that needs to be done first?
>
> 3. I think I found a typo in external-scripts/docker-compose.yml
> You have mapped Cassandra port 9042 to port 9142 for the outside world but
> I think it should be still 9042. I created a pull request for you repo to
> fix this.
>
> I hope you have a chance to help me with my questions.
>
> Thanks
> Juhan Aasaru
>
>
>
>
>
>
>
>
>
> Kontakt Courage Angeh () kirjutas kuupäeval K, 26.
> detsember 2018 kell 17:29:
>
> > Hi Patrick,
> >
> > Could you check this out instead?
> > https://github.com/Anh3h/fineract-cn-docker-scripts
> > I am still to merge that into the Mifos codebase
> > That should work.
> >
> > Thanks,
> > Courage.
> >
> > On Tue, Dec 25, 2018 at 6:04 PM Patrick Finken  >
> > wrote:
> >
> > > Hello Courage,
> > >
> > > Actually, the script is from
> > > https://github.com/openMF/fineract-cn-containers. The problem is that
> > the
> > > provisioner is expecting two properties that are not specified in the
> > > Dockerfile.
> > >
> > > provisioner| ***
> > > provisioner| APPLICATION FAILED TO START
> > > provisioner| ***
> > >
> > > provisioner| Description:
> > > provisioner|
> > > provisioner| Binding to target
> > > 

Re: Setup on Containers

[Juhan Aasaru]

Hi Courage,

I also checked out the work you have done on containers as I also plan to
deploy the Fineract CN services to the cloud. Would you mind explaining a
few things for me:

1. I tried running the scripts (taken from your GitHub fork) locally (I
always find I need to be able to run anything locally first before
deploying to anywhere else).
I tried out both the Kubernetes scripts (with Minikube) and the
docker-compose scripts. I didn't manage to get them running because of the
hardcoded IP addresses (there is no easy method in mac to have several
static IP addresses at the same time). I don't have much experience with
deploying container-based
systems so if you could elaborate on the topic a bit and if it would make
sense to
to replace IP addresses with service names or aliases.

2. The docker-compose.yml in root directory has all of the services besides
rythm-ms commented out. Can one just comment other services back in or is
there some work that needs to be done first?

3. I think I found a typo in external-scripts/docker-compose.yml
You have mapped Cassandra port 9042 to port 9142 for the outside world but
I think it should be still 9042. I created a pull request for you repo to
fix this.

I hope you have a chance to help me with my questions.

Thanks
Juhan Aasaru









Kontakt Courage Angeh () kirjutas kuupäeval K, 26.
detsember 2018 kell 17:29:

> Hi Patrick,
>
> Could you check this out instead?
> https://github.com/Anh3h/fineract-cn-docker-scripts
> I am still to merge that into the Mifos codebase
> That should work.
>
> Thanks,
> Courage.
>
> On Tue, Dec 25, 2018 at 6:04 PM Patrick Finken 
> wrote:
>
> > Hello Courage,
> >
> > Actually, the script is from
> > https://github.com/openMF/fineract-cn-containers. The problem is that
> the
> > provisioner is expecting two properties that are not specified in the
> > Dockerfile.
> >
> > provisioner| ***
> > provisioner| APPLICATION FAILED TO START
> > provisioner| ***
> >
> > provisioner| Description:
> > provisioner|
> > provisioner| Binding to target
> > org.apache.fineract.cn.provisioner.config.SystemProperties@72443081
> > failed:
> > provisioner|
> > provisioner| Property: system.privateKey.modulus
> > provisioner| Value: null
> > provisioner| Reason: may not be null
> > provisioner|
> > provisioner| Property: system.privateKey.exponent
> > provisioner| Value: null
> > provisioner| Reason: may not be null
> >
> > But I kind of figured out the solution. I used a tool online to generate
> a
> > RSA key.
> > I'm all set now. The platform is running. Thanks
> >
> > Merry Christmas
> > Patrick
> >
> > On Tue, Dec 25, 2018 at 6:43 AM Courage Angeh 
> > wrote:
> >
> > > Hi Patrick,
> > >
> > > You wouldn't want to deactivate it 'cause its needed for
> authentication.
> > > I containerized Fineract CN as a summer of code project, that should
> help
> > > you out.
> > > https://github.com/openMF/fineract-cn-containers
> > >
> > > Merry Christmas,
> > > Courage.
> > >
> > > On Tue, Dec 25, 2018 at 1:22 AM Patrick Finken <
> patr...@finksolutions.ca
> > >
> > > wrote:
> > >
> > > > Hello Everyone,
> > > >
> > > > I'm Patrick. I've recently discovered Fineract CN and I might be
> > > interested
> > > > to use as a backend system for a financial application I'm building.
> > > > I succeed to build and launch the demo-server on my local machine,
> but
> > > I'm
> > > > stuck when I try to run it inside containers.
> > > > I used the script from the repo "apache/fineract-cn-provisioner", but
> > the
> > > > provisioner service failed to run because of the missing
> configuration
> > > > "system.privateKey.modulus" and "system.privateKey.exponent". I'm
> > > > guessing it's related to some RSA configuration, but there is a way
> to
> > > > deactivate it in order to run and test the API?
> > > >
> > > >
> > > > regards
> > > > --
> > > > Patrick,
> > > >
> > >
> >
> >
> > --
> > Patrick Finken,
> > Owner
> >
>

Re: Setup on Containers

[Courage Angeh]

Hi Patrick,

Could you check this out instead?
https://github.com/Anh3h/fineract-cn-docker-scripts
I am still to merge that into the Mifos codebase
That should work.

Thanks,
Courage.

On Tue, Dec 25, 2018 at 6:04 PM Patrick Finken 
wrote:

> Hello Courage,
>
> Actually, the script is from
> https://github.com/openMF/fineract-cn-containers. The problem is that the
> provisioner is expecting two properties that are not specified in the
> Dockerfile.
>
> provisioner| ***
> provisioner| APPLICATION FAILED TO START
> provisioner| ***
>
> provisioner| Description:
> provisioner|
> provisioner| Binding to target
> org.apache.fineract.cn.provisioner.config.SystemProperties@72443081
> failed:
> provisioner|
> provisioner| Property: system.privateKey.modulus
> provisioner| Value: null
> provisioner| Reason: may not be null
> provisioner|
> provisioner| Property: system.privateKey.exponent
> provisioner| Value: null
> provisioner| Reason: may not be null
>
> But I kind of figured out the solution. I used a tool online to generate a
> RSA key.
> I'm all set now. The platform is running. Thanks
>
> Merry Christmas
> Patrick
>
> On Tue, Dec 25, 2018 at 6:43 AM Courage Angeh 
> wrote:
>
> > Hi Patrick,
> >
> > You wouldn't want to deactivate it 'cause its needed for authentication.
> > I containerized Fineract CN as a summer of code project, that should help
> > you out.
> > https://github.com/openMF/fineract-cn-containers
> >
> > Merry Christmas,
> > Courage.
> >
> > On Tue, Dec 25, 2018 at 1:22 AM Patrick Finken  >
> > wrote:
> >
> > > Hello Everyone,
> > >
> > > I'm Patrick. I've recently discovered Fineract CN and I might be
> > interested
> > > to use as a backend system for a financial application I'm building.
> > > I succeed to build and launch the demo-server on my local machine, but
> > I'm
> > > stuck when I try to run it inside containers.
> > > I used the script from the repo "apache/fineract-cn-provisioner", but
> the
> > > provisioner service failed to run because of the missing configuration
> > > "system.privateKey.modulus" and "system.privateKey.exponent". I'm
> > > guessing it's related to some RSA configuration, but there is a way to
> > > deactivate it in order to run and test the API?
> > >
> > >
> > > regards
> > > --
> > > Patrick,
> > >
> >
>
>
> --
> Patrick Finken,
> Owner
>

Re: Setup on Containers

[Patrick Finken]

Hello Courage,

Actually, the script is from
https://github.com/openMF/fineract-cn-containers. The problem is that the
provisioner is expecting two properties that are not specified in the
Dockerfile.

provisioner| ***
provisioner| APPLICATION FAILED TO START
provisioner| ***

provisioner| Description:
provisioner|
provisioner| Binding to target
org.apache.fineract.cn.provisioner.config.SystemProperties@72443081 failed:
provisioner|
provisioner| Property: system.privateKey.modulus
provisioner| Value: null
provisioner| Reason: may not be null
provisioner|
provisioner| Property: system.privateKey.exponent
provisioner| Value: null
provisioner| Reason: may not be null

But I kind of figured out the solution. I used a tool online to generate a
RSA key.
I'm all set now. The platform is running. Thanks

Merry Christmas
Patrick

On Tue, Dec 25, 2018 at 6:43 AM Courage Angeh 
wrote:

> Hi Patrick,
>
> You wouldn't want to deactivate it 'cause its needed for authentication.
> I containerized Fineract CN as a summer of code project, that should help
> you out.
> https://github.com/openMF/fineract-cn-containers
>
> Merry Christmas,
> Courage.
>
> On Tue, Dec 25, 2018 at 1:22 AM Patrick Finken 
> wrote:
>
> > Hello Everyone,
> >
> > I'm Patrick. I've recently discovered Fineract CN and I might be
> interested
> > to use as a backend system for a financial application I'm building.
> > I succeed to build and launch the demo-server on my local machine, but
> I'm
> > stuck when I try to run it inside containers.
> > I used the script from the repo "apache/fineract-cn-provisioner", but the
> > provisioner service failed to run because of the missing configuration
> > "system.privateKey.modulus" and "system.privateKey.exponent". I'm
> > guessing it's related to some RSA configuration, but there is a way to
> > deactivate it in order to run and test the API?
> >
> >
> > regards
> > --
> > Patrick,
> >
>


-- 
Patrick Finken,
Owner

Re: Setup on Containers

[Courage Angeh]

Hi Patrick,

You wouldn't want to deactivate it 'cause its needed for authentication.
I containerized Fineract CN as a summer of code project, that should help
you out.
https://github.com/openMF/fineract-cn-containers

Merry Christmas,
Courage.

On Tue, Dec 25, 2018 at 1:22 AM Patrick Finken 
wrote:

> Hello Everyone,
>
> I'm Patrick. I've recently discovered Fineract CN and I might be interested
> to use as a backend system for a financial application I'm building.
> I succeed to build and launch the demo-server on my local machine, but I'm
> stuck when I try to run it inside containers.
> I used the script from the repo "apache/fineract-cn-provisioner", but the
> provisioner service failed to run because of the missing configuration
> "system.privateKey.modulus" and "system.privateKey.exponent". I'm
> guessing it's related to some RSA configuration, but there is a way to
> deactivate it in order to run and test the API?
>
>
> regards
> --
> Patrick,
>