Docker-compose + tt-rss

Tiny Tiny RSS Development
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!

294

I don’t update my copy of the docker compose repository very often, the last time was months ago, but I had a weird respawn loop in one of the containers recently so I assumed they were out of sync with tt-rss auto updates and I needed to pull in the latest docker-compose repo changes. It has been quite an ordeal.

The first breaking change was the switch to TTRSS_DB_* variables. This was obvious as soon as docker-compose started so while I wasn’t expecting a breaking config change from updating the compose scripts it wasn’t too much of a hassle to fix.

However the docker environment issues were a serious challenge. I’m running on a raspberry pi 3, and while I know this isn’t a common use case I thought you might like to know what’s causing it to break at the moment.

The problem stems from the php8 upgrade. This requires Alpine 3.13, and that version isn’t supported on the raspberry pi. It breaks due to time64-related changes that require a more recent version of Docker than is available in raspbian stable. The errors are confusing and difficult to track down, with messages like ERROR: https://dl-cdn.alpinelinux.org/alpine/v3.13/main: temporary error (try again later) and nslookup: clock_gettime(MONOTONIC) failed.

I haven’t looked into Alpine’s recommended docker configuration change; that might be the better long-term solution but I want to understand the impact of it before I start messing with seccomp profiles.

For now, since php8 isn’t available on alpine 3.12 and I can’t run alpine 3.13, I ended up manually reverting the docker-compose code to php7. That involved s/php8/php7 and s/fpm8/fpm7 across all the files. This seems to be working, but it probably means I won’t be able to pull in further updates to the docker-compose repository very easily (if at all).

I’m not asking for anything to change. I spent an hour or two tracking down the solution so I just hope this helps anyone else looking for a workaround.

295

there’s a php7 branch: https://git.tt-rss.org/fox/ttrss-docker-compose/src/branch/dynamic-php7

i’ve merged all recent changes there and basically did the same search and replace. i’m not going to promise maintaining it proactively but if something breaks and you report it, i’ll try to merge stuff from master so that it works (again).

296

Oh thank you!

I’ll keep that in mind for future updates. If raspbian or docker release an update that resolves the Alpine 3.13 situation I’ll let you know.

297

For anyone that had an interest in this discussion - Caddy v2.4 now has this; see the example “X-Accel-Redirect support” here: reverse_proxy (Caddyfile directive) — Caddy Documentation

298

I’ve been using tt-rss for probably close to 12-13 years. I recently switched to the docker-compose setup and everything was working great for a few weeks. But for the last 2 days I get “Update daemon is not updating feeds” (and it’s not). I’m a docker noob but I did launch a shell in each of the running containers and tried to look at what’s going on but there were no errors in /var/log or other obvious problems. “docker logs” didn’t seem to have any smoking guns, but I’m not really sure what I’m looking for. Any ideas of where I should look?

Thx