feat(#171): add support for kubernetes deployment in EKS

[sugat009]

Description

Adds support for kubernetes deployment in EKS.

Fixes: #171

Code review checklist

• Readable: Concise, well named, follows the style guide, documented if necessary.
• Documented: Configuration and user documentation on cht-docs
• Tested: Unit and/or e2e where appropriate
• Backwards compatible: Works with existing data and configuration or includes a migration. Any breaking changes documented in the release notes.

License

The software is provided under AGPL-3.0. Contributions to this project are accepted under the same license.

[github-advanced-security]

SonarCloud found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

[witash]

Looks good, I tested in EKS and got all the services running. The domains didn't work yet, but that could be something else, I'm still looking into that.

For local setup, whats the advantage of using kind instead of k3s/k3d? If there's a good reason, that's ok, but cht-core's test and local set up uses k3s or k3d, so since would often want cht-core if developing cht-interoperabilty, it means having two different kubernetes things running locally.

[witash]

I think for EKS at least, couchdb and the cht deployment should be conditional, and allow an external cht to be used. Even for testing and development deployments, its common to want to deploy only the interop stack, with an cht instance deployed somewhere else (that has the data you want).

[sugat009]

cht-core's test and local set up uses k3s or k3d

Ahh, ok! I was not aware of the local setup for CHT, just the tests. I've not tried k3s or k3d but if this works in them it does make sense to use those instead. Let me try this out.