Kkeiv Jan 21 at 21:24

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

Easy

6 min

7.4K

HostingSystem administration*

+10

Comments 15

szanislo Jan 21 at 21:46

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

Kkeiv Jan 21 at 21:53

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

Framework Jan 21 at 22:08

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

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

Framework Jan 21 at 22:14

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

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

Kkeiv Jan 21 at 22:25

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

Framework Jan 21 at 22:32

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

Kkeiv Jan 21 at 22:50

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

u007 Jan 21 at 23:11

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

Kkeiv Jan 22 at 09:41

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

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

bnidia Jan 22 at 09:20

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

Eklykti Jan 21 at 23:25

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

Kkeiv Jan 22 at 09:25

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

in_heb Jan 22 at 01:12

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

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

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

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

ky0 Jan 22 at 07:17

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

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

-1

abagnale Jan 22 at 12:22

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

Show the best of all time