Latest Dockhand from YAML anyone?

Apps and Virtualization
1

Does anyone use Dockhand and installed it with a custom YAML instead of the ix catalog? I watched some videos and want to try this. The ix version is 1.0.3 and the latest on the homepage is 1.0.12, seems like the pace of development is quite fast. I created a dataset /mnt/apps/config/dockhand and a dataset /mnt/apps/config/stacks. Both with the apps-preset (or should I move “stacks” above /config to /mnt/apps ? Does it matter?)

What would be the correct YAML to install the latest dockhand using these paths?

For anyone interested https://www.youtube.com/watch?v=F7aXfYGf5q4 piqued my curiosity

2

Haven’t tested dockand, but just saw a video about it today myself. I may give it a try on the weekend.
Regarding the yaml you should use: Propably the one without the postgress db. For a deployment in a homelab the one without prostgress should suffice

3

I followed the same video and now use this on 2 x truenas and 1 x flatcar server. As of 1.0.13 dockhand is a lot less buggy and quite useable.

Firstly i like to run apps each in their own dataset so that the permissions, snapshots, replication etc can be independent of each other. The default layout/functionality of dockhand makes you create an environment name and then creates new stacks inside itself under ./dockhand_data/stacks/environment_name/app_name. You can enhance this though with an extra bind mount where you can have another location of stacks outside of this tree (in my case the old dockge stacks). Then you can adopt those stacks to be managed by dockhand.

services:
  dockhand:
    image: fnsys/dockhand:latest
    container_name: dockhand
    restart: unless-stopped
    ports:
      - 3077:3000
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /mnt/flash-2/apps/dockhand/dockhand_data:/app/data
      - /mnt/flash-2/apps:/mnt/flash-2/apps # this bind mount is to a dataset containing my apps in sub datasets
networks: {}
  • I use port 3077 only as my 3000 is already taken.
  • The 3rd volume mount is the mapping of my existing stacks dataset into the dockhand container. I choose to keep the naming the same inside the container as it reminds me where it is on the outside but you could rename/relocate this.
  • dockhand can be in its own dataset under apps or wherever you like.
  • dockhand can not update and restart itself (yet) unlike dockge.

Once in dockhand you can adopt the stacks in the web ui adopt button and browsing the third mount. No reason you could not have more mounts if needed.

Re your question in your specific layout should I move “stacks” above /config to /mnt/apps ? Does it matter?
In my current usage you can see I have it set above with dockhand itself inside the stacks just like the other apps. It might affect some future auto self update but i doubt it.

I am finding it a good management tool as the bugs are getting ironed out.

4

Didn’t watch the video. Can you guys please say in a nutshell why it’s better than portainer?

Last time I spent time watching the video about another “portainer killer” (dockge), it turned out to be worse in every aspect (except being lightweight, I guess).

5

Dockhand is up-to-date in Truenas apps.

6

IMO if you use and enjoy portainer don’t think there’s any real reason to move off other than curiosity.
Dockhand looks/feels pretty sleek, but considering just how new it is I wouldn’t readily recommend migrating.

That being said, I enjoy things breaking, so:

image
image930×131 22.4 KB

This is the compose I use:

services:
  dockhand:
    container_name: dockhand
    environment:
      - DATA_DIR=/mnt/path/to/dockhand_data
    image: fnsys/dockhand:latest
    labels:
      - com.centurylinklabs.watchtower.enable=true
    ports:
      - '50283:3000'
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /mnt/path/to/dockhand_data:/mnt/path/to/dockhand_data

I’ve run into a couple annoying issues with it already which have required me to go into CLI and docker compose down --remove-orphans && docker compose up -d after it borked a container image update then couldn’t bring the containers online because the addresses were “in use”.

Overall though it seems quite well built so I expect these things will get ironed out over time. The Github repo is only a month old!

IMO it is not a “portainer killer” by any means, different tools for different jobs. Who knows though, time will tell :slight_smile:

1 Like
7

I agree that it is just horses for courses. Dockge is a bit too light in that it can manage little but the stacks. Portainer vs dockhand very similar - personal preference with which way you go.

I always start my preferred docker managemnet app first time with CLI docker compose up -d and restart : unless stopped.. Not quite sure why I would want Truenas ix-app manager managing a docker app that manages docker apps. Is that a bit OCD?

8

thanks for the replys. I will give it a try. It is not important which features are beta or not, it is just my home NAS and I need something to tinker/improve/try :grinning_face_with_smiling_eyes:

9

I am currently in the middle of slow transition from Dockge to Dockhand.

I considered Arcane previously, but after discovering Dockhand it seems like better choice.

I also compared with Portainer and Dockhand seems to be more easy to use. For example in Stacks tab I can directly stop and restart everything in Dockhand. I cant in Portainer.

Dockhand is new and needs some more testing but the user experience seems really good.

1 Like