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)
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?
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):
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?
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...
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.
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).
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?
Those logs didn’t have any smoking guns but it was enough of a hint for me to notice that there was supposed to be an updater container. docker ps only showed the other 4 running containers. At some point I rebooted (typical braindead IT advice) and figured docker would restart whatever was supposed to be running, but it only restarted the 4 that were running at shutdown (and I didn’t know that there was supposed to be a fifth).
I ran docker-compose up -d and now everything is good. This is probably pretty obvious but like I said I’m new to docker.
Thanks for pointing me in the right direction. Now I have a lot of articles to catch up on…
Yeah, I was using docker commands, not docker-compose. The obvious problem is that docker doesn’t know what is supposed to be running and neither did I.
I have been working on migration from a self hosted instance into docker and would like to point out an omission I found on the wiki FAQ for Docker under Backup and Restore. The command for clearing the database is missing the “-c” option to execute the drop/create part of the command.
psql -h db -U $DB_USER $DB_NAME -e -c “drop schema public cascade; create schema public”
Today I noticed my feeds weren’t updating so I figured I might as well update the docker images. It’s been a while. Turns out the last time dynamic-php7 was rebased on master (thank you for continuing to do that!) it included a change to alpine 3.14 which would break my setup
Before asking for it to be reverted I did some more digging. In the last year Docker has been updated on raspberry pi, and libseccomp2 has been updated in a newer raspbian release - but raspbian recommends doing a full reinstall to upgrade
Luckily I found instructions for updating libseccomp2 on older raspbian. Turns out lots of people use alpine on an rpi and smarter people than me figured out a solution that avoids downgrading docker security. It works! I’m now using master and php8
little typo in your wiki
thank you!
