sendnrw/netbird-docs
2
0
Fork 0
mirror of https://github.com/netbirdio/docs.git synced 2026-04-16 15:36:36 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fix doc compilation

Browse Source
This commit is contained in:
braginini
2024-10-02 15:05:03 +01:00
parent a5ef0c9b08
commit 2713b0536b
1 changed files with 9 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
src/pages/how-to/db-workload-migration.mdx
View File

@@ -1,4 +1,4 @@
# Streamlining Workload Migration with NetBird: Secure and Efficient Data Transfer
# Workload Migration with NetBird: Secure and Efficient Data Transfer
For DevOps and platform engineering teams, workload migration presents significant challenges, especially when transferring data-intensive applications between different environments or cloud providers. Key challenges include:
@@ -73,8 +73,6 @@ INSERT INTO employees (name, department) VALUES
('John Doe', 'IT'),
('Jane Smith', 'HR'),
('Mike Johnson', 'Sales');
\q
```
Verify the table was created by printing it to the terminal:
@@ -165,7 +163,7 @@ With the on-premise environment ready, you can install NetBird on the destinatio
Login to NetBird and navigate to `Peers`. Ensure the source instance, the one hosting the database, is connected.
![NetBird Local Peer](/public/docs-static/img/how-to-guides/db-workload-migration/workload-migration-01.png)
![NetBird Local Peer](/docs-static/img/how-to-guides/db-workload-migration/workload-migration-01.png)
Next, generate a setup key for enhanced security when connecting your remote workload to the NetBird network:
@@ -174,7 +172,7 @@ Next, generate a setup key for enhanced security when connecting your remote wor
* Enter a descriptive name for the setup key (e.g., "Remote Workload 01"). Also, set an expiration date and define auto-assigned groups (if required). You can find [more information regarding setup key options in the documentation](https://docs.netbird.io/how-to/register-machines-using-setup-keys).
* Copy the generated key since you'll need it shortly
![NetBird Creating Setup Key](/public/docs-static/img/how-to-guides/db-workload-migration/workload-migration-02.png)
![NetBird Creating Setup Key](/docs-static/img/how-to-guides/db-workload-migration/workload-migration-02.png)
To install the NetBird agent on the remote instance, run the following command:
@@ -222,7 +220,7 @@ sudo netbird status
The expected output is similar to the following:
```output
```bash
OS: linux/amd64
Daemon version: 0.29.0
CLI version: 0.29.0
@@ -240,7 +238,7 @@ Peers count: 0/0 Connected
If everything goes as expected, you will see your remote workload in NetBird's `Peers` dashboard.
![NetBird Peers Network](/public/docs-static/img/how-to-guides/db-workload-migration/workload-migration-03.png)
![NetBird Peers Network](/docs-static/img/how-to-guides/db-workload-migration/workload-migration-03.png)
## 3. Setting Up NetBird's Access Control for Secure Data Transfer
@@ -261,7 +259,7 @@ For this use case, we disabled the `Default` policy and created the following on
This policy restricts access to the local environment where the database is running by only allowing the members of the group `Remote Workloads` to connect.
![NetBird Access Policy](/public/docs-static/img/how-to-guides/db-workload-migration/workload-migration-04.png)
![NetBird Access Policy](/docs-static/img/how-to-guides/db-workload-migration/workload-migration-04.png)
The next step is to assign peers to their respective groups. To add the remote instance to the `Remote Workloads` group:
@@ -269,14 +267,14 @@ The next step is to assign peers to their respective groups. To add the remote i
* Click on `remote-workload` (or any name you gave to the remote instance)
* Find the `Assigned Groups` field and select `Remote Workloads` from the dropdown list.
![NetBird Remote Peer](/public/docs-static/img/how-to-guides/db-workload-migration/workload-migration-05.png)
![NetBird Remote Peer](/docs-static/img/how-to-guides/db-workload-migration/workload-migration-05.png)
Follow a similar procedure to assign your local machine to the `On-Premise-DB` group:
* Locate and click on the local peer
* Find the `Assigned Groups` field and select `On-Premise-DB` from the dropdown list.
![NetBird Local User Peer](/public/docs-static/img/how-to-guides/db-workload-migration/workload-migration-06.png)
![NetBird Local User Peer](/docs-static/img/how-to-guides/db-workload-migration/workload-migration-06.png)
Your network configuration is complete, enabling secure communication between the remote instance and your local machine via an encrypted WireGuard tunnel. However, additional adjustments are necessary to finalize the workload migration process.
@@ -327,7 +325,7 @@ These changes allow PostgreSQL to listen on all interfaces and accept connection
To complete the migration, deploy your workload to the remote instance by recreating the local setup: establish a Python virtual environment, install the `psycopg2-binary` library, and create `employee_workload.py`. However, in the Python code, you must update the `host` parameter, replacing `localhost` with the NetBird-assigned IP address of the remote instance. You can find this IP address in your peers' list on your NetBird dashboard.
![NetBird IP Addresses](/public/docs-static/img/workload-migration/workload-migration-07.png)
![NetBird IP Addresses](/docs-static/img/workload-migration/workload-migration-07.png)
Optionally, you can change the label `(On-Premise)` with `(Remote)` as mentioned earlier. The Python code should look similar to this: