Встановлення Tiny Tiny

Що ми налаштовуємо і навіщо

Ми встановлюватимемо Tiny Tiny RSS (TTRSS) — це потужний, повністю відкритий (AGPLv3) веб-орієнтований агрегатор RSS/Atom-стрічок. У світі, де багато комерційних RSS-сервісів приходять і йдуть, або починають показувати рекламу та обмежувати функціонал, TTRSS пропонує повну свободу та контроль над вашими новинними потоками. Ви зможете збирати, читати та організовувати тисячі стрічок з найрізноманітніших джерел, будь то блоги, новинні сайти, подкасти або канали YouTube (за допомогою спеціальних плагінів).

У підсумку читач отримає власний, приватний та повністю контрольований RSS-сервер, доступний з будь-якої точки світу через веб-інтерфейс та мобільні додатки (що підтримують API TTRSS). Це ідеальне рішення для тих, хто цінує конфіденційність, хоче уникнути нав'язливої реклами та мати повний контроль над своїм інформаційним простором.

Існують альтернативи, такі як хмарні сервіси (Inoreader, Feedly) або інші самохостингові рішення (FreshRSS, Nextcloud News). Хмарні сервіси зручні, але позбавляють вас контролю над даними та часто мають платні тарифи з розширеним функціоналом. Самохостингові рішення, такі як TTRSS, вимагають початкового налаштування, але в довгостроковій перспективі пропонують незрівнянну гнучкість, безпеку та економічну вигоду, особливо коли ви розгортаєте їх на власному VPS. Ви володієте своїми даними, можете встановлювати будь-які плагіни та налаштовувати сервіс під свої потреби без обмежень.

Який VPS-конфіг потрібен для цього завдання

Для розгортання Tiny Tiny RSS з Docker, Nginx та PostgreSQL на одному VPS потрібні відносно скромні ресурси, але з невеликим запасом для комфортної роботи та можливості розширення.

Мінімальні вимоги (для 1-5 користувачів, до 1000 стрічок):

• CPU: 1 ядро (наприклад, Intel Xeon E3/E5 або AMD EPYC).
• RAM: 1 ГБ. Цього достатньо для Docker-контейнерів TTRSS, PostgreSQL та Nginx, але без великого запасу.
• Диск: 20 ГБ SSD. TTRSS не споживає багато місця для самої установки, але база даних та кеш зображень можуть з часом зростати. SSD значно прискорює роботу з БД.
• Мережа: 100 Мбіт/с. Для RSS-агрегатора швидкість мережі не є критичною, оскільки трафік в основному складається з невеликих HTTP-запитів.

Рекомендований VPS-план (для 5-20 користувачів, до 5000+ стрічок, із запасом на майбутнє):

• CPU: 2 ядра. Забезпечить кращу продуктивність при оновленні великої кількості стрічок та одночасній роботі кількох користувачів.
• RAM: 2-4 ГБ. Дозволить PostgreSQL ефективніше кешувати дані, а TTRSS обробляти більше фонових завдань.
• Диск: 50-100 ГБ SSD. Дасть достатньо місця для зростання бази даних, зберігання кешу, а також для резервних копій.
• Мережа: 1 Гбіт/с. Стандартна швидкість, що забезпечує швидке завантаження веб-інтерфейсу.

Для такого сценарію можна взяти VPS із зазначеними характеристиками. Вибирайте провайдера, що пропонує гнучкі тарифи та можливість масштабування.

Коли потрібен dedicated, а не VPS

Виділений сервер (dedicated server) для Tiny Tiny RSS зазвичай не потрібен, якщо тільки ви не плануєте обслуговувати сотні чи тисячі користувачів, агрегувати десятки тисяч стрічок з дуже високою частотою оновлення, або якщо TTRSS є лише однією з безлічі вимогливих служб, що працюють на цьому ж сервері. Dedicated сервери пропонують повну ізоляцію ресурсів та часто вищу продуктивність введення/виведення, але для TTRSS на кілька десятків користувачів VPS середнього рівня буде більш ніж достатньо та значно економічніше.

Локація: на що впливає

Вибір локації VPS впливає на:

• Затримку (latency): Чим ближче сервер до вас та ваших користувачів, тим швидше завантажуватиметься веб-інтерфейс TTRSS.
• Законодавство: Деякі користувачі віддають перевагу розміщенню своїх даних у юрисдикціях з більш суворими законами про конфіденційність.
• Швидкість агрегації: Якщо більшість ваших RSS-стрічок походить з певного географічного регіону, розміщення VPS там же може трохи прискорити процес оновлення стрічок, але це рідко є критичним фактором.

