Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 47
«Спасибо» не нажимается ;)
Всегда интересно прочитать про внутреннюю инфраструктуру работающих приложений\сервисов\компаний, особенно без больших бюджетов и с описанием, почему именно так(на какие грабли наступали). Надуюсь на цикл статей.
Однозначно полезная публикация. Очень хочется подробностей про развертывание (pm2, bamboo и т.д.). Заранее благодарю.
Сама по себе развёртка приложений не представляет сложности — манулы достаточно подробны.
А вот дальнейшая настройка сложна. Если по этим моментам будут статьи, то уже больше по использованию.
Там есть специфика при развертывании на крупные компании, когда тысячи сотрудников. Вот в таком случае там это не так тривиально. Но подобного опыта у меня нет.
А вот дальнейшая настройка сложна. Если по этим моментам будут статьи, то уже больше по использованию.
Там есть специфика при развертывании на крупные компании, когда тысячи сотрудников. Вот в таком случае там это не так тривиально. Но подобного опыта у меня нет.
Очень интересная статья, спасибо!
Не совсем понял, про Mongo. Вы используете Sharding или просто репликацию или sharding с репликацией?
Не совсем понял, про Mongo. Вы используете Sharding или просто репликацию или sharding с репликацией?
Большой труд по разработке игры ( в смысле статья тоже).
Роутер надо было брать 3011, он на 20$ дороже, но в несколько раз производительнее.
Производительности данного роутера достаточно что бы решить поставленные задачи и иметь ещё пласт мощности сверху. При куче правил, условий и прочего нагрузка на роутер не увеличивается более чем на 10%. Т.е. у меня ещё 90% неиспользуемой мощности :-)
Хм, у меня одна только раздача торрентов мегабит на 200-300 прогружает роутер на ~20% плюс всякие ipsec к виртуалкам, впн для доступа в домашнюю сетку и тд. Запас производительности еще большой, но предыдущей платформы на 2011, которая даже чуть-чуть быстрее Вашей, мне уже не хватало, 600 мбит для нее потолок при 30-40 правилах. Хотя об объема трафика и количества конектов конечно зависит)
Предполагаю что у вас всё организовано через bridge, а не через мастер-порт.
По сути ощутимые затраты идут только на установление соединения, а сами данные очень быстро бегают и правила не проверяются каждый пакет.
По сути ощутимые затраты идут только на установление соединения, а сами данные очень быстро бегают и правила не проверяются каждый пакет.
Конечно через мастер порт, все соединения с не-туннельными шлюзами через fast track. Я внимательно читаю документацию и по роду занятий хорошо понимаю, как оно устроено внутри :) Проблема в том, что даже с фасттрэком ~700МГц мипс не может переваривать больше 600 мбит трафика с натом.
Именно по этому у микротика все не сохо модельки масштабируются с помощью увеличения количества ядер и частот.
Именно по этому у микротика все не сохо модельки масштабируются с помощью увеличения количества ядер и частот.
Slack.
Стучится в личку или в свой канал пишет?
У нас тоже слэк, но так и не получилось найти бота, который бы писал в личку что «вот эта задача назначена на тебя». Остановились на том что весь поток событий льётся в канал, который никто не читает, т.к. нет персонификации.
Если эту проблему решили, то прошу рассказать детали.
Откомментили твою задачу? Слакбот уже стучится к тебе.
Стучится в личку или в свой канал пишет?
У нас тоже слэк, но так и не получилось найти бота, который бы писал в личку что «вот эта задача назначена на тебя». Остановились на том что весь поток событий льётся в канал, который никто не читает, т.к. нет персонификации.
Если эту проблему решили, то прошу рассказать детали.
У меня несколько проще задача, т.к. он пишет в личку только мне :-)
С ходу нашел несколько вариантов решения. Вот один, в лоб:
на каждого пользователя создается дополнительная slack конфигурация, которая шлёт то что надо, и указывается конкретный пользователь. По сути эту операцию можно делать при найме сотрудника и она совсем не трудоёмка, особенно если как-то автоматизировать.
Возможно, есть решения лучше :-)
С ходу нашел несколько вариантов решения. Вот один, в лоб:
на каждого пользователя создается дополнительная slack конфигурация, которая шлёт то что надо, и указывается конкретный пользователь. По сути эту операцию можно делать при найме сотрудника и она совсем не трудоёмка, особенно если как-то автоматизировать.
Возможно, есть решения лучше :-)
У слака хороший апи, бот на питоне пишется легко и быстро даже без опыта написания ботов, с необходимой логикой :)
Может я чего не понимаю, но для того, чтобы в канал написал используется #channelname, для лички someusername?
Также можно в сообщении упомянуть ользователя, тогда ему подругому нотификация в трее придет.
зыж ботами не пользовался, через curl все работает как часы.
Также можно в сообщении упомянуть ользователя, тогда ему подругому нотификация в трее придет.
зыж ботами не пользовался, через curl все работает как часы.
Если мне не изменяет память, не все так просто. Сначала надо зайти на общий канал, получить список всех пользователей, а потом уже из списка получить id нужного пользователя, и ему писать сообщение.
ну естественно, что нужно знать имя пользователя. тут уж зависит от реализации… самое простое заводить в слаке пользователя с таким же логином, что в <вашсписокпользователей>ю Сложнее и, видимо, дороже — сделать авторизацию в слаке через вашу систему.
Я про то, что обратиться напрямую по имени/логину/емейлу — нельзя (хотя могу и ошибаться, точно не помню). А только из общего списка по емейлу (допустим) получить id и уже через него писать личное сообщение.
Смутился, только что проверил — все работает
curl -X POST --data-urlencode 'payload={"channel": "@myusername", "username": "HostWatcher", "text": "This is posted to DM and comes from a bot named HostWatcher.", "icon_emoji": ":ghost:"}' https://hooks.slack.com/services/YOURTOKENПравда пришло в канал slackbot'a, но сдается мне, что это фича :)
Да тут много тем же.
Банально надо что бы какой-то механизм соотнёс имя в слаке с тем что в жире.
Можно делать как выше написал или бота своего писать или ещё что-то. Но из коробки реально универсального решения не нашел с ходу.
Банально надо что бы какой-то механизм соотнёс имя в слаке с тем что в жире.
Можно делать как выше написал или бота своего писать или ещё что-то. Но из коробки реально универсального решения не нашел с ходу.
Интересно, спасибо. Надо будет почитать внимательно (а не после рабочего дня), но в любом случае — пишите ещё!
P.S.: С докером может быть помочь чем? Пользуюсь год, разворачиваю на kubernetes на локалке (для разработки) и в GCE. Всего полтора велосипеда написал под это дело…
P.S.: С докером может быть помочь чем? Пользуюсь год, разворачиваю на kubernetes на локалке (для разработки) и в GCE. Всего полтора велосипеда написал под это дело…
Вот это, кстати, небольшой парадокс — индивидуально с докером проблем нет почти ни у кого.
Я даже одно время приложение разворачивал как докер (но была просадка около 10% из-за некоторых особенностей).
Но вот когда дело доходит до корпоративных решений — когда подготавливается образ и все настройки не индивидуально, а, хотя бы для полста человек — почему то волшебным образом начинаются проблемы.
Я даже одно время приложение разворачивал как докер (но была просадка около 10% из-за некоторых особенностей).
Но вот когда дело доходит до корпоративных решений — когда подготавливается образ и все настройки не индивидуально, а, хотя бы для полста человек — почему то волшебным образом начинаются проблемы.
Ну на самом деле всё объясняется просто. Дла того чтоб разобраться с какой-то технологией — надо посидеть, подумать, почитать документацию, поэксперементировать… При условии того что мы знаем как в наших компаниях происходит работа (давай, быстрей, нужен релиз, сейчас!!!11) — ничего удивительного что не получается внедрить толком что-то новое. Я этим всем спокойно занимался в перерывах между работами в компаниях, изучил, попробовал, применил на своих проектах, набил шишек и написал пару скриптов. Так же стоит отметить проблему с документацией что у докера что у кубурнетес, нужно реально захотеть в этом разобраться чтоб чего-то добиться, ну и навык гугления должен быть минимум 4 уровня :). Вспомнить хотя бы этот новомодный миникуб, которым заменили кубернетес разворачиваемый в докере, который разворачивает кубернетес в виртуалке и куда не подключить hostPath без танцев с бубном, но в документации уже всё выпилили.
Сейчас пришёл в новую компанию, увидел что они всё ещё деплоят прям на железо (причём у разработчика стоял nginx, а на проде apache) и ужаснулся. Достал свои скрипты, допилил под нужды командной разработки и обучил разработчиков. У меня конечно не «полста человек», а всего лишь 4 разработчика, но судя по тому с какой лёгкостью мы подключаем новых людей — не должно быть проблем с расширением, просто будем постепенно допиливать решение (скрипты).
Минусы и неудобство перекрываютс плюсами с головой, по крайней мере с точки зрения людей которые работают с конечным сетапом. Разработка вернулась на локальный комп и при этом — окружение идентичное тесту/проду, этож просто чудо какое-то…
Сейчас пришёл в новую компанию, увидел что они всё ещё деплоят прям на железо (причём у разработчика стоял nginx, а на проде apache) и ужаснулся. Достал свои скрипты, допилил под нужды командной разработки и обучил разработчиков. У меня конечно не «полста человек», а всего лишь 4 разработчика, но судя по тому с какой лёгкостью мы подключаем новых людей — не должно быть проблем с расширением, просто будем постепенно допиливать решение (скрипты).
Минусы и неудобство перекрываютс плюсами с головой, по крайней мере с точки зрения людей которые работают с конечным сетапом. Разработка вернулась на локальный комп и при этом — окружение идентичное тесту/проду, этож просто чудо какое-то…
При условии того что мы знаем как в наших компаниях происходит работа (давай, быстрей, нужен релиз, сейчас!!!11)
К сожалению, моя речь касалась совершенно не наших компаний :-)
всё ещё деплоят прям на железо
Ну это тоже из крайности в крайность. Я предпочитаю использовать виртуальные машины хоть в каких то проявлениях. Но даже это не всегда спасает.
Например, jail, это те же самые контейнера, на самом деле. У меня в jail стоит virtualbox. Даже при такой, казалось бы, изоляции, у меня несколько раз мастер-машина падала из за проблем на одной из виртуальных в virtualbox. Там очень специфичные ошибки были, но факт был что они сначала вырывались и из virtualbox, а потом и из jail, уводя машину в кернел паник.
всего лишь 4 разработчика, но судя по тому с какой лёгкостью мы подключаем новых людей
Вот в этом и есть разница. Мало сделать решение — его надо ещё поддерживать. Своевременно обновлять и так далее. Зачастую изначальные контейнера готовятся вот такой командой, а когда она расширяется, и когда кодовая база сильно больше, и требований в целом больше — забывают актуализировать и искренне считают что это ты тут дурак, не смог разобраться как их уюненький докер поставить в 1 команду :-)
Окей, мы можем проблему вынести в другую плоскость — «любое решение требует поддержки» — но это вопрос для отдельной статьи :-) Я думаю так или иначе мы поняли позиции друг друга.
К сожалению, моя речь касалась совершенно не наших компаний :-)
Тогда почему «К сожалению»? :) На самом деле под «нашими» я подразумевал «компании в которых мы работаем». Я работал много где (и много кем) но «война… война никогда не меняется». Везде есть «эффективные менеджеры», которыми самими надо управлять для достижения результатов…
Я предпочитаю использовать виртуальные машины хоть в каких то проявлениях. Но даже это не всегда спасает.
Например, jail, это те же самые контейнера, на самом деле. У меня в jail стоит virtualbox.
Я подумал что у меня подводит память (jail и freebsd в частности пользовался последний раз лет 5 назад), но оказалось что нет:
В основу FreeBSD Jail вошёл системный вызов chroot(2), при котором для текущего процесса и всех его потомков, корневой каталог переносится в определённое место на файловой системе
К контейнеризации это относится слабо, вы просто говорите процессу что «вот эта папка — корень системы и выше ничего нет», то есть вы засунули виртуалку в папку и сказали ей «сиди тут». В контейнере же у вас полноценная ОСь, окукленная в оперативке, по сути. Если не накосячить с подключением чего-либо с хост-машины (например — монтирование папок в контейнер) то очень сложно вообще что-либо сломать. Но если прям происходит какая-то жесть — в дело вступает система оркестрации, например kubernetes, которая быстро, решительно объясняет контейнеру или даже целому поду что они не правы. Такой сетап используется гуглом уже лет 15, я думаю они могли бы в своё время просто заюзать jail и не париться, но похоже что это не одно и то же…
Мало сделать решение — его надо ещё поддерживать. Своевременно обновлять и так далее
Окей, мы можем проблему вынести в другую плоскость — «любое решение требует поддержки»
Если не поддерживать — совершенно всё равно какие технологии и в каком кол-ве применять. Рано или поздно всё нужно обновлять и переделывать.
А я бы кстати не против был бы что-то обсудить в этой плоскости, может быть — это не плохая тема для вашей следующей статьи? :) Буду ждать, удачи!
К контейнеризации это относится слабо
Да ладно, Jail вполне соотносится идеологически с контейнерами.
Более того можно собрать linux джейл, и проксировать linux-команды.
У них много общего, на самом деле.
Вот дальше:
Однако FreeBSD Jail также имеет поддержку на уровне ядра, что позволяет ограничивать доступ к сети, общей памяти, переменным ядра sysctl и ограничивать видимость процессов вне jail.
Процесс, заключённый в Jail, может иметь доступ только к определённым IP-адресам операционной системы и использовать определённый hostname. Такой процесс называется «изолированный процесс» или «Jailed-процесс».
Таким образом, создаётся безопасная «клетка», внутри которой можно исполнять даже потенциально опасное программное обеспечение, которое не сможет никак повредить основной системе или другим таким же «клеткам».
это не плохая тема для вашей следующей статьи
Точно не следующей — слишком мало у меня материала.
Например, вот эта статья была написана за один присест. Прям реально — сел и написал, отрывался только что бы чая ещё сдлать.
Но вот материал мариновался в голове полтора года :-)
Да ладно, Jail вполне соотносится идеологически с контейнерами.
Из цитаты:
позволяет ограничивать доступ к сети, общей памяти, переменным ядра sysctl и ограничивать видимость процессов вне jail.
И в этом (на мой взгляд) изначальное различие: в контейнерах по умолчанию «всё запрещено что не разрешено». Разрешили контейнеру доступ в сеть — есть сеть, нет — значит идёт лесом. Сложно (сложнее) сломать хост-систему если софт понятия не имеет что есть какая-то хост-система.
Точно не следующей — слишком мало у меня материала.
Как вы сами пишите — надо просто взять кусочки того что есть и не обрезать:
Практически каждый из пунктов имеет под собой довольно обширную историю (я намеренно сильно сокращал всё) и тянет на отдельную полноценную статью.
Тьфу, я думал вы хотите статью про докер :-)
Про виртуализацию в целом это можно, но, тем не менее, не следующей точно.
Не цепляйтесь к словам, пожалуйста. Это уже детали. Мы можем создавать Jail'ы с большим количеством ограничений сразу, что для большинства пользователей является достаточным.
Я это к тому что задачу они решают кране схожую — лёгкий слой изоляции с минимальными издержками. Я не говорю что это одно и тоже, но сравнивать вполне можно.
Несмотря на этот пост я не считаю себя крутым сетевиком или системным администратором, и не претендую на то, что данные решения самые лучшие и корректные из возможных — более того, вероятно, это совсем не так. Но они позволили решить поставленные задачи на должном уровне и гарантировать большое количество свобод.
Мне нравится правило 100 часов, и в ряде отдельно взятых навыков у меня именно схожий опыт. Ну может не 100, а скажем 200-500.
Про виртуализацию в целом это можно, но, тем не менее, не следующей точно.
Не цепляйтесь к словам, пожалуйста. Это уже детали. Мы можем создавать Jail'ы с большим количеством ограничений сразу, что для большинства пользователей является достаточным.
Я это к тому что задачу они решают кране схожую — лёгкий слой изоляции с минимальными издержками. Я не говорю что это одно и тоже, но сравнивать вполне можно.
Несмотря на этот пост я не считаю себя крутым сетевиком или системным администратором, и не претендую на то, что данные решения самые лучшие и корректные из возможных — более того, вероятно, это совсем не так. Но они позволили решить поставленные задачи на должном уровне и гарантировать большое количество свобод.
Мне нравится правило 100 часов, и в ряде отдельно взятых навыков у меня именно схожий опыт. Ну может не 100, а скажем 200-500.
Тьфу, я думал вы хотите статью про докер :-)
Про докер я тоже хочу! :)
Я это к тому что задачу они решают кране схожую — лёгкий слой изоляции с минимальными издержками.
Так я же и не против, просто предположил что некоторых проблем можно было бы избежать используя, например, докер.
Но они позволили решить поставленные задачи
И это — самое главное.
> В контейнере же у вас полноценная ОСь, окукленная в оперативке, по сути.
Это не так. Полноценная ось — только в виртуальной машине. Контейнер это лишь огораживание окружения средствами ядра, в линуксе это cgroups и namespaces, в бсд что-то аналогичное. Но и у гостевой и у хост ос общее ядро, адресное пространство, ресурсы и тд. Дело лишь в ограничении доступа к ресурсам для процессов, которые крутятся в контейнере.
Это не так. Полноценная ось — только в виртуальной машине. Контейнер это лишь огораживание окружения средствами ядра, в линуксе это cgroups и namespaces, в бсд что-то аналогичное. Но и у гостевой и у хост ос общее ядро, адресное пространство, ресурсы и тд. Дело лишь в ограничении доступа к ресурсам для процессов, которые крутятся в контейнере.
Ну как верно сказал автор — не цепляйтесь к словам, а то мы дойдём до того что «полноценная ось у нас только на железе», т.к. виртуалка это тоже только эмуляция :) Я же не про это писал.
Дело в том, что общее ядро накладывает определенные ограничения. Мало того, что нельзя запустить ос, отличную от хост ос, так еще и существует софт, требующий интеграции юзерспейса и кернелспейса. Самый простой пример (и актуальный на сегодняшний момент) — поднятие собственного openvpn сервера на удаленной площадке для обхода блокировок. Он тупо не заработает в контейнере, т.к. требует подгрузки модуля в ядро. Это же относится и к файловым системам, крутящимся в юзерспейсе и тд.
Спасибо за статью!
Если в общем: отличная экономия времени для тех, кто имеет проблемы, с которыми вы сталкивались или ищет похожие технические решения.
Если в общем: отличная экономия времени для тех, кто имеет проблемы, с которыми вы сталкивались или ищет похожие технические решения.
Можете в DTLN обратиться на тему теста S3 стораджа для хранения своих фотографий и замены owncloud
Между тем подъехала вакансия разработчика/тимлида: https://moikrug.ru/vacancies/1000027249
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Инфраструктура онлайн игры