hub.yaml

Rick Richardson Updated by Rick Richardson

The hub.yaml is the manifest for a Stack template. It outlines the inventory of a Template, and the plan for deployment. It has several sections which merit some explanation. An example hub.yaml looks something like this:

version: 1
kind: stack
meta:
name: example-stack
components:
- name: tiller
source:
dir: components/tiller
- name: automation-tasks-namespace
source:
dir: components/namespace
- name: cert-manager
source:
dir: components/cert-manager
- name: traefik
source:
dir: components/traefik
- name: dex
depends:
- traefik
source:
dir: components/dex
- name: cluster-autoscaler
source:
dir: components/cluster-autoscaler

requires:
- aws
- kubernetes
lifecycle:
verbs:
- deploy
- undeploy
order:
- tiller
- automation-tasks-namespace
- cert-manager
- traefik
- dex
- cluster-autoscaler
mandatory:
- stack-k8s-aws
- tiller
- automation-tasks-namespace
- cert-manager
- traefik
- dex
- cluster-autoscaler
outputs:
- name: 'cert-manager:component.tls.kind'
- name: 'traefik:component.ingress.protocol'
- name: 'traefik:component.ingress.fqdn'
- name: 'traefik:component.ingress.ssoFqdn'
- name: 'traefik:component.ingress.urlPrefix'
- name: 'traefik:component.ingress.ssoUrlPrefix'
- name: 'traefik:component.ingress.loadBalancer'
- name: 'traefik:component.ingress.loadBalancerDnsRecordType'
- name: 'dex:component.dex.issuer'

Meta and fromStack

The first is `meta`. It contains the name and other metadata, but this also contains a very important parameter: `fromStack`. This tells this stack to inherit from an existing stack. In this case, we're inheriting from stack `k8s-aws`. As the name implies, it creates a new Kubernetes cluster in an AWS VPC. `fromStack` is a great way to re-use code and configurations, and help create standardized deployments across your organizations.

Components

The next next section is `components`. This is where you enumerate the components that you would like to have deployed in your stack. Components can either be deployments into Kubernetes itself, or it can be packaged automation tasks such as terraform or cloud-formations that create resources to be used by your stack, such as RDS, autoscaling groups, or even invocations of other 3rd party APIs. Anything that can be automated in the shell can be incorporated as a component.

In this stack, we have several components we're requesting. Note that they're already included in the repo, but you can alternately specify git, http, or relative filesystem URLs, and they can be fetched with the `hub pull` command.

Requires

The `requires` section lists the resources and components that are required by this stack that this stack doesn't control. Specifically, this stack is requesting that `aws` and `kubernetes` be present before proceeding, and those are provided by the `k8s-aws` stack that we inherit using `fromStack`

Lifecycle

This section lists the deployment order of components. Since many components are interdependent, here is where you specify which must come first. For example, many components in the AgileStacks ecosystem are based around helm charts, therefore, Tiller must be present and working before deployment can continue.

The `mandatory` section lists the required components that are a condition of the success of the deployment. Many components are not critical for the stack, and are optional by default. In this example, if `dex` fails to install, the deployment will discontinue and exit with a failure. However, if `efk` fails to install, the installation will succeed, although there will be a warning that the nats component failedd.

Outputs

This a very important section. This lists all of the parameters that are to be exposed back into the environment so that other, future components can auto-configure themselves to interact with that component. A good example is the `minio:component.bucket.accessKey`. A future component running in this system would consume that variable so that it can authenticate to minio. As long as the component takes `component.bucket.accessKey` as an input parameter, the configiruation will be automatically applied.

As a stack creator/deployer, you shouln't have to worry too much about maintaining this section.

It is auto-populated by the `hub pull` command.

How did we do?

hub_version

hub_backup_unbundle

Contact