Компания Red Hat представила (http://investors.redhat.com/releasedetail.cfm?ReleaseID=918711) результаты опроса корпоративных заказчиков о планах по внедрению контейнеров приложений. Проведенный компанией TechValidate по заказу Red Hat опрос, в котором приняли участие 338 лиц, принимающих решения, и технических ИТ-специалистов из различных организаций, включая компании Fortune 500 и органы власти, показал, что, несмотря на прогнозируемый на ближайшие годы всплеск числа внедрений, обеспокоенность вопросами безопасности и сертификации контейнеров, а также подготовки специалистов сохраняется. На решение этих проблем и ориентирована программа сертификации контейнеров Red Hat.
Результаты опроса демонстрируют твердые намерения корпоративных заказчиков по переходу на технологию контейнеров: 67% респондентов планируют ее промышленное внедрение в течение следующих двух лет. Опрошенные планируют использовать приложения на основе контейнеров в роли облаков (50%), а также в составе веб-решений и систем электронной торговли (56%).
Главными преимуществами технологии контейнеров по результатам опроса стали преимущества при разработке приложений: наибольшее количество голосов (по 60%) получили два таких фактора, как сокращение сроков развертывания и снижение затрат на развертывание. 44% опрошенных рассматривают контейнеры в качестве средства консолидации имеющихся серверов. В качестве предпочтительного метода развертывания респонденты чаще всего называют виртуальные машины: 83% опрошенных планируют развертывание контейнерных приложений поверх виртуальных сред, подтверждая тем самым, что организации оценили преимущества совместного использования контейнеров и виртуализации по сравнению с применением только одной из этих двух технологий.
Однако, несмотря на твердое намерение перейти на технологию контейнеров, корпоративные заказчики, судя по результатам опроса, обеспокоены нерешенностью ряда вопросов, таких как:
- Безопасность и отсутствие сертификации / подтверждения происхождения контейнеров (60%);
- Интеграция с имеющимися средствами и процессами разработки (58%);
- Управление (55%);
- Знания и навыки персонала (54%).
В заключение отметим, что ПО с открытым исходным кодом сохраняет доминирующее положение в мире контейнерных приложений: более 95% опрошенных планирует внедрять контейнеры на базе операционных систем Linux. При этом лидирующая роль при переходе на контейнерные приложения, по результатам опроса, отводится разработчикам (39%) или менеджерам среднего уровня 36%), а высшее руководства и ИТ-директоры принимают ограниченное участие в этом процессе.Тим Итон (Tim Yeaton), старший вице-президент по инфраструктурным решениям Red Hat, сообщил «При всей очевидности растущего интереса корпоративных заказчиков к контейнерным приложениям, отмеченные участниками опроса проблемы дополнительно подчеркивают важность собственной стратегии Red Hat в этой области. Эта стратегия направлена на решение проблем безопасности и сертификации, обеспечение надежного управления контейнерами вне зависимости от платформы развертывания, создание инструментов и методов, позволяющих организациям выработать навыки, необходимые для успешной реализации преимуществ Linux-контейнеров.
Контейнеры, безусловно, серьезно меняют парадигму разработки и развертывания корпоративных приложений, как при использовании в качестве средства модернизации имеющихся приложений до уровня принципиально новых облачных рабочих нагрузок или веб-решений, так и при переходе к методологии DevOps. Повышенное внимание к перечисленным выше проблемам, которые являются предметом обеспокоенности корпоративных заказчиков, может подстегнуть массовое промышленное внедрение контейнерных приложений, и компания Red Hat уже сегодня готова выступить в качестве опытного и надежного партнера, который поможет организациям войти в мир новых ИТ-технологий».
URL: http://investors.redhat.com/releasedetail.cfm?ReleaseID=918711
Новость: http://www.opennet.me/opennews/art.shtml?num=42489
Что-то мне кажется, что значимость контейнеров сильно преувеличена. Классическая виртуализация (kvm, xen, vmware) - это достигнутый оптимальный уровень виртуализации. Для чего вы используете контейнеры? Как произовдится обновления безопасности?
Контейнеры легковесные, легко деплоить/изменять
Когда приходится их менять очень часто
Но если изменения идут раз в год, или раз в месяц обычные Chef или puppet гораздо эффективней
С вами не согласен.
Контейнерная виртуализация позволяет быстрее поднимать сервисы, даёт максимально возможную производительность(актуально для линукса). Обновление - пересборка докер-контейнера со старыми данными. В наше время вообще принято отделять софт от изменяемых данных(одна из парадигм ДевОПС).По поводу безопасности - да, она будет явно ниже, чем у систем с аппаратной виртуализации.
Насчёт xen - не актуален нигде кроме амазона, хотя идея была хорошей.
Насчёт vmware - эталонное "ненужно". Геморрой, глюки и тормоза, притом за деньги. Не хочу. Неосилившим kvm проще написать управляющую прослойку для виртуалбокса, преимущества будут во всём(замечу, что ни vmware, ни виртуалбокс для построения облаков не годятся, но здесь цель приследуется явно другая).
> Насчёт vmware - эталонное "ненужно". Геморрой, глюки и тормоза, притом за деньги. Не хочу. Неосилившим kvm проще написать управляющую прослойку для виртуалбокса, преимущества будут во всём(замечу, что ни vmware, ни виртуалбокс для построения облаков не годятся, но здесь цель приследуется явно другая).С чего Вы взяли, что "то лучше, чем это", когда и там, и там лежит в основе linux && libvirt?
Датацентр из 350 серверов. Глюков, геморроя, тормозов нет. Миграция и балансинг ресурсов хостов работают на ура. К 6 версии допилили нормальный фэйловер (в виде HA), но пока, увы, нет нигде 10 Gb-оптики, дабы его потестить. На очереди load-balancing через vSwitch.
vmWare VCloud умеет облака ещё с 5.0 версии, но внутри корпораций IaaS для себя самих не нужны.Да, я "продался", не отрицаю, но конторе дешевле раз заплатить за лицензию vmware, чем оплачивать админов, поднимающих/ребутающих/мигрирующих kvm-машины "на коленке" и прикручивающих к ним openstack.
- IaaS внутри корпораций как раз-то нужны. Сильно захочется вам хранить видеоархив "сами знаете чего" размером в несколько петабайт в амазоне? Что по этому поводу думает пиндосское законодательство? Хотя там бывают и исключения.
- Разворачивание и поддержка опенстековского облака всегда сильно дешевле вымытой вари по деньгам.
- Я из тех, кто раньше писал скрипты для "мёртвой миграции", но сейчас живая миграция уже работает.
- В конторе, где я сейчас работаю, происходит глобальный отказ от вымытой вари в пользу опенстека, даже несмотря на то, что это древний устоявшийся и отстоявшийся кровавый ЪЫнтъръпрайзъ! Я в этом процессе тоже замешан.
- На вмварю вменяемый админ/девопс даже не посмотрит, ибо шиндозный управлятор - это основное предупреждение, которое чётко и неиллюзорно намекает.
Вопрос не в деньгах, а смене технологий. У нас тоже как-то предлагали OpenStack+kvm в качестве замены vmWare, но из-за возможных простоев руководство "очкануло" и сказало, мол, нельзя, невыгодно и ненадёжно, ага.Про живую миграцию на kvm в курсе, но раз уж заговорили: есть ли для kvm решение вроде high availability (хост умер, машины автоматом поднялись на другом)?
Управлятор (сфера) уже давно перешёл на веб, "толстый" клиент также на фреймах, но, да, только под оффтопик. Вообще, vmWare хотят полностью перейти на веб-клиент, где-то у них читал.
> Про живую миграцию на kvm в курсе, но раз уж заговорили: есть ли для kvm решение вроде high availability (хост умер, машины автоматом поднялись на другом)?https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...
>Насчёт xen - не актуален нигде кроме амазонаБольшое количество VPS провайдеров предлагают именно xen. Из крупнейших Linode.
> Большое количество VPS провайдеров предлагают именно xen. Из крупнейших Linode.До них тоже дошло что kvm лучше.
https://forum.linode.com/viewtopic.php?f=26&t=11818
Лучше KVM чем XEN или нет я не знаю, но уязвимость VENOM (CVE-2015-3456) накрывает обоих
he Floppy Disk Controller (FDC) in QEMU, as used in Xen 4.5.x and earlier and KVM, allows local guest users to cause a denial of service (out-of-bounds write and guest crash) or possibly execute arbitrary code via the (1) FD_CMD_READ_ID, (2) FD_CMD_DRIVE_SPECIFICATION_COMMAND, or other unspecified commands, aka VENOM.https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3456
>>Насчёт xen - не актуален нигде кроме амазона
> Большое количество VPS провайдеров предлагают именно xen. Из крупнейших Linode.С разморозкой! Продолжайте излагать последние новости 2010 года, мы с удовольствием послушаем :)
Я вас научу быстро поднимать и обновлять сервисы)
Храните все необходимые библиотеки, бинарники, зависимости и код в одном каталоге или лучше разделе.
Пропишите их в переменных окружения среды.
Обновляйте каталог с помощью git, sync и т.д. или синкайте всё блочное устройство.Подготовить подобную схему разливки не дольше чем Dockerfile создать, оттестировать и сбилдить.
По безопасности так будет в разы лучше, так как все компоненты сервиса запускаются не под привилегированным пользователем.
>Что-то мне кажется, что значимость контейнеров сильно преувеличена.А мне кажется нет.
>Классическая виртуализация (kvm, xen, vmware) - это достигнутый оптимальный уровень виртуализацииПотребление от 200 мб оперативной памяти и от 1 Gb на диске на VM трудно назвать "оптимальным уровнем".
>Как произовдится обновления безопасности
Я использую yum update -y (в контейнерах).
Кстати о безопасности. Список уязвимостей исправленных в xenserver в этом месяце
• CVE-2015-4106 (Medium): Unmediated PCI register access in qemu.
• CVE-2015-4163 (Medium): GNTTABOP_swap_grant_ref operation misbehavior.
• CVE-2015-4164 (Medium): vulnerability in the iret hypercall handler
• CVE-2015-2756 (Low): Unmediated PCI command register access in qemu
• CVE-2015-4103 (Low): Potential unintended writes to host MSI message data field via qemu.
• CVE-2015-4104 (Low): PCI MSI mask bits inadvertently exposed to guests.
• CVE-2015-4105 (Low): Guest triggerable qemu MSI-X pass-through error messages
Если нужно организовать работу кластера без сбоев, a la high availability, то есть большая разница, что таскать межу нодами - контейнерные diff-ы весом в сотни мегабайт или тяжелые VA/vmdk/ovf.
> Если нужно организовать работу кластера без сбоев, a la high availability, то
> есть большая разница, что таскать межу нодами - контейнерные diff-ы весом
> в сотни мегабайт или тяжелые VA/vmdk/ovf.А можно вообще запилить виртуалки с nfs root и ничего не таскать совсем.
>> Если нужно организовать работу кластера без сбоев, a la high availability, то
>> есть большая разница, что таскать межу нодами - контейнерные diff-ы весом
>> в сотни мегабайт или тяжелые VA/vmdk/ovf.
> А можно вообще запилить виртуалки с nfs root и ничего не таскать совсем.Хорошая "работа кластера без сбоев" получится, когда этот nfs server упадет.
NFS-сервер достаточно легко делается резервированным.
pNFS
Для решения проблемы с dll/so-hell.
Возможно, offtopic, но объясните мне (в виде ссылок, например), чем1. развертывание контейнеров лучше чем привычная установка приложения из пакетов,
2. что такое DevOps и чем он отличается от работы обычного сисадмина, который занимается установкой (развертыванием), настройкой и обслуживанием софта на рабочих серверах.
Раньше контейнеры использовались хостерами, чтобы предоставлять услуги кому попало (т.е. когда нет никакого контроля за тем кто и что запускает) и ограничить их влияние на других пользователей по потреблению ресурсов сильнее, чем простым chroot. Для создания ограничений собственному софту есть cgroups. Зачем тут контейнеры я не догоняю. Видимо, кто-то просто не осилил настроить cgroups. Но что-то мне кажется, что я что-то упускаю...
С DevOps ситуация, думаю, еще проще - это новый модный термин под которым каждый понимает что-то свое. Т.е. если собрать 3-х человек и спросить, что такое DevOps, то получим 4 разных мнения.
В любом случае, хочу понять, что это за модные веяния и что я упускаю. Итак вопросы: зачем сейчас используются контейнеры при развертывании софта и кто такой DevOps по сравнению с обычным сисадмином.
>развертывание контейнеров лучше чем привычная установка приложения из пакетов,А если пакетов нет? Куча софта который официально поддерживает только убунту.
>что такое DevOpsВсе просто. Это сисадмин не аутист.
> Возможно, offtopic, но объясните мне (в виде ссылок, например), чем
> 1. развертывание контейнеров лучше чем привычная установка приложения из пакетов,готовый контейнер, по их мнению, запускается быстрее чем создание и настройка виртуалки с установкой пакетов. Тут непонятно, накой хер всё каждый раз пересоздавать.
> 2. что такое DevOps и чем он отличается от работы обычного сисадмина,
> который занимается установкой (развертыванием), настройкой и обслуживанием софта на рабочих серверах.Среди хипсторского мозгового поноса о хипсторских бирюльках можно разобрать, что часть админовой работы берут на себя разработчики со своими жуткими взглядами на жизнь, а часть разработок ковыряет админ. Причём в последнее время кодеришки решили, что все админские задачи можно решить только при помощи своих безумных программерских поделий и кода.
> Тут непонятно, накой хер всё каждый раз пересоздавать.Пересоздание контейнера будет сделано из обновлённых слоёв, а вообще - это очень быстро и заменяет поцедуру вкл/выкл виртуалки. Данные хранятся отдельно.
>> 2. что такое DevOps и чем он отличается от работы обычного сисадмина,
>> который занимается установкой (развертыванием), настройкой и обслуживанием софта на рабочих серверах.
> Среди хипсторского мозгового поноса о хипсторских бирюльках можно разобрать, что часть
> админовой работы берут на себя разработчики со своими жуткими взглядами на
> жизнь, а часть разработок ковыряет админ. Причём в последнее время кодеришки
> решили, что все админские задачи можно решить только при помощи своих
> безумных программерских поделий и кода.Да, я один из тех хипстеров, которые девопсы. Я не вижу физических серваков, ибо их ковыряют местные админы, которые могут только поставить ОСь и выдать кренделя с адресом. Потом есть Virtualization engineers, которые деплоят опенстек и дают мне тенанты, с ними связан аккаунтинг-отдел. Есть монопсы, вставляющие всюду свои зонды из генетически-модифицированного нагиоса. И нетопсы, или просто сетевики.
За последнее время просто повысилось количество абстракций.
> Пересоздание контейнера будет сделано из обновлённых слоёв, а вообще - это очень
> быстро и заменяет поцедуру вкл/выкл виртуалки. Данные хранятся отдельно.Пакеты в виртуалке обновляются на ходу, и максимум, что нужно сделать — перезапустить севис.
Данные хранятся где угодно.> Да, я один из тех хипстеров, которые девопсы.
Не, ты недостаточно девопс, надо больше безумных терминов.
1) Не совсем, содержимое последнего слоя надо или обновить, или пересоздать. Он не подтянется за содержимым базовых слоёв.
2) Тоже хороший вариант.
3) Таки да, учту на будущее.
А в виртуалку собственный софт вместе с операционкой запихивают, я так понимаю, чтобы его можно было запустить на любом дистрибутиве. И плевать что он места больше занимает как на диске, так и в оперативке, да и на обеспечение виртуализации ресурсы тратятся (CPU в том числе).Но все равно не понятно, почему бы для своего софта не использовать определенный дистрибутив? Кроме того, если раньше админу нужно было обновлять операционку только на физической машине (где работают несколько приложений), то теперь нужно следить за содержимым каждой виртуалки.
P.S. Я реально пытаюсь осмыслить причину этой новой тенденции, т.к. тенденция есть, активно развивается, значит у нее есть причина. Теперь хочется ее понять, т.е. кому и для чего это надо...
> Но все равно не понятно, почему бы для своего софта не использовать определенный дистрибутив?можно, в том числе внутри контейнера (если это дистрибутивы линукс)
> Кроме того, если раньше админу нужно было обновлять операционку только на физической машине (где работают несколько приложений), то теперь нужно следить за содержимым каждой виртуалки.
зато меньше шансов сломать работу приложения при обновлении, если разделить их по контейнерам и обновлять отдельно. Также можно разделять общие системные каталоги между контейнерами (через ro bind mount) и обновлять сразу группу контейнеров.
По сравнению с kvm, xen - низкие накладные расходы без необходимости в hardware virtualization, простая настройка (в том числе легкий проброс железа в контейнер). Зависит от конкретного сценария использования.
Вот бы ещё контейнеры были не дырявые как в докеровых залежах, и при этом удобные как тот же докер
> Вот бы ещё контейнеры были не дырявые как в докеровых залежах, и
> при этом удобные как тот же докерЧто то мешает зайти в контейнер и сделать apt-get upgrade||yum update ?
Грех это. Контейнер должен быть иммутабелен.
Образ(Image) должен быть "иммутабелен" контейнер это как раз "мутабеленый" образ.
Из пропатченного контейнера делается образ с помощью docker commit.
> Образ(Image) должен быть "иммутабелен" контейнер это как раз "мутабеленый" образ.
> Из пропатченного контейнера делается образ с помощью docker commit.В том-то и дело, что докероводы против, они у себя на сайте считают, что надо только образы перекачивать, а уязвимостей у них на самом деле нет.
Оналитеги не знают что так можно делать.
> Оналитеги не знают что так можно делать.Не, оналитеги про это знают. Но зато они не знают, что оно проживает только до следующей остановки контейнера.
# docker start
Start one or more stopped containers
# docker commit
Create a new image from a container's changes
Надо курить маны Карл. Маны.
И толку? Оно сбросится после перезапуска.
Образ надо заново билдить.
> И толку? Оно сбросится после перезапуска.
> Образ надо заново билдить.ITT люди которые пользуются докером не прочитав даже начальный гайд.
man docker stop/start/restart
man docker commit
man docker push
>> И толку? Оно сбросится после перезапуска.
>> Образ надо заново билдить.
> ITT люди которые пользуются докером не прочитав даже начальный гайд.
> man docker stop/start/restart
> man docker commit
> man docker push
>Can't stack more than 42 aufs layersТак я и говорю, что никто маны не читает, ясно же написано:
The aufs Backend
The aufs backend uses the aufs union filesystem. This is not supported on the upstream kernel and most distributions (including any from Red Hat), and thus is not recommended as a production filesystem. It is the original backend for Docker and commonly used on Ubuntu based distributions.
Что не понятного в "aufs ... is not recommended as a production filesystem"?
AUFS - это бекэнд докера доступеный только для Ubuntu. Для остальных дистрибутивов:
$sudo docker info
Containers: 139
Images: 600
Storage Driver: devicemapper <- обратите внимание.Совет от меня: если хотите сберечь нервы и время, не используйте Ubuntu в "продакшене". Никогда.
Удачи.
пора со стороны сообщества пользователей тоже создавать программы сертификации предлагаемых продуктов и услуг
А какие продукты и услуги может предложить сообщество _пользователей_?На ум приходит только услуга по тестированию ПО.
RHEL на утюге и чайнике