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

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

Чини детектор, я вообще не админ, а кодер, и мои знания никуда не девались. К тому же, я топлю за питон-портянки.

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

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

Я собрался обновлять код приложения, а не данные

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

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

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

Тем же самым с теми же уязвимостями, известными каждому скрипт-кидду?

Зависит от твоей квалификации

http://lurkmore.to/Неуловимый_Джо

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

Докером можно сделать плохо, а можно сделать хорошо. Бандлингом можно сделать строго плохо. Ещё вопросы?

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

Какой в жопу десктоп? Кто вообще говорил про десктоп?

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

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

Восхитительно. ЧТД

У тебя никогда не получалось собрать нерабочий контейнер, что ли?

Ты ставишь трояна в качестве операционной системы

Подкинул тебе на обочину мелочи, сходи на курсы повышения квалификации что ли

На 2020 год не существует достоверных способов полного отключения всех бесчисленных механизмов слежения за пользователем и автоматического скачивания софта. То, что ты вроде бы всё поотключал, не значит, что отключил всё. Если же ты намертво всё перекрыл фаерволом, вплоть до исходящих 80 и 443 портов, то не все ли равно, какая там ось у тебя?

Отвечу самоцитатой

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

Надо отличать «имеем дело с тем, что имеем» от «мы всё делаем как надо». И надо говорить, что то, что мы делаем сейчас - полная фигня. Потому что, если мы будем молча это делать, мы никогда не исправимся.

Прохладная история. Только я не увидел, где в ней docker unique функции?

Держу в курсе, спустя N времени у вас в контейнерах каша такая же будет, если не хуже. Потому как проблема от сложности проекта.

Надо

И надо

Кому надо :) ? У бизнеса одни из ключевых критериев - прибыль и риски, а не чего там надо отдельно взятому идеалисту из серверной. Если ты бизнесу начнешь задвигать, что процессы надо на ровном месте лочить под редких специалистов, тебя не поймут. Потому что лишние риски никому не нужны.

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

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

дай угадаю, stateless – дрисня для смузихлебов, настоящие сумрачные мужики делают stateful монолиты и смотрят на хипстеров свысока?

Disnix сильно экспериментальный и вряд ли готов заменить k8s. NixOps тоже сыренький, большинство бэкендов заброшенные и недоделанные, и всем лень их пилить, потому что тот же terraform делает примерно то же самое и уже допилен. Можно, например, собирать образа виртуалок через nix и развёртывать через terraform. Алсо, образа контейнеров тоже можно собирать через nix и развёртывать через k8s. В nixpkgs есть чудесная функция buildLayeredImage, которая делает очень компактные образы для докера. Ещё и дедупликация работает намного лучше, чем с традиционными докерфайлами. Только к одному не могу привыкнуть: собранный образ получается настолько минимальным, что там даже bash и coreutils нет по умолчанию, и nix внутри образа не работает, чтобы можно было для отладки что-то доустановить внутрь живого контейнера. Поэтому вообще непонятно, как такие контейнеры отлаживать, если что-то пойдёт не так. Круто бы иметь возможность примонтировать внутрь живого контейнера нужные пакеты из /nix/store, но пока никто такого не запилил. Или запилил?

слои, порты и оркестрация уровня контейнеров, а не jar-файлов

Мораль басни не в том что докер придет и всех спасет.

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

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

Прошу прощения, я не знал, что ЛОР не околотехнический, а околоделовой форум.

Орки, они как лук - у них тоже есть слои.

Мы захардкодили порты и нам нужно городить костыли, поэтому докер хорошо.

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

дай угадаю, stateless – дрисня для смузихлебов, настоящие сумрачные мужики делают stateful монолиты и смотрят на хипстеров свысока?

Ты рассуждаешь как-то слишком широко, деление stateless/statefull проходит по целой куче разных сфер. Банальная домашняя страничка Wordpress — это stateless сервис на пыхе, и ничего тут плохого нет. Другое дело, что если у тебя ни разу не домашняя страничка, а сервис, который даже со stateless сервисами таки оперирует состоянием через контроллеры кубернета — в итоге за что боролся, на то и напоролся.

епт, ты б хоть посмотрел в интернете как слово stateful пишется перед тем, как на новый раунд выходить

прям квинтэссенция безграмотности, поразительно просто

Disnix сильно экспериментальный
NixOps тоже сыренький
тот же terraform делает примерно то же самое и уже допилен
Алсо, образа контейнеров тоже можно собирать через nix и развёртывать через k8s

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

Круто бы иметь возможность примонтировать внутрь живого контейнера нужные пакеты из /nix/store, но пока никто такого не запилил. Или запилил?

Не знаю.

Итак, суровые админы локалхоста забили оперирующих сотнями серверов сынков помойными тряпками. Душераздирающее зрелище.

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

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

Поэтому вообще непонятно, как такие контейнеры отлаживать, если что-то пойдёт не так.

Для этого есть всякие Sentry и подобные штуки, специально чтобы не заходить в стопицот контейнеров на проде. Если не говнокод, то этого в 95% случаев достаточно для написания тесткейса и починки бага.

Пример в студию, пожалуйста.

Что именно докер не смог решить как «предсказуемую сборку софта»?

У нас все образы собираются предсказуемо, с точностью в 100%.

