smazani
This commit is contained in:
@@ -1,214 +0,0 @@
|
||||
[KUBE](../README.md) / Transfer sites
|
||||
|
||||
# Transfer sites
|
||||
|
||||
> [!NOTE]
|
||||
> In progress...
|
||||
|
||||
- [Transfer via console](#transfer-via-console)
|
||||
- [Transfer via plugin Wordpress](#transfer-via-plugin-worpress)
|
||||
- [Workflow 1. Cloning a website via the WordPress plugin](#workflow-1-cloning-a-website-via-the-wordpress-plugin)
|
||||
- [Workflow 2. Cloning websites to SODEW servers via the WordPress plugin](#workflow-2-cloning-websites-to-sodew-servers-via-the-wordpress-plugin)
|
||||
- [Workflow 3. Detailed description of the process](#workflow-3-detailed-description-of-the-process)
|
||||
|
||||
## Transfer via console:
|
||||
|
||||
```bash
|
||||
sudo kube.sh --worker task </path/to/configFile> [domain]
|
||||
```
|
||||
|
||||
### Configuration analysis.
|
||||
|
||||
Example:
|
||||
|
||||
```ini
|
||||
action=test
|
||||
files_url=https://wp.krumax.cz/transfer_36b91e68-53d3-49ac-922a-0031e664125b/2b3d170e-9f50-435c-b189-b8c3a45cbb8a.zip
|
||||
database_url=https://wp.krumax.cz/transfer_36b91e68-53d3-49ac-922a-0031e664125b/2b3d170e-9f50-435c-b189-b8c3a45cbb8a.sql.zip
|
||||
domain=new.domain.com
|
||||
status=new
|
||||
```
|
||||
|
||||
Where:
|
||||
|
||||
* `action` — the main operation (`copy`/`test`/`migrate`/...)
|
||||
* `files_url` — link to the files archive
|
||||
* `database_url` — link to the DB archive
|
||||
* `status` — execution status:
|
||||
* `new` - new task
|
||||
* `execution` - in progress
|
||||
* `success` - task completed successfully
|
||||
* `failed` - task failed
|
||||
* `domain` - new domain (optional field)
|
||||
|
||||
> [!NOTE]
|
||||
> Working only action `test` (18.11.2025).
|
||||
|
||||
> [!NOTE]
|
||||
> If a domain is specified in the command call, the domain from the configuration file is ignored.
|
||||
|
||||
> [!NOTE]
|
||||
> If the domain is not specified in the command and not specified in the configuration file, it will be assigned automatically from the available ones (`domainsList`). If none are available, the task fails.
|
||||
|
||||
### Work
|
||||
|
||||
**Stage 1**. Configuration analysis.
|
||||
|
||||
**Stage 2**. Availability check and archive download.
|
||||
|
||||
The download is performed into the folder `<transferPath>/<domain>/`:
|
||||
|
||||
* `<transferPath>/<domain>/<domain>.zip` — files archive
|
||||
* `<transferPath>/<domain>/<domain>.sql.zip` — DB archive
|
||||
|
||||
**Stage 3**. Depending on the task:
|
||||
|
||||
* `test` - A site is created based on the downloaded backup.
|
||||
* `copy` - in progress...
|
||||
* `migrate` - in progress...
|
||||
|
||||
**Stage 4**. The status is changed in the configuration file
|
||||
|
||||
* `success` - upon successful completion of the task
|
||||
* `failed` - upon errors at any stage
|
||||
|
||||
## Transfer via plugin Wordpress
|
||||
|
||||
When using the plugin "SODEW Backup & Transfer" ([https://gitlab.wedos.org/mk250/transfer-plugin](https://gitlab.wedos.org/mk250/transfer-plugin)), it is possible to copy a site to SODEW hosting.
|
||||
|
||||
### Preparation
|
||||
|
||||
**Stage 1**. Create a full site backup in the plugin.
|
||||
|
||||
**Stage 2**. Create a task "Launch a copy of the website on SODEW hosting".
|
||||
|
||||
### Work
|
||||
|
||||
**Stage 1**. Sending a request to create a copy of the site for testing to `api.sodew.ai`. Request parameters:
|
||||
|
||||
* `action` – selected action
|
||||
* `transfer_id` – plugin identifier
|
||||
* `backup_id` – backup identifier
|
||||
* `base_url` – site URL (WordPress)
|
||||
* `base_path` – base path
|
||||
|
||||
Example:
|
||||
|
||||
```json
|
||||
[
|
||||
"action":"test",
|
||||
"transfer_id":"22222222-53d3-49ac-922a-0031e664125b",
|
||||
"backup_id":"33333333-c976-43c2-bdee-d7d6ec21900a",
|
||||
"base_url":"https://wp.us1.com",
|
||||
"base_path":"/usr/www/wp.us1.com",
|
||||
]
|
||||
```
|
||||
|
||||
**Stage 2**. Processing the request on the `api.sodew.ai` side.
|
||||
|
||||
1. Parameter validation
|
||||
2. Preparation and validation of URLs to the backup:
|
||||
```ini
|
||||
<base_url>/transfer_<transfer_id>/<backup_id>.zip
|
||||
<base_url>/transfer_<transfer_id>/<backup_id>.sql.zip
|
||||
```
|
||||
3. Creating a task for Workers
|
||||
|
||||
**Stage 3**. Request from the Worker (agent) to `api.sodew.ai` to obtain a new task and receiving it.
|
||||
The task is assigned to the Worker.
|
||||
|
||||
**Stage 4**. Processing of the `api.sodew.ai` response by the Worker (agent) and creating a task for the `kube.sh` script.
|
||||
|
||||
A task file `<task_id>.task` is created in the `workerTasksPath` folder with the following content:
|
||||
|
||||
* `action` – action
|
||||
* `files_url` – URL to the files archive
|
||||
* `database_url` – URL to the database archive
|
||||
* `domain` – domain (optional)
|
||||
* `status` – new (task status: new)
|
||||
|
||||
**Stage 5**. Launching the `kube.sh` task handler via CRON, searching for new tasks and starting execution of the found new task.
|
||||
|
||||
**Stage 6**. Validation of the task parameters. Checking the availability of backup files. Downloading the backup files. Creating the site. (Detailed: [Transfer](#transfer))
|
||||
|
||||
**Stage 7**. Monitoring of the task execution status by the Worker (agent) and sending reports to `api.sodew.ai`.
|
||||
|
||||
**Stage 8**. Receiving task execution reports from the Worker (agent).
|
||||
|
||||
**Stage 9**. Updating the task execution status on `api.sodew.ai` by the plugin.
|
||||
|
||||
## Workflow 1. Cloning a website via the WordPress plugin.
|
||||
|
||||
```mermaid
|
||||
flowchart TB;
|
||||
|
||||
subgraph SW[Server-worker]
|
||||
WO(Worker-observer<br>CRON)
|
||||
WA(Worker-agent)
|
||||
TP[[workerTasksPath/task_id.task<br>action<br>files_url<br>database_url<br>status=new]]
|
||||
CS[Сopy of user's website]
|
||||
end
|
||||
subgraph API[api.sodew.ai]
|
||||
AT(task_id<br>files_url<br>database_url)
|
||||
end
|
||||
subgraph US[User site]
|
||||
WP(Plugin WP<br>action<br>transfer_id<br>backup_id<br>base_url)
|
||||
end
|
||||
|
||||
WP -->|1. create task<br>check status| AT
|
||||
WA -->|2. get new task<br>send statuses| AT
|
||||
WA -->|3. save new task| TP
|
||||
WO -->|4. executing tasks| TP
|
||||
WO -->|5. load files| US
|
||||
WO -->|6. create site| CS
|
||||
```
|
||||
|
||||
## Workflow 2. Cloning websites to SODEW servers via the WordPress plugin.
|
||||
|
||||
```mermaid
|
||||
flowchart LR;
|
||||
US[[User sites...]]
|
||||
SW[[Server-workers...]]
|
||||
API(api.sodew.ai)
|
||||
|
||||
US -->|tasks...| API -->|tasks...| SW
|
||||
```
|
||||
|
||||
## Workflow 3. Detailed description of the process.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
|
||||
alt task
|
||||
Wordpress plugin ->> api.sodew.ai: new task
|
||||
|
||||
loop every 30sec
|
||||
Wordpress plugin ->> api.sodew.ai: how status task?
|
||||
activate api.sodew.ai
|
||||
api.sodew.ai ->> Wordpress plugin: status task is ...
|
||||
deactivate api.sodew.ai
|
||||
end
|
||||
end
|
||||
|
||||
loop every 30sec
|
||||
Worker-Agent ->> api.sodew.ai: receiving new tasks
|
||||
activate api.sodew.ai
|
||||
api.sodew.ai ->> Worker-Agent: <task>
|
||||
deactivate api.sodew.ai
|
||||
activate Worker-Agent
|
||||
Worker-Agent ->> workerTasksPath: saving a new task <task>
|
||||
deactivate Worker-Agent
|
||||
end
|
||||
|
||||
loop every 15sec
|
||||
Worker-Agent ->> workerTasksPath: reading task statuses
|
||||
activate Worker-Agent
|
||||
Worker-Agent ->> api.sodew.ai: sending task statuses
|
||||
deactivate Worker-Agent
|
||||
end
|
||||
|
||||
loop every 1min
|
||||
Worker-Observer ->> workerTasksPath: get new task
|
||||
Note over Worker-Observer: Execute task...
|
||||
end
|
||||
```
|
||||
Reference in New Issue
Block a user