Trace: • Habitat Jumpstart

Habitat Jumpstart

This is an old revision of the document!

Chef survey about app dev

Most common measurement for success is speed
Speed is still a difficult challenge
Environments are heterogenous and management is the most challenging ongoing aspect
Hybrid environments are always going to be with us

Habitat

Traditionally we think about building apps “from the ground up”
- Think about which platforms we deploy to, then build the app
We should think about the app first
Habitat covers building and deploying apps
With habitat you start locally and you build artifacts
Then you deploy the artifact to places
Then you manage it via a built in supervisor

Building

Habitat builds from the application down
Built artifact includes all your dependencies
Packaging app steps
- Plan
  - Defines how to build app
  - Defines configuration stuff
- Artifact
- Depot
Deploying apps
- Habitat supports service rings, leader/standalone/leader election topologies, and two different updating strategies

Builder Service

CI for habitat in the clouds
Builder watches repositories, builds artifacts, publishes them to the depot
Builder can trigger builds based on new versions of dependencies

Bindings

Habitat binding is how services discover each other
Binds are implemented as a contract between consumer plan and provider plan
Relationship is expressed in the plan
Habitat Supervisor starts services only after all required binds are met

Consumers

pkg_binds
- Sets a required bind
- Service won't start without it
- Supervisor will wait forever for the other service before starting the consumer
pkg_binds_optional
- Supervisor will look for a provider but own't prevent consumer startup if it can't satisfy the bind

Providers

pkg_exports
- Exposes a service to Habitat Supervisor
- Provides attributes