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:
- name: tiller
- name: automation-tasks-namespace
- name: cert-manager
- name: traefik
- name: dex
- name: cluster-autoscaler
- 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.
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.
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`
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.
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.