У більшості випадків вибирайте локацію, яка знаходиться географічно близько до вас або до основної маси ваших користувачів.

Підготовка сервера

Після отримання доступу до вашого нового VPS перше, що потрібно зробити — це провести базове налаштування безпеки та встановити необхідні утиліти. Ми використовуватимемо дистрибутив на базі Debian/Ubuntu, який є одним з найпопулярніших та добре документованих.

1. Підключення по SSH та створення нового користувача

Підключіться до сервера як користувач root (або той, якого надав провайдер):

ssh root@ВАШ_IP_АДРЕС

Створіть нового користувача з правами sudo для повсякденної роботи. Замініть ваш_пользователь на бажане ім'я користувача:

adduser ваш_пользователь # Створюємо нового користувача
usermod -aG sudo ваш_пользователь # Додаємо його до групи sudo

Встановіть надійний пароль для нового користувача, коли система запитає.

2. Налаштування автентифікації за SSH-ключами (рекомендується)

Це значно підвищує безпеку. Скопіюйте ваш публічний SSH-ключ на сервер:

# На вашій локальній машині:
ssh-copy-id ваш_пользователь@ВАШ_IP_АДРЕС

Потім вимкніть автентифікацію за паролем для SSH (тільки після того, як переконаєтеся, що можете увійти за ключем). Відредагуйте файл /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Знайдіть рядки та змініть їх значення:

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no # Іноді корисно вимкнути, якщо у вас проблеми з логіном
PermitRootLogin no # Вимикаємо вхід для root

Перезапустіть SSH-сервіс:

sudo systemctl restart sshd

Тепер вийдіть з root-сесії та увійдіть як новий користувач:

exit
ssh ваш_пользователь@ВАШ_IP_АДРЕС

3. Оновлення системи та встановлення базових утиліт

Оновіть список пакетів та встановіть усі доступні оновлення:

sudo apt update && sudo apt upgrade -y

Встановіть необхідні утиліти, які знадобляться в процесі налаштування:

sudo apt install -y curl wget git nano htop unzip

4. Налаштування файрволу (UFW)

Увімкніть UFW та дозвольте лише необхідні порти (SSH, HTTP, HTTPS):

sudo apt install -y ufw # Встановлюємо UFW, якщо ще не встановлений
sudo ufw allow OpenSSH # Дозволяємо SSH (порт 22 за замовчуванням)
sudo ufw allow http # Дозволяємо HTTP (порт 80)
sudo ufw allow https # Дозволяємо HTTPS (порт 443)
sudo ufw enable # Вмикаємо файрвол
sudo ufw status # Перевіряємо статус файрволу

Підтвердіть увімкнення файрволу, натиснувши y.

5. Встановлення Fail2Ban

Fail2Ban допомагає захистити сервер від атак методом підбору паролів, блокуючи IP-адреси, з яких надходять численні невдалі спроби входу.

sudo apt install -y fail2ban # Встановлюємо Fail2Ban
sudo systemctl enable fail2ban # Вмикаємо автозапуск сервісу
sudo systemctl start fail2ban # Запускаємо сервіс
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local # Копіюємо конфіг для редагування

Відредагуйте /etc/fail2ban/jail.local, якщо хочете змінити параметри (наприклад, bantime або maxretry). Для більшості випадків налаштування за замовчуванням для SSH достатні.

sudo nano /etc/fail2ban/jail.local

Переконайтеся, що секція [sshd] активна (enabled = true).

Конфігурація

Тепер, коли все необхідне ПЗ встановлено, ми перейдемо до налаштування Tiny Tiny RSS, бази даних PostgreSQL та Nginx.

1. Створення файлу docker-compose.yml

Цей файл описує наші сервіси (TTRSS, PostgreSQL) та їхні взаємозв'язки. Створіть файл docker-compose.yml у каталозі ~/ttrss:

nano docker-compose.yml

Вставте наступний вміст. Замініть ВАШ_ДОМЕН на ваш реальний домен, наприклад ttrss.example.com. Також придумайте надійні паролі для POSTGRES_PASSWORD та TTRSS_DB_PASS.

version: '3.8'

