You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Whenever we organize local development environment we take care of such requirements as:
ability to have OS-indepdent set-up
ability to share dev environments
ability to backup workspace seamlessly
Devcontainers are very nice tool helping us to reach these goals, however the problem is - how to organize the super-workspace managing all the projects in a best way?
1. Windows workspace
As a developer I used to have Windows 11 due to certain software I need to operate with. At the same time I'd like to develop inside devcontainers to have an OS-independent project setup. I also noticed that it is very slow to use Windows file system for large projects. npm install and other scenarios with intensive I/O workload work much faster in Linux. Luckily we have WSL2 now which solves the problem
2. WSL workspace
The fastest way to start developing in WSL is to clone project there and to open it via devcontainer. However in this case we receive another problem. All the code is stored inside the distro and if it's broken or even worse unregistered - then all your data may be lost.
3. Workspace in a virtual disk mounted to WSL
This is where I am now. I solved the problem of sharing workspace among distros and at same time having an ability to unregister distro without the risk of loosing the actual code. For that puprpose I've created an external virtual drive which I mount on system startup with a command like:
# Mount the VHD
wsl --mount --vhd "$PSScriptRoot\ws.vhdx" --partition 1 --name workspace
This approach allows me to have a Linux workspace stored in the external ext4 virtual drive. However backup problem is not solved. Also it requires some manual actions to set it up.
What is the proposal?
4. Using docker volume instead of the virtual disk
Imagine if instead of creating a virtual disk we create a docker volume. To be able to mount this volume to WSL we need to have a running container.
What if along with WSL integration checkbox we will have an option to choose volumes we would like to mount directly to WSL?
Docker is already mounting internal volumes. Then imagine how simple would be just to follow these steps:
Create a new docker volume ( CLI or GUI ) docker create volume workspace
Configure volume as "WSL integration" volume
Consume volume in WSL via path like /mnt/wsl/docker/volumes/workspace
By doing so - we'll get the ability to set up periodic backups via available export feature.
What do you think of this idea? Does it make any sense? Do you have better proposals may be?
Thanks!
The text was updated successfully, but these errors were encountered:
Why?
Whenever we organize local development environment we take care of such requirements as:
Devcontainers are very nice tool helping us to reach these goals, however the problem is - how to organize the super-workspace managing all the projects in a best way?
1. Windows workspace
As a developer I used to have Windows 11 due to certain software I need to operate with. At the same time I'd like to develop inside devcontainers to have an OS-independent project setup. I also noticed that it is very slow to use Windows file system for large projects. npm install and other scenarios with intensive I/O workload work much faster in Linux. Luckily we have WSL2 now which solves the problem
2. WSL workspace
The fastest way to start developing in WSL is to clone project there and to open it via devcontainer. However in this case we receive another problem. All the code is stored inside the distro and if it's broken or even worse unregistered - then all your data may be lost.
3. Workspace in a virtual disk mounted to WSL
This is where I am now. I solved the problem of sharing workspace among distros and at same time having an ability to unregister distro without the risk of loosing the actual code. For that puprpose I've created an external virtual drive which I mount on system startup with a command like:
This approach allows me to have a Linux workspace stored in the external ext4 virtual drive. However backup problem is not solved. Also it requires some manual actions to set it up.
What is the proposal?
4. Using docker volume instead of the virtual disk
Imagine if instead of creating a virtual disk we create a docker volume. To be able to mount this volume to WSL we need to have a running container.
What if along with WSL integration checkbox we will have an option to choose volumes we would like to mount directly to WSL?
Docker is already mounting internal volumes. Then imagine how simple would be just to follow these steps:
docker create volume workspace
By doing so - we'll get the ability to set up periodic backups via available export feature.
What do you think of this idea? Does it make any sense? Do you have better proposals may be?
Thanks!
The text was updated successfully, but these errors were encountered: