4 ms·

that's a fair point, but Argocd + Packer is just that right ? >some tool that is easily configurable like this that spawns ephemeral environments and deploymen

that's a fair point, but Argocd + Packer is just that right ? >some tool that is easily configurable like this that spawns ephemeral environments and deployments based off a checked in production grade configuration template like you would get with Argo Totally with you there, but you can build this on top of Argo by having your opinionated manifest language (like Packer or Cuberfile or something else). But there is no joy to maintaining the Kubernetes api interfaces.

SOLAR_FIELDS 3y ago
you could achieve this with packer and some custom tooling yeah. But just saying “and some custom tooling” is like saying “you could do what Dropbox does with a custom rsync script”. There’s no off the shelf tooling to do it. One does not simply “build this on top of Argo by having your opinionated manifest language”. There’s probably 10 tools I could customize to do this, packer being one of them, but no real patterns I’m aware of where people are actually doing it with argocd or fluxcd config as a base. Usually you’re either all in or all out on gitops, so I would be interested in seeing blog posts or libraries of people who have done hybrid approaches (push and pull deployments) and the trade offs they had to make. There is a decent amount of decisions that have to be made to build an abstraction like that, so anyone who has done it before I’m happy to stand on the shoulders of. It’s been on my list of unsolved devops/infra problems to unwrap for a couple of years now In the end there are really three steps that need to happen for true “copy prod” ephemeral environments. You need to provision some stack of infra and then deploy some stuff on top of it and then pull some arbitrary, extremely customizable state into that deployment. I’ve been quite interested in Layerform recently for the first part of that, I think they are getting close to the right abstraction on the infra side. But then you still have to deploy (Argo, helm, flux, something) into that infra stack. Then you have to get the state into that deployment somehow. there is no answer for the latter two from Layerform (terraform is not the right tool for deploys or state backups once you do anything beyond a hello world app). Getting the state in has its own whole Pandora’s box (can I copy customer data from prod into another environment? How do I do so on a way that doesn’t violate SOC2/hipaa/whatever? How will my system’s data and configurations affect the third party systems it connects to?) that I think is simply just not generalizable. But the first two steps should be able to be generalized, and the last step is something that tools can be made available to make it easier with the knowledge that it’s basically business logic at that point
- sandGorgon 3y ago
  well my intention was not to trivialize the effort. I think i was trying to ask an architecture question: if you were to build something like Cuber...would you build it over Argocd ? or build it entirely from the ground up. It would still take equal amount of effort probably, but you get the benefit of a larger ecosystem and more work on the underlying infra, while you can focus entirely on the abstractions.

SOLAR_FIELDS 3y ago

you could achieve this with packer and some custom tooling yeah. But just saying “and some custom tooling” is like saying “you could do what Dropbox does with a custom rsync script”. There’s no off the shelf tooling to do it. One does not simply “build this on top of Argo by having your opinionated manifest language”. There’s probably 10 tools I could customize to do this, packer being one of them, but no real patterns I’m aware of where people are actually doing it with argocd or fluxcd config as a base. Usually you’re either all in or all out on gitops, so I would be interested in seeing blog posts or libraries of people who have done hybrid approaches (push and pull deployments) and the trade offs they had to make. There is a decent amount of decisions that have to be made to build an abstraction like that, so anyone who has done it before I’m happy to stand on the shoulders of. It’s been on my list of unsolved devops/infra problems to unwrap for a couple of years now In the end there are really three steps that need to happen for true “copy prod” ephemeral environments. You need to provision some stack of infra and then deploy some stuff on top of it and then pull some arbitrary, extremely customizable state into that deployment. I’ve been quite interested in Layerform recently for the first part of that, I think they are getting close to the right abstraction on the infra side. But then you still have to deploy (Argo, helm, flux, something) into that infra stack. Then you have to get the state into that deployment somehow. there is no answer for the latter two from Layerform (terraform is not the right tool for deploys or state backups once you do anything beyond a hello world app). Getting the state in has its own whole Pandora’s box (can I copy customer data from prod into another environment? How do I do so on a way that doesn’t violate SOC2/hipaa/whatever? How will my system’s data and configurations affect the third party systems it connects to?) that I think is simply just not generalizable. But the first two steps should be able to be generalized, and the last step is something that tools can be made available to make it easier with the knowledge that it’s basically business logic at that point

sandGorgon 3y ago
well my intention was not to trivialize the effort. I think i was trying to ask an architecture question: if you were to build something like Cuber...would you build it over Argocd ? or build it entirely from the ground up. It would still take equal amount of effort probably, but you get the benefit of a larger ecosystem and more work on the underlying infra, while you can focus entirely on the abstractions.