> Я даже не знаю, кому повезло больше Админам

@etw Ле.

@etw а что там насчет облаков? С одной стороны, забот меньше, с другой стороны, за всем надо следить, иначе будет как на хабре. Ну и облака тоже кто-то должен обслуживать //роботы

@ckorzhik > а что там насчет облаков? Админам облаков больше всех и повезло. > С одной стороны, забот меньше Не надо с железками ебаться ток, разве что, а так та же хуйня. > за всем надо следит Палю: за всем в любом случае надо следить. > иначе будет как на хабре. как?

@etw разве у админов облаков норм зарплата? так http://geektimes.ru/post/247794

@etw Нет. Админам ещё держать эту хуйню, которую напишут вебомакаки.

@manul Засунуть в контейнер и пусть крутится, лишь бы не на ноде было написано.

@etw контейнеры это хорошо, но не всегда подходит. Сторадж в контейнере ты не сделаешь. Ну, то есть, сделаешь, но это глупо.

@etw А контейнер кто админить будет?

@ckorzhik Ссылка к зарплате админов в отрасли отношение имеет слабое.

@manul Если у тебя сторадж не на ноде или php, то проблем не вижу.

@etw Родная, ты когда-нибудь пробовала админить ту хуйню, которую веб-макаки пишут? Для них админов повышенной усвояемости говна выпустили — девопсы называются.

@etw > сторадж на ноде или на пхп > сторадж > ноде Значение знаешь?

@l29ah Как будто накладные расходы на администрирование приложения в виде контейнера такие же, как на администрирование приложения в виде набора пакетов.

@etw Содержимое контейнера блять. Или так и будешь с хартблидом носиться?

@manul Окай, я перефразирую: если у тебя софт управления хранилищем написан не на node.js или php, то проблем не вижу. Алсо, почему сторадж в контейнере - это глупо?

@l29ah Не поняла, в чем проблема? Дергаешь CI, собирается новый контейнер, ты его выкатываешь. Ну будет у тебя на неделе не три деплоя, а четыре.

@etw То есть, те люди, которые собирают прыщедистр, уже называются "разработчиками"? Удобно.

@komar Сарказм же.

@l29ah Т.е. CI, которая собирает контейнер, уже называется человеком? Удобно.

@etw А, я неправильно тебя понял. Тогда ТЕСТИРОВЩИКА не хватает.

@etw софт управления хранилищем написан блядь на C и называется ext4. метабаза написана на С++ и называется (допустим) mnogodb. Любой говнософт, независимо от того, на чем он написан - это жопная боль для админов. сторадж в контейнере это глупо, потому что ты не можешь виртуализировать физические носители. и не нужно пробрасывать в виртуалку или хипстерский докер хардварные устройства через node number, за такое убивают нахуй. А ещё нет смысла использовать виртуализацию на машинах, к которой, допустим, подключен DAS.

@manul > потому что ты не можешь виртуализировать физические носители Ответь на вопрос: что виртуализируется в контейнерах? Палю: ничего (лан, опционально сетевые девайсы). > и не нужно пробрасывать в виртуалку или хипстерский докер хардварные устройства через node number А ты не пробрасывай, запускай в privileged mode. На хосте все равно кроме тебя никого, а ценность докеров не в их дырявой ололоизоляции, а в том, что не надо в dependency hell пердолиться и при деплое ты оперируешь одним артефактом. >виртуализацию >контейенеры у кого-то каша в голове

@l29ah Если тебя беспокоит, что кто-то должен нажимать кнопку "перебосрать это говно", то палю: можно автоматически собирать контейнер по появлению новых версий библиотек в репе.

@etw я и так оперирую одной сущностью - наливочным образом для машины, в котором уже все есть. актуальные изменения конфигов можно привезти с помощью saltstack + gitfs. Это заебись. почему каша? чем контейнер отличается от той же kvm-виртуалки? ваш любимый докер суть lxc + куча говноскриптов и костылей.

@etw но нахуя собирать новый контейнер и деплоить каждый раз всю машину, когда можно выкатить пакет и порестартить сервис?

@manul Потому что в дебиане депенденси хелл такой что проще с нуля его переставить, и для этого уже написаны скриптокостыли, грят же.

