running small business in docker but without cloudflare?

[zen85]

Hello Elonen,

i just saw that you added this option:

2. Docker + Cloudflare (make public on the Web)

i would love to have a productive system running in a docker compose but i dont need cloudflare for that? i managed to run the demo in a docker compose container but i am not sure why it should absolutly not used other than for Demo purposes?

[elonen]

Yes, the latest htadmin Docker image can be used with other external reverse proxies as well as Cloudflare. The way it works now is that the test/run-cloudflare.sh starts cloudflared in one Docker containter, and Clapshot in another. Technically, cloudflared in this setup is an HTTPS reverse proxy that just happens to delegate its stuff to the could. You could very well replace it with a local Nginx if you have a way to update the HTTPS cert on it (Let's Encrypt, most likely). Reading the test/run-cloudflare.sh script should help you get started.

If you are trying to replace a RasPi deployment, once you've got it running, just stop the new installation, copy the videos/ dir and the clapshot.sqlite file from RasPi to the Docker volume bind directory, and restart the container. That should be enough to move your existing data to the container setup.

[zen85]

i finally managed to get this to work.

this nginx config:

` GNU nano 7.2 /etc/nginx/sites-enabled/clapshot.impressive-files.com server { listen 443 ssl; server_name clapshot.impressive-files.com;

ssl_certificate /etc/letsencrypt/live/clapshot.impressive-files.com/fullchain.pem;  # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/clapshot.impressive-files.com/privkey.pem;  # managed by Certbot
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers '123123123-USEYOUrOWN';
ssl_prefer_server_ciphers on;

location / {
    proxy_pass http://192.168.1.117:8080;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

location /api {
    proxy_pass http://192.168.1.117:8080/api;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    # Allow large uploads
    proxy_request_buffering off;
    client_body_buffer_size 256K;
    client_max_body_size 50G;  # Set to a limit that suits your needs, e.g., 50G is quite large
}

} server { listen 80; server_name clapshot.impressive-files.com; return 301 https://$host$request_uri; } ` made it work together with this docker-compose container:

version: '3.8'
services:
  clapshot:
    image: elonen/clapshot:latest-demo-htadmin
    container_name: clapshot_host
    volumes:
      - /mnt/clapshot-data:/mnt/clapshot-data/data  # Maps the host directory to the container directory
    networks:
      - clapshot_network
    environment:
      - CLAPSHOT_URL_BASE=https://clapshot.impressive-files.com
    ports:
      - "8080:80"  # Maps port 80 inside the container to port 8080 on the host

networks:
  clapshot_network:
    driver: bridge

i will try now some real life usecases and report back. but i like it already very much!

[zen85]

oh the first rather big obstacle i dont seem to be able to manage is the persistance of the users. when i down and up again the docker compose i am set back to the demo, alice and admin user every time. what do you think would be the best way to tackle this?

[elonen]

If you want to use htadmin for auth, you’ll need to put the .htpasswd file that it writes to, and that Nginx reads, to some persistent Docker volume (or perhaps a folder bind).

[zen85]

this worked now. my docker-compose.yml looks like this:

services:
  clapshot:
    image: elonen/clapshot:latest-demo-htadmin
    container_name: clapshot_host
    volumes:
      - /mnt/clapshot-data:/mnt/clapshot-data/data  # Existing data directory
      - /mnt/clapshot-data/config:/var/www/htadmin/config  # Existing configuration directory
      - /mnt/clapshot-data/config/.htpasswd:/var/www/.htpasswd  # Bind mount the .htpasswd file
    networks:
      - clapshot_network
    environment:
      - CLAPSHOT_URL_BASE=https://clapshot.impressive-files.com
    ports:
      - "8080:80"  # Maps port 80 inside the container to port 8080 on the host

networks:
  clapshot_network:
    driver: bridge

amazing so far and i am starting to use this in production now with smaller projects that are not that critical. my endgoal is to delete my frame.io account (i just tried the new beta and it is a complete featurecreep).

I feel really enthusiastic about clapshot now!

other nice to haves would be:

• a way to make "versions" where i can replace a video via drag and drop on top of it
• a way to create anonymous preview links
• a way to share a movie for feedback with multiple users
• a way to add a custom logo to the top

[elonen]

a way to make "versions" where i can replace a video via drag and drop on top of it

This is a rather big feature not likely to happen soon.

a way to create anonymous preview links

This essentially means bypassing the .htpasswd (for htadmin-based deployments), which Clapshot can't do directly as auth happens on Nginx level - by design. I guess the way you could do it is by configuring Nginx to check for a JWT before falling back to .htpasswd, and have Clapshot Server work as a JWT generator/validator for them. "Share this by anonymous link" menu action would then generate the JWT and copy it to clipboard. Not an impossible feature by any means, but would once again raise the administration difficulty level for people not super familiar with Nginx and modern HTTP auth methods. I'll have to think about it.

a way to share a movie for feedback with multiple users

This you can already do. Make user accounts for all the users you want a review from, then share them the link to your video. The way latest-demo-htadmin is configured lets all authenticated users review any video in the system, provided they know the hash. I.e. the hash(/link) of the video is the secret you share with them. Optionally, you can click the "collab" icon at the top of the player an share that link instead. All the simultaneously online reviewers can then share the player, annotate and seek the video. This is meant to be done during a conference call or something.

[elonen]

a way to add a custom logo to the top

The image in Docker Hub now supports this: docker run -e CLAPSHOT_LOGO_URL="https://1000logos.net/wp-content/uploads/2020/09/Hello-Kitty-Logo.png" -e CLAPSHOT_APP_TITLE="Super Cat Videos" --rm -it -p 0.0.0.0:8080:80 -v clapshot-demo:/mnt/clapshot-data/data elonen/clapshot:0.8.0-demo

[zen85]

amazing! thank you. does this also work with the htadmin-demo?

another little thing just popped up that would greatly enhance usabilty.: on mobile i cant click a video to watch it while i can drag it around to reorder quite fine. i guess the touch and the click event are handled differently?

I am sorry i write all the little ideas here in this threat which makes it kind of hard for you to track? should i create little issues for such things? consider me a fan!

[elonen]

Thanks, I created a new issue about the mobile browsers. Closing this issue now, but feel free to open new ones.