Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fragmented Makefile for localhost deploy #1325

Open
crazyhouse33 opened this issue Oct 24, 2024 · 2 comments
Open

Fragmented Makefile for localhost deploy #1325

crazyhouse33 opened this issue Oct 24, 2024 · 2 comments

Comments

@crazyhouse33
Copy link

crazyhouse33 commented Oct 24, 2024

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

@crazyhouse33 crazyhouse33 changed the title Fragmented Makefile for local host deploy Fragmented Makefile for localhost deploy Oct 24, 2024
@aneojgurhem
Copy link
Contributor

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 :

# 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
Copy link
Author

crazyhouse33 commented Oct 28, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants