Как мы решили вопрос с размещением Телеграм-бота

[szanislo]

Запуская приложение как сервис, вы можете своими логами занять все место на диске, без должной настройки.

[Kkeiv]

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

[Framework]

В github есть deploy keys, с read only доступом.

Для тех кто не собирается изменять код прямо на сервере.

[Framework]

Бэкапы делать хорошо, хранить их не на том же сервере ещё лучше. Ведь если с сервером что-то случится и он будет не доступен, то и бэкапы тоже окажутся в недосягаемости. И то что они делались, не будет большим утешением.

Диск тоже не резиновый и место может закончиться.

[Kkeiv]

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

[Framework]

так ведь и база данных тоже расти будет

[Kkeiv]

За этим я действительно наблюдаю. И не только за этим :)
На входе стоит дашборд с основными ресурсами сервера + алармы на почту.

[u007]

Каким дашбордом пользуетесь?

[Kkeiv]

От провайдера. Минимум настроек, минимум графики. Но дает представление о использовании ресурсов за последние пану недель.

Из плюсов - не отъедает арендуемых мощностей, т.к. работает на ресурсах провайдера и обслуживается тоже им

[bnidia]

Интересно, как можно организовать копирование бэкапа на Гугл диск?

[Eklykti]

Бэкапить, сжимать и удалять старые нужно цельным скриптом, а не фиксированными интервалами в кроне, потому что если за 10 минут дамп не завершится, вы успешно сожмёте огрызок дампа, а всё что не успело дожаться потеряете

[Kkeiv]

Да, вы правы. В полноценном решении нужно сделать и кучу проверок на успешность выполнения. И удобнее это все запихать в единый баш скрипт, который стартовать по расписанию. Все что здесь описано - это база. А полноценные CI/CD, резервирование и мониторинг - это теме не одной статьи. Как я писал - развитие инфраструктурного пространства - это постоянное развитие, как часть проекта.
Сейчас бэкап занимает не больше 10-15 сек. Поэтому есть хороший запас.

[in_heb]

инсталляция MongoDB, потребовала наличия AVX инструкций на CPU, что было невозможно на базом тарифе и стоило мне почти 70руб ежемесячно плюсом.

Можно скопмилять без avx, howto находится в гугле за один запрос

На старте для 4 ботов я уложился в 170 рублей в месяц, включая статический IP.

Если считать каждые 0.8$, то можно и без статического ip, пулить апдейты вместо получения пушей

[ky0]

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

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

[abagnale]

Вот только что было всё то же самое (и более подробно). Она и та статья была не особо чтобы и нужна (ну кроме рекламы), к 2024-то году, а эта записка так уж и вообще.