1

I have a running container on a remote host. I can ssh this host. I can exec on the running container from the host.

I would like to persist some changes that I make directly on my container files on my local machine. To this aim I need to sync the container files with my local machine. I would be interested in a rsync or sshfs command to do so.

To provide more context, I am trying to find a development flow on a legacy system where I cannot run the container locally. I am using vscode remote extensions to develop on the remote container which works well. Yet my container is orchestrated and can be killed at any moment, I need to persist locally the development changes. Any other idea that could address the development workflow is also welcome.

I thought about creating a volume bridge on the host machine and sync directly from the host to my local machine. However, this is not an option for other reasons.

Benoit P
  • 121
  • 1
    Thanks for providing context, too few people do that. Can you run sshd in your remote container, and expose the ssh port to the host, or is that a security risk? If you can run it, than the situation is the same as for rsync via any jump host, so see e.g. here. Also look into Docker volumes to be able to use persistent storage from containers that can be restarted any time. – dirkt Jul 17 '21 at 05:49
  • This is only for development environment, as long as we do not modify the docker images that will run in production, I guess it does not create any security risk. I'll definitely have a look at the proxy jump. Thanks a lot. As I mentioned at the end of the post, I also tried the Volume approach but that was not satisfactory because I would need to "init" the volume with the container files. Instead mounting the volume overrides my container files with nothing. – Benoit P Jul 18 '21 at 08:01
  • Using a volume only works if the changes that are persisted can be stored in that volume. With vscode source code, this is definitely an option, and possibly even with the executables produced, if you set up the container correctly. If you are required to make changes in the container files themselves, then that doesn't work well (and then I'd also take some time to re-think the whole approach, because the whole point of containers is that they are "immutable" cattle you can redeploy as required). – dirkt Jul 18 '21 at 10:38
  • 1
    @dirkt agreed. The volume approach should be the favored one but is not a short term viable option for now. I managed to execute the desired result using the Jump Host trick. Thanks a lot. – Benoit P Jul 18 '21 at 17:51

0 Answers0