this post was submitted on 02 Sep 2023
29 points (93.9% liked)

Selfhosted

40394 readers
356 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
ruud@lemmy.world
Loki@lemmy.world
CannaVet@lemmy.world
devve@lemmy.world
HybridSarcasm@lemmy.world
HybridSarcasm@lemmy.hybridsarcasm.xyz
29
How to migrate to Docker? (links.hackliberty.org)
submitted 1 year ago by anarchotaoist@links.hackliberty.org to c/selfhosted@lemmy.world
23 comments fedilink hide all child comments
 

Hello! I need a guide on how to migrate data from shared hosting to Docker. All the guides I can find are about migrating docker containers though! I am going to use a PaaS - Caprover which sets up everything. Can I just import my data into the regular filesystem or does the containerisation have sandboxed filesystems? Thanks!

you are viewing a single comment's thread
view the rest of the comments
[–] fmstrat@lemmy.nowsci.com 3 points 1 year ago

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.