services:
  db:
    image: postgres:17-alpine # Актуальна версія PostgreSQL на 2026 рік
    restart: always
    environment:
      POSTGRES_USER: ttrss_user
      POSTGRES_PASSWORD: ваш_очень_надежный_пароль_для_бд # Змініть на свій
      POSTGRES_DB: ttrss_db
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ttrss_user -d ttrss_db"]
      interval: 10s
      timeout: 5s
      retries: 5

  app:
    image: ghcr.io/henrywhitaker3/ttrss:latest # Офіційний Docker образ Tiny Tiny RSS
    restart: always
    depends_on:
      db:
        condition: service_healthy
    environment:
      TTRSS_DB_TYPE: pgsql
      TTRSS_DB_HOST: db
      TTRSS_DB_NAME: ttrss_db
      TTRSS_DB_USER: ttrss_user
      TTRSS_DB_PASS: ваш_очень_надежный_пароль_для_бд # Повинен збігатися з POSTGRES_PASSWORD
      TTRSS_SELF_URL_PATH: https://ВАШ_ДОМЕН/ # Замініть на ваш домен
      TTRSS_FEED_UPDATE_INTERVAL: 15 # Інтервал оновлення стрічок у хвилинах
      TTRSS_PLUGINS: auth_internal,bookmarklets,embed_original,fever,force_refresh,mark_read_on_scroll,note,nsfw,open_in_new_window,toggle_sidebar,updater,view_original,youtube
      TTRSS_PHP_TZ: Europe/Moscow # Встановіть свій часовий пояс
      TTRSS_NO_SMTP_HOSTNAME: "true" # Якщо не використовуєте SMTP для надсилання пошти
      TTRSS_LOG_DESTINATION: "stdout"
      TTRSS_DEFAULT_UPDATE_DAEMON: "true" # Вмикаємо вбудований демон оновлення
    volumes:
      - ttrss_data:/var/www/html/feed-icons # Для іконок фідів
      - ./config.php:/var/www/html/config.php # Якщо потрібна кастомна конфігурація, але краще через ENV
    ports:
      - "127.0.0.1:8080:80" # TTRSS буде доступний на хості через порт 8080

volumes:
  db_data:
  ttrss_data:

Налаштування TTRSS_SELF_URL_PATH, TTRSS_FEED_UPDATE_INTERVAL, TTRSS_PLUGINS та TTRSS_PHP_TZ можна адаптувати під свої потреби.

Збережіть та закрийте файл (Ctrl+O, Enter, Ctrl+X).

2. Запуск сервісів Docker Compose

У каталозі ~/ttrss виконайте:

docker compose up -d # Запускаємо контейнери у фоновому режимі

Перевірте статус контейнерів:

docker compose ps # Перевіряємо, що всі сервіси запущені та здорові (healthy)

3. Налаштування Nginx як зворотного проксі

Створіть новий файл конфігурації Nginx для вашого домену. Замініть ВАШ_ДОМЕН на ваш домен.

sudo nano /etc/nginx/sites-available/ВАШ_ДОМЕН.conf

Вставте наступний вміст:

server {
    listen 80;
    listen [::]:80;
    server_name ВАШ_ДОМЕН; # Замініть на ваш домен

    location / {
        return 301 https://$host$request_uri; # Перенаправляємо HTTP на HTTPS
    }
}

# Цей блок буде налаштований Certbot'ом автоматично після отримання SSL
# server {
#     listen 443 ssl http2;
#     listen [::]:443 ssl http2;
#     server_name ВАШ_ДОМЕН;
#
#     ssl_certificate /etc/letsencrypt/live/ВАШ_ДОМЕН/fullchain.pem;
#     ssl_certificate_key /etc/letsencrypt/live/ВАШ_ДОМЕН/privkey.pem;
#     ssl_trusted_certificate /etc/letsencrypt/live/ВАШ_ДОМЕН/chain.pem;
#
#     # Інші SSL-налаштування для безпеки
#     ssl_protocols TLSv1.2 TLSv1.3;
#     ssl_prefer_server_ciphers off;
#     ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";
#     ssl_session_cache shared:SSL:10m;
#     ssl_session_timeout 1h;
#     ssl_session_tickets off;
#     ssl_stapling on;
#     ssl_stapling_verify on;
#     resolver 8.8.8.8 8.8.4.4 valid=300s;
#     resolver_timeout 5s;
#
#     add_header X-Frame-Options "SAMEORIGIN" always;
#     add_header X-Content-Type-Options "nosniff" always;
#     add_header X-XSS-Protection "1; mode=block" always;
#     add_header Referrer-Policy "no-referrer-when-downgrade" always;
#     add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
#
#     location / {
#         proxy_pass http://127.0.0.1:8080; # Перенаправляємо на TTRSS контейнер
#         proxy_set_header Host $host;
#         proxy_set_header X-Real-IP $remote_addr;
#         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
#         proxy_set_header X-Forwarded-Proto $scheme;
#         proxy_buffering off;
#         proxy_request_buffering off;
#     }
#
#     # Заборона доступу до прихованих файлів
#     location ~ /\.ht {
#         deny all;
#     }
# }

