Bringing the Chef Habitat Depot On-Premise in the Enterprise

At ChefConf 2019 in Seattle, I led a session discussing the challenges and the opportunities of bringing a Chef Habitat Depot on-site.

The core focus of my talk was on: 

• The difference between Product Based Origins and Channels and Organization Based Origin and Channels.
• Single Vs Multi-Depot.
• Possible iterations of Multi-Depot architecture along with their pros and cons and best use cases. 

To see my presentation and slide deck, just scroll down to the bottom of this post.

If you’re looking for a quick run-through of what I presented, check out the summary below:

CHEF HABITAT ORIGINS AND CHANNEL PATTERNS:

• Product Based Origin and Channels
  Big enterprises will usually adopt a Product Based pattern as it allows teams to work independently without losing sight of the company’s standards. It’s also ideal for large product-driven organizations; however, on the flipside, it introduces a lot of management overhead for the product teams.

When selecting the pattern that is right for you, ask yourself the following questions:

• How do my application/product teams work?
• How do we release code?
• How do we want to work and release code?

SINGLE VS. MULTI-DEPOT

• Single Depot Overview

Single Depot has a straightforward architecture: your on-prem depot syncs with an upstream public depot.

• Multi-Depot Overview

As the name implies, Multi-Depot architecture involves a single on-prem Prod Depo syncing with multiple non-Prod upstream Depos.

Indellient has an open source Habitat Builder Upstream Sync to help you adopt a multi-depot pattern: https://github.com/Indellient/bldr_package_sync

CI PIPELINE INTEGRATION AND GOVERNANCE

• Multi-Depot With CI:

This architecture enables you to connect your Habitat Multi-Depot with a CI pipeline and abstract the build, upload and promote tasks of your Habitat Packages.

• Multi-Depot with CI and RBAC:

To ensure that your pipeline is secured and compliant, you can also introduce Role Based Access Control as illustrated by the following diagram:

• Pipeline Governance:

For a stricter Pipeline Governance, you can add separation of concerns to your architecture so that the non-production stages promote packages to a production pipeline where they undergo further checks before getting pushed to the Production Ready Habitat Depot.

• Service Architecture:

The following is a Service Architecture that Skyler proposed where a Depot API manages the Depot storage and renders data and relevant controls on a Web UI.

• Service Infrastructure:

Here’s one possible infrastructure for a Hybrid Enterprise Cloud where built packages are stored on an external service:

• HA Multi-Depot With CI and RBAC

Chef Habitat offers flexibility for large enterprises when it comes to architecting their CI pipeline and their Depot Infrastructure. To sum it all up:

1. Choose the correct origin and channel strategy that works for you.
2. Ensure that you address CI pipeline integration and governance.
3. HA S3 storage is essential for production readiness.
4. A Multi-Depot strategy depends on an organization’s needs (separation of responsibilities, etc.)
5. Chef Habitat is ready for the enterprise.

Here are the slides from my presentation: 

And here’s the video of my presentation:

Questions?

If you need help or have any questions about moving Chef Habitat Depot on-premise, please fill out the form here and we’ll get back to you as soon as possible.

---

Indellient is a Canadian Software Development Company that specializes in Data Analytics, DevOps Services, and Business Process Management.