Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, Vetal_ca, Вы писали:
V_>>В очень редких случаях, но оппоненты, ожидаемо, не знают. Иначе уже давно закидали бы
Ops>Так я же привел ссылку на баг, о котором и идет речь. Который висит именно годы. Который все это время активно обсуждают, и предлагают различные костыли для его обхода. И который разработчикам пофиг, они его только периодически закрывают, видимо, как не интересный.
Да, скорее всего, редкий случай. Врядли кто-то будет крутиь Postgress под Windows когда можно в Linux. Есть интересные баги или нерешенноси, которые реально хотелось бы решить
то, где ты не смог. Отсутствует важнейшее умение решение проблем и поиска информации.
T>вопрос в том, нужно ли разработчику становиться системным администратором: нужно ли ему уметь разбираться в том, почему то, что у него локально как-то работает, почему-то в production работает неудовлетворительно и куда ему бежать ?
T>есть, например, прекрасный пример с citrix: пока нагрузка небольшая, всё прекрасно работает, когда же происходит переход нагрузки за какой-то некому непонятный порог, то всё начинает виснуть, все недовольны, никто не знает, почему это так и т.д.
T>и есть какие-то шаманы, которые занимаются тем, что ездят по всему миру и занимаются только тем, что подкручивают какие-то некому неизвестные параметры citrix так, что вроде после их подкруток становится лучше, где тут разница с докером & co.?
T>ну, в принципе, докер попроще citrix, конечно, но ведь появление подобных описанным выше проблемам , в принципе, уже запрограммировано: T>эффективными контейнеры станут только тогда, когда весь стек будет правильно подогнан, а такой цели нет, цель индустрии — пересадить народ на то, за что надо регулярно платить и для индустрии желательно, чтобы платили за всё это больше, нежели за то, что было до этого
Не знаю про Cytrix, но контейнеры и есть mainstream.
И backend я разроботчиком я был, пока одни товарищи не стали слезно просить, чтобы я и DevOps часть сделал. Вот так и "втянуло".
У меня очень большой драйв, когда делаешь вещи очень нужные другим, это очень мотивирует
И точно так же отмотивировало из геймдева, когда EA делать 1000 и одна таблетка для игрунов-наркоманов, чисто чтобы все ниши рынка закрыть. Хотя, в целом, большинство игр это вредный мусор. Кроме нескольких затягивающих, все они убивают годы жизни.
Здравствуйте, Vetal_ca, Вы писали:
V_>Да, скорее всего, редкий случай. Врядли кто-то будет крутиь Postgress под Windows когда можно в Linux. Есть интересные баги или нерешенноси, которые реально хотелось бы решить
А там не надо крутить именно постгрю, там надо сделать возможность монтирования папки не только с владельцем рутом. Вообще, работа всего и вся от рута в докере — это довольно неприятный момент, который вот так вылезает, когда софт от рута не хочет работать.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, takTak, Вы писали:
T>вопрос в том, нужно ли разработчику становиться системным администратором: нужно ли ему уметь разбираться в том, почему то, что у него локально как-то работает, почему-то в production работает неудовлетворительно и куда ему бежать ?
Я недоволен не совсем этим. Мне ведь обещают магическим образом "стабильное окружение где угодно". Только на поверку магия не работает и вылезают частные случаи, которые надо обходить. А когда магию надо подпирать костылями, то какой смысл мне с ней возиться? Ведь настроить все без волшебного докера может быть даже проще, чем возиться с его особенностями.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Я недоволен не совсем этим. Мне ведь обещают магическим образом "стабильное окружение где угодно". Только на поверку магия не работает и вылезают частные случаи, которые надо обходить.
Так ведь работает, кроме Windows.
Ops>А когда магию надо подпирать костылями, то какой смысл мне с ней возиться? Ведь настроить все без волшебного докера может быть даже проще, чем возиться с его особенностями.
А кто сказал, что руками каждое Docker-приложение будет настраивать быстрее, чем один раз разобраться с настройкой Docker'а?
Здравствуйте, smeeld, Вы писали:
S>Пишутся скрипты для Continuos integration, собирающей свои пакеты для каждой версии каждой OS. На текущем проекте таким образом поддерживается: две centos/rhel, два debian, три ubuntu, две opensuse, два sles-а, два solaris. И это всё компилится с одного дерева исходников, с входами для CI в рутовом Jamroot. На выходе пакет, который админы ставят одной командой. Вот так делается в unix-like-ах.
и что мешает туда же прикрутить сборку докер образа?
Вообще, это все только звучит просто, мне приходится поддерживать множество дистров линукса, Debian(x2)/Ubuntu(x3)/Centos, под две архитектуры, arm64 и amd64. Это тот еще гемор. В Ubuntu 16.04 не доложили нужный буст, в Centos нужную версию gcc и билд горит огнем. В итоге ты разрабатываешь на том, что доступно во всех поддерживаемых дистрах, а это даже выяснить нельзя стандартным образом. Дистрибутивы живут в прошлом и мешают двигаться вперед. Мне было бы сильно проще выкинуть все это гавно и юзать только докер.
Здравствуйте, Ops, Вы писали:
Ops>А там не надо крутить именно постгрю, там надо сделать возможность монтирования папки не только с владельцем рутом. Вообще, работа всего и вся от рута в докере — это довольно неприятный момент, который вот так вылезает, когда софт от рута не хочет работать.
Просто не монтировать host folder и забыть об этой проблеме.
Что в докере что в host <-> VM, разделяемая общая папка это особый вопрос кросс-OS взаимодействия со своими особенностями.
Раз уже предлагается дополнительный уровень структуризации, нужно им пользоваться. Тем более, что структуризация очень хорошая вещь сама по себе, не зависимо от докера.
CK>Вообще, это все только звучит просто, мне приходится поддерживать множество дистров линукса, Debian(x2)/Ubuntu(x3)/Centos, под две архитектуры, arm64 и amd64. Это тот еще гемор. В Ubuntu 16.04 не доложили нужный буст, в Centos нужную версию gcc и билд горит огнем. В итоге ты разрабатываешь на том, что доступно во всех поддерживаемых дистрах, а это даже выяснить нельзя стандартным образом. Дистрибутивы живут в прошлом и мешают двигаться вперед. Мне было бы сильно проще выкинуть все это гавно и юзать только докер.
... вместо чтобы тратить усилия, сфокусировано, на именно то, что самое ценное от продукта: его функционал
Здравствуйте, Vetal_ca, Вы писали:
V_>Просто не монтировать host folder и забыть об этой проблеме.
Или не использовать докер, оно в результате проще оказалось, по крайней мере в моих задачах. Вот этот вот ректальный доступ к файлом в томе — это не удобство ни разу.
V_>Что в докере что в host <-> VM, разделяемая общая папка это особый вопрос кросс-OS взаимодействия со своими особенностями.
Да-да, это не баг, это фича.
V_>Раз уже предлагается дополнительный уровень структуризации, нужно им пользоваться. Тем более, что структуризация очень хорошая вещь сама по себе, не зависимо от докера.
Так и разные пользователи предлагаются, что ж ими докер не пользуется, а все из-под рута хреначит?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Vetal_ca, Вы писали:
CK>>...В итоге ты разрабатываешь на том, что доступно во всех поддерживаемых дистрах... V_>... вместо чтобы тратить усилия, сфокусировано, на именно то, что самое ценное от продукта: его функционал
Так фокусируйся. И следуй рекомендациям админа/девапса. И не по желанию левой пятки внешнюю либу добавляй в проект, а после обсуждения с этим самым админом/девапсом.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, Vetal_ca, Вы писали:
V_>>Просто не монтировать host folder и забыть об этой проблеме.
Ops>Или не использовать докер, оно в результате проще оказалось, по крайней мере в моих задачах. Вот этот вот ректальный доступ к файлом в томе — это не удобство ни разу.
Или использовать докер и не обращать внимание на тех кто не может. Крупные компании могут, маргиналы не могут. Что-то мне подсказывает, что маргиналы внизу.
Я использую Windows контейнеры уже давно. Сначала через docker-machine, потом через Kubernetes. Это работает у нас. Не обращать внимание на "Петрова, Иванова и Сидорова не получилось" меня еще в детстве приучили. Надо идти за теми кто может.
Ops>Да-да, это не баг, это фича.
Это оправдание для лузеров, наверное, не знаю. Я не вдавался, у меня не агентство по спасению тех кто не может.
Ну а к критиканам, чтобы лучше понимать, подход простой: "Чтобы избежать критики, ничего не делай, ничего не говори, будь никем."
Ops>Так и разные пользователи предлагаются, что ж ими докер не пользуется, а все из-под рута хреначит?
Не всегда, в рабочих контейнерах у меня не root. Тем не менее для persistent data все работает
Здравствуйте, Sheridan, Вы писали:
V_>>... вместо чтобы тратить усилия, сфокусировано, на именно то, что самое ценное от продукта: его функционал S>Так фокусируйся. И следуй рекомендациям админа/девапса. И не по желанию левой пятки внешнюю либу добавляй в проект, а после обсуждения с этим самым админом/девапсом.
Ты читать умеешь?
Или покомандовать хочется, помахать кулаком в объектив микроскопа?
Здравствуйте, Vetal_ca, Вы писали:
V_>Или использовать докер и не обращать внимание на тех кто не может. Крупные компании могут, маргиналы не могут. Что-то мне подсказывает, что маргиналы внизу.
Может и хочет — разные вещи. Если потренироваться, наверное, можно и на гвоздях спать. И кто-то даже на это согласится, когда крупная компания ему будет за это соответственно платить.
V_>Я использую Windows контейнеры уже давно. Сначала через docker-machine, потом через Kubernetes. Это работает у нас. Не обращать внимание на "Петрова, Иванова и Сидорова не получилось" меня еще в детстве приучили. Надо идти за теми кто может.
Зачем? У меня свои задачи, в которых можно обойтись без мазохизма, мне платят за результат, а не за докер. А докер, как выяснилось, на таких задачах больше тратит времени, чем экономит, благодаря багам и агрессивному коммунити с завышенным ЧСВ — скорее тебя обосрут, чем признают баг, не говоря уже про его исправление.
Ops>>Да-да, это не баг, это фича.
V_>Это оправдание для лузеров, наверное, не знаю. Я не вдавался, у меня не агентство по спасению тех кто не может.
Да конечно для лузеров. Не осилили нормальное монтирование — это еще ладно, но вот человека на защите этой "особенности" иначе не назовешь.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, Vetal_ca, Вы писали:
V_>>Или использовать докер и не обращать внимание на тех кто не может. Крупные компании могут, маргиналы не могут. Что-то мне подсказывает, что маргиналы внизу.
Ops>Может и хочет — разные вещи. Если потренироваться, наверное, можно и на гвоздях спать. И кто-то даже на это согласится, когда крупная компания ему будет за это соответственно платить.
(C) Некто Ops, у которого не получилось.
Ops>Зачем? У меня свои задачи, в которых можно обойтись без мазохизма, мне платят за результат, а не за докер.
Тебе платят за то, что ты можешь делать. Остальное это попытка прикрыть несостоятельность.
По факту, у нас расклад такой:
Старый проект, неконтейниризирован, куча Windows, IIS, и прочего.
5 DevOps делойят 8 часов. Плановое время — 1 час, 1 делает, 1 ассистирует. Плановое время практически никогда не было достигнуто.
против
Наш проект: пара минут (AppVeyor Artifacts -> Cloud), любой член команды.
И это я вижу повсеместно. Конечно, есть пара маргиналов где-то на rsdn, которые на словах еще эффективнее. Но мой опыт подсказывает, что это обычная песня "отставших от поезда". У нас такие же "гении" есть, рыночек ставит их на свое место. По крайней мере, так как я за зарплату они не торгуются.
Ops> А докер, как выяснилось, на таких задачах больше тратит времени, чем экономит, благодаря багам и агрессивному коммунити с завышенным ЧСВ — скорее тебя обосрут, чем признают баг, не говоря уже про его исправление.
У Ops не получается выйти на эффективное использование. Кто-то всю жизнь шины меняет, не в силах перейти на более сложные и оплачиваемые вещи. Это нормально, такова жизнь.
Естественно, толпа опытных инженеров не побежит переучиваться на шиномонтаж
Я не продвигаю докер контейнеры, я тот кто это эффективно использует.
Мне выгодно,
— чтобы те, у кого не получается сабмитили баги (хоть какой-то выхлоп)
— чтобы те, у кого получается, делились своими эффективными подходами.
Нравится или нет это какому-то XYZ — все равно.
Ops>Да конечно для лузеров. Не осилили нормальное монтирование — это еще ладно, но вот человека на защите этой "особенности" иначе не назовешь.
Я еще сервера не умею тряпочкой эффективно протирать, да. Это важно?
Здравствуйте, Vetal_ca, Вы писали:
V_>>>... вместо чтобы тратить усилия, сфокусировано, на именно то, что самое ценное от продукта: его функционал S>>Так фокусируйся. И следуй рекомендациям админа/девапса. И не по желанию левой пятки внешнюю либу добавляй в проект, а после обсуждения с этим самым админом/девапсом. V_>Ты читать умеешь?
А ты?
V_>Или покомандовать хочется, помахать кулаком в объектив микроскопа?
Почему тебя в первую очередь волнует "покомандовать хочется", а не продукт, который тебе девапс поможет сделать еще более качественным?
У тебя девапс жену увёл? Не дали руководящую должность? Что произошло? Я тебе уже в который раз говорю: надо работать в команде, а не "кто из нас главнее?". Как только про главность споры возникают — сразу всё валится к чертям собачьим. Можно разворачиваться и уходить.
Здравствуйте, Vetal_ca, Вы писали:
V_>Старый проект, неконтейниризирован, куча Windows, IIS, и прочего. V_>5 DevOps делойят 8 часов. Плановое время — 1 час, 1 делает, 1 ассистирует. Плановое время практически никогда не было достигнуто.
V_>против V_>Наш проект: пара минут (AppVeyor Artifacts -> Cloud), любой член команды.
Очень интересно почему ты сравниваешь время деплоя некоего старого проекта с каким-то новым. Причём не приводя ничего из того что надо сделать. Не, ну понятно в докере надо контейнеры скопировать и это самая долгая операция (что косвенно говорит о масштабах вашего проекта — "пара минут").
А что делалось в старом проекте? Я, например, участвовал в задачах задачи деплоя с нуля, начиная с подъёма гипервизора. То есть развернуть гипер, развернуть виртуалки в указанных количествах, развернуть сервисы внутри виртуалок. Это было достаточно долго, но не часы. Поэтому вывода два: либо надо было нанимать девапсов а не студентов, либо проект был настолько монстроидальным.
Ну или как вариант — вы требовали от девапсов магии — совместить в одной машине ваш код, требующий разных версий одних и тех-же библиотек и чтобы это не мешало прочим сервисам. Ну и опять же, 8 часов это оверкилл, никуда не годится. Может они там БД инициализировали кучей генерируемых налету данных?
Здравствуйте, Sheridan, Вы писали:
S>Так фокусируйся. И следуй рекомендациям админа/девапса. И не по желанию левой пятки внешнюю либу добавляй в проект, а после обсуждения с этим самым админом/девапсом.
какой еще админ, если софт хостит пользователь у себя сам и ему нужно просто дать что-то, чтобы он его установил? я понимаю что это немного не то, и мы тут больше про ситуации, когда у нас есть компания, в которой программисты и девопсы делают какой-то сервис, владеют инфраструктурой и тд
просто не надо говорить что путь делать все через пакеты и стандартные линуксовые репозитории, он такой простой, это мало того что нихера не просто, так еще и накладывает ограничения на разработку, потому что нужно постоянно иметь ввиду что ты можешь использовать только наименьший общий знаменатель того, что есть в поддерживаемых тобой дистрах
поэтому появился cloud native и многие облачные продукты деплоятся только докером, ты просто не сможешь поддерживать свой репозиторий со всеми зависимостями для кучи дистрибутивов, а когда ты полагаешься на то что есть в стандартных репозиториях, получается то что я описал выше, не все это могут поятнуть
Здравствуйте, chaotic-kotik, Вы писали:
CK>Здравствуйте, Sheridan, Вы писали:
S>>Так фокусируйся. И следуй рекомендациям админа/девапса. И не по желанию левой пятки внешнюю либу добавляй в проект, а после обсуждения с этим самым админом/девапсом.
CK>какой еще админ, если софт хостит пользователь у себя сам и ему нужно просто дать что-то, чтобы он его установил? я понимаю что это немного не то, и мы тут больше про ситуации, когда у нас есть компания, в которой программисты и девопсы делают какой-то сервис, владеют инфраструктурой и тд
Значит в вашей команде админ/девапс должен заниматься пакетированием, а не деплоем в хосты.
CK>просто не надо говорить что путь делать все через пакеты и стандартные линуксовые репозитории, он такой простой, это мало того что нихера не просто, так еще и накладывает ограничения на разработку, потому что нужно постоянно иметь ввиду что ты можешь использовать только наименьший общий знаменатель того, что есть в поддерживаемых тобой дистрах
Опакетить несложно. А накладывает оно ограничения на разработку до тех пор, пока вы не примете решение — вам важнее продавать софт, установка которого безболезнена для пользователя или вы пишете софт для того чтобы легче было писать софт.
CK>поэтому появился cloud native и многие облачные продукты деплоятся только докером, ты просто не сможешь поддерживать свой репозиторий со всеми зависимостями для кучи дистрибутивов, а когда ты полагаешься на то что есть в стандартных репозиториях, получается то что я описал выше, не все это могут поятнуть
Поддержать репозитории не проблема пока в разработчики хотят писать продаваемый софт, а не писать так чтобы было легче писать.
Здравствуйте, Sheridan, Вы писали:
S>Значит в вашей команде админ/девапс должен заниматься пакетированием, а не деплоем в хосты.
А точно не CI?
Я еще раз повторю, что все эти проблемы, они не про пакетирование, а про разработку. Тебе легко писать — пусть программисты пишут хорошо, вместо того чтобы писать плохо. Но попробуй сделай хорошо основываясь на зависимости, которая ломает обратную совместимость или работает по разному в разных дистрибутивах linux, т.к. собрана там с разными флагами.
S>Опакетить несложно. А накладывает оно ограничения на разработку до тех пор, пока вы не примете решение — вам важнее продавать софт, установка которого безболезнена для пользователя или вы пишете софт для того чтобы легче было писать софт.
На разработку софта есть какой-то бюджет времени, ты можешь расходовать его на фичи, а можешь на непродуктивные вещи.
S>Поддержать репозитории не проблема пока в разработчики хотят писать продаваемый софт, а не писать так чтобы было легче писать.
А потом оказывается, что твой пакет для Debian почти не качают, наверное потому, что апологеты linux way стремаются ставить софт из сторонних репозиториев, а вот активнее всего народ качает именно твой докер образ (в моей ситуации примерно в пять раз чаще скачивают docker image нежели все rpm/deb вместе взятые под все платформы).
