Tiny Tiny RSS¶
Tiny Tiny RSS is a self-hosted, AJAX-based RSS reader, which rose to popularity as a replacement for Google Reader. It supports
geeky advanced features, such as:
- Plugins and themeing in a drop-in fashion
- Filtering (discard all articles with title matching "trump")
- Sharing articles via a unique public URL/feed
Setup data locations¶
We'll need several directories to bind-mount into our container, so create them in /var/data/ttrss:
1 2 3
Create ttrss.env, and populate with the following variables, customizing at least the database password (POSTGRES_PASSWORD and DB_PASS) and the TTRSS_SELF_URL to point to your installation.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Setup docker swarm¶
Create a docker swarm config file in docker-compose syntax (v3), something like this:
I share (with my patreon patrons) a private "premix" git repository, which includes necessary docker-compose and env files for all published recipes. This means that patrons can launch any recipe with just a
git pull and a
docker stack deploy 👍
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
Setup unique static subnets for every stack you deploy. This avoids IP/gateway conflicts which can otherwise occur when you're creating/removing stacks a lot. See my list here.
Launch TTRSS stack¶
Launch the TTRSS stack by running
docker stack deploy ttrss -c <path -to-docker-compose.yml>
Log into your new instance at https://YOUR-FQDN - the first user you create will be an administrative user.
Chef's Notes 📓¶
There are several TTRSS containers available on docker hub, none of them "official". I chose x86dev's container for its features - such as my favorite skins and plugins, and the daily automatic updates from the "rolling release" master. Some of the features of the container I use are due to a PR I submitted:
Docker swarm looses the docker-compose concept of "dependencies" between containers. In the case of this stack, the application server typically starts up before the database container, which causes the database autoconfiguration scripts to fail, and brings up the app in a broken state. To prevent this, I include "wait-for", which (combined with "S6_BEHAVIOUR_IF_STAGE2_FAILS=2"), will cause the app container to restart (and attempt to auto-configure itself) until the database is ready.
The upstream git URL changed recently, but my experience of the new repository is that it's SO slow, that the initial "git clone" on setup of the container times out. To work around this, I created my own repo, cloned upstream, pushed it into my repo, and pointed the container at my own repo with TTRSS_REPO. I don't get the latest code changes, but at least the app container starts up. When upstream git is performing properly, I'll remove TTRSS_REPO to revert back to the "rolling release".
Tip your waiter (support me) 👏¶
Did you receive excellent service? Want to make your waiter happy? (..and support development of current and future recipes!) See the support page for (free or paid) ways to say thank you! 👏
Flirt with waiter (subscribe) 💌¶
Want to know now when this recipe gets updated, or when future recipes are added? Subscribe to the RSS feed, or leave your email address below, and we'll keep you updated. (double-opt-in, no monkey business, no spam either - check the archive for proof!)