ky0

Но я бы хотел научиться делать следующее. Запустить БОТА+БАЗУ ДАННЫХ на докере.

Контейнеризация приложений предполагает разделение сщностей - а вы зачем-то хотите их рядом засунуть.

Это уже не говоря о том, что СУБД в докере - идея не очень хорошая в принципе, о чём было неоднократно и подробно описано.

Вы уверены, что вам нужно именно так?

location /api/ {
proxy_pass http://127.0.0.1:8000/;

В такой конфигурации внутрь проваливается запрос не /api, а просто /. В противном случае - уберите слэш в конце директивы proxy_pass.

P. S. - раз у вас определён апстрим, странно не использовать его в proxy_pass:

proxy_pass http://backend/;

Ноутбук, линукс, ошибки ACPI при установке - ммм, классика... Что могло пойти не так?

Наделать условий с регулярками, обходящими соответствующий заголовок. Но вообще это не самый кошерный способ использования нгинкса - обычно подобную логику оставляют внутри приложения.

В Гитлабе есть секреты, куда, помимо прочего, можно положить и SSH-ключи.

Но вообще, раз у вас на хостах уже запущены раннеры - значит, доступ уже есть и достаточно добавить пользователю gitlab-runner нужные права, например, через sudo.

В документации написано следующее:

Файлы содержат SQL-скрипт, создающий базу данных demo и наполняющий её данными (фактически, это резервная копия, созданная утилитой pg_dump). Обратите внимание, что при установке существующая база данных demo будет удалена и создана заново! Владельцем базы данных demo станет пользователь СУБД, выполнявший скрипт.

Дамп, созданный с помощью pg_dump восстанавливает с помощью утилиты pg_restore.

Пгадмин выкиньте, не привыкайте к плохому.

location /api {
proxy_pass
}

location / {
что там вам нужно
}

Зачем вам if? Сделайте отдельный серверный блок для хоста без www и добавьте в него безусловный редирект.

Ну так настройки веб-сервера покажите - может, там шрифтовые расширения другим локейшеном обрабатываются, к которому не применяются соответствующие заголовки.

Ну, так напишите простецкий скрипт, который бы складывал в какой-нибудь файл состояние и периодически сравнивал его содержимое с результатами пинга. Условно, если в файле 0, а пинг идёт - сообщать. Если в файле 1, а пинг не идёт - тоже.

Если у вас всё это в рамках единой инфраструктуры - то непонятно, зачем столько DNS-серверов. Современные роутеры вполне умеют либо форвардить запросы, либо и вовсе становиться slave-серверами. А раз источник один - не будет и никаких проблем вида "тут резолвится, тут не резолвится".

Нгинкс - это веб-сервер. Для форварда трафика общего назначения стоит использовать другие инструменты, да хотя бы тот же iptables/nftables.

Не делайте ничего сложнее селектов через верморду, а лучше выкиньте её вообще.

pg_dump -U postgres -Fc merch_telegram_bot_db > test.backup
createdb -U postgres -E UNICODE merch_telegram_bot_db
pg_restore -U postgres -j 2 -d merch_telegram_bot_db test.backup

Судя по логам - у вас какие-то проблемы с сетевой связностью до хоста. Либо правда что-то с сетью, либо надо покурить настройки заббикс-сервера на предмет количества процессов-сборщиков, памяти и т. д.