nedland, скорее всего проблема в том, что надо использовать media_id, а не прямые ссылки на файлы. Вот прямые ссылки регулярно протухают, а media_id не должен.
Для начала проверить как картинки добавлены в письмо. Если по внешним ссылкам - многие почтовые клиенты нельзя уговорить их открывать вообще никак. Потому что это позволяет контролировать открытие письма и выдаёт IP пользователя серверу. Что очень нехорошо с точки зрения безопасности.
Вместо это картинки надо делать аттачами к письму. Тогда они будут показываться.
Не надо верить людям, которые рассказывают сказки про "это не путь". В случае minio - это именно путь! Надо сразу иметь в голове тот механизм, который minio на самом деле использует для хранения данных. А minio хранит каждый бакет как каталог, в котором путь отражается в иерархии каталогов на файловой системе и конечный файл представляет из себя ещё один каталог, внутри которого два файла: json с метаданными и шифрованный блоб с содержимым.
Если в одном каталоге (в одном уровне иерархии) у minio будут миллионы записей, а сами данные хранятся на HDD (распространённая ситуация для хранения), то регулярно будут начинаться дикие тормоза на том, что операционная система будет вычитывать этот каталог с диска в память. И лучше не решать это установкой SSD, лучше решать это правильно, не создавая такую ситуацию с самого начала. Тем более что это совсем несложно. Достаточно раскладывать файлы по каталогам на основе даты, или диапазонов id, или хеша от имени (например, берём md5 и первые 2-3 символа - хеш), или по каким-то ещё логическим признакам в бизнес-логике.
(Это не какая-то глубоко теоретическая ситуация, мы реально столкнулись с проблемами из-за такой вот невнимательности, которые ещё и повлияли на другие приложения в том же кластере)
Что касается подхода к разворачиванию, нужно исходить из числа файлов, объёма файлов, числа запросов к ним, из необходимости геодоступности для отдельных пользователей, итд итп. Никаких универсальных ответов тут нет, без подробностей о предполагаемом профиле использования советовать нечего. В большинстве случаев вообще ничего особенно не нужно, может быть вполне достаточно одного инстанса.
С точки зрения minio два каталога в одном бакете и два бакета ничем не отличаются.
Пути к файлам в базе - да, лучше хранить именно так. Практика показывает, что в процессе жизненного цикла можно неоднократно изменить подход к организации хранения, и это будет наилучший способ обеспечить доступ к старым файлам без специальных усилий по их перекладыванию по новой. А новые файлы будут получать новый вид путей.
Временные ссылки - да, так их и используют часто. Сам minio их тоже не хранит, вся информация представлена в самой ссылке (время протухания и криптографическая подпись всего адреса). Поэтому можно хоть тысячу ссылок на один файл сделать - это никак не повредит производительности ни minio, ни вашего приложения.
Если делать проксирующий сервис (как тут в ответах посоветовали) - то да, так тоже делают - но рекомендую подойти к созданию такого аккуратно, тяп-ляп точно не надо. Иначе можно получить ситуацию, когда перед суперэффективным распределённым хранилищем наскоро написанный скрипт на php, который помрёт от сотни запросов или будет падать от любого чиха. Там может быть важно правильно обрабатывать partial content (поддерживать докачку) и всё такое. Между прочим, эффективность промышленных прокси-серверов (nginx, haproxy, envoy итд) по сравнению с наколенными поделками - это сильный аргумент в пользу того, чтобы свой проксирующий сервис не делать вообще. С другой стороны, откровенно показывать наружу, что фактически используется minio - это создавать риски целенаправленной атаки именно на minio. Ну, это вполне обычные риски, конечно, но их надо понимать.
я думаю в таком случае хотя бы письмо прислали, как владельцу домена
Нет, они никому ничего не присылают и вообще блочат втихаря, иногда даже ненадолго. Это чистое беззаконие, но увы, с этим ничего сделать нельзя. По закону они должны это делать только по решению суда, по факту же давно уже блокируют по желанию левой пятки любого чиновника.
Как вариант, можно использоать любое андроидное устростство и на нём запустить приложение, которое будет логгировать позицию. Можно даже на бортовой системе автомобиля попробовать (если там есть андроид в развлекательной системе ака "магнитола").
Можно было с самого начала делать ветку от branchOne. Можно попробовать сделать cherrypick нужных изменений (если всё аккуратно делать, получится как будто ветка от branchOne).
Но лучше всего, конечно, не писать новый код от неготового предыдущего, не создавать себе проблем на пустом месте. Потому что branchTwo может по итогам тестирования ещё раз меняться, и получишь дурацкую голвную боль по слиянию со своим кодом. Зачем это нужно?
Кеняка Кенякович, есть домены 2 уровня, владельцы которых продают в них поддомены. Например, можно купить домен в зоне msk.ru.
Если тебе принадлежит домен some-example.ru, то ты можешь в нём поддомены прописывать бесплатно и самостоятельно.
В принципе, можно у себя на DNS-сервере любой домен прописать - даже habr.com. Проблема в том, что никто в интернете не придёт на твой сервер с запросом имени habr.com. Потому что вместо этого придут на эти сервера:
habr.com. 36567 IN NS ns2.habradns.net.
habr.com. 36567 IN NS ns3.habradns.net.
habr.com. 36567 IN NS ns1.habradns.net.
nerdhhh, "виртуальные номера", особенно бесплатные, во многих сервисах уже "грязные" и не годятся для регистраций, потому что на них уже десятки раз регали Telegram WhatsApp и много чего другого. Так что если искать, то надёжнее платные и чтобы сервис продавал целенаправленно под Телеграм в долгосрочную и лучше бы была предусмотрена процедура возврата денег при неудачной регистрации.
.. Может в итоге оказаться проще пойти купить пару симок в ближайшем салоне.
nerdhhh, если это не будет делаться агрессивно (например, тысячами запросов в секунду), если для мониторинга, скажем, штучного числа личных каналов (а не всего интернета), то скорее всего даже не заметят.
Но я файлы только в Bot API посылал.