Створіть символічне посилання на цей файл у sites-enabled та перевірте конфігурацію Nginx:

sudo ln -s /etc/nginx/sites-available/ВАШ_ДОМЕН.conf /etc/nginx/sites-enabled/
sudo nginx -t # Перевіряємо синтаксис конфігу Nginx

Якщо помилок немає, перезапустіть Nginx:

sudo systemctl restart nginx

4. Отримання SSL-сертифіката з Certbot

Тепер отримаємо SSL-сертифікат для вашого домену за допомогою Certbot. Переконайтеся, що ваш домен вже вказує на IP-адресу вашого VPS.

sudo certbot --nginx -d ВАШ_ДОМЕН # Замініть на ваш домен

Дотримуйтесь інструкцій Certbot. Він запитає ваш email для сповіщень та згоду з умовами. Після успішного виконання Certbot автоматично змінить ваш файл конфігурації Nginx, додавши блок server для HTTPS та налаштувавши SSL.

Перевірте, що автоматичне поновлення сертифікатів працює:

sudo certbot renew --dry-run # Тестовий запуск поновлення

Якщо тестовий запуск пройшов успішно, Certbot налаштував cron-завдання для автоматичного поновлення сертифікатів.

5. Перевірка працездатності

Відкрийте у браузері https://ВАШ_ДОМЕН. Ви маєте побачити сторінку входу Tiny Tiny RSS. Логін за замовчуванням: admin, пароль: password. Обов'язково змініть пароль одразу після першого входу!

Всередині TTRSS перейдіть до "Preferences" -> "Feeds" та спробуйте додати кілька RSS-стрічок, щоб переконатися, що вони оновлюються.

Ви також можете перевірити доступність сервісу за допомогою curl з сервера:

curl -I https://127.0.0.1:8080 # Перевіряємо доступ до TTRSS через внутрішній порт

Або, якщо ви хочете перевірити через Nginx (з хоста):

curl -I https://ВАШ_ДОМЕН # Перевіряємо доступ через Nginx та HTTPS

Переконайтеся, що заголовки відповіді показують успішне з'єднання (наприклад, HTTP/2 200).

Резервне копіювання та обслуговування

Регулярне резервне копіювання — критично важлива частина будь-якого продакшн-сервісу. Для Tiny Tiny RSS необхідно створювати резервні копії бази даних та користувацьких даних.

1. Що резервувати

• База даних PostgreSQL: Містить усі ваші стрічки, статті, налаштування, користувачів. Це найважливіша частина.
• Конфігураційні файли TTRSS: Хоча ми використовуємо змінні середовища, якщо ви вносили зміни до config.php або інших файлів, їх потрібно резервувати.
• Дані користувачів (feed-icons): Каталог ttrss_data, куди монтуються іконки стрічок.
• Конфігурація Nginx та Certbot: Файли /etc/nginx/sites-available/ВАШ_ДОМЕН.conf та /etc/letsencrypt/.

2. Простий скрипт авторезервування

Створимо простий скрипт, який буде створювати резервні копії бази даних PostgreSQL та важливих файлів.

nano ~/ttrss/backup_ttrss.sh

Вставте наступний вміст, замінивши ВАШ_ДОМЕН на ваш домен та ваш_очень_надежный_пароль_для_бд на пароль від вашої БД:

#!/bin/bash

# --- НАЛАШТУВАННЯ ---
BACKUP_DIR="/var/backups/ttrss"
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
DB_CONTAINER="ttrss-db-1" # Ім'я контейнера бази даних (можна переглянути через 'docker ps')
DB_USER="ttrss_user"
DB_NAME="ttrss_db"
DB_PASSWORD="ваш_очень_надежный_пароль_для_бд" # Пароль від БД