@manul > я и так оперирую одной сущностью - наливочным образом для машины, в котором уже все есть. При необходимости обновить софт переустанавливаешь шиндошс^W люнекс? > чем контейнер отличается от той же kvm-виртуалки всем. > ваш любимый докер суть lxc сорта говна, обе эти хуйни - контейнеризация.

@manul У тебя никогда не было такого, что при деплое библиотеки не те встали и демон, например, падал из-за этого в сегфолт при взлете, или что еще хуже, в произвольный момент времени?

@etw define "обновить софт". апгрейд дистрибутива с одного релиза на другой? да, я делаю новый образ, допустим с red hat 7, в котором есть ssh-ключи, базовые пакеты, salt, мониторинг, вся хуйня. и переустанавливаю люнекс на машине, благо pxe и kickstart позволяют мне не ебаться с переустановкой. дальше salt-call state.highstate. если же обновить серверный софт - я обновляю его пакетом и делаю /etc/init.d/имя restart.

@etw было. для этого есть тестинг и престейбл. я приходил к программистам, давал им пиздюлей и через 5 минут у меня ехал хотфикс.

@manul притом коркалось не из-за зависимостей, а из-за багов самих либ.

@manul > если же обновить серверный софт - я обновляю его пакетом и делаю /etc/init.d/имя restart. ент. тольк не пакетом, а ПАКЕТАМИ, ибо зависимости. суть докера в том, что у тебя теперь не набор артевактов, который компонуется во время деплоя с потенциально разным результатом в зависимости от условий, а один артефакт, насчет одинаковости которого в любом из окружений ты уверен.

@manul > было. для этого есть тестинг и престейбл. В тестинге у тебя приехали одни версии библиотек, в престейбле другие, а в продакшене вообще третьи. Потому что конфигурация у тебя компонуется во время деплоя и нет гарантий, что то, что протестировано в тестинге, окажется в продакшене. > я приходил к программистам, давал им пиздюлей и через 5 минут у меня ехал хотфикс. Молодец, конечно, но пиздюлей ты им давал после того, как уже обосрался. А нормальный подход - перестать обсираться.

@etw заебало в два бранча писать. /R98 зависимости берутся не с потолка, а прописываются специально, как раз для того, чтобы не поставилась либа, которая, к примеру, ложит демона в кору. на моём кластере нет даже потенциально разных условий - мониторинг проверяет одинаковость окружений. во время деплоя не компонуется ничего, все ставится одновременно. /FD0 каких _именно_ библиотек? системных? нет. у меня и в тестинге, и в престейбле, и в продакшне одинаковые версии системных библиотек и одинаковые наливочные образы. служебные серверные библиотеки в окружениях действительно отличаются и каждый релиз едет сначала в тестинг. затем в престейбл, затем в продакшн. и никак иначе. перед тем, как пачка новых пакетов едет в тестинг, она проходит кучу автотестов и если хоть что-то блеванулось - сборка пакетов фейлится. потом она едет в тестинг. если что-то разъеблось - тестинг на то и тестинг, чтобы там все отловить. после того, как версия оттестирована в тестовом кластере- она едет в престейбл с такими же, СУКА, системными библиотеками, как и в тестинге. А отработав там, уже едет в прод. гарантия есть. то, что протестировано в тестинге и престейбле, окажется в продакшне и не разъебёт ничего.

@manul Ну молодцы, че. Вы пошли по пути контроля версий пакетов, наколбасили велосипедов и вам хорошо. Докер предлагает другой путь, сводя количество артефактов деплоя к одному, исключая необходимость трекать зависимости, что я и пыталась тебе объяснить, потому что не у всех нужные велосипеды уже написаны и не все их хотят писать.

@etw ссылка к вопросу "как?"

@etw Ты говоришь про трекинг зависимостей, я говорю, что в правильно построенной системе деплоя служебных пакетов отсутствует необходимость трекинга зависимостей на уровне отдельного destination сервера. Идём дальше. Ты все равно должна определять зависимости и ставить новые пакеты согласно им при создании отдельного контейнера, ведь правда? Иначе контейнер (а точнее, пакетный менеджер) сам тебе скажет при создании "хозяин, ты ебанулся, не буду я эту ссань ставить". Необходимость трекинга все равно нужна, иначе контейнер просто не соберется. В обоих случаях ответственность за правильность выставления зависимостей лежит на разработчике. дальше контейнер деплоится. согласись, что размер контейнера много больше размера отдельной группы служебных пакетов. деплоить такое хотя бы на 1000 машин - это ебаный пиздец. займёт кучу времени и уложит сеть.

