Но если копать глубже, но я в статье как раз и озвучивал ситуацию про смену поколений, и поколение приходящих студентов, не зная прошлых наработок и не имея достаточно опыта, реализует деплой в виде простых скриптов или вообще вручную. Посмотрите на результаты опроса: деплой через FTP или самописными скриптами отнюдь не на последнем месте. Т.е. все делается, на самом деле, с минимумом усилий. И чтоб сделать качественный скачок — нужны мотивированные люди и опыт.
Вы много встречали джуниоров, которые грезят о будущем человечества? Сеньоры — да, от них стоит этого ожидать, но не от всех же. Поэтому и задачки по опыту даются, и стратегии разрабатываются соответствующими людьми.
Любой человек, а разработчик тем более, будет усиленно сопротивляться внедрению нового, если не увидит выгод для себя, а изучение нового — это в первый момент сильно затратно. Так что один из способов уменьшить сопротивление — показать радужные перспективы в будущем. Иногда надо просто дорасти до технологии.
Я не против критики, потому что только так и можно увидеть все стороны ситуации. И да, как автор, я смотрю на ситуацию субъективно исходя из своего опыта, чего и не скрываю, изначально понимая, что вариантов использования намного больше, чем я затронул.
И то, что я видел, что люди используют докер не потому, что он реально нужен, а потому что это нынче популярно — это реальный кейс, с которым пришлось столкнуться. Отнюдь не все так делают, конечно же нет, и мы сами используем докер, я хотел лишь подчеркнуть в статье два основных момента:
1. Докер надо использовать там, где он реально нужен, а не везде вообще
2. Не надо забывать про хорошие системы упаковки, про которые сейчас мало говорят, но они есть и успешно работают и не надо их бояться
So if your machine has 128 GB of RAM, run two nodes each with just under 32 GB. This means that less than 64 GB will be used for heaps, and more than 64 GB will be left over for Lucene.
Желание завести две ноды на одной машине появляется, если на машине, например, 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.»
Но таких мало, так что особого вреда они вряд ли нанесут.
Чтобы современный стиль жизни отразился на генетике, надо еще не одно тысячелетие, чтобы человеческий конструктив перестал быть заточен под физические нагрузки.
Поделитесь пожалуйста опытом, что НЕ нравится в этой дорожке.
А что, наоборот, очень удобно и хорошо. И на что обратить внимание.
Как раз занимаюсь поиском похожего девайса для себя, было бы интересно узнать Ваше мнение.
Очков Валерий Федорович, Хмелюк В. А.
1990 год
эквм.рф/biblioteka/cartochki/0003.htm
Но если копать глубже, но я в статье как раз и озвучивал ситуацию про смену поколений, и поколение приходящих студентов, не зная прошлых наработок и не имея достаточно опыта, реализует деплой в виде простых скриптов или вообще вручную. Посмотрите на результаты опроса: деплой через FTP или самописными скриптами отнюдь не на последнем месте. Т.е. все делается, на самом деле, с минимумом усилий. И чтоб сделать качественный скачок — нужны мотивированные люди и опыт.
И то, что я видел, что люди используют докер не потому, что он реально нужен, а потому что это нынче популярно — это реальный кейс, с которым пришлось столкнуться. Отнюдь не все так делают, конечно же нет, и мы сами используем докер, я хотел лишь подчеркнуть в статье два основных момента:
1. Докер надо использовать там, где он реально нужен, а не везде вообще
2. Не надо забывать про хорошие системы упаковки, про которые сейчас мало говорят, но они есть и успешно работают и не надо их бояться
www.elastic.co/guide/en/elasticsearch/guide/master/heap-sizing.html#_just_how_far_under_32gb_should_i_set_the_jvm
So if your machine has 128 GB of RAM, run two nodes each with just under 32 GB. This means that less than 64 GB will be used for heaps, and more than 64 GB will be left over for Lucene.
Не хватает возможности нормально отлаживать контейнер, если с ним творится что-то нехорошее. При использовании полноценной машины там обычно есть достаточно инструментов для мониторинга, в случае же контейнера, как Вы сами заметили, есть желание урезать его по максимуму со всеми вытекающими последствиями.
А чем хуже иметь полноценный сервер, куда так же просто раскладывается jar?
Тем более что сам jar — это уже готовый контейнер, а java-машина и так управляет ресурсами (на то она так и называется Java Virtual Mashine, JVM)? Зачем вообще в такой связке нужен докер? Мне кажется, что это просто лишний слой.
Что Вы имеете ввиду под унифицированным интерфейсом взаимодействия с любым приложением?
Кстати, пробовали одно и то же объявление давать трем разным «бабам Зинам». Представте себе, они дали 3 разных ответа по классификации ремонта. Вопрос: какой из трех верить?
Но таких мало, так что особого вреда они вряд ли нанесут.
А что, наоборот, очень удобно и хорошо. И на что обратить внимание.
Как раз занимаюсь поиском похожего девайса для себя, было бы интересно узнать Ваше мнение.