Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Ilya81, Вы писали:
I>>Так что написать так, что сработает на разных первоначальных конфигурациях, предоставляемых конкретным hoster'ом — дело не из простых. S>Это всё довольно просто делается. Вангую трудозатраты где-то 8 часов на дистрибутив при старте и поддержка 2-4 часа на дистрибутив в месяц.
И не случалось при этом такого, что при перемещении на другой hosting приходилось что-то вручную доисправлять?
Здравствуйте, Sheridan, Вы писали:
S>В остальных случаях использование докеров — звоночек в некотором тяпляпстве разработчиков.
тяпляпство — это когда на рабочих серверах ставят JVM от IBM, а разработчикам — от Oracle. Случай реальный.
S>Значит что они не смогли разрулить зависимости и просто запихнули нужное окружение в контейнер. Как правило плюсом к этому идут старые либы окружения, которые разрабам "некогда" обновлять.
Балинн, сколько раз это уже обсуждалось. Ну не всегда есть возможность взять последние версии всего и вся.
Вот я несколько лет назад работал с одной библиотекой (open source, замечу). Однажды скачал ее последнюю версиию. И увидел, что некоторые классы, которые я активно использую, просто исчезли. Я сунулся в документацию, а ее почему-то не обновили. Исходников было всего ничего, каких-то 12 мегов. На полчаса чтобы разобраться. Но вот не было у меня тогда этиъ полчаса.
Позже я перешел на новую версию. Раскопал в исходниках то, что мне нужно. Потому что в новой версии были некоторые очень удобные функции. Плюс там починили пару багов. Но найти нужные классы и подключить их вместо старых заняло чуть больше получаса.
Здравствуйте, student__, Вы писали:
A>>2) X Window в то время уже был больше десяти лет.
__>Был-то он был, но какой полноценный десктоп был в 1995г. на X Window, и сколько стоило железо?
Я подозреваю, что стоимость железа к самому X Window отношения не имеет.
Ничто не мешало Биллигейцу запилить свою реализацию Иксов на своём железе.
Но он предпочёл идти своим путём. И создал глючное (очень глючное) поделие.
PS.
Ах да! Я же вспомнил! У меня на Windows95 стоял Xceed!
Это реализация X-протокола для Виндов.
Сидишь на Винде, а Sun не твоём мониторе тебе окошки отрисовывает.
Так что всё нормально тогда было со стоимостью железа.
Здравствуйте, Tai, Вы писали:
Tai>Мне одному кажется, что Microsoft перестаёт дарить миру революционные технологии?
А он их когда то дарил? Оппортунизм почти всегда был основой их стратегии.
Tai> Windows топчется на месте,
Десктоп умер, а на мобилках и серверах венда в итоге не шмогла. В первом случае в силу безумных действий топ менеджмента, во втором в силу неверно выбранной ценовой политики.
Здравствуйте, CreatorCray, Вы писали:
A>>Например нормальная работа с памятью, нормальная многозадачность, A>>нормальная графическая система, нормальные средства отладки, A>>нормальная защищённость.
CC>Это ну очень уж нормальные общие слова. CC>В чём именно заключается "нормальность" каждого из них?
Это примерно как обьяснить негру, что такое снег.
Ну вот вы не ели ничего слаще морковки, ну и не знаете, как оно бывает.
Ну, что, я тебе буду всю свою жизнь рассказывать?
Ну вот есть IBM PC с Виндой и ТурбоС и есть Микровакс.
И на Микроваксе разработка идёт в десять раз быстрее,
потому что он не падает, не ломается, не теряет данные, в нём нет вирусов,
он не убивает свою файловую систему, и фиксирует все ошибки работы с памятью.
CC>Ну вот например "нормальная многозадачность", как это "нормально" реализовывалось на 486x да чтоб ещё и работало приемлемо быстро?
Нормальная многозадачность — это когда одна задача не может завалить другую,
не может поставить всю ось раком, когда помогает только перезагрузка,
когда после перезагрузки не слетает файловая система,
и когда машину вообще можно перегружать раз в год.
Чё вам так дался этот 486?
Мой первый линукс (RedHat 5.2) был установлен именно на AMD486DX5.
И там была та самая многозадачность, и иксовая графика.
И работало всё там приемлемо быстро.
И набор средств программирования там был уже более-менее.
Винда так не умела? Ну кто-ж ей виноват?
Но только Микровакс давал всё это уже во времена 286-х.
И вообще, PC — отстой.
Я бы предпочёл иметь тот же самый Линукс, но на процессоре другой архитектуры.
VAX подходит, ARM — тоже ничего.
Здравствуйте, ·, Вы писали:
S>>·>Причём тут отмазы? Какой ты ещё способ предложишь быть уверенным, что то что работает в проде это ровно то, что тестировалось? Как ещё быть уверенным, что ищешь багу ровно в том коде, который работает на проде? S>>Оно должно работать без тепличных условий контейнера. А это значит как минимум — с актуальными версиями библиотек окружения. ·>Однако, оно может работать немного по-разному.
Значит вы чтото делаете не так.
S>>Как такого добиться? Очень просто. Устанавливаем дистрибутив, обновляем его (читай — восстанавливаем "как было" виртуалку из снапшота) и тестируем. ·>И сколько по времени занимает установка дистрибутива и обновление? ·>При генерации docker image это и просиходит — устанавливается дистрибутив, нужные компоненты, обновляется, конфигурируется. Просто после этого результат фиксируется в виде снапшота с уникальным sha2 и может быть мгновенно за секунды развёрнут и запущен где угодно.
Устанавливаются тепличные условия, ты прав.
S>>·>Можно, конечно, придумать какие-то скрипты, в которые можно прописать компоненты и их версии, описать как их разместить их в дереве файлов, запаковать в архивы и выложить в какое-нибудь хранилище. Или, Иными словами, переизобрести докер-имадж. Но зачем? S>>Ничего переизобретать и вообще изобретать не надо. Я выше описал. ·>Да, ты выше и переизобрёл, правда кривовато и тормозно.
В чём кривость и тормоза?
S>>В дополнение могу написать только то, что если вы разрабатываете сложную систему (которая устанавливается не просто юзеру на машину, но требует для себя несколько серверов, несколько сервером для окружения итд), то деплой пишется на том-же ансибле или там солте. ·>Ансибл и подобное имеет другое предназначение. Это, например, подготовка компа для пользователя. Купили лаптоп, натравили ансибл и у тебя готовая машинка выдать очередному сотруднику. Если сотрудник что-то испортит — можно легко пофиксить. ·>У докера другое предназначение, для деплоймента приложений. Поставили новую железку в стойку и запустили на нём нужные сервисы. Потом обновляем сервис на новую версию, переносим на другую железку, етс.
Докер не для деплоя. Докер для тепличных условий. Деплой это сетуп.экзе, ансибл, салт.
S>>И никакие тепличные докеры не нужны. ·>Не нужны, но с ними проще и быстрее решаются некоторые задачи.
Я описал какие:
1. Создание окружений для разработки/тестирования (например, в условиях параллельной разработки нескольких проектов)
2. Необходимость масштабирования в рантайме.
S>>есть ещо окружение, за которым тоже надо следить и своевременно обновлять. ·>Докер это не запрещает, а упрощает.
Бгггг. Докер не запрещает и не обновлять. И этим категорически злоупотребляют.
Точнее, сначала забивают болт на обновления, а потом прикручивают докер чтобы и дальше забивать.
Здравствуйте, Ilya81, Вы писали:
I>>>Так что написать так, что сработает на разных первоначальных конфигурациях, предоставляемых конкретным hoster'ом — дело не из простых. S>>Это всё довольно просто делается. Вангую трудозатраты где-то 8 часов на дистрибутив при старте и поддержка 2-4 часа на дистрибутив в месяц. I>И не случалось при этом такого, что при перемещении на другой hosting приходилось что-то вручную доисправлять?
Тут как минимум два варианта:
1. Заказчик сам деплоит. ХЗ, может и допиливает.
2. Деплою я. У меня значит есть все входные данные и хотелки заказчика. Деплой изначально подравнивается под него.
Но ты увёл разговор немного в сторону. Речь щла о деплое под разные дисрибутивы а не про переезд с одного хостера в лругой. Тут непонятно что такое hosting. Если это виртуалки — то какая разница. С точки зрения деплоя это просто сервера. Если это некие сервисы (типа амазоновских) то непонятно почему вообще возникает вопрос такой "не допиливается ли?...". Ясен хрен не просто допиливается а хорошо допиливается ибо все подобные сервисы — разные.
Здравствуйте, Privalov, Вы писали:
S>>В остальных случаях использование докеров — звоночек в некотором тяпляпстве разработчиков. P>тяпляпство — это когда на рабочих серверах ставят JVM от IBM, а разработчикам — от Oracle. Случай реальный.
Да, это тоже тяплапство: отсуствие упоминание о поддерживаемой jvm в документации. Отсуствие деплоя jvm в процессе, собственно, деплоя приложения.
S>>Значит что они не смогли разрулить зависимости и просто запихнули нужное окружение в контейнер. Как правило плюсом к этому идут старые либы окружения, которые разрабам "некогда" обновлять. P>Балинн, сколько раз это уже обсуждалось. Ну не всегда есть возможность взять последние версии всего и вся.
Всегда. Правильно распределяйте время, планируйте.
P>Вот я несколько лет назад работал с одной библиотекой (open source, замечу). Однажды скачал ее последнюю версиию. И увидел, что некоторые классы, которые я активно использую, просто исчезли. Я сунулся в документацию, а ее почему-то не обновили. Исходников было всего ничего, каких-то 12 мегов. На полчаса чтобы разобраться. Но вот не было у меня тогда этиъ полчаса.
Форсмажоры никто не отменяет. В данном случае оставаться на той что есть плюс запрос автору на документацию.
P>Позже я перешел на новую версию. Раскопал в исходниках то, что мне нужно. Потому что в новой версии были некоторые очень удобные функции. Плюс там починили пару багов. Но найти нужные классы и подключить их вместо старых заняло чуть больше получаса.
Но ты даже осилил сам всё раскопать. Молодец.
Здравствуйте, alpha21264, Вы писали:
A>Ничто не мешало Биллигейцу запилить свою реализацию Иксов на своём железе.
Таки мешало. Потому как SW бизнес и HW бизнес это ОЧЕНЬ рахные вещи.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, alpha21264, Вы писали:
A>Это примерно как обьяснить негру, что такое снег. A>Ну вот вы не ели ничего слаще морковки, ну и не знаете, как оно бывает.
Какие милые детские понты
Начало интересное, дальше надо полагать такие же растопыреные пальцы будут?
A>Ну, что, я тебе буду всю свою жизнь рассказывать?
Да кому твоя жизнь надо, тебя про технические детали спрашивают.
A>Ну вот есть IBM PC с Виндой и ТурбоС и есть Микровакс. A>И на Микроваксе разработка идёт в десять раз быстрее, A>потому что он не падает, не ломается, не теряет данные, в нём нет вирусов, A>он не убивает свою файловую систему, и фиксирует все ошибки работы с памятью.
Это всё пустой трёп и байки. Чикага была тем ещё говном, но в отличие от большинства альтернатив, которые юзер мог запускать на своём железе, она таки работала с приемлемой скоростью и, самое главное, давала юзеру возможность запускать тот софт, что ему был нужен.
Так что проблема винды была в том, как это всё заставить шевелиться на том букете железа, что есть у массового кастомера, а не на SoC от одного производителя.
Потому и были отдельно NT для серваков и отдельно чикага для юзверей, с кучей вынужденных компромиссов чтоб оно на том хламе, что у юзера есть, бегало.
A>не может поставить всю ось раком, когда помогает только перезагрузка,
Кривой драйвер или глючная железяка может поставить всё раком в любой системе.
В тепличных условиях, когда всё железо твоё — с этим проще. Но это не заслуга ОС.
A>когда после перезагрузки не слетает файловая система,
Это вообще не имеет отношения к многозадачности.
A>Чё вам так дался этот 486?
Да потому что на момент выходя Win95 это был наиболее вменяемый проц из того что было у клиентской базы.
A>Мой первый линукс (RedHat 5.2) был установлен именно на AMD486DX5.
А линух то к VMX каким боком?
A>И там была та самая многозадачность, и иксовая графика. И работало всё там приемлемо быстро. И набор средств программирования там был уже более-менее.
Вот это щас очень смешно было. Я помню как оно было "быстро", какой глючный мрак был та самая "иксовая графика", и какой там был набор средств для девелопмента — каменные топоры и палки копалки.
Причём что в те времена что линух что винду периодинчески раскорячивало.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Sheridan, Вы писали:
S>Да, это тоже тяплапство: отсуствие упоминание о поддерживаемой jvm в документации. Отсуствие деплоя jvm в процессе, собственно, деплоя приложения.
Я, признаться, не знаю, как получилось, что разные JVM работали в разных средах. Могу сказать: админы накосячили. Но не скажу. Реальность суровее. Поэтому я и не учу админов админить.
S>Всегда. Правильно распределяйте время, планируйте. S>Форсмажоры никто не отменяет.
Не находишь тут противоречия? думаю, что нет.
Тебе всегда удается все правильно планировать? Мне — с переменным успехом. В силу ряда объективных и субъективных причин.
S>Но ты даже осилил сам всё раскопать. Молодец.
Опыт не пропьешь. Я чуть меньше, чем все врем, работаю с чужим кодом. После лазания с маркером и карандашом по километровым листингам с фортрановским кодом, а почти ничего не боюсь. Плюс толька везения в данном конкретном случае. Во-первых, все остальные части остались без изменений. Во-вторых, нужный мне функционал находился в определенном пространстве имен. Ну пришлось исходники покопать, и я знал что в данном конкретном случае на низком уровне происходит. Потому и справился.
Здравствуйте, Sheridan, Вы писали:
S>>>·>Причём тут отмазы? Какой ты ещё способ предложишь быть уверенным, что то что работает в проде это ровно то, что тестировалось? Как ещё быть уверенным, что ищешь багу ровно в том коде, который работает на проде? S>>>Оно должно работать без тепличных условий контейнера. А это значит как минимум — с актуальными версиями библиотек окружения. S>·>Однако, оно может работать немного по-разному. S>Значит вы чтото делаете не так.
Цель изменений — чтобы что-то работало по-другому. Поэтому, разные версии по определению работают по-разному. Вопрос лишь в том, оказывает ли существенное влияние эта разница на функционирование нашего приложения. Это можно узнать только тестированием. А ещё бывают баги и неожиданные изменения.
S>·>И сколько по времени занимает установка дистрибутива и обновление? S>·>При генерации docker image это и просиходит — устанавливается дистрибутив, нужные компоненты, обновляется, конфигурируется. Просто после этого результат фиксируется в виде снапшота с уникальным sha2 и может быть мгновенно за секунды развёрнут и запущен где угодно. S>Устанавливаются тепличные условия, ты прав.
Чем устанавливаются? Куда?
S>>>·>Можно, конечно, придумать какие-то скрипты, в которые можно прописать компоненты и их версии, описать как их разместить их в дереве файлов, запаковать в архивы и выложить в какое-нибудь хранилище. Или, Иными словами, переизобрести докер-имадж. Но зачем? S>>>Ничего переизобретать и вообще изобретать не надо. Я выше описал. S>·>Да, ты выше и переизобрёл, правда кривовато и тормозно. S>В чём кривость и тормоза?
Ответь на вопрос вначале: И сколько по времени занимает установка дистрибутива и обновление?
S>>>В дополнение могу написать только то, что если вы разрабатываете сложную систему (которая устанавливается не просто юзеру на машину, но требует для себя несколько серверов, несколько сервером для окружения итд), то деплой пишется на том-же ансибле или там солте. S>·>Ансибл и подобное имеет другое предназначение. Это, например, подготовка компа для пользователя. Купили лаптоп, натравили ансибл и у тебя готовая машинка выдать очередному сотруднику. Если сотрудник что-то испортит — можно легко пофиксить. S>·>У докера другое предназначение, для деплоймента приложений. Поставили новую железку в стойку и запустили на нём нужные сервисы. Потом обновляем сервис на новую версию, переносим на другую железку, етс. S>Докер не для деплоя. Докер для тепличных условий.
Именно — для быстрого и надёжного деплоя куда угодно ровно того что нужно.
S>Деплой это сетуп.экзе, ансибл, салт.
Это инсталляция.
S>>>И никакие тепличные докеры не нужны. S>·>Не нужны, но с ними проще и быстрее решаются некоторые задачи. S>Я описал какие: S>1. Создание окружений для разработки/тестирования (например, в условиях параллельной разработки нескольких проектов)
Это можно и тем же ансиблом можно делать. Докер для этого необязателен. Но таки да, удобнее, т.к. быстрее.
S>2. Необходимость масштабирования в рантайме.
Это уже следствие. Если мы можем легко и быстро переносить софт между хостами, то можно это делать много, т.е. масштабировать.
S>>>есть ещо окружение, за которым тоже надо следить и своевременно обновлять. S>·>Докер это не запрещает, а упрощает. S>Бгггг. Докер не запрещает и не обновлять.
А кто может запретить не обновлять?!
S>И этим категорически злоупотребляют.
Злоупотреблять можно чем угодно. И без докеров нередко попадаются древние версии операционок и т.п.
S>Точнее, сначала забивают болт на обновления, а потом прикручивают докер чтобы и дальше забивать.
Отсутствие докера положение только усугубляет. Начнёшь что-нибудь обновлять, что-то сломается по дороге и фиг потом восстановишь. Особенно весело, когда на тестовом окружении всё прошло как по маслу, а на проде что-то пошло не так. Поэтому риск слишком высок.
С докером же если обновление не работает, откат тривиален и надёжен, и часто даже автоматический откат.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Privalov, Вы писали:
S>>Да, это тоже тяплапство: отсуствие упоминание о поддерживаемой jvm в документации. Отсуствие деплоя jvm в процессе, собственно, деплоя приложения. P>Я, признаться, не знаю, как получилось, что разные JVM работали в разных средах. Могу сказать: админы накосячили. Но не скажу. Реальность суровее. Поэтому я и не учу админов админить.
Как получилось не знаешь, но виноваты всё равно админы. Но работать ты их не учишь...
Может беды из-за этого и пора начать учить?
S>>Всегда. Правильно распределяйте время, планируйте. S>>Форсмажоры никто не отменяет. P>Не находишь тут противоречия? думаю, что нет. P>Тебе всегда удается все правильно планировать? Мне — с переменным успехом. В силу ряда объективных и субъективных причин.
"Не планировать" и "запланировать но в силу обстоятельств сдвинуть планы" — несколько разные вещи, не находишь ли?
Здравствуйте, Farsight, Вы писали:
S>>Докер не для деплоя. Докер для тепличных условий. Деплой это сетуп.экзе, ансибл, салт. F>А вдруг для деплоя?
В рекламе и не такого могут понаписать.
Здравствуйте, ·, Вы писали:
·>Цель изменений — чтобы что-то работало по-другому. Поэтому, разные версии по определению работают по-разному. Вопрос лишь в том, оказывает ли существенное влияние эта разница на функционирование нашего приложения. Это можно узнать только тестированием. А ещё бывают баги и неожиданные изменения.
Раз такая цель — то и никаких проблем, ибо изменения ожидаемые.
S>>Устанавливаются тепличные условия, ты прав. ·>Чем устанавливаются? Куда?
Докером для приложения.
S>>>>·>Можно, конечно, придумать какие-то скрипты, в которые можно прописать компоненты и их версии, описать как их разместить их в дереве файлов, запаковать в архивы и выложить в какое-нибудь хранилище. Или, Иными словами, переизобрести докер-имадж. Но зачем? S>>>>Ничего переизобретать и вообще изобретать не надо. Я выше описал. S>>·>Да, ты выше и переизобрёл, правда кривовато и тормозно. S>>В чём кривость и тормоза? ·>Ответь на вопрос вначале: И сколько по времени занимает установка дистрибутива и обновление?
S>>>>В дополнение могу написать только то, что если вы разрабатываете сложную систему (которая устанавливается не просто юзеру на машину, но требует для себя несколько серверов, несколько сервером для окружения итд), то деплой пишется на том-же ансибле или там солте. S>>·>Ансибл и подобное имеет другое предназначение. Это, например, подготовка компа для пользователя. Купили лаптоп, натравили ансибл и у тебя готовая машинка выдать очередному сотруднику. Если сотрудник что-то испортит — можно легко пофиксить. S>>·>У докера другое предназначение, для деплоймента приложений. Поставили новую железку в стойку и запустили на нём нужные сервисы. Потом обновляем сервис на новую версию, переносим на другую железку, етс. S>>Докер не для деплоя. Докер для тепличных условий. ·>Именно — для быстрого и надёжного деплоя куда угодно ровно того что нужно.
Ansible, salt для сложный систем.
Опакетить, опять же можно если очередной сидтэжектор.
Но нет же. Нужен именно докер...
S>>Деплой это сетуп.экзе, ансибл, салт. ·>Это инсталляция.
Ээээ, друг. Это смотря сколько чего участвует в развёртывании.
Если сидиэжектор очередной ставится на ноут домохозяйки — это инсталляция.
Если поднимается некая скада у которой только обслуживающих серверов под перефирийное ПО несколько штук — это деплой.
S>>>>есть ещо окружение, за которым тоже надо следить и своевременно обновлять. S>>·>Докер это не запрещает, а упрощает. S>>Бгггг. Докер не запрещает и не обновлять. ·>А кто может запретить не обновлять?!
Проблема в том, что нет как правило волевых людей, которые запрещают не обновлять. И в итоге всё скатывается в сраное говно когда приложения для работы нужны либы вековой давности а переход на новые версии, из-за систематического забивания болтов на обновления, настолько уже сложен, что проще начать писать с нуля.
И дуд приходит докер в ореоле Чистого Света. И появляется куча статей "ооо какие мы крутые переехали на докер!". А там куда ни копни — вежде говно мамонта внутрях.
S>>И этим категорически злоупотребляют. ·>Злоупотреблять можно чем угодно. И без докеров нередко попадаются древние версии операционок и т.п.
Попадаются, да. Категорически легко обходится пунктом в инструкции под заголовком "Минимальные системные требования".
S>>Точнее, сначала забивают болт на обновления, а потом прикручивают докер чтобы и дальше забивать. ·>Отсутствие докера положение только усугубляет. Начнёшь что-нибудь обновлять, что-то сломается по дороге и фиг потом восстановишь. ·>Особенно весело, когда на тестовом окружении всё прошло как по маслу, а на проде что-то пошло не так.
Вот, вот оно! Я дождался!
Знаешь почему это происходит в проде?
Потому что, ммать, вы забили болт обновлять дистрибутивы у себя даже на тестах, не говоря уже об остальном.
Добавьте в планы хотя бы раз в квартал обновляться. Да ладно раз в квартал... Хотя бы перед релизом протестируйте на свежих версиях поддерживаемых дистрибутивов.
Здравствуйте, Sheridan, Вы писали:
S>·>Цель изменений — чтобы что-то работало по-другому. Поэтому, разные версии по определению работают по-разному. Вопрос лишь в том, оказывает ли существенное влияние эта разница на функционирование нашего приложения. Это можно узнать только тестированием. А ещё бывают баги и неожиданные изменения. S>Раз такая цель — то и никаких проблем, ибо изменения ожидаемые.
Ты баги, например, уже запретил?
Как ты проверишь, что ожидаемые изменения работают ожидаемо?
S>>>Устанавливаются тепличные условия, ты прав. S>·>Чем устанавливаются? Куда? S>Докером для приложения.
Ты говоришь, как будто это что-то плохое.
S>>>В чём кривость и тормоза? S>·>Ответь на вопрос вначале: И сколько по времени занимает установка дистрибутива и обновление?
Сложный вопрос, да?
S>·>Именно — для быстрого и надёжного деплоя куда угодно ровно того что нужно. S>Ansible, salt для сложный систем.
Это как раз для простых систем. В сложных системах становится всё плохо.
Такой простой сценарий. Прогоняешь ты на проде очередной плейбук из 10 шагов. Допустим 5й шаг зафейлился. Что будешь делать?
В случае же докера у тебя ровно один шаг — выкатить имадж. Если он не срабатывает, то всё остаётся в текущем состоянии.
Другой сценарий. Ты прогнал таки плейбук и выкатил очередную версию. Через пол часа юзеры пожаловались, что как-то всё притормаживает. Как откатишься к предыдущему состоянию? Как потом будешь искать проблему тормозов, пока прод крутится на старой версии?
В случае докера просто выкатываешь предыдущий образ, идентифицируемый по sha2. Всё. Проблему ищешь в тестовом енве, выкатив ровно тот же sha2 на который юзеры жаловались.
S>Опакетить, опять же можно если очередной сидтэжектор. S>Но нет же. Нужен именно докер...
Я понял, ты не видел ничего сложнее сидиэджектора, вот и думаешь, что аснибл — всемогутер.
S>>>Деплой это сетуп.экзе, ансибл, салт. S>·>Это инсталляция. S>Ээээ, друг. Это смотря сколько чего участвует в развёртывании. S>Если сидиэжектор очередной ставится на ноут домохозяйки — это инсталляция. S>Если поднимается некая скада у которой только обслуживающих серверов под перефирийное ПО несколько штук — это деплой.
Ну вот видишь... А теперь представь, что серверов у тебя на порядка 2 больше, десятки разных приложений, на разных яп, использующие разные версии рантайма, операционки, дублирование в разных DC, всякий A/B-rollout, етс.
S>>>Бгггг. Докер не запрещает и не обновлять. S>·>А кто может запретить не обновлять?! S>Проблема в том, что нет как правило волевых людей, которые запрещают не обновлять.
Как только неожиданный очередной WindowsUpdate, или важные security updates внезапно перезагрузит прод и что-то не загрузится, так сразу все эти обнавлялки и повырубают.
S>И в итоге всё скатывается в сраное говно когда приложения для работы нужны либы вековой давности а переход на новые версии, из-за систематического забивания болтов на обновления, настолько уже сложен, что проще начать писать с нуля. S>И дуд приходит докер в ореоле Чистого Света. И появляется куча статей "ооо какие мы крутые переехали на докер!". А там куда ни копни — вежде говно мамонта внутрях.
Ты так и не объяснил, чем недокер поможет.
S>>>И этим категорически злоупотребляют. S>·>Злоупотреблять можно чем угодно. И без докеров нередко попадаются древние версии операционок и т.п. S>Попадаются, да. Категорически легко обходится пунктом в инструкции под заголовком "Минимальные системные требования".
Инструкции в ворд-документе?!
S>·>Отсутствие докера положение только усугубляет. Начнёшь что-нибудь обновлять, что-то сломается по дороге и фиг потом восстановишь. S>·>Особенно весело, когда на тестовом окружении всё прошло как по маслу, а на проде что-то пошло не так. S>Вот, вот оно! Я дождался! S>Знаешь почему это происходит в проде?
Потому что очень сложно без докера обеспечить повторяемость. Результат обновления у себя в тестах может быть не идентичен результату такого же обновления в проде, спустя некоторое время.
S>Потому что, ммать, вы забили болт обновлять дистрибутивы у себя даже на тестах, не говоря уже об остальном.
Ты видимо не понимаешь как докер работает. Он как раз этот процесс и облегчает. Обновляешь у себя в тестах, тестируешь, а потом ровно это обновлённое и оттестированное промоутишь в прод.
S>Добавьте в планы хотя бы раз в квартал обновляться. Да ладно раз в квартал... Хотя бы перед релизом протестируйте на свежих версиях поддерживаемых дистрибутивов.
Именно. Вопрос в планах на обновление, а не в докере-ансибле.
И ты упорно игнорируешь тот факт, что планы на обновление осуществлять _проще_ в докере, чем в ансибле.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Sheridan, Вы писали:
P>>Могу сказать: админы накосячили. Но не скажу. Реальность суровее. Поэтому я и не учу админов админить. S>Как получилось не знаешь, но виноваты всё равно админы. Но работать ты их не учишь...
Величайшей ошибкой было бы думать. В. И. Ленин, ПСС, т.42. с.74
Может, попробуешь прочитать чуть дальше "авмины накосячили"? Специально оставлю.
S>Может беды из-за этого и пора начать учить?
Мое дитя выросло и стало нормальным сисадмином. Само научилось. Код писать не хочет. Говорит, не умеет.
У расработчиков специфика другая. Мы в реальности с админами взаимодействуем. Как и с безопасниками, и остальными спецами. Редкие исключения случаются. Типа того "админа",который на рабочий сервер дважды в неделю умудрялся трояна, шифрующего файлы, пропускать. Я его, кстати, однажды полдня убеждал, что у него на сервере часы неправильно идут. Убедил, только получив доступ к тому серверу и сделав снимок экрана с часами. А мог бы и отформатировать там чего-нибудь.
Сейчас там нормальный спец, никаких терок не возникает. Любые конфликты разрешаются в рабочем порядке.
S>"Не планировать" и "запланировать но в силу обстоятельств сдвинуть планы" — несколько разные вещи, не находишь ли?
Но вот не было у меня тогда этиъ полчаса.
Я чуть меньше, чем все врем, работаю с чужим кодом. После лазания с маркером и карандашом по километровым листингам с фортрановским кодом, а почти ничего не боюсь. Плюс толька везения в данном конкретном случае. Во-первых, все остальные части остались без изменений. Во-вторых, нужный мне функционал находился в определенном пространстве имен. Ну пришлось исходники покопать, и я знал что в данном конкретном случае на низком уровне происходит. Потому и справился.
