15 ms·

They forgot one con off pull based deployments which is that you need to put a repository key in your cluster where your code is running. This was a nonstarter

They forgot one con off pull based deployments which is that you need to put a repository key in your cluster where your code is running. This was a nonstarter for a lot of companies I worked for. Also if I was going for pull based I would use Argo or Flux, not some gitlab feature half stitched together by underpaid devs

SOLAR_FIELDS 4y ago
I use Flux, it's great once you grok it and get it configured. Docs are a bit sparse in some areas for things like containers but otherwise quite easy and powerful to set up. One example is that I had my infra code stored in Github and wanted to migrate it to Gitlab. Simple as pushing the existing repository up to Gitlab instead and then flux init Gitlab - everything works as it did before.
physicles 4y ago
> They forgot one con off pull based deployments which is that you need to put a repository key in your cluster where your code is running. Conversely for push-based deployments, there's a process running somewhere outside your cluster that has admin access to your cluster. Did you analyze the threat models for both push and pull, and decide that push is less risky?
nagyv 4y ago
The GitLab PM responsible for the agent for Kubernetes work here. The agent supports automatic (and short lived) support for registry keys for the push-based approach with [Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/stages.html#auto-deploy https://docs.gitlab.com/ee/topics/autodevops/stages.html#aut...), and we have documented how one can [set up container registry keys for the pull-based approach](https://docs.gitlab.com/ee/user/clusters/agent/gitops/secrets_management.html https://docs.gitlab.com/ee/user/clusters/agent/gitops/secret...) The difference between Argo/Flux and the agent is that Argo and Flux are pull-based deployment point solutions (especially Flux), while the agent (originally built on shared codebase with Argo) is the basic integration layer for GitLab - Kubernetes connections. This way, already today, GitLab provides integrated container vulnerability scanning that is out of scope for the other tools. About the half-stitched solution, among the three mentioned tools, only the agent supports server-side applies. The others have it as planned features. If you ever struggled with setting up the right annotations to use pull-based deployments and any competing controller at the same time, using server-side applies provides a lot of benefits.

SOLAR_FIELDS 4y ago

I use Flux, it's great once you grok it and get it configured. Docs are a bit sparse in some areas for things like containers but otherwise quite easy and powerful to set up. One example is that I had my infra code stored in Github and wanted to migrate it to Gitlab. Simple as pushing the existing repository up to Gitlab instead and then flux init Gitlab - everything works as it did before.

physicles 4y ago

> They forgot one con off pull based deployments which is that you need to put a repository key in your cluster where your code is running. Conversely for push-based deployments, there's a process running somewhere outside your cluster that has admin access to your cluster. Did you analyze the threat models for both push and pull, and decide that push is less risky?

nagyv 4y ago

The GitLab PM responsible for the agent for Kubernetes work here. The agent supports automatic (and short lived) support for registry keys for the push-based approach with [Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/stages.html#auto-deploy https://docs.gitlab.com/ee/topics/autodevops/stages.html#aut...), and we have documented how one can [set up container registry keys for the pull-based approach](https://docs.gitlab.com/ee/user/clusters/agent/gitops/secrets_management.html https://docs.gitlab.com/ee/user/clusters/agent/gitops/secret...) The difference between Argo/Flux and the agent is that Argo and Flux are pull-based deployment point solutions (especially Flux), while the agent (originally built on shared codebase with Argo) is the basic integration layer for GitLab - Kubernetes connections. This way, already today, GitLab provides integrated container vulnerability scanning that is out of scope for the other tools. About the half-stitched solution, among the three mentioned tools, only the agent supports server-side applies. The others have it as planned features. If you ever struggled with setting up the right annotations to use pull-based deployments and any competing controller at the same time, using server-side applies provides a lot of benefits.