Configured URL Not Displaying in Kubernetes Environment for CHT User Management Tool

Technical Support
1

Hello,

I am experiencing an issue with the CHT User Management tool when deploying it in a Kubernetes environment using Minikube. The application works correctly when running in the development environment with npm run dev, but it does not display the configured URL when deployed to Kubernetes.

Development Environment

In the development environment, I cloned the repository, configured the .env file, and ran npm run dev. The application works as expected, and the configured URL is displayed correctly.

Dev
Dev2880Ă—1800 509 KB

image
image2880Ă—1800 235 KB

Kubernetes Environment

In the Kubernetes environment, I used this Helm Chart and only added values in the env section of the values.yaml file:

cht-user-management:
  replicaCount: 1

  service:
    port: 3000

  image:
    repository: steveroy/cht-user-management
    tag: "latest"

  env:
    CONFIG_NAME: chis-ke
    COOKIE_PRIVATE_KEY: xxxx-xxxx-xxxx-xxxx
    PORT: 3000
    EXTERNAL_PORT: 3000
    INTERFACE: 0.0.0.0
    CHT_DEV_URL_PORT: test-instance.com 
    CHT_DEV_HTTP: false

  envSecrets:
  - env: COOKIE_PRIVATE_KEY
    secretName: '{{ include "chtUserManagement.fullname" . }}'

While the landing page is accessible, it does not display the configured URL.

kube-term
kube-term2685Ă—920 181 KB

kube-cht-user
kube-cht-user2880Ă—1800 206 KB

Below are the details of my configurations and observations:

  • Development Environment: Works as expected.
  • Kubernetes Environment: Landing page loads, but the configured URL is not displayed.

Additional Information

  • Both environments are running locally.
  • I am using Minikube for the Kubernetes deployment.

Could you please assist me in diagnosing and resolving this issue? Any guidance on what might be causing the discrepancy between the development and Kubernetes environments would be greatly appreciated.

Thank you for your support.

2

@kenn, @ejimba and @Fred, do you have any ideas that can help unblock @Steve_Roy

3

Hey @Steve_Roy. Good questions here.

So if I understand you correctly, you can use the Management Tool to configure users for vihiga-prod-clone-moh-515-testing-go-ke.lg-apps.com when running in dev-mode, but not when in production. You’re setting the CHT_DEV_URL_PORT environment variable to vihiga-prod-clone-moh-515-testing-go-ke.lg-apps.com and expecting that to show up within the Kubernetes environment. Am I correct here about what you’re expecting?

If yes - the way we have things built today is that the $Development Instance option only shows when in dev mode and it is deliberately not available for production instances. Here is that logic. We link of it as a “tool for developers” rather than as a production setting.

Here are a few ideas for how we might proceed:

  1. Add vihiga-prod-clone-moh-515-testing-go-ke.lg-apps.com as a domain in the chis-ke configuration here.
  2. Copy the chis-ke config and make something like a chis-lg configuration which is similar to chis-ke but has your own domain list.
  3. You could make a code change in cht-user-management: maybe you change when the $Development Instance option is visible, or make additional ways of adding domains, etc …
  4. If you’re just testing this; setting the NODE_ENV value to be non-production would be the hackiest path to seeing it work.

It is hard to advise you without understanding your long-term goal a little better. Why are you setting up this server to manage a clone? Are you just testing some things out? I assume there is production data on this clone; so best to be careful with the credentials going throught the user management tool.

Can you confirm this is an eCHIS Kenya instance with the same user types, contact_types, contact forms, etc.?

Recommend changing this

2 Likes
4

Hi @kenn,

Thank you very much for your detailed feedback and suggestions.

Indeed, the $Development Instance option is primarily geared towards development purposes, hence its exclusion from production environments. I appreciate the suggestions you’ve outlined for moving forward.
Regarding your query about the long-term goal behind setting up this server, it’s primarily for testing and experimentation purposes at this stage. We’re being cautious, especially considering the sensitive nature of the data involved. I had also clarified that the env is local.

As for the instance, it shares similarities with the eCHIS Kenya instance in terms of user types, contact types, and contact forms. However, I’ll verify the specifics to ensure alignment.

Many thanks.

5

You did. Apologies.

Then my recommendation is to treat this as a new configuration within the User Management Tool. Here are the steps to create your configuration. It is a bit of a bumpy road, so please let me know if you get stuck. Duplicating the current eCHIS Kenya configuration will put you in a good place to start.

1 Like
6

Hi @kenn

Thank you. I was able to clone one of the configs and defined the relevant properties as required. I now understand where I was getting confused, It seems I didn’t read the instructions well :sweat_smile: Many thanks for the support.

2 Likes