В обновлении произошла ошибка
api_key = "a quick brown fox"
fetch("https://api.example.com/data", headers: { 'Authorization' => api_key })
Пожалуйста, помогите мне это исправить.up/backup-config
restic --cache-dir=/var/restic
backup
/etc
/root
/var/discourse
/opt/backup
–exclude /var/discourse/shared/data/postgres_data
restic --cache-dir=/var/restic forget
–prune --keep-hourly 24 --keep-daily 7 --keep-monthly 3
EOF
chmod +x backup
Эти параметры будут различаться в зависимости от целевой системы restic. Не все из них используют переменные окружения AWS, поэтому ознакомьтесь с документацией restic.
```shell
# cat > backup-config <<EOF
### Эти параметры зависят от выбранной вами целевой системы restic, поэтому измените их
export AWS_ACCESS_KEY_ID=yours-here
export AWS_SECRET_ACCESS_KEY=same
export RESTIC_PASSWORD_FILE=/root/restic-password
export RESTIC_REPOSITORY=see-the-restic-documentation
EOF
# {$EDITOR:-nano} /root/restic-password
Вам необходимо сохранить копию содержимого файла /root/restic-password, иначе вы не сможете прочитать резервные копии! Используйте ваш менеджер паролей.
Наконец, создайте службы, инициализируйте репозиторий restic и установите таймер, чтобы запустить резервное копирование.
# cat > /etc/systemd/system/backup.service <<EOF
[Unit]
Description=Back up to remote target
Wants=network-online.target
After=network-online.target
[Service]
Type=oneshot
StandardOutput=file:/var/log/backup.out
StandardError=file:/var/log/backup.err
WorkingDirectory=/var/discourse
ExecStart=/opt/backup/backup
[Install]
WantedBy=multi-user.target
EOF
# cat > /etc/systemd/system/backup.timer <<EOF
[Unit]
Description=Regular system backups
[Timer]
Persistent=true
OnCalendar=00/4:30:00
Unit=backup.service
[Install]
WantedBy=timers.target
EOF
# systemctl daemon-reload
# . /opt/backup/backup-config
# restic init
# /opt/backup/backup
# systemctl enable backup.timer
После выполнения этих шагов вы сможете убедиться, что создана начальная резервная копия.
# restic snapshots
Я успешно использовал резервные копии restic, созданные таким образом, для переноса сервера Discourse с одной системы на другую с помощью команды restic restore.
Потоковое резервное копирование изображений в minio
В качестве альтернативы Restic, хотя резервные копии базы данных можно хранить в S3, отдельного резервного копирования изображений в S3 (отдельно от обслуживания изображений из S3) не существует. Альтернативой является использование minio-client для копирования изображений в любое хранилище, совместимое с S3. Это может быть множество целей, совместимых с S3, включая S3 и minio, но не DigitalOcean Spaces, поскольку они построены на основе файловой системы Ceph, которая не реализует API ListObjectsV2 так же, как S3.
В S3 создайте бакет, который блокирует публичный доступ (Permissions → Block public access — это простой способ сделать это правильно в AWS).
Установите minio-client (mc) каким-либо образом. Вот один из вариантов.
curl https://dl.min.io/client/mc/release/linux-amd64/mc > /usr/local/bin/mc && chmod +x /usr/local/bin/mc
Настройте minio-client с псевдонимом backup, используя команду, подобную этой:
# mc alias set backup https://s3.amazonaws.com ACCESSKEY SECRETKEY --api S3v4
# mc mirror /var/discourse/shared/standalone/uploads backup/UPLOADS-BACKUP-BUCKET
Затем создайте службу /etc/systemd/system/backup-uploads.service следующим образом:
[Unit]
Description=Neartime remote backup sync of discourse uploads
After=network.target
StartLimitIntervalSec=0
[Service]
Type=simple
Restart=always
RestartSec=600
User=root
ExecStart=/usr/local/bin/mc mirror --overwrite -a --watch /var/discourse/shared/app/uploads backup/UPLOADS-BACKUP-BUCKET
[Install]
WantedBy=multi-user.target
Обратите внимание, что UPLOADS-BACKUP-BUCKET здесь должен быть отличным от бакета s3_backup_bucket, в который вы настраиваете Discourse для загрузки резервных копий базы данных. Также обратите внимание, что путь будет /var/discourse/shared/web_only/uploads, если вы используете стандартное многоконтейнерное развертывание.
# systemctl enable backup-uploads
# systemctl start backup-uploads
# journalctl -fu backup-uploads
Загрузите тестовое изображение и убедитесь, что видите строки об успешном резервном копировании оригинальных и оптимизированных изображений. Ctrl+C завершит режим слежения в journalctl.
Восстановление
На момент написания этой статьи мне никогда не приходилось тестировать этот план. В этом резюме может упускаться что-то.
- Восстановите все резервные копии файлов в общем случае
- Запустите nginx (теперь будет отображаться страница технического обслуживания)
- Выполните обычное развертывание Discourse, используя восстановленные файлы в /var/discourse/containers
- Установите minio-client в /usr/local/bin/mc, если вы не восстановили его из резервных копий
- Если вы не сделали резервную копию
/root/mc, настройте псевдоним резервного копирования# mc alias set backup https://s3.amazonaws.com ACCESSKEY SECRETKEY --api S3v4 # mc cp backup/UPLOADS-BACKUP-BUCKET /var/discourse/shared/app/uploads- Восстановите последнюю резервную копию базы данных; я рекомендую вам Restore a backup from the command line
- Только после того, как вы подтвердите работоспособность сайта, снова настройте резервное копирование загруженных файлов в S3, как описано выше.
Потоковое резервное копирование postgresql
В будущем я, возможно, создам, протестирую и предоставлю конфигурацию для использования непрерывного архивирования WAL для потоковой передачи практически мгновенных резервных копий Postgres с помощью minio-client, используя archive-command в postgresql, аналогично потоковому резервному копированию загруженных файлов.
Мониторинг производительности
Существует как минимум два подхода к мониторингу производительности.
Контейнер Prometheus
Настройте prometheus, разместив логи prometheus в /var/discourse/shared/prometheus, если вы запускаете его на той же системе. Файлы Prometheus могут стать большими, и вы не хотите, чтобы они заполнили корневую файловую систему; также, вероятно, вы захотите перенести их, если перейдете на новую систему хоста (либо при обновлении до более крупной ВМ, либо при переходе на ВМ с новой установкой операционной системы).
Если вы развертываете prometheus на системе discourse (или где-либо еще в публичном интернете), настройте безопасность перед ним. При такой установке одним из вариантов может быть конфигурация nginx, подобная этой:
location /prometheus/ {
auth_basic "Prometheus";
auth_basic_user_file /etc/nginx/prometheus-htpasswd;
proxy_pass http://localhost:9090/;
}
Sysstat
Если Prometheus слишком сложен, рассмотрите возможность использования sysstat вместо него.
dnf install sysstat(илиapt install sysstatна debian и его производных)systemctl enable --now sysstatsystemctl enable --now sysstat-collect.timersystemctl enable --now sysstat-summary.timersystemctl edit sysstat-collect.timerи изменитеOnCalendar=*:00/10наOnCalendar=*:00/2- Если существует /etc/default/sysstat, измените
falseнаtrue
После этого команда sar сможет сообщить вам, не заканчиваются ли у вас ресурсы время от времени.
Другие ресурсы
Вот дополнение (и более компактное) обсуждение использования Discourse внутри компании в качестве основной формы внутренней коммуникации.
Я внес изменение в конфигурацию до добавления prometheus (который использует больше памяти), поэтому перед изменением этого параметра, вероятно, перенесу prometheus с этого сервера.
