-
Notifications
You must be signed in to change notification settings - Fork 146
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Review the migration steps up to the tenant provisioning part (includ…
…ed).
- Loading branch information
1 parent
efc5d88
commit 2142170
Showing
1 changed file
with
39 additions
and
22 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -115,15 +115,15 @@ The following CLI commands were updated to become tenant-aware: | |
|
|
||
| The single-tenant commands for DB migration and pre-population used to be: | ||
|
|
||
| ```sh | ||
| ```shell | ||
| ./stellar-disbursement-platform db migrate up # ⚠️ DECOMISSIONED! | ||
| ./stellar-disbursement-platform db auth migrate up # ⚠️ NEEDS A TENANT-AWARE FLAG! | ||
| ./stellar-disbursement-platform db setup-for-network # ⚠️ NEEDS A TENANT-AWARE FLAG! | ||
| ``` | ||
|
|
||
| The new multi-tenant commands are: | ||
|
|
||
| ```sh | ||
| ```shell | ||
| ./stellar-disbursement-platform db admin migrate up | ||
| ./stellar-disbursement-platform db tss migrate up | ||
| ./stellar-disbursement-platform db auth migrate up --all | ||
|
|
@@ -139,7 +139,7 @@ Please notice that some commands require a tenant-aware flag, that can be either | |
|
|
||
| The ensure command was updated from using the `--num-channel-accounts-ensure` flag to using a positional argument: | ||
|
|
||
| ```sh | ||
| ```shell | ||
| ./stellar-disbursement-platform channel-accounts ensure --num-channel-accounts-ensure 1 # OLD WAY | ||
| ./stellar-disbursement-platform channel-accounts ensure 1 # NEW WAY | ||
| ``` | ||
|
|
@@ -156,33 +156,41 @@ In the updated version, the database structure has been revised to accommodate m | |
|
|
||
| These changes allow for the isolation of tenant data per schema, ensuring that each tenant's data is kept separate from other tenants. | ||
|
|
||
| ## Migration Process | ||
| ## Step-by-Step Migration Guide | ||
|
|
||
| ### Create the New database | ||
|
|
||
| Create a brand new database to be used by the multi-tenant version of the SDP. This database will eventually be populated with the existing single-tenant data. | ||
|
|
||
| ### Deploying a new version | ||
| ### Deploy the New Version | ||
|
|
||
| To transaction to a multi-tenant setup, deploy the latest version of the SDP 2.x.x. This deployment can be achieved through various methods depending on your infrastructure, such as updating to a new Docker image, utilizing the latest Helm chart for Kubernetes deployments, etc. | ||
| To transaction to a multi-tenant setup, deploy the latest version of the SDP `2+` version. If you're using helm charts, you can get the helm chart from the [SDP Helm Chart repository](https://github.com/stellar/helm-charts/pull/80). | ||
|
|
||
| ### Executing Database Migrations | ||
| ### Executing Initial Database Migrations | ||
|
|
||
| Following the deployment of the new SDP, the next step is to perform **database migrations** to align the database structure with the multi-tenant requirements. | ||
| Following the deployment of the multi-tenant SDP, the next step is to perform the initial **database migrations**. It does not include the tenant-specific tables yet, they will be created later. | ||
|
|
||
| Migration Commands: | ||
|
|
||
| <CodeExample> | ||
|
|
||
| ```bash | ||
| ```sh | ||
| ./stellar-disbursement-platform db admin migrate up | ||
| ./stellar-disbursement-platform db tss migrate up | ||
| ``` | ||
|
|
||
| </CodeExample> | ||
|
|
||
| These commands will create the tenant admin tables on the **public** schema and the Transaction Submitter Service tables on the **tss** schema, respectively. | ||
| > TODO: rename public to admin after https://stellarorg.atlassian.net/browse/SDP-1147 is done. | ||
| These commands will create the tenant admin tables on the **public** (soon to be **admin**) schema and the Transaction Submitter Service tables on the **tss** schema, respectively. | ||
|
|
||
| ### New Tenant Provisioning Process | ||
|
|
||
| After successfully applying the database migrations, the next step is to provision a new tenant. This is achieved by making an HTTP request to the **Admin API**. | ||
|
|
||
| Be aware that it will provision the tenants with all the per-tenant migrations complete. We will later revert the new migrations (not present in multi-tenant), and re-execute them after we import the data from the single-tenant. | ||
|
|
||
| #### Starting the SDP API server | ||
|
|
||
| To facilitate tenant provisioning, initiate the SDP Server using the command: | ||
|
|
@@ -195,37 +203,46 @@ To facilitate tenant provisioning, initiate the SDP Server using the command: | |
|
|
||
| </CodeExample> | ||
|
|
||
| #### Accessing the Admin API | ||
| #### Conecting to the Admin API | ||
|
|
||
| - **Port Configuration**: The Admin API is accessible on port `8003` by default. This port setting can be adjusted by altering the `ADMIN_PORT` environment variable. | ||
| - **Authentication**: Admin API employs Basic Authentication for securing access. To authenticate, concatenate the administrator’s account name (set in the `ADMIN_ACCOUNT` environment variable) and the Admin API KEy (specified in the `ADMIN_API_KEY` environment variable). This concatenated string must then be base64 encoded to create the Authorization Header. | ||
| - **API port**: The Admin API is accessible on port `8003` by default. This port setting can be adjusted by altering the `ADMIN_PORT` environment variable. | ||
| - **Authentication**: Admin API employs Basic Authentication for securing access. To authenticate, populate the request "Authorization" header with `"Authorization: Basic ${Base64(ADMIN_ACCOUNT:ADMIN_API_KEY)}"`. | ||
|
|
||
| Shell script example of creating a tenant through the Admin API: | ||
| Here's a shell script that can be used to create a tenant through the Admin API: | ||
|
|
||
| <CodeExample> | ||
|
|
||
| ```shell | ||
| adminAccount="SDP-admin" | ||
| adminApiKey="api_key_1234567890" | ||
| encodedCredentials=$(echo -n "$adminAccount:$adminApiKey" | base64) | ||
| AuthHeader="Authorization: Basic $encodedCredentials" | ||
| ADMIN_ACCOUNT="SDP-admin" | ||
| ADMIN_API_KEY="api_key_1234567890" | ||
| basicAuthCredentials=$(echo -n "$ADMIN_ACCOUNT:$ADMIN_API_KEY" | base64) | ||
| AuthHeader="Authorization: Basic $basicAuthCredentials" | ||
|
|
||
| tenant="bluecorp" | ||
| baseURL="http://$tenant.stellar.local:8000" | ||
| sdpUIBaseURL="http://$tenant.stellar.local:3000" | ||
| ownerEmail="owner@$tenant.org" | ||
|
|
||
| curl -X POST https://bluecorp.backend.com:8003/tenants \ | ||
| -H "Content-Type: application/json" \ | ||
| -H "$AuthHeader" \ | ||
| -d '{ | ||
| "name": "bluecorp", | ||
| "name": "'"$tenant"'", | ||
| "organization_name": "Blue Corp", | ||
| "email_sender_type": "DRY_RUN", | ||
| "sms_sender_type": "DRY_RUN", | ||
| "base_url": "https://bluecorp.backend.com", | ||
| "sdp_ui_base_url": "https://bluecorp.com", | ||
| "owner_email": "[email protected]", | ||
| "base_url": "'"$baseURL"'", | ||
| "sdp_ui_base_url": "'"$sdpUIBaseURL"'", | ||
| "owner_email": "'"$ownerEmail"'", | ||
| "owner_first_name": "john", | ||
| "owner_last_name": "doe" | ||
| }' | ||
| ``` | ||
|
|
||
| > TODO: review configurations: | ||
| > - are `sms_sender_type` and `email_sender_type` needed/used? | ||
| > - were `base_url` and `sdp_ui_base_url` removed from the envs? | ||
| </CodeExample> | ||
|
|
||
| In the SDP Multi-tenant, certain configurations previously managed through environment variables in the single-tenant setup are now stored within the **tenants** table in the admin schema. This change allows each tenant to have its own custom configuration. | ||
|
|
||