Acorn Questions

[vsamurov]

Some questions that came up in my mind, after reading the Acorn blog post.

• How does Acron provide auditability to operators and security teams?
• What happens when I have to change out a config (do i need to build another image?)
• How does Acorn handle composability?
• How does Acron handle specific CRDs (imaging Acorn asking for an operator in Kube, but that operator is not there in the new kube cluster where you are installing the Acron image)?
• What is the adoption rate for CUE vs Yaml?

[vincent99]

How does Acron provide auditability to operators and security teams?

The output artifact is a valid OCI manifest/image.. since we're brand new there is no special integration with existing tools, but that will evolve over time. The acorn includes all the exact container images used to build it so you can ship one artifact from e.g. test to staging to prod and be confident you're running the exact same thing.

What happens when I have to change out a config (do i need to build another image?)

If it's just an arbitrary string/file burned into the image, yes. If you want to make something configurable you would declare it in args, or as a secret, ideally with a default value. Then it shows up as something the consumer can override, and they can provide a different value at deploy-time.

How does Acorn handle composability?

Acorns can be 'nested', i.e. one acorn deploys another. Again at deploy-time, you can override that with something else if you want.

How does Acron handle specific CRDs (imaging Acorn asking for an operator in Kube, but that operator is not there in the new kube cluster where you are installing the Acron image)?

It doesn't. Acorn is focused on application-level deployment and has no mechanism for describing cluster-level resources like CRDs. We have considered adding support for CRs (not CRDs), but that does not currently exist.

What is the adoption rate for CUE vs Yaml?

Approximately 1:∞. It will certainly grow but CUE is virtually unknown to the average dev/ops user. We basically want something a bit more powerful than YAML. Things like first-class templating, writing YAML in a soup of gotemplates like Helm is gross/unparseable.

So while the implementation is CUE under the hood, we are purposely:

• Calling it just an Acornfile
• Making no regular-user-facing reference to CUE, or .cue files
• Preventing the use of some complicated parts we don't need (packages, import)
• Making some common thing friendlier, e.g.:
  • Variables are just args: foo: "default" instead of args: foo: string | *"default"
  • Function calls are just foo(x) instead of (foo & {_args:x}).out

[cjellick]

How does Acorn handle composability?

Regarding this, in addition to nesting, acorn supports linking, which lets you swap out one container in your app for another running acorn or really any other Kubernetes service. We use it in our DNS service, which is ran as an acorn. You can see here that the acorn-dns app has two "containers": the app named default and the databased named db:

https://github.com/acorn-io/acorn-dns/blob/main/Acornfile#L39-L48

That db configuration is not production worthy, but our MariaDB acorn is. So, we deployed a production grade mariaDB acorn app and then deployed acorn-dns linking to it like so:

acorn run ghcr.io/acorn-io/acorn-dns:v0.1.0 --link my-production-mariadb:db

This is a really powerful. Will be writing a blog article soon about how we're using acorn at Acorn Labs.