@ckorzhik Сорь

@manul > Ты говоришь про трекинг зависимостей, я говорю, что в правильно построенной системе деплоя служебных пакетов отсутствует необходимость трекинга зависимостей на уровне отдельного destination сервера. "Трекинг зависимостей" в смысле "трекинг пакетов, которые являются зависимостями". > Ты все равно должна определять зависимости и ставить новые пакеты согласно им при создании отдельного контейнера, ведь правда? Нет, неправда. Можно нихуя не трекать и собирать "лишь бы работало" каждый релиз, а потом просто оперировать уже единожды собранными артефактами, свойство постоянности которих имманентно. Релиз-инжиниринг это, конечно, усложнит, но на деплой никак не повлияет. > В обоих случаях ответственность за правильность выставления зависимостей лежит на разработчике. Разработчик может недостаточно строго указать зависимости в пакете, не версионировать символы библиотек, или, например, банально не знать, что минорные версии одной и тоже библиотеки плохо совместимы, в итоге, у тебя софт будет тестироваться с libfoo 2.6.17, а в продакшен поедет с libfoo 2.6.16, с которым не работает. В общем, слишком много человеческого фактора, а контейнер всегда будет гарантировано работать в одном и том же окружении, потому что он сам себе окружение. > дальше контейнер деплоится. согласись, что размер контейнера много больше размера отдельной группы служебных пакетов. деплоить такое хотя бы на 1000 машин - это ебаный пиздец. займёт кучу времени и уложит сеть. Для этого в докере есть слои. Деплой новой версии контейнера при условии общих базовых слоев выльется только в скачивание отличающихся.

@etw бля сорь

блядь, @etw, создавай свои треды и там пизди, хули для тебя комар придумывает

@komar А нахуя тебе треды, в которых никто не будет пиздеть?

@etw 1. да 2. и ты разъебешь базовый образ, поздравляю. потом к тебе из-за горящих мониторингов придут админы и настучат. 3. нет, не поедет он в продакшн с 2.6.16, ибо тикет на выкатку из тестинга копируется ПОЛНОСТЬЮ, где точно указана 2.6.17. как раз для исключения этой ситуации. 4. про это не знал, спасибо. у меня докер только на ноуте, в нем вибер для рабочих чатов стоит, не хочу шкварить им свою няшную гентушку.

@manul > да Что "да"? У меня был не вопрос, а утверждение про то, что "трекинг пакетов" в смысле не трекинг зависимостей, а трекинг зависимых пакетов как обычных пакетов. > и ты разъебешь базовый образ см. про слои. алсо, админам будет, вообще, похуй как он там собирался, они говорят docker pull ...; docker run ... и их не ебет что внутри, лишь бы работало. > нет, не поедет он в продакшн с 2.6.16, ибо тикет на выкатку из тестинга копируется ПОЛНОСТЬЮ, где точно указана 2.6.17. как раз для исключения этой ситуации. А за тем, что в тикетах на выкатку перечислено, кто следит? И не случится ли обосрамс, если он какой-то пакет указать забудет? > про это не знал, спасибо. ^_^

@etw 1. не, ты немного не догоняешь. это не слака. деплой просто пофейлится в доебане, если указаны кривые зависимости. админ, который катит пакеты, увидит, что системой не накатилось ничего и пойдет засовывать бутылку разработчику в анус или если девопс, сам выставит нужную зависимость и продеплоит автоматом. 2. докер - отдельный инстанс. и его желательно мониторить. при разъебанном образе разъебутся мониторинги. 3. разработчик пакетов и ответственный админ сервиса. Если обосрамс случится по причине кривого софта - докер не спасет и придется образ переделывать с пофикшенными версиями. не отличается от выкатки пакетами ничем. установка кривой зависимости не получится, ибо системные библиотеки везде одинаковые. 4. Ня ^_^

@etw Чем тебе нода не нравится?

