Спасибо. Читал об этом в комментариях opennet'а, но не увидел конкретной записи в release notes, поэтому написать забыл. Если правильно всё понял, было частью node-local в Swarm (#32981 в Moby) (#1675 в libnetwork).
Спасибо, исправил в тексте на: «Главной фичей релиза стала официальная стабилизация поддержки многоэтапных сборок (multi-stage builds), впервые представленных в Docker 17.05.0».
Про eBay я находил упоминания Mesos от 2014 года, а с 2015 гуглится уже Kubernetes. Здесь пишут так (кстати, прямо в пику утверждений о зрелости проектов :-)):
At the time eBay started searching for an answer, Docker Swarm had yet to emerge, Mesos was a young open source code project (later supported and productized through the firm Mesosphere) and Kubernetes was just emerging from Google's halls. Early in 2016, having played the field, eBay settled on Kubernetes as the most mature option.
А вот достаточно свежее (2017 год), что всё-таки k8s.
Про крупных пользователей не могу с вами согласиться. Разве уже упомянутый Google с GCE — не пример крупной компании? Red Hat с OpenShift? Huawei? eBay?
Спасибо за полезный комментарий. Конкретные фичи, которые предлагает k8s, очень кратко описаны в докладе (на него ссылка в конце статьи). А для больших подробностей планируем цикл, потому что в одну статью это не уложишь.
Краткая суть, которую хотели здесь донести: основное предназначение k8s — предоставить всё необходимое для построения/обеспечения функций PaaS на её основе (а не только то, что нужно в каком-то одном конкретном или нескольких применениях — уж для этого существуют разные PaaS с более специализированным набором фич).
Если у вас есть реальный опыт и ваш вопрос не был самоцелью, поделитесь, пожалуйста, личным видением этого вопроса — тем более, если он сильно отличается или сильно более понятен. Всем на пользу пойдёт.
Предназначение Kubernetes как платформы — предоставить базовую, абстрактную платформу как услугу (Platform as a Service, PaaS), сохранив гибкость в выборе конкретных компонентов этой PaaS.
Или вот: «в Kubernetes первичен универсальный, абстрактный подход». И вот: «платформа является модульной и предлагает пользователям самим выбирать конкретные решения для тех или иных задач». И в конце пример со стандартной библиотекой и фундаментом…
Не увидел в вашем списке одно из ключевых нововведений по мнению самих разработчиков ;-)
Thanks to the Reproducible Builds project, over 90% of the source packages included in Debian 9 will build bit-for-bit identical binary packages. This is an important verification feature which protects users from malicious attempts to tamper with compilers and build networks. Future Debian releases will include tools and metadata so that end-users can validate the provenance of packages within the archive.
[..] это обновления безопасности для PostgreSQL. В стандартной конфигурации Ubuntu Server [..] автоматическое обновление критичных уязвимостей в этой СУБД приводило к её рестарту в то время, когда не все этого ожидали.
Автор этой истории, кстати, пишет, что связаться с HR'ом ему даже не дали: «I haven't heard from HR, or anything and i am panicking to high heavens». Т.е. CTO психанул и решил всё, минуя этого самого HR.
Про «security updates» у нас в самом начале, где рассказывается, что по умолчанию unattended upgrades настроен только на них.
То, что вы называете руганью, таковой тоже не является — ну, я это так не воспринял, например, да и автор, думаю, тоже в виду не имел… Это предупреждение о том, что нужно учитывать, если использовать unattended upgrades не только по умолчанию. И уж точно не «тяжелое обвинение», если читать всё внимательно. В приведённой цитате вы опять упускаете из вида следующее предложение, на которое я уже указал и которое всё уточняет.
На правах редактора исправил «Итак, какие возможности предоставляют…» на «Итак, какие дополнительные возможности предоставляют…». Надеюсь, это снимет возможную двусмысленность для тех, кто читает иначе.
Нет тут тяжёлых обвинений. Цитата, которую вы приводите, не утверждает такого в контексте конкретно security updates — она про «вообще». В следующем после неё предложении написано: «Собирая или заимствуя пакет в свой репозиторий, помните…», — а не «Включая/оставляя unattended upgrades для security updates, помните…».
Я не думаю, что все несколько тысяч людей, поставивших плюсики новому awless, не слышали про Terraform ;-) Это всё-таки решение совсем другого масштаба (пусть не лучший критерий, но я не поленился сравнить объёмы репозиториев: 31M против 339M — ровно на порядок!). В реальности, как правило, сосуществуют решения более простые-узкоспециализированные-прикладные и более сложные-универсальные. Ведь разные люди выбирают разное, причём даже в тех случаях, когда разницы сильно меньше, чем между awless и terraform (достаточно взглянуть на зоопарк Linux-дистрибутивов). Вопрос удобства тоже субъективен (зависит не только от предпочтений, но и специфики применения).
Надстройки над veth — да. Для контейнера создаётся network namespace, интерфейсы которого управляются с помощью плагинов CNI. Вот из спецификации:
A CNI plugin is responsible for inserting a network interface into the container network namespace (e.g. one end of a veth pair) and making any necessary changes on the host (e.g. attaching other end of veth into a bridge).
Calico, Flannel и т.п. — это просто дополнительные плагины, которых может и не быть. Вот есть просто «обычный» (встроенный в CNI плагин) macvlan.
Во второй конец veth могут вставляться разные решения, что как раз и реализуется плагинами.
Да. У нас при наборе DevOps-инженеров этого [т.е. наличия способностей к программированию при отсутствии опыта профессиональной разработки] не раз бывало достаточно, и всё получалось.
А вот достаточно свежее (2017 год), что всё-таки k8s.
Совсем недавно было про Oracle.
Если у вас есть реальный опыт и ваш вопрос не был самоцелью, поделитесь, пожалуйста, личным видением этого вопроса — тем более, если он сильно отличается или сильно более понятен. Всем на пользу пойдёт.
Или вот: «в Kubernetes первичен универсальный, абстрактный подход». И вот: «платформа является модульной и предлагает пользователям самим выбирать конкретные решения для тех или иных задач». И в конце пример со стандартной библиотекой и фундаментом…
Подробнее о проекте — reproducible-builds.org
То, что вы называете руганью, таковой тоже не является — ну, я это так не воспринял, например, да и автор, думаю, тоже в виду не имел… Это предупреждение о том, что нужно учитывать, если использовать unattended upgrades не только по умолчанию. И уж точно не «тяжелое обвинение», если читать всё внимательно. В приведённой цитате вы опять упускаете из вида следующее предложение, на которое я уже указал и которое всё уточняет.
На правах редактора исправил «Итак, какие возможности предоставляют…» на «Итак, какие дополнительные возможности предоставляют…». Надеюсь, это снимет возможную двусмысленность для тех, кто читает иначе.
Заходите поболтать про Docker, Kubernetes и прочие DevOps-радости, а также принять участие в конкурсах по теме ;-)
Calico, Flannel и т.п. — это просто дополнительные плагины, которых может и не быть. Вот есть просто «обычный» (встроенный в CNI плагин) macvlan.
Во второй конец veth могут вставляться разные решения, что как раз и реализуется плагинами.