Concepts

Search…
Concepts
Understand the basic concepts in Humanitec.
Apps
Apps in Humanitec are made up of one or more related Workloads running in a single Kubernetes namespace. An App has one or more Environments associated with it. Apps can be deployed into these Environments. Developers in Humanitec can work on one or more Apps. 
Application Configuration
Application Configuration refers to all the configuration details needed to deploy an App. It includes Environment Variables, Secrets, and Container Configurations.
Container Images
Humanitec is made for containerized Apps. Humanitec tracks new Container Images as they are built by hooking into the end of your Continuous Integration (CI) pipelines. 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.
Deployment Sets
Deployment Sets contain all the non-environment-specific configuration for an App.
Drafts
A Draft is a version of an App that is not yet deployed.
Environments
Each App in Humanitec 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
independent 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.
Environment Types
Environment Types define which infrastructure to use for related Environments. Environment Types are created by the DevOps team and can be selected by the developers when creating a new Environment. The default Environment Type in Humanitec is called development. You can create as many own Environment Types as you want and name them depending on the naming used in your organization (e.g., QA, test-feature-branch). They are matched with Resources using Resource Definitions.
Environment Variables and Secrets
Environment Variables externalize application configuration. An externalized application configuration allows for the ad-hoc creation of new Environments whenever needed. If Environment Variables contain sensitive information (e.g., passwords) they can be stored as Secrets and are only decrypted during deployment time.
External Resources
Humanitec can also manage and provision dependencies that are external to the cluster. These resources are called External Resources. Examples include:
PostgreSQL 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 Workload 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.
Dynamic vs. Static Resource Definitions
Humanitec IDs
Humanitec IDs are used throughout the platform to identify objects. They have the following requirements:
Can only contain lowercase letters, numbers and dashes '-'.
Must be at least 3 characters long.
Cannot start or end with a dash '-'.
Examples of valid IDs:
my-organization
2021-02-01--temp-environment
Examples of invalid IDs:
My-Organization - contains characters other than lowercase letters, numbers or dashes.
a - fewer than 3 characters.
test-env- - starts or ends in a dash.
Manifests
Manifests refer to Kubernetes Manifests. In general Humanitec manages the creation of Manifests as part of the deployment process. It is possible to export Manifests out of Humanitec for a particular deployment.
Resource Drivers
Resource Drivers are used to controlling External Resources. Humanitec provides a growing number of Resource Drivers out-of-the-box. It is also possible to use 3rd party Resource Drivers or even to write your own. Resource Drivers typically call APIs associated with managed services. They use the credentials provided by Resource Accounts in order to manipulate resources provided via managed services.
Static Token
Static tokens allow systems using the Humanitec API to authenticate with Humanitec.
Workloads
Workload refers to the Kubernetes definition of "Workload". In general, it represents a set of pods with its controller specified by a Kubernetes Workload Resource, (e.g Deployment, StatefulSet, or Job.)
The type of controller used is managed by the Workload Profile which can be defined by your DevOps team. The default profile used in Humanitec is a Deployment.
Workload Profiles
A Workload Profile defines the structure of the Kubernetes Manifests that will be generated for a particular Workload. The Workload Profile also defines additional parameters that can be set by the developer through a Deployment Set.