OpenCRVS v1.0.1 - Configuration

[euanmillar]

If you have any questions regarding configuration, first read these docs

If you still need help, ask here.

[baldwinox]

Hello,
While trying to do the installation, i get the warning below;

:::::::::::::::::::: Building OpenCRVS dependencies ::::::::::::::::::::

This can take some time on slow connections. Docker is downloading Mongo DB, ElasticSearch, OpenHIM and Hearth docker images. These are large files. Then it will build them.

yarn run v1.22.19
$ docker-compose -p opencrvs -f docker-compose.deps.yml -f docker-compose.dev-deps.yml up -d
WARNING: The Docker Engine you're using is running in swarm mode.

Compose does not use swarm mode to deploy services to multiple nodes in a swarm. All containers will be scheduled on the current node.

To deploy your application across the swarm, use docker stack deploy.

---

I would like to install OpenCRVS across a 3 node Cluster that has been setup using the ansible inventory and playbook files. How can i go about this. Most of the documentation i see is about a local installation. Any guidance will be appreciated.

Baldwin

[opencrvsug]

Hello Riku, I have finally and successfully deployed using the supplied Github Actions. I would like some direction/clarification on when it comes to generating demo data for a 3 Server QA configuration. The attached error is what i keep getting when i try to use the 'Generate Demo Data' Action. The clarity i need is basically regarding the following, this will help connect all the dots i keep scratching my head about (No programming background :-)

1 - Before i run the Demo Data Action, MUST i ensure that opencrvs-core and/or opencrvs-farajaland (opencrvs-UGA in my case) is running? As you will notice the error i get is FetchError: request to http://localhost:4040/authenticate failed, reason: connect ECONNREFUSED 127.0.0.1:4040 which basically indicates that its trying to access port 4040 on the localhost. This port is not currently listening on the manager node. Currently i am only getting "404 page not found" without importing the demo data.

2 - There are some ENV Secrets in the Demo Action YML which were not explicitly created during at deployment, could this be the direction i should be looking
DISTRICTS:
COUNTRY_CONFIG_HOST:
AUTH_API_HOST:
GATEWAY_HOST:
CONFIG_HOST:
CONCURRENCY:

Its been a steep learning curve to get to this point and i am confident i am close to the finish line. Thank you for your guidance.

[opencrvsug]

Thanks. I understand it now. I am able to view the login page for OpenCRVS. My stumbling block now is whether all the replicas should be running. I see some replicas that are not running 0/2, 0/3 etc and i am no sure if this is because i am not running and fully production setup so the deploy script doesnt not start them as a result i only get a white screen when i try to login to openCRVS. Please clarify if all those replicas (see attachment) are all meant to be up. I want to be able to view the logs and troubleshoot.

[rikukissa]

Yes, most of those should be up. My guess is that it's still loading the (relatively large images) on the background. I have just encountered the same issue when making a country deployment in a low-bandwidth setting (2Mbps), and I had to modify the deployment script so that it first downloads the images and then updates the docker stack. It's experimental as always, but if you wanna give it a try, you can checkout to core's deployment-improvement branch and run the deployment script from there. Interested to know the results.

[opencrvsug]

Thanks Riku! I went ahead to reinstall the entire setup and somehow majority of the Replica's sets are up. just about 4 out of the whole lot are not running. I am also able to login to both the OpenHIM Admin Console and the OpenCRVS page. Totall awesome. Now, I would like to expose these landing pages to the external network however i notice that opencrvs-core (port 3020 and 3000) listen and bind to 127.0.0.1 rather than 0.0.0.0 as shown below;
tcp 0 0 127.0.0.1:3020 0.0.0.0:* LISTEN 45039/node
tcp 0 0 127.0.0.1:3000 0.0.0.0:* LISTEN 45059/node

yet there are other services/ports that are accessible over the external network e.g.

tcp 0 0 0.0.0.0:8086 0.0.0.0:* LISTEN -

My quesiton is: Is this localhost 127.0.0.1 hard coded in any of the scripts. I would like to change it to 0.0.0.0 so i can access the application from over my LAN

[rikukissa]

No worries :) Glad you got it running

just about 4 out of the whole lot are not running

That's expected. We have a few services that are only run on deployment and shut down right after.

Is this localhost 127.0.0.1 hard coded in any of the scripts. I would like to change it to 0.0.0.0 so i can access the application from over my LAN

Interesting question. In the default deployment, we have a service called Traefik, that acts (or should act) as the first point of contact for all HTTP(S) request coming into the stack. Traefik run on port 80 and captures requests with all domains as long as those domains point to the server's IP address. So you can imagine login.farajaland.opencrvs.org, register.farajaland.opencrvs.org... all pointing to the same IP address. I think we might actually be using a wildcard *.farajaland.opencrvs.org to capture all domains and point them to this IP address.

If you look at the service definitions in our docker-compose files, you'll see that some services also configure Traefik as part of their own configuration (login service as an example). The configuration tells Traefik when it should redirect the request to this service (traefik.frontend.rule=Host: login.{{hostname}}') and to which port to forward the request inside the container traefik.port=80.

The not immediately obvious benefit of this is also that we do not have to expose the services at all to the host machine, and we actually try to avoid this actively. As long as your server exposes port 80 of Traefik, external machines should be able to use all of the services through port 80. For your annoyance, of course, not exposing the ports means that you cannot easily access 3020 from LAN.

If you are ok with exposing your stack through a public domain, then I suggest you do that.

If you only want to use the software in LAN, I recommend you come up with a hostname (let's say myopencrvs.internal) and configure all computers that will use your OpenCRVS instance to understand that myopencrvs.internal and *.myopencrvs.internal domains should point to your OpenCRVS server's local IP address. You can do this by manipulating the HOSTS file (mechanism should be almost the same on all platforms).
I have never done this myself and networking is definitely my strongest suit, but I think this could work. Interested to know the results if you do decide to try this.

[opencrvsug]

Sounds like rocket science but let me do some research and poke around then i will revert. :-)