113 lines
5.5 KiB
Markdown
113 lines
5.5 KiB
Markdown
---
|
|
title: Managing Instances
|
|
linkTitle: Managing Instances
|
|
weight: 50
|
|
description: >
|
|
Managing instances of EDP deployed in OTC
|
|
---
|
|
|
|
## Deployment Strategy
|
|
|
|
The core of the deployment strategy revolves around the primary production EDP
|
|
instance, `edp.buildth.ing`. This instance acts as a centralized control plane
|
|
and code repository, storing all application code, configuration, and deployment
|
|
pipelines. It is generally responsible for orchestrating the deployment and
|
|
updates of most other EDP instances across both production and non-production
|
|
tenants, ensuring consistency and automation.
|
|
|
|
<likec4-view view-id="otcTenants" browser="true"></likec4-view>
|
|
|
|
### Circular Dependency Issue
|
|
|
|
However, a unique circular dependency exists with `observability.buildth.ing`.
|
|
While `edp.buildth.ing` manages most deployments, it cannot manage its _own_
|
|
lifecycle. Attempting to upgrade `edp.buildth.ing` itself through its own
|
|
mechanisms could lead to critical components becoming unavailable during the
|
|
process (e.g., internal container registries going offline), preventing the
|
|
system from restarting successfully. To mitigate this, `edp.buildth.ing` is
|
|
instead deployed and managed by `observability.buildth.ing`, with all its
|
|
essential deployment dependencies located within the observability environment.
|
|
Crucially, git repositories and other resources like container images are
|
|
synchronized from `edp.buildth.ing` to the observability instance, as
|
|
`observability.buildth.ing` itself does not produce artifacts. In turn,
|
|
`edp.buildth.ing` is responsible for deploying and managing
|
|
`observability.buildth.ing` itself. This creates a carefully managed circular
|
|
relationship that ensures both critical components can be deployed and
|
|
maintained effectively without single points of failure related to
|
|
self-management.
|
|
|
|
## Configuration
|
|
|
|
This section outlines the processes for deploying and managing the configuration
|
|
of EDP instances within the Open Telekom Cloud (OTC) environment. Deployments
|
|
are primarily driven by Forgejo Actions and leverage Terraform for
|
|
infrastructure provisioning and lifecycle management, adhering to GitOps
|
|
principles.
|
|
|
|
### Deployment Workflows
|
|
|
|
The lifecycle management of EDP instances is orchestrated through a set of
|
|
dedicated workflows within the `infra-deploy` Forgejo
|
|
[repository](https://edp.buildth.ing/DevFW/infra-deploy), hosted on
|
|
`edp.buildth.ing`. These workflows are designed to emulate the standard
|
|
Terraform lifecycle, offering `plan`, `deploy`, and `destroy` operations.
|
|
|
|
- **Triggering Deployments**: Workflows are manually initiated and require
|
|
explicit configuration of an OTC tenant and an environment to accurately
|
|
target a specific system instance.
|
|
|
|
- **`plan` Workflow**:
|
|
- Executes a dry-run of the proposed deployment.
|
|
- Outputs the detailed `terraform plan`, showing all anticipated
|
|
infrastructure changes.
|
|
- Shows the diff of the configuration that would be applied to the
|
|
`stacks-instances` repository, reflecting changes derived from the `stacks`
|
|
repository.
|
|
|
|
- **`deploy` Workflow**:
|
|
- Utilized for both the initial creation of new EDP instances and subsequent
|
|
updates to existing deployments.
|
|
- For new instance creation, all required configuration fields must be
|
|
populated.
|
|
- **Important Considerations**:
|
|
- Configuration fields explicitly marked as "(INITIAL)" are foundational
|
|
and, once set during the initial deployment, cannot be altered through the
|
|
workflow without manual modification of the underlying Git configuration.
|
|
- Certain changes to the configuration may lead to extensive infrastructure
|
|
redeployments, which could potentially result in data loss if not
|
|
carefully managed and accompanied by appropriate backup strategies.
|
|
|
|
- **`destroy` Workflow**:
|
|
- Initiates the deprovisioning and complete removal of an existing EDP system
|
|
instance from the OTC environment.
|
|
- While the infrastructure is torn down, the corresponding configuration entry
|
|
is intentionally retained within the `stacks-instances` repository for
|
|
historical tracking or potential re-creation.
|
|
|
|
> NOTE: When deploying a new instance of EDP it is bootstrapped with random
|
|
> secrets including admin logins. Initial admin credentials for individual
|
|
> components are printed in workflow output. They can be retrieved from the
|
|
> secrets withing Kubernetes at a later point in time.
|
|
|
|
<a href="../workflow-deploy-form.png" target="_blank">
|
|
<img alt="Deploy workflow form" src="../workflow-deploy-form.png" style="max-width: 300px;" />
|
|
</a>
|
|
|
|
### Configuration Management
|
|
|
|
The configuration for deployed EDP instances is systematically managed across
|
|
several Git repositories to ensure version control, traceability, and adherence
|
|
to GitOps practices.
|
|
|
|
- **Base Configuration**: A foundational configuration entry for each deployed
|
|
system instance is stored directly within the `infra-deploy` repository.
|
|
- **Complete System Configuration**: The comprehensive configuration for a
|
|
system instance, derived from the `stacks` template repository, is maintained
|
|
in the `stacks-instances` repository.
|
|
- **GitOps Synchronization**: ArgoCD continuously monitors the
|
|
`stacks-instances` repository. It automatically detects and synchronizes any
|
|
discrepancies between the desired state defined in Git and the actual state of
|
|
the deployed system within the OTC Kubernetes cluster. The configurations in
|
|
the `stacks-instances` repository are organized by OTC tenant and instance
|
|
name. ArgoCD monitors only the portion of the repository that is relevant to
|
|
its specific instance.
|