What’s New in v0.5.0

Acorn’s team has been hard at work to bring a collection of new features to Acorn as part of our first release of 2023. With the release of v0.5.0 we have a couple of features we’re particularly excited about and want to highlight for you in this blog post. We’ve added memory constraints for Acorns, a new organization structure called Projects, support for cutom domain patterns, and a number of other features.

Take a look at all of the shiny new features and letus know your thoughts in the Acorn Users slack channel or on Github!

Setting memory specifications for acorns

In the lifecycle of applications, it becomes necessary to consider resources constraints. This is useful for a number of things, among them being auto-scaling and resource conservation. In this release, we are introducing a new feature for setting memory for acorns.

There are four main ways that you can interact with this new feature. In order of precedence, they are:

1. acorn run --memory app=512Mi foo – Sets the memory for the app workload in the foo acorn to 512Mi
2. acorn run --memory 512Mi foo – Sets the memory for all workloads in the foo acorn to 512Mi
3. The memory property attached to workloads in the Acornfile.
4. acorn install --workload-memory-default 512Mi – Specifies the default memory to 512Mi that will be used if the other three values are not set.

Workload is a new term used to aggregate both containers and jobs. Say that we have an nginx container workload that we’re creating in an Acornfile. If we want to change its memory, we would use the new memory property.

containers: {
    nginx: {
        image: "nginx"
        memory: 512Mi
        // ...
    }
}

Under-the-hood, this memory feature is setting the request and limits of the underlying pods for these workloads to be the value specified.

For more information, check out the documentation around the memory feature here.

Autocompletion of Acorn resources

One large quality of life improvement included with this release is the autocompletion of Acorn resources. With this feature, you are now able to see available options for commands targeting Acorn resources.

For example, say that we want to want to remove a volume, foo. Prior to this feature, we would have to get all of the volumes, select the one we want and then run acorn volumes rm foo. Now, we can instead just run acorn volumes rm [TAB] and it will autocomplete with valid values.

For more information and to get setup with autocompletion, check out the documentation here.

Custom acorn domain patterns

When deploying acorns, you’ll likely want them to be accessible at more friendly endpoints than the default. Prior to this release, we had some magic values that would get set across the CLI to enable different forms of the endpoint. With this release, we’ve implemented a new install flag that allows you to completely customize the endpoints your acorns are reached at using a Golang template.

Let’s take a look at an example. The default endpoint pattern that Acorn follow for deployment {{.Container}}-{{.App}}-{{.Hash}}.{{.ClusterDomain}}. This enables easy integration with Let’s Encrypt for certificate generation. However, what if we want a simpler endpoint? We can achieve this by installing acorn with a custom pattern.

$ acorn install --http-endpoint-pattern "{{.Container}}.{{.ClusterDomain}}"

With that option set, our acorns will be deployed at an endpoint like workload.cluster.domain

For more information around this feature, check out the endpoint pattern documentation here.

Projects

Projects allow you to logically group your Acorn resources. In the future this will manage features around membership, RBAC, network isolation and resource quotes. For now, it it a way to create and interact with resources in a logical grouping. It is intended to replace the previous namespace flag that came attached with most Acorn commands prior to this release.

When you install Acorn, you get the acorn namespace by default. You can view this by running acorn projects.

$ acorn projects NAME DEFAULT DESCRIPTION acorn *

You can create a new one easily with the create subcommand. With that created, you can tell Acorn to use it as the default project with the use subcommand.

$ acorn project create foo 
$ acorn project use foo

Now all Acorn commands ran will be done inside of the foo project.

For more information about using project, check out the documentation here.

Custom CA bundle for internal registries

For some users, especially those operating in restricted environments, they will be bringing their own image registry that they will want Acorn to use. In this case, we’ve implemented a new feature that allows you to tell Acorn to trust a registry of your choosing by defining a certificate authority bundle.

First, create two secrets with the name of cabundle – one in the acorn-system namespace and one in acorn-image-system.

$ kubectl -n acorn-system create secret cabundle --from-file=ca-certificates.crt=/path/to/your/ca-certificates.crt 
$ kubectl -n acorn-image-system create secret cabundle --from-file=ca-certificates.crt=/path/to/your/ca-certificates.crt

With these secrets created, you just need to tell acorn to utilize them and point it to your registry.

$ acorn install --internal-registry-prefix your-registry-endpoint/ --use-custom-ca-bundle

Acorn is looking for a secret explicitly called cabundle in both the acorn-system and acorn-image-system namespaces. You cannot currently set it to look for a secret with a different name

Built in roles for different Acorn users

Not all of the users interacting with Acorn need to utilize all of its features. For example, some users need only be able to view logs while others need the full suite of features in order to ship a product. In order to keep permissions as light as necessary while not being restrictive where it doesn’t make sense, we are now providing some built-in roles that allow for sets of Acorn functionality.

Feel free to assign these RBAC roles to your team in order to provide them with the functionality they need to get work done.

acorn:cluster:edit
acorn:cluster:view
acorn:project:admin
acorn:project:build
acorn:project:edit
acorn:project:view
acorn:project:view-logs

For more information, check out our documentation around security considerations here.

Wrapping up

That brings us to the end of another release blog post. For all of the features listed here and others, check out our release notes.

We hope that you’ve been having a fantastic experience using Acorn and will continue to follow us as we improve the product. As always, you can reach us on Github, Slack, Twitter, and LinkedIn with feedback or questions! Please join us for one of our live trainings if you’d like to get a hands-on overview of Acorn.