Developers work on one or more Apps. An App is made up of one or more related modules running in Kubernetes. In general, an app represents a single namespace in a Kubernetes cluster.
Humanitec tracks new Container Images as they are built by hooking into the end of the Continuous Integration (CI) pipeline. This allows Container Images to be associated with source control metadata such as the commit that it was built from or what branch it came from.
Container Images you build can be stored in Humanitec’s hosted registry or in your own private registry.
Each App has one or more Environments. An Environment is an independent space that an app can be deployed into. Different versions of the same app can be deployed into many environments at the same time.
Environments can be configured to be either:
- Independant namespaces in the same Cluster, or
- Each environment is deployed in its own cluster.
(It is possible to have some environments, e.g. Production and Staging deploy to their own unique clusters while at the same time deploying all development environments as independent namespaces in the same cluster.)
Environments can also include environment specific External Resources.
An app is made up of one or more modules. Modules have the same meaning as in Kubernetes - i.e. representing a Pod with its Controller (Deployment, StatefulSet, Job etc.)
Humanitec can also manage and provision dependencies that are external to the cluster. We call these “External Resources”. Examples include:
- Postgres databases provided via a managed service such as Google CloudSQL,
- DNS Names provisioned using Cloudflare Managed DNS or
- S3 buckets provided by Amazon S3.
External Resources can either be Dynamic or Static.
Dynamic Resources are created and destroyed on demand when a new Deployment defines a dependency on a resource. For example, can be created when a new Modules is added to an app or an existing app is deployed into a new environment; or destroyed when an environment is deleted.
Static Resources simply map to an existing resource that is managed outside of Humanitec. For example, the production database instance might be managed on a dedicated physical server by the SRE team but should be used by an app deployed to the “Production” Environment in Humanitec.
Both, Dynamic and Static Resources, can be configured to resolve based on criteria such as a particular environment. For example, databases for all development Environments might be dynamically provisioned from a single Google CloudSQL instance whereas the production databases should use pre-provisioned databases running on dedicated physical on-premise servers.
Developers can define Draft Deployments which define changes that should be applied to what is currently deployed in an environment.
Everything that is deployed to an environment is held as a ”Deployment Set”. A Deployment Set holds all of the non-environment specific configuration for an app. This property allows for the same Deployment Set to be deployed to different environments without having to update configuration. An example of non-environmental configuration is that a particular modules has a dependency on a Postgres database. The environment specific part of that configuration is which exact database running on which Postgres instance the modules should access. Environment specific values are referenced via “Variable Expansions” which are resolved at deployment time.
All deployments in an environment are recorded. Humanitec tracks the user who initiated the deployment, time and an optional comment alongside the full Deployment Set of what was deployed. This provides a complete audit log of what happened in an environment. Humanitec also allows developers to see the differences between any two deployments much in the way a developer could generate a diff between two commits in git.