aws-ia / terraform-aws-mendix-private-cloud Goto Github PK

Enhance to handle variable namespaces and mutiple namespaces if needed. Raised by @atheiman
The helm chart seems to assume Mendix will only be registered within one namespace. What would need to change to register multiple namespaces into Mendix? We have found “mendix” namespace hardcoded in a few spots in the helm chart and tried to change the chart to support deploying to multiple namespaces, but we want your opinions on what needs to be considered before we deploy the helm chart into multiple namespaces using multiple terraform helm_release resources.

When applying the code,has this error.

Please help,thanks!

A colleague mentioned that even though both the EKS control plane and EKS worker nodes are deployed in HA, the NAT Gateway is deployed in a single AZ:
https://github.com/aws-ia/terraform-aws-mendix-private-cloud/blob/main/modules/vpc/main.tf

single_nat_gateway = true

I understand some customers would want to keep their costs down in pilots/testing but I suggest changing the default to multi AZ and highlight in the documentation some changes that customers can take to reduce costs (single AZ NAT, change instance type,etc)

Hi,

I am in the process of deployment and encountering an error with the Prometheus module. It's attempting to mount the prometheus-server onto a volume that doesn't exist, and I'm unsure why this is happening.

this error terraform:

│ Error: Kubernetes cluster unreachable: the server has asked for the client to provide credentials
│
│ with module.eks_blueprints_kubernetes_addons.module.prometheus[0].module.helm_addon.helm_release.addon[0],
│ on .terraform\modules\eks_blueprints_kubernetes_addons\modules\kubernetes-addons\helm-addon\main.tf line 1, in resource "helm_release" "addon":
│ 1: resource "helm_release" "addon" {

this error in k8s:

Warning ProvisioningFailed persistentvolumeclaim/prometheus-server failed to provision volume with StorageClass "gp2": rpc error: code = Internal desc = Could not create volume "pvc-a10eae24-b883-4bf6-aa54-34a949921e1e": failed to get an available volume in EC2: InvalidVolume.NotFound: The volume 'vol-05a3611b1fd4caad9' does not exist....

Warning ProvisioningFailed persistentvolumeclaim/prometheus-server failed to provision volume with StorageClass "gp2": rpc error: code = AlreadyExists desc = Could not create volume "pvc-a10eae24-b883-4bf6-aa54-34a949921e1e": Parameters on this idempotent request are inconsistent with parameters used in previous request(s)

When I run this as terraform module with the Provision Instructions, it reports error:
│ Error: could not download chart: path "./charts/mendix-installer" not found
│
│ with module.mendix-private-cloud.helm_release.mendix_installer,
│ on .terraform/modules/mendix-private-cloud/main.tf line 168, in resource "helm_release" "mendix_installer":
│ 168: resource "helm_release" "mendix_installer" {

Work around solution:
after update .terraform/modules/mendix-private-cloud/main.tf Line 170
from
chart = "./charts/mendix-installer"
to
chart = "${path.module}/charts/mendix-installer"
then the error disappear.

Have you considered using AWS Certificate Manager(ACM) instead of the custom cert Manager? I believe the setup with Let's Encrypt might be an overhead. I suggest utilizing AWS Certificate Manager along with an Application Load Balancer instead of a Network Load Balancer. So we can disable the cert manager and Nginx controller here.
This way, we can streamline the process, eliminate an extra layer, and leverage a free, AWS-managed certificate solution.
We can group the application load balancer and use the same ALB for grafana endpoint and application endpoints.

Additionally, I recommend integrating Karpenter and enabling the Metric Server to facilitate Horizontal Pod Autoscaling (HPA), ensuring an optimal scaling solution. For the database solution, AWS Aurora could be an excellent choice. Leveraging the cluster endpoint ensures automatic failover to reader instances in case of an Availability Zone (AZ) failure. Moreover, enabling S3 replication adds a layer of Disaster Recovery (DR) readiness to the setup.

Moreover, you might want to explore AWS Managed Grafana for monitoring. It offers easy accessibility for users and streamlined management due to its AWS-managed nature. This solution provides numerous integrations, reducing administrative overhead. However, do consider the cost implications as some clients might request this solution. It's worth considering as an available option in your toolkit.

Additionally, enabling a backup mechanism for the database would be beneficial. Establishing a pipeline to create database and file backups or leveraging a tool like Velero for backups would be a great addition to ensure data safety and recovery capabilities.

I have tested these solutions with terraform and they are working perfectly fine.