@manul > не, ты немного не догоняешь. это не слака. деплой просто пофейлится в доебане, если указаны кривые зависимости Ты понимаешь, что можно прописать такие кривые зависимости, что пакетный менеджер не обосрется поставить, но с которыми софт обосрется нормально работать? Например, тупо не указав версии этих зависимостей в debian/control, или, например, указав не все необходимые зависимости, а при этом на серверах уже будут стоять нужные либы, но неправильных версий. > докер - отдельный инстанс. и его желательно мониторить. при разъебанном образе разъебутся мониторинги. Еще раз перечитай про слои. В докере нет базовых образов, которые можно разъебать, есть только базовые слои, которые иммутабельны. Сборка контейнера - это взять некоторый набор базовых слоев и наслоить по указанным в скрипте шагам еще несколько сверху. Например, у тебя в первом слое находится базовая убунта, во втором какие-нибудь специфичные для твоего отдела/конторы приколюхи, а в третьем - собственно, приложуха со всеми нужными ей либами, и при сборке образа конкретной приложухи будет перегенерироваться только последний третий слой. > разработчик пакетов и ответственный админ сервиса. и где гарантии, что разработчик или админ не забудут ни про одну библиотеку? У софта обычно в зависимостях их с десяток, если что. что в твоем случае защищает от ситуации, когда в тикете не будут указаны нужные для работы зависимости, но в тестинге нужные библиотеки нужных окажутся поставленными руками, а в продакшене версии будут другими? Ты же только что рассказывал, как у тебя левые версии библиотек прилетели из-за ошибки разработчика, и теперь мне затираешь, что объебаться невозможно. > докер не спасет и придется образ переделывать с пофикшенными версиями. Спасет, потому что обосрамс времени компоновки пакетов в докере случится еще на этапе сборки и будет обнаружен в еще в dev-окружении и сразу же будет исправлен, а без докера обосрамс времени компоновки пакетов происходит при деплое и может случиться в продакшене. >не отличается от выкатки пакетами ничем. установка кривой зависимости не получится, ибо системные библиотеки везде одинаковые. Просто скажи мне, у тебя сейчас libc6 на всех серверах одинаковой версии?

@krkm Программистами^W Разработчиками // Ничего личного, просто много среди них откровенных макак.

@etw А, лан. Я уж было думал, что очередной фрактал отсоса.

@krkm лишь бы не как у антона

@etw А еще мне javascript не нравится.

@mugiseyebrows Лишь бы не как у ларри :coolface:

@etw это уже тупо похуй чо тебе там нравится (ты не клиент), я просто испугался, что там есть какой-то невиданный для меня отсос

@krkm районы, фракталы, большие массивы, я приведу к инту насильно

@mugiseyebrows :-*

@krkm > Чем тебе нода не нравится? > похуй чо тебе там нравится Зачем тогда спрашивал? > я просто испугался, что там есть какой-то невиданный для меня отсос Не читает gai.conf, а всегда пробует ipv4-адрес перед ipv6, например.

@etw 1. неправильных версий быть не может, ещё раз говорю. если не указать версии зависимостей - то разъебется на дев-машине разработчика. 2. а это забавно, надо будет посмотреть. 3. то же самое и при сборке пакета в дев-окружении, пакет не пройдет автотест и ёбнется. в тестинг поедет правильно слинкованная версия. а в продакшне такого не случится 146%, так как иначе версия даже из дева не выедет. 4. да, 2.13-38+deb7u8

@l29ah Лавашик, не мешай господам разговаривать, съеби на свою парашу.

@etw this

@krkm ♥

@etw перл же заебись :3

@etw >Не читает gai.conf tfw не лгбт-френдли

@etw Тебе не похуй на меня? Приходи потрахаться тогда, а то не с кем.

