search

Azure / draft

A day 0 tool for getting your app on k8s fast
MIT License
514 stars 61 forks source link

Support a true GitOps workflow #264

Open dtzar opened 6 months ago

dtzar commented 6 months ago

Is your feature request related to a problem? Please describe. As a user, I'd like to be able to utilize true pull-based GitOps workflows for Day 1/2+ operations after getting started. The existing push-based model does not scale as the number of applications, teams, and clusters grow.

Mention what platform you want to support the new feature Has implications possibly across all of: az-extension, oss draft, and vscode.

Describe the solution you'd like

  1. draft create provisions a GitOps-friendly/planned repo structure and optionally wraps the structure in ArgoCD application(Set).
  2. draft setup-gh or likely alternative command bootstraps the cluster with ArgoCD agent sync'ed to the repo specified
  3. draft generate-workflow still sets up the pipeline to build the container image, but it does not authenticate/kubectl apply push down to the cluster. The ArgoCD agent in the previous step will automatically install the newly created container image after it is merged into the proper git directory as specified previously.

Describe alternatives you've considered https://github.com/gitops-bridge-dev/gitops-bridge-argocd-control-plane-template https://github.com/argoproj-labs/argocd-autopilot https://github.com/alexellis/arkade?tab=readme-ov-file#catalog-of-clis -- ArgoCD

imiller31 commented 6 months ago

Draft was explicitly created as a Day 0 tool for rapid prototyping and trying out k8s quickly.

This feature request seems like it wants a separate tool entirely.

As someone who has used GitOps, it is absolute overkill for someone new to the k8s/cloud native space (the target audience of Draft). In your request you even mention Day 1/2+, which is very much outside of the current scope of Draft (ofc the other maintainers may think differently).

dtzar commented 5 months ago

I strongly believe in a great day 0 experience and IMO it should be possible the GitOps aspects to be slipstreamed/hidden from the user. On day 0 they shouldn't have to care that it is using GitOps. The end result should be the same - they get the repo & k8s yaml scaffolding, pipeline to build the container, and the k8s things showing up on the cluster. The difference is they will greatly appreciate not going into a dead-end when they try to scale up to more clusters and apps (e.g. pipeline explosion) and realize they have to re-do everything with GitOps.

imiller31 commented 5 months ago

I'm of the opinion that Draft should be a tool in a toolbox rather than a swiss army knife.

We've talked about Draft supporting GitOps very early on in the Draft lifecycle. It was pretty clear we were targeting different users.

Nothing is stopping a user from running flux bootstrap or similar on the generated manifests.

Does jamming more functionality (and bloat) into Draft really accomplish anything when other tools exist? I'm not sure.

This is probably a better discussion for @davidgamero and @qpetraroia. I only have context on the original intent of this incarnation of Draft.

dtzar commented 5 months ago

Nothing is stopping a user from running flux bootstrap or similar on the generated manifests.

Sure, nothing is stopping people from doing this. The big problem is these two patterns are in opposition to each other. Draft sets up a pipeline which pushes to the Kubernetes cluster. GitOps still needs a pipeline to build the image, but it should not have a pipeline which pushes to the cluster present alongside the agent which pulls from git and applies it.

At a minimum, perhaps draft can have a "GitOps friendly" workflow?

OliverMKing commented 5 months ago

At a minimum, perhaps draft can have a "GitOps friendly" workflow?

What would a "GitOps" friendly workflow look like? Isn't that just the existing draft create command that generates a Dockerfile and manifest?

dtzar commented 5 months ago

Updating generate-workflow to NOT push the contents to the AKS cluster. It could create a pipeline which just builds and pushes the container image to ACR. So with this workflow, it would look something like this:

✔ helm Please enter the Azure container registry name: myacryo.io Please enter the container image name: myimage <--- remove these steps Please enter the Azure resource group of your AKS cluster: mycluster ✔ Please enter the AKS cluster name: ---> <--- rename this step to avoid confusion since you're not actually deploying to the cluster, but you are pulling from this branch to build the image ✔ Please enter the Github branch to automatically deploy from: main█ ----> ✔ Please enter the path to the Docker build context (default: .): █

Then people would be free to use their own GitOps implementation (Argo/Flux) without it being a conflict.

OliverMKing commented 5 months ago

That workflow seems reasonable to me.

davidgamero commented 5 months ago

Updating generate-workflow to NOT push the contents to the AKS cluster

I agree with allowing users to opt out of the manifest applying step in the workflow if they are using GitOps, so we could add a prompt/step to allow restricting the generated workflow to just the build/push for the generated manifests.