Fragmented Makefile for localhost deploy

[crazyhouse33]

Hello we use armonik on distant clusters with modified images, custom ingress... I want my dev to be able reproduce the exact same setup than distant server . Your localhost script infrastructure/quick-deploy/localhost/Makefile is deploying everything, ingress, apps, seq. It would be really handy to split the all target into sub ones in order to reduce the deployment time / bug possibilities (I struggle to make your ingress work on minikube). The only things that I need is storage (redis/mongo) and secrets.

I see there were such an handy multi target makefile at this version:
https://github.com/aneoconsulting/ArmoniK/tree/v2.19.0/infrastructure/quick-deploy/localhost/multi-stages

Would it be possible to put it back? It could replace easily the existing one by just replacing deploy-all target by all.

Thanks for your time

[aneojgurhem]

Hello,
Thank you for your interest in ArmoniK.

Multi-stage deployment was deploying exactly the same services that the all-in-one that you see today. You would have not be able to only deploy everything except monitoring (part of monitoring is needed for autoscaling). We realised this deployment was not working as well as expected on Cloud and was slower (multi-stage deployment was not able to take advantage of all the parallelism available in the resource dependencies). It also blocked lot of the improvements we wanted to perform on ArmoniK. As such, we will not add it back.

That being said, ArmoniK infrastructure is highly modular so you can create your own infrastructure that suits your needs while using our terraform modules like what is doing the All-in-one deployment. There is also an option to turn off the ingress :

ArmoniK/infrastructure/quick-deploy/localhost/parameters.tfvars

Line 266 in a9042fb

# PS: to not deploy ingress put: "ingress=null"

However, by doing so, you will not be able to use authentication. It is our ingress that manages this part.

Last but not the least, do you mind sharing the errors you are encountering while deploying our ingress on minikube ? In our test pipelines, we use k3s and it works fine. If it makes sense, you could use it for local deployment and tests. This is what our team does!

Hope this helps!
If you have any other issue, do not hesitate to contact us,
Jérôme

[crazyhouse33]

Hello thanks for the quick answers!

But do you think there is a way to break down the whole infra and to control it like you did for the ingress ? With other vars like kube_apps=null, storage=null...?

Then I dont know terraform but it would be nice if the Makefile would read an optional terraform var file to add our specific use case vars (such as $HOME/aneo.tf or read path via env var). It is also a need to override k8s_config_context var. This would avoid us the need to fork the whole repo just for this part.

I will link you the error I have on minikube next time I bump into it for a new vm. Right now it seems to be ok (maybe it just took a long time to converge to working state) since the error is just already exists:

Plan: 1 to add, 0 to change, 0 to destroy.

Changes to Outputs:

• armonik = {
  • admin_app_url = (known after apply)
  • chaos_mesh_url = null
  • control_plane_url = (known after apply)
  • grafana_url = (known after apply)
  • seq_web_url = (known after apply)
    }
    module.armonik.kubernetes_service.ingress[0]: Creating...
    ╷
    │ Error: services "ingress" already exists
    │
    │ with module.armonik.kubernetes_service.ingress[0],
    │ on generated/infra-modules/armonik/ingress.tf line 131, in resource "kubernetes_service" "ingress":
    │ 131: resource "kubernetes_service" "ingress" {
    │
    ╵
    make: *** [Makefile:38: apply] Error 1