skaffold VS garden

A nice middle ground is using a tool like Google's Skaffold, which provides "Bazel-like" capabilities for composing Docker images and tagging them based on a number of strategies, including file manifests. In my case, I also use build args to explicitly set versions of external dependencies.

While I am in a Typescript environment with this setup at the moment, my personal experience that Skaffold with Docker has a lighter implementation and maintenance overhead than Bazel. (You also get the added benefit of easy deployment and automatic rebuilds.)

I quite liked using Bazel in a small Golang monorepo, but I ran into pain when trying to do things like include third-party pre-compiled binaries in the Docker builds, because of the unusual build rules convention. The advantage of Skaffold is it provides a thin build/tag/deploy/verify layer over Docker and other container types. Might be worth a look!

Kudos to the Google team building it! https://skaffold.dev

To get a similar experience of preevy up, first we’ll need to split the build and deploy using process or alternatively employ tools that orchestrate build-tag-push-update-sync flow like Skaffold/Tilt.

We will be using docker and microk8s from Canonical. For running our software during development, we will be using skaffold which is a great tool developed by Google.

I have used both Skaffold and Devspace. I prefer the latter.

I wonder if it has some overlap with https://skaffold.dev/.

K3d and Skaffold for local development

skaffold.dev - build in k8s - no more asking for the database password. All the plumbing to the backend is just done so it's easier for them to test and demo any branch

To access you service your have several options (it depends on teams the preferences) you can use scaffold https://skaffold.dev/ or for simple case kfwd https://github.com/GiGurra/kfwd. Last for everything that is normally expose on internet you would have an Ingress and use external-dns as you would in prod.

This approach works great when it’s feasible, which is usually at a very early stage in the life of the application where it’s still small and tenable. There’s some tooling that lets you extend this honeymoon phase by letting you do it more easily, like docker-compose, Skaffold, or Tilt. However, at a certain point, even if you’ve written whatever scriptage is needed to actually configure and run the latest stable version of all of your components together, you’re going to hit some sort of ceiling: if you’ve got a large database, or some CPU-heavy computations, or you’re relying on some managed service that can’t be containerized, this approach soon becomes untenable.

Another dev optimization is the conditional rebuilding of a container. For example tools like devspace and skaffold support syncing filles which have changes, but which don't require recompiling.

To add to what's already been said: If you think about it, CI pipelines are typically a complete description of how your system is built, tested, and deployed.

Which is pretty fantastic except for how walled off they are. You can't really re-use these descriptions for e.g. development, they're not vendor agnostic, and they only way to run them is by pushing your code.

Maybe it's a silly analogy but it's almost like being a web dev that doesn't have a browser and needs to send their code to a friend who can tell them if that font size looks good.

I think we're way over due for freeing these "blueprints" of our system from the confines of CI and making them portable and flexible. And containers are the technology that's enabling that.

Full disclaimer (as always): I work at Garden[0] where we're also solving that problem but taking a slightly different approach to Dagger (it's still a DAG). Garden config is declarative and the jobs (we call them actions) have a semantic meaning. You can e.g. have a Build action of type container or a Deploy action of type Helm and Garden will figure out what to do with it.

[0] https://github.com/garden-io/garden

Yes, there's us over at https://github.com/garden-io/garden! We're big believers in pipelines that run anywhere. I even made a short little video that should give you the gist. [1]

Some of the short-list of differences: we use YAML for our configuration language, Dagger can use full-fat languages to define its pipelines. Our feature scope is broader: you can use us to vend IDP-like stacks to your developers if you're a Platform Team; we make development with remote Kubernetes clusters very easy, including all the remote image builds; and we have a number of integrations so you can bring your IaC tool of choice (Pulumi, Terraform) into your pipeline and set up service -> infra dependencies.

[1] https://www.youtube.com/watch?v=JFnan6s2cDg

Me too. In fact Garden (dev tooling for the Kubernetes)[0] is a Berlin start-up with three Icelandic founders.

And if I'm not mistaken, two of us worked briefly with @halldorel (above commenter) at an earlier Icelandic start-up. It's a small world (if you're Icelandic).

[0] https://garden.io

There are dedicated tools just for that. Apart from skaffold check also tilt.dev, garden.io, devspace.sh, okteto.com

Telepresence, tilt, garden.io, okteto, skaffold etc.

- https://garden.io/

I just used garden.io for a small personal project that was more about figuring out how to use garden. I started with the examples and used the Terraform GKE example.

A few other people in the space: garden and tilt have been around for awhile. Skaffold has also been around awhile, but I think it's a step below the others. Or at least it was back when I was evaluating.

We use Mutagen for Garden's hot reloading mechanism. (Garden is a dev tool for K8s and hot reloading enables users to sync changes directly to a prod like dev environment as opposed to doing a rebuild and re-deploy).

It's a really a fantastic piece of technology and completely transformed the whole experience (we were using good 'ol rsync before). In particular it works seamlessly across platforms.

If anyone's interested in how we use it, it's here: https://github.com/garden-io/garden/blob/master/core/src/plu...