New "easy mode" for Docker coming in v2.1

Announcements
,
28

Thanks - but I do not have an existing docker installation. I have PS running on the desktop now and do not want to touch that with an alpha release. Wanted to try docker which is my ultimate goal to move to.
So, I was looking for a guide for an initial install using the easy docker option.

29

Gotcha!

  1. Set up a new container using photostructure/server:alpha as the repository
  2. Add a mapped directory for the library. The container directory should be ‘/ps/library’. The host directory can be whatever directory you want on your host machine.
  3. Start the container

There may be some particulars depending on your host, but this bare-minimum should get you pretty close, if not all the way there!

30

@madmari : @tkohhh is correct: the result of “docker easy mode” is that instead of 4 required bind mounts, you just give the container a single bind-mount to /ps/library, and PhotoStructure will put the other stuff (like cache and logs) into a subdirectory within that bind mount.

So, in other words, the docker run command becomes just

docker run \
  --name photostructure \
  --detach \
  --restart on-failure \
  --stop-timeout 120 \
  --publish 1787:1787 \
  -e TZ="$TZ" \
  -e UID=$(id -u) \
  -e GID=$(id -g) \
  -v /path/on/your/nas/to/your/photostructure/library:/ps/library \
  -v /path/on/your/nas/to/your/photos:/photos \
  photostructure/server:v2.1.0-alpha.1

Be sure to change /path/on/your/nas/to/your/photostructure/library and /path/on/your/nas/to/your/photos to suit your setup.

Note that there was a docker tagging bug found yesterday, so :alpha isn’t pulling the correct image. After I get that fixed (probably today), please change photostructure/server:v2.1.0-alpha.1 to photostructure/server:alpha.

Once v2.1:stable is released, I will update the docker and docker-compose instructions.

1 Like
31

Do you have an estimate as to how large the cache dir needs to be?

Is there a reason that it can’t be an NFSv4 mount?

32

Just to clarify here, when @mrm is referring to a cache directory, he’s talking about the “temp” directory for photostucture, not the Unraid cache disk. If you’re using Unraid in a standard way*, you’re not going to have any problems, even if you don’t have a cache disk (although it might run a little slow if you don’t use a cache disk).

As for the sizing of the library directory, for my collection of 21,000 photos, my library is 12.2GB. That’s about 630KB of library size per photo. Your mileage may vary!

*if you use the mergerfs or unionfs plugin, or if you use Unassigned Devices to attach a network drive, then you’ll have to be careful about using those directories in Photostructure.

edit: sorry, I got my wires crossed and was thinking this was an Unraid question!

33

Great question: I moved my answer to this new topic (so it’d be easier to find later):

34

What is the intent behind having the new subfolders for cache, docker-config, and all the other folders within .photostructure be a hidden folder? If we’re already specifying a location for /ps/library, why would the only subdirectory content (other than the .uuid file) in that location need to default to hidden?

It just adds an extra flag requirement of -a on an ls from my perspective where if I’m looking for something.

Going further, couldn’t all of the content that is already living within .photostructure just be moved to up to live adjacent to the /ps/library/.uuid file within /ps/library - else we’re just adding one layer of directory structure.

If /ps/tmp, /ps/config, or /ps/logs are defined, used those. Else, fall back to (respectively) /ps/library/cache-$UID, /ps/library/docker-config, and /ps/library/logs.

35

I’m hoping that for most users these folders are totally ignorable “implementation details”.

Are you thinking I could move all the directories in .photostructure up one level and have them hidden?

I’m a bit hesitant to have them not be hidden, just to avoid customer support issues when people delete their database or previews directory because “it’s taking up disk space” and they don’t know the provenance of those files.

(But I agree with you, there may be better defaults than just cramming everything into .photostructure/)

36

Moreso I was hoping things could be either unhidden, or unhidden and moved up a level. That said, perhaps sensitive things could be moved up a level and remain hidden, but others could be moved up and also unhidden?

Eg: Hide docker config. Don’t hide logs. You’d need to make the call for each directory/folder.

It does feel like it could be a win though, because right now my directory structure (similar to others, I imagine) is ~/docker/photostructure/.photostructure/<content>

A bunch of other services I have running dump stuff directly into the equivalent of /ps/config or /ps/library at the top level, and so are only two levels deep from my parent docker folder.

Edit: I could also bind mount into the .photostructure subfolder directly, but not sure of the consequences within the app if I do that as I’d be pointing both /ps/library and /ps/library/.photostructure to the same location.

37

I suspect the people that would do this are running Photostructure on Windows or Mac, not docker.

The hidden folder doesn’t bother me at all. But it’s absence wouldn’t bother me either. shrug

38

OK:

for i in logs docker-config ; do 
  mkdir -p ~/docker/photostructure/$i
done

The next build will use those directories if they exist.

Will that work for you?

39

That was moreso an example based on me running an ls -ahl on the folder and choosing two sample directories. Personally, while troubleshooting or otherwise I’d often jump into the models folder to dig out the database.