> неправильных версий быть не может, ещё раз говорю. если не указать версии зависимостей - то разъебется на дев-машине разработчика. Почему раъебется? У разработчика на дев-машине все нужные библиотеки уже стоят, как раз там обосраться с указанием зависимостей - раз плюнуть. Написал libfoo (>= 1.6.0) вместо libfoo (= 1.6.27) и пиздец. > то же самое и при сборке пакета в дев-окружении, пакет не пройдет автотест и ёбнется. в тестинг поедет правильно слинкованная версия. а в продакшне такого не случится 146%, так как иначе версия даже из дева не выедет. Смотри, у разработчика есть дев-машина, он туда ставит нужные библиотеки нужных версий и среди них libfoo-1.6.27, далее разработчик пишет код и потом прописывает в debian/control зависимость libfoo (>= 1.6.0) (а хуле, минорная версия же совпадает, должно по идее работать). Потом он собирает пакет, прогоняет автотесты, у него стоят нужная версия библиотеки, потому все норм. В CI все тоже отлично, потому что сборочное окружение - одноразовая виртуалка и пакеты там всегда ставятся по зависимостям самые свежие из репозитория. Потом вы решаете выкатить софт в тестинг для начала руками, чтобы, например, посмотреть, исправлен ли определенный баг, проявляющийся в конкретных условиях. Выкатили, поставили руками все нужные новые версии библиотек, включая libfoo, погоняли пару дней софт под нагрузкой, посмотрели и решили деплоить в престейбл, сочинили тикет, повспоминали нужные пакеты, но про libfoo забыли. Поскольку в престейбле (и продакшене) стоит libfoo-1.6.26, то пакет поставился нормально и демон даже запустился. Через час решили катить в остальной продакшен, что и сделали, а еще через 2 часа выяснились, что из-за несовместимости софта с libfoo-1.6.26 он падает через 3 часа после работы под реальной нагрузкой. ... Профит! Еще можно было бы пофантазировать о том, что, как обычно, инцидент являлся бы последствием наложения сразу нескольких проблем и второй такой проблемой было бы несрабатывание мониторинга на отказ престейбла, из-за чего вы не успели обновить libfoo в продакшене и он весь сложился через 3 часа. В случае использования докера проеб с libfoo-1.6.26 был бы заметен еще в тестинге, или даже на dev-машине.

@komar Сорь, похуй. Непонятно прост, нахуя тебе посты без камментов? [Процветание](/p/5IL3S9) лучше, чем [деградация](/p/F5QCQE) же.

@etw машину разработчика админю я, и без моего ведома там не появится версия libfoo, отличная от версии в продакшне. (МАААНИИИИТОООРИНГ), рута у него нет, sudo на apt нет. сборочное окружение - не одноразовая виртуалка, а многоразовая :) у которой опять-таки те же версии системных либ, что и в продакшне, ибо МАААНИИИИТОООРИНГ не может быть такого, что в деве и тестинге будет libfoo-1.6.27, а в престейбле libfoo-1.6.26. если это системная библиотека, она докатится мониторингом на 1.6.27, а тикеты в престейбл не едут без тестинга. а если это библиотека внутренняя и ее пишет тот же разработчик, он 100% выкатит её, потому что только что написал, через своюdev-машину - testing - prestable - production. не создал тикет на 1.6.27 == не включил 1.6.27 в докерный образ - ССЗБ. между выкаткой из престейбла в прод проходит минимум день, максимум неделя. // :3 ня, с тобой приятно общаться.

@manul Ебать вы фашисты. Впрочем, дело ваше, однако, с докером все эти изъебы с мониторингом версий пакетов бы не понадобились, зато понадобились бы другие^W^W^W^W

@etw когда мы начинали работать и запускали первые большие сервисы - таких штук как lxc и докер не было вообще, так что мониторинг версий это аццки древний, но охуенно отлаженный и работающий велосипед. Хотя свою монгу я на lxc держу, да, поверх 4x2xRAID0 SSD - 4 контейнера на машине, каждый ходит в свой рейд без ебли с портами, 4 data carrying реплики разных шардов в итоге. Вот тут контейнеры охуенно спасают. Докер трогать не хочу, что-то меня блеватушки от него тянет.

@manul s/мы/контора/ , сорь

@etw Ура, я дедфуд.

@manul >на моём кластере нет даже потенциально разных условий - мониторинг проверяет одинаковость окружений А как вы проверяете одинаковость мониторингом? Берёте и раз в N минут проверяете все пакеты и сравниваете с каким-то эталонным списком на сервере, который мониторит? >во время деплоя не компонуется ничего, все ставится одновременно. Поясни, пожалуйста, что это значит. Есть приложение и либы/файлы, от которого оно зависит. Либы обновляются до нужных версий, файлы копируются, что может компоноваться?

@etw Давно хотел спросить: как мониторить приложения в докере? Допустим, у меня заббикс. //только не бейте Мне надо в образ ставить агент, открывать порт для агента внутри образа (или там всё открыто по дефолту?), при этом порты разных контейнеров мапятся в разные порты хоста и надо это учитывать в конфигах, чтобы сервер заббикса стучал в нужные порты, правильно понимаю?