-
Notifications
You must be signed in to change notification settings - Fork 3
Home
Hub CTL is stack composition and lifecycle tool:
- template and stack creation, stack deploy / undeploy / backup lifecycle;
- stack and component parameters, output variables, and state;
Assuming you're already committed to (idempotent) infrastructure automation with infrastructure as code - in the cloud or on-prem - Hub CTL could solve a specific problem for you. For example, how to deploy a VPC with a set of network rules, then a Kubernetes cluster, create Okta users, some databases, install Helm charts, then your applications? Making it all play together - in a reproducible, as a cattle way? Repeat 20 times every week in each data center or on different cloud providers or in each cloud region? Omit something or add something, making some installations subtly different yet manageable? Bridge independent instances together? Redeploy a piece of the system to repair or introduce changes? Undeploy safely?
Hub CTL core user experience is about connecting various pieces of software - called components into a stack, each component developed independently yet designed to work together, and also being reusable. Components are wired by producing parameters and consuming outputs.
Components could be anything - Hub CTL is not tied to any particular technology - the only requirements are:
- it must be something executable: a binary, a script, or a format the CLI knows about - Helm, Terraform, etc.;
- input parameters are passed via templates and environment variables;
- outputs are captured from stdout or files;
- the implementation should be idempotent (for best results).
To adopt a component Hub CTL needs just one file - a hub-component.yaml
manifest. In the manifest, component declares input parameters, for example: DNS domain name dns.domain
, number of worker nodes component.kubernetes.worker.count
. It also declares outputs, for example kubernetes.api.endpoint
. Component examples: Kubernetes cluster, complex database setup, microservice. There is support for:
- exporting parameters as environment variables;
- templating with
${}
, Mustache, Golang templates; - secure output capture via one-time pad;
- calculated parameters and outputs;
- synthetic components for calculations;
- default and empty values, base64 and bcrypt, and other small useful things.
To deploy a stack Hub CTL needs hub.yaml
manifest that enumerates components, component locations, order, supported lifecycle operations, initial requirements, and initial parameters. Stack example: microservice or multitier application, with network infrastructure, persistence services, and 3rd party API integrations.
Components are deployed in sequence. Outputs of components become parameters for subsequent components. There is support for mapping outputs and parameters, though most of the time it will just work. State and operation log is recorded and placed encrypted on shared object storage - S3, GCS, or Azure. Components could be undeployed and redeployed individually. Backups can be made, then new instances of the stack could be brought up from snapshots in an organized way, ie. blue-green deployments.
Toolbox is a Docker image that could be used to perform lifecycle operations on a stack. The image contains all the tools installed and configured that are required by the software components supported by Agile Stacks.
Hub CTL extensions are scripts to augment Hub CTL functionality. They provide a simplified command-line experience by leveraging .env
and files under .hub/
.
- Configure
- Stack Deploy
- AWS extension
- Azure extension
- GCP extension
- Kubernetes extension
- Env extension
-
Bubble DNS domain under
epam.devops.delivery
- Pull extension
Cloud-based CI/CD integrations:
- FromStack composition
- Stack design best practices
- Backup and restore from snapshot
- Platform stack
- Encryption applied to state and elaborate files
© 2022 EPAM Systems, Inc. All Rights Reserved