Как-то в один момент я решил написать статью про поставку в виде контейнеров докер и deb-пакетов, но когда начал, меня почему-то понесло в далекие времена первых персональных компьютеров и даже калькуляторов. В общем, вместо сухих сравнений докера и deb получились вот такие вот размышления на тему эволюции, кои и представляю на Ваш суд.
Любой продукт, какой бы он ни был, должен каким-то образом добраться до продуктовых серверов, должен быть настроен и запущен. Вот об этом и будет эта статья.
Размышлять я буду в историческом контексте, «что вижу — о том пою», что я видел, когда начинал только писать код и что наблюдаю сейчас, что мы сами используем в настоящий момент и почему. Статья не претендует на полноценное исследование, некоторые моменты упущены, это мой личный взгляд на то, что было и что есть сейчас.
Итак, в старые добрые времена… самый ранний способ поставки, который я застал — это были кассеты от магнитофонов. У меня был компьютер БК-0010.01…
Эпоха калькуляторов
Нет, был еще более ранний момент, был еще калькулятор МК-61 и МК-52.
Так вот, когда у меня был МК-61, то способом переноса программы был обычный листок бумаги в клеточку, на котором была записана программа, которая при необходимости ее запустить вручную записывалась в калькулятор. Хочешь поиграть (да-да, даже на этом допотопном калькуляторе были игры) — садишься и вписываешь программу в калькулятор. Естественно, при выключении калькулятора программа уходила в небытие. Кроме собственноручно выписанных на бумагу кодов калькулятора, программы публиковались в журналах «Радио» и «Техника молодежи», а также печатались в книгах того времени.Следующей модификацией был калькулятор МК-52, у него уже появилось какое-то подобие энергонезависимого хранения данных. Теперь уже игру или программу не надо было вбивать вручную, а, проделав некоторые магические пассы кнопками, она загружалась сама.
Объем самой большой программы в калькуляторе был 105 шагов, а размер постоянной памяти в МК-52 — 512 шагов.
Кстати, если есть фанаты этих калькуляторов, кто читает эту статью — в процессе написания статьи я нашел и эмулятор калькулятора для андроид, и программы для него. Вперед, в прошлое!
Небольшое отступление про МК-52 (из википедии)
МК-52 летал в космос на корабле «Союз ТМ-7». Его предполагалось использовать для расчёта траектории посадки в случае, если выйдет из строя бортовой компьютер.
МК-52 с блоком расширения памяти «Электроника-Астро» с 1988 года поставлялся на корабли ВМФ в составе штурманского вычислительного комплекта.
Первые персональные компьютеры
Вернемся к временам БК-0010. Понятное дело, что и памяти там стало больше, и вбивать код с бумажки было уже совсем не вариант (хотя первое время я делал именно так, потому что другого носителя попросту не было). Основным средством хранения и поставки ПО становятся аудиокассеты для магнитофонов.
Хранение на кассете обычно было в виде одного или двух бинарных файлов, все остальное содержалось внутри. Надежность была очень низвая, приходилось держать 2-3 копии программы. Время загрузки тоже не радовало, энтузиасты экспериментировали с разным частотным кодированием, чтобы побороть эти недостатки. Я сам в то время еще не занимался профессиональной разработкой софта (не считая простых программ на бейсике), поэтому в деталях, как все было устроено внутри, к сожалению, не расскажу. Сам факт наличия на компьютере только ОЗУ по большей части определяло простоту схемы хранения данных.Появление надежных и больших носителей информации
Позже появляются дискеты, упрощается процесс копирования, вырастает надежность.
Но кардинально меняется ситуация, только когда появляются достаточно большие локальные хранилища в виде HDD.
Принципиально меняется тип поставки: появляются программы-инсталляторы, которые управляют процессом конфигурирования системы, а также зачисткой после удаления, поскольку программы не просто считываются в память, а уже копируются в локальное хранилище, из которого надо уметь и очищать ненужное при необходимости.
Параллельно увеличивается сложность поставляемого программного обеспечения.
Число файлов в поставке возрастает с единиц до сотен и тысяч, начинаются конфликты версий библиотек и прочие радости, когда разные программы используют одни и те же данные.
В те времена для меня еще не было открыто существование Linux, я жил в мире MS DOS и, позже, Windows, а писал на Borland Pascal и Delphi, иногда поглядывая в сторону C++. Для поставки продуктов в те времена многие использовали InstallShield ru.wikipedia.org/wiki/InstallShield, который вполне успешно решал все поставленные задачи развртывания и конфигурирования софта.Эпоха интернет
Постепенно сложность программных систем еще усложняется, от монолита и декстопных приложений происходит переход к распределенным системам, тонким клиентам и микросервисам. Теперь нужно уже конфигурировать не одну программку, а их набор, причем так, чтобы они дружили все вместе.
Изменалась полностью концепция, пришел Интернет, наступила эпоха облачных сервисов. Пока еще толко в начальной стадии, в виде сайтов, особо сервисами никто и не грезил. но это было поворотным моментом в индустрии как разработки, так и собственно поставки приложений.
Для себя я отметил, что в этот момент произошла смена поколений разработчиков (или это было только в моем окружении), и сложилось такое ощущение, что все старые добрые способы поставки были позабыты в один момент и все началось с самого начала: всю поставку стали делать наколеночными скриптами и назвали это гордо «Continuous delivery». По факту начался какой-то период бардака, когда старое позабыто и не используется, а нового попросту нет.
Я помню времена, когда у нас в компании, где я тогда работал (не буду называть), вместо того, чтобы делать сборку через ant (maven тогда еще не был популярен или вообще не было), народ просто собирал jar в IDE и безмятежно коммитил его в SVN. Соответственно, разворачивание заключалось в доставании файла из SVN и копированию его по SSH на нужную машину. Вот так просто и топорно.
В это же время поставка простых сайтов на PHP делалась уж совсем примитивно простым копированием поправленного файла через FTP на целевую машину. Иногда не было и такого — код правили вживую на продуктовом сервере, и было особым шиком, если были где-то бэкапы.
RPM- и DEB-пакеты
С другой стороны, с развитием интернета все большую популярность стали набирать UNIX-подобные системы, в частности, именно в то время для себя я открыл RedHat Linux 6, примерно 2000г. Естественно, что и там были определенные средства для поставки ПО, согласно википедии, RPM как основной пакетный менеджер появился аж в 1995г, в версии RedHat Linux 2.0. И с тех пор и до наших дней система поставляется в виде RPM-пакетов и вполне успешно существует и развивается.Дистрибутивы семейства Debian пошли похожим путем и реализовали поставку в виде deb-пакетов, что так же неизменно до наших дней.
Пакетные менеджеры позволяют поставлять сами программные продукты, конфигурировать их в процессе установки, управлять зависимостями между разными пакетами, осуществлять удаление продуктов и зачистку лишнего в процессе деинсталляции. Т.е. по бОльшей части это все, что нужно, именно поэтому они и продержались несколько десятилетий практически без изменений.
Облачность добавила в пакетные менеджеры установку не только с физических носителей, но и из облачных репозиториев, но принципиально мало что изменилось.
Стоит заметить, что в настоящее время есть некоторые поползновения в сторону ухода от deb и перереход на snap-пакеты, но об этом позже.
Так вот, это новое поколение облачных разработчиков, которое не знало ни DEB, ни RPM, тоже потихоньку росло, набиралось опыта, продукты усложнялись, и нужны были какие-то более разумные способы поставки, нежели FTP, bash-скриптики и подобные студенческие поделки.
И здесь на сцену выходит Docker, эдакая смесь виртуализации, разграничения ресурсов и способа поставки. Это сейчас модно, молодежно, но нужен ли он для всего? Панацея ли это?
По моим наблюдениям, очень часто Docker предлагается не как разумный выбор, а просто потому, что об этом, с одной стороны, говорят в сообществе, и те, кто предлагают, только его и знают. С другой стороны, о старых добрых системах упаковки по большей части молчат — они есть и есть, свое дело делают тихо и незаметно. В такой ситуации другого выбора особо-то и нет — выбор очевиден — Docker.
Попробую поделиться опытом, как у нас проходило внедрение Docker, и что в результате получилось.
Самописные скрипты
Изначально были bash-скрипты, которые деплоили jar-архивы на нужные машины. Управлял этим процессом Jenkins. Это успешно работало, благо сам по себе jar-архив уже является сборкой, содержащей в себе классы, ресурсы и даже конфигурацию. Если сложить в него все по максимуму — то разложить его скриптом — это не самое сложное, что нужно
Но у скриптов есть несколько недостатков:
- скрипты обычно пишутся на скорую руку и потому настолько примитивны, что содержат только один самый благополучный сценарий. Этому способствует то, что разработчик заинтересован в скорейшей поставке, а нормальный скрипт требует вложение приличного количества ресурсов
- как следствие предыдущего пункта, скрипты не содержат процедуры деинсталляции
- нет установленной процедуры апгрейда
- при появлении нового продукта надо писать новый скрипт
- нет поддержки зависимостей
Конечно, можно написать навороченный скрипт, но, как я писал выше — это время на разработку, причем не самое малое, а времени, как известно, всегда не хватает.
Это все очевидно ограничивает круг применения такого способа развертывания только простейшими системами. Настал момент это менять.
Docker
В какой-то момент к нам начали приходить свежеиспеченные мидлы, бурлящие идеями и бредящие докером. Что ж, флаг в руки — делаем! Было две попытки. Обе неудачных — скажем так, из-за больших амбиций, но недостаточности реального опыта. Надо ли было форсировать и доделывать любыми силами? Вряд ли — коллектив должен эволюционно дорасти до нужного уровня, прежде чем сможет использовать соответствующие инструменты. Ко всему прочему, используя готовые образы докера, мы часто сталкивались с тем, что там некорректно работала сеть (что, возможно, было еще связано с сыростью самого докера) или было сложно расширять чужие контейнеры.С какими неудобствами мы столкнулись?
- Проблемы с сетью в режиме bridge
- Неудобно смотреть логи в контейнере (если они никуда не вынесены отдельно в файловую системы хост-машины)
- Периодически странное зависание ElasticSearch внутри контейнера, причину так и не установили, контейнер официальный
- Нудобно пользоваться шеллом внутри контейнера — все сильно урезано, нет привычных инструментов
- Большой размер собираемых контейнеров — дорого хранить
- Из-за большого размера контейнеров сложно поддерживать множественные версии
- Более длительная сборка, в отличие от других способов (скрипты или deb-пакеты)
С другой стороны, чем Spring-сервис в виде jar-архива хуже деплоить через тот же deb? Реально ли нужна изоляция ресурсов? Стоит ли лишаться удобных инструментов операционной системы, запихивая сервис в сильно урезанный контейнер?
Как показала практика — в реальности это не нужно, deb-пакета хватает в 90% случаев.
Когда же все-таки старый добрый deb не срабатывает и когда действительно нам был необходим докер?
Для нас это было развертыванием сервисов на python. Множество библиотек, нужных для машинного обучения и отсуствующих в стандартной поставке операционной системы (а то, что там было — не тех версий), хаки с настройками, необходимость разных версий для разных сервисов, живущих на одной и той же хост-системе привели к тому, что единственным разумный способом поставки этой ядерной смеси оказался докер. Трудоемкость сборки докер-контейнера оказалась ниже, чем идея упаковать все это в отдельные deb-пакеты с зависимостями, да собственно никто в здравом уме за это бы и не взялся.
Второй момент, где планируется использовать докер — для развертывания сервисов по схеме blue-green deploy. Но здесь хочется получить постепенное увеличение сложности: сначала собираются deb-пакеты, а затем уже из них собирается докер-контейнер.
Snap-пакеты
Вернемся к snap-пакетам. Впервые они официально появились в Ubuntu 16.04. В отличие от привычных deb-пакетов и rpm-пакетов, snap несут в себе все зависимости. С одной стороны, это позволяет избежать конфликта библиотек, с другой стороны — это более значительные размеры результирующего пакета. Кроме того, это же может влиять на безопасность системы: в случае поставки snap за всеми изменениями включенных библиотек должен следить сам разработчик, который создает пакет. В общем не все так однозначно и всеобщее счастье от их использования не наступает. Но, тем не менее, это вполне себе разумная альтернатива, если тот же Docker используется только как средство упаковки, а не виртуализации.Как итог, у нас сейчас в разумном сочетании используются как deb-пакеты, так и докер-контейнеры, которые, возможно, в отдельных случаях мы заменим на snap-пакеты.
Комментарии (39)
farcaller
18.03.2019 00:39Так вот, когда у меня был МК-61
ЕГГОГ :-)
eaa Автор
18.03.2019 00:49Я помню, было отдельное шаманство, как писать символы на числовом дисплее… жаль книжек старых не сохранилось
farcaller
18.03.2019 12:24http://xn--b1aph9d.xn--p1ai/biblioteka/cartochki/0019.htm держите. Я в детстве часами за этой книгой сидел.
eaa Автор
19.03.2019 00:01У меня вот такая была в свое время: «От микрокалькулятора к персональному компьютеру»
Очков Валерий Федорович, Хмелюк В. А.
1990 год
эквм.рф/biblioteka/cartochki/0003.htm
romangoward
18.03.2019 01:08Docker в первую очередь даёт унифицированный интерфейс взаимодествия с любым приложением, что позволяет значительно повысить надёжнось и снизить стоимость поддержки ops.
Ни один из пакетных менеджеров не решает эту задачу.eaa Автор
18.03.2019 01:14Что Вы имеете ввиду под унифицированным интерфейсом взаимодействия с любым приложением?
gecube
18.03.2019 01:27+1Унифицированный — это про способ установки/удаления, про сбор логов и метрик и пр.
Еще докер сам следит за работоспособностью процесса как супервизор. И не нужно лепить костыли.
Концептуально — можно паковать не в докер, а в rpm/deb + systemd юниты — по идее почти тоже самое, но это реально сложнее + можно налететь на проблемы зависимостей.eaa Автор
18.03.2019 08:51Не соглашусь с Вами только по поводу того, что rpm/deb + systemd — это сложнее. На самом деле это проще. Сложность здесь кажущаяся, потому что про докер Вы слышите в публикациях и на конференциях чуть ли не каждый день, а про rpm — тишина. И поэтому те, кто пришел в разработку не так давно, вынуждены выбирать то, что на виду. Если же подходить к выбору осознанно — то у каждого варианта есть своя сфера, в которой применение соотвествующего инструмента оправдано.
gecube
18.03.2019 09:18Не соглашусь с Вами только по поводу того, что rpm/deb + systemd — это сложнее
Нет, нет и еще раз нет. rpm сложнее. Т.к. нужно, во-первых, собирать под несколько операционных систем (el6, el7, opensuse etc.). Во-вторых, rpm не решает проблему с зависимостями типа python пакетов. В третьих, есть еще в манифестах системные зависимости. Ну, там от libqt, внешних утилит (openssl, openssh?) и пр. И никто, никто, черт побери, не прописывает их нормально. Например, в убунте эти зависимости обычно идут как «я завишу от пакета XXX версии не младше YYY» (см., например, ntp). А то что пакет XXX версии ZZZ (ZZZ>YYY) все сломает — пофиг.
Докер в этом отношении идеален, т.к. образ — это по сути слепок операционной системы со всеми необходимыми пакетами, причем протестированными с конкретной версией приклада. Да — в минусах размер. Да — проблема с тем, что если есть какая-либо уязвимость, то нужно пересобирать и перескачивать все уязвимые образы.eaa Автор
18.03.2019 09:24Мы не поставляем продукты по всему миру, поэтому нет проблемы сборки под несколько операционных систем. А то, что Вы описываете — это как раз то, что пытались решить введением snap-пакетов, и в части случаев это оправдано, в части — совсем нет. Ваш пример с библиотеками питона — это именно тот самый случай, когда полный слепок не то что оправдан — он просто необходим. И тут я Вас всячески поддерживаю.
trapwalker
18.03.2019 11:58+1Всё же в вашей статье отчетливо читается некая предвзятость. Не знаю осознанно или из экономии времнии на поиск более убедительных и строгих аргументов, но в статье вы постоянно манипулируете мнением читателя:
И здесь на сцену выходит Docker, эдакая смесь виртуализации, разграничения ресурсов и способа поставки. Это сейчас модно, молодежно, но нужен ли он для всего? Панацея ли это?
В какой-то момент к нам начали приходить свежеиспеченные мидлы, бурлящие идеями и бредящие докером. Что ж, флаг в руки — делаем! Было две попытки. Обе неудачных — скажем так, из-за больших амбиций, но недостаточности реального опыта. Надо ли было форсировать и доделывать любыми силами? Вряд ли — коллектив должен эволюционно дорасти до нужного уровня [..]
С другой стороны, чем Spring-сервис в виде jar-архива хуже деплоить через тот же deb? Реально ли нужна изоляция ресурсов? Стоит ли лишаться удобных инструментов операционной системы, запихивая сервис в сильно урезанный контейнер?
Как показала практика — в реальности это не нужно, deb-пакета хватает в 90% случаев.
При этом перечисленные вами проблемы при использовании контейнеров — это либо признаки не совсем правильного использования контэйнеризации (в плане логов или шелла внутри контейнера), либо «какие-то частные непонятные проблемы», в суть которых, видимо, никто не углублялся (проблемы с сетью, странные зависания ElasticSearch), либо понятные и по-разному решаемые особенности докеризации, которые, по сути, и есть та компромиссная часть trade-off, на которую мы смотрим решая допустимо ли перевести систему на docker (размеры контейнеров, скорость сборки).
Да, докер не панацея и, чем у'же убласть, тем больше поводов смотреть на частные и альтернативные решения. Однако, чем шире мы смотрим на индустрию, тем в лучшем свете представляется докер, ведь он хорош своим движением в сторону универсализации и унификации.
Квинтесценция манипулятивности и некоторой нелогичности вашей статьи на мой взгляд в этой цитате:
По моим наблюдениям, очень часто Docker предлагается не как разумный выбор, а просто потому, что об этом, с одной стороны, говорят в сообществе, и те, кто предлагают, только его и знают. С другой стороны, о старых добрых системах упаковки по большей части молчат — они есть и есть, свое дело делают тихо и незаметно.
Я там наподчёркивал то, что меня, прям, покоробило. Тут и отсылка к личному опыту, и странное обобщение, будто бы о докере говорят исключительно те, кто лишь его только и знает…
Лично я, когда такое читаю, сразу задумываюсь о предвзятости мнений и о направлении причинно-следственных связей. Почему об одном молчат, а о другом кричат? Если бы вы нейтрально рассмотрели плюсы и минусы без манипуляций, то как по-вашему, статья стала бы менее объективной? Может быть она дала бы читателям лишнюю возможность сделать неверные выводы? Ну не знаю…
Вы только не обежайтесь, уважаемый автор. Я постарался внести конструктивную критику вашей статьи. Из моих тезисов, конечно, не следует, что вы не правы по существу, что докер в вашем юзкейсе более верное решение, и даже что в сторону докера нет излешнего перекоса в среде хипстеров от девопса=).eaa Автор
18.03.2019 12:21Я не против критики, потому что только так и можно увидеть все стороны ситуации. И да, как автор, я смотрю на ситуацию субъективно исходя из своего опыта, чего и не скрываю, изначально понимая, что вариантов использования намного больше, чем я затронул.
И то, что я видел, что люди используют докер не потому, что он реально нужен, а потому что это нынче популярно — это реальный кейс, с которым пришлось столкнуться. Отнюдь не все так делают, конечно же нет, и мы сами используем докер, я хотел лишь подчеркнуть в статье два основных момента:
1. Докер надо использовать там, где он реально нужен, а не везде вообще
2. Не надо забывать про хорошие системы упаковки, про которые сейчас мало говорят, но они есть и успешно работают и не надо их бояться
usego
18.03.2019 15:16Взгляд на докеризацию исключительно как на средство упаковки слишком однобоко. Докеризация решает проблему (ну или помогает решать), когда программер заявляет «а у меня всё работает». Граница ответственности за работоспособный environment заметно смещается в сторону разработчика, что упрощает жизнь опсам и повышает их capacity. Возможно это одна из причин, почему столько сопротивления со стороны разработчиков, когда им «усложняют» жизнь, хотя в реальности процесс только улучшается. И да, я пробивал перфокарты в детстве.
eaa Автор
18.03.2019 15:45Любой человек, а разработчик тем более, будет усиленно сопротивляться внедрению нового, если не увидит выгод для себя, а изучение нового — это в первый момент сильно затратно. Так что один из способов уменьшить сопротивление — показать радужные перспективы в будущем. Иногда надо просто дорасти до технологии.
gecube
18.03.2019 15:53Ключевое —
если не увидит выгод для себя
Т.е. это опять ситуация, когда локальный оптимум (i.e. разрабу не нужно учить ничего нового, он эффективен в своей зоне комфорта) абсолютно не попадает в глобальный оптимум (i.e. эффективность всей организации). Извините, что так сложно изъясняюсь.eaa Автор
18.03.2019 16:10Вы много встречали джуниоров, которые грезят о будущем человечества? Сеньоры — да, от них стоит этого ожидать, но не от всех же. Поэтому и задачки по опыту даются, и стратегии разрабатываются соответствующими людьми.
gecube
18.03.2019 16:11Эм, ну, Вы все правильно сейчас говорите, но как это соотносится с темой статьи?
eaa Автор
18.03.2019 16:17Вообще-то я просто ответил на Ваш вопрос :)
Но если копать глубже, но я в статье как раз и озвучивал ситуацию про смену поколений, и поколение приходящих студентов, не зная прошлых наработок и не имея достаточно опыта, реализует деплой в виде простых скриптов или вообще вручную. Посмотрите на результаты опроса: деплой через FTP или самописными скриптами отнюдь не на последнем месте. Т.е. все делается, на самом деле, с минимумом усилий. И чтоб сделать качественный скачок — нужны мотивированные люди и опыт.usego
18.03.2019 18:31У меня почему-то внедрение нового CI/CD упиралось не в джунов, а именно в «стариков», которым опыт больше мешал, чем помогал принимать новое. Аргументы те же — 100 лет деплоили вот так, зачем всё «усложнять». А вопросы долговременной поддержки инфраструктуры в целостном состоянии, вопросы масштабирования и миграций, то что сильно облегчает докеризация — по факту девов вообще не волнуют. Ни сениоров, ни джунов. Пока самих их не заставишь разгребать собственные грехи в проде, но до таких крайностей лучше не доходить.
gecube
18.03.2019 01:32+1Проблемы с сетью в режиме bridge
Неудобно смотреть логи в контейнере (если они никуда не вынесены отдельно в файловую системы хост-машины)
Периодически странное зависание ElasticSearch внутри контейнера, причину так и не установили, контейнер официальный
Нудобно пользоваться шеллом внутри контейнера — все сильно урезано, нет привычных инструментов
Большой размер собираемых контейнеров — дорого хранить
Проблемы с сетью — используйте балансировщик (nginx, traefik, envoy или вообще внешний). Или host mode сеть.
Неудобно смотреть логи? Не верю (с). Наоборот — через docker logs удобнее смотреть логи, чем бегать по 100500 файлов в файловой системе. Единственное, что docker лучше сразу настроить на драйвер journald, т.к. остальные (кроме дефолтного json file) не сохраняют локальные логи и тогда действительно команда docker logs не работает. А хранить логи в контейнере — ССЗБ.
Эластик запускать внутри контейнера — такое себе удовольствие, но почти наверняка уверен, что это не проблема самого докера или образа. Т.к. у нас все работает. К тому же, рекомендую graylog, а не elk, т.к. это более законченное решение (если, конечно, Вы не готовые эластику отвалить 1****** $$$ за ёлку под ключ).
Шелл внутри докера? Чего там не хватает? Если что-то нужно, то всегда можно доустановить быстро утилиты для диагностики проблемы. А вообще — меньше программ в образе — меньше размер — меньше поверхность атаки и меньше проблем.
Большой размер образов — ну, так нужно их уметь собирать… И в общем случае размер артефакта в разумных пределах не является проблемой.
Из-за большого размера контейнеров сложно поддерживать множественные версии
Более длительная сборка, в отличие от других способов (скрипты или deb-пакеты)
это вообще пять. Про первое я уже сказал. Кстати, docker registry позволяет дедупликацию данных, поэтому два образа по 5ГиБ скорее всего займут сильно меньше, чем 2*5=10ГиБ. Второе — да, есть нюанс, но она более длительная не на порядок, а раза в два и все равно можно ее оптимизировать. Идеальный вариант сборки — имеется базовый образ с java и туда попросту инжектируется уже собранный jar или war файл. Тогда и сборка получается максимально быстрая, и размер итогового образа минимальный.eaa Автор
18.03.2019 09:11Про логи — каждому свое, кому что больше нравится. Логи от больших распределенных сервисов мы храним в эластике (не в том, что неудачно пытался жить в докере, а в нормальном кластере без всяких лишних контейнеров), а для логов простых сервисов посмотреть файл все-таки проще. Но тут, как я уже сказал, о вкусах не спорят.
Шелл внутри докера? Чего там не хватает?
Не хватает возможности нормально отлаживать контейнер, если с ним творится что-то нехорошее. При использовании полноценной машины там обычно есть достаточно инструментов для мониторинга, в случае же контейнера, как Вы сами заметили, есть желание урезать его по максимуму со всеми вытекающими последствиями.
имеется базовый образ с java и туда попросту инжектируется уже собранный jar или war файл.
А чем хуже иметь полноценный сервер, куда так же просто раскладывается jar?
Тем более что сам jar — это уже готовый контейнер, а java-машина и так управляет ресурсами (на то она так и называется Java Virtual Mashine, JVM)? Зачем вообще в такой связке нужен докер? Мне кажется, что это просто лишний слой.gecube
18.03.2019 09:21Не хватает возможности нормально отлаживать контейнер, если с ним творится что-то нехорошее. При использовании полноценной машины там обычно есть достаточно инструментов для мониторинга, в случае же контейнера, как Вы сами заметили, есть желание урезать его по максимуму со всеми вытекающими последствиями.
У Вас есть strace на хостовой машине, htop на хостовой машине и пр. Они прекрасно показывают процессы внутри контейнера, и, да, strace к процессу внутри контейнера прекрасно подцепляется. Поэтому вопрос — НУЖНО ли тащить внутрь контейнера весь этот лишний пейлоад?
А чем хуже иметь полноценный сервер, куда так же просто раскладывается jar?
Тем более что сам jar — это уже готовый контейнер, а java-машина и так управляет ресурсами (на то она так и называется Java Virtual Mashine, JVM)? Зачем вообще в такой связке нужен докер? Мне кажется, что это просто лишний слой.
Не Mashine, а Machine :-) И, да, Вы правы, что JVM сама заведует ресурсами. Тут вопрос в другом, что если Вы едете в какой-нибудь унифицированный стек для управления ресурсами (тот же кубернетес), то проще всех загнать под единую гребенку. А именно — паковать все в докеры. Тем более, что это позволяет разработчикам проводить множество экспериментов у себя на системе, не захламляя ее серверами приложений Java (а они прям проникают во все уголки хостовой системы).eaa Автор
18.03.2019 09:39Kubernetes — это уже тот уровень, где решаются не просто задачи упаковки, а задачи балансирования нагрузки и все прочие радости высоконагруженных систем (иначе зачем этот Kubernetes?), там и подход другой — дешевле развернуть контейнер целиком за пару секунд, когда в динамике будет расти нагрузка, чем ставить цепочку rpm-пакетов.
usego
18.03.2019 15:22Инструментарии отладки в докерах ровно те же самые. Сам недавно перевёл пару своих ES кластеров на докера под ансиблом и вижу в этом только плюсы — лёгкий апгрейд и реконфигурация и возможнось плотнее упаковать инстансы. К примеру держу 2 EC2шки в конфигурации coordinator + 2 masters. Дата ноды отдельно. Всё это конечно и без докеров можно сделать, но ансиблирование в этом случае заметно объёмней.
easyman
18.03.2019 01:51-1Меня смущает слово виртуализация рядом со словом docker, когда не имеют в виду запуск хоста docker в VM.
vasyapivo
18.03.2019 08:52Если вы пошли в докер, то вам по-любому надо следовать идеологии микросервисов и выносить логи в какой-то внешний сервис, вроде ES. ES же не рекомендуется использовать в варианте с одной нодой, поскольку ES штука мощная, но довольно нестабильная. Один мой знакомый на очень нагруженном проекте говорит, что правильный сетап, это как минимум две ноды ES, которые перезагружаются раз в сутки. Таким образом проблем с доступностью ES нет.
Когда мы начинали стартап, то тоже была идея взять кубер, но денег и ресурсов было мало, потому развернули всё на обычных VDS с обычным деплоем через Octopus Deploy. Эта штука позволяет делать довольно навороченные сценарии и заменяет самописные скрипты.eaa Автор
18.03.2019 08:56Мы очень любим ElasticSearch, и, на самом деле, он очень стабилен при правильной конфигурации. Докер для него — действительно не то место, где он себя будет хорошо чувствовать. На примере нашего кластера эластиков замечу, что его уж точно не надо перегружать раз в сутки, он может работать без перезегрузки месяцами. Тут главное не забыть его мониторить — как и любой нагруженный сервис с несколькими нодами.
gecube
18.03.2019 09:29Докер для него — действительно не то место, где он себя будет хорошо чувствовать.
Мне кажется, что проблема в другом.
ES в каком-то тестовом виде можно развернуть в докерах. Но смысла, кроме быстрого обновления версии, это не имеет. Потому что под ES в идеале нужно давать выделенные ноды — будь то аппаратные сервера или виртуальные машины. И в случае с докером — ES нужно «правильно» готовить. А зачем, если можно сделать проще, а, следовательно, и надежнее.arheops
18.03.2019 09:57Куда уж правильнее, чем официальный образ?
eaa Автор
18.03.2019 10:05Ошибаться могут все. Если бы Вы читали, например, про официальный образ для MediaWiki — как народ плюется от этого официального и использует собственные кастомные взамен — Вы бы не были столь категоричны.
arheops
18.03.2019 10:07Конечно. Но мы же про «правильность».
Правильно — если у вас есть образ, работающий лучше официального — отправить в официальный изменения, которые позволяьт работать лучше.
gecube
18.03.2019 10:11+1А Вы ответьте на вопрос — зачем он вообще существует? Т.е. это вариант для быстрого разворачивания тестового стенда эластика или все-таки production решение?
Кстати, знаете, чем закончится запуск штатного стека через docker-compose? Такой или такой. Первый — точно упадет по памяти рано или поздно. Второй — а зачем, позвольте, две ноды эластика запускать на одной машине? Это только, чтобы кластер зеленый хелсчек показал? А в остальном это создает проблемы: от конкуренции за процессор и память между обеими нодами эластика, вплоть до того, что отказоустойчивости по факту никакой. Вот и угадай, чем они думали, когда рекомендовали такой конфиг…eaa Автор
18.03.2019 11:07Желание завести две ноды на одной машине появляется, если на машине, например, 64гига памяти… вот тут есть нюансы при использовании эластиком памяти больше 32 гигов habr.com/ru/company/yamoney/blog/419041
eaa Автор
18.03.2019 11:36А вот из официальной доки эластика:
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.gecube
18.03.2019 11:37Я не против такого конфига. Это звучит здраво и имеет смысл. Но docker-compose — это решение для моделирования, тестирования и отладки. И вряд ли пользователь попробует эластик изначально на дорогой ноде с 32+ГиБ ОЗУ.
К тому же, две дата-ноды на одном хосте требуют грамотного микроменеджмента разделов диска и т.п.
ttys
18.03.2019 23:53Чего вы пристали к человеку? Просто не получилось у него осилить докер. Как сам и сказал "дорастёт команда" и будет им счастье (не сразу конечно, через грабли) но будет ;)
sumej
19.03.2019 08:41+1Работал я в одном Энтерпрайзе(сетевое оборудование), где нужно следующее:
Выпускается версия С/С++/Java/Python/NodeJs/Go приложения — миллионы строк и 800 человек разработчиков. Поддержка из коробки 15 лет, но её частенько расширяют.
Нужно гарантировать на всём протяжении существования продукта:
* неизменную среду разработкии и исполнения(железо или любой клауд, любая втртуализация github.com/weldpua2008/deployer) — в обычной убунте с помощью alternatives, .bash_*, /opt/ я создавал кастомный build toolchain: g++/make/Shared objects/Kernel headers/ld_library_path и т.д. Которые таким же макаром создавались пакеты(rpm/deb) или архивы.
* не важно сколько раз пробежит билд — это всегда будет одна и та же версия. И если при сборки версии 1.1.1 пробегал скрипт и создавал неправильную конфигурацию в CI и потом мы это исправили, то для версии 1.1.2 этих изменений не будет существовать.
Мы версиировали систему сборок (https://github.com/weldpua2008/compage).
Мы использовали всевозможные стандартные системы распространения ПО: rpm, deb, pipe, npm, maven репозитории, Artifactory. Почти всегда есть следующая ситуация: следующий билд на может найти тот или иной пакет или его версию. Я помню как в 2015 фиксировал версию requests для Python, потому что между минорными версиями были глобальное изменение.
Все вышесказанное кристаллизировать у меня следующее:
* если вы не выпускаете коробки/виртуальную машину со своим кодом, то вы должны фиксировать версию ваших прямых зависимостей и их зависимостей. (Желательно у себя, иначе условная Cloudera сломает репозиторий и вы не сможете обновлять /устанавливать в облаке новые машины): AMI, созданные через packer образы VM, LXC, частный docker репозиторий.
* Chef/Ansible и другие представители CM — сами могут падать из-за обновлений и нужно уметь откатывать версии.
* разработчики могут вставить в код всевозможные вещи, которые вас пригвоздят к конкретной машине, среде запуска или же пользователю.
inkvizitor68sl
20.03.2019 02:23Есть такая болячка, «докер головного мозга» называется. Сейчас в докер тащут всё, что нужно и что не нужно (и ладно бы если бы понимали, чем это грозит).
uonick
1. Sentry
2. stdout + сборщик логов
3. logspout
4. Filebeat
5. Fluentd