SODEW/sodew-bash-main/docs/transfer.md

KUBE  /  Transfer sites

Transfer sites

Note

In progress...

• Transfer via console
• Transfer via plugin Wordpress
• Workflow 1. Cloning a website via the WordPress plugin
• Workflow 2. Cloning websites to SODEW servers via the WordPress plugin
• Workflow 3. Detailed description of the process

Transfer via console:

sudo kube.sh --worker task </path/to/configFile> [domain]

Configuration analysis.

Example:

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), 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:

[
"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:

<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)

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.

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.

flowchart LR;
  US[[User sites...]]
  SW[[Server-workers...]]
  API(api.sodew.ai)

  US -->|tasks...| API -->|tasks...| SW

Workflow 3. Detailed description of the process.

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