Не сложнее чем freepbx, при этом freepbx потребляет заметно больше ресурсов, да и в принципе избыточен для целей автора. Freepbx исключительно для тех, кому проще в web интерфейсе натыкать чем в консоли, в остальном ванильный астер в docker контейнере куда лучше будет для этих целей.
Как уже выше написали, у tailscale есть классная open source замена - headscale, но у них нет своих собственных клиентов, приходится пользоваться клиентами tailscale, а с ними в РФ уже проблемы возникают. По поводу того что WG нещадно блочат провайдеры, есть реальный кейс когда заблочили ipsec до AWS, а WG без проблем работает, причём не только до AWS, но и до hetzner. В целом, по поводу использования голого WG для клиентов весьма специфический кейс. Для небольшой команды наверное ок, в компании от 100 и более человек есть огромная вероятность что создавать ключи и MR будет один человек, потому что пользователи либо не смогут, либо не захотят это делать. И тут уже проще какой-нибудь open source pritunl развернуть, тем более что там и WG тоже есть из коробки.
Нет подводных камней кроме производительности такого решения. Видел даже single node single drive на виртуалке в проде, с бэкапом данных с помощью restic в s3 облака. И всё это работает уже несколько лет без особых проблем.
У Алексея Плетнева есть два видео с конференции Highload++ на ютюбе, он там тоже про вариант 4х4 рассказывает как об оптимальном. Пулы дисков у них презентуются с СХД, что позволяет динамически увеличивать объём S3 хранилища, не добавляя при этом новые пулы в самом minio. Я бы дополнил эту статью отказоустойчивостью проксирующего фронта для minio, обычно это nginx или angie, и важно чтобы он был всегда доступен.
Это не мониторинг и алертинг к сожалению, а просто периодические отчёты в тг. Реализовать exporter для Prometheus на go иди python не так сложно, тем более что логика уже вся описана в скриптах. Хотя, если погуглить, то всё уже давно есть. А про этот экспортёр даже статья на хабре имеется.
Спасибо за статью, было интересно, особенно с точки зрения финансовой составляющей. 50-200 серверов в контексте данной статьи это что конкретно, физические серверы, VM в cloud или хосты k8s?
Это удобно, описал всё в compose.yml и одной командой запустил весь стэк. Захотел всё потушить или удалить тоже достаточно пары команд. Воспроизводимость, простота миграции на другой хост, для этого достаточно перенести docker тома и сам файл compose.yml на другой хост. Очень удобно и просто настроить и пользоваться мониторингом контейнеров как отдельных сервисов, что упрощает дебаг в будущем. Версии пакетов не конфликтуют с другими сервисами хостовой ОС, для обновления, достаточно изменить версию образа. Можно тонко настраивать лимиты по ресурсам для отдельных контейнеров и т.д. и т.п. Тем более что nextcloud отлично работает в docker и в репозиториях на github всё уже есть, изобретать велосипед не придётся.
Это всё понятно, но зачем 480гб в зеркальном RAID под ОС использовать не понятно. Почему не 120 или 240? Или у вас там временные файлы на системный диск интенсивно пишутся? Ну да ладно, спишем это на типовую конфигурацию серверов вашего поставщика.
Интересно, не использование СХД это действительно изначально целевое решение или больше от безысходности, так как те же Lenovo уровня enterprise проблематично в РФ притащить, а "импортозамещенные" по цене "крыла сбитого Боинга"?
Проходил недавно собес в одну немаленькую компанию, первый этап с hr - OK. Второй этап, технический скрининг - интервьюер опоздал на 10 минут, после того как написал hr, он подключился к встрече. Третий этап, техническое собеседование на 1.5 часа - ждал 20 минут, никто не подключился, написал hr, ответила что разберерется в сложившейся ситуации, и вот уже 24 часа не ответа ни привета. У меня такое впервые.
ПО можно легко установить на чистый сервер, достать из сейфа ленты, воткнуть в библиотеку и просканировать. Затем восстановить необходимые данные. По крайней мере с Symantec backup exec это так работало когда-то.
Не сложнее чем freepbx, при этом freepbx потребляет заметно больше ресурсов, да и в принципе избыточен для целей автора. Freepbx исключительно для тех, кому проще в web интерфейсе натыкать чем в консоли, в остальном ванильный астер в docker контейнере куда лучше будет для этих целей.
А зачем использовать для таких целей тяжёлую артиллерию в виде freepbx, если есть ванильный астериск без лишних заморочек?
У автора две статьи, одна из них про настройку мониторинга дисков).
То что циска висела не на стандартном 22 порту ssh уже моё почтение сетевикам)).
Как уже выше написали, у tailscale есть классная open source замена - headscale, но у них нет своих собственных клиентов, приходится пользоваться клиентами tailscale, а с ними в РФ уже проблемы возникают. По поводу того что WG нещадно блочат провайдеры, есть реальный кейс когда заблочили ipsec до AWS, а WG без проблем работает, причём не только до AWS, но и до hetzner. В целом, по поводу использования голого WG для клиентов весьма специфический кейс. Для небольшой команды наверное ок, в компании от 100 и более человек есть огромная вероятность что создавать ключи и MR будет один человек, потому что пользователи либо не смогут, либо не захотят это делать. И тут уже проще какой-нибудь open source pritunl развернуть, тем более что там и WG тоже есть из коробки.
Нет подводных камней кроме производительности такого решения. Видел даже single node single drive на виртуалке в проде, с бэкапом данных с помощью restic в s3 облака. И всё это работает уже несколько лет без особых проблем.
У Алексея Плетнева есть два видео с конференции Highload++ на ютюбе, он там тоже про вариант 4х4 рассказывает как об оптимальном. Пулы дисков у них презентуются с СХД, что позволяет динамически увеличивать объём S3 хранилища, не добавляя при этом новые пулы в самом minio. Я бы дополнил эту статью отказоустойчивостью проксирующего фронта для minio, обычно это nginx или angie, и важно чтобы он был всегда доступен.
Это не мониторинг и алертинг к сожалению, а просто периодические отчёты в тг. Реализовать exporter для Prometheus на go иди python не так сложно, тем более что логика уже вся описана в скриптах. Хотя, если погуглить, то всё уже давно есть. А про этот экспортёр даже статья на хабре имеется.
Спасибо за статью, было интересно, особенно с точки зрения финансовой составляющей. 50-200 серверов в контексте данной статьи это что конкретно, физические серверы, VM в cloud или хосты k8s?
Это удобно, описал всё в compose.yml и одной командой запустил весь стэк. Захотел всё потушить или удалить тоже достаточно пары команд. Воспроизводимость, простота миграции на другой хост, для этого достаточно перенести docker тома и сам файл compose.yml на другой хост. Очень удобно и просто настроить и пользоваться мониторингом контейнеров как отдельных сервисов, что упрощает дебаг в будущем. Версии пакетов не конфликтуют с другими сервисами хостовой ОС, для обновления, достаточно изменить версию образа. Можно тонко настраивать лимиты по ресурсам для отдельных контейнеров и т.д. и т.п. Тем более что nextcloud отлично работает в docker и в репозиториях на github всё уже есть, изобретать велосипед не придётся.
Развернуть nextcloud в облаке догадались, а использовать для этого docker/docker-compose нет. Хотя в целом для рекламы облака сойдёт).
В чем сложность настроить мониторинг и алертинг токенов? Есть даже готовый экспортер на гитхабе.
Любопытства ради, почему ушли из Softline проработав всего полгода? Как на это отреагировал следующий работодатель?
Я когда-то сделал на коленке парсинг тг каналов по ключевым словам. Давно его не обновлял, но может кому-то пригодится.
Это всё понятно, но зачем 480гб в зеркальном RAID под ОС использовать не понятно. Почему не 120 или 240? Или у вас там временные файлы на системный диск интенсивно пишутся? Ну да ладно, спишем это на типовую конфигурацию серверов вашего поставщика.
А это не оверхэд?
Интересно, не использование СХД это действительно изначально целевое решение или больше от безысходности, так как те же Lenovo уровня enterprise проблематично в РФ притащить, а "импортозамещенные" по цене "крыла сбитого Боинга"?
В крупных компаниях наверняка за выступления на конференциях есть материальные бонусы. Вот вам и мотивация.
n8n можно и локально развернуть, в том же docker-compose. С n8n не работал толком, но уж очень сильно на apache airflow похоже.
Проходил недавно собес в одну немаленькую компанию, первый этап с hr - OK. Второй этап, технический скрининг - интервьюер опоздал на 10 минут, после того как написал hr, он подключился к встрече. Третий этап, техническое собеседование на 1.5 часа - ждал 20 минут, никто не подключился, написал hr, ответила что разберерется в сложившейся ситуации, и вот уже 24 часа не ответа ни привета. У меня такое впервые.
ПО можно легко установить на чистый сервер, достать из сейфа ленты, воткнуть в библиотеку и просканировать. Затем восстановить необходимые данные. По крайней мере с Symantec backup exec это так работало когда-то.