your docker-compose version is too old. instead of installing it from the repository, get the upstream version. it’s a single binary that goes into /usr/local/bin, you don’t have to apt install it.
Actually, the problem is more complicated. if you see, the sudo docker-compose returns version 1.9. However, the apt-get says that the version is 1.17.1-2. So the installation is correct, sth else is the problem…
another older version in /usr/local/sbin?
find /usr -name docker-compose
also not really tt-rss related, isn’t it
I fix it.
The older version was in ./usr/local/bin/docker-compose, so I link it to the new one ./usr/bin/docker-compose
how do i remove/disable caddy, my installation is lan and http only
/20char
Hello alltogether,
I started building a docker-compose setup some time ago:
https://gogs.meyca.de/carstenmeyer/tt-rss-docker
The main differences to fox’ container setup is that I use individual container instances for update-daemon, PHP-app, database and web-proxy. However update-daemon and PHP-app are identical containers (started with different commands).
This way the standard containers for database and web-proxy can be updated independent from the rest of the setup and the individual containers stay as small as possible.
There are still some things to do (but not written down yet), mail being one the them. Another one is the automation of the build process to have a new container on each commit to master and eventually publishing it on Docker hub.
As of now I use a “local” copy of tt-rss (gogs-mirror) because I did not want to generate too much traffic at the source during my tests. I would be happy to change this and contribute my parts to a “stock” tt-rss-docker-container, wherever it lives. The design decisions being different I am not sure, if this is wanted.
Thanks for feedback
meyca
fixed your link.
this setup looks interesting. separate daemon container instead of a cronjob is a good idea.
it looks like you have an immutable tt-rss source snapshot but you rsync it over to live version on startup - wouldn’t it be better to use symlinks for user-modifable data in this situation so that the benefit of immutability is utilized better? am i making sense here?
i’m not sure if there’s much point in replacing my docker scripts with yours since they implement things somewhat differently and some users might prefer either. however, linking your setup in the installation guide docker section as an alternative immutable setup looks like a good idea.
one thing you’re missing is a proper README and pointing to main tt-rss repositories on a production setup i think.
user-modifiable are directories plugins.local and themes.local as well as config.php, right?
Regarding config.php I think it is better to have the configuration in one place (in this case within app.env or docker-compose.yml). Changes to these configs should be applied on a container restart, hence the overwrite of config.php in entrypoint.sh.
Regarding plugins.local and themes.local you are right. These should be omitted when overwriting/rsyncing the tt-rss-installation on the volume.
Did I miss something?
These are two things, but you are right. 
I put this on my todo list.
feed-icons should also be persistent. stuff like lock should probably go on tmpfs.
this makes sense and i thought about using it too (and maybe add it for SELF_URL_PATH) but you shouldn’t rewrite config.php from the template - some plugins require adding things in there so it should be persistent, generally.
plugins.local, themes.local, feed-icons and config.php are not overwritten anymore on upgrades. 
Overwriting lock and cache cares for a “clean” state after upgrading.
tmpfs filesystems have limitations on docker containers. Especially in this usecase, they cannot be shared between containers (see tmpfs mounts | Docker Docs). So the app container cannot be aware if the update.php-script is running or not. So I leave it the way it is.
regarding
I am not yet sure, how or if I should deal with extra plugins and their updates. An automated/inline way for updates would be nice. Right now, I leave plugins.local all alone.
Ideas, anyone?
local plugins may be written by user, updated from all sorts of places (i.e. not git), they may be locally modified, have broken upstream, etc. i’m not sure if auto updating them is a good idea.
I don’t think it’s been mentioned yet but having cache be tmpfs would create problems for plugins like cache_starred_images. Those images would be removed and because their respective articles are marked as having all the images downloaded, they would not be re-fetched.
yes, cache should definitely be persistent.
added /cache to exclude.upgrade
@meyca
The php fpm container build is failing with the latest 7.4.1 version of the php:fpm-alpine image. The error message during build is:
configure: error: unrecognized options: --with-freetype-dir, --with-png-dir, --with-jpeg-dir
Updating the Dockerfile to use the older 7.3 version of the php fpm-alpine image resolves the build error.
To resolve the build error and still use the latest 7.4.1 php fpm-alpine image, the following changes are needed to the Dockerfile:
- Add the
oniguruma-devapk package to build dependencies:
apk add --no-cache --virtual .build-deps \
$PHPIZE_DEPS \
autoconf \
curl-dev \
freetype-dev \
icu-dev \
libjpeg-turbo-dev \
libmcrypt-dev \
libpng-dev \
libxml2-dev \
libzip-dev \
oniguruma-dev \
pcre-dev \
postgresql-dev \
git \
; \
- Update the command-line options of the
docker-php-ext-configure gdcommand:
From:
docker-php-ext-configure gd --with-freetype-dir=/usr --with-png-dir=/usr --with-jpeg-dir=/usr; \
To:
docker-php-ext-configure gd --with-freetype --with-jpeg; \
Issue discussion and resolution is located here:
https://github.com/docker-library/php/issues/912
I was playing around with Docker Hub to publish an image of the tt-rss-fpm-container: Docker
Has anyone setup any automation tools for updating a code snippet at github.com to include a commit hash? This would then initate a new container build.