Docker-compose + tt-rss

Tiny Tiny RSS Development
274

The permissions on /var/lib/docker/volumes will keep a user from accessing the files, even if they share a UID with them, but it would really mess with filesystem quotas for that user. Also, it just looks ugly to have a bunch of files from a container owned by some random user. I have no idea what will happen if somebody runs deluser --remove-all-files on the user with that UID. Certainly those things are not a big deal on a single user system, but I work on a lot of multi-user systems, so I tend to plan that users come and go, and they’ll do stupid things like download terabytes of data without knowing where to put it.

Yes, it is probably better to use names for the different dockers, and be able to address them that way. I went down the path of using static IP addresses for my containers, and I’m going to stick with it even if it makes thing harder for me!

275

i don’t think you should go in there directly, at least not during regular container operation. storage volumes are kinda abstracted away for a reason.

if this was a virtual machine, this would be editing machine filesystem image directly while complaining that UIDs inside don’t correspond to anything on the host. they aren’t supposed to.

i don’t think i ever used filesystem quotas in my life (other than on dedicated storage devices) so i can’ t comment here.

e: me pointing out the unnecessary parts was largely because someone is obviously going to follow the most convoluted post on this forum for his rpi “homelab” because people somehow always make things harder on themselves for no reason.

276

Why does the default (non-ssl) setup still use Caddy 1 instead of nginx? Caddy 1 is not supported anymore, and I read somewhere in this gigantic thread that fox doesn’t want to upgrade to Caddy 2 yet (can’t remember why). Also, web-nginx already exists and works fine, so it’s not more effort.

277

i think caddy is only there because of letsencrypt, which is a niche usecase. we could switch to nginx being the default and keep caddy optional.

this would also remove an unmaintained (?) third party dependency.

e: at some point nginx wasn’t there so using caddy would save on configuration files and stuff but since web-nginx is there anyway yeah it doesn’t make a lot of sense to use caddy for http.

278

i’m going to migrate web to web-nginx as the default, basically comment out the former and uncomment the latter in the default yml.

we’re going to keep caddy as an optional ssl-aware frontend.

relevant commits:

https://git.tt-rss.org/fox/ttrss-docker-compose/commit/105edb31490d0d6c970afd02373173ca179ff8b0

https://git.tt-rss.org/fox/ttrss-docker-compose/commit/c447753a50dcc6f6bb1c56b923825e89a8d2bd12

happy new year, etc.

e: this may be entirely subjective but i think it works faster with nginx too, especially noticeable on larger cached media files not slowing down the rest.

279

I’ve been looking at migrating to Docker as well - it looks like a really pleasant setup. I am aware that you don’t much care about the /tt-rss/ subfolder being there, @fox, and I understand your reasoning. But I don’t want to confuse a handful of not technologically fit users here, so wanted to get rid of it.

So I went and changed nginx.conf to show root /var/www/html/tt-rss; as well as removing the tt-rss part of the two location statements, loaded my old database as described in the forum and am running this as a test for a few days now. Seems to work nicely.

Is this an acceptable modification or will it break in unexpected ways?

1 Like
280

nope, it shouldn’t break anything.

281

I’ve updated the wiki on the subject of connectivity errors:

https://git.tt-rss.org/fox/ttrss-docker-compose/wiki/Home#im-running-into-502-errors-andor-other-connectivity-issues

I think I mentioned the important parts, however suggestions welcome to add anything else related I’ve missed that could help troubleshoot these issues.

282

Thanks for the work on providing tt-rss in docker compose containers.

I was wondering, what are your thoughts on providing & maintaining configuration information, separately to the application code?

Typically, with docker containers, the application code & containers should be disposable, with state (the db, etc.) kept outside the container in a datastore or persistent volume.

Currently the application is stored, along with the config, in the ‘app’ persistent volume.

When starting a new container, configuration information for some parameters can be provided through environment variables, and then on first startup, where the defaults are taken from config.php-dist displayed to the user, validated, then saved to config.php

There’s also a bunch of options in the config.php that can’t be configured through the interface, and must be manually edited. Eg. SINGLE_USER_MODE, SIMPLE_UPDATE_MODE, LOCK_DIRECTORY, CACHE_DIR, ENABLE_REGISTRATION, REG_MAX_USERS, etc, etc. A whole lot of config is possible.

One solution some alternative dockers configurations have used are reading environment variables, and using sed, to replace some of these configuration items on startup.

This effectively means there has to be a one to one mapping/mechanism for each configurable item with an environment variable.

It’s manageable, but the use of sed to modify config.php is a bit hacky.

Another option is to put config.php on it’s own docker volume, separate from the app volume, which would persist it and allow the app volume/code to be rebuilt separately. But this doesn’t allow for easy configuration through environment variables, and deployment using configuration/architecture as code.

I think ideally, it’d be great if nearly everything in either config.php, or config.php-dist was configurable through environment variables, then stored in a persistent data store. However, this needs to be designed in to the installation process.

Do you have any plans or thoughts on how you want initializing and persistence of configuration to be stored long term?

283