I guess what I’m saying is, don’t move only 1 or 2 folders up to check if they exist directly at the root level of /ps/library's bind mount. That would just add a lot of conditionals to the code. Just leave things as they are right now, or if you’re so inclined, move everything up a level but hide things you think are too sensitive to not be hidden.

To @tkohhh’s point though, I doubt the people setting this up on docker-compose are the ones who would be accidentally deleting folder structure to free up disk space. It feels like the equivalent of the Media, Metadata, Plug-ins, Plug-in Support, Codecs, etc. folders within the Plex docker image. None of them are hidden, and there is vibrant community discussion on the forums as to what is safe to delete, if any, when migrating installations of Plex.

(Admittedly this is not the best overall example however, since Plex buries everything 3 folders down in Library/Application Support/Plex Media Server, but they aren’t going to take my suggestions to fix it on the forums anyway.)

40

Hmm, that seems to indicate the stash-everything-away approach might result in less drama/confusion?

Meh, I think it’s OK?

export function defaultLogDir() {
 if (isDocker()) {
    return firstDirOrFail(
      [
        "/ps/logs",
        "/ps/library/logs", // < added line
        {
          dir: "/ps/library/.photostructure/logs",
          parentRequiredToExist: "/ps/library"
        }
      ],
      "logs"
    )
  }
41

Just chiming in, I also find the hidden folder to be uneccessary and a mild annoyance. I would welcome this change.

I get the intend behind it, but I think a README in the root folder that says “Don’t manually mess with these files or else” would be sufficient CYA.

EDIT: frankly, the more I think about it, I think the hidden folder might generate another kind of support call. Someone might just delete the folder thinking it’s empty. I mean, your use case is for user not sophisticated enough to even look for hidden folders, right?

42

This really depends on the setup. For instance, if you export the host directory via SMB (as is common in Unraid) and then pull that directory up in Windows, then the dot prefix doesn’t render the folder as hidden… it just looks like any other directory.

That said, if we’re talking about ideal (for the docker version), my preference would be to have my host directory be ../appdata/photostructure/ and then have everything that’s currently in .photostructure in that folder.

But again, I’m pretty meh about it either way.

43

Thanks for sharing, you guys. I think you’re right, @adamf about adding complexity. I’ve reverted that change.

I suspect (most? many?) people won’t care where these directories go–they just want the thing to work.

If you do care, you can either set up the bind-mount to point where ever you want, or set PS_LOG_DIR, PS_CONFIG_DIR, PS_CACHE_DIR (and even PS_LIBRARY_DIR) to whatever sparks joy.

As far as making directories visible or moving the defaults: I want to maintain cross-OS and cross-machine library portability. If the library is moved to a Windows or macOS box which doesn’t use the same system cache or system logging directories, it’s no big deal–the library contents stay the same. Conversely, we don’t want the system configuration to be shared between editions, so it’s fine to adjust the docker-config heuristics–PhotoStructure for Node and PhotoStructure for Desktops won’t look at any docker-config directory, so we’re good there.

44

Soo… where does that leave everything? Back to current behavior, or is the folder not hidden at least?

45

I rolled back the changes after

  1. I realized everything was already configurable, and complications here would lead to confusion
  2. I don’t want to write a automatically-adopt-different-folders-upgrader.
  3. Any folder structure won’t make everyone happy. As everything is already customizable via settings, you already have the flexibility to put folders right where you want them.
46

I’m trying to minimize the number of settings required outside of defaults while also taking advantage of the new simple docker bind mount mode which, thankfully, has the potential to reduce my bind mounts from 4 down to 1.

I think I settled on 2 bind mounts though for the docker directory. Here’s where I am. Do you foresee any issues with this, and also any possible improvements?

(Commented lines for testing)

  photostructure:
    image: photostructure/server:alpha
    container_name: photostructure
    restart: unless-stopped
    networks:
      - $TRAEFIK_NETWORK
    security_opt:
      - no-new-privileges:true
    ports:
      - 1787:1787
    runtime: nvidia
    stop_grace_period: 2m
    volumes:
      - $MEDIADIR/photos:/photos
      - $DOCKERDIR/photostructure:/ps/library
      - $DOCKERDIR/photostructure:/ps/library/.photostructure
    environment:
      - TZ
      - PUID
      - PGID
      - UMASK=002
      - NVIDIA_VISIBLE_DEVICES=all
      - PS_LOG_LEVEL=warn
      #- PS_START_PAUSED=true
      - PS_ORIGINALS_DIR=/photos
      - PS_MAX_ASSET_FILE_SIZE_BYTES=0
      #- PS_TRANSCODE_VIDEOS=false
      - PS_ENABLE_EMPTY_TRASH=true
      - PS_ENABLE_REMOVE_ASSETS=true
      - PS_ASSET_PATHNAME_FORMAT=y/MM/y-MM-dd/BASE
      - PS_DISABLED_HELMET_MIDDLEWARE=all
      #- PS_FFMPEG_HWACCEL=auto
47

Interesting! Is the first bind mount really neccessary? I think I am going to try this…