"role cookbook" pattern for Habitat?

Habitat Help
#1

Do we have a good pattern established for something similar to a role cookbook with Habitat? I have to run multiple services on the same VM call it 10-30 different services. What are some good practices? Could you have a “role plan” that brings all 10-30 services together? Should another layer in the stack handle what versions of each Hab package to run and the configuration tomls? Since all services run on the same VM and interface with each other they need to be tested and upgraded together as an overall unit.

This seems like a similar problem as Automate 2 which runs 20 or so different Habitat packages but uses a deployment utility “./chef-automate” to load and configure the Habitat packages. I also noticed the Automate 2 version number looks like the Hab package date stamp so maybe something similar to a “role plan” is being used to tie all the services into an overall unit.

https://automate.chef.io/docs/quickstart/

#2

Sounds like you’re looking for Composite Packages. It’s a preview feature at this point, so it’s not recommended for production.

Note that composite plans are deployed and managed the same as any other service. You could potentially pin the version of your component services in your composite and version everything that way, but this runs against how Habitat tries to work.

The recommended way is to use release channels in the depot and release/update all of your services independently and have the supervisor handle updating packages automatically, This allows you to put new version of packages into a staging channel, have your staging env auto-updated, test everything, and when it’s good, just promote those staging packages to the stable channel and let your prod environment update itself.

1 Like
#3

awesome I’ll dig into Composite Packages. That looks promising.

I’d still want to be able to update all services independently via the channel but also have some overall method of tracking the services as a set. That way I could test how they behave together in the lessor environments and have some way to track the overall application as a whole.

I’d still subscribe to the channel system automatically updating when new packages area available but before “stable” or “Production” I’d want to promote it as a tested set.