having everything in config.php to be configurable via environment is a good idea but i’m not sure how to do this properly given its format (a php source file). the setup is currently using sed for SELF_URL_PATH etc but it’s obviously not the best solution.

284

2 posts were split to a new topic: Docker: environment-based configuration

285

Thanks for everyone who posted here, and obviously fox specifically for the work and documentation. Thanks to you, I successfully migrated from a hosted install (on and ARM64 platform) to a docker install (also on an ARM64 platform, though a different device).

To be able to get the containers up and running on ARM64 I used the dynamic installation. I understand that to update application I just have to restart the containers but I have some extra questions:

  1. Can I see somewhere that there is an update available, so that I’m not just restarting the containers when it’s not necessary. (Either in the app itself, or by comparing the version number to a published number on github or somewhere else)
  2. Do I always need to restart all containers, or only the app container, or …

Thanks!

286

Can I see somewhere that there is an update available, so that I’m not just restarting the containers when it’s not necessary. (Either in the app itself, or by comparing the version number to a published number on github or somewhere else)

A green icon will show up near the top of tt-rss when there are new commits. Alternatively, compare the commit in the footer of Preferences (or manually, via Shift+V w/ a plugin, etc.) against https://git.tt-rss.org/fox/tt-rss/commits/branch/master .

Do I always need to restart all containers, or only the app container, or …

I restart app, updater, and web-nginx (the last due to an odd bad gateway issue that wouldn’t go away).

287

fox,

I don’t know if this is a dumb request or not, but for those of us who would like to be as close to the environment you’re running as possible, can you give us a run down? I gather you’re using Debian, I know you’re using PostgreSQL. I think you’re using php 7.3. What browser do you develop with mostly? Where are you getting Docker from? From docker.io or the Debian repos? That kind of thing.

Also, I appreciate both the static and dynamic docker options. Which do you recommend and why?

288

I do have a VM for development (Debian 10, hyper-v) but it doesn’t matter much because everything actually php-related is inside the container.

I’m using stock dynamic setup for development (so it’s php8 now), only difference is that source tree is exposed so I can open it in vscode over ssh:

docker-compose.override.yml 
version: '3'

services:
  app:
    build:
      context:
        ./app
    volumes:
      - ./html:/var/www/html
    env_file:
      - .env

  updater:
    build:
      context:
        ./app
    volumes:
      - ./html:/var/www/html
    env_file:
      - .env

  web-nginx:
    build: ./web-nginx
    volumes:
      - ./html:/var/www/html
    env_file:
      - .env

VM itself doesn’t have much installed - nodejs (from the nodesource repo) so I could use gulp/lessc/etc and docker-ce (from the official repos).

I’m using Brave because that’s what I’m normally using, but really all Chromium clones are the same.

Dynamic is the “I don’t want to use docker hub” option. Some people wanted it, and it’s easier for actual development, so it’s there. Normally for production use I’d suggest docker hub image because you can always rollback and in general it’s harder to break.

just in case, here's what I use in vscode for tt-rss (it's not much):

image

289

I am following the default installation guide.

I have done everything up until “Pull and start the container”. docker info says “Running: 5”. What now? The guide doesn’t explain what to do next, where the software is, etc. Is it now accessible via URL http://localhost:8280/tt-rss ? If so, when I click it, I get redirected to http://localhost/tt-rss/ and firefox says it cannot open this page. What to do?

What are the login and password to?

290

Hi Fox,

Since your last update, my instance no longer starts.

db_1         | 2021-03-06 17:32:46.330 UTC [1] LOG:  starting PostgreSQL 12.5 on x86_64-pc-linux-musl, compiled by gcc (Alpine 9.3.0) 9.3.0, 64-bit
db_1         | 2021-03-06 17:32:46.333 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
db_1         | 2021-03-06 17:32:46.335 UTC [1] LOG:  could not create IPv6 socket for address "::": Address family not supported by protocol
db_1         | 2021-03-06 17:32:46.341 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
db_1         | 2021-03-06 17:32:46.355 UTC [20] LOG:  database system was shut down at 2021-03-06 17:23:09 UTC
db_1         | 2021-03-06 17:32:46.359 UTC [1] LOG:  database system is ready to accept connections

runn’s in a loop …

app_1        | pg_isready: option requires an argument: U
app_1        | Try "pg_isready --help" for more information.
app_1        | waiting until db is ready...
updater_1    | pg_isready: option requires an argument: U
updater_1    | Try "pg_isready --help" for more information.
updater_1    | waiting until db is ready...

Thank you.

Sorry, found it! :roll_eyes:

291

Hi Fox;

this is how you really drive the noobs crazy :smiley: little typo in your wiki

https://git.tt-rss.org/fox/ttrss-docker-compose/wiki#i-m-trying-to-run-cli-tt-rss-scripts-inside-the-container-and-they-complain-about-root

docker exec -it --user app APP_CONTAINER_ID php8 /var/www/html/tt-rss/update.php --help
292

oh oops. how about now?

https://git.tt-rss.org/fox/ttrss-docker-compose/wiki/Home#i-m-trying-to-run-cli-tt-rss-scripts-inside-the-container-and-they-complain-about-root

293

Perfect :slight_smile: thank you!