Представлен (https://blog.docker.com/2018/11/introducing-docker-engine-18... релиз инструментария для управления изолированными Linux-контейнерами Docker 18.09 (https://www.docker.com/community-edition), предоставляющего высокоуровневый API для манипуляции контейнерами на уровне изоляции отдельных приложений. Docker позволяет, не заботясь о формировании начинки контейнера, запускать произвольные процессы в режиме изоляции и затем переносить и клонировать сформированные для данных процессов контейнеры на другие серверы, беря на себя всю работу по созданию, обслуживанию и сопровождению контейнеров. Инструментарий базируется на применении встроенных в ядро Linux штатных механизмов изоляции на основе пространств имён (namespaces) и групп управления (cgroups). Код Docker написан на языке Go и распространяется (https://github.com/docker/docker-ce/) под лицензией Apache 2.0.Основные изменения (https://docs.docker.com/engine/release-notes/):
- Начиная с Docker 18.09 время поддержки выпуска увеличено с 4 до 7 месяцев в связи с модернизацией цикла разработки Docker Community Edition (стабильные релизы теперь формируются не раз в квартал, а раз в полгода, плюс для тестирования введены (https://docs.docker.com/install/) ночные сборки);- Базовый runtime для управления контейнерами обновлён до выпуска containerd (https://www.opennet.ru/opennews/art.shtml?num=47681) 1.2 (https://github.com/containerd/containerd/releases/tag/v1.2.0), в котором стабилизировано использование механизма gRPC для управления контейнерами, обеспечена совместимость с платформой Kubernetes 1.12 и улучшена поддержка универсальных образов для различных архитектур (multi-arch);
- Расширены возможность нового сборочного бэкенда (обеспечивает функциональность команды "docker build") BuildKit, построенного с использованием расширяемой модульной архитектуры, поддерживающего распараллеливание процесса разрешения зависимостей в несколько потоков, эффективно использующего кэширование инструкций и результатов импорта/экспорта, жестко не привязанного к формату файлов Dockerfile, автоматически выполняющего операции сборки мусора, поддерживающего вложенный запуск работ и не требующего в процессе работы полномочий пользователя root. По сравнению с прошлым выпуском:
- Переработан код для организации параллельного выполнения работ и изменена модель кэширования, что позволило существенно ускорить сборку. Например, при тестировании Dockerfile проекта moby (https://github.com/moby/moby) скорость сборки возросла от 2 до 9.5 раз за счёт одновременного выполнения разных стадий сборки, игнорирования неиспользуемых стадий и файлов, инкрементальной передачи данных между сборками с учётом контекста;
- Добавлена возможность интеграции в Dockerfile "секретов" (secrets) и их безопасной передачи в процессе сборки, без сохранения в результирующих образах и без оседания в сборочном кэше;- Реализована возможность проброса по SSH сокетов ssh-agent, например, для соединения с приватными репозиториями с использованием существующего соединения через ssh-agent;
- Появилась возможность управления сборочным кэшем, отдельно от образов. Добавлена новая команда "docker builder prune" для очистки кэша и возможность определения правил очистки;
- Представлена новая директива "#syntax", позволяющая подключать расширения для парсинга Dockerfile;
- Добавлена возможность использования BuildKit без включения экспериментального режима.
- Объявлена устаревшей поддержка драйверов хранения devicemapper и overlay, прекращена поддержка версий TLS меньше 1.2, удалена поддержка платформ Ubuntu 14.04 и Debian 8 "Jessie";- API обновлён до версии 1.39. Добавлена поддержка удалённого обращения при помощи SSH;
- Добавлена новая команда "docker engine" для управления жизненным циклом Docker Engine, запущенном в отельном привилегированном контейнере на базе containerd;
- Обновлены сценарии автодополнения ввода для bash и zsh;- Добавлен новый драйвер ведения логов local (https://github.com/moby/moby/issues/33475), позволяющий хранить лог в локальном файле. В отличие от jsonfilelog новый драйвер не привязан к конкретному формату лога;
- Добавлена поддержка применения по умолчанию глобального пула адресов;
На базе Docker Engine 18.09 сформирован выпуск коммерческого продукта Docker Enterprise 2.1, отличающийся поставкой дополнительных плагинов, поддержкой SLA (Service Level Agreement (https://ru.wikipedia.org/wiki/%D0%A1%D0%... и средствами для верификации по цифровым подписям.
В новой версии добавлены модули для верификации в соответствии с требованиями FIPS 140-2 и реализована настройка, ограничивающая работу только с образами, имеющими корректные цифровые подписи (блокировка в случае обнаружения нарушения целостности контейнера).
URL: https://blog.docker.com/2018/11/introducing-docker-engine-18-09/
Новость: https://www.opennet.ru/opennews/art.shtml?num=49628
#nobigfatdaemon
> удалена поддержка платформ Ubuntu 14.04за чтооооо.....
так оно eol'нется через полгода, как бы намекают, что если хотите самый последний докер -- пора бы переходить на более свежую ос.
Поддержка Ubuntu LTS начиная с 14.04 продлена до 10 лет.
> Поддержка Ubuntu LTS начиная с 14.04 продлена до 10 лет.А что, есть официальное заявление?
Прикинь, Вась! Иногда надо читать дальше заголовков.
Читать надо оригиналы! :)
https://endoflife.software/operating-systems/linux/ubuntu
> Прикинь, Вась! Иногда надо читать дальше заголовков.Во-первых, я просил текст из официальных источников, а во-вторых, даже в той новости, на которую ты дал ссылку, ничего не сказано о принятом решении - только размышления на тему. Ну и кто из нас Вася?
так там как раз таки написано что 14я убунта не в списке - вот лошара
Видать xpeновый god выдался, неурожайный, раз уже и мозги потекли)) Читаем вместе: "Для Ubuntu 16.04 и 14.04 обновления пока планируется выпускать в течение 5 лет.". Дошло? В течении ЕЩЕ 5 лет от сего момента. Как-бы срок изначально запланированных апдейтов для 14.04 истек в этом году, и его продлили еще на 5 лет. Ну а для 16.04 истечет через 2 года, и его тоже продлили на 5 лет. Твоя понимай?)
> "Для Ubuntu 16.04 и 14.04 обновления пока планируется выпускать в течение
> 5 лет.". Дошло? В течении ЕЩЕ 5 лет от сего момента.слова "ещё" там нету. сайт убунты про это тоже ничего не знает, у них ровно 5 лет от апреля 14 года: https://www.ubuntu.com/about/release-cycle
да, у них есть ещё ESM, но это за деньги: https://blog.ubuntu.com/2018/09/19/extended-security-mainten...
> Как-бы срок изначально запланированных апдейтов для 14.04 истек в этом году,
> и его продлили еще на 5 лет.2014+5=2019.
у них никогда не было LTS-релиза на 4 года, это ты с чем-то перепутал.6.06, 8.04 и 10.04 поддерживались 3 года, более новые по 5. 4 лет для LTS никогда не было.
Неужели тут так много Виталиев? +7 за такой бред..
От плюсов бред правдивей не становится.
Иногда нужно учиться ещё и мыслить.
пока включая только 18.04, да и то на словах
Это откуда инфа? https://www.ubuntu.com/about/release-cycle - 14.04 только с 2014-2019. Где тут 10 лет?
У тебя в ссылке в 18.04 только 5 лет хотя уже объявлено что 10.
Ссылка же на официальный сайт. Что и следовало ожидать: космонавт звездит, как всегда.
У Windows XP для корпорейтов и то поддержка была больше
Главное обмазаться зондами посильнее, так победим!)
Используй systemd-контейнеры, там и 14 покатит. Что мешает? Ах да, господа, вперёд, минусуйте.
Кому убунта нужна на сервере?.... Есть же CentOS
CentOS еще не переименовали в IBMOS ?
пока еще нет. В любом случае, есть ещё OpenSUSE
Зачем нужна центось, когда есть Ubuntu?
кому нормальному нужна убунту, когда есть debian
Мне нужна убунта. Дебиан оставь себе!
С учётом поддержки 10 лет для лтс поддерживаю!
Технология молодая. Стрёмная. Нет сил поддерживать 14.04. И желания у них нет. Не успевают или не способны много и хорошо.Устриц - ел. )
Пока докер не научится работать с открытым стандартом контейнеров можно закапывать.
А вообще давно уже все юзают альтернативу в виде подмана с сыновьями.
А как у подмана и аналогов с работой под OSX?
Есть ли такие же проблемы как у докера при работе с APFS?
Он о buildah, podman, scopeo имеет смутное представление. Он даже не знает, что до недавнего времени эти утилиты имели недостатки, которые ставили мертвый крест на продакшен серверах. Да и сейчас доля podman на продакшен очень, ооочееннннь ограничена.
редхату-то уже об этом рассказали? А то я что-то волнуюсь...
В 7 до сих пор абсолютное большинство контейнеров находится под крышей Docker. В 8 же будет переломный момент для Docker vs (Buildah, Podman, Scopeo).Вы с этими инструментами знакомы, сами использовали на большом количестве инсталляций или слышал звон, да не знаю, где он? В курсе, что эти инструменты лишь недавно вышли из вечной альфы-беты?
понимаете, от того что инвесторы доскера любят большие числа - совершенно не происходит никакой магии, и эта вечная убогая недоделка из состояния вечной пре-альфы не выйдет никогда, даже если ей нарисуют версию не 18 а 180.а вот то что редхат ее выпилила напрочь из своей восьмерки - не оставив своим пользователям вообще никакого выбора - говорит о том, что им на вас наплевать...ой, зачеркнуто - что они в принципе не видят никакой катастрофы в этой замене и готовы помогать своим клиентам, если вдруг лыжи у тех разъедутся. А вот с доскером - почему-то нет.
Почему бы это? ;-)
Потому что редхат это айбиэм и это вечные проприетарщики. Вендор лок это их всё.
понял, понял, подман и открытый стандарт контейнеров - это проприетарь и вендорлок и вот это вот все. Докер - швятой, швятой, хотя именно он не поддерживает, внезапно, никаких форматов кроме своего собственного.продолжайте держать нас в курсе, репортажи из дурдома крайне уместны на опеннете.
Зачем докеру поддерживать форматы которые даже из альфы толком не вышли лучше поддерживать хотя бы свой хорошо, что и так происходит с переменным успехом. А то что айбиэм выкинет все не угодные форматы это уже свершившийся факт, чего стоит что они выкинули из редхат все старые айбиэм архитектуры кроме S390.Хорошо хоть если ядро не тронет оно под GPL. А вот когда ты обмажешься своими подманами к тебе придёт письмо из айбиэм плати 10 000$ за ядро в год. А деваться тебе уже будет некуда.
а чем EULA от redhat была лучше?
Ничем.
После покупки шляпы можно считать что инициатива открытых контейнеров откатилась далеко взад.
Еще rkt дропнут.
Просто совещание на эту тему ещё не собрали. А так можно считать что одна экосистема один формат контейнеров и это не докер.
Никак. Но контейнеры переносимы между Docker и Podman.
> Пока докер не научится работать с открытым стандартом контейнеров можно закапывать.
> А вообще давно уже все юзают альтернативу в виде подмана с сыновьями.Да. Принимая во внимание масштабную поддержку докера от гугла в виде того же k8s, Ваше утверждение крайне сомнительно.
> ... масштабную поддержку докера от гугла в виде того же k8sВообще-то, кубернетес умеет ещё как минимум rkt и containerd.
С другой стороны, у докера есть Swarm, так что не кубернетесом единым...
Сварм не взлетел, так что пока kubernetes rules the world.
>> ... масштабную поддержку докера от гугла в виде того же k8s
> Вообще-то, кубернетес умеет ещё как минимум rkt и containerd.Да, вот только много ли Вы видели людей, которые используют k8s не совместно с docker?
> С другой стороны, у докера есть Swarm, так что не кубернетесом единым...
А разве swarm ещё шевелится?
а разве его не впилили в сам докер?
> а разве его не впилили в сам докер?Воу. А вот это для меня откровение. Возможно, надо дать ему шанс и посмотреть на него ещё разок.
Кто эти все? Я например никого не знаю кто бы это юзал.
Ты всегда пытаешься казаться умным, но получается наоборот. Предлагаю обратную тактику))
> Объявлена устаревшей поддержка драйверов хранения devicemapper и overlayА что сейчас рекомендуется использовать?
> А что сейчас рекомендуется использовать?overlay2
zfs или ceph
Исключительно вместе и под кубер
> Исключительно вместе и под куберугу, тут ведь данные точно не нужны.
Рeкомeндую зaнятьcя бoдиbuildингoм, вeсьма oздoрaвливaет (если без фанaтизма и без фaрмы)! ;)
Интересно, сколько в этой версии сломали старого и добавили новых косяков
То есть как это "не заботясь о формировании начинки контейнера"?
А "docker build" - эта команда что делает? Или докер, в понимании его создателей, окончательно превратился в игрушку для макак, таскающих образы из репозитория?
> То есть как это "не заботясь о формировании начинки контейнера"?не вырывайте цитаты из контектста - _позволяет_, не заботясь, далее по тексту.
> А "docker build" - эта команда что делает?
"не заботясь о формировании начинки", докидывает поверх неглядя хапнутого первого попавшегося мусора с докерхаба вашу поделку, должна же у вас быть какая-то своя? То есть - "позволяет", это не единственный возможный функционал, но наиболее востребованный целевой аудиторией.
> Или докер, в понимании его создателей, окончательно превратился в игрушку для макак,
> таскающих образы из репозитория?что значит "превратился"? Он ей всегда и был задуман, FROM scratch (преудивительный, заметьте, синтаксис) и появился-то в 14й, что-ли, только версии - для особых ценителей.
а что, вы сами что-ли хотите вот этот весь трэш и хлам собирать вручную?
беда докера-то вовсе не в этом, ЭТО - решает (ну, пытается решать) вполне реальную проблему, как запустить продукцию современных кодошлепов на соседнем компьютере, а не на том же самом, на котором он только что гордо закончил "разработку", и не тут же, а хотя бы через неделю.
Правда, они все равно умудряются сделать так, чтобы через неделю не запустилось.
> поверх неглядя хапнутого первого попавшегося мусора с докерхабаКак из моих слов следует "хапанье не глядя"? Во-первых, есть официальные образы, за доброкачественность которых ручаются создатели докера. Во-вторых, нет ничего сложного скачать, например, alpine minirootfs и сделать на нём образ с нужным софтом, если не доверяешь контейнерам в докеровском репо.
> Во-первых, есть официальные образы, за доброкачественность которых ручаются создатели докера.мамой клянутся!
Ваша ирония понятна, но устанавливая ПО этих разработчиков человек, как ни крути, им доверяет. Если же по какой-то причине пользователь докера не доверяем качеству образов (например, образы делают менее квалифицированные сотрудники, нежели те, кто пишут сам код, или образы делают энтузиасты со стороны, а статус официальных они получают без достаточной проверки) - есть вариант "from scratch".
> "позволяет", это не единственный возможный функционал, но наиболее востребованный целевой аудиториейЭто-то и печалит.
> Ваша ирония понятна, но устанавливая ПО этих разработчиков человек, как ни крути,
> им доверяет.а куда ж ты денешься - как известно, буква s в слове Docker означает "security", а вот r - что угодно, только не reliability.
> Если же по какой-то причине пользователь докера не доверяем
> качеству образов (например, образы делают менее квалифицированные сотрудники, нежелиа они одинаково неквалифицированные, или еще хуже - это один и тот же сотрудник, и код шлепать он еще хоть как-то обучен, а азам администрирования - вообще никак. А сборка образа - это именно администрирование, а не кодошлепство. Результат - контейнер без исходников вообще. И не потому что зажал, а потому что нету их вот. Он как-то, методом проб и ошибок, у себя на хосте все это вручную понасобрал в состояние "запускается", а потом просто скопировал внутрь то что получилось. Но это-то хотя бы работает.
У меня вот уже целая коллекция образов, которые при _старте_ контейнера начинают что-то там качать из этих вот ваших интернетов и пытаться (безрезультатно, ибо интернеты невечны) там что-то покомпилять. (отдельный вопрос - кто им обещал интернет)
То есть сляпавшие их обезьянки вообще не понимали, каково _единственное_ назначение образов. Просто у них так принято - любая ненужнохрень должна быть в виде докерфайла, а его содержимое никто не проверяет или проверяют такие же.Ну и FROM чегототам:latest (без :latest, просто они ничего там не указывают, либо по незнанию, либо сознательно) - вообще общепринятая практика. А что оно через неделю сломается, ибо stable api is nonsence - кодошлепа не колебет, он нагадил и улетел дальше развивать индустрию.
> У меня вот уже целая коллекция образов, которые...Ну так ведь это же и доказывает, что о формировании содержимого контейнера надо заботиться самым ответственным образом! Возможность запускать что-то произвольное не заботясь о формировании начинки контейнера - это иллюзия. Можно нарваться на образ с кодом, который в лучшем случае за деньги хостинг-арендатора будет что-нибудь майнить в пользу автора образа, в худшем - воровать номера кредиток.
> что-то там качать из этих вот ваших интернетов и пытаться <...> там что-то покомпилятьФейспалм.жэпэгэ. Где вы такое находите?
> Ну так ведь это же и доказывает, что о формировании содержимого контейнера надо заботитьсяи зачем нам тогда вся эта музыка с контейнерами?
Оно для того только и было пригодно, чтобы не думать. В смысле, о том, как уживется вся оказавшаяся внутри помойка с окружающей системой и соседними скриптами, внезапно, требующими перпендикулярных помоек.> Фейспалм.жэпэгэ. Где вы такое находите?
вот тут: https://hub.docker.com/ - тыщи их. (если не хватит - есть еще гитхаб, для ниасиливших push с авторизацией)
> беда докера-то вовсе не в этом, ЭТО - решает (ну, пытается решать)
> вполне реальную проблему, как запустить продукцию современных кодошлепов на соседнем компьютере,
> а не на том же самом, на котором он только что
> гордо закончил "разработку", и не тут же, а хотя бы через
> неделю.Нихт, эту проблему докер как раз НЕ решает. Поясняю: буквально недавно разрабы-вебники одного из моих проектов предоставили свой docker-compose.yml для интеграции с CI. Я посмотрел, и переделал вообще всё, потому что они были такими молодцами, что статику и скрипты в контейнер докидывали через монтирование git workdir прямо в контейнер. Я уж не говорю о том, что у них были вопиющие race condition-ы: порядок загрузки контейнеров оказывался жизненно важен для того, чтобы их поделие работало.
Докер же решает несколько иные проблемы. Как известно, софт нынче сложный, если не сказать переусложнённый. Контейнер обеспечивает идентичное окружение, чтобы этот переусложнённый софт вёл себя точно так, как задумано. Это в частности означает, что протестировав однажды контейнер можно быть в определённой степени уверенным, что подняв его на другой машине, с другой осью и т.п., он будет вести себя так, как задумано.
Само собой это не совсем правда, и выстрелить себе в ногу можно даже при использовании контейнеров. Но что уж поделать. Контейнеры тоже надо уметь строить. :)
о, до этой стадии мои подопечные еще не доросли.то есть, внезапно, и composer можно ухитриться использовать так, что ровно то, для чего он предназначен - автомагически возводить инфраструктуру из хитросвязанных контейнеров, работать не будет. Ну я подозревал, конечно, что так понакодить можно, теперь буду уверен.
скрипты в контейнер я, кстати, тоже беру из (внешнего) git - не вижу чем это плохо, контейнер им обеспечивает _среду_ выполнения, она меняется редко и должна быть тиражируемой. Он при обновлении даже не пересоздается - просто перезапускается, чтобы перечитались ro маунты (зачем и как авторы докера умудрились сделать их персистентными - у них спросите).
А сами скрипты кодеры могут менять хоть сто раз на дню - для того им гит и даден.> Это в частности означает, что протестировав однажды контейнер можно быть в определённой степени
> уверенным, что подняв его на другой машине, с другой осью и т.п., он будет вести себя так, как
> задумано.с современными системами можно только слабо надеяться, что подняв его на другой похожей машине с точной такой же осью он будет вести себя так же - не смотря на то что "точно такая же ось" не имеет стабильной версии и каждый раз после установки с нуля получается нетакойже и без всякой возможности вернуть как было (привет бубунточке и дебиану, великим экономам места в репо).
> FROM scratch (преудивительный, заметьте, синтаксис) и появился-то в 14й, что-ли, только версии - для особых ценителейНикто не мешал сделать tar с нуля и импортировать этот tar в виде image в docker.
и очень плохо что никто не мешал (и не мешает по сей день) - потому что при этом не остается никаких следов того, что наимпортили.
В результате и получаются образы с содержимым, мгновенно возникшим из ниоткуда, созданые неведомо кем, причем еще и докерфайл в этом случае не создается, а те параметры, что можно подделать из командной строки, весьма ограничены.А консистентного метода создания новых образов так и нет - кодошлепам некогда, они новую муру шлепают, и вообще, дадено же вам "from scratch", подумаешь, синтаксис уродлив.
Возможно говно мамонтовое которое работает на железе перенести в докер и запустить?
Смотря какое говно. Контейнер это не виртуалка, он использует ядро хоста. Так что, если старое ядро не нужно, а только старые библиотеки, то вполне. Если нужны старые ядра, то лучше пробовать qemu + kvm + проброс устройств.
Для этого лучше брать не докер, а systemd-nspawn или lxc: докер нужен для организации не самостоятельных контейнеров, а для наслоения друг на друга стандартных образов с экономией места и издержек при обновлении.
> Для этого лучше брать не докер, а systemd-nspawn или lxc: докер нужен
> для организации не самостоятельных контейнеров, а для наслоения друг на друга
> стандартных образов с экономией места и издержек при обновлении.Экономией чего, простите?
Нет там никакой экономии со стороны железа (диск, память, проц и т.п.), не волнуйтесь
Use KVM, Luke!
Запуская, я разрешаю!
"время поддержки выпуска увеличено с 4 до 7 месяцев" ОМГ!
А у нас в продакшене докер 3х летней давности крутится, т.к. в более поздних версиях "разработчики" что-то безвозвратно сломали.
Я свалил с продакшона на фриланс, и не жалею! Зарплата поднялась в 4 раза.
а что вместо devicemapper? глючный btrfs? overlay2?
kvm. Ну или хотя бы lxc, он, вроде ,поддерживает. И physical network attachment, afair, тоже - который из докера выпилен давным-давно, и тоже некоторые плакали-убивались.
Если вам понадобился devicemapper - вы явно используете докер не для того, для чего планировали разработчики.
А вместо девмаппера пойду-ка в доту погамаю!
Они наконец исправили дуплище, которое через -v /etc:/test позволяет cat /test/shadow из хостовой системы? или так и кладут на это?
> Они наконец исправили дуплище, которое через -v /etc:/test позволяет cat /test/shadow из
> хостовой системы? или так и кладут на это?Не кладут, а тщательно планирют этим заняться сразу после переименования в dockerS -- без 's' в названии тут никак не обойтись.
так и кладут - с пробором, потому что "если ты дал левому пользователю доступ к docker socket'у - ты дал ему рута" (миллионом возможных способов, а не только cat).В принципе, все в рамках концепции - оно не предназначено для изоляции _пользователей_, тем более - заведомо засланных казачков. Оно предназначено для изоляции процессов - запущенное в контейнере без -v /etc:чтонибудь - до твоего /etc гарантированно не доберется. Другое дело, что оно и тут недоделанное :-(
Это опенсорс детка, исходники в руки и вперед.
> Они наконец исправилиВы же сами пишите mount --bind /etc /test (-v /etc:/test), что вы тут исправлять, простите, хотите? Что бы mount вам запрещал это делать?
дурачек
Докер это сила!