Core
Humanitec concepts
Everything in Humanitec revolves around a few core objects: Organizations, Applications and Environments. Broadly speaking, Organizations hold Applications and Applications have one or more Environments. Applications model what you want to run and Environments are where you run it. The hierarch is important and is relied on in other areas such as Application Configuration Management and Resource Management.
Organizations are the "root" object in Humanitec. They are the basic unit of membership for developers and platform teams working in Humanitec. When you are invited to Humanitec, you are invited to an Organization. If you are not a member of an Organization, you cannot access anything owned by that Organization. Most companies will have a single organization in Humanitec. Larger companies might have different organizations for different divisions. All Organizations are independent from each other and cannot share access to applications.
It is possible to control access to Organizations via the Humanitec RBAC system. Members of the organization can be granted the following roles:
Member- the most basic level of access to an Organization,Manager- for managing users in an Organization and creating new Applications andAdministrator- for complete access to the entire Organization.
A Humanitec Application is collection of related Kubernetes workloads that run in the same Kubernetes namespace. You may prefer to think of them as "projects", "systems" or "domains" depending on your team's internal conventions. Complex systems consisting of multiple namespaces or even multiple clusters would be represented as multiple Applications in Humanitec.
It is possible to control access to Applications via the Humanitec RBAC system. Members of the organization can be granted the following roles:
Viewer- for read only access to the Application,Developer- for making updates to Application Configuration andOwner- for making updates and also granting access to the Application.
An Environment is a space where an instance of an Application can be deployed. Each Environment maps to a namespace in a Kubernetes cluster containing the Workloads. An Environment also contains any Resources that workloads in the Application have dependencies on.
An Application can be deployed into 1 or more environments. Each environment could contain different versions of code, different configurations or even different sets of resources. Humanitec provides tools to allow individual workloads or even whole environments to be "cloned" to other environments. This allows a systematic way of promoting from one Environment to another. See Application Configuration Management for more detail on how application configuration works in Humanitec.
Environments each have a "type" which can be used to manage and provide access to sets of Environments.
Each Environment has an Environment Type. Environment Types are used to categorise Environments. Common types would be:
development for all Environments developers are allowed to update directly, staging for Environments used to run verification and QA processes before deployment to production and production for Environments that are used by customers.It is possible to control access to Environments based on their Environment Type. For example, developers may have permission to make manual deployments into environments of type
development but not into environments of type production.A Deployment represents an actual change to the state of an Environment. Humanitec keeps track of every Deployment that happens in an Environment and the state of the Application Configuration at the time of the deployment. This provides an audit history of changes in an Environment and also allows for rolling back Application Configuration to previously deployed states.
The state of Application Configuration is stored in Deployment Set. Humanitec provides a rich set of tools for comparing and describing changes to Deployment sets allowing for use cases such as:
- Identifying the material differences between 2 deployments in the same or different environments,
- Applying a consistent set of updates across different environments and
- rolling back an environment to a previously deployed state.
Last modified 6mo ago