company_banner

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


    Недавно в наших соцсетях выступал Александр Чистяков, DevOps с 7-летним опытом и сооснователь Санкт-Петербургского сообщества DevOps-инженеров.

    Саша один из топовых докладчиков в этой сфере, он выступал на главных сценах на Highload++, РИТ++, PiterPy, Стачка, всего сделав не менее 100 докладов. В прошлый понедельник он ответил на вопросы зрителей и рассказал про свой опыт.

    Делимся записью эфира и расшифровкой.



    Меня зовут Александр Чистяков, я много лет работаю DevOps-инженером. Я давно консультирую различные компании на тему внедрения DevOps-практик, использования современного DevOps-инструментария и организации инфраструктур таким образом, чтобы все мы могли спокойно спать по ночам, и люди продолжали получить деньги за свои товары и услуги.

    В основном я консультировал иностранные компании.

    Мы поговорим о том, как люди используют Kubernetes в повседневной практике, зачем это нужно, почему этого не стоит бояться, на что стоит обратить внимание и что будет дальше.
    Думаю, что системным администраторам, DevOps-инженерам, IT-директорам, другим специалистам, которые занимаются управлением инфраструктурами (и сочувствующим) это будет полезно.

    Как развивался этот ландшафт? Я помню компьютеры, на которых был установлен ROM Basic, и можно было писать программы без установленной ОС. С тех пор много воды утекло. Сначала ОС не было как таковых (точнее, они были написаны на ассемблере). Потом появился язык C и ситуация принципиально улучшилась. Конечно, теперь мы все знакомы с понятием ОС: это платформа, которая позволяет запускать пользовательские приложения и управлять ресурсами, которые у нас есть на этом компьютере. Или на других, если она распределенная. Уже тогда можно было собрать высокопроизводительный вычислительный кластер из своего ноутбука и десктопа – так делали студенты в общежитии Санкт-Петербургского политеха году в 97-м.

    Потом оказалось — я, наверно, лет 10 назад читал эту статью — что компания Google, которая придумала web-почту, строит вокруг этой самой web-почты операционную систему для того, чтобы пользователи пользовались ею с планшетов и телефонов. Это было неожиданно, обычно операционная система – это нечто, что запускает бинарники, и, когда вы смотрите через браузер на приложение, вы даже не знаете, есть ли там бинарник. Вы можете читать почту, общаться в мессенджере онлайн, рисовать слайды, вместе редактировать документы. Оказалось, что это многих устраивает.

    Правда, компания Google была не очень последовательна и наделала множество таких продуктов, которые оказались не нужны и не ушли дальше прототипа — например, Google Wave. Ну, такова бывает политика любой большой компании – двигаться быстро, ломаться часто, пока компания не прекратит существование.

    Тем не менее, в массовом сознании произошел сдвиг в сторону представления об ОС как о платформе, которая не предоставляет те сервисы, которые были один раз одобрены каким-то стандартообразующим комитетом и оказались закреплены за ней, а просто удовлетворяет нужды пользователей. Каковы эти нужды?

    Раньше было принято спрашивать разработчика, на чем он пишет. Были специалисты по C++ (наверно, и сейчас есть где-то), сейчас – много специалистов по PHP (они и сами над собой смеются, бывает) и очень много разработчиков на JavaScript. Сейчас набирает популярность Typescript, язык GoLang, в который переключились люди со знанием PHP. Был язык Perl (наверно, и сейчас остался, но сильно потеряв в популярности), язык Ruby. Вообще, приложение может быть написано на чем угодно. Если вы живете в реальном мире, вы, наверно, сталкивались с тем, что они пишутся на чем угодно: на Javascript, на Rust, на C; придумайте название – на этом что-то было написано.

    И все это надо эксплуатировать. Оказалось, что в такой гетерогенной системе, во-первых, нужны специалисты для разработки на разных языках, и, во-вторых, нужна платформа, которая позволяет запустить сервис в приятном ему окружении и следить за его жизненным циклом. Есть некий контракт с этой платформой, который в современном мире выглядит так: у вас есть образ контейнера (система управления контейнерами сейчас везде – Docker, хотя ничего хорошего про него я не могу сказать; о проблемах мы еще поговорим).

    Несмотря на то, что человечество движется по некому эволюционному процессу, этот процесс имеет сходимость. В нашей индустрии так получается, что кто-то все еще пишет код на языке Perl (под mod_perl Apache), а кто-то уже на GoLang пишет микросервисную архитектуру. Оказалось, что очень важен контракт с платформой, очень важно наполнение платформы, и очень важно, чтобы платформа помогала человеку. Делать вручную операции для того, чтобы завернуть и запустить сервис, становится очень дорого. Мне приходилось сталкиваться с проектами, где было 20 сервисов – и это был не слишком большой проект; я слышал и о ребятах, у которых тысяча разных сервисов. 20 – это нормальной количество; и каждый набор сервисов разрабатывает своя команда на своем языке, они связаны только протоколом обмена.

    Касаемо того, как устроен контракт для приложения. Есть «манифест о 12-факторном приложении» — 12 правил того, как приложение должно быть устроено, чтобы его было удобно эксплуатировать. Мне он не нравится. В частности, там написано, что надо доставлять конфигурации через переменные окружения; и я уже не раз сталкивался с тем, что в Amazon, например, количество переменных окружения, которые можно передать в Elastic Beanstalk, составляет одну страницу ядра Linux – 4 килобайта. И они очень быстро переполняются; когда у тебя 80 различных переменных, 81-ю уже сложно воткнуть. Более того, это плоское конфигурационное пространство – когда есть переменные, их надо называть большими буквами с подчеркиванием, и среди них нет иерархии; сложно понять, что происходит. Я еще не придумал, как с этим быть, и мне не с кем это обсудить – нет группы энтузиастов, которые были бы против подобного подхода. Если это вдруг кого-то тоже не устраивает – напишите мне (demeliorator в Telegram), буду знать, что я не одинок. Мне это категорически не нравится. Этим трудно управлять, трудно передавать иерархические данные; получается, что работа современного инженера состоит в том, чтобы знать, где какие переменные, что они значат, правильно ли они заведены, насколько легко их изменять. Мне кажется, что старые добрые конфигурационные правила были лучше.

    Возвращаясь к контракту. Получается, что нужен Docker Image: понадобится непосредственно сам Docker (несмотря на то, что он сам убогий – я надеюсь, что их какая-нибудь Microsoft купит и либо похоронит, либо разовьет нормально). Если вас не устраивает Docker, можно попробовать Stack от Red Hat; про него я не могу ничего сказать, хотя мне и кажется, что это должно быть лучше, чем просто ванильный Kubernetes. Ребята из Red Hat уделяют гораздо больше внимания вопросам безопасности, умеют делать даже multi-turned инсталляции, многопользовательские, многоклиентские, с нормальным разделением прав – в общем, следят за тем, чтобы управление правами было.

    Остановимся на вопросах безопасности. С ней плохо везде, не только на Kubernetes. Если говорить о вопросах безопасности и оркестрирования контейнеров, я большие надежды возлагаю на web assembly, которую делают server side, и для web assembly-приложений можно будет ограничения потребления ресурсов, системных вызовов прикрутить в специальных контейнерах, на Rust. Это будет хороший ответ на вопрос безопасности. А в Kubernetes безопасности нет.

    Допустим, у нас есть приложение. Оно представляет из себя Docker-образ, оно 12-факторное – то есть, оно умеет забирать вашу конфигурацию из переменных окружения, из файла, который вы смонтируете внутри контейнера. Его можно запустить – внутри оно самодостаточно, его можно попытаться связать с другими приложениями через конфигурации, автоматически. И оно должно писать логи в стандартный вывод – что, наверно, является наименьшим злом; когда логи контейнер пишет в файлах, оттуда не очень легко собирать. Даже Nginx запатчили так, чтобы можно было собирать логи со стандартного вывода контейнера, это приемлемо (в отличие от передачи конфигурации через параметр). По сути дела, раньше у нас было несколько оркестраторов: Rancher, Marathon Mesos, Nomad; но, как гласит принцип Анны Карениной применительно к техническим системам, сложные технические системы устроены одинаково.

    С Kubernetes у нас ситуация, как у авиакомпаний с Boeing 737 MAX – он не летает, потому что в нем ошибка, но ничего другого нет, потому что конструкция очень сложная. Я не могу сказать, что он нравится мне – как и язык GoLang, и управление через формат YAML, когда у вас есть некий синтаксис, и поверх него ничего нет – никаких проверок того, что вы пишете, никаких типов данных. Все проверки, которые вы делаете перед тем, как сделать apply конфигурации в Kubernetes – это рудименты. Вы можете попытаться сделать apply неправильной конфигурации, и она применится без вопросов, и получится неизвестно что. Очень легко написать неправильный конфигурационный файл. Это большая проблема, и люди уже начали потихоньку решать её, используя DSL-и Kubernetes на языках Kotlin, даже Typescript. Есть такой проект Pulumi, есть Amazon-овский проект EKS – хотя он больше ориентирован на Amazon; Pulumi – это такой Terraform, только на Typescript. Я жалею, что до сих пор не попробовал Pulumi, потому что считаю, что в нем будущее. Конфигурация должна быть описана на языке программирования со строгой статической типизацией, чтобы перед применением, которое может потенциально уничтожить кластер, вам хотя бы сказали бы на этапе компиляции, что так нельзя.

    Таким образом, на данный момент оркестратор только один. Я знаю, что где-то остались пользователи на MATA, я жму им руку; надеюсь, что Docker Swarm больше никто не использует – мой опыт с ним был достаточно негативным. Я верю, что может быть иначе, но не знаю, зачем; никакого дальнейшего развития Docker Swarm я не предвижу, и не думаю, что люди, выпускающие его, что-то сейчас собираются с ним делать. Капитализм; если вы не зарабатываете деньги, то на разработку тратить нечего – а их компания последние два года находится в «долине смерти» стартапов: денег им никто не хочет давать. Можно делать ставки, кто купит их. Microsoft не заинтересовался. Может быть, какой-нибудь Microfocus это сделает, если Docker доживет.
    Раз остался один Kubernetes, давайте поговорим про него. Есть прекрасная картинка с пентаграммой из пяти его бинарей; написано, что Kubernetes – это очень просто, всего пять бинарников. Но я далек от того, чтобы сложности системы измерять в количестве бинарников, в которые она скомпилирована, и в количестве сервисов, которые составляют ядро системы. Неважно, сколько там бинарников – важно, что Kubernetes умеет выполнять, и как он устроен внутри.

    Что он умеет выполнять? Вот представьте себе, что вам надо объяснить пятилетнему ребенку, что вы делали на работе. И вот папа, который пытался на Ansible написать playbooks и роли, которые позволят ему сделать blue-green deployment на базе Nginx на хосте и набора контейнеров, которые не регистрируются ничем, кроме tv-ansible, говорит: «Знаешь, сынок, я пытался все это время сделать свой собственный Kubernetes. Он плохо работает, он плохо протестирован, я плохо его понимаю, я не знаю всех граничных условий, работает в пределах одной машины, но зато он мой!» Я неоправданно много раз такое видел – 2 или 3 раза только смотрел, и 2 раза участвовал в написании подобного. Рано или поздно человек, который в таком участвует, понимает, что 4-го раза быть не должно. Это как у моих друзей-автолюбителей, которые однажды восстановили ВАЗ-2101 – поставили электростеклоподъемники, флоком салон заделали, покрасили в металлик. Создание своего собственного оркестратора – это примерно так. Можно попробовать один раз, чтобы убедиться, что вы умеете, но рекомендовать это всем – а не только энтузиастам – я не готов. Поэтому управление жизненным циклом, управление состояниями контейнеров – это задача Kubernetes.

    Он может убедиться в том, что контейнер запущен на том узле, где есть ресурсы, может перезапустить умерший контейнер, может убедиться в том, что, если контейнер не запускается, то на него трафик не пойдет, если будет новый deployment. Кроме того, мы начали со слов о том, что Kubernetes – это ОС; где ОС, там должен быть пакетный менеджер. Когда Kubernetes начинался, описания объектов в нем были императивны; stateful сет и описание кода – это такие описания, которые работают напрямую, и сверху надо добавить что-то, чтобы было более понятно состояние вашего [??? 18:52 – глюк записи]. Собственно, радикальное отличие от Ansible и других подобных конфигурационных систем управления заключается в том, что в Kubernetes вы описываете то, что должно получиться, а не то, как это должно получиться. Вы натурально описываете, какие у вас объекты есть и какие у них есть свойства. Объекты – это service, deployment, daemonset, statefulset. Интересно, что, кроме тех объектов, которые можно создавать стандартно, есть и кастомные объекты, которые в Kubernetes можно описывать и создавать. Это очень полезно; это еще и сильно проредит ряды сисадминов и devops-инженеров.

    Когда умрет Kubernetes?


    Хороший вопрос. Зависит от того, что понимать под словом «умрет». Вот Docker – мы год назад собирались на конференции в Петербурге, был круглый стол, и мы совместно решили (ну, поскольку мы и есть индустрия, я думаю, там было квалифицированное большинство, и мы вполне могли себе позволить говорить за всех), что Docker уже умер. Почему? Потому что на конференции не было докладов про Docker, хотя ему не так много лет. Про него никто ничего не рассказывал. Рассказывали про Kubernetes, про следующие шаги – Kube Flow, например, про использование операторов, про то, как размещать базы Kubernetes. Про что угодно, но не про Docker. Это смерть – когда вы насколько плохи, что вы как бы живы, но к вам никто не приходит.

    Docker уже умер. Когда умрет Kubernetes – давайте подождем лет 5. Он не умрет, он будет у каждого – он будет внутри Tesla, внутри вашего телефона, везде, и никому не будет интересно о нем говорить. Я думаю, что это и есть смерть. Может быть, даже не через 5 лет, а через 3. Другой вопрос – что придет ему на смену: какая-то громкая новая технология, про которую все будут говорить, возможно, не из DevOps-мира вообще. Сейчас про Kubernetes говорят даже просто для того, чтобы поддержать разговор, и это нормально – это модно.

    Что не так с Docker?


    Все. Это единый бинарь для управления всем, это сервис, который должен быть запущен в системе, это штука, которая управляется через сокет в том числе. Это такой продукт, в котором много кода, который не сильно кто ревьюил, как я думаю. Это продукт, за которым нет, по большому счету, энтерпрайзных денег. В компании Red Hat работают очень умные люди, я их очень уважаю, и, если вы – обычный инженер, то вам следует смотреть на то, что они делают, потому что это может определить ландшафт на следующие 5 лет. Так вот, Red Hat выкинули Docker вообще. Они движутся к тому, чтобы его не было. Пока они не могут сделать этого до конца, но они близки, и рано ли поздно они дожмут Docker. У него, кроме всего, что я перечислил, громадная площадь атаки. Безопасность там никакая. Было поднято не так много CVE по нему, но, если посмотреть на них – понятно, что, как и в любом другом проекте, где безопасность не во главе угла, ею занимаются по остаточному принципу. Это закон. Безопасность – это долго, дорого, муторно, ограничивает разработчика, сильно усложняет жизнь. Правильно сделать безопасность – это тяжелый труд, за который надо заплатить. Если поговорить с любым специалистом по безопасности, неважно, какой квалификации – вы наслушаетесь страшилок про Docker и историй про то, как все плохо. Они частично связаны с самим Docker, частично – с людьми, которые его эксплуатируют, но сам Docker мог бы и помогать людям и некоторые security checks внутри себя проводить; например, не стартовать процесс в контейнере от рута, если не сказано сделать это явно.

    Как хранить состояния? Допустимо ли базу данных разместить в Kubernetes?


    Если вы спросите DBA, или человека, который за инфраструктуру этой БД отвечал до того, как вы решили ее поместить в Kubernetes, этот человек скажет «нет». Я думаю, на многих круглых столах люди скажут, что никаких БД в Kubernetes не должно быть: это сложно, ненадежно, непонятно, как этим управлять.

    Я считаю, что БД в Kubernetes могут быть представлены. Насколько это надежно? Ну, смотрите: мы имеем дело с распределенной системой. Когда вы будете ставить БД в кластер, вы должны понимать, что у вас есть требование по отказоустойчивости. Если у вас есть такое требование, скорее всего, то, что вы поставите к себе в Kubernetes внутрь – это кластер БД. Много ли людей в современном мире умеют делать нормально кластер базы данных? Много ли БД предоставляют возможность кластеризации? Здесь начинается разделение БД на традиционные – реляционные, и на нереляционные. Их отличие не в том, что вторые не поддерживают SQL в том или ином виде. Отличие в том, что нереляционные БД гораздо лучше подходят для работы в кластерах, потому что их изначально писали для того, чтобы БД была распределенной. Поэтому, если для какой-нибудь MongoDB или Cassandra хотите сделать размещение в Kubernetes, я не могу вас отговаривать, но вы должны очень хорошо представлять, что будет дальше. Вы должны очень хорошо понимать, где лежат ваши данные, что будет в случае отказа и восстановления, как идут бэкапы, где находится точка восстановления и за какое время вы восстановитесь. Эти вопросы не имеют отношения к Kubernetes; они имеют отношение к тому, как вы в принципе эксплуатируете кластерное решение на базе обычных баз данных. С NoSQL-решениями проще, они сразу “cloud-ready”.
    Но все-таки возникает вопрос – а зачем БД помещать в Kubernetes? Вы можете взять предоставляемую вашим провайдером услугу, managed-решение; вы можете в Amazon взять RDS, в Google – тоже managed-базу. И даже географически распределенный кластер этой базы, в случае с Amazon это Aurora, можете установить и использовать. Но, если вы будете ставить географически распределенный кластер базы, прочитайте внимательно документацию; мне доводилось встречать кластера Aurora, состоявшие из одного узла – они даже не были распределены на два региона. Более того, второй регион вообще не был нужен. У людей вообще очень странные вещи в головах: они считают, что главное – выбрать продукт, а дальше он сам себя обеспечит и заработает, как надо. Нет. Реляционные БД вообще не были готовы к тому, чтобы работать даже в обычном кластере, не говоря уже про геораспределенные. Поэтому, если вы делаете что-то сложное на их базе, ознакомьтесь с документацией.

    В принципе, у меня есть опыт эксплуатации БД внутри Kubernetes. Ничего страшного не было. Произошло несколько сбоев, связанных с падением узла; переезд штатно отработал на другой узел. Все под контролем. Единственное, что я не могу вас обрадовать и сказать, что там держалось огромное количество тысяч запросов в секунду.

    Если у вас среднее или небольшое решение – среднее решение для России примерно соответствует большому новостному агентству типа Ленты – то большого количества сложных запросов к базе не должно быть. Если база не справляется, то, наверно, вы что-то делаете не так, и вам нужно об этом подумать. Не пытайтесь бездумно масштабироваться. Перевод некластерного решения в кластер несет свои плюсы, но также и большое количество минусов – особенно, если вы возьмете postgres-кластера на базе Patroni или Stallone. Там много граничных условий; я с ними не сталкивался, но коллеги из Data Egret вам с удовольствием расскажут про то, как бывает. Есть доклад Алексея Лесовского прекрасный о том, что будет, если вы попытаетесь вашу базу перевести в кластер, не думая.

    Насчет тысяч запросов в секунду. Если у вас есть один инстанс БД, то тюнинговать его по тысячам запросов в секунду – это все еще масштабирование вверх. Вы рано или поздно упретесь. Мне кажется, что лучше, если планируется большая нагрузка, рассмотреть горизонтальные варианты масштабирования. Найдите самую большую таблицу в вашей БД, посмотрите, что там лежит, и подумайте, нельзя ли это вынести в нереляционное хранилище. Думайте, как не хранить в реляционной БД то, что вы в ней обычно храните – например, логи доступа в систему, которых падает достаточно много, а доступаетесь к ним вы обычно по тому же шаблону, по которому доступаетесь в хранилище «ключ-значение». Поэтому, почему бы не писать логи в Cassandra? Это вопрос к архитектору. Держать небольшой и не очень нагруженный инстанс базы в Kubernetes – это самое то, потому что за него начинает отвечать магия оператора.

    В принципе, если посмотреть на то, что из себя представляет Kubernetes как ОС и платформа, то это – конструктор «сделай сам». Там есть все, чтобы вы построили микросервисную архитектуру, в том числе с возможностью хранения стейтов на дисках, организации телеметрии, мониторинга, алертинга. Это делается средством Helm – это пакетный менеджер Kubernetes. В интернете огромное количество опенсорсных, публично доступных Helm Charts. Самый просто способ поднять инфраструктуру проекта – это взять Helm Chart, который ставит ваше приложение, ваш сервис, если этот сервис – это база данных Redis, PostgreSQL, Patroni – что угодно; начать его конфигурировать, и применить эту конфигурацию. Она полностью декларативна; все, что можно предусмотреть, авторы Helm Charts обычно предусматривают. Ваше приложение тоже лучше всего релизить при помощи Helm. Третий Helm не содержит сервисов на стороне кластеров; второй – содержал, у него был постоянно работающий от администратора кластера сервис, необходимый, чтобы раскладывать по namespace релизы, но третий Helm эту дыру в безопасности закрыл.
    Helm – это такой шаблонизатор на базе синтаксиса шаблонов GoLang. Он берет список переменных, которые представляют собой неплоскую структуру (она, слава богу, иерархическая – записывается в YAML); эти переменные с помощью Helm расставляются по нужным местам в Helm Templates, дальше применяете это все в какой-то namespace, там запускаются ваши коды, сервисы, ваши роли создаются. Есть генератор скаффолдинга, который позволяет Helm Chart написать, не приходя в сознание. Единственное, что мне не нравится – это необходимость знать синтаксис шаблонизатора GoLang и условных ветвлений в самом Helm; они сделаны по lispовому принципу, с префиксной нотацией. Хорошо, что это еще нравится кому-то, но это заставляет каждый раз голову переключать. Ну, переживем это.

    Теперь немного о том, что будет дальше. Я уже напоминал операторы; это такие сервисы, которые живут внутри кластера Kubernetes и управляют жизненным циклом другого, большего приложения. Достаточно сложно. Можно считать, что оператор – это такой ваш кремниевый домашний site reliability engineer; наверняка в дальнейшем люди будут писать все больше операторов, потому что никому не хочется держать смену людей 1-го уровня поддержки, которые бы следили за графиком Nagios, замечали бы outages и предпринимали действия вручную. Оператор понимает, какие состояния системы возможны; это конечный автомат. Теперь концентрирование знаний человечества, написанное на языке GoLang или подобном, компилируется, ставится в кластер и делает большое количество работы за вас: добавляет или удаляет узлы, реконфигурирует, следит за тем, чтобы упавшее поднималось, чтобы данные пристыковывались к нужным кодам с того места, где они находятся. В общем, управляет жизненным циклом того, что под ним установлено. Операторы сейчас есть буквально для всего. Я вот развлекался тем, что при помощи оператора Rook ставил sev прямо в кластер Kubernetes. Я посмотрел на то, как это происходит, и я очень доволен, и думаю, что операторов нужно больше, и все мы должны участвовать в их тестировании. Время, которые вы затрачиваете на исправление чужого оператора – это подарок человечеству. Вам больше не нужно будет делать одну и ту же работу много раз. Вы сможете эту работу в отчуждаемом виде положить в репозиторий, и дальше умная программа будет делать ее за вас – это ли не счастье.

    Я скачал книгу Red Hat – они ее раздают бесплатно – про то, как устроены Kubernetes-операторы и как написать свой, рекомендую вам пойти на их сайт и тоже скачать, книга очень интересная. Когда я ее прочитаю полностью, может быть, разберем вместе какой-нибудь оператор.

    Кто поддерживает Swarm? Кроме Docker Inc?


    Никто. А Docker Inc. уже раздербанили на две половины, и одну половину куда-то продали. Я не слежу за тем, что у них происходит; одно время они называли продукт Mobi, но это была open source-версия, то есть, была не открытая версия. И что-то продали с правами, а что-то не продали. Для меня это выглядит как «больной перед смертью потел» — люди пытаются хоть как-то извлечь вложенные деньги. В общем, никто не поддерживает.

    Master/Slave


    Это работает. Если в реляционной БД перестанет работать master/slave, то на этом мир закончится. Kubernetes никак не мешает работе БД; единственное, что он привносит – это разные health checks, которые можно при желании отключить, и, в принципе, управление состоянием. Желательно не отключать – ваш оператор, который управляет БД, должен видеть ее состояние.

    Как называется книга Red Hat?


    Kubernetes Operators, так и называется. Там уточка нарисована. Книга O’Reilly, сейчас сделали редизайн обложек; довольно много книг в сотрудничестве с Red Hat выпустили. У Red Hat есть еще 3 или 4 книги по Kubernetes, которые можно скачать бесплатно: например, Kubernetes Patterns, gRPC. Протокол gRPC, хотя и не имеет прямого отношения к Kubernetes, применяется многими для обмена данных между микросервисами. Кроме того, он в балансировщиках следующего поколения применяется, например, в Envoy.

    Что такое SRA?


    Это такой человек, который понимает временные рамки изменений, происходящих в распределенной системе. Грубо говоря, он понимает, сколько уже вы в этом месяце полежали, сколько еще можно, можно ли давать разрешение на релиз. Заведует ключами от бэкапов, рекавери-планами, вопросами восстановление после сбоя, вопросами обслуживания инфраструктуры промышленного приложения, которое должно работать 24/7. У него есть метрики по состоянию и бизнес-состоянию приложения в части application metrics – сколько latency, где и сколько запросов; те самые 4 золотых сигнала. Дальше SRA на основании этих метрик может предпринимать шаги по приведению системы в боеготовое состояние обратно, у него есть план того, как это сделать. От классического DevOps почему-то это не требуется, он просто помогает разработчику довести приложение до релиза, вообще куда-то выкатить. А SRA еще и противостоит потоку запросов с разных сторон.

    Я обещал поговорить про безопасность. Вы знаете, это достаточно молодая тема в Kubernetes. Я знаю только самые основы: например, то, что не следует запускать приложение в сервисе от рута, потому что, как только это происходит, у него есть доступ ко всему в namespace, права суперпользователя, и можно попытаться проломить ядро хостовой системы, что, наверно, получится (и всякие другие операции выполнять от рута). Не надо давать хакерам подобную подсказку; по возможности, давайте пользователям как можно меньше прав и хорошо обрабатывайте пользовательский инпут. Мне кажется, что, если говорить о безопасности Kubernetes, его надо выносить куда-то в закрытые контура, которые сейчас есть. Или, если действительно хотите заняться вопросами безопасности, следует обратить внимание на проект Cilium. Он умеет использовать сетевые фильтры, разграничение прав сетевого трафика на базе BPF – это работает лучше, чем iptables. Это будущее. Мне кажется, что за пределами Калифорнии его особо никто не использует, но можно уже начинать. Может быть, будет какой-то еще проект, но я в это сомневаюсь. У человечества вообще мало рабочих рук.

    Поэтому про безопасность мне особо нечего сказать. Есть различные варианты mounted tenancy в Kubernetes, но там надо сидеть с карандашиком и разбираться в том, что люди сделали, какую уязвимость закрыли, имело ли это смысл, применимо ли это к вашей модели угроз. Кстати, я рекомендую начинать с поиска описания того, как строится модель угроз, и построения ее для себя. Есть более-менее формальные методики. Нарисуйте, посмотрите на нее, и, может быть, произойдет озарение, и вы поймете, что вам нужно, а что – не нужно в текущей ситуации. Может быть, будет достаточно загнать весь Kubernetes в закрытый контур. Это, кстати, правильное решение; я с таким сталкивался, и это непробиваемо. Если получить доступ к системе можно, только предъявив пропуск на вахте, и внутри никакого интернета нет, а обмен идет через какой-нибудь специальный gateway, находящийся в DMZ, и его сложно сломать, потому что он необычно написан – тогда это хорошо защищенная система. Как это делать техническими средствами – ну, надо мониторить текущий рынок решений. Он сильно меняется, безопасность – горячая тема. Игроков пытается быть много, но кто из них врет, а кто нет – я не берусь говорить. Хотя Red Hat, скорее всего, не врет, но он и не впереди всех. Надо просто сделать research (и мне тоже), потому что пока непонятно.

    Поговорим о том, что еще в кластере Kubernetes должно быть. Раз уж у нас есть возможность ставить туда приложения бесплатно, и мы не боимся хранить там БД. Кстати, если у вас Managed Kubernetes, то нет вопросов о том, где хранить БД: у вас есть отказоустойчивое хранилище, в том или ином виде (часто – в виде блочных устройств) подводимое из облака, в котором размещен Managed Kubernetes. Можно спокойно диски с этого хранилища размещать у себя по кластеру и с помощью snapshots забирать консистентные бэкапы. Только не забывайте, что snapshot – это не бэкап, нужно еще отснапшоченное куда-то скопировать. Это очевидно, но очевидные вещи хорошо повторять, чтобы не забывались.

    Очень важно, когда у вас есть платформа с микросервисной архитектурой, сделать так, чтобы она прослеживалась, чтобы было observability, чтобы вы могли понять, где находятся запросы и где они теряют время, и так далее. Построение такой платформы – это большой труд. Вам понадобится Prometheus. Он понадобится потому, что является проектом Cloud Native Computing Foundation; он специально предназначен для того, чтобы мониторить Kubernetes. Содержит огромное количество экспортеров, сборщиков метрик; некоторые приложения нативно содержат все его dashboard. Если ваше приложение их не содержит, то приделать к долгоживущему приложению dashboard Prometheus – это дело 20 минут. Хотя почему-то никто не приделывает. По моему опыту это происходит из-за того, что люди держат свои продукты в облаках. Там есть Amazon CloudWatch, Google StackDriver, и туда можно точно так же отправлять метрики – хотя это будет стоить денег. То есть, если люди все равно платят за инфраструктуру, то они платят и за средства мониторинга, прилагаемые к ней. Тем не менее, Prometheus бывает очень удобен, если у вас есть несколько разных мест, откуда вы забираете метрики, если облако не в одном месте, если оно гибридное, если у вас есть машины on-premise и нужна централизованная инфраструктура. Тогда Prometheus – ваш выбор.

    Что вам еще понадобится? Понятно, что там, где Prometheus, там и Alert Manager нужен. И еще понадобится какой-то вариант распределенной трассировки ваших запросов. Как это сделать в Kubernetes – ну, взять какой-нибудь продукт типа jaeger, или zipkin, или что там сейчас на топе; также Cassandra, чтобы хранить ваши трейсы, также Grafana, чтобы их визуализировать. Насколько я понимаю, в Grafana эта функция появилась недавно, но это не повод не внедрять. То есть, вы можете вручную собрать среду, в которой приложения будут [глюки 49:14] (иметь?) к этому времени выполнения и счетчики, и еще метрики, пригодные к выстраиванию, визуализации ваших трейсов, распределенных: где приложение сколько времени проводит?

    Рассказывать об этом менее удобно, чем показывать, но показать мне сейчас нечего; у меня в лаборатории сейчас ничего этого нет. Однажды я, наверно, соберусь.

    Мне кажется, я рассказал все, что хотел рассказать. Повторю еще раз основные положения.

    Первое: Kubernetes избавляет вас от необходимости писать механизм отказоустойчивой замены одного контейнера другим самому на Ansible Engine X.

    Второе: Kubernetes никуда не исчезнет. Он может «умереть», но перестать им пользоваться уже невозможно, он захватил большую часть рынка. На вопрос «когда умрет Kubernetes:» я хочу спросить «а когда умрет WordPress?» А ему еще жить и жить Давайте очередность установим: сначала WP, потом Kubernetes.

    Итак, Kubernetes – с нами. Интересен скорее не он сам, а интересны те сервисы, которые накручиваются поверх – это операторы и Custom Resource Definition. Возможность взять и написать свой ресурс, который будет называться «PostgreSQL cluster», описать его одной YAML-портянкой и забросить в кластер.

    Что еще будет? Еще будет возможность управления всем этим, статически типизированные языки программирования – такие, как GoLang и TypeScript. И в Котлин я очень верю – на нем уже написано очень много классных DSL. И еще будет написано.

    Еще появятся платные Helm Chart, платные приложения, которые можно запускать on-premise, какие-то лицензионные, по подписке. Будет интеграция разных сервисов – собственно, она уже есть, например, DataDog уже интегрируется с Kubernetes. И новые ребята, которые будут появляться на рынке мониторинга-алертинга, тоже будут интегрироваться с Kubernetes, по понятным причинам. Любой облачный продукт не пройдет мимо Kubernetes, так или иначе. Это та платформа, в которую каждый будет целиться.

    Но все это не значит, что Kubernetes – хороший, и ничего нельзя придумать лучше. Я сравниваю его с тем, что было раньше – с решениями Amazon: ECS, Elastic Beanstalk. Кто сталкивался с ними – знает, что в моей давней аналогии что одно, что другое было бы не просто 737 MAX, а 737 MAX, сделанным из изоленты и пластилина. Поэтому основные игроки – Amazon, Microsoft Azure, Google – все уже в Kubernetes.Наверно, Яндекс и Mail.ru – тоже, но я за ними не слежу. Это такое общее будущее. Такое плохое, но «достаточно хорошее» общее будущее, на которое пока все согласны. Во что это все мутирует дальше, надо спрашивать у Red Hat – они умнее меня.

    Как себя Java чувствует в Kubernetes?


    Нормально.

    Какую ОС используете на своем ПК?


    На обоих – MacOS.

    Берут ли сейчас активно DevOps-специалистов на удаленку?


    Да, их всегда активно брали на удаленку, и сейчас точно так же активно берут. Ситуация принципиально не изменится, я думаю. Я вообще неудаленную работу не рассматриваю: не у любой хорошей компании есть офис в Санкт-Петербурге. Конечно, удаленка будет, и текущие события показали людям, что она возможна. Количество людей, которым она удобнее, будет только расти. Нам говорят, что «многие попробовали и вернулись в офис» — ну, вернуться в офис стоит денег. Нет денег – нет выбора, а многие компании экономят сейчас.



    Что было ранее


    1. Илона Папава, Senior Software Engineer в Facebook — как попасть на стажировку, получить оффер и все о работе в компании
    2. Борис Янгель, ML-инженер Яндекса — как не пополнить ряды стремных специалистов, если ты Data Scientist
    3. Александр Калошин, СEO LastBackend — как запустить стартап, выйти на рынок Китая и получить 15 млн инвестиций.
    4. Наталья Теплухина, Vue.js core team member, GoogleDevExpret — как пройти собеседование в GitLab, попасть в команду разработчиков Vue и стать Staff-engineer.
    5. Ашот Оганесян, основатель и технический директор компании DeviceLock — кто ворует и зарабатывает на ваших персональных данных.
    6. Сания Галимова, маркетолог RUVDS — как жить и работать с психиатрическим диагнозом. Часть 1. Часть 2.
    7. Илья Кашлаков, руководитель фронтенд-отдела Яндекс.Денег — как стать тимлидом фронтендеров и как жить после этого.
    8. Влада Рау, Senior Digital Analyst в McKinsey Digital Labs — как попасть на стажировку в Google, уйти в консалтинг и переехать в Лондон.
    9. Ричард «Левелорд» Грей, создатель игр Duke Nukem 3D, SiN, Blood — про личную жизнь, любимые игры и о Москве.
    10. Вячеслав Дреер, гейм-дизайнер и продюсер игр с 12-летним стажем — про игры, их жизненный цикл и монетизацию
    11. Андрей, технический директор GameAcademy — как видеоигры помогают прокачивать реальные навыки и найти работу мечты.
    12. Александр Высоцкий, ведущий PHP-разработчик Badoo — как создаются Highload проекты на PHP в Badoo.
    13. Андрей Евсюков, заместитель CTO в Delivery Club — про найм 50 синьоров за 43 дня и о том, как оптимизировать фреймворк найма
    14. Джон Ромеро, создатель игр Doom, Quake и Wolfenstein 3D — байки о том, как создавался DOOM
    15. Паша Жовнер, создатель тамагочи для хакеров Flipper Zero — о своем проекте и другой деятельности
    16. Татьяна Ландо, лингвист-аналитик в Google — как научить Google-ассистента человеческому поведению
    17. Путь от джуна до исполнительного директора в Сбербанке. Интервью с Алексеем Левановым
    18. Как Data Science продает вам рекламу? Интервью с инженером Unity
    19. Как я переехал в Лондон c Revolut
    20. Завтрак с легендарным геймдизайнером Американом МакГи: о новой Алисе, России и депрессии
    21. Как организовать IT-конференцию и не сойти с ума




    RUVDS.com
    VDS/VPS-хостинг. Скидка 10% по коду HABR

    Комментарии 225

      +7
      Более того, это плоское конфигурационное пространство – когда есть переменные, их надо называть большими буквами с подчеркиванием, и среди них нет иерархии; сложно понять, что происходит.

      Не выглядит проблемой.
      Решение #1. Указывать иерархию в названии переменных (KAFKA__SUPER__VARIABLE). Любая иерархия в каком-то смысле виртуальна, все равно под капотом k/v
      Решение #2. Засунуть все в консул. Там уже по-настоящему — и acl, и иерархия. А имя окружения все равно передаём через переменные окружения. Таким образом у нас переменных становится 1, остальное в хранилище конфигурации.


      особенно, если вы возьмете postgres-кластера на базе Patroni или Stallone.

      Stolon?


      Она полностью декларативна; все, что можно предусмотреть, авторы Helm Charts обычно предусматривают.

      Если не заглядывать под капот ) там начинается ад с хуками, темплейтингом, функциями. А основная претензия к Хельм — ни один чарт без доработки не работает ( речь не про «подкинуть нужные values.yaml») Индустрия явно свернула куда-то не туда — генерирую тонны контента, который неприменим на практике. Но оно и понятно. То что работает — продаётся за деньги. Это становится «ноу-хау» консалтеров как из якобы бесплатного и доступного собрать рабочее решение


      Операторы сейчас есть буквально для всего. Я

      Только вот проблема. Как к любоум системному ПО — к операторам предъявляются ОЧЕНЬ ВЫСОКИЕ требования по качеству кода. Вряд ли условный пользователь будет счастлив потере данных в БД, вправляемой оператором, из-за того, что разработчики не рассмотрели все возможные граничные случаи. И я гарантирую, что нормальных операторов для production использование из всей массы — единицы. Даже не десятки.


      Что такое SRA?

      SRE? galimova_ruvds большая просьба — давать выверять текст изначальному докладчику (я так понял — это расшифровка доклада)

        +2
        Решение #1. Указывать иерархию в названии переменных (KAFKA__SUPER__VARIABLE). Любая иерархия в каком-то смысле виртуальна, все равно под капотом k/v

        Это решение основано на соглашении между людьми, и его исполнение сложно проверять.
        Решение #2. Засунуть все в консул. Там уже по-настоящему — и acl, и иерархия. А имя окружения все равно передаём через переменные окружения. Таким образом у нас переменных становится 1, остальное в хранилище конфигурации.

        Да, это отличное решение, но им, почему-то, предпочитают пользоваться только относительно большие команды (или же команды с высокой инженерной культурой).
          +4
          И я гарантирую, что нормальных операторов для production использование из всей массы — единицы.


          Да, но для решения одной инфраструктурной задачи необходим всего один хорошо написанный оператор. Я думаю, по одному оператору на задачу человечество напишет.
            +3

            И возникнет старая как мир проблема — как в тоннах говна найти алмаз. Ответом будет альтернативная платформа в которой сразу все есть.

              0

              Давайте пилить такую платформу поверх кубера (как стандарте де-факто для PaaS)
              ОпенШифт точно идет не в ту сторону, потому что после покупки РедХата IBM'ом он мутирует в кусочек облака IBM Cloud со всеми вытекающими

                0

                Поверх k8s будет не интересно для бизнеса, который это будет спонсировать. Не удивлюсь если это будет MS через пару лет.

            +3
            Что такое SRA?

            О, боги! Я себе мозг ненадолго сломал на этом месте про каких-то новых и загадочных "SRA" .

              0
              Может быть site reliability architect?
            +14

            Отличная статья. Она вкрывает очень много реальных насущных проблем. И не боится пойти против течения.


            К сожалению, индустрия продолжит двигаться по течению. То, что мой комментарий тут второй — лишь печальное подтверждение.


            Тут каждую проблему можно брать и превращать в отдельную статью.
            Возьмем пример.


            И они очень быстро переполняются; когда у тебя 80 различных переменных, 81-ю уже сложно воткнуть.

            Большое количество переменных — это хорошо. А даже если плохо — то неизбежно. Сколько осталось ГНУ утилит у которых меньше 40 параметров? Изначально они должны были быть супер простыми.


            Мое мнение — что проблема в другом. Проблема в подходе Infrastructure as a code. Проблема в понимании этого термина. Если я написал текст в текстовом файле и положил в гит — я молодец, у меня теперь инфраструктура — это код. Проблема в том, что это нифига не код, это текст (или файл). Код, это когда ИДЕ знает что это переменная. ИДЕ знает все места где эта переменная устанавливается, где переопределяется, где используется. ИДЕ знает, что сейчас значение будет взято именно отсюда. И не важно сколько либ, тулов или языков используют эту переменную.


            Когда мы использует переменные окружения (.env) мы строим непрозрачные стены для ИДЕ. Она уже не знает что и как происходит этой переменной.


            Все остальное — следствие. То что у нас одноранговые переменные (без именных пространств) То что нам надо руками мапить и пропихивать значение от значения и до использования. Что вообще нужен отдельный файл со списком переменных. Что он неуправляемо растет и там уже сложно ориентироваться. Что имена уже давно не соотвтсвуют смыслу, но всем лениво (да и немнолго страшно) рефакторить и поэтому добавляются новые имена, тоже не соответствующие смыслу. Я молчу про все проблемы с документацией.


            Потому что это не код, а чертов текст. В коде все эти проблемы уже решены.

              +18

              Сейчас могли бы прибежать ребята и растолковать, что IDE — это для слабых духом, vi(m)/emacs и больше ничего не нужно, дебаг — это удел джуниоров, профессионалы пишут с первого раза и им всё-равно, они разобрались, не сложнее GNU Make, на самом деле же.

                +4

                Ну вот GNU make уже лет 30 как "умер".

                  +5

                  Но его забыли похоронить и поэтому на нём проросли разные automake, autoconf и прочие генераторы генераторов компоновщиков скриптов компоновки генераторов мейкфайла? :-)


                  ЗЫ. Пытался так разобраться, чтоб вкрутить поддержку нового формата в mpd, в итоге забил, захардкодил и оставил чисто форк для себя, кому приспичит — сами поправят...

                    +2

                    Какие альтернативы?
                    Cmake? Qmake? Bazel? Другие системы сборки?


                    К мейкфайлам у меня всего две претензии :


                    1. Дебильные табуляции, которые нужно очень аккуратно расставлять
                    2. Необходимость создания фейковых флаг-файлов, если нужно собирать объекты вне фс. Те же докер образы
                      0

                      Что такое фейковые флаг-файлы?

                        +1

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

                        0
                        Cmake, насколько я знаю, поверх GNU make работает (может работать, во всяком случае).
                        Если проводить параллель, то Cmake — альтернатива autoconf, а GNU make с ним можно заменить на Ninja.
                        Qmake и Bazel не щупал
                        +1

                        Да его уже фиг похоронишь, несмотря на все его "достоинства", да и auto tools поверх него тот ещё зомби.
                        Так и живём теперь на костях былых проектов, с докером, видимо, та же история.

                      +8
                      IDE — это для слабых духом,

                      отличная тема для еще одной отдельной статьи.


                      Я имел в виду не обязательно именно ИДЕ. А код, отвечающий за постоение AST. Такой код используется и в компиляторе и сборщике и статическом анализе. Да наверное, должен использоваться во всем.


                      Люди, которые говорят, что код можно (рационально) писать в блокноте — не разработчики. АСТ должен быть построен и валидирован. Если разработчик вместо валидации на лету (при написании кода) руками запускает консольную тулу (когда и если вспоминает) — то он теряет ценное время себя, команды и копмании, которая оплачивает банкет. Как именно происходит валидация на лету — в ИДЕ, или текстовом редакторе с подключенным language server, или еще чем — уже не важно для этого разговора.

                        +11

                        Я регулярно встречаю разработчиков, которые пишут «в блокноте», что на статически типизированных языках, что на динамике.
                        И они реально крутят носом от этих ваших «language servers» и прочей валидации перед пушем. Это такой определённый склад ума и вид людей, их не переубедить ничем, они с детства в далёких 80-х/начале 90-х так привыкли и меняться не будут.
                        Специалисты, кстати, зачастую, очень хорошего уровня, но со своими тараканами. Адекватный менеджмент даёт подобным людям соответствующие роли и все довольны.

                          +4

                          Были люди, которые умели программировать на перфокартах. Потом появилась возможность писать код прямо с клавиатуры. Возможность править появилась позднее. Но не суть. Суть в том, что тогда тоже говорили "да есть отличные спецы, но они работают с перфокартами".


                          Проблема в том, что они не отличные спецы. Если бы таких было большинство, мы бы никогда не перешли от машинного кода к асемблеру. А от него к си и так далее. Может быть конкретные люди хорошо решают конкретую проблему. Может быть, они приносят хорошие деньги. Но они уже не программисты.


                          Точно так же, как ученые, которые разучились воспринимать критику в свой адресс — не ученые. Или которые заросли догматизмом — перестали быть учеными. Например, как лорд Кельвин.

                            +10
                            Проблема в том, что они не отличные спецы.

                            Это очень сильное и безосновательное утверждение. Множество специалистов высшего уровня пользуются очень простыми инструментами разработки. Примеры:


                            • Линус Торвальдс пишет код в https://github.com/torvalds/uemacs, очень простой текстовый редактор.
                            • Walter Bright, создатель языка D, пишет код в https://github.com/DigitalMars/med.
                            • Simon Peyton Jones, мой личный герой, пишет код в обычном Emacs. Аналогично поступают Andrei Alexandrescu, Richard Stallman, Donald Knuth, etc.

                            Я лично знаю очень талантливых и продуктивных разработчиков, которые пишут код в обычном Vim без LSP (для многих языков никакого LS и нету вовсе).


                            Я не против IDE. Я против предубеждений и громких, необоснованных высказываний.


                            Вы считаете IDE абсолютно незаменимым инструментом для вашей продуктивности? Отлично, пользуйтесь на здоровье. Никто не будет сомневаться в вашей профпригодности на основании этого факта.


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


                            заросли догматизмом

                            Мне кажется, в своём глазу бревно сложнее увидеть.


                            M-x projectile-compile-project

                              +4

                              Если человек отличный спец с горой знаний и навыков (а главное – цепким вниманием и железной памятью) и способен держать в голове flow целого проекта, где какие определения лежат и куда переменные изменяются, и где какие баги могут возникать, — он сможет писать даже в блокноте, даже на динамике. Может, IDE его скорее отвлекать будет. Но к сожалению, не всем повезло такими сверхлюдьми быть v_v

                                0
                                ещё во времена, когда и слова IDE не было, а писали почти все на С и Паскале, я приметил, что программер способен удержать в голове код размером в 350к. Хороший программер. В среднем у человека можно сходу получать ответы по его коду, пока код не превысил 200к по объёму исходника. Дальше уже «сейчас посмотрю, уточню».

                                Сейчас, конечно, эти цифры напрямую прикладывать нельзя — но вряд ли головы сильно изменились.
                                +3
                                Мне кажется, в своём глазу бревно сложнее увидеть

                                Я плохой разработчик. Я могу часамми расказывать почему докер плох. Но это не имеет значение, потому что это де-факто стандарт. Тот факт, что я начал по настоящему разбраться с докером только в этом году — делает меня плохим разработчиком. Вне зависимостиот моих достижений в других областях.


                                Вы считаете IDE абсолютно незаменимым инструментом для вашей продуктивности?

                                Не перекручивайте пожалуйста мои слова. Я сказал именно то, что сказал. Валидация АСТ дерева должна происходить на лету.


                                Мне есть что сказать о людях выше. Но хабр этого не хочет. Хабру интересны легкие разговоы, которые не задевают чуства читателей. Я получил по одному минусу в комментарии (и несколько плюсов) и минус в карму (без плюсов, если я правильно помню, сколько было голосов до этого).


                                Моэтому перейдем на более простые темы. Знаете ли Вы, что говорил Кельвин на старости лет? Кельвин был выдающимся ученым, без скидок. Считаете ли Вы что Кельвин оставался ученым на старости лет?

                                  +4
                                  Тот факт, что я начал по настоящему разбраться с докером только в этом году — делает меня плохим разработчиком.

                                  Очень странная логика. Мне лично докер никогда не нужен был, я вряд ли будет нужен в ближайшее время. Почему знание докера вдруг становится критерием хорошего разработчика? Мне нравится работать с людьми, которые быстро разбираются в чём угодно и создают красивые понятные дизайны, а не знают все детали всех технологий.


                                  Я сказал именно то, что сказал. Валидация АСТ дерева должна происходить на лету.

                                  Почему именно должна? Я считаю, что у разных людей разные подходы к написанию кода, и это нормально.


                                  Меня вот, например, люто раздражает задержка (latency). Я зачастую согласен отказаться от автокомплита, если это поможет сделать редактор более отзывчивым.


                                  Мне вот, например, не нравится интерактивная подсветка ошибок. Я люблю написать несколько страниц интерфейсов и кода, написать АПИ-комментарии и инварианты, набросать реализацию, и только когда в голове всё сложилось, я запускаю компилятор и перехожу в другой режим работы: от креатива в механическое исправление мелких ошибок.


                                  Если вам больше подходит какой-то способ работы, это не значит, что он всем лучше подходит.


                                  Понимание уже написанного кода — это тоже другой режим работа мозга. Для этого важна быстрая навигация, и ctags/LANGUAGE-tags/codesearch вполне неплохо с этим справляются.


                                  На некоторых языках очень сложно писать без IDE, в основном из-за того, что там доминируют порочные практики. К примеру, в Java принято разбивать проект на малюсенькие файлы, один класс — один файл. Это делает понимание структуры и навигацию настолько непосильным делом, что без специальных инструментов становится не обойтись. Ответ на вопрос "где происходит X" может занять пару часов, даже с IntelliJ IDEA.


                                  Поэтому мне гораздо легче понимать проекты на C, чем на Java. Зачастую ответить на вопрос "где происходит X" в коде PostgreSQL или Redis или Emacs, который ты видишь первый раз, гораздо проще без всяких IDE, чем в Java-махине, над которой ты работаешь уже как 2 года.


                                  Знаете ли Вы, что говорил Кельвин на старости лет?

                                  Кельвин до конца жизни считал, что Солнце – это большой кусок угля, который скоро сгорит, и очень гордился своими расчётами возраста земли.
                                  Он не хотел серьёзно рассматривать данные, противоречащие его мировоззрению. Никого не напоминает?

                                    +1
                                    Он не хотел серьёзно рассматривать данные, противоречащие его мировоззрению. Никого не напоминает?

                                    что конкретно я не рассмотрел?


                                    Мне лично докер никогда не нужен был… Почему знание докера вдруг становится критерием хорошего разработчика?

                                    может быть для Вас — и не критерий. Для меня критерий. Моя работа связана с вебом, и следовательно облаками.


                                    Почему именно должна?

                                    Потому что это тот этап индрустрии, который давно стал необходимостью. Ради скорости разработки. Это нормально. В любой индустрии производительность труда постепенно растет за счет введения новых инструментов и практик.


                                    Я считаю, что у разных людей разные подходы к написанию кода, и это нормально.

                                    Где я говорю что использовать перфокарты для программирования — не нормально? Я говорю что это не эффективно.


                                    Меня вот, например, люто раздражает задержка (latency). Я зачастую согласен отказаться от автокомплита, если это поможет сделать редактор более отзывчивым.

                                    Я тоже. Больше, чем многих людей. К сожалению эта проблема, которую должны были решить и забыть еще лет двадцать назад, волнует мало людей. Потому что я знаю только один проект, который с ней борется — https://github.com/xi-editor/xi-editor.


                                    Я люблю написать...

                                    и в чем проблема? Вы понимаете что отключить функцию всегда проще, чем агитировать за ее создание?


                                    Если вам больше подходит какой-то способ работы, это не значит, что он всем лучше подходит.

                                    СОЛИД может не всем подходить. Но конечное качество кода должно быть не ниже, чем если он есть.


                                    К примеру, в Java принято разбивать проект на малюсенькие файлы, один класс — один файл. Это делает понимание структуры и навигацию настолько непосильным делом

                                    Как любят говорить сишники (я не конкретно про Вас, но кореляция со старой школой прослеживается) сейчас компьютеры на порядки быстрее, чем были в ракетах. Вам не противно, что мы больше полувека можем попасть в космос, но еще спорим какие файлы и где должны использоваться в проектах? Почему вообще об этом думать? Почему я не могу начать писать новый класс прямо там, где нахожусь — а комплятор сам найдет в какой файл это перенести? Все технологии уже есть, производительное железо тоже.

                                  +2
                                  Мне есть что сказать о людях выше. Но хабр этого не хочет. Хабру интересны легкие разговоы, которые не задевают чуства читателей. Я получил по одному минусу в комментарии (и несколько плюсов) и минус в карму (без плюсов, если я правильно помню, сколько было голосов до этого).
                                  Я поставил вам минус в карму. За то что вы сказали, что не считаете разработчиками людей, которые не используют IDE. И за то что затем сравнили их с «программистами на перфокартах», которые замедляют прогресс.

                                  Я считаю такие сравнения не уместными, и что вам нужно научиться различать «я не понимаю как программировать без IDE» и «все люди, которые не используют IDE – идиоты».
                                    0

                                    1 я специально обьяснял что говорил не конкретно иде, а про конкретную фичу.
                                    2 я остаюсь верен своему сравнению в следующей формулирове. Если человек не развивает свои инструменты — он похож на тех, кто хочет работать с перфокартами.
                                    3 я умею программировать без иде. Я имел достаточно случаев починки серверов по ссш в карьере.
                                    4 я не оскорблял людей, которые не хотят развивать свои инструменты. Я сказал, что они могут быть крайне уместны на своем месте. Но они уже не полноценные професионаллы. Это может быть неприятно, но это не оскорбление. И тем более не приуменьшение интеллекта.


                                    Итого Вы увидели то, что хотели. А не то, что я написал.

                                      0
                                      они уже не полноценные професионалы

                                      Адекватные люди профессионализм измеряют выхлопом, а не инструментами. Не думал, что мне захочется использовать заезженную до дыр максиму «вам шашечки, или ехать?» — но уместнее аллюзии тут не найти.


                                      Представьте себе, что вы вызвали сантехника, прочинить унитаз. Вы предпочтете чувака в грязном ватнике со шведкой в руках, который через несколько минут отряхнет руки и скажет: «готово», или выряженного в новехонький комбинезон обладателя кубометрового ящика различных модных инструментов, который спустя пару часов пожмет плечами и изречет «проверил буквально все, в чем проблема — неясно»?


                                      Я это к чему. Вот есть вы, шагающий в ногу с прогрессом, с развитыми инструментами. Покажите ваши профили на github, stack overflow, коммиты в компилятор языка, который используете, и так далее. Потому что я вот, к примеру, показать все это не стесняюсь, и инструмент в виде любого редактора, который умеет набирать текст — мне в этом деле не помеха.


                                      Давайте сравним профессионализм, раз уж вы начали этот разговор.

                                        +1

                                        Вы меня обвиняете в том, что я определение "профессионализма" свожу к одной характеристике. А потом делаете то, в чем обвиняете, только меняя характеристику на "коммитит в компилятор".


                                        Люди, которые коммитят в компиляторы у меня вызывают искренее восхищение. Как и те люди, которые смогли запустит человека в космос, используя перфокарты.


                                        Если же пререйти к примеру с сантехником. В нашей жизни, профессионалазм определяется постфактум, после работы. Если кран проработал только полгода — это кто накосячил? Поэтому людей приходится оценивать по внешнему виду. Грустная правда нашего времени. Что печально — то аналогично происходит уже в нашей индустрии. На собеседованиях задают много вопросов много вопросов слабосвязанных с работой. Или вообще не связаных. Чтобы интервьювер "сложил картину".

                                          0

                                          Может вам просто кажется, что слабовязаных? Или ваше представление об эффективной работе отличается от такового работодателя?

                                            0

                                            Это дискуссия из разряда, что считать "сильной", а что "слабой" связью. И честно говоря, я не готов начинать еще одну.


                                            Я скажу иначе. Каждый интервьювер имеет личное мнение, что важно проверить на собеседовании. И делает свои отличные выводы из того что услышал. Эти факторы по определению превращают процесс в субьективный, а не обьективный.


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


                                            Или другой пример. Когда на собеседовании спрашивают про ACID и изоляцию. А в компании нет ни одной нагруженной БД, чтобы эти инструменты вообще пришлось применять. С одной стороны это "сильно связано" — интервьювер знает, что человек умеет в это напрвление тоже. С другой стороны "слабо", потому что эти знания исользованы не будут.


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

                                              +2
                                              Когда на собеседовании спрашивают про ACID и изоляцию. А в компании нет ни одной нагруженной БД, чтобы эти инструменты вообще пришлось применять.


                                              Почему нагруженной?
                                              Это к любой БД имеет отношение.
                                              А уж любая БД точно есть.
                                                +1
                                                А уж любая БД точно есть.

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


                                                Я вот библиотеки, к примеру, пишу. Микросервисы там всякие. Как и зачем мне общаться с базой — загадка. Причем, замечу, я выбросил persistent storage из двух микросервисов и заменил его на горизонтально масштабируемый пул supervised гринтредов как раз, чтобы не жертвовать ничем из CAD, и I туда само бесплатно при таком подходе влилось, ибо процессы в OTP полностью изолированы по определению.


                                                Я, в принципе, согласен, что про теорему CAD знать хорошо, но вот «база есть везде» — это сродни «веб есть везде». Оно, может, и есть — но с ним можно десятилетиями не сталкиваться, если неохота.

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

                                            Неправда. Я ни в чем вас не обвиняю. Вы все сделали сами:


                                            [...] людей, которые не хотят развивать свои инструменты. [...] они уже не полноценные профессионалы

                                            Я даже прямую цитату привел, чтобы избежать кривотолков.


                                            На собеседованиях задают много вопросов [...]

                                            Я уже забыл, что такое «собеседование», поэтому ничего сказать не могу. Скорее всего потому, что время, необходимое на освоение новых модных «инструментов» тратил на то, чтобы писать код, который потом используют другие люди, как следствие — предлагающие работу безо всяких там собеседований.

                                              0

                                              Вы привели следующию цитату


                                              они уже не полноценные професионалы

                                              И первое предложение


                                              Адекватные люди профессионализм измеряют выхлопом, а не инструментами.

                                              И далее по комментарию видно, что вы спорите с утверждением "новомодные инструменты === профессионал".


                                              1) Меня очень сильно раздражает что проверку AST дерева называют навомодной. Этому подходу более двух десятков лет.


                                              Это как нызвать електрошуруповерт "новомодным".


                                              2) Я говорю про необходимое, но не достаточное условие. "инстурменты не улучшаются -> уже не такой уж и профессионал", "инструменты улучшаются -> хорошо, но мало чтобы быть профессионалом".

                                                0
                                                далее по комментарию видно, что вы спорите с утверждением «новомодные инструменты ≡ профессионал».

                                                Протрите очки, пожалуйста. Я спорю с утверждением «¬ новомодные инструменты ⇒ ¬ профессионал», которое вы высказали и которое ни разу не изоморфно вашему. Инверсия логического отрицания работает немного иначе.


                                                Я говорю про необходимое, но не достаточное условие.

                                                Так вот, я нигде вообще ни разу не упомянул достаточность. См. выше про инверсию отрицаний. Хорошие инструменты — прихоть, которая может помогать, может не оказывать влияние, может вообще мешать. Люди разные. Вам нужны инструменты — рад за вас; мне — нет. Я думаю в миллион раз медленнее, чем пишу код, даже если за названиями каждой функции надо ходить в документацию.


                                                Наверное, если клепать круды и перекладывать туда-сюда джейсончик — хороший автокомплит экономит время, потому что там думать-то вообще не нужно.


                                                Но в актуальных задачах разработки (нагрузка, десятки тысяч гринтредов, распределенный горячий кэш, preemptive failover, настоящий zero downtime, и т. д.) — инструменты не помогут примерно никак. Даже отладчик, я не говорю про интеллисенс.


                                                проверку AST дерева называют навомодной. Этому подходу более двух десятков лет.

                                                Во-первых, более двух десятков — это 62, забавно вы округляете. Во-вторых, проверка AST в момент написания кода мне лично вообще никуда не вперлась, я умею компилятор запустить, когда надо. На лету она только путает, мерцает, отвлекает и мешает думать. В-третьих, «AST дерева» — это немного тавтология, «T» там и так уже дерево. В-четвертых, в мире существуют только четыре языка с полноценной поддержкой AST, и ни один из них не используется широко (у раста есть шансы, впрочем). В-пятых, наконец, в нашем ремесле — результат все-таки важен несоизмеримо больше процесса, о чем я и сообщил в предыдущем комментарии. Если код работает, не имеет никакого значения, написан он угольком на бересте, или в SuperASTBuildingAndSyntaxHighloadingTool.

                                                  0

                                                  Вы сейчас описали процесс создания артефактов. В мифологическом смысле. Дорованные богами. Которые смертные никогда не поймут и рано или поздно сломают или потеряют.


                                                  Как много людей смогут Вас заменить? Как долго они будут разбираться? Как долго будет чинится система с "настоящим zero downtime" когда в ней обнаружат непонятный баг?


                                                  Шуруповерт можно производить используя уникальные пятигранные винты. Однако это негативно сказывается на поддержании этого продукта в рабочем состоянии.

                                                    0

                                                    С чем разбираться, с блокнотом? ) с IDE посложнее будет

                                                      0

                                                      С кодом.


                                                      Смысл инструментов в том, что с ними уже умеют работать. Если же это велосипеды — то их эффективность резко падает.

                                                        0

                                                        С кодом по любому придётся разбираться, хоть с суперкрутыми IDE, хоть с голой консолью. Обычно программисты имеют право выбирать в блокноте, редакторе или IDE они будут работать с кодом. В репозитории-то код идёт.

                                                          0

                                                          Конечно. Вопрос в том, как долго. Если надо потратить столько же времени, как написать фичу с нул — то в чем смысл?

                                                            0
                                                            Кто по вашему создает те инструменты, которые позволяют вам не городить велосипеды?

                                                            Как думаете, какую часть своего рабочего времени они тратят на валидацию AST?

                                                            Спрашиваю у вас как человек, который например чинил код для построения AST в одном небезызвестном языке и написал один фреймворк который даже кто-то использует.
                                                              0
                                                              Кто [...] создает те инструменты

                                                              Обжигатели горшков?


                                                              какую часть своего рабочего времени они тратят на валидацию AST

                                                              Зависит :)


                                                              Иногда ради производительности и при использовании высокоуровневого языка приходится много времени тратить на валидацию написание AST ручками.


                                                              [...] чинил код для построения AST

                                                              Контрибьюторы компиляторов 2 : 0 адепты IDE.

                                                                0

                                                                Вы утверждаете, что все, кто коммитит к компиляторы — предпочитают блокнот? Вы утверждаете что есть четкое разграничение этих групп?


                                                                chapuza такой же вопрос, на Ваш комментарий.

                                                                  0
                                                                  Нет, мы утверждаем, что те кто не используют IDE не обязательно обжигатели горшков дыроколы перфокарт.

                                                                  Кажется, это вы утверждали, что есть способ отличить не настоящего разработчика по признаку не использования некоторой фичи IDE.
                                                                    0

                                                                    В четвертый раз. Я не говрю про иде. Я говорю про фичу. Которая может быть и не в ИДЕ.


                                                                    Напоминаю, что дыроколы тоже писали самый сложный код своего времени. Тоже думали долго, а писали мало. Без них современного программирования не было бы. Мне было бы стыдно таких людей оскорблять.


                                                                    хм
                                                                      0
                                                                      Я запутался. Вы пишете:
                                                                      Напоминаю, что дыроколы тоже писали самый сложный код своего времени. Без них современного программирования не было бы.
                                                                      И это тоже написали вы:
                                                                      Были люди, которые умели программировать на перфокартах. [...] Проблема в том, что они не отличные спецы. Если бы таких было большинство, мы бы никогда не перешли от машинного кода к асемблеру.
                                                                      Один я вижу здесь прямое противоречие?

                                                                      Проверочный вопрос: считаете ли вы, что контрибьютор компилятора может быть «неполноценным професионалом» в вашем понимании?
                                                                      хм
                                                                      Вы два раз спросили, вам два раза ответили.
                                                                        0
                                                                        Один я вижу здесь прямое противоречие?

                                                                        Уверен, что не только Вы. Противоречия тут нет. Часть людей, которые работают на Х, создали Y. Отсюда первое утверждение. Большинство со временем, стало использовать Y вместо X.


                                                                        Однако, если бы большинство рассказывало, что Y ненужен и как у них все классно в X — Y бы де-факто был бы мертв. Отсюда второе утверждение.


                                                                        Заблуждение в том, что я там и там описывают одних людей. Это нет так. Те и те люди писали код на перфокартах. Но первые создавали замену перфокартам, а вторые — рассказывали, что замена никому не нужна.

                                                                          +1

                                                                          Я, наконец, понял, что за недопонимание тут приключилось.


                                                                          Ни я, ни defuz (смею сказать от его имени), не против прогресса. Наоборот. Мы этот прогресс даже — в меру сил и умений — вперед двигаем: вот коллега парсинг AST в расте поправил, я понемногу компилятор эликсира рихтую надфилем.


                                                                          Мы просто не считаем, что IDE — это прогресс по отношению к блокноту. Алгоритм, который считает в два раза быстрее — прогресс. Правильный парсинг AST — прогресс. А облегчение условий существования людей, которые без подсказки две функции высшего порядка связать не могут — нет.


                                                                          Нам быстрее, удобнее и проще в блокноте. Не потому, что мы отстали в развитии, а потому, что IDE — это приставные колесики на детском велосипеде. Научившись кататься, люди их снимают.

                                                                    –1

                                                                    Нет, мы утверждаем, что те кто не используют IDE не обязательно обжигатели горшков дыроколы перфокарт.


                                                                    Кажется, это вы утверждали, что есть способ отличить не настоящего разработчика по признаку не использования некоторой фичи IDE.

                                                0
                                                вам шашечки, или ехать?

                                                А можно мне и то, и то? Я хочу, чтобы у таксиста была бы и рабочая сертифицированная машина, и права на вождение, что не отменяет требования «доехать и пункта А в пункт Б».


                                                От сантехника я хочу не просто результата работы, но и гарантии на будущее, и формального сертификата (в Европе ремонт абы кем может привести к проблемам в будущем). И ещё хочу, чтобы специалист прошёл обучение заранее, чтобы «результат» не развалился бы через месяц.


                                                Фраза выше — это отличный пример троллинга-манипуляции: вам в машине двигатель или коробку передач? В телевизоре должен работать звук или видео?

                                                  0
                                                  Я как-то не припомню, чтобы где-то выдавали сертификаты по владению IDE, и где-то их требовали. Как думаете, почему?
                                                    0
                                                    Я как-то не припомню, чтобы где-то выдавали сертификаты по владению IDE, и где-то их требовали. Как думаете, почему?

                                                    Я написал про некорректную фразу, не более. Она не является ни доказательством, ни обоснованием.


                                                    "Как думаете, почему?" — я не люблю загадки и наводящие вопросы. Я еще по школе запомнил, что учитель задает много наводящих вопросов чаще всего тогда, когда сам не знает ответ. Аналогично и на собеседованиях происходит иногда. Не всегда, но мне приходилось быть свидетелем подобного. Если у Вас есть ответ, то напишите, пожалуйста, прямо.


                                                    Если мы вернемся к теме ветки, то у меня нет своего мнения на этот счет (ни обоснованного, ни эмоционального). Иногда необходимо уметь работать без IDE, иногда это неэффективно. Лично я пишу 99% кода в IDE, а оставшийся процент — это либо однострочники, либо мелкие исправления в известном мне коде. Но это лично мой опыт, а исследований я не только не проводил, но и даже не читал. Навязывать что-то я тоже не хочу. Так что тут мне сказать нечего. Основной мой посыл — фраза про шашечки является некорректной, как и заезженная "исключение доказывает правило".

                                                      +2
                                                      Мне показалось, что ответ лежит на поверхности: использование IDE не является ни трудным, ни обязательным навыком для эфективной разработки.

                                                      Если дальше проводить аналогии, то я сравнил бы IDE с автоматической коробкой передач – кому-то с ней удобнее, а кому-то она будет мешать, если человек хорошо ездит на механике. Но вряд ли вам прийдет в голову утверждать, что те кто ездят на механике – плохие водители. И, как и автоматическая коробка передач для водителей, IDE не расширяет фундаментально ваши возможности как разработчика.
                                                        0
                                                        Лично я пишу 99% кода в IDE, а оставшийся процент — это либо однострочники, либо мелкие исправления в известном мне коде


                                                        Аналогично, кэп.

                                                        Но ключевая польза IDE ровно одна — автодополнения названия функций/методов/классов.

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

                                                        Ну то есть тут нет какого профессионализма или непрофессионализма.
                                                        Просто ограничения человеческой памяти.

                                                        Или вы всерьез считает, что кто-то освоивший концепции программирования может при этом не понимать что такое autocomplete в IDE?
                                                          +3
                                                          Но ключевая польза IDE ровно одна — автодополнения названия функций/методов/классов.

                                                          Ну да, ну да.


                                                          А как же семантическое переименование сущностей? Переход от объявления к реализации и наоборот? Поиск использований сущности? Подсказки типов? Визуальный мердж, в конце-концов?

                                                            –1
                                                            Но ключевая польза IDE ровно одна — автодополнения названия функций/методов/классов.


                                                            А как же семантическое переименование сущностей? Переход от объявления к реализации и наоборот? Поиск использований сущности? Подсказки типов? Визуальный мердж, в конце-концов?


                                                            Я написал ключевая польза.
                                                            Вы же приводите пример пользы вообще.

                                                            То, что вы написали — вторично.

                                                            Если предложат на выбор — автокомплит или все остальное — что выберите?
                                                              +1

                                                              Лично я рефакторинг и поиск использования/объявления

                                                                0
                                                                Лично я рефакторинг и поиск использования/объявления


                                                                Использовать/не использовать != ключевой или не ключевой фактор.

                                                                Я все это использую.
                                                                Но не считаю самой важной особенностью IDE.

                                                                Хотя, когда появилось функциональность рефакторинга в начале 20 века в Intellij — это было «вау».
                                                                +1
                                                                Если предложат на выбор — автокомплит или все остальное — что выберите?

                                                                Всё остальное. Автокомплит лишь немного экономит время при наборе кода, а делать руками то, что умеет IDE, обычно оказывается неоправданно долго и больно.

                                                                  0
                                                                  Автокомплит лишь немного экономит время при наборе кода


                                                                  Дело, имхо, не в скорости набора текста на клавиатуре.
                                                                  Я автокомплит использую, хотя и владею слепым десятипальцевым методом набора на клавиатуре уже много-много лет.

                                                                  Использую потому что не помню 100500 названий функций.

                                                                  Если с функциями ядра языка программирования еще куда ни шло, ихо худо-бедно можно и помнить большую часть, но а при использовании сторонних библиотек — запомнить всё это невозможно, а в документацию каждый раз лазать — не продуктивно.
                                                                    0
                                                                    а в документацию каждый раз лазать — не продуктивно.

                                                                    Переход на объявление же :)

                                                                      0
                                                                      Переход на объявление же :)


                                                                      Для начала нужно помнить название типа экземпляр которого ты объявляешь.

                                                                      А потом, когда объявленное используешь — без автокомлита тебе нужна документация, чтобы написать имя метода/свойства.
                                                                      Это и не продуктивно по сравнению с автокомплитом — постоянно лазать в документацию.
                                                                        +1
                                                                        А потом, когда объявленное используешь — без автокомлита тебе нужна документация, чтобы написать имя метода/свойства.

                                                                        Она всегда нужна. Потому что у свойства/метода есть еще параметры, допустимые значения на входе и возможные варианты возврата. И IDE помогает только с названием метода и (иногда) с названиями параметров.
                                                                        Только вот она вам вывалит сырцом все 254 метода, 130 полей и сверху, в поле выбора, будут внутренние методы, начинающиеся с подчеркиваний. И?

                                                                          +1
                                                                          Она всегда нужна. Потому что у свойства/метода есть еще параметры, допустимые значения на входе и возможные варианты возврата. И IDE помогает только с названием метода и (иногда) с названиями параметров.


                                                                          Моя Jetbrains IDE показывает и параметры.
                                                                          Причем еще древняя Delphi это умела в начале веке.

                                                                          Грамотно составленное API библиотеки имеет логично названные и функции и параметры.

                                                                          В результате не нужно на каждый вызов идти в документацию. Документация нужна только «чтобы въехать в тему».

                                                                          После чего достаточно подсказок автокомплита.

                                                                          Только вот она вам вывалит сырцом все 254 метода, 130 полей и сверху, в поле выбора, будут внутренние методы, начинающиеся с подчеркиваний. И?


                                                                          Дайте угадаю:

                                                                          Вы пишете на языке с динамической типизацией? Это там такие простыни подсказок, видимо?

                                                                          Дело в том, что языке со статической типизацией — подсказки IDE максимально уточнены, благодаря довольно жесткому-точному AST. Никаких лишних портянок не выводится.

                                                                          Собственно это одна из двух причин, почему я предпочитаю языки со статической типизацией.
                                                                            +1
                                                                            Дайте угадаю:

                                                                            Зачем гадать, когда можно прочитать процитированный фрагмент?


                                                                            Хоть с автокомплитом, хоть без, если вы не знаете названия метода — вам в документацию. Если вы запомнили его неправильно — вам в документацию. Если вы не помните особенности метода — вам обратно в документацию. До тех пор, пока сигнатура функции и половина документации не отпечатаются у вас в памяти — вам в документацию; или при написании, или, если у вас синдром "прокатило", потом при отладке, когда "прокатило" не прокатит.


                                                                            Дело в том, что языке со статической типизацией — подсказки IDE максимально уточнены

                                                                            Автокомплит начнет работать сразу, как вы поставите точку. И вывалит портянку. И см. выше.
                                                                            Конечно, если у вас в объекте в принципе не больше 5÷7 методов, полей и свойств в сумме, то тогда автокомплит будет работать точно так, как вы рекламируете.


                                                                            А когда вы помните сигнатуру, то допечатать обычно быстрее, чем ждать пока протупит подсказка автокомплита. Разве что у вас методы и поля по 30+ символов, но это уже проблема совершенно другого рода.


                                                                            Емнип, у дельфи в 5 версии была самая лучшая IDE. Ее было очень удобно изучать автокомплитом.
                                                                            И он был настолько шустр, что даже почти не мешал при написании…

                                                                              0
                                                                              Хоть с автокомплитом, хоть без, если вы не знаете названия метода — вам в документацию.


                                                                              Странно, почему то у меня работает без простыней кода.
                                                                              Наверное потому что IDE учитывает тип возвращаемого значения? Наверное потому что IDE умеет искать не с начала названия метода?
                                                                              А возможно, IDE использует какой-то «нечеткий поиск»?

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

                                                                              Ну лет 10 назад я бы с вами согласился.
                                                                              Но на современном железе что-то тупит?

                                                                                0
                                                                                Наверное потому что IDE учитывает тип возвращаемого значения?

                                                                                Только если ваш код состоит из одних присваиваний.
                                                                                Если нужно дернуть метод, не возвращающий значения или возвращаемое значение не представляет интереса — привязываться не к чему.


                                                                                Наверное потому что IDE умеет искать не с начала названия метода?

                                                                                Так это только увеличит количество вариантов


                                                                                А возможно, IDE использует какой-то «нечеткий поиск»?

                                                                                А это еще пропорционально домножит.


                                                                                Ну лет 10 назад я бы с вами согласился.
                                                                                Но на современном железе что-то тупит?

                                                                                Да вот как-то современное железо еще купить надо бы.
                                                                                А так пока что Sublime 3 — наше всё.

                                                                                  0
                                                                                  Наверное потому что IDE умеет искать не с начала названия метода?


                                                                                  Так это только увеличит количество вариантов


                                                                                  Это радикально уменьшает количество вариантов, если вы помните хотя бы несколько букв из названия.
                                                                                    0

                                                                                    Простите, но комбинаторика против.
                                                                                    Если вместо последовательности в n символов вы ищете количество их сочетаний, то у вас никак не может стать меньше результатов, чем в первом случае.

                                                                                      0
                                                                                      Простите, но комбинаторика против.
                                                                                      Если вместо последовательности в n символов вы ищете количество их сочетаний, то у вас никак не может стать меньше результатов, чем в первом случае.


                                                                                      Вы из числа всевозможных комбинаций считаете что ли?

                                                                                      Зачем? Когда нам нужно считать из числа имеющихся в гипотетической библиотеке идентификаторов.

                                                                                      Чем больше вы даете подсказок IDE, хоть даже вы и делаете это отдельными буквами — тем меньше список, который IDE вам предлагает.

                                                                                      Только если ваш код состоит из одних присваиваний.
                                                                                      Если нужно дернуть метод, не возвращающий значения или возвращаемое значение не представляет интереса — привязываться не к чему.


                                                                                      Ну здрасте.
                                                                                      Вы же сами написали «метод», то есть он привязан к классу.
                                                                                      В грамотно продуманном классе, как правило, методов не сотни.

                                                                                      Или у вас гиганские классы-боги только в ходу?
                                                                                      Тогда я понимаю откуда вы взяли портянки автокомплита.

                                                                                      У меня второе подозрение, что вы пишете на языке с динамической типизацией. Там, действительно, IDE может вам давать огромный список-методов, ибо она не знает точно что вам надо.

                                                                                      Но, уверяю вас, в языке со статической типизацией — IDE определяет вам необходимое намного точнее и упомянутый список возможных методов много короче.
                                                                                        0
                                                                                        Зачем?

                                                                                        Это у вас надо спросить. Вы же пишете:


                                                                                        Наверное потому что IDE умеет искать не с начала названия метода?

                                                                                        и


                                                                                        А возможно, IDE использует какой-то «нечеткий поиск»?

                                                                                        Без комментариев.


                                                                                        В грамотно продуманном классе, как правило, методов не сотни.

                                                                                        В идеально-продуманом классе, написанным сферическим сеньором в идеальной команде по идеальным гайдлайнам… не слишком ли мало идеального в требованиях?


                                                                                        В реальности приходится работать с очень разным кодом, на очень разных языках.


                                                                                        У меня второе подозрение, что вы пишете на языке с динамической типизацией.

                                                                                        Нет, просто вы используете магию, а этот говорит о том, как энта магия работает. Вы защищаете свое мнение, а каджит говорит, что если вы добавляете больше вариантов, то у вас никак их не может стать меньше. Вы говорите, что вариантов всегда мало — и совершенно опускаете, что по вашим же условиям, вы забыли название метода — а значит, прекратите набор после точки (или что в вашем языке выполняет роль синтаксического сахара для методов), и угадайте, что произойдет?

                                                                                          0
                                                                                          Я первым грешным делом подумал на vim у вашего оппонента, но и Sublime хрен редьки не слаще.

                                                                                          Плюс у него в классах
                                                                                          все 254 метода, 130 полей

                                                                                          Это не особенности языков с динамической типизацией. Тот же PHPStorm дает вполне вменяемый автокомплит на адекватном коде.

                                                                                          Это особенности того, как он (ваш оппонент) пишет свой код. Потому и страдает.
                                                                                            0

                                                                                            А PHPStorm (или любая другая идея) умеет Idris? Потому что на PHP можно и в блокноте писать, там IDE при наличии минимального интеллекта вообще не требуется.


                                                                                            А вот в Idris (ну в Агде тоже) без фидбека компилятора делать вообще нечего. Так как там? vim умеет, если что — и в case split, и в дырки, и во все остальное.

                                                                                              –1
                                                                                              Вы плохо знаете php-экосистему.
                                                                                              Изучите ее, потом расскажете свои впечатления о виме в ней
                                                                                                0

                                                                                                Вы плохо знаете вим. Изучите его, потом рассказывайте о каких-то там экосистемах.

                                                                                                +1

                                                                                                Когда хотел попробовать Idris, нагуглил, что плагина для IDE от JetBrains нет, но люди приспособили плагин Haskell и худо-бедно базовую поддержку Idris получили (для меня звучит дико :) ).

                                                                                                  +1
                                                                                                  люди приспособили плагин Haskell и худо-бедно базовую поддержку Idris получили

                                                                                                  Не получили. Весь смысл фидбека компилятора в том, что он три четверти кода за вас напишет, особенно в части доказательств, заполнения дырок. case-сплитов всяких.


                                                                                                  Эти люди, которые «приспособили» — они вообще не понимают, зачем им идрис. Хаскель против идриса — ну если не сравнивать возраст и качество компилятора — пшик. В типах, как таковых, никакого смысла нет, а зависимые типы первого класса — это прямо глоток свежего воздуха в душном мире CS.


                                                                                                  Если бы меня не тошнило от Idea, я бы сам, кстати, плагин написал бы: там ≈10 прямых вызовов API компилятора надо имплеметировать и ответ в редактор прокинуть; компилятор идриса сам себе language server.


                                                                                                  Но мне с головой хватает вима и vscodium’а, а там с плагинами все в порядке.

                                                                                                    +1
                                                                                                    Эти люди, которые «приспособили» — они вообще не понимают, зачем им идрис.

                                                                                                    Я часто не понимаю зачем та или иная технология на проекте, на который только пришёл. Но работать с ней надо как-то. Вот и ищутся пути попроще, читай — привычнее.


                                                                                                    Или спросил где-нибудь "надоело по TDD писать, которое про тесты, хвалят на Хабре то, которое про типы. Какой язык сейчас самый перспективный считается?" и кто-то называет тот же Idris. Открываешь доку и там "create a file called hello.idr containing the following text". Ну не в блокноте же создавать, избалованы же MSами, JetBrainsами и прочими Borlandами, нам GUI подавай, автодополнения и рефакторинги. и вот не начав изучать языка начинаем настраивать среду разработки...

                                                                                                      +2

                                                                                                      Idris — это совсем другой подход к программированию вообще просто. В отличие от того же хаскеля — там синтаксис бегло просмотрел — и ты уже на коне. Тут нет.


                                                                                                      Если хотите, оставьте почту в личке, я скину «Type Driven Development» Эдвина Бради, автора языка. Смысл TDD в том, что в языке с настоящими зависимыми типами (которым хаскель не станет никогда) — тип такой же полноправный элемент языка, как все остальное. И пока вы инкрементально пишете код, компилятор вам выводит по типам, что тут может появиться, что — нет, и во многих случаях, получается так, что пишет код за вас.


                                                                                                      P. S. что-то мне сложно представить себе ситуацию «пришел на проект, а там внезапно идрис» :)

                                                                                                        0
                                                                                                        В отличие от того же хаскеля — там синтаксис бегло просмотрел — и ты уже на коне.

                                                                                                        Ну нет, синтаксис в Idris гораздо проще же. Сам Брэди об этом говорит (например, тут https://corecursive.com/006-type-driven-development-and-idris-with-edwin-brady/).
                                                                                                        Haskell большой, сложный и постоянно расширяется. Зависимые типы делают язык более простым и однородным.


                                                                                                        синтаксис бегло просмотрел — и ты уже на коне

                                                                                                        Ага. От беглого осмотра синтаксиса сразу впечатывается в мозг вся Typeclassopedia и семантика GHC Runtime, начинаешь ориентироваться в сотнях расширений GHC и не задумываясь писать Хаскель-код который не тормозит и не течёт мемликами.


                                                                                                        Idris — это совсем другой подход к программированию вообще просто.

                                                                                                        Другой подход именно к процессу набора кода. Процесс дизайна программ не сильно меняется.


                                                                                                        В типах, как таковых, никакого смысла нет, а зависимые типы первого класса — это прямо глоток свежего воздуха в душном мире CS.

                                                                                                        У зависимых типов, конечно, много приятных применений (самый близкий мне пример, пожалуй, — схемы бд).


                                                                                                        По мне так type inference + pure functions + ADTs + pattern matching + type classes дают 80% профита от ФП в принципе, и дальнейшее усложнение типов — diminishing returns, хоть и не лишено смысла.


                                                                                                        И пока вы инкрементально пишете код, компилятор вам выводит по типам, что тут может появиться, что — нет, и во многих случаях, получается так, что пишет код за вас.

                                                                                                        Пока проект чуть-чуть не подрастёт, и тогда ответы компилятора начинают занимать несколько секунд, а не миллисекунд...

                                                                                                          +1
                                                                                                          синтаксис в Idris гораздо проще же

                                                                                                          Конечно. Я нигде иного и не утверждал. Я говорил, что в Хаскеле, как и примерно во всех остальных языках, синтаксиса достаточно, чтобы въехать.


                                                                                                          Haskell большой, сложный и постоянно расширяется.

                                                                                                          И именно поэтому он — обреченная, тупиковая ветвь развития.


                                                                                                          начинаешь ориентироваться в сотнях расширений GHC

                                                                                                          Вы хвастаетесь неизлечимыми пороками языка, ради оправдания которых была даже выдумана максима «avoid success at all cost»? Это религиозное?


                                                                                                          Процесс дизайна программ не сильно меняется.

                                                                                                          Эмммм… Я вот некоторые критичные части нашего софта пишу на идрисе, а потом руками транспилирую куда надо (эрланг, джава, руби). Именно потому, что процесс дизайна программ вообще другой. А не потому, что мне нужны типы (не нужны).


                                                                                                          type inference + pure functions + ADTs + pattern matching + type classes дают 80% профита от ФП

                                                                                                          К ФП напрямую тут относятся только pure functions.


                                                                                                          усложнение типов

                                                                                                          Назвать зависимые типы — усложнением системы типов, это как назвать отрицательные числа — избыточным усложнением арифметики.


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

                                                                                                          Поэтому такие надежды люди возлагают на второй компилятор. Первый — фактически PoC же. Да и несколько секунд — тоже не трагедия; обособьте модуль на первых порах, и все начнет летать.

                                                                          0
                                                                          … а в документацию каждый раз лазать — не продуктивно.

                                                                          Если документация удобная, наглядная и с поиском, то почему бы и нет?

                                                                            0
                                                                            Если документация удобная, наглядная и с поиском, то почему бы и нет?


                                                                            а что есть без поиска?

                                                                            Продуктивнее в неё вообще не лазать при наборе кода, когда уже с докой разобрался.

                                                                            Лазать в доку только для составления концепции работы с той или иной библиотекой.

                                                                            Но даже если ты доку прочитал и понял, что 100500 функций библиотеки после этого всё равно на память не помнишь.

                                                                            И вроде бы ты помнишь что тебе нужна такая функция и она есть. Но вот как она называется SignRSASHA или SignSHARSA — хоть убей не помнишь уже.
                                                              –1
                                                              Фраза выше — это отличный пример троллинга-манипуляции [...]

                                                              Ничего подобного. Все перечисленное вами — гарантии на будущее, формальный сертификат, обучение заранее, «результат» не развалился через месяц — это про продукт.


                                                              Если вы хотите аналогию с тем, какой инструмент при этом использовать — то это «сколько иконок у него на торпеде» и «какой формы янтарный набалдашник на ручке переключения передач».

                                                                0

                                                                Нет. Я написал конкретно про такси. И вот лично мне необходимы и шашечки, и ехать, и непрокуренный салон и еще кучу других мелочей.


                                                                "Шашечки или ехать" — это стандартный прием "выбор без выбора".


                                                                Если вы хотите аналогию с тем, какой инструмент при этом использовать — то это «сколько иконок у него на торпеде» и «какой формы янтарный набалдашник на ручке переключения передач».

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

                                                                  –2
                                                                  это стандартный прием «выбор без выбора»

                                                                  Вы неверно понимаете, в каком значении там используется «или». Ну да ладно, у вас все равно наверняка найдется еще немало ссылок на умные статьи по психологии.


                                                                  P. S. Иконки на торпеде:


                                                                  Иконки на торпеде

                                                                  0

                                                                  После новости, что xi умер у меня упала всякое желание дальше продолжать дискусию. Потому что ваша (не лично Ваша, а множество людей) точка зрения, что писать в блоконте нормально — останется де-факто верной еще минимум 5 лет. Может быть кто-то через несколько лет опять поднимет знамя и займется системой для ввода, которое работает бытрее и блокнотов и ИДЕ. А может быть такого для клавиатуры уже не будет.


                                                                  Но ради imanushin.


                                                                  Ваш пример с ручкой не верен. Правильный пример с системой безопастности. Ремни, подушки, абс и прочее. На доставку из А в Б оно никак не влияет. Но когда что-то идет не по плану, оно окзывает больше влияния, чем сама задача попасть из А в Б.


                                                                  В примере с сантехникой — то, что кран после мастера будет работать — менее важно, чем то что новый кран затопит и меня и соседей.

                                                                    0
                                                                    Какая ирония.

                                                                    Между прочим, для токенизации кода и подсветки синтаксиса в xi-editor используется пакет syntect, который в свою очередь основан на моем заброшенном проекте sublimate по созданию open source клона Sublime Text 3 и на моем байндинге регулярных выражений oniguruma.

                                                                    Так что мы по одну сторону баррикад гораздо больше, чем вам кажется.
                                                                      0

                                                                      я никогда не расставлял людей по стороны барикад. Я начал с примера человека который делал что-то хорошо, а что-то плохо.

                                                      –5
                                                      Следуя вашей логике, я, как человек, 7 лет назад отказавшийся от IDE в пользу «блокнота», либо развиваюсь в обратном направлении как специалист, либо вы пишете полную ахинею.
                                                        +3

                                                        Это еще очень сильно от языка зависит. И от уровня владения этим самым языком.


                                                        Java без автокомплита сотрет пальцы до первых фаланг, на одних импортах. В очень динамических языках, типа руби и перла, — напротив, LS беспомощен и только мешает. Эрланг и эликсир настолько изящно минималистски спроектированы, что в редкие моменты замешательства проще в документацию глянуть, но полная поддержка кастомных компиляторов с прокинутыми и экспортируемыми аннотациями всех сортов очень облегчают глубокое понимание сайд-эффектов собственного кода.


                                                        А вот идрис (да и агда), например, в блокноте просто потеряют 95% своего очарования, потому что основной смысл языка в принципе — помощь в доказательстве лемм, которые без обратной связи с компилятором можно и в императивном языке доказывать, и на бумаге. Это очень значительная часть процесса написания кода (если не использовать их как хаскель, конечно) — и посредник между компилятором и человеком тут просто необходим, потому что далеко не каждый case-/with-сплит очевиден, я уж молчу про проверку тотальности.

                                                          0
                                                          А вот идрис (да и агда), например, в блокноте просто потеряют 95% своего очарования

                                                          +100500


                                                          Использовать языки вроде Coq без какого-нибудь Proof General — за пределами человеческих возможностей, как мне кажется.

                                                            –1

                                                            Ну утюгом, в принципе, можно худо-бедно заколотить шуруп, просто первый вопрос лично у меня будет «а зачем ты, мил человек, взял такой язык, если тебе proff assistant не нужен?».

                                                              0

                                                              Легаси )

                                                                0

                                                                «У нас много легаси на Coq» — это, наверное, самое козырное описание вакансии, которое вообще можно себе представить.

                                                                  +1

                                                                  "Легаси" же не обязательно что-то старое. Вот был какой-то фанат такого программирования, потом ушёл и оставил после себя наследство местами. А кому-то поддерживать...

                                                            –2
                                                            Это еще очень сильно от языка зависит. И от уровня владения этим самым языком.
                                                            А еще очень сильно зависит от класса решаемых задач.

                                                            В моем случае, приведение написанного кода в компилиреумый AST – дай бог если 5% работы, и это при том что я пишу в том числе на Rust, который славится придирчивостью компилятора.

                                                            Очевидно, что применяя IDE, приведение кода к состоянию компилируемости произойдет быстрее, но лично для меня этот плюс перевешивает минусы.

                                                            Плюсы от «блокнота»:

                                                            1. Минималистичность, и, как следствие, 100% предсказумость рабочего окружения. Мне никогда не приходится бороться с моим инструментом, ждать перестроение индексов или убеждать окружение что то что я сделал на самом деле правильно. Мне никогда не нужно конфигурировать окружение – конфигурация одинакова для всех проектов. Я просто открываю файл и пишу код. Отклик окружения на мои действия всегда миллисекундный, и окружение никогда не мешает мне работать с той скоростью, которой я могу.

                                                            2. Ты начинаешь знать язык программирование, на котором пишешь. Благодаря использованию «блокнота» с глупым аутокомплитом, я случайно стал тем самым идеальным кандидатом на собеседованиях, где нужно на бумажке написать безошибочный код. Потому что я помню имена методов, порядок аргументов, и пространства имен, которые использую. Не скажу, что это обязательный навык для программиста, но я заметил что это сильно ускоряет работу, потому что «умный аутокомплит» в голове работает быстрее.

                                                            3. Я знаю, как писать правильный код. Когда цена написания ошибочного кода выше, начинаешь задумываться, как с первого раза писать код, который заработает. В итоге написание кода для меня – это не игра в кошки-мышки с компилятором, а именно процесс написания, с последующей верификацией компилятором. Я спокойно могу написать 500-1000 строк кода без помощи компилятора, и только затем с его помощью отловить пропущенные ошибки. Я не трачу время на исправление ошибок в коде, который будет несколько раз переписан по ходу изменения структуры решения.

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

                                                            5. Окружение не указывает мне, когда и что мне делать и почему я не прав. Часто в процессе написания сложного кода не удобно описывать сущности в такой последовательности, чтобы в любой момент полученный код был валидным. Иногда удобнее проектировать сверху вниз, вызая функции и ссылаясь на типы, которых еще не существует. Я могу себе это позволить, потому что сам контролирую, когда хочу проверить мой код.

                                                            6. В конце концов, я знаю свое окружение, в том смысле что я всегда точно понимаю, как из написанных мной букв возникает работающий артефакт, как он тестируется, и как интегрируется с другими сущностями.

                                                            7. Поскольку нет IDE – нет и деббагера. Лично я считаю, что дебаггеры делают разработчиков ленивыми и не способными писать одновременно понятный и работающий код (кроме случаев низкоуровневого системного программирования). Если мой код не работает, я думаю как написать тест, который проверит мои предположения о его работе. Или добавляю строку в лог, которая поможет лучше понимать происходящее. И если код трудно «отдебажить» без дебагера, скорее всего он плохо спроектирован, и стоит задуматься о его рефакторинге. Для меня код, который настолько запутан, что в нем трудно сразу увидеть ошибку, такой же проблемный, как и не работающий код.

                                                            Ничего против IDE и тех кто их использует IDE не имею. И признаю что в некоторые моменты мне их возможностей не хватает. Но возвращаться назад и терять приобретенные плюсы не хочется.
                                                              0

                                                              А я вместо того, чтобы заучивать документацию на выходных погулял с детьми в ботаническом саду. А за 8 часов работы мне таски надо делать, а не дзен постигать, потому что скрам и надо делать быстро новые фичи.
                                                              П.С. Я все рано использую emacs + LSP, но вот без последнего пришлось бы действительно туго

                                                                0

                                                                Ну да, я тоже не пользуюсь IDE, кроме, как я и оговорился, идриса. Потому что его просто нет смысла использовать, если не заставлять компилятор выводить типы для лемм на лету.


                                                                И кроме тех языков, в которых я не чувствую себя свободно (java, python, R, haskell). Раст пока ходит мимо меня, но вот Julia внезапно зарекомендовала себя очень круто именно потому, что я со второго часа погружения выкинул LS и стал писать «в блокнот». Что характерно, с хаскелем этот вариант не пройдет, из-за ублюдочности дизайна Prelude и миллиарда функций в глобальном неймспейсе, подтянутых из квадриллиона сторонних пакетов, по сотне раз дублирующих одно и то же. Я просто не способен выучить это все наизусть (да и не хочу, и смысла не вижу).


                                                                stobaksov100 я не использую языки, в которых существует нужда в более, чем пяти библиотеках на проект. Ассенизаторов и без меня вокруг полно́.

                                                                  0
                                                                  Ну так Idris и его старшие коллеги не просто так называются proof assistant. Еще к «IDE oriented» языкам я бы добавил C# и Java. Их использование с MS Studio и IntelliJ оставило у меня исключительно приятные впечатления.

                                                                  А вот для Python рекоммендации IDE меня только бесили, потому слишком часто ошибались. В конечном итоге меня интересует лишь мнение компилятора/интерпретатора о выполнимости моего кода, и если мнение IDE с ним расходится, то я начинаю отвлекаться на несущевствующие проблемы.

                                                                  C Rust та же проблема, хоть он и статически типизирован. Там проблема в том, что пока не смогли сделать одновременно быстрый и корректный language server, из-за сложного выведения типов и навороченности макросов.
                                                                0
                                                                Это еще очень сильно от языка зависит. И от уровня владения этим самым языком.


                                                                Типа вы на память помните названия всех функций из 100500 библиотек — это великолепное знание языка?

                                                      0

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


                                                      Что касается X as a code — это вполне себе код. Разнца только в том, что это декларативный код, а не императивный, как большинство ЯП.


                                                      И IDE в этом случае делает то же, что и в любом другом — пытается эмулировать воспроизведение этого кода его интерпретатором/компилятором, обычно за счет анализа.


                                                      При этом будь то код, написанный на питоне, будь то С++, будть то докерфайл или куб конфиг, для IDE разницы между ними намного меньше, чем для программиста.


                                                      Если вопрос в том, что не все IDE пока умеют хорошо с этим справляться — вопрос времени и установки плагинов.


                                                      Если вопрос в том, что IDE не может проанализировать, что там внутри контейнера за этими переменными скрывается — то это общая интеграционная проблема, у вас и в коде приложения ни одна IDE не покажет, что конфиг подключения к внешней системе как-то невалиден.


                                                      Скорее всего это исправится со временем, когда появятся стандарты для описания фасада контейнера в явном виде (сейчас можно только список ENV прописать, но это больше хороший тон, нежели стандарт).

                                                        0

                                                        Виноват, пропустил комментарий за срачем выше.


                                                        Разнца только в том, что это декларативный код, а не императивный.

                                                        Не согласен. Конечно это декларативный код, но не код в контекте того, что я пишу. Нет ни одного инструмента, который отслеживает цикл жизни этой переменной. От декларации, до задания, до использования. Каждый инструмент "ведет" эту переменную только в рамках одной технологии. Может двух.


                                                        Конечно, со временем ИДЕ научатся стирать эти границы. Первые попытки уже можно найти. Но есть все шансы, что к этому моменту уже и докера не будет. Может даже и ИДЕ уже не будет.

                                                          +1

                                                          Концепция X as a code наверняка надолго переживет докер.


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


                                                          Вполне вероятно, что императивное программирование, про которое вы говорите


                                                          но не код в контекте того, что я пишу
                                                          отойдет на задний план как более низкоуровневое, чем оперирование контейнерами и конфигурациями. Уже сейчас есть четкая тенденция к реализации систем через композицию контейнеров, как раньше была композиция классов. Уже сейчас нормально вместо загрузки библиотеки в приложение запускать готовый контейнер сайдкаром для тех же задач.
                                                            0
                                                            но мало где получила широкое распространение кроме SQL

                                                            Excel и прочие электронные таблицы же

                                                              0

                                                              По своему опыту могу сказать, что сколько-нибудь нетривиальная обработка данных в Excel(-like) в какой-то момент вызывает острое желание переписать это всё на нормальный ЯП.

                                                                0
                                                                По своему опыту могу сказать, что сколько-нибудь нетривиальная обработка данных в Excel(-like) в какой-то момент вызывает острое желание переписать это всё на нормальный ЯП.


                                                                Там же есть встроенный Visual Basic?
                                                                  0

                                                                  Я же сказал нормальный ЯП.

                                                                    0
                                                                    Я же сказал нормальный ЯП.


                                                                    С формальной точки зрения Visual Basic — вполне себе полноценный язык программирования. Там всё есть.

                                                                    Ну а прямой доступ из него к объектам Excel позволяет легко писать «нетривиальные вещи» которые вам были нужны.

                                                                    Это далеко не Basic, от которого только название. А вполне себе развитый по выразительным средствам язык.

                                                                    Вам же не Kubernetes на нём писать.

                                                    +12

                                                    Так что делать то? Докер умер, да здравствует кто? Судя по тексту Swarm сырой ещё. Вообще в статье все уг, не понятно куда простому разработчику двигаться. С докером хоть понятно все и инструкций полно.

                                                      0

                                                      Читайте https://m.habr.com/ru/post/467607/
                                                      Кратко — редхат завозит podman & buildah & skopeo для разработки
                                                      В опеншифт — докер ими заменяем на cri-O
                                                      В кубере — все нормальные люди уже выкидывают докер и ставят containerd/runc
                                                      Кто-то идёт дальше и заменяет runc на gVisor или kata.
                                                      Для изучения:
                                                      https://t.me/sre_hamster/70 (там две ссылки на серьёзные исследования)


                                                      Где докер пока ещё останется жить — это локальная разработка (но с тем же успехом можно вагрант машины использовать, тем более на виндовых или мак машинах))))

                                                      +24
                                                      Докер никуда не делся. Он живет и здраствует в небольших инсталляциях, на машинах разрабов, в CI. Эта экосистема отлично поживает и никуда не делась. Если мне надо поднять какой-нить гитлаб для офиса, то я это буду делать в докере естественно, потому что все под него написано. А еще лучше docker compose.

                                                      Докладов по нему не так много, но они есть. Непонятно зачем-то тут говорить за всех на основе российского сообщества. Туториалов полно создается до сих пор именно по нему. У меня тут другое мнение. Докер очевидно перешел в стадию зрелой технологии — он просто есть и стал синонимом контейнеров. Все о нем знают, все им пользуются. Смысл о нем говорить. Говорят о том, что модно и развивается, что постоянно меняется. Много ли говорят про виртуальные машины, какой-нить виртуал бокс, esxi? Нет, но странно на основе этого делать вывод, что они мертвы. Они просто есть и неотъемлемая часть инструментария.

                                                      Докер умирает в одной определенной нише — как интерфейс контейнеров для оркестраторов. Вместо докера там все больше модно использовать тот же cri-o. И причин этому много разных, в том числе здесь упомянутых. Но основная — докер просто слишком большой для этих целей. Оркестраторам нужная совсем небольшая прослойка, а докер это целое окружение в первую очередь предназначенное для людей.

                                                      Вообще в статье все уг, не понятно куда простому разработчику двигаться.

                                                      Да, есть такие авторы. Если такое ощущение от статьи, то стоит ее просто с большим скепсисом читать и мысленно заменять фразы о смерти на «теряет популярность, не так модно, зрелое, устоявшееся». Для простого разработчика и девопса ничего не поменялось — изучать докер и кубер все так же актуально как никогда.
                                                        0
                                                        Спасибо за адекватный коммент. Походу еще не все разработчики или девопсы такие хайпожоры как автор статьи у которых каждый день что-то умирает.
                                                        +1

                                                        Kubernetes — наш батюшка, Helm — наша матушка.

                                                          0

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

                                                          +2
                                                          Судя по тексту Swarm сырой ещё.

                                                          Он уже не высохнет.
                                                          Его развитие официально прекращено.
                                                            0

                                                            Вы про Docker Swarm или про docker swarm mode?

                                                          +1
                                                          Рискую нарваться на минусы со стороны «пряморуких» людей, но все же напишу. Я в прошлом системный администратор, сейчас разработчик, с докером дел особо не имел, пару раз чужой проект разворачивал локально, там да пришлось ставить docker compose и поднимать всю необходимую инфраструктуру, но это все с гуглением и чтением SOF, а также документации.

                                                          А вот недавно решил научится делать свои образы и вообще научится пользоваться Docker, сделал микроскопическое приложение на flask (несколько килобайт), создал Dockerfile прописал там все инструкции и ужаснулся введя docker build -t image_name, при сборке скачалась куча разных либ и файлов, суммарно чуть больше гигабайта, а если прикинуть сколько там кода, который возможно никто не проверял, откуда он качается? Как он будет влиять на работу хоста? А на работу приложения как будет влиять? А если что то заглючит где искать концы? В общем мне показалось все это не очень надежным и не безопасным, отчасти я нашел подтверждение своим подозрениям в статье, спасибо автору.
                                                            +16
                                                            Ваши подозрения мало связаны со статьей, которая говорит о докере и оркестрации. Докер не виноват, что ваше приложение на фласке занимает гиг. Мои приложения на Go занимают несколько десятков мегабайт — это мое приложение + alpine контейнер. Все ясно и понятно. А уж откуда что качается, как влияет на что — ответы на все эти вопросы можно легко найти, если изучить матчасть немного, а не просто по случайному туториалу чего-то делать. Когда кажется, то это всегда исходит от непонимания.
                                                              –2
                                                              alpine контейнер.

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


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

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

                                                                +5
                                                                Не надо преувеличивать проблему. Альпайн прекрасен. Все приложения на го на нем, потому что нам все еще нужно небольшое окружение для правильной работы приложений и отладки, когда что-то идет не так. Все приложения на питоне на убунте. Так уж случайно повелось, но в итоге обошли и возможные проблемы из упомянутых статей.
                                                                  0
                                                                  Не надо преувеличивать проблему. Альпайн прекрасен. Все приложения на го на нем, потому что нам все еще нужно небольшое окружение для правильной работы приложений и отладки, когда что-то идет не так.


                                                                  А зачем Go контейнер, он же по умолчанию вкомпилирует в бинарник библиотеки и более не зависит от окружения, кроме ядра ОС?
                                                                    +2
                                                                    От libc по умолчанию зависит (резолвинг DNS).
                                                                    А вообще вот вывод ldd на гошный бинарник:
                                                                    linux-vdso.so.1 (0x00007ffdced79000)
                                                                    libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fedff5ba000)
                                                                    libc.so.6 => /usr/lib/libc.so.6 (0x00007fedff3f1000)
                                                                    /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fedff9a7000)
                                                                      –1
                                                                      Упомянутые библиотеки являются частью дефолтной инсталляции операционной системы.
                                                                        +2
                                                                        более не зависит от окружения, кроме ядра ОС?

                                                                        Я лишь указал, что приведённая цитата не совсем соответствует действительности. И продолжая далее: если мы завязаны на дефолтный резолвер, то нам уже могут понадобиться resolv.conf, hosts, а это уже NSS. И это только первое, что пришло в голову, так что цитата «небольшое окружение для правильной работы приложений...» остаётся актуальной.
                                                                  0
                                                                  несомненно, все так — нужно изучать матчасть. Проблема только лишь в том, что докер снижает планку настолько сильно, что можно получать результат без матчасти, а потом удивляться, что же все так плохо работает. С другой стороны — в быстром результате есть плюс. Главное, не останавливаться на нем, а продолжать процесс познания

                                                                  Любая технология, которая хоть что-то делает за разработчика, дает ему повод расслабиться. Даже линукс — вместо маленьких bare-metal приложений у нас в роутерах целый линукс. Ничего, все живы здоровы. Наше дело не винить технологию, которая тут вообще не при чем, а подталкивать людей к изучению матчасти и пропагандировать хорошие практики.
                                                                +7

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

                                                                  +3

                                                                  Аргументация негативного опыта уровня "Я не разобрался в командной строке, ваш Linux — УГ!". У меня средний production-образ весит ~20-50mb, это я ещё туда системную обвязку для траблшутинга втаскиваю (всякие nc, dig, netstat, tcpdump и т.д.). Как же так?

                                                                    +1

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

                                                                      0
                                                                      Это что ж такое было, что network host нужен был? По опыту такое нужно всякому легаси и кривом уг вроде freeipa.
                                                                        +2

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

                                                                          0

                                                                          Поддержу то мнение что очень напрягает когда докер по своему усмотернию подсовывает првила в iptables. Я напрмер там обычно прописывал некоторые ограничения для защиты от атак но с докером от этого пришлось отказаться.

                                                                            +3

                                                                            Да, благо что большая часть CNI в Kubernetes сделана более грамотно, чем сеть Docker.

                                                                            0

                                                                            Плохой у вас опыт. --net=host позволяет использовать docker как формат распространения приложений, не притаскивая ничего другого в рабочий процесс.


                                                                            А процессы бывают разные, и уютный очередной CRUD с веб-интерфейсом — это не единственный тип приложения, которые бывают в этом мире.

                                                                              0
                                                                              Дефолтный бридж (ну или руками созданный) позволяет делать то, для чего докер был создан — изоляция. Внутри контейнера может быть хоть миллион портов поднято быть. Я все равно смогу вытащить только то, что мне нужно и только на том интерфейсе, на котором мне нужно. При этом контейнеры могу общаться между собой в своем уютном мирке и никого не трогать.
                                                                              Поэтому если какому-то приложению, которое ничего не делает хитрого с сетью вроде DHCP или еще чего, абсолютно требуется для работы --net=host, то ему мало оправданий.
                                                                                0
                                                                                Внутри контейнера может быть хоть миллион портов поднято быть. Я все равно смогу вытащить только то, что мне нужно и только на том интерфейсе, на котором мне нужно.

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


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

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

                                                                                  0
                                                                                  Это надо спрашивать у тех, кто писал приложение. Каждое приложение какие ему нужно поднимает порты. Когда у тебя на хосте их несколько поднимается, то неизбежно происходят конфликты, а какие-то порты вообще нет желания вытаскивать наружу. Для этого бриджи и сделаны. Не бегать по каждому конфигу и искать где бы там порты поменять, а делать это просто и в одном месте.

                                                                                  Я уж не говорю о том, что ВНУТРИ БРИДЖА НИКАКОГО контроля взаимодействия контейнеров нет.

                                                                                  Ну так не используйте дефолтный, кто вас заставляет. Зачем кричать сразу.

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

                                                                                  Ага, изоляция от хоста прекрасно работает. Изоляция контейнеров прекрасно работает, когда у каждого свой IP и нет проблем с конфликтами портов. И я специально написал про созданный руками бридж, если вам нужно через DNS разрешение имен контейнеров. Вам бы поменьше за других додумывать и обзываться бежать.
                                                                                    0

                                                                                    А если у приложения нет портов? Например, у меня zigbee стек, или ble?


                                                                                    Вам CRUD на TCP сожрал всё.

                                                                                  +3

                                                                                  вы находитесь в каком-то уютном мирке мегабитных коннектов.


                                                                                  Если у меня приложение генерирует несколько гигабит/с ICMP на почти рандомные адреса, то следует ли мне его пропускать через iptables, или --net=host всё-таки более разумное решение? (Приложение полностью легитимное и конкретному IP достанется не больше 3-5 ping'ов за 5 минут, плюс мы уважаем abuse'ы и блеклистим IP, которые нам не нужны).


                                                                                  На самом деле есть ещё масса причин для net=host. Например, потому что проект не на k8s/docker, а docker используется только для запуска приложений в контейнерах (например, графаны).


                                                                                  Или потому, что кто-то должен мониторить хосты под k8s, и метрики лучше собирать oob методом (без участия контроллеров).


                                                                                  Причин много, и вы смотрите на свой продакшен и не видите их. Чужие продакшены другие.


                                                                                  Просто представьте себе, например, IoT, где надо слать сетевой трафик (например, zigbee) — и как вы это завернёте в докер без net=host?

                                                                        0
                                                                        Это большая проблема, и люди уже начали потихоньку решать её, используя DSL-и Kubernetes на языках Kotlin, даже Typescript. Есть такой проект Pulumi, есть Amazon-овский проект EKS – хотя он больше ориентирован на Amazon; Pulumi – это такой Terraform, только на Typescript.

                                                                        Можно подробнее про EKS в этом аспекте?
                                                                          +5

                                                                          Базы данных держу в докере только для разработки. После того как на продакшине начала разрушаться PostgreSQL база (которая практически неубиваема если не на докере) больше не рискую.


                                                                          История с к8 воспринимается как хорошо проплаченный облачными сервисами хайп. Так как самостоятельно обслуживать к8 практически нереально малыми силами, то нужно покупать облако с к8 и остаться с ним навсегда.


                                                                          Пока что мало нахожу отличий по функционалу от nomad (кроме красивой админки). Скорее наоборот, в nomad можно найти решений поболее (например с теми же базами данных которые не обязательно тулить в контейнер). Только вместо загадочного монстра (к8) для работы nomad нужно скопировать (именно скопировать) один исполняемый файл.

                                                                            +2

                                                                            Что значит "начала разрушаться"? Работала, но не совсем?

                                                                              0

                                                                              Такая была странная ситуация. Я меняю записи в таблицах а из мнений нет. Как будто бы я работаю в транзакции и она не коммитится. Потом все вообще перестало работать. Перед этим был рестарт контейнеров. Я для себя это объявил тем что какие то файлы необходимые для восстановления после сбое находились не в файловой системе а внутри контейнера и разрушились. Либо еще вариант что слоеная файловая система использует не такие железобетонные операции сохранения как это делает постгрес на хвостовой машине в результате чего их вероятность разрешения существенно выше. Кстати аналогичное слышал от знакомого очень крутого DevOps только про MySQL

                                                                                +1

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

                                                                                  +1
                                                                                  А еще есть простое правило: рутовая файловая система самого контейнера должна быть установлена в r/o при запуске.
                                                                                  И /tmp тогда — просто точка монтирования тома с хоста.
                                                                                    +1

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


                                                                                    1. независим от user id (потому что оркестратор всегда может айди перемаппить и мы должны быть готовы к этому)
                                                                                    2. не гадить себе под ноги. Т.е. рассчитываем на R/O файловую систему. А то тот же пайтон — начинает компилять py в pyc, выкачивать ML модели на эфемерный слой, а потом ловишь веселые спецэффекты.
                                                                                      и куча еще всяких нюансов, что описаны и не описаны в 12 факторах
                                                                                      0
                                                                                      Вот с моделям мы наоборот намеренно пошли на такое решение и все нравится. Модели очень большие, класть их в контейнер нереально. Положили на S3, при старте под закачивает их себе в ФС, загружает в память и удаляет. Сейчас поднимем хранилище для подов, может будем монтировать эти модели прямо в под, что уберет копирование.
                                                                                        0
                                                                                        Модели очень большие, класть их в контейнер нереально

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

                                                                                          –1
                                                                                          Все реально, только нафиг оно надо. Образы и так долго собираются из-за этого питона, так еще модели туда пихать. Держать миллион версий контейнеров с этим моделями тоже никакого желания.

                                                                                          либо запустился и работает, либо нет

                                                                                          Readiness пробы все решают.
                                                                                            0

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

                                                                                              –1
                                                                                              Ничем они не странные. Когда держишь свой bare-metal кластер, то место на диске тратить на бесполезные копии моделей в каждом контейнере не хочется.
                                                                                              А рединес пробы именно из той самой оперы. Вы говорили про бинарность работы подов — либо запустился, либо нет. Так вот рединес проб эту бинарность дает. Пока модель не выкачалась под не запустился, все просто и понятно. Мне сложно распарсить еще что-то, если этого не было в вашем посте.
                                                                                                0
                                                                                                то место на диске тратить на бесполезные копии моделей в каждом контейнере не хочется.

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


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

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


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

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

                                                                                                  0
                                                                                                  потому что на ноде лежат только те образа, которые сейчас нужны, с нужными версиями моделей

                                                                                                  Если не принимать специальных мер на ноде лежат все образа, когда-либо использовавшиеся на ней.

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

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

                                                                                                      0

                                                                                                      Он же без cadvisor не работает вроде как

                                                                                                        0

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

                                                                                                          0

                                                                                                          Отстал, хорошо если так...

                                                                                                    0
                                                                                                    Тут видимо сказывается, что мы в bare-metal кластере со своей локальной сеткой быстрой, со своим хранилищем под поды и образы контейнеров. У нас другие сложности и запросы. В интернете конечно несколько по-другому надо думать над всем этим.