• «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    0

    Да и кубернетес можно написать. Докер же на баше написали!


    https://github.com/p8952/bocker

  • «Однорукий интерфейс»: баг или фича, позволяющая Делимобилю отнимать деньги у пользователей?
    0
    относительно безопасную 7местную машину но есть желание...

    минимум мульт рублей, самое дешевое было — Hyunday Starex. Но там нюанс с категорией. А так — Mercedes Vito/Viano, VW Caravelle… И тяготеем к последнему

  • «Однорукий интерфейс»: баг или фича, позволяющая Делимобилю отнимать деньги у пользователей?
    +1

    детей старше какого возраста, простите, по-Вашему?

  • «Однорукий интерфейс»: баг или фича, позволяющая Делимобилю отнимать деньги у пользователей?
    0

    А какая разница? У меня трое и три полноценных детских кресла и мы строго привязаны к своей машине поэтому… Ни одно такси не подойдет (


    непригодные для нормальных кресел

    ???? Ну, вообще любые дети, кажется, лет до 8, точно ездят или в креслах, или в бустерах

  • «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    0
    А потом пару часов пытаешься понять почему по ряду задач у тебя 2 tps кладут твой магический кластер на k8s…

    не принимается — это сертифицированный дистрибутив CNCF. А как известно… сломать можно что угодно :-)


    В общем, когда я слышу, что k8s поднимается за 5-10-15 минут и даже часов…

    в облаке тем более поднимается за 5-10-15 минут :-) Повторю тезис, что основные решения типовые, но если требуется что-то особенное — проектирование и согласование может занять времени существенно больше, чем фактическое разворачивание.

  • «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    0

    С конфетами в файлах много проблем. Если запекать их в образа — конфиг получается 100% статичным. Кубер же предлагает ConfigMap. Неудобство в том, что во многих приложениях нет хотреалоада конфига — приходится костылять сбоку. И получается два процесса (независимых) — доставка конфига и доставка новой версии приложения.


    Поэтому мой выбор — пара переменных для определения окружения (prod|dev|test) и все остальное в иерархии в консуле. И это мы еще не затрагивали доставку секретов (oh, shi~..)


    как следствие — неявная конфигурация, когда переменная окружения может повлиять на приложение неизвестным способом

    было уже. Кубер пишет переменные окружения, иногда они пересекаются с конфигурацией приложения… Потом — закономерный ба-бах. Как здесь: https://habr.com/ru/company/flant/blog/510486/

  • «Однорукий интерфейс»: баг или фича, позволяющая Делимобилю отнимать деньги у пользователей?
    0
    В итоге поездка вышла на 200 рублей дороже чем такси (вместо 500 за такси, 700 за каршеринг), с тех пор я думаю мы с каршерингом точно вынуждены будем попрощаться.

    КАК ПРАВИЛО — каршеринг получается 1/2 от стоимости такси. Но вот буквально на днях получилось наоборот — Академическая — Мытищи — каршеринг — 1200, такси (комфорт) — 1000, естественно, поехал на такси.

  • Эти безумные KPI
    0

    Ну, если премия квартальная и уволиться раньше ее выплаты, то я не знаю о случаях не выплаты за неполные интервалы

  • «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    0
    Мы активно используем OpenShift, и там до сих пор, даже в последних версиях используется Docker в качестве основного инструмента контейнеризации.

    информация недостоверна. В новых версиях OpenShift — CRI-O.

  • KPI. Или как руководители боятся посмотреть в глаза сотруднику при начислении зарплаты. (Исправлено)
    0
    KPI системного администратора бывает.

    и каково его оптимальное значение, подскажите?

  • KPI. Или как руководители боятся посмотреть в глаза сотруднику при начислении зарплаты. (Исправлено)
    0
    когда Сашу лишают премии/уволняют «потому что лентяй», без объяснения ему и окружающим

    если всем очевидно, что Саша лентяй — почему бы и не уволить? Проблема в том, что зачастую это неочевидно, а в случае еще и с кривыми KPI это все равно будет "нечестной игрой".

  • KPI. Или как руководители боятся посмотреть в глаза сотруднику при начислении зарплаты. (Исправлено)
    –3
    Разве непонятно что корень проблемы не в ножах?

    ну, все стандартно — лечим или симптомы (это проще, но не очень эффективно в долгосроке), или корневую причину (долго, дорого).


    Ну и в чём тут виноват KPI?

    в том, что это узаконенный "кнут"?

  • «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    0
    Внутри контейнера может быть хоть миллион портов поднято быть. Я все равно смогу вытащить только то, что мне нужно и только на том интерфейсе, на котором мне нужно.

    с какой целью должно быть поднято миллион портов? Извините, из Ваших суждений — Вы ничего не понимаете. На уровне разработки — уверен, у Вас все прекрасно, на уровне эксплуатации — именно то, что я говорю. Я уж не говорю о том, что ВНУТРИ БРИДЖА НИКАКОГО контроля взаимодействия контейнеров нет.


    Дефолтный бридж

    тем более — в котором и изоляции нет, и DNS не работает, ага-ага.

  • «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    0

    скорее — наши кормильцы, хлеб насущный нам дающие… vivat!

  • «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    +1

    Это когда ты внутри мейкфайла при сборке докер образа делаешь что-то типа touch image.flag и далее по этому флаг-файлу мейк понимает, что образ уже собран и, например, пересобирать его не надо

  • Агрессивный переход в облако Atlassian или это vendor lock-in?
    0

    Тут проблема в другом. Конкурентов практически нет. Точнее есть. Но это все не то. И есть останавливающая от перехода его стоимость. Которая сильно не нулевая. И поэтому какое-то время ёжики будут жрать кактус. Что хуже — на полученные от жира деньги потенциально атлашиан может попробовать скупить своих конкурентов. В результате будет экосистема Атлашиан и ещё пары конкурентов. С примерно одинаковым качеством.
    Уходить в опенсурс — так ничего примерно такого же по качеству и функционалу нет. Редмайн? Ну, умоляю. Гитлаб? Ну, там с ишьюс можно работать только в платной версии. Ну, и т.д. Краткий вывод — пользователь заплатит в любом случае. Вопрос только в сумме и количестве страданий

  • «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    0

    Уже давно работает без

  • «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    0

    Есть упрощенные варианты кубернетеса, которые можно устанавливать на единичные отдельные ноды. Те же K3s, microk8ss, Minikube etc. Цель — унификация процесса разработки, доставки приложений, управления приложениями и эксплуатацией…

  • «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    0

    Там все сложно. Есть rke. Это дистрибутив куба, сделанный ранчером. Но не ранчер. В принципе, штука неплохая и достаточно беспроблемная sn00p может подробно рассказать. Никаких «левых» сущностей не тащит.
    Ранчер же сам — это в первую очередь панель для централизованного управления кластера. И как Вы правильно заметили, тащит некие свои сущности в кластер (проекты, например, свою ролевую модель). В принципе, не выглядит как что-то совсем невменяемое, но специфика имеется. Мониторинг в ранчере тоже очень своеобразный. Плюс, что он есть. Минус, что они его сделали не самым прямолинейным образом. Интеграция с магазином приложений ( и там тоже есть как стандартные Хельм чарты, так и допиленные ранчером).
    Я хотел бы, чтобы потенциальные пользователи этого решения сами его пробовали и осознанно выбирали нужно ли оно им. Есть строгие подозрения, что вместо ранчера лучше брать ОКД (бесплатный опеншифт), но в нем специфики ещё больше. Что с точки зрения разраба, что с точки зрения эксплуатации.

  • «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    0
    Если не принимать специальных мер на ноде лежат все образа, когда-либо использовавшиеся на ней.

    это не так. Хотя бы потому что kubelet делает garbage collection на неиспользуемые по определенному набору критериев

  • «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    0
    то место на диске тратить на бесполезные копии моделей в каждом контейнере не хочется.

    так место с докер образами, напротив, экономится (потому что на ноде лежат только те образа, которые сейчас нужны, с нужными версиями моделей). Если только не делать сетевое хранилище.


    так вот рединес проб эту бинарность дает.

    только Вы еще добавляете еще зависимость от ненадежной сети :-/ И если делать скачивание c S3, как Вы предлагаете:


    Положили на S3, при старте под закачивает их себе в ФС, загружает в память и удаляет.

    то каждый старт контейнера пода скачивает из хранилища модель. Дорого по трафику и времени. И вносит определенную степень хаоса (модель может не скачаться вовсе). И кушают место на эфемерном хранилище ноды… (хотя бы временно)

  • «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    0

    Пользователь хочет k8s, потому что он обеспечивает "единый язык описания" вне зависимости от нижележащей инфраструктура. Кубер в целом одинаковый и в amazon, и в google, и в azure, и в он-прем. Могут быть детали, какие-то дополнительные фишки, но это не критично

  • «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    +1
    По поводу rancher исходя из устаревшего сравнения https://dvps.blog/minimalnoie-sravnieniie-swarm-kubernetes-mesos-nomad-rancher/ там не все так ванильного.

    чушь. Они там сравнивают rancher 1.x. Rancher 2.0 — это просто панель к кубернетесу. А сетевой плагин можно выбрать любой — calico, canal, flannel. Т.е. ранчер — точно такой же кубер как и остальные куберы

  • «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    +1
    1. Простота обманчива.
    2. Развернуть долго? “rke up” и через 10 минут получаешь кластер ) здесь скорее больше времени правильное проектирование внедрения займет
    3. Насчёт эксплуатационной сложности — поддерживаю. Тем более, если там ещё навернуто хранение данных и куча всего другого. На самом деле с кубером сейчас ситуация как пару десятков лет назад с дистрибутивами линукса — полный «Дикий запад». И самое главное, что пользователю не «голый» кубер нужен… а платформенное решение для деплоя ( о чем выше shurup и пишет) — со всякой обвязкой, безопасное и удобное
  • Агрессивный переход в облако Atlassian или это vendor lock-in?
    0

    Охотно делают — нет, конечно. Но для таких штук как коробочный софт, например, операционные системы — существует одновременно несколько lts линеек, каждая из которых имеет вполне понятный жизненный цикл. Скажем, 5 лет. Это действительно поддержка и она стоит дорого. Очень. Но бизнес за это и платит. Потому что не всегда есть возможность переползти безболезненно на новую версию. Как правильно заметил однажды VolCh — получая НОВУЮ версию со своим багфиксом Вы ещё бесплатно получаете кучу новых ненужных фичей (это вроде не очень больно), но и целую пачку новых багов (а это уже больно). И совершенно не факт, что будет возможность выбора или даже отката назад, к старой версии

  • «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    +1

    Это ты сам сказал ) но в целом — да, мне не нравятся универсальные решения именно тем, что у них очень большие амбиции по спасению человечества, а в результате они не решают никаких проблем, а сами становятся проблемой. В частности, в поддержке.
    Вот пример — https://github.com/kubernetes-sigs/kubespray/pull/6814
    Это настолько грустно, что уже не смешно

  • KPI. Или как руководители боятся посмотреть в глаза сотруднику при начислении зарплаты. (Исправлено)
    +2
    Но вместо этого руководство пытается придумать, как бы сделать так, что бы платить Саше меньше, а работал он больше

    нормальное желание капиталиста, тем более в кризис.


    И получает закономерный итог, где Саша симметрично пытается работать меньше и получать больше.

    справедливо.


    Саша, мы видим, что ты крутой продажник, давай ты будешь так же хорошо продавать, как ты это делаешь, а мы тебе будем платить в два (три, четыре, n) раза больше, чем ты получал с премией

    идеальный сценарий. К сожалению, я не видел НИ ОДНОЙ компании, где было бы так сделано

  • KPI. Или как руководители боятся посмотреть в глаза сотруднику при начислении зарплаты. (Исправлено)
    +4

    Ничего, скоро эти новомодные веяния доберутся и до остальных программистов (((((

  • KPI. Или как руководители боятся посмотреть в глаза сотруднику при начислении зарплаты. (Исправлено)
    +1

    Полностью согласен — любую систему kpi метрик можно заэбьюзить. Но. При этом эти системы полезны — нет других способов оценить эффективно ли работает сотрудник. Потому что при отсутствии объективных метрик как базы — начнётся кумовство. Вот Маша мне нравится больше, просто по-человечески — поэтому у неё будет премия. А Саша социопат — и та ну его. А вот с Дашей я сплю — поэтому она идёт на повышение. Бизнесу жизненно необходимо такие кейсы вырезать на корню.
    С другой стороны, бизнес — это про что? Это про зарабатывание денег. Но не в моменте — иначе можно эффективно напродавать на отчетный период, получить свою премию, а потом хоть труба, хоть компания пускай закрывается. А — в долгосроке. А это измерить уже гораздо сложнее. Эффективные же менеджеры хотят свою премию и свой «золотой парашют» сейчас!!! Так и живем.


    Если кратко подытожить. Есть компании, которые живут не по непонятным виртуальным метрикам, а по реальной работе. Их мало. Но они есть. Остальные — занимаются ИБД. С игрой «обмани kpi».
    Второй итог — первоочередная метрика «сколько денег ты принёс компании» или на худой конец — «сэкономил». Все остальное вторично

  • «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    0

    У Вас более чем странные аргументы.
    А рединес пробы — это вообще из другой оперы. Жаль, что Вы не распарсили, что я имел в виду.

  • «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    0
    Модели очень большие, класть их в контейнер нереально

    до 5ГиБ — реально класть в образ. Продакшн опыт. По крайней мере софт работает в этом случае бинарно — либо запустился и работает, либо нет (если образ не выкачался на ноду) — и не зависит от качества сети.
    Единственное, я все-таки так и не проверил — как там mmap() работает и экономит ли память (грузить каждую модель в ОЗУ — очень расточительно на больших вычислительных узлах с сотнями подов)

  • Caesar3 все таки open
    0

    По сути то же самое, только в другом сеттинге

  • «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    +1

    да, все так — софт в контейнерах должен быть


    1. независим от user id (потому что оркестратор всегда может айди перемаппить и мы должны быть готовы к этому)
    2. не гадить себе под ноги. Т.е. рассчитываем на R/O файловую систему. А то тот же пайтон — начинает компилять py в pyc, выкачивать ML модели на эфемерный слой, а потом ловишь веселые спецэффекты.
      и куча еще всяких нюансов, что описаны и не описаны в 12 факторах
  • «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    –1

    Никакой трагедии. Ну, будет кубер вместо ансибла. Зато бизнесу выгода — не кастомные плейбуки, а вроде «стандартный» кубер....

  • «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    +1

    Ну, какая проблема реально есть — это почти 100% аварийное завершение постгреса на любой мало-мальски крупной базе внутри докера при stop контейнера. Оно обычно проходит бесследно, т.к. при следующем запуске происходит recovery, но приятного мало — факт.
    Проблемы же с потерей данных на aufs вроде бы давным давно решены отказом от этого самого aufs в пользу более быстрого и стабильного overlay2 fs.

  • «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    +2

    тем, что бриджованные сети на самом деле не нужны, они снижают быстродействие (минимум на 5%), дают сложноконтролируемые эффекты на файрволл (например, публикация приложения docker run -p 80:80… идет через цепочку NAT и сервис становится доступен НАРУЖУ вне зависимости от настроек цепочки INPUT, что было бы логично)

  • Бизнес, госслужба, вуз, наука: все ли работы хороши?
    0
    Типа когда там выше рекоммендуют семейно настроенным девушкам банковскую сферу речь не идет о трейдерах в инвестбанках

    +++ именно!

  • «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    +1

    Ну, здесь проблема ожиданий и реальности. Ожидания — докер решит все проблемы, все будет круто. Реальность — это инструмент со своими прибабахами и далеко не универсальный. Это не означает, что докер — абсолютное зло ) он вполне применим для определенного класса задач, но дело в том, что об этом ( как его правильно применять ) — никто не рассказывает. Например, amarao недавно рассказывал, что его спасло --network host, чтобы затащить докер в прод. И я с ним полностью согласен. Сколько мне понадобилось времени, чтобы дойти до такого же мнения — 1 месяц экспериментов. А сразу про это никто подсказать не мог :-/

  • «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    –2
    alpine контейнер.

    не надо про эльпайн ок? Если человек умный — он делает из scratch или distroless.
    А с эльпайн — можно напороться на кучу проблем. И это только вершина айсберга:
    https://habr.com/ru/post/415513/
    https://habr.com/ru/company/flant/blog/452754/
    https://habr.com/ru/post/486202/


    А уж откуда что качается, как влияет на что — ответы на все эти вопросы можно легко найти, если изучить матчасть немного, а не просто по случайному туториалу чего-то делать.

    несомненно, все так — нужно изучать матчасть. Проблема только лишь в том, что докер снижает планку настолько сильно, что можно получать результат без матчасти, а потом удивляться, что же все так плохо работает. С другой стороны — в быстром результате есть плюс. Главное, не останавливаться на нем, а продолжать процесс познания

  • «Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить
    +6

    Ну, все правильно — зачем нужен докер? Чтобы заметать этот мусор под ковер. Не держать его на хосте. Раньше же как — в первую очередь с интерпретируемыми языками вроде php, python, ruby — было целое приключение установить несколько версий на хост одновременно. Потом конфликты библиотек и окружений. Докер действительно эту проблему решил — изолировав эту "помойку" внутри контейнера. Но здесь появилась новая проблема. Разработчику решительно перестало быть нужно разбираться в этой "помойке" и как-то ее оптимизировать. Если это было необходимо, чтобы обеспечить стабильность работы системы (см. выше) и это было действительно сложно, практически ювелирной работой, бывали отказы из-за этого, то теперь все стало сильно проще и можно делать "как попало", т.к. это не дает немедленного манифестация каких-либо проблем. Эффект отложенный. А потом спустя недели, месяцы или годы проблема встает в полный рост, но уже поздно что-то менять. В результате мы обмазываемся принципами вроде того, что "контейнеры эфемерны" и "релизы должны релизиться максимально часто". Ну, ок — ТАК ТОЖЕ МОЖНО ЖИТЬ. И оно даже дает приемлемый результат для большинства задач… Но все равно нельзя говорить, что так нужно делать везде — например, в более консервативных средах или в средах требующих повышенной надежности.