I’ll try to answer the specific question here about importing data and sandboxing. You wouldn’t have to sandbox, but it’s a good idea. If we think of a Docker container as an “encapsulated version of the host”, then let’s say you have:

• Service A running on your cloud
• Requires apt-get install -y this that and the other to run
• Uses data in /data/my-stuff
• Service B running on your cloud
• Requires apt-get install -y other stuff to run
• Uses data in /data/my-other-stuff

In the cloud, the Service A data can be accessed by Service B, increasing the attack vector of a leak. In Docker, you could move all your data from the cloud to your server:

# On cloud
cd /
tar cvfz data.tgz data
# On local server
mkdir /local/server/
cd /local/server
tar xvfz /tmp/data.tgz ./
# Now you have /local/server/data as a copy

You’re Dockerfile for Service A would be something like:

FROM ubuntu
RUN apt-get install -y this that and the other
RUN whatever to install Service A
CMD whatever to run

You’re Dockerfile for Service B would be something like:

FROM ubuntu
RUN apt-get install -y other stuff
RUN whatever to install Service B
CMD whatever to run

This makes two unique “systems”. Now, in your docker-compose.yml, you could have:

version : '3.8'

services:
  
  service-a:
    image: service-a
    volumes:
      - /local/server/data:/data

  service-b:
    image: service-b
    volumes:
      - /local/server/data:/data

This would make everything look just like the cloud since /local/server/data would be bind mounted to /data in both containers (services). The proper way would be to isolate:

version : '3.8'

services:
  
  service-a:
    image: service-a
    volumes:
      - /local/server/data/my-stuff:/data/my-stuff

  service-b:
    image: service-b
    volumes:
      - /local/server/data/my-other-stuff:/data/my-other-stuff

This way each service only has access to the data it needs.

I hand typed this, so forgive any errors, but hope it helps.