TTRSS to Docker

Some time ago I wrote about the TinyTiny RSS. I did shutdown the service in 2017 because the server it was running got de-provisioned. But everything was stored on a backup.

Since I got some time to spare I’ve decided to re-active the TT-RSS service, however, because I lack the server in the internet, it was moved to a small system at home. This time the deployment should be run on a docker container to allow better deployment. The TT-RSS project itself provides a docker-compose file. It is spilited into seperated container for different task. Many aspects of the services has been decopubled including an container to updated the feeds.

The container names are quite self-explanatory:

Importing the containers

To get started I’ve ported the app and db from the offical docker-compose first to my personal docker-compose file.

  db:
    restart: always
    image: 'postgres:13-alpine'
    volumes:
      - "./volumes/postgresql:/var/lib/postgresql/data"
    environment:    
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - POSTGRES_USER=${POSTGRES_USER}
  ttrss:
    ports:
      - "9000:9000"
    build: 
      context:
        ./ttrss
    restart: unless-stopped
    environment:
      - DB_TYPE=pgsql
      - DB_HOST=db
      - DB_NAME=${POSTGRES_USER}
      - DB_USER=${POSTGRES_USER}
      - DB_PASS=${POSTGRES_PASSWORD}
      - OWNER_UID=${OWNER_UID}
      - OWNER_GID=${OWNER_GID}
      - SELF_URL_PATH=${SELF_URL_PATH}
    volumes:
      - "./volumes/ttrss/:/var/www/html"
    depends_on:
      - db

I’m doing this because of a pre-existing infrastructure hosted with docker, this way I can use some services already in place like nginx for instance.

The appended configuration was already altered, the app was renamed to ttrss to be more identifiable with in the many services I run. Also, I prefer to use relative paths to provide storage. Once the changes were in place we only had to run docker-compose up ttrss. As expected, the first start was not successful, but why?

Accessing the port 9000 of ttrss container directly caused the connection to be restted. Maybe the port forward was not working correctly? After some check it became clear: The ttrss container only takes CGI requests and the web container was necessary to process the CGI resources from Caddy and forward it correctly to the ttrss container. So I copied it down the web entry. It also became necessary to update the upstream name of the Caddyfile to be not app but ttrss.

  web:
    environment:
      - VIRTUAL_HOST=ttrss
      - VIRTUAL_PORT=2015
    build: ./web
    restart: unless-stopped
    volumes:
      - "./volumes/ttrss/:/var/www/html:ro"
    depends_on:
      - ttrss

Once web started it was almost completed. Accessing the port 2015 opens the website of ttrss and asking for a password. At this stage I didn’t know the default password of the service. I tried some basic things like ‘admin:admin’ and so on. After five minutes I decided to try a different way, right, check for the password with in the database and google the hash. The default password of TT-RSS is ‘password’. Gosh I should have tested that, who ever will guess this, I didn’t !?

Proper serving of my old instance

I’m using a nginx-proxy within the docker-compose file that reads out the environment variables for the hostname parameter, this way the proxy knows what name to listen for and where to forward the traffic to for a corresponding container. Once this is configured you’re can access the service with the hostname in my case it will serve http://ttrss.

On this point we need to update the .env to include the correct hostname. I had to rebuild the ttrss container and the took a bit of time until the redirection from the nginx-proxy was working.

Conclusion

I have now a running TT-RSS service within a docker-compose. The next part will be the database restoration and migration, because it takes quite more effort to get it running it will be a post of it’s own.

so far
akendo