Hello Myrle,
Thanks for sharing your thoughts on Dockerization of services.
My experience with embedding infrastructure inside application JVM (even for
development purposes) has not been great. In a development, when things change
so much, embedding infrastructure adds additional time to bootstrap the whole
thing when application restarts needed. Having external infrastructures gives
better visibility as well as their failure to start can be diagnosed better
(e.g. a port is not available because another instance of a infrastructure is
already running in the background).
With external infrastructures, installation becomes cumbersome if we go with
installation of infrastructure and every one need to follow those steps to
install to get there. My PR is really to solve that part.
Some of the complexity, that you alluded to, are really complexity of
design/developing in micro services architecture.
Couple of points about logging (that stays within Docker) as well as debug mode
with Docker deployment, are very much solvable with Docker deployment.
Regarding high amount of resources needed for deployment, one strategy that
could be looked into is to provide capability to selectively start services
needed for a feature to complete and leave the full deployment to integration
environments.
If you looking into collapsing micro-services into a single war, for
development purposes, it can be a strategy that would work. But all of the
services need to be using compatible version of frameworks and managing
different configurations can be challenge.
Having infrastructure as Docker can still come handy in day to day development.
I understand the timeline/priority. No problem.
RegardsViswa
On Monday, March 5, 2018 07:17:41 AM EST, Myrle Krantz
<[email protected]> wrote:
Hey Viswa,
It's going to take me a little longer to get to merging and reviewing
this, so please be patient with me. But a couple of comments while
you're waiting:
1.) That you're not seeing those error messages probably may not mean
they are gone. It may mean that they are now "hidden" in the docker
image. That's not ideal for error messages. It makes debugging
harder when there really is an issue.
2.) Thank you for finding the error with the artifact path. Consider
submitting a patch to fineract-cn-service-starter.
I'm a bit concerned about the idea of moving this all into docker.
Yes docker is one important method for deploying microservices, and
showing an example of how to use those technologies is important. But
the demo-server is also there partly to test code and get a local
installation up and running. When I started on it, my intention was
to support Mark van Veen so that he didn't have to start all the
services and then provision by hand to work on the UI. Unfortunately
there are serious problems with the demo-server the way it is now. It
takes a huge amount of resources because it starts every service in
its own process. Many developers do not have computers with
sufficient resources to run this locally. At one point, Kuelap
literally bought me a new computer after I had spent a couple of days
unsuccessfully trying to make the demo-server work because Markus had
added a couple more services to it. Moving these processes into
containers doesn't solve this problem. Docker works with computing
resources in a shockingly efficient manner, so it probably doesn't
actually make the problem worse, but it does make the problem harder
to solve.
Another point, is that currently I can start these services in debug
mode, and attack a debugger to them to understand tricky problems. I
don't know how to do that in a docker container. Any changes in that
direction should consider this use case.
I can see that testing this running in docker might be important for
some of our users and contributors. But I don't want it to be the
default. I would feel more comfortable with your change sets if you
made this "more optional".
My first priority for this project is to enable contributors. To do
that, I'd like to look for ways to run all of the services in one
process for the purposes of local testing and debugging.
Best Regards,
Myrle Krantz
Committer, Apache Fineract
On Fri, Mar 2, 2018 at 3:35 AM, Viswa Ramamoorthy
<[email protected]> wrote:
> Hi,
> I have raised a PR with docker compose yml for Eureka and ActiveMQ.
> It is https://github.com/apache/fineract-cn-demo-server/pull/3
> Please note that after I launch Eureka and ActiveMQ via Docker, I do not see
> JMS connect error as well as Eureka registration error anymore.
> But service launch was failing with below errorCould not find artifact
> io.mifos.provisioner:service-boot:jar:0.1.0-BUILD-SNAPSHOT
> Locally was able to fix artifact path to "org.apache.fineract.cn." in
> fineract-cn-service-starter and move forward with service launch.
> But there were more errors. I have not looked into further yet.
> I think demo server needs some more work to get it to work consistently. All
> of the services can be launched via shell script if there are no start up
> dependencies between them
> Regards
> Viswa
