Желание завести две ноды на одной машине появляется, если на машине, например, 64гига памяти… вот тут есть нюансы при использовании эластиком памяти больше 32 гигов habr.com/ru/company/yamoney/blog/419041
Ошибаться могут все. Если бы Вы читали, например, про официальный образ для MediaWiki — как народ плюется от этого официального и использует собственные кастомные взамен — Вы бы не были столь категоричны.
Kubernetes — это уже тот уровень, где решаются не просто задачи упаковки, а задачи балансирования нагрузки и все прочие радости высоконагруженных систем (иначе зачем этот Kubernetes?), там и подход другой — дешевле развернуть контейнер целиком за пару секунд, когда в динамике будет расти нагрузка, чем ставить цепочку rpm-пакетов.
Мы не поставляем продукты по всему миру, поэтому нет проблемы сборки под несколько операционных систем. А то, что Вы описываете — это как раз то, что пытались решить введением snap-пакетов, и в части случаев это оправдано, в части — совсем нет. Ваш пример с библиотеками питона — это именно тот самый случай, когда полный слепок не то что оправдан — он просто необходим. И тут я Вас всячески поддерживаю.
Про логи — каждому свое, кому что больше нравится. Логи от больших распределенных сервисов мы храним в эластике (не в том, что неудачно пытался жить в докере, а в нормальном кластере без всяких лишних контейнеров), а для логов простых сервисов посмотреть файл все-таки проще. Но тут, как я уже сказал, о вкусах не спорят.
Шелл внутри докера? Чего там не хватает?
Не хватает возможности нормально отлаживать контейнер, если с ним творится что-то нехорошее. При использовании полноценной машины там обычно есть достаточно инструментов для мониторинга, в случае же контейнера, как Вы сами заметили, есть желание урезать его по максимуму со всеми вытекающими последствиями.
имеется базовый образ с java и туда попросту инжектируется уже собранный jar или war файл.
А чем хуже иметь полноценный сервер, куда так же просто раскладывается jar?
Тем более что сам jar — это уже готовый контейнер, а java-машина и так управляет ресурсами (на то она так и называется Java Virtual Mashine, JVM)? Зачем вообще в такой связке нужен докер? Мне кажется, что это просто лишний слой.
Мы очень любим ElasticSearch, и, на самом деле, он очень стабилен при правильной конфигурации. Докер для него — действительно не то место, где он себя будет хорошо чувствовать. На примере нашего кластера эластиков замечу, что его уж точно не надо перегружать раз в сутки, он может работать без перезегрузки месяцами. Тут главное не забыть его мониторить — как и любой нагруженный сервис с несколькими нодами.
Не соглашусь с Вами только по поводу того, что rpm/deb + systemd — это сложнее. На самом деле это проще. Сложность здесь кажущаяся, потому что про докер Вы слышите в публикациях и на конференциях чуть ли не каждый день, а про rpm — тишина. И поэтому те, кто пришел в разработку не так давно, вынуждены выбирать то, что на виду. Если же подходить к выбору осознанно — то у каждого варианта есть своя сфера, в которой применение соотвествующего инструмента оправдано.
Баба Зина может прочитать одно объявление, ну 100, но несколько миллионов даже 50 баб Зин не осилят.
Кстати, пробовали одно и то же объявление давать трем разным «бабам Зинам». Представте себе, они дали 3 разных ответа по классификации ремонта. Вопрос: какой из трех верить?
А Вы в рельности такие объявления встречали или это чисто умозрительный пример? Люди продают и стараются адекватно (насколько умеют) описать ситуацию, а не постебаться. Хотя такого типа бред попадается: «Продам лужу. Большого размера. Много людей поместиться может. Очищенная, фильтрованная. Всей семьей проверяли! Гарантия возврата 15 минут. В комплекте с лужей идет: 1)Бесплатная вода (первые 4 дня, потому что замерзнет скоро), 2)Жена (беременная), 3)Сосед-вейпер+жижа в подарок, 4)Мусорный бак. Лужа просвященная священником, но есть сосед сектант, так что из лужи выходить не стоит. По этому и снизили цену до 500000.»
Но таких мало, так что особого вреда они вряд ли нанесут.
Чтобы современный стиль жизни отразился на генетике, надо еще не одно тысячелетие, чтобы человеческий конструктив перестал быть заточен под физические нагрузки.
Поделитесь пожалуйста опытом, что НЕ нравится в этой дорожке.
А что, наоборот, очень удобно и хорошо. И на что обратить внимание.
Как раз занимаюсь поиском похожего девайса для себя, было бы интересно узнать Ваше мнение.
Не стоит при этом забывать, что часто нафигаченный ночью код требует трезвого осмысления на утро и потом жесткого багфиксинга или вообще переписывания с нуля.
Сильно не уверен, что нужно прям вот так «изучать 3D», но обычное черчение нужно в обычной жизни. Даже для нетехнического специалиста: элементарно нарисовать, как должна выглядеть кухня. Или набросать окно с размерами, чтобы заменить его (как-то видел, как человек хочет объяснить расстановку и ну никак не может это хоть коряво нарисовать — ну вот как его можно понять, что ему нужно?). То, что черчение развивает мышление — это факт, тоже достаточно полезно. К тому же черчение, вернувшись опять же в обычной жизни, это не только 3D, это вообще культура и умение в виде графики объяснить мысль. Чего только стоит правильно и грамотно проставить размеры на чертеже — это тоже как-то надо уметь. Но изучать специфические инструменты для моделирования — это уже не в школе нужно, а тем же инженерам в институте: аналитическая геометрия, Aucocad и т.п., 3D-дизайнерам, соответственно, 3D Studio Max.
Не хватает возможности нормально отлаживать контейнер, если с ним творится что-то нехорошее. При использовании полноценной машины там обычно есть достаточно инструментов для мониторинга, в случае же контейнера, как Вы сами заметили, есть желание урезать его по максимуму со всеми вытекающими последствиями.
А чем хуже иметь полноценный сервер, куда так же просто раскладывается jar?
Тем более что сам jar — это уже готовый контейнер, а java-машина и так управляет ресурсами (на то она так и называется Java Virtual Mashine, JVM)? Зачем вообще в такой связке нужен докер? Мне кажется, что это просто лишний слой.
Что Вы имеете ввиду под унифицированным интерфейсом взаимодействия с любым приложением?
Кстати, пробовали одно и то же объявление давать трем разным «бабам Зинам». Представте себе, они дали 3 разных ответа по классификации ремонта. Вопрос: какой из трех верить?
Но таких мало, так что особого вреда они вряд ли нанесут.
А что, наоборот, очень удобно и хорошо. И на что обратить внимание.
Как раз занимаюсь поиском похожего девайса для себя, было бы интересно узнать Ваше мнение.