Что я у себя на рабочем компе написал / протестировал / отладил, что на CI потом закинул и там все работает, что у коллеги тот же образ развернулся и все работает точно так же.

Нет тупых глюков по принципу «у меня такая же левая нога и не болит».

Sentry - это когда твой софт упал с очевидной ошибкой, которая элементарно воспроизводится на локалхосте. Бывают неочевидные ошибки, которые случаются лишь в продакшоне по нечётным дням в полнолуние. Можно неделю гадать на кофейной гуще, а можно влезть через kubectl exec и за пять минут продиагностировать.

Если не говнокод, то этого в 95% случаев достаточно

Это уже из серии «хорошие программисты на C пишут код без ошибок и сегфолтов, Rust не нужен».

Если твой докерфайл начинается со строчки типа «FROM ubuntu:20.04» - результат заведомо невоспроизводим.

Если в твоём докерфайле встречается строчка типа «RUN apt-get update && …» - результат заведомо невоспроизводим.

И т. д.

Строчка типа «FROM ubuntu:20.04» даст мне ОС ubuntu версии 20.04.

Строчки типа «RUN apt-get update && …» дадут один и тот же результат для определенной версии ОС, которую я раньше задал тегом.

Какая требуется точность воспроизведения?

Пока точности воспроизведения хватало для всех наших случаев использования (разработка и развертывание нашего софта). Как в облаках, так и на наших серверах. И я не вижу, на каком этапе и при каких условиях я могу эту точность воспроизведения (версия ОС и окружение, необходимые для работы софта) потерять.

Если нужны подробности, то я могу их найти в dockerfile в открытом доступе.

Если не устраивает тот dockerfile, который в открытом доступе, то я могу написать свой, from scratch.

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

Каждый сам пиротехник своего счастья.

Это все аргументы и примеры?

Если да, то «слив защитан».

p.s. среди bash-скриптов, наскоро собранных архивов и прочей ерунды пиротехники больше ровно в N раз.

Ты путаешь, начал не я.

О, реклама xaassware пошла, все подписываемся.

Но пока что add rootfs / заруливает своей мощностью все. Вкупе с отсутствием пруфов отсутствия майнера в стандартной поставке.

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

В общем, как всегда, ни единого примера, только голословные утверждения «решето, есть варианты лучше, вы все делаете неправильно». Зелень и толстота одна.

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

Не знаю что подразумевается под «начал», но писать откровенную пургу про косты стал точно не автор поста на который ты сослался :) . Собсна, я хотел только поделиться что не так и почему, но если не надо - нивапрос.

Тогда с какой целью это «Во сколько час своей работы оцениваешь?»

Хочешь сказать, что оно не про «10 джамшутов стоят дешевле одного профессионала», а про понты «эта задача недостойна внимания такого специалиста как я»?

Логичнее наверное было бы уточнить у самого автора, а не у меня?

Что именно докер не смог решить как «предсказуемую сборку софта»?

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

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

не удалось решить в общем случае без деградации функционала.

Я прошу прощения, вы про замедление какой-то числовой функции? Или вы так тонко намекнули на интимные предпочтения разработчика?

боится красноглазить

Красноглазить - плохая практика.

Смотря для чего, если это «разово» для получения полезного опыта, то можно.

Проще оркестрировать stateless сервисы

Какие еще очевидные вещи хочешь рассказать?

нужно минимум

Опять ты что-то слышал, но сам не делал. У тебя совершенно неправильные представления о минимуме.

я вообще не админ

Это как-то оттеняет твою некомпетентность?

не все ли равно, какая там ось у тебя?

Мне-то как раз плевать. Я использую докер и в линуксе, и на винде. А судя по вашим высказыванием, для вас оказалось откровением, что виндовый докер умеет в виндовые контейнеры, от чего вы решили заострить внимание на винде. Ну и кому ты этот вопрос задаешь тогда, шизофреник?

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

1. становится воспроизводимым;
2. масштабируется;
3. имеет более предсказуемый результат;
4. снижается порог вход для исполнения задачи.

Я инженер, но я думаю о стоимости своей работы. Если рутину может выполнить младший сотрудник, незачем ее поручать сотруднику, который может выполнить более ценную задачу. Чтобы это понимать, не нужно быть менеджером или бизнесменом, нужно просто ответственно относиться к своей работе.

Пусть местные гуру раскатают k8s, например, по k8s the hard way. Сколько будет стоить эта задача (пусть в часах, если местные инженеры боятся денег)? А сколько будет стоить обслуживание кластера? Джун с кубеспреем раскатает кластер за 15-30 минут, обслуживание кластера зашито с скрипты кубеспрея инженерами, которые не воротили нос от ансибла, например, утверждая, что и баша будет достаточно.

Просто не разобрался, что тебя интересует не техническая сторона вопроса, а доказательство собственной правоты любой ценой. Извини. Конечно, для этого нужна не логика, а черная риторика.

Пусть местные гуру построят здание по всем правилам. Сколько будет стоить эта задача, пусть не в деньгах а по времени? А сколько будет стоить микрорайон? Джамшут зная этажность и планировку соберёт каркасник за пару месяцев.

FTFY

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

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

Именно техническая без оговорок на «у нас это захардкодили, поэтому надо», «у нас некому изучить» и прочее «у нас есть НО и поэтому приходится». Докер за пределами тачки (или кластера отданного на игрища разрабам) разработчика - фу.