how do i remove/disable caddy, my installation is lan and http only
I started building a docker-compose setup some time ago:
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
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 https://docs.docker.com/storage/tmpfs/). So the app container cannot be aware if the update.php-script is running or not. So I leave it the way it is.
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.
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
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 gd --with-freetype-dir=/usr --with-png-dir=/usr --with-jpeg-dir=/usr; \
docker-php-ext-configure gd --with-freetype --with-jpeg; \
Issue discussion and resolution is located here:
Thank you for the hints @milkman671. I just pushed your changes to the repo.
I was playing around with Docker Hub to publish an image of the tt-rss-fpm-container: https://hub.docker.com/r/meyca/tt-rss-fpm
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.
How are updates from fox’s master branch updated in your fpm container?
I see that the entrypoint.sh script runs rsync to update files from
/var/www/html/, but how is the
/usr/src/tt-rss/ directory updated?
git pull origin master command be issued before the rsync command?
The update is done during build time of the container:
The (not yet realized) idea is to (automatically) build and push a new container on each push to the master repo of TT-RSS on git.tt-rss.org. I will try with my local Gogs installation how things (webhooks, git hooks etc.) turn out.
Unless I’m something something, it appears that the container won’t receive regular updates as new commits are pushed to the master branch. With the current Dockerfile, the container will be built with the latest commit, but in order to update in the future, the container would need to be stopped, removed, and then built from source again.
startup.sh script resolves this issue by running
git pull origin master during a container reboot to make sure an existing container gets updated to the latest commit.
@milkman671, you are absolutely right and not something something.
It is some kind of container philosophy to think of a container as complete piece of software/service/microservice including all its dependencies. With this in mind you want one place to update this “monolithic” container. Having the container updating itself you suddenly have two places where updates may occur. This can become a version nightmare between dependencies and the software/service/microservice itself, because different version combinations between software/service/microservice and dependencies become possible.
So, in general, it is not a good idea to have a container updating itself. @fox’s setup does not include multiple containers for the tt-rss service so this setup only has one version combination. This reduces the problem, but might be difficult to support or a security problem, if you forget to update the container itself.
To avoid this, I want to use docker’s infrastructure to build the container and push it to the public registry. But this is, as I mentioned, not yet realized.
I forgot to mention watchtower (https://containrrr.github.io/watchtower/) to automatically update containers.