What happens if you hit "Deploy"?
Understand in detail how an Internal Developer Platform works and what happens under the hood when you hit "Deploy".
At deployment time Humanitec puts the resources (DBs, cluster, DNS etc.) into the desired state using the concept of infrastructure orchestration. It creates context-specific application configurations in the form of manifests by applying changes of the user to the underlying workload profile. It executes the manifest against the Kubernetes API and wires the services to its dependencies. In this section we are going to explore the exact steps in detail.
Before you deploy, make sure Humanitec has been wired up to your tools and infrastructure. This typically includes:
- Your Kubernetes clusters are connected. So are your CI pipelines and all required external resources such as databases, DNS, or file storage.
- Specific Environment Types have been defined (e.g., development, QA) that define which infrastructure is provisioned or used once you Deploy.
You or your DevOps team connected your Internal Developer Platform to your tools and infrastructure (see Infrastructure Orchestration for all the details). This typically includes:
- Your Kubernetes clusters are connected. So are your CI pipelines and all required external resources such as databases, DNS, or file storage.
- Specific Environment Types have been defined (e.g., development, QA) that define which infrastructure is provisioned or used once you hit the Deploy button.
Also, your application is fully configured (see App Configuration Management for all the details). This typically includes:
- All workloads required for your application have been defined.
- Each workload is configured. This includes things like:
- The specific image to be used is defined.
- All required environment variables are defined (maybe including placeholders for environment-specific environment variables such as specific database connections).
- All required external resources (such as databases) are defined. Check the section Resource Dependencies for more information.
- Your DevOps team defined the workload profile (baseline YAML file) to be used when creating the deployment manifests.
Let's assume you set up a simple application like this:
- Two workloads: one frontend application and one backend service with the following configuration:
- Frontend application: exposed via public URL
- Backend service: a PostgreSQL database
- An environment called Development of type development.
Your application draft (it's a draft since it has not yet been deployed) now looks like this in Humanitec:
If you hit Deploy, the following things are happening:
- 1.Your Internal Developer Platform checks the environment type to be used (development in our example from above).
- 2.From that, it checks which specific resources to use for the new deployment (e.g., which Kubernetes cluster to deploy to, which database server to use).
- 3.Let's assume your environment has never been deployed before...
- 1.Your Internal Developer Platform creates a new namespace within the Kubernetes cluster for the new environment.
- 2.It creates a new PostgreSQL database for the backend service.
- 3.It creates a new subdomain to be used to access your frontend application.
- 4.Your Internal Developer Platform then takes the non-environment-specific configuration for both workloads, adds in the environment-specific configuration (e.g., the specific database and URL to be used), and applies them to the baseline configuration.
- 5.From that, it creates all the required manifests needed to deploy the new environment. These Manifests can be exported.
- 6.In a final step, your Internal Developer Platform will use the manifests to run the deployment and record all deployment logs.
- 7.If defined, your Internal Developer Platform will trigger a webhook once the deployment is finished (e.g., to trigger an automated test run).
Each deployment in Humanitec is stored in a so-called Deployment Set. This way you have a log of all deployments ever tun through your Internal Developer Platform. You can use these logs to recreate the specific deployment later on or to diff it against any other deployment to see the non-environment-specific differences.