lifeexample, ну с таким подходом да, может быть будет непросто. Но просто для примера как у нас это решают:
1. Все сервисы регистрируются в consul с помощью containerpilot (или если приложение нашей разработки то оно само может уметь).
2. В качестве прокси используется envoy, который умеет много вещей на тему динамической конфигурации.
3. Для envoy написан специальный Envoy Management Server, который снабжает его конфигурацией по правилам.
4. Появление/изменение/переезд контейнеров между датацентрами прозрачно отражается на работе всех сервисов.
5. До кучи envoy автоматом обновляет сертификаты из HashiCorp Vault, так что при перевыпуске их не нужно ничего рестартить, всё прозрачно взлетает автоматом.
Правда, сейчас не исключено, что новые проекты будем просто пускать в кубере.
Иоанн, это не почта, а система для коллаборативной работы (в основном для разработчиков, но можно использовать и для других задач). Если нужна именно почта (тем более если в том числе для общения с внешними пользователями), то не подходит никак. Не говоря уже о том, что ставится redmine где-то на один отдельный сервер.
Иоанн, после беглого гугления я бы посмотрел на https://www.hmailserver.com, бесплатный, выглядит красиво, может ли он распределять почту per domain я не понял, но документация у него довольно большая.
1. Старый уважаемый почтовый сервер с конфигом для наркоманов, лучше с ним не связываться.
2. Просто компонент любого почтовика (sendmail/postfix/exim/...), который служит низкоуровневым агентом для отправки почты из софта и скриптов.
В списке есть postfix/exim - вот их чаще всего и используют в наше время. Но они обычно используются на LInux/UNIX-серверах, а в данном случае я подозреваю нужно решение для винды.
hellmagic, для докера понятие "куда ставится" имеет мало смысла. Обычно докер всё своё хозяйство хранит в /var/docker, но это можно переделать. Ну и лазать туда смысла мала, потому что без поллитра не разберёшься, что там лежит, а уж сломать можно только так.
Советую освоить базовые мануалы по докеру, многое станет понятнее.
mvk843, я конкретно с маркетинговым API не работал, но в Graph API даже если данные есть, то их необязательно покажут в дефолтном запросе. А вот дальше вопрос, что будет при явном указании field. Может ругнуться, что такого field в такой node нет, может ругнуться что к этому field нет прав (тогда нужно проходить домодерацию). Ещё может оказаться, что получение location зависит от privacy-настроек пользователя.
Полгода назад Facebook для Pages API закрыл получение имени и аватарки пользователей без получения отдельного модерируемого разрешения. Пришлось тогда нашему приложению проводить модерацию, чтобы вернуть. Персональные данные, все дела... Может быть, тут то же самое?
Александр Колотов, ну так в запросе photo:[] - пустой список. В чём проблема не понять, тем более в приведённом коде вызова saveWallPhoto не видно. Кстати, я не уверен, что upload_url не одноразовый, что через него можно загрузить несколько картинок, но не проверял.
Так это и делается, выясняем какой Exception случается в подобной ситуации и оборачиваем в try: except ThatAnnoyingException: где обрабатываем (например, помечаем пользователя как неактивного в своей базе).
70 Гб - это вообще не гигантский объём. Люди оперируют террабайтами и даже больше. Главная проблема не в объёме таблицы, а в том, чтобы не читать её целиком (full scan) при выполнении запроса. И вот тут главная фигня: одно только условие like '%слово%' в любом случае требует просмотреть каждую строку, значит, будет full scan. Обычные индексы по этому полю строить бесполезно. Есть всякие полнотекстовые, но в общем случае их тоже надо правильно готовить, чтобы работало приемлемо. Решение может зависеть от задачи. Например, если это ключевые слова в виде текстовой строки с пробелами или иными разделителями, то их можно вынести в отдельную таблицу отдельными строками и проиндексировать там, полнотекстовый поиск тут будет излишним.
kolotovalexander, да, надо завести standalone-приложение. Можно использовать чужое (как предлагает vkhost.github.io), но только осторожно, только через надёжные приложения. Я бы создал своё, потому что это несложно и в дальнейшем твои действия будут к этому приложению привязаны.
Главное: нужно указать все нужные разрешения и обязательно среди них offline, чтобы токен работал даже тогда, когда твой пользователь не будет находиться на сайте vk. А лишние разрешения лучше убрать.
kolotovalexander, у каждого метода API свои ограничения, некоторые можно с ключом сообщества, некоторые нельзя. Постить на стену можно только с ключом пользователя, чтобы скрыть имя постящего - надо использовать параметр from_group=1 (в приведённом примере он используется).
1. Все сервисы регистрируются в consul с помощью containerpilot (или если приложение нашей разработки то оно само может уметь).
2. В качестве прокси используется envoy, который умеет много вещей на тему динамической конфигурации.
3. Для envoy написан специальный Envoy Management Server, который снабжает его конфигурацией по правилам.
4. Появление/изменение/переезд контейнеров между датацентрами прозрачно отражается на работе всех сервисов.
5. До кучи envoy автоматом обновляет сертификаты из HashiCorp Vault, так что при перевыпуске их не нужно ничего рестартить, всё прозрачно взлетает автоматом.
Правда, сейчас не исключено, что новые проекты будем просто пускать в кубере.