I have read countless emails and websites on this subject, but just don't seem to be able to find a solution that fits my needs.
I have around 25 LXC on my Proxmox server, many running docker, but all with their own local application storage and configuration files. I prefer to use one LXC per application for simplicity.
My preferred weapon of choice for remote access to the servers to maintain those files is VSCode (don't judge me) as it allows me to manage a central set of SSH configs, shared keys for easy access. However, instead of using Windows VS Code, I'd rather use the web version running it in an LXC, but that doesn't support SSH to other LXC instances, and I just can't seem to get my head around the VSCode server stuff/tunnels etc. to see if that would solve the problem.
I have looked at NFS sharing, but I couldn't determine if it made sense (or was even possible) to install an NFS service in each LXC instance to share the config folders to a single common LXC where I run VS Code.
Now I have tried bind mounts, and stored all of my content on a local drive in proxmox, but then that data is not backed up with the LXC, so versioning, backups and restores don't work either. The same would be true for external NAS servers, I want to keep all the data locally within the LXC.
So to state the two goals clearly....
I want all of my config data to be stored locally within an LXC so it can be backed up and restored with that LXC.
I want those config folders shared and available to another LXC instance running VS Code server so it sees them as local files and manages them as such.
It doesn't seem much to ask, but every solution seems to have a problem that I can't overcome. On windows, I would just use network file sharing, so is Samba / SMB the only realistic way to do this, it doesn't feel like the right solution, but may be the only one that would work.
If there was another way of centrally storing the configuration and application generated files, but still have them backed up by the Proxmox LXC backup process, I would be happy to go for that as well, but that seems a little less practical.
I have around 25 LXC on my Proxmox server, many running docker, but all with their own local application storage and configuration files. I prefer to use one LXC per application for simplicity.
My preferred weapon of choice for remote access to the servers to maintain those files is VSCode (don't judge me) as it allows me to manage a central set of SSH configs, shared keys for easy access. However, instead of using Windows VS Code, I'd rather use the web version running it in an LXC, but that doesn't support SSH to other LXC instances, and I just can't seem to get my head around the VSCode server stuff/tunnels etc. to see if that would solve the problem.
I have looked at NFS sharing, but I couldn't determine if it made sense (or was even possible) to install an NFS service in each LXC instance to share the config folders to a single common LXC where I run VS Code.
Now I have tried bind mounts, and stored all of my content on a local drive in proxmox, but then that data is not backed up with the LXC, so versioning, backups and restores don't work either. The same would be true for external NAS servers, I want to keep all the data locally within the LXC.
So to state the two goals clearly....
I want all of my config data to be stored locally within an LXC so it can be backed up and restored with that LXC.
I want those config folders shared and available to another LXC instance running VS Code server so it sees them as local files and manages them as such.
It doesn't seem much to ask, but every solution seems to have a problem that I can't overcome. On windows, I would just use network file sharing, so is Samba / SMB the only realistic way to do this, it doesn't feel like the right solution, but may be the only one that would work.
If there was another way of centrally storing the configuration and application generated files, but still have them backed up by the Proxmox LXC backup process, I would be happy to go for that as well, but that seems a little less practical.