В Китае второй по величине банк China Construction Bank открыл отделение, в котором клиентов обслуживают роботы
Ну их роботами можно назвать только при очень бурном воображении. Как по мне (и глядя на синнет половина китайцев со мной согласны) это самый обычный интерактивный терминал, только в робото-подобном корпусе и даже без колес. Скорее всего очередной распил средств (тут такое еще чаще случается чем в России).
Другая часть этих настроек конечно должна быть проведена в настройках домена. Что к сожалению не всегда выполняется правильно. И поэтому почта часто попадает в серые и черные списки или отвергается некоторыми серверами.
Так я вот именно поэтому и спрашиваю — зачем? Настройка полноценного мейл-сервера, которому другие сервера будут доверять, это дело очень сложное (DNS A/AAAA, DNS PTR, DNS SPF это как минимум, еще добавим TLS, DKMS и прочее), что все достоинства использования контейнеров сходят на ноль, совсем.
При этом в интернете тысячи (ну или хотя бы сотни уж точно) сервисов, которые делают отправку почты через API банальным делом (например — AWS SES, не знаю какие сервисы для этого популярны в России).
Если надо отправить почту из приложения которое крутится внутри контейнера, можно:
а) подключиться к локальному MTA на хосте из докера (локально оно слушает всегда на 127.0.0.1:25)
или
б) отправлять по API через предназначенные для этого сервисы (а не заморачиваться с настройкой своего mail-сервера, а то адрес отправителя и IP очень быстро улетит в замечательный spam-blacklist)
Как мне кажется (и я и сам часто об этом задумываюсь) это о том что когда гугл только развивался, там было намного меньше (если вообще были) «эффективных менеджеров», и намного больше программистов. Но когда гугл стал популярен, то туда начали рваться всякие менеджеры и прочее непотребство и компания стала увязать в бюрократии. К тому же, по-моему мнению, в больших компаниях, те кто вообще не знают этого бизнеса и не понимают чем занимается компания могут легко спрятаться на уровне среднего звена менеджмента.
Это, конечно же, мое мнение, и другие могут быть с этим не согласны, но это мнение основано на моем опыте нескольких лет работы в одной достаточно крупной корпорации.
Там все сложнее чем намертво :) По моим тестам сначала они разрешают UDP для IP адреса, но при непрерывном трафике через 5 минут отрубают на несколько часов. Потом опять можно отправлять UDP. Но если они при этом детектят зашифрованный трафик на UDP, то IP попадает в черный список и весь международный трафик включая TCP и UDP отрубается на совсем (не уверен какая продолжительность бана, но точно больше месяца).
У такой географии есть простое объяснение — толпы «DevOps» инженеров, которые не знают основ администрирования и оставляют тысячи и более сервисов светить портами в интернет, сканировали, знаем ;) А, например, там нет Китая (где тоже все очень печально в этом плане), так как GFW намертво отсекает UDP, так как многие пытаются делать VPN via UDP.
Это я к тому что при нормальной установке Linux на сервер соответствующие пакеты которые бы добавили соответствующие модули ядра (cpufrequtils на Debian, например) не установлены по-умолчанию, а это означает что ваши тесты были проведены, мягко говоря, не в совсем корректном окружении. Я так же собеседовал и собеседую людей на различные роли. И все рвутся мне рассказать как же правильно настроить kubernetes, хотя когда их спрашиваешь банальные вещи (как работает swap, разница между статической и динамической линковкой, для чего используется strace и мой любимый — как работает OOM) смотрят на меня «глазами полными ужаса»
Дочитал до тюнинга «scaling_governor» как решения и бросил. Не уверен как остальным читателям, но мне вот именно этот момент и показал проблему DevOps. ОС на сервере настроена как для desktop/laptop, и вы пытаетесь на этом показать производительность production? Смешно. Вот этот как раз и есть настоящая беда, когда люди рвутся везде использовать новейшие buzzword'ы, но при этом не знают как еще настроить сервер для production.
А вы знаете китайский включая сленг и IT жаргонизмы на достаточном уровне? У них полно форумов (или как они их называют BBS). Самый крупный это www.csdn.net, и очень много региональных или узко-специализированных.
Но если вы думаете сделать «китайский хабр», то я вам 100% гарантию даю что не взлетит, по одной простой причине — государственный контроль над IT и телекоммуникациями, и иностранцам и иностранным компаниям там ничего не светит.
Так то да, nothing is perfect, но как мне кажется вся соль именно в том, что это уже устоявшиеся сервисы, со своей культурой и своей аудиторией. Делать что-то новое с целью заменить эти сервисы будет проблематично. Вопрос не в том, можно ли сделать, сделать можно все что угодно (ну или почти все), было бы желание, а в том, что нужно ли это той самой иностранной аудитории? И если их сейчас спросить, то ответ будет «нет, не нужно, есть же Reddit и HN».
Да бывают такие ситуации, тогда Wayback machine часто спасает, а если нет, то наверняка есть другие статьи по данному вопросу, а если уж совсем беда беда, то и на SO спросить не грех, как мне кажется.
Вы, наверное, веткой ошиблись, я не спрашивал почему и зачем, а высказал свою точку зрения как человек который читает в основном на английском, а на Хабр заходит чтобы русский язык не забыть.
Но я, так и быть, отвечу на ваш комментарий:
1) Мультиселект языка.
Так вы делают англо-язычный ресурс, или «для всех». Как мне кажется, «для всех» не взлетит. Не будет никто переводить на многие языки. Точно так же как никто не переводит вопросы/ответы с англ SO на русский SO.
2) Если статьи на языке пользователя нет, то он может выбрать, на каком из имеющихся читать. (+оповестить о переводе)
И как этот пользователь который не может найти статью на своем языке ее еще для начала найдет?
4) Галочка «только на языках, которыми я владею» в поиске / топе(тут мб тонкое место с поддержкой кучи топов)
А вот на этом пункте я немного задержусь. Я, как человек, который последние 10 лет работает только в англо-язычной среде в IT, вам замечу что такая ситуация (с плохим знанием англ., настолько что переводить надо) существует только в двух сообществах — русском IT и в китайском IT. Все другие сообщества в той или иной мере могут общаться на английском. Я не говорю про Европу. Я говорю про Вьетнам (очень большая популяция разработчиков), Индия и Пакистан (ну там то все понятно, колониальное прошлое сказывается), Таиланд, страны Центральной и Латинской Америк, и т.д. Как мне кажется (опять же как человеку, который прожил в России 20 лет до окончательно и бесповоротного переезда, а так же долгое время работающему с азиатскими странами) сказывается менталитет. В обоих случаях (Россия и Китай), сообщество концентрируется на 99% на внутренних ресурсах и думает что «мы и сами с усами» и «никто нам не указ» и «наши программисты самые программистые программисты». Хотя у Китая еще и цензура сказывается, но в России это тоже начинается как я слышал. В то же время все основные языки программирования, документация, конфигурация и т.д. изначально идут на англ., и далеко не все из них переведены хотя бы на 2-й язык. Так что для всех, кто хочет работать в IT, самым простым и оптимальным решением является учение английского языка, а не перевод статей на свой язык. Как результат, как мне кажется, вся эта идея с переводом на многие языки будет работать только на 50% и только для двух языков — русского и китайского.
Так что мое пожелание, это чтобы люди в российском IT учили (de facto) стандартный язык общения в IT, а не занимались переводами. Это лучше оставить профессиональным переводчикам.
Я потому и написал про Reddit, там же много тематических форумов где каждый может пропиарить свою статью в своем же уютном бложике на Wordpress (или на чем другом). Я подписался именно на те форумы, которые мне интересны, и оттуда и читаю.
Много авторов кросс-постят на Reddit и HackerNews. Или если автор только запостил в один из них, кто-нибудь другой запостит на другом ресурсе. Так что вроде ничего мимо не проходит.
И получится Reddit с кармой и другими свистелками. К тому же я вас уверяю, что на английском языке намного больше годных статей, именно поэтому половина [годных и технических] статей на Хабре это переводы.
Как то очень поверхностно и сумбурно. Многие вопросы не раскрыты, а другие написаны в стиле «ну потому что так, не будем углубляться». Хотя там на самом деле никак магии и нет и все очень просто объясняется если начать с основ. Вот бы кто-нибудь сделал такого же рода комиксы для всего сетевого стека, а не только для 10% от 4-го уровня…
За что же облачного провайдера линейкой бить, если создание свопа никто не ограничил и проблемы это не вызвало
За то что учат всех что «no swap, no problems», хотя это далеко не так. Мой пример как раз и написан для того чтобы показать что своп это такой же инструмент, которым нужно знать как и когда пользоваться. Может они (облачные провайдеры) и хотят как лучше, но получается «как всегда». Точно также как они (облачные провайдеры) по-умолчанию отключают SElinux на всех своих образах, ну а как-же, половина интернетов отключают (потому что не знают как им пользоваться), вот мы им и поможем, заранее для них отключим.
Учитывая отсутствие общего хранилища сессий и общей неготовности приложения к многонодовому исполнению
1. Я где-то написал про HTTP сессии? В этом контексте это TCP сессии. Если приложение убит ООМ что с ними случится? И какие такие «общие хранилища» для TCP сессий вы предлагаете?
2. Как подрядчик будет «продолжать получать деньги за предоставление некачественной услуги» если подрядчик проект сделал и испарился. Работаем мы с клиентом, подрядчика этого мы в глаза не видели.
3. JFYI: Я вроде нигде и не писал про «мучиться с разметкой диска». В том конкретном случае мы просто # dd if=/dev/null of=/swapfile bs=1M count=$(1024*20). Быстро и просто.
Им критически важно чтобы для всех пользователей был 100% uptime (даже если за счет задержек в ответах)
И как systemd restart=always или supervisord тут поможет? Те сессии, которые были открыты когда OOM случился отвалятся с ошибкой. Правильный подход будет — убрать ноду из LB, дождаться когда на ноде 0 сессий, прибить приложение и перезапустить. Своп помог оттянуть время ООМ чтобы все это можно было провернуть. Да — не оптимально и вручную, но это именно то что нужно клиенту и дало нам достаточно времени чтобы найти постоянное решение (тот самый unicorn-worker-killer).
За отключение свопа надо линейкой по рукам. Что там люди делают на своих личных машинах (где всякие Хромы и прочее непотребство крутится) это одно, а когда все облачные провайдеры предоставляют образы машин без свопа и в 99% случаев народ так с ними и работает это совершенно другая история.
Мой пример:
У одного из наших клиентов есть «очень серьезное приложение» (TM) написаное на RoR какими-то подрядчиками. Подрядчики эти уже больше года отказываются починить memory leak который случается стабильно раз в два дня и на большой скорости выжирает всю доступную память примерно за 5 минут, после чего ООМ убивал приложение.
До того как они к нам пришли за помощью оно (приложение) у них падало раза 3-4 на неделе на каждой из машин (10 серверов после HAproxy). Им критически важно чтобы для всех пользователей был 100% uptime (даже если за счет задержек в ответах). Времени среагировать просто нет (за 5 минут мы только первые сигналы увидим о том что память заканчивается).
Как временное решение — добавили своп 20ГБ на каждой из машин, vm.swappiness = 15.
Теперь у нас есть примерно 1 час чтобы среагировать на заканчивающуюся память. И больше времени для более стабильного решения.
В конце мы просто поставили unicorn-worker-killer gem и сконфигурировали его чтобы убивал worker процессы когда они отъедают больше чем X% памяти.
Так что медленный своп это в некоторых ситуациях скорее достоинство чем недостаток.
Ну их роботами можно назвать только при очень бурном воображении. Как по мне (и глядя на синнет половина китайцев со мной согласны) это самый обычный интерактивный терминал, только в робото-подобном корпусе и даже без колес. Скорее всего очередной распил средств (тут такое еще чаще случается чем в России).
Так я вот именно поэтому и спрашиваю — зачем? Настройка полноценного мейл-сервера, которому другие сервера будут доверять, это дело очень сложное (DNS A/AAAA, DNS PTR, DNS SPF это как минимум, еще добавим TLS, DKMS и прочее), что все достоинства использования контейнеров сходят на ноль, совсем.
При этом в интернете тысячи (ну или хотя бы сотни уж точно) сервисов, которые делают отправку почты через API банальным делом (например — AWS SES, не знаю какие сервисы для этого популярны в России).
Если надо отправить почту из приложения которое крутится внутри контейнера, можно:
а) подключиться к локальному MTA на хосте из докера (локально оно слушает всегда на 127.0.0.1:25)
или
б) отправлять по API через предназначенные для этого сервисы (а не заморачиваться с настройкой своего mail-сервера, а то адрес отправителя и IP очень быстро улетит в замечательный spam-blacklist)
Это, конечно же, мое мнение, и другие могут быть с этим не согласны, но это мнение основано на моем опыте нескольких лет работы в одной достаточно крупной корпорации.
Но если вы думаете сделать «китайский хабр», то я вам 100% гарантию даю что не взлетит, по одной простой причине — государственный контроль над IT и телекоммуникациями, и иностранцам и иностранным компаниям там ничего не светит.
Но я, так и быть, отвечу на ваш комментарий:
Так вы делают англо-язычный ресурс, или «для всех». Как мне кажется, «для всех» не взлетит. Не будет никто переводить на многие языки. Точно так же как никто не переводит вопросы/ответы с англ SO на русский SO.
И как этот пользователь который не может найти статью на своем языке ее еще для начала найдет?
А вот на этом пункте я немного задержусь. Я, как человек, который последние 10 лет работает только в англо-язычной среде в IT, вам замечу что такая ситуация (с плохим знанием англ., настолько что переводить надо) существует только в двух сообществах — русском IT и в китайском IT. Все другие сообщества в той или иной мере могут общаться на английском. Я не говорю про Европу. Я говорю про Вьетнам (очень большая популяция разработчиков), Индия и Пакистан (ну там то все понятно, колониальное прошлое сказывается), Таиланд, страны Центральной и Латинской Америк, и т.д. Как мне кажется (опять же как человеку, который прожил в России 20 лет до окончательно и бесповоротного переезда, а так же долгое время работающему с азиатскими странами) сказывается менталитет. В обоих случаях (Россия и Китай), сообщество концентрируется на 99% на внутренних ресурсах и думает что «мы и сами с усами» и «никто нам не указ» и «наши программисты самые программистые программисты». Хотя у Китая еще и цензура сказывается, но в России это тоже начинается как я слышал. В то же время все основные языки программирования, документация, конфигурация и т.д. изначально идут на англ., и далеко не все из них переведены хотя бы на 2-й язык. Так что для всех, кто хочет работать в IT, самым простым и оптимальным решением является учение английского языка, а не перевод статей на свой язык. Как результат, как мне кажется, вся эта идея с переводом на многие языки будет работать только на 50% и только для двух языков — русского и китайского.
Так что мое пожелание, это чтобы люди в российском IT учили (de facto) стандартный язык общения в IT, а не занимались переводами. Это лучше оставить профессиональным переводчикам.
Много авторов кросс-постят на Reddit и HackerNews. Или если автор только запостил в один из них, кто-нибудь другой запостит на другом ресурсе. Так что вроде ничего мимо не проходит.
За то что учат всех что «no swap, no problems», хотя это далеко не так. Мой пример как раз и написан для того чтобы показать что своп это такой же инструмент, которым нужно знать как и когда пользоваться. Может они (облачные провайдеры) и хотят как лучше, но получается «как всегда». Точно также как они (облачные провайдеры) по-умолчанию отключают SElinux на всех своих образах, ну а как-же, половина интернетов отключают (потому что не знают как им пользоваться), вот мы им и поможем, заранее для них отключим.
1. Я где-то написал про HTTP сессии? В этом контексте это TCP сессии. Если приложение убит ООМ что с ними случится? И какие такие «общие хранилища» для TCP сессий вы предлагаете?
2. Как подрядчик будет «продолжать получать деньги за предоставление некачественной услуги» если подрядчик проект сделал и испарился. Работаем мы с клиентом, подрядчика этого мы в глаза не видели.
3. JFYI: Я вроде нигде и не писал про «мучиться с разметкой диска». В том конкретном случае мы просто
# dd if=/dev/null of=/swapfile bs=1M count=$(1024*20). Быстро и просто.И как systemd restart=always или supervisord тут поможет? Те сессии, которые были открыты когда OOM случился отвалятся с ошибкой. Правильный подход будет — убрать ноду из LB, дождаться когда на ноде 0 сессий, прибить приложение и перезапустить. Своп помог оттянуть время ООМ чтобы все это можно было провернуть. Да — не оптимально и вручную, но это именно то что нужно клиенту и дало нам достаточно времени чтобы найти постоянное решение (тот самый unicorn-worker-killer).
Мой пример:
Так что медленный своп это в некоторых ситуациях скорее достоинство чем недостаток.