# Каталог з даними TTRSS
TTRSS_DATA_DIR="/var/lib/docker/volumes/ttrss_ttrss_data/_data" # Шлях до volume ttrss_data

# Каталог з конфігурацією Nginx та Certbot
NGINX_CONF_DIR="/etc/nginx/sites-available"
LETSENCRYPT_DIR="/etc/letsencrypt"
COMPOSE_FILE_PATH="/home/ваш_пользователь/ttrss/docker-compose.yml" # Шлях до docker-compose.yml

# --- СТВОРЕННЯ КАТАЛОГУ ДЛЯ РЕЗЕРВНИХ КОПІЙ ---
mkdir -p "$BACKUP_DIR"

# --- РЕЗЕРВНЕ КОПІЮВАННЯ БАЗИ ДАНИХ ---
echo "[$TIMESTAMP] Створення резервної копії бази даних PostgreSQL..."
docker exec -e PGPASSWORD="$DB_PASSWORD" "$DB_CONTAINER" pg_dump -U "$DB_USER" -d "$DB_NAME" -Fc > "$BACKUP_DIR/ttrss_db_$TIMESTAMP.dump"
if [ $? -eq 0 ]; then
    echo "[$TIMESTAMP] Резервна копія бази даних успішно створена: $BACKUP_DIR/ttrss_db_$TIMESTAMP.dump"
else
    echo "[$TIMESTAMP] ПОМИЛКА: Не вдалося створити резервну копію бази даних."
fi

# --- РЕЗЕРВНЕ КОПІЮВАННЯ ДАНИХ TTRSS (feed-icons) ---
echo "[$TIMESTAMP] Копіювання даних TTRSS (feed-icons)..."
tar -czf "$BACKUP_DIR/ttrss_data_$TIMESTAMP.tar.gz" -C "$TTRSS_DATA_DIR" .
if [ $? -eq 0 ]; then
    echo "[$TIMESTAMP] Резервна копія даних TTRSS успішно створена: $BACKUP_DIR/ttrss_data_$TIMESTAMP.tar.gz"
else
    echo "[$TIMESTAMP] ПОМИЛКА: Не вдалося створити резервну копію даних TTRSS."
fi

# --- РЕЗЕРВНЕ КОПІЮВАННЯ КОНФІГУРАЦІЇ NGINX та Certbot ---
echo "[$TIMESTAMP] Копіювання конфігурації Nginx..."
cp "$NGINX_CONF_DIR/ВАШ_ДОМЕН.conf" "$BACKUP_DIR/nginx_ВАШ_ДОМЕН_conf_$TIMESTAMP"
if [ $? -eq 0 ]; then
    echo "[$TIMESTAMP] Резервна копія Nginx успішно створена."
else
    echo "[$TIMESTAMP] ПОМИЛКА: Не вдалося створити резервну копію Nginx."
fi

echo "[$TIMESTAMP] Копіювання конфігурації Certbot..."
tar -czf "$BACKUP_DIR/letsencrypt_conf_$TIMESTAMP.tar.gz" -C "$LETSENCRYPT_DIR" .
if [ $? -eq 0 ]; then
    echo "[$TIMESTAMP] Резервна копія Certbot успішно створена."
else
    echo "[$TIMESTAMP] ПОМИЛКА: Не вдалося створити резервну копію Certbot."
fi

echo "[$TIMESTAMP] Копіювання docker-compose.yml..."
cp "$COMPOSE_FILE_PATH" "$BACKUP_DIR/docker-compose_$TIMESTAMP.yml"
if [ $? -eq 0 ]; then
    echo "[$TIMESTAMP] Резервна копія docker-compose.yml успішно створена."
else
    echo "[$TIMESTAMP] ПОМИЛКА: Не вдалося створити резервну копію docker-compose.yml."
fi

# --- ОЧИЩЕННЯ СТАРИХ РЕЗЕРВНИХ КОПІЙ (зберігаємо останні 7 днів) ---
echo "[$TIMESTAMP] Видалення старих резервних копій (старших за 7 днів)..."
find "$BACKUP_DIR" -type f -name "*.dump" -mtime +7 -delete
find "$BACKUP_DIR" -type f -name "*.tar.gz" -mtime +7 -delete
find "$BACKUP_DIR" -type f -name "*.yml" -mtime +7 -delete
find "$BACKUP_DIR" -type f -name "*_conf_*" -mtime +7 -delete
echo "[$TIMESTAMP] Очищення завершено."

echo "[$TIMESTAMP] Процес резервного копіювання завершено."

Зробіть скрипт виконуваним:

chmod +x ~/ttrss/backup_ttrss.sh

3. Налаштування Cron для автоматичного резервного копіювання

Додайте скрипт до розкладу Cron для щоденного виконання:

crontab -e

Додайте наступний рядок в кінець файлу (наприклад, для запуску о 03:00 ночі щодня):

0 3 * * * /home/ваш_пользователь/ttrss/backup_ttrss.sh >> /var/log/ttrss_backup.log 2>&1

Збережіть та закрийте файл. Тепер резервні копії будуть створюватися автоматично.

4. Куди зберігати резервні копії (зовнішнє сховище)

Зберігати резервні копії на тому ж сервері, що й основний сервіс, небезпечно. У разі виходу з ладу сервера ви втратите і сервіс, і резервні копії. Рекомендується використовувати зовнішні сховища:

• S3-сумісне сховище: Хмарні сервіси, такі як AWS S3, Backblaze B2, DigitalOcean Spaces, пропонують надійне та недороге зберігання. Для їх використання можна інтегрувати скрипт з утилітами на кшталт awscli або rclone.
• Окремий VPS: Ви можете мати невеликий, дешевий VPS, куди за допомогою rsync або scp будуть копіюватися резервні копії.
• Локальний NAS/ПК: Якщо ви хочете зберігати резервні копії вдома, можна налаштувати rsync або scp для копіювання їх на ваш домашній сервер.

Приклад відправлення резервних копій на інший сервер через rsync (додайте до скрипту після створення архівів):

# --- ВІДПРАВЛЕННЯ РЕЗЕРВНИХ КОПІЙ НА ВІДДАЛЕНИЙ СЕРВЕР ---
REMOTE_USER="backup_user"
REMOTE_HOST="ваш_удаленный_сервер_ip"
REMOTE_PATH="/mnt/backups/ttrss/"

echo "[$TIMESTAMP] Відправлення резервних копій на віддалений сервер $REMOTE_HOST..."
rsync -avz "$BACKUP_DIR/" "$REMOTE_USER@$REMOTE_HOST:$REMOTE_PATH"
if [ $? -eq 0 ]; then
    echo "[$TIMESTAMP] Резервні копії успішно відправлені на віддалений сервер."
else
    echo "[$TIMESTAMP] ПОМИЛКА: Не вдалося відправити резервні копії на віддалений сервер."
fi

Переконайтеся, що на віддаленому сервері налаштована автентифікація за SSH-ключами для користувача backup_user.

5. Оновлення: rolling vs maintenance window

• Оновлення Docker-образів (rolling): Для TTRSS та PostgreSQL, оскільки вони працюють у Docker, оновлення відносно просте. Ви можете виконати docker compose pull для завантаження нових образів, а потім docker compose up -d для їх розгортання. Це можна робити без значного простою, оскільки Docker вміє gracefully перезапускати контейнери. Рекомендується перевіряти логи після оновлення.
• Оновлення системи (maintenance window): Оновлення самої операційної системи (sudo apt update && sudo apt upgrade -y) краще проводити у заздалегідь визначене "вікно обслуговування", коли навантаження на сервер мінімальне. Це може вимагати перезавантаження сервера, що призведе до короткочасного простою TTRSS.

Для автоматизації оновлення Docker-образів можна використовувати утиліти типу Watchtower, яка відстежує нові версії образів та автоматично оновлює запущені контейнери. Однак, для критично важливих сервісів краще контролювати оновлення вручну або через CI/CD пайплайни.

Вирішення проблем + FAQ

Який VPS-конфіг мінімально підійде?

Для Tiny Tiny RSS на одного-двох користувачів з помірною кількістю стрічок (до 1000) мінімально підійде VPS з 1 ядром CPU, 1 ГБ оперативної пам'яті та 20 ГБ SSD. Цього достатньо для роботи Docker-контейнерів TTRSS, PostgreSQL та Nginx, але без великого запасу. При збільшенні кількості користувачів або стрічок, рекомендується збільшити RAM та дисковий простір.

Що вибрати — VPS чи dedicated для цього завдання?

У переважній більшості випадків для Tiny Tiny RSS на кілька десятків користувачів достатньо VPS. Виділений сервер (dedicated) має сенс лише для дуже великих інсталяцій, що обслуговують сотні або тисячі користувачів, або якщо на сервері працюють інші ресурсоємні сервіси. VPS пропонує кращу гнучкість та економічність для більшості сценаріїв використання TTRSS.

TTRSS недоступний після встановлення, що робити?

Перевірте наступні кроки:

1. Переконайтеся, що Docker-контейнери запущені: docker compose ps. Усі сервіси повинні бути в статусі running (healthy).
2. Перевірте, що Nginx працює: sudo systemctl status nginx.
3. Перевірте конфігурацію Nginx: sudo nginx -t. Переконайтеся, що немає синтаксичних помилок.
4. Перевірте, що доменне ім'я вказує на ваш VPS: використовуйте ping ВАШ_ДОМЕН або онлайн-інструменти DNS-lookup.
5. Перевірте правила файрволу: sudo ufw status. Порти 80 та 443 повинні бути дозволені.
6. Спробуйте отримати доступ до TTRSS безпосередньо через внутрішній порт: curl -I http://127.0.0.1:8080 з сервера. Якщо це працює, проблема в Nginx або Certbot.

Мій SSL-сертифікат закінчився або не був виданий, що робити?

Сертифікати Let's Encrypt діють 90 днів. Certbot повинен автоматично їх продовжувати. Якщо сертифікат закінчився або не був виданий:

1. Переконайтеся, що ваш домен коректно вказує на IP-адресу VPS.
2. Перевірте конфігурацію Nginx: sudo nginx -t. Переконайтеся, що Nginx працює на порту 80 і може відповідати на запити Certbot.
3. Спробуйте оновити сертифікати вручну: sudo certbot renew --force-renewal.
4. Перевірте логи Certbot: sudo tail -f /var/log/letsencrypt/letsencrypt.log на наявність помилок.

Стрічки не оновлюються автоматично, хоча TTRSS працює.

Це може бути пов'язано з тим, що демон оновлення TTRSS не запущений або не має доступу до інтернету:

1. Перевірте, що в docker-compose.yml встановлена змінна TTRSS_DEFAULT_UPDATE_DAEMON: "true".
2. Переконайтеся, що контейнер TTRSS може отримати доступ до зовнішніх ресурсів. Перевірте логи контейнера: docker compose logs app.
3. Всередині TTRSS перейдіть до "Preferences" -> "Feeds" і спробуйте примусово оновити кілька стрічок.
4. Перевірте системний час VPS: date. Неправильний час може викликати проблеми з планувальником.

Docker Compose видає помилки при запуску.

Уважно прочитайте повідомлення про помилку. Часті причини:

1. Помилки синтаксису YAML: Переконайтеся, що відступи та структура файлу docker-compose.yml коректні. Використовуйте онлайн-валідатори YAML.
2. Проблеми з портами: Якщо порт 8080 вже зайнятий на хост-машині іншим сервісом, Docker не зможе його використовувати. Перевірте sudo lsof -i :8080.
3. Недостатньо ресурсів: Якщо у вас дуже мало оперативної пам'яті, контейнери можуть не запуститися. Перевірте docker compose logs для відповідного сервісу.
4. Неправильні змінні середовища: Переконайтеся, що паролі та доменні імена в docker-compose.yml вказані вірно.

Висновки та наступні кроки

Вітаємо! Ви успішно розгорнули та налаштували свій власний Tiny Tiny RSS сервер на VPS, використовуючи Docker, Nginx та PostgreSQL. Тепер у вас є потужний, приватний та повністю контрольований інструмент для агрегації та читання новинних стрічок. Ви освоїли сучасні підходи до розгортання веб-додатків, включаючи контейнеризацію, безпечне з'єднання через HTTPS та автоматичне резервне копіювання.

Куди рухатися далі?

• Налаштування плагінів: Вивчіть багату екосистему плагінів TTRSS для розширення функціоналу, наприклад, для інтеграції з іншими сервісами, покращення парсингу або додавання нових тем.
• Мобільний доступ: Встановіть один з мобільних додатків, що підтримують TTRSS API (наприклад, FeedMe для Android або TTRSS Reader для iOS), щоб читати стрічки з мобільних пристроїв.
• Моніторинг ресурсів: Встановіть систему моніторингу (наприклад, Prometheus + Grafana або Netdata) для відстеження використання ресурсів вашого VPS та продуктивності TTRSS, щоб бути готовим до масштабування.