Компания Google представила (http://opensource.googleblog.com/2017/11/container-diff-for-...) утилиту container-diff (https://github.com/GoogleCloudPlatform/container-diff), предназначенную для изучения различий между несколькими образами контейнеров или для анализа состава образа. Код утилиты написан на языке Go и распространяется (https://github.com/GoogleCloudPlatform/container-diff) под лицензией Apache 2.0.
Утилита позволяет оценить изменения в образе и представить результат сравнения в наглядном виде, удобном для восприятия человеком и учитывающем сведения о пакетах, с которыми связаны выявленные изменения. Для интеграции с другими приложениями вывод также может быть оформлен в формате JSON. Сontainer-diff может отдельно выводить различия в системных пакетах, пакетах с модулями и библиотеками, используемыми в приложениями, или в произвольных файлах из состава образа. Например, можно отдельно оценить изменения, связанные с дистрибутивом Linux, и пакетами Python и Node.js, установленными через pip или npm.Образы для сравнения могут задаваться как в виде ссылки на на локальный или удалённый демон Docker, так и в форме tar-архива (например, можно сравнить образы на локальной системе и внешнем сервере без их ручного копирования). Кроме выявления различий утилита также может быть запущена в режима анализа одного образа, при котором выводится отчёт о составе образа со списком пакетов и файлов, их версий и размера, а также изучается история изменений.
URL: http://opensource.googleblog.com/2017/11/container-diff-for-...
Новость: http://www.opennet.dev/opennews/art.shtml?num=47588
Google открыл код ктилиты для сравнения контейнеров docker. Всего лишь только docker. Или сейчас уже других контейнеров не бывает? Быстро же хипстота заграбастала название.
это де-факто уже стандарт для SMB контейнерезации, детка. если по поводу менеджмента еще возникают терки, то по поводу docker/cgroups уже нет.
Для деток может уже и стандарт :)
А чаво там у взрослых дяденек и старичков для контейнеров? Опенвз? До чего ж приятно быть дитём!
Ох уж эта молодёжь. Открою небольшую тайну - cgroups - это не заслуга докера. Докер всего лишь использует этот механизм ядра. А точнее, он использует механизмы lxc.Проще говоря - докер - узкоспециализированная обёртка над частью функционала lxc.
Так что со своим де-факто стандартом и другими умными словами сходи пока и поучи ещё матчасть.
И что? Все пользуются докером потому что это удобно, и в нем за тебя решили все вопросы и сделали все костыли прямо в продукте, но ты продолжай употреблять низкоуровневую базу.
Не говори за всех. Я не пользуюсь, как и миллиарды других.
Ссылку на статистику.
Для чего тебе статистика? Чтобы записать меня и других во все? И доказать мне, что я - не я? Ты вообще думать умеешь?
Для того, чтобы подкрепить свои заявления про миллиарды.
На Земле 7 млрд людей. Все пользуются докером? Докажи, предъяви статистику, болтун.
Не все. Я пользую rkt.
Все это знают, дядя великовозрастный. Суть стандартизации докера в наличии экосистемы для удобного создания образов и их распространения.
> Все это знают, дядя великовозрастный. Суть стандартизации докера в наличии экосистемы для
> удобного создания образов и их распространения.Ты щас сядь, чтобы не упал когда узнаешь что есть сервисы на контейнерах и без docker, щенок
Дядь, ты чего подорвался? Я думал, ты взрослый и адекватный, а ты на самом деле анонимный мусор.
CRI-O - вот что дяди будут использовать в скором времени
Ну так сделай для других, нытик. По ссылке на репозиторий ясно написано, что этот инструмент для докера.
по ссылке-то написано. А вот писателю новостей на опеннете хорошо бы быть в теме и не считать все контейнеры докерами.
> Google открыл код ктилиты для сравнения контейнеров docker. Всего лишь только docker.
> Или сейчас уже других контейнеров не бывает?к сожалению, поляна загажена по колено. При слове "контейнер" всем представляется именно эта дрянь - как там ниже по тексту - "пакетные менеджеры ниасилены, запустил make install, догадайтесь откуда и сколько какого дырявого хлама он мне понатащил".
а для чего нужны эти докер контейнеры ?
Чтобы писать о них статьи.
в контейнерах очень удобно деплоить приложения.если раньше, для того, чтобы 100% быть уверенным, что во время установки модулей языка на продакшн, мне нужно было сделать пакеты для всех моделей приложения в формате пакетного менеджера дистрибутива (dev, rpm), то теперь я могу использовать пакетный менеджер языка для установки модулей внутри контейнера, далее протестировать контейнер, и потом вываливать его в хоть сто продакшнов.
далее решения вроде kubernetes позволяют удобно масштабировать приложения, а решения вроде consul его потом находить.
более того, я могу больше не делать дебки и рпмки, а просто сделать make install внутри контейнера, а предложеный в заголовке новости инструмент поможет мне посмотреть , какие же файлики были установлены. вроде rpm -ql
> в контейнерах очень удобно деплоить приложения.
> если раньше, для того, чтобы 100% быть уверенным, что во время установки
> модулей языка на продакшн,случайно запостил. так вот, если раньше, для того, чтобы 100% быть уверенным, что во время установки модулей языка на продакшн не случится ничего плохого ...
> случайно запостил.ты "сломал продакшн" во время доказательства что теперь сложнее сломать продакшн
Ну зачем ты так жестоко? Он ничего не сломал. Он просто не знает, что такое продакшн за пределами стартапа из пары-тройки человек.
конкретно kubernetes позволяет писать тебе статьи и рекламные мурзилки, а потом вендорлочить результат. Остальное все так.
>>мне нужно было сделать пакеты для всех моделей приложенияпростите, вы сисадмин или программист ?
>>далее решения вроде kubernetes позволяют удобно масштабировать приложения
что значить "удобно масштабировать"?
> простите, вы сисадмин или программист ?Сейчас многие переходят на философию DevOps, в рамках которой как раз и получили широкое распространение Докера Уубирнетисы. И в рамках данной философской системы ответить на Ваш вопрос может быть так же сложно как на вопрос "Вы уже перестали пить коньяк по утрам?".
> в контейнерах очень удобно деплоить приложения.
> если раньше, для того, чтобы 100% быть уверенным, что во время установки модулей языка на продакшн,Давно прикладушки стали системнозависимые? Может руки?
> а для чего нужны эти докер контейнеры ?Твой продукт в докере будет 100% рабочим у заказчика, какой бы хлам у него в системе не стоял, твой образ уникальный.
ОО.. Линуксяторы не осилили LSB ?
> ОО.. Линуксяторы не осилили LSB ?Вот не надо нас к этим быдлoкoдepaм пeхaпeшнегам относить.
Это мусор пришедший из мира Вантуза: "Не работает - переустанови венду"
Напомнило мне отмазку - "у меня на локалхосте всё работает" )))
чтобы жрать память, циклы cpu и место на диске.
> чтобы жрать память, циклы cpu и место на диске.оверхед? в своё время и про ксен, квм и прочую виртуализацию так говорили.
Контейнеры нужны всего для двух вещей:
Когда тебе нужно динамически изменять количество работающих приложений согласно какой-то логике. Для этого ещё нужна какая-то система оркестровки, вроде Kubernetes или Mesos/Marathon.
Когда тебе нужно какое-то приложение или пакет приложений и при этом не хочется заниматься их установкой настройкой, а потом вычищать всё это дело из системы.P.S. Это без учёта потребностей хостингов
> Когда тебе нужно динамически изменять количество работающих приложенийчитай - когда автор ниасилил еще и управление ресурсами (иначе бы тебе было нужно изменять не количество каких-то там "приложений", а количество физических/виртуальных хостов, потому что изменять-то его надо только в одном случае - когда уперлись в cpu/сокеты/диски)
> Когда тебе нужно какое-то приложение или пакет приложений
и ты согласен общаться с ними через stdin/stderr, ага?
> и при этом не хочется заниматься их установкой настройкой, а потом вычищать всё это дело из
> системы.у нас же ни пакетных менеджеров нет (а, ну да - обычно эти "приложения" написаны на чем-то, что имеет свой, доморощенный, ни с чем несовместимый), ни средств контроля системы.
Вот притащить другую неизвестно чью систему с неведомым зоопарком внутри целиком - эт мы готовы.> Это без учёта потребностей хостингов
хостингам ваши дыряводокеры, каждые пять минут рут на хосте, нахрен не нужны.
хостинги используют либо "глубокую" контейнеризацию c fine-grained разделением ресурсов (openvz), либо вовсе аппаратную изоляцию (xen,kvm - оба, по сути, надстройки над qemu уже сотню лет, как, кстати, и неопен-virtuozzo) - последняя нынче более востребована в том числе потому, что openvz несовместима с модными контейнерами.интел вон даже уже придумал как внутри такой виртуализации запускать контейнер- если юзер идиот в терминальной стадии и требует именно контейнер докера(кого ж еще).
Я вижу, с юзеркейсами у вас школе туговато.> читай - когда автор ниасилил еще и управление ресурсами (иначе бы тебе было нужно изменять не количество каких-то там "приложений", а количество физических/виртуальных хостов, потому что изменять-то его надо только в одном случае - когда уперлись в cpu/сокеты/диски)
Например прошла реклама и в систему пошло большое количество запросов. При этом наплыв спадёт а за простаивающие ресурсы платить не хочется.
> у нас же ни пакетных менеджеров нет (а, ну да - обычно эти "приложения" написаны на чем-то, что имеет свой, доморощенный, ни с чем несовместимый), ни средств контроля системы.
Вот притащить другую неизвестно чью систему с неведомым зоопарком внутри целиком - эт мы готовы.
Очень часто это связка из бэка, фронта, базы данных и какого-нибудь редиса. Всё это городить из пакетов, настраивать конфиги, слишком накладно по времени только для того чтобы посмотреть функционал чтобы понять подходит оно тебе или нет.
> хостингам ваши дыряводокеры, каждые пять минут рут на хосте, нахрен не нужны.
Глаза протри. Где я писал про докер? я описывал контейнеризацию в целом.
> Контейнеры нужны всего для двух вещей:
> Когда тебе нужно динамически изменять количество работающих приложений согласно какой-то
> логике. Для этого ещё нужна какая-то система оркестровки, вроде Kubernetes или
> Mesos/Marathon.А зачем докер? Нужна окестровка, да. Смысл контейнеризации и тем более в докере не раскрыт.
> Когда тебе нужно какое-то приложение или пакет приложений и при этом не
> хочется заниматься их установкой настройкой, а потом вычищать всё это
> дело из системы.Да, с поправкой что на локалхосте, а не в продакшне. Либо очень специфичное приложение. Для обычных приложений с перзистент стореджом, логами, SLA к примеру, проще нормально развернуть либо образ использовать, чем обходить грабли докеров.
Это на настоящий момент. Но скорее всего так и не допилят до продового состояния, хайп на спад пошёл.
> А зачем докер? Нужна окестровка, да.нужна _неизвестно_заранее_чего_. Поэтому управлять этим можно только в виде контейнеров.
> Смысл контейнеризации и тем более в докере не раскрыт.
вот в этом и смысл. Ну и еще в том, что разработчик кроме своей убунты ничего знать не желает, и его поделка запускается только в ней, плюс стопиццот левых бинарей хз откуда и тристатыщ "модулей" единственно-верной версии, которую нельзя зафиксировать, ибо в самодельном репо очередного чудо-языка об этом не подумали.
Что оно насквозь дырявое, и рассыпатеся от пристального взгляда - разработчику и его менеджерам пофиг, поэтому жрите что дают.
> Да, с поправкой что на локалхосте, а не в продакшне. Либо очень
на локалхосте ты бы еще мог их всех ублажить, в продакшне как раз и приходится обниматься с этим хламом.
> специфичное приложение. Для обычных приложений с перзистент стореджом, логами, SLA к
в том и дело что обычных скоро вообще не останется.
> Это на настоящий момент. Но скорее всего так и не допилят до
им и не надо, это тебе надо. А они завтра новую высосанную из пальца технологию навернут, и все твои контейнеры и их стораджи опять (уже два раза было) превратятся в тыкву, потому что backward compatibility не для них, смузи не ждет!
>> А зачем докер? Нужна окестровка, да.
> нужна _неизвестно_заранее_чего_. Поэтому управлять этим можно только в виде контейнеров.Я управляю и на виртуалках и на железе. В ВМ намного проще чем в контейнере изолировать неведомое и формировать чисиые окружения кстати. Прелесть докеров не раскрыта опять.
> им и не надо, это тебе надо. А они завтра новую высосанную
> из пальца технологию навернут, и все твои контейнеры и их стораджи
> опять (уже два раза было) превратятся в тыкву, потому что backward
> compatibility не для них, смузи не ждет!Пусть высасывают. Рано или поздно кто-то сделает как надо. Концепция правильная. Окружения для неймспэйсов нужны, только в нормальной реализации и без очередной попытки отливать серебрянную пулю.
>> нужна _неизвестно_заранее_чего_. Поэтому управлять этим можно только в виде контейнеров.
> Я управляю и на виртуалках и на железе. В ВМ намного прощеты не знаешь, чего именно тебе надо vm. Потому что разработчик выкатывает на-гора контейнер. Пока ты героически вручную его разбираешь на составляющие, так, тут позапрошлая версия убунты, здесь на нее надо апдейт, тут надо из вот этого репо еще вот эту штуку, здесь запустить языко-зависимый установщик и натащить им то, се, пятое, десято...ой, а этой версии уже нет в репо, как быть, как быть, куды бечь?! Он тебе еще более новую собрал, в окружении от старой она не работает. Тут тебе бы помог гуглодифф, потому что разница в одном-единственном модуле, явно не упомянутом но притянутом зависимостями, но ты гордо бежишь по граблям дальше.
> чем в контейнере изолировать неведомое и формировать чисиые окружения кстати. Прелесть
этим всем мило и прекрасно заниматься, когда этих виртуалок у тебя штук пять. А когда их 500, и надо еще заниматься работой, а не "формировать чистые окружения" заботливо нулевочкой - начинаются опаньки.
> Пусть высасывают. Рано или поздно кто-то сделает как надо.
не, не сделает. industry standard уже. Да и изначально концепция cgroups была горбатой.
Нормальная - у *bsd в jail и у солярки в zones, той и другой больше десятка лет, и никаких тебе "cve-каждыйгод-овердофига: рут в зоне внезапно вылез рутом в хосте", случаи по пальцам одной руки можно пересчитать.
Но никто не наладил массовую выпечку готовых решений для них в виде скрипта, создающего контейнер. И не просто так.
> этим всем мило и прекрасно заниматься, когда этих виртуалок у тебя штук
> пять. А когда их 500, и надо еще заниматься работой, а
> не "формировать чистые окружения" заботливо нулевочкой - начинаются опаньки.Гыыы, виртуалки еще и масштабируются лучше, чем контейнеры. И распределять нагрузку с ними удобнее. Если у тебя 500 контейнеров "занимающихся работой", их нужно по нескольким виртуалкам разложить, как минимум.
Вот если бы ты сказал про динамическое распределение ресурсов, тут есть и плюсы и минусы у контейнеров, но не у докера в частности. Докер и этого не умеет.
Опять мимо, но ближе уже.> не, не сделает. industry standard уже. Да и изначально концепция cgroups была
> горбатой.
> Нормальная - у *bsd в jail и у солярки в zones, той
> и другой больше десятка лет,Linux контейнеры это неймспэйсы, которым, кстати, больше десятка лет. А не cgroups, как почему-то считают хаброэникеи, наслушавшиеся вэбинаров за докер. Не верь им. Cgroups конечно тоже используются для ограничения ресурсов, но это не основное.
> Гыыы, виртуалки еще и масштабируются лучше, чем контейнеры. И распределять нагрузку сконтейнер - ни разу не то что ты подумал. Контейнер - отдельное приложение.
В понятных админу локалхоста приближениях: nginx - один контейнер. php-fpm - второй. неведомый демон приложения к которому тот php лазит - третий. Все вместе - один инстанс. Их таких могут быть (и есть) сотни.
А теперь расскажи мне, как это "масштабируется" в случае, когда вместо тридцати таких контейнеров в одной виртуалке (да, оно обычно еще и в виртуалке) - у тебя будет тридцать виртуалок. Каждая с полным набором - ведро, драйвера с прослойками эмуляторов, кроны-демоны-логгеры-вся общесистемная херня - в каждой отдельная. В системе с микросервисами их очень быстренько будет тридцать три (и по прежнему сотни хостов). Все еще "масштабируется"?> ними удобнее. Если у тебя 500 контейнеров "занимающихся работой", их нужно
> по нескольким виртуалкам разложить, как минимум.по пятистам, ага. Потом налаживать между всеми ними передачу данных. Потом каждую отдельно мониторить и обслуживать.
И все вручную, какой еще kubernetes, это слишком по хипстерски, мы так не можем, от него смузей воняет (к тому же угадай, в каком виде он поставляется).> Linux контейнеры это неймспэйсы, которым, кстати, больше десятка лет. А не cgroups,
cgroups и того старше - это подарок из openvz, без которого вся система была неработоспособна в принципе - поскольку любой взбесившийся контейнер может сожрать все, до чего дотянется.
проблема что обе конструкции оказались переусложненными и ненадежными в принципе. virtuozzo в конечном итоге сдалось и пошло за qemu, как все. И проиграло. Потому что хипстеры выпилили таки из того что было - то что было им удобно.
>[оверквотинг удален]
> приложение.
> В понятных админу локалхоста приближениях: nginx - один контейнер. php-fpm - второй.
> неведомый демон приложения к которому тот php лазит - третий. Все
> вместе - один инстанс. Их таких могут быть (и есть) сотни.
> А теперь расскажи мне, как это "масштабируется" в случае, когда вместо тридцати
> таких контейнеров в одной виртуалке (да, оно обычно еще и в
> виртуалке) - у тебя будет тридцать виртуалок. Каждая с полным набором
> - ведро, драйвера с прослойками эмуляторов, кроны-демоны-логгеры-вся общесистемная херня
> - в каждой отдельная. В системе с микросервисами их очень быстренько
> будет тридцать три (и по прежнему сотни хостов). Все еще "масштабируется"?1. Путаешь масштабирование и утилизацию ресурсов. Приложение может использовать меньше ресурсов, но при этом слабо масштабироваться. Гугли, разбирайся, я на сегодня устал от просветительской деятельности.
2. Если приложение нагружено, то оверхэд на систему и виртуализацию незначительный. А бездействующих контейнеров обчно да, можно больше и быстрее наплодить. Хотя и тут есть нюансы, но тебе еще рано обэтом.
3. Докер тоже ресурсы потребляет если что. Только голое железо, только хардкор. И если ты не знаешь, а ты наверняка не знаешь, почти во всех крупных конторах существенная часть прода на голом железе. У некоторых весь прод.> по пятистам, ага. Потом налаживать между всеми ними передачу данных. Потом каждую
> отдельно мониторить и обслуживать.
> И все вручную, какой еще kubernetes, это слишком по хипстерски, мы так
> не можем, от него смузей воняет (к тому же угадай, в
> каком виде он поставляется).То есть ты не в курсе что докеры чаще в виртуалках деплоят, независомо от оркестратора?
> А зачем докер? Нужна окестровка, да. Смысл контейнеризации и тем более в докере не раскрыт.Докер просто модный и раскрученный, но архитектура его, особенно в плане безопасности ужасна. Но она побудила сделать стандарт контейнеризации по которому делаются rkt и LXC например. Например тот же Kubernetes работает с rkt.
Контейнеры вышли из подхода когда ты собираешь своё приложение в определённую папку, кладёшь туда же все необходимые библиотеки, для непривилегированного пользователя переопределяешь переменные окружения и запускаешь приложение под этим пользователем. В таком виде приложение хорошо переносимо, запаковал папку в архив, перенёс на другую машину, развернул, переопределил переменные окружения среды и готово.
Но подход не всегда удобен разработчикам когда нужно таскать кучу библиотек и зависимостей, проще же понаставить их из пакетов и забыть что ставил)
Вот для того чтобы можно было понаставить кучу пакетов и не заботиться о зависимостях и используется контейнеризация. А докер предоставляет удобный интерфейс и репозиторий с готовыми контейнерами, чем экономит время разработчикам, этим и популярен.> Да, с поправкой что на локалхосте, а не в продакшне.
Да, я имел ввиду на локалхосте.
> Это на настоящий момент. Но скорее всего так и не допилят до продового состояния, хайп на спад пошёл.
Ну я наблюдаю, что даже самые заскорузлые проекты начинаю переходить на микросервисы. А это немножко другая архитектура где ключевым узлом являются прокси сервера на входе, несколько узлов фронта, а остальные компоненты прода динамически поднимаются/опускаются.
В том что конкретно докер будет долго жить я и сам не верю, а вот что контейнеры вообще всерьёз и на долго, так это скорее всего.
> Ну я наблюдаю, что даже самые заскорузлые проекты начинаю переходить на микросервисы.
> А это немножко другая архитектура где ключевым узлом являются прокси сервера
> на входе, несколько узлов фронта, а остальные компоненты прода динамически
> поднимаются/опускаются.ты не поверишь, но для этого как раз не нужен был докер - и контейнеры вообще.
вся эта хрень прекрасно жила на физических хостах ровно в такой же схеме - балансеры на входе, морды на выходе, в середине - мешанина общающихся между собой сервисов, один жрет память, другой что-то терабайтами пишет в логи, третий падает по sigbus, четвертый запускает запрос к базе и часами ждет ответа. Этих компонент можно было добавлять-убавлять точно так же.
Проблема что это было жутко неудобно программистам - их заставляли оформлять свои чудеса принятыми в прод-системе пакетами, любая версия чего угодно, отличающаяся от дистрибутивной "устаревшей на пять лет", требовала обоснования, пакетирования и разбора конфликтов.
И полный пэ настал с новыми модными языками, каждый из которых норовил нагадить в $HOME, потому что по другому авторы работать не умели.
>> изменять количество работающих приложений согласно какой-то логике.ага так всё просто, как один выше господин утверждал об "простом масштабировании" :)
возьмите два докер образа с друпалом и я посмотрю как вы будете решать вопросы с синхронизацией.
Разворачивать проекты где угодно одной командой.
на attiny13 мне развернешь?
Смотря какой бюджет у хотелки.
> а для чего нужны эти докер контейнеры ?кто-то тут когда-то дал удачнейшую ссылку на правильный ответ:
https://habrahabr.ru/post/277699/#comment_8781057Докер — это отличная возможность переложить проблемы поддержания актуальных версий системных библиотек (того же самого libssl) с поставщиков ОС и сисадминов на никого. После того, как проблемы безопасности окружения переложены на никого, скорость внедрения и эксплуатации заметно возрастает, ведь производительность никого ограничена только супремумом пофигизма, а он, в свою очередь, верхней границы не имеет.
(на самом деле еще и кучу других проблем заодно, не только библиотек)
собственно, то что гуглю (!) понадобилось, по сути, средство быстрого _реверс_инжиниринга_ контейнеров (а что еще это, по-вашему? Именно средство быстро узнать, что же тут обезьянка наколбасила - в случае, когда у нее самой спрашивать просто бесполезно.)
>>Докер — это отличная возможность переложить проблемыИ тем самым убить понятие сисадмина
>>(а что еще это, по-вашему? Именно средство быстро узнать, что же тут обезьянка наколбасила - в случае, когда у нее самой спрашивать просто бесполезно.
ну и собственно вопрос, зачем всё в кучу складывать, а потом ещё придумывать инструментарий для разгребания этой кучи?
>>>Докер — это отличная возможность переложить проблемы
> И тем самым убить понятие сисадминаон теперь называется devop, да. Не удивлюсь, если в списке требований окажется уметь программировать на go.
сисадмины - это что-то из области it-отдела, ну тот чувак, который так забавно картридж у принтера вчера тряс.> ну и собственно вопрос, зачем всё в кучу складывать, а потом ещё
> придумывать инструментарий для разгребания этой кучи?так там без тебя уже все сложили. зарплата программиста больше твоей, поэтому экономия его времени важнее. А ты беги, разгребай.
> он теперь называется devop, да.ага завтра он будет решать проблемы масштабирования, агрегацию логов, аналитику, настраивать сеть, а сис админ пусть втыкает телефонные кабеля и трясёт картриджи.
> зарплата программиста больше твоей, поэтому экономия его времени важнее.
ага до первого "ботлнека", программисты давно уже на себя многое взяли, вот и придумывают как всё это разгребать.
>Код утилиты написан на языке Go и распространяется под лицензией Apache 2.0.Google не осилил утилиту diff.
>>Код утилиты написан на языке Go и распространяется под лицензией Apache 2.0.
> Google не осилил утилиту diff.иксперт опеннет во всей красе
Нормальный эксперт кстати. Расскажи, что из обозначенных сверхвозможностей сабжа я не сделаю при помощи стандартного окружения?
> Нормальный эксперт кстати. Расскажи, что из обозначенных сверхвозможностей сабжа я не сделаю
> при помощи стандартного окружения?за _ограниченное_ время - ничего, вероятно? Кстати, насколько хорошо ты владеешь "стандартными окружениями" питона, руби, php, перл, go, rust... положим, хватит - во всех ты знаешь как побыстрому глянуть версии?
никаких "сверхвозможностей", банальная задача - где-то на проде крутится контейнер версии 0.0.0.1... не, не так - где -то на проде крутится контейнер версии 254. Где-то в другом датацентре на проде крутятся контейнеры версии 255. При попытке попапгрейдить первый все падает, быстро разберись, чем они отличаются.
(никто не обещал, что они мелкие, и что отличие не в образе пятнадцатого уровня вложенности, ага)
Не "чем отличаются их докерфайлы", это мы без тебя знаем, а какую неведомую херь притащил с собой воон тот апдейт.собственно, это все описано по ссылке на гугль, которую ты, конечно же, не пошел прочитать.
> за _ограниченное_ время - ничего, вероятно? Кстати, насколько хорошо ты владеешь "стандартными
> окружениями" питона, руби, php, перл, go, rust... положим, хватит - во
> всех ты знаешь как побыстрому глянуть версии?хэло гугл, как мне посмотреть версии модулей питона -- 'pip list'.
Уфф, как сложно.
> Не "чем отличаются их докерфайлы", это мы без тебя знаем, а какую
> неведомую херь притащил с собой воон тот апдейт.И не узнаешь и сабж не поможет
> собственно, это все описано по ссылке на гугль, которую ты, конечно же,
> не пошел прочитать.У меня есть суперспособность фильтровать шлак за несколько секунд, не тратя времени на чтение и на разбирание почему этот мусор на Go не работает как заявлено.
> хэло гуглто есть - не знаешь. Я так и предполагал.
дальше, собственно, обсуждать нечего, ибо не с кем.
> У меня есть суперспособность фильтровать шлак за несколько секунд,
суперспособности управлять миром незаметно для санитаров у тебя, случайно, нет?
>> хэло гугл
> то есть - не знаешь. Я так и предполагал.
> дальше, собственно, обсуждать нечего, ибо не с кем.Не сливайся так быстро, я добью тебя танцем. Расскажи как ты этим инновационным инструментом от гугла сравнишь контейнеры, в который не Руби с Питоном, а например Эрланг/OTP с модулями? Я не читал, но почему-то знаю, что сравнивать модули OTP оно не умеет. А если конфиги надо сравнить? А если конфиги доморощенных приложений?
Вот. А я в свой десятистрочник на баше с диффами, написанный за 15 минут на левой коленке, добавлю одиннадцатую и двенадцатую строчку.
А если чего-то не знаю, это не повод обмазываться очередными гавяшками на Go. Cпрошу у дэвов, для которых контейнер.
> Расскажи как ты этим инновационным инструментом от гугла сравнишь контейнеры,
> в который не Руби с Питоном, а например Эрланг/OTP с модулями?а вот тут я почти уверен, что не ошибусь в несуществовании в реальном мире подобной херни.
Впрочем, если даже она существует - добавить в уже работающую программу один частный случай гораздо проще, чем закатывать солнце вручную.> А если конфиги надо сравнить?
Дай угадаю снова: ты не то что никогда не работал с контейнерами, ты вообще дальше локалхоста с пятью-десятью тщательно вручную отполированными глюкалами не вылезал. Конфиги руками раскладываешь, да?
> А я в свой десятистрочник на баше с диффами
о б-же мой... творец десятистрочников на баше...
дифами - чего? эта штука вовсе не дифы текстовых файлов сравнивает, если до тебя еще не дошло. Это мы и без гугля умеем сделать.
И она нихрена не десятистрочная.> А если чего-то не знаю,
то это повод не болтать, о том в чем совсем не пертришь, ага. Можно либо за умного сойти, либо тихонечко сходить, наконец-то, посмотреть на еще одну технологию.
>> Расскажи как ты этим инновационным инструментом от гугла сравнишь контейнеры,
>> в который не Руби с Питоном, а например Эрланг/OTP с модулями?
> а вот тут я почти уверен, что не ошибусь в несуществовании в
> реальном мире подобной херни.Здесь ты меня впервые в тупик поставил. Не знаю что ты имеешь в виду. В несуществовании чего ты уверен? =)
>> А если конфиги надо сравнить?
> Дай угадаю снова: ты не то что никогда не работал с контейнерами,
> ты вообще дальше локалхоста с пятью-десятью тщательно вручную отполированными глюкалами
> не вылезал. Конфиги руками раскладываешь, да?ты квасишь чтоли сейчас?
> дифами - чего? эта штука вовсе не дифы текстовых файлов сравнивает, если
> до тебя еще не дошло. Это мы и без гугля умеем
> сделать.Дифы вывода консольных команд. Ты вообще Юникс и Юникс-лайк системы видел?
> И она нихрена не десятистрочная.
Вот это и проблема. Функциональность-то десятистрочная.
Типичный диалог в Гугле между каким-то менеджером и неким директором:
- Дайте миллион на новый инновавационный проект
- Зачем он нужен?
- Это гиперконвергентная облачная контейнерная аггрегация, позволяющая проактивно добиваться синергии... (еще 100500 базводрдов)
- Но по сути это давно уже изобретено, никому не нужно и забудется через год как предыдущие более ваших 9000 проектов.
- Мы будем писать на Go.
- Вот ваш миллион.
> Типичный диалог в Гуглес точки зрения гордого админа локалхоста, которого не то что в гугле, а в крупной роиссьской компании не ждут.
на "гордых админах локалхоста" строился и гугл и "крупные" РФ компании, которых в них уже давно нет, одни студенты (х*як, х*як и в продакшен).
> на "гордых админах локалхоста" строился и гугл и "крупные" РФ компанииони с тех пор либо поумнели и кое-чему научились, либо интенсивно трясут картриджи в лавках по торговле китайской лапшой, в свободное время рассказывая мне про "масштабирование виртуалок", в этом и разница.
и да, в гугле гадюшник еще тот, если что, инфа из первых рук.
Но совсем-совсем иначе устроен, чем мечтается местным шаманам, вручную полирующим виртуалочки. Поэтому гугль там, а они - в жопе.денег под баззворды не дадут нифига. Разрабатывать на чем _принято_ и как принято - _заставят_, или придется очень-очень попотеть, объясняя, почему ты не такой как все (а те кому объясняешь - сцуко умные, на...ть не получится). Сейчас принято на go - значит, будешь на go.
>>Поэтому гугль там, а они - в жопея не в гугле и не в жопе, а вы где ?
>>Сейчас принято на go - значит, будешь на go.
согласен, когда работаешь на дядю Сэма, в любых областях так
>>или придется очень-очень попотеть, объясняя, почему ты не такой как все
глупец тот, кто глупцу указывает на его глупости.
если свести всё к деньгам, то на торговле я больше заработаю, чем вы, работая в гуглэ, и нафиг мне не сдалось "изменять мир к лучшему"
> если свести всё к деньгам, то на торговле я больше заработаюбольше Брина - точно-точно заработаете?
А если нет - то дам на прощанье один почти бесполезный совет: не считайте себя умнее ни его, ни нанятых им.
Они там глупцов не нанимают, им не надо строить иерархию я-начальник, ты-дурак. Им надо умненьких, и они имеют возможность выбирать по всему миру.
>>больше Брина - точно-точно заработаете?деньги того же Пабло до сих пор откапывают )))
>>не считайте себя умнее ни его, ни нанятых им
а как себя считать умнее всех, если тебя не оценит умней тебя человек ? парадокс
>> им не надо строить иерархию я-начальник, ты-дурак
всё зависит от того кем ты хочешь быть, дураком среди начальников, или начальником среди дураков
>>Им надо умненьких, и они имеют возможность выбирать по всему миру.
послушненьких, с пирожком во рту и кнутом в заду, чтоб не забывали кому служат ) - реалии
>> потому что backward compatibility не для нихВот это печалит, да.
самое забавное в таких тредах, что практически всем присутствующим критикам в самое ближайшее время придется осваивать эту ненавистную им технологию, чтобы продолжать зарабатывать свои деньги :)
> самое забавное в таких тредах, что практически всем присутствующим критикам в самое
> ближайшее время придется осваивать эту ненавистную им технологию, чтобы продолжать зарабатывать
> свои деньги :)пока жив человек будут и жить деньги, а способов заработать их, также плодятся с каждым днём как и ваши все эти технологии
> самое забавное в таких тредах, что практически всем присутствующим критикам в самое
> ближайшее время придется осваивать эту ненавистную им технологию, чтобы продолжать зарабатывать
> свои деньги :)предположим кому-то придется, но от этого ни докер не перестанет быть глючной кучей фекалий, ни ты не поумнеешь
зря злорадствуешь
а чё сразу злорадство ? по мне так - критика чистого разума.