Application orchestration
How application orchestration works
Application orchestration in Apsara Devops AppStack defines the deployment architecture for applications and supports both Kubernetes and host deployment scenarios. The orchestration logic is as follows:
Apsara Devops AppStack defines application environment deployment configurations based on the desired state. When you deploy an environment, AppStack reads the corresponding orchestration file and replaces placeholders with deployment parameters. This process renders the final YAML file for a Kubernetes deployment or a script for a host deployment. The file or script is then sent to the associated cluster or host to execute the deployment.
Application orchestration: Defines the deployment architecture of an application and supports both Kubernetes YAML and host script deployment architectures.
Orchestration component: In a Kubernetes scenario, a component is an independently deployable resource that corresponds to a Kubernetes YAML file. In a host scenario, a component is an independently deployable service that corresponds to the configuration for one or more software packages and their dependencies.
Placeholder: A fixed location in an application orchestration file where content can be dynamically replaced.
Variable: A key-value pair.
Variable group: A collection of variables.
Application orchestration version: Each time you modify an orchestration file, a new version is generated. This lets you easily review changes and perform rollbacks.
Apsara Devops AppStack provides placeholders and variable groups. You can use placeholders to replace keywords in orchestration files, which lets you create different deployments for multiple environments. AppStack includes common built-in placeholders, and you can also add custom placeholders as needed.
Example scenarios
Use multiple Kubernetes namespaces to isolate multiple environments
In a Kubernetes deployment scenario, non-production environments might share the same Kubernetes cluster. You can use multiple namespaces to isolate these environments, such as `dev` for the development environment and `test` for the staging environment, while the production environment runs on a separate cluster. To do this, replace the value of the `namespace` keyword in the YAML file with the placeholder
{{ .Values.namespace }}. Then, assign the variable${namespace}to this placeholder and set its value to `dev` for the development environment and `test` for the staging environment. When you submit the deployment, variable substitution occurs, and the application is deployed to the specified Kubernetes namespace.Start services on different ports for non-production and production environments
In a host deployment scenario, non-production and production environments may need to start services on different ports. To do this, replace the port number in the host startup script with the placeholder
{{ .Values.port }}. Then, assign the variable${port}to this placeholder and set its value to `8080` for the development environment and `8081` for the staging environment. When you submit the deployment, variable substitution occurs, and the application starts its service on the specified port.
Deployment methods
Apsara Devops AppStack application orchestration supports three deployment methods:
Kubernetes deployment (for cloud-native scenarios). For more information, see Kubernetes deployment orchestration.
Host deployment (for traditional host scenarios). For more information, see Host deployment orchestration.
Kubernetes and host hybrid deployment (for migration scenarios).
When migrating your application architecture, you can add or remove an orchestration method to ensure a smooth migration.
Orchestration configuration changes and environment deployment
Changes to application deployment configurations must be validated in each environment before they are released to the production environment. Apsara Devops AppStack lets you add environment tags when you update an orchestration to identify the modified version. When you deploy to an environment, you can select a specific orchestration version. This prevents unintended changes from affecting other environments, such as the production environment.
The following example uses the `myapp` application to describe the process of changing an orchestration configuration. The `myapp` application is orchestrated using a Kubernetes YAML file and has three environments: test, staging, and production. The initial version is V1, and it needs to be updated to V2 by changing the `containerPort` from 80 to 8080.
In application orchestration, modify the YAML file to generate version V2. After you confirm the changes, tag V2 for the test environment.
Deploy to the test environment and select version V2 for validation.
Deploy the V2 version to the staging environment for verification.
After successful testing and verification, the environment is marked as Staging Environment.
After passing staging verification, it is promoted to the Production Environment.
When you are ready to release to production, a notification indicates that a new version is available. You can then manually create a deployment ticket and select version V2 to release to the production environment.
This completes the process of changing an orchestration configuration, from validation in the test and staging environments to the final release to the production environment.