Docker-compose + tt-rss

Hello! Any intention to update this to use Caddy v2, now that it’s released and v1 is no longer being worked on?

if someone wants to file a PR (and there’s a telemetry-less docker repository), sure.

Happy to - I have it working on my local machine, and v2 of caddy dropped telemetry entirely. It’s also TLS by default, as it can do local TLS certificate issuance (without Let’s Encrypt or an external domain), so that even localhost traffic can be encrypted. I think that means you no longer need to have different /web and /web-ssl directories, and maybe have everything depend on a single environment variable (which the user could set as either localhost or a web domain name) - but I want to play around a bit to test all that.

I’ve signed up an account on git.tt-rss.org, but can’t create or fork the repo. Do I need special permissions? My username is dante.

Second question - how important to you are following three directives in the current Caddyfile? I’d need to figure out how to convert them to v2 format - I just don’t know if they’re especially important in this scenario.

log stdout
errors stderr
internal /tt-rss/cache

the first two are niceties so that you can see log output via docker-compose log, i’d like to have those if possible.

the last one is actually important, it’s related to nginx-compatible X-Accel support, it marks cache directory so that static files are sent in a fast way, without php.

if there’s no X-Accel support i’d rather go back to nginx.

sure, you should be able to fork and make repositories now.

OK - logging should be doable, see log (Caddyfile directive) — Caddy Documentation

Less sure about X-Accel, though. I think it might be better to wait for caddy v2.1 for that. You’re currently using the http.internal module for that directive (in caddy v1), as I understand it. Git issue commentary from the dev suggests he’s working on something in v2.1 that’s related to this (this time leveraging the reverse_proxy directive) - see here:

Second thought - I wonder if we can use caddy’s route{} directive for this, to serve static files from /cache directly, sending everything else to php? See php_fastcgi (Caddyfile directive) — Caddy Documentation ?

See also: Example: configure WordPress with a static cache - Wiki - Caddy Community

Is it just the cache directory that needs to be served as static files? I might have a try.

For what it’s worth, my single user install is using caddy2 sending everything to PHP (including calls to tt-rss’s cache, I guess), and performance is fine - but that’s on an intel i3 6th gen 8gb ram machine, I guess a raspi or similar might be a different story.

Out of the box PHP isn’t multi-threaded. It only handles one thing at one time per process. This means as requests increase (more users or interaction) it gets tied up handling requests and can’t respond. Basically, PHP itself is a bottleneck. This becomes readily apparent if you start using it to serve media files. Whereas modern web servers can tend to handle that stuff pretty easily. By having PHP pass that type of request back to the web server, it’s freed to handle the stuff it needs to handle (loading article content, marking things read, starred, etc.).

Gotcha.

There seems to be quite a lot of possibility within caddy v2 to do this; e.g. the examples here are specifically to bypass PHP if something exists in cache: try_files (Caddyfile directive) — Caddy Documentation

Would that approach suffice, or do we need to be a bit more sophisticated (e.g. do we need to authenticate requests to cached resources, i.e. only serve something from cache if the user has a logged-in session cookie)?

i think we might as well wait until there’s proper x-accel support. it does make a difference and i would definitely prefer to not lose it.

if caddy didn’t support it in the first place, my docker setup would use nginx instead.

Sure. Just so I’m clear on what you’re looking for - is it because simply bypassing the php engine when requesting cached static files isn’t sufficient - e.g. are you relying on x-accel for security as well?

I would prefer to not replace current implementation with some try files kludge if that’s what you’re talking about.

OK, I’ll noodle along in a fork, watch caddy 2 development, and report back once things are as you’d like them. Is there some way of testing for the behaviour you’re looking for? E.g. “if the file has an “X-Accel-Redirect” header, check that it isn’t served from […]” ?

Why does the docker setup use the standard location /var/www/html for web files?

Not surprisingly this clashes with my nginx installation; I don’t get the point of dockerising but putting a volume in a well-known location which immediately breaks the isolation.

Am I missing something?

hint: this well known location is inside the container, mapped to a storage volume.

i have no idea how would you even make this path clash with what is presumably your host :face_with_raised_eyebrow:

Sorry I was reading it the wrong way round, doh!

Any suggestion about add Access-Control-Allow-Origin for use in api using docker?

The FAQ had a nice description of a nginx reverse proxy setup. I was able to take that and make it work with apache. Would someone be able to add this to the FAQ?

You need to run

a2enmod proxy
a2enmod proxy_http

To get apache to load the mod_proxy module. Then add a config file to /etc/apache2/sites-enabled, such as this:

<VirtualHost *:80>
    ServerName domain.com

    ProxyPreserveHost On
    ProxyRequests Off

    # Server IP + the exposed port of docker container 
    ProxyPass / http://127.0.0.1:8280/
    ProxyPassReverse / http://127.0.0.1:8280/
</VirtualHost>

I didn’t see much out here as to backing up the database. I was able to write a script with the following lines to get it working:

source .env
docker-compose exec db /bin/bash \
  -c "export PGPASSWORD=$POSTGRES_PASSWORD \
  && pg_dump -U $POSTGRES_USER $POSTGRES_USER" \
  | gzip -9 > backup.sql.gz

Would that be worth adding to the FAQ?

I haven’t tried restoring to a new machine yet, but presumably it would be a similar command.

sure, why not. i’ll add this to the wiki. thanks.

e: added to https://git.tt-rss.org/fox/ttrss-docker-compose/wiki/Home

The guide was great, thanks - one issue: created it, changed owner/user id in .env, the created index.php didn’t have global read permissions and the wrong owner so I couldn’t access the webview until I fixed that manually