The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Результаты опроса Red Hat, касающегося внедрения Linux-контейнеров

24.06.2015 12:19

Компания Red Hat представила результаты опроса корпоративных заказчиков о планах по внедрению контейнеров приложений. Проведенный компанией 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 уже сегодня готова выступить в качестве опытного и надежного партнера, который поможет организациям войти в мир новых ИТ-технологий».

  1. Главная ссылка к новости (http://investors.redhat.com/re...)
Лицензия: CC BY 3.0
Источник: Red Hat
Короткая ссылка: https://opennet.ru/42489-redhat
Ключевые слова: redhat
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (44) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Аноним (-), 13:38, 24/06/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Что-то мне кажется, что значимость контейнеров сильно преувеличена. Классическая виртуализация (kvm, xen, vmware) - это достигнутый оптимальный уровень виртуализации. Для чего вы используете контейнеры? Как произовдится обновления безопасности?
     
     
  • 2.4, algerd (ok), 13:48, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Контейнеры легковесные, легко деплоить/изменять
     
     
  • 3.39, badmilkman (ok), 09:32, 25/06/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Когда приходится их менять очень часто
    Но если изменения идут раз в год, или раз в месяц обычные Chef или puppet гораздо эффективней
     
  • 2.5, Аноним (-), 13:57, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • +8 +/
    С вами не согласен.
    Контейнерная виртуализация позволяет быстрее поднимать сервисы, даёт максимально возможную производительность(актуально для линукса). Обновление - пересборка докер-контейнера со старыми данными. В наше время вообще принято отделять софт от изменяемых данных(одна из парадигм ДевОПС).

    По поводу безопасности - да, она будет явно ниже, чем у систем с аппаратной виртуализации.

    Насчёт xen - не актуален нигде кроме амазона, хотя идея была хорошей.

    Насчёт vmware - эталонное "ненужно". Геморрой, глюки и тормоза, притом за деньги. Не хочу. Неосилившим kvm проще написать управляющую прослойку для виртуалбокса, преимущества будут во всём(замечу, что ни vmware, ни виртуалбокс для построения облаков не годятся, но здесь цель приследуется явно другая).

     
     
  • 3.9, tensor (?), 14:23, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Насчёт vmware - эталонное "ненужно". Геморрой, глюки и тормоза, притом за деньги. Не хочу. Неосилившим kvm проще написать управляющую прослойку для виртуалбокса, преимущества будут во всём(замечу, что ни vmware, ни виртуалбокс для построения облаков не годятся, но здесь цель приследуется явно другая).

    С чего Вы взяли, что "то лучше, чем это", когда и там, и там лежит в основе linux && libvirt?
    Датацентр из 350 серверов. Глюков, геморроя, тормозов нет. Миграция и балансинг ресурсов хостов работают на ура. К 6 версии допилили нормальный фэйловер (в виде HA), но пока, увы, нет нигде 10 Gb-оптики, дабы его потестить. На очереди load-balancing через vSwitch.
    vmWare VCloud умеет облака ещё с 5.0 версии, но внутри корпораций IaaS для себя самих не нужны.

    Да, я "продался", не отрицаю, но конторе дешевле раз заплатить за лицензию vmware, чем оплачивать админов, поднимающих/ребутающих/мигрирующих kvm-машины "на коленке" и прикручивающих к ним openstack.

     
     
  • 4.25, Аноним (-), 17:23, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    - IaaS внутри корпораций как раз-то нужны. Сильно захочется вам хранить видеоархив "сами знаете чего" размером в несколько петабайт в амазоне? Что по этому поводу думает пиндосское законодательство? Хотя там бывают и исключения.
    - Разворачивание и поддержка опенстековского облака всегда сильно дешевле вымытой вари по деньгам.
    - Я из тех, кто раньше писал скрипты для "мёртвой миграции", но сейчас живая миграция уже работает.
    - В конторе, где я сейчас работаю, происходит глобальный отказ от вымытой вари в пользу опенстека, даже несмотря на то, что это древний устоявшийся и отстоявшийся кровавый ЪЫнтъръпрайзъ! Я в этом процессе тоже замешан.
    - На вмварю вменяемый админ/девопс даже не посмотрит, ибо шиндозный управлятор - это основное предупреждение, которое чётко и неиллюзорно намекает.
     
     
  • 5.37, tensor (?), 04:21, 25/06/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вопрос не в деньгах, а смене технологий. У нас тоже как-то предлагали OpenStack+kvm в качестве замены vmWare, но из-за возможных простоев руководство "очкануло" и сказало, мол, нельзя, невыгодно и ненадёжно, ага.

    Про живую миграцию на kvm в курсе, но раз уж заговорили: есть ли для kvm решение вроде high availability (хост умер, машины автоматом поднялись на другом)?

    Управлятор (сфера) уже давно перешёл на веб, "толстый" клиент также на фреймах, но, да, только под оффтопик. Вообще, vmWare хотят полностью перейти на веб-клиент, где-то у них читал.

     
     
  • 6.44, Аноним (-), 14:49, 25/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Про живую миграцию на kvm в курсе, но раз уж заговорили: есть ли для kvm решение вроде high availability (хост умер, машины автоматом поднялись на другом)?

    https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/

    http://www.proxmox.com

     
  • 3.11, Аноним (-), 14:25, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Насчёт xen - не актуален нигде кроме амазона

    Большое количество VPS провайдеров предлагают именно xen. Из крупнейших Linode.

     
     
  • 4.14, anonnon (?), 14:29, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Большое количество VPS провайдеров предлагают именно xen. Из крупнейших Linode.

    До них тоже дошло что kvm лучше.
    https://forum.linode.com/viewtopic.php?f=26&t=11818

     
     
  • 5.16, Аноним (-), 15:01, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Лучше 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

     
  • 4.31, Аноним (-), 20:33, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>Насчёт xen - не актуален нигде кроме амазона
    > Большое количество VPS провайдеров предлагают именно xen. Из крупнейших Linode.

    С разморозкой! Продолжайте излагать последние новости 2010 года, мы с удовольствием послушаем :)

     
  • 3.18, SunXE (ok), 15:35, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Я вас научу быстро поднимать и обновлять сервисы)
    Храните все необходимые библиотеки, бинарники, зависимости и код в одном каталоге или лучше разделе.
    Пропишите их в переменных окружения среды.
    Обновляйте каталог с помощью git, sync и т.д. или синкайте всё блочное устройство.

    Подготовить подобную схему разливки не дольше чем Dockerfile создать, оттестировать и сбилдить.
    По безопасности так будет в разы лучше, так как все компоненты сервиса запускаются не под привилегированным пользователем.

     
  • 2.6, Аноним (-), 14:05, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • +6 +/
    >Что-то мне кажется, что значимость контейнеров сильно преувеличена.

    А мне кажется нет.
    >Классическая виртуализация (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

     
  • 2.7, Аноним (-), 14:16, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если нужно организовать работу кластера без сбоев, a la high availability, то есть большая разница, что таскать межу нодами - контейнерные diff-ы весом в сотни мегабайт или тяжелые VA/vmdk/ovf.
     
     
  • 3.22, Аноним (-), 16:45, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Если нужно организовать работу кластера без сбоев, a la high availability, то
    > есть большая разница, что таскать межу нодами - контейнерные diff-ы весом
    > в сотни мегабайт или тяжелые VA/vmdk/ovf.

    А можно вообще запилить виртуалки с nfs root и ничего не таскать совсем.

     
     
  • 4.30, Аноним (-), 20:32, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> Если нужно организовать работу кластера без сбоев, a la high availability, то
    >> есть большая разница, что таскать межу нодами - контейнерные diff-ы весом
    >> в сотни мегабайт или тяжелые VA/vmdk/ovf.
    > А можно вообще запилить виртуалки с nfs root и ничего не таскать совсем.

    Хорошая "работа кластера без сбоев" получится, когда этот nfs server упадет.

     
     
  • 5.38, Аноним (-), 07:47, 25/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    NFS-сервер достаточно легко делается резервированным.
     
  • 5.41, Аноним (-), 12:55, 25/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    pNFS
     
  • 2.15, as (??), 14:40, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Для решения проблемы с dll/so-hell.
     

  • 1.8, Аноним (-), 14:23, 24/06/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Возможно, offtopic, но объясните мне (в виде ссылок, например), чем

    1. развертывание контейнеров лучше чем привычная установка приложения из пакетов,

    2. что такое DevOps и чем он отличается от работы обычного сисадмина, который занимается установкой (развертыванием), настройкой и обслуживанием софта на рабочих серверах.

    Раньше контейнеры использовались хостерами, чтобы предоставлять услуги кому попало (т.е. когда нет никакого контроля за тем кто и что запускает) и ограничить их влияние на других пользователей по потреблению ресурсов сильнее, чем простым chroot. Для создания ограничений собственному софту есть cgroups. Зачем тут контейнеры я не догоняю. Видимо, кто-то просто не осилил настроить cgroups. Но что-то мне кажется, что я что-то упускаю...

    С DevOps ситуация, думаю, еще проще - это новый модный термин под которым каждый понимает что-то свое. Т.е. если собрать 3-х человек и спросить, что такое DevOps, то получим 4 разных мнения.

    В любом случае, хочу понять, что это за модные веяния и что я упускаю. Итак вопросы: зачем сейчас используются контейнеры при развертывании софта и кто такой DevOps по сравнению с обычным сисадмином.

     
     
  • 2.17, Аноним (-), 15:10, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >развертывание контейнеров лучше чем привычная установка приложения из пакетов,

    А если пакетов нет? Куча софта который официально поддерживает только убунту.
    >что такое DevOps

    Все просто. Это сисадмин не аутист.

     
  • 2.24, Аноним (-), 17:01, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Возможно, offtopic, но объясните мне (в виде ссылок, например), чем
    > 1. развертывание контейнеров лучше чем привычная установка приложения из пакетов,

    готовый контейнер, по их мнению, запускается быстрее чем создание и настройка виртуалки с установкой пакетов. Тут непонятно, накой хер всё каждый раз пересоздавать.

    > 2. что такое DevOps и чем он отличается от работы обычного сисадмина,
    > который занимается установкой (развертыванием), настройкой и обслуживанием софта на рабочих серверах.

    Среди хипсторского мозгового поноса о хипсторских бирюльках можно разобрать, что часть админовой работы берут на себя разработчики со своими жуткими взглядами на жизнь, а часть разработок ковыряет админ. Причём в последнее время кодеришки решили, что все админские задачи можно решить только при помощи своих безумных программерских поделий и кода.

     
     
  • 3.26, Аноним (-), 17:38, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Тут непонятно, накой хер всё каждый раз пересоздавать.

    Пересоздание контейнера будет сделано из обновлённых слоёв, а вообще - это очень быстро и заменяет поцедуру вкл/выкл виртуалки. Данные хранятся отдельно.

    >> 2. что такое DevOps и чем он отличается от работы обычного сисадмина,
    >> который занимается установкой (развертыванием), настройкой и обслуживанием софта на рабочих серверах.
    > Среди хипсторского мозгового поноса о хипсторских бирюльках можно разобрать, что часть
    > админовой работы берут на себя разработчики со своими жуткими взглядами на
    > жизнь, а часть разработок ковыряет админ. Причём в последнее время кодеришки
    > решили, что все админские задачи можно решить только при помощи своих
    > безумных программерских поделий и кода.

    Да, я один из тех хипстеров, которые девопсы. Я не вижу физических серваков, ибо их ковыряют местные админы, которые могут только поставить ОСь и выдать кренделя с адресом. Потом есть Virtualization engineers, которые деплоят опенстек и дают мне тенанты, с ними связан аккаунтинг-отдел. Есть монопсы, вставляющие всюду свои зонды из генетически-модифицированного нагиоса. И нетопсы, или просто сетевики.

    За последнее время просто повысилось количество абстракций.

     
     
  • 4.27, Аноним (-), 17:43, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Пересоздание контейнера будет сделано из обновлённых слоёв, а вообще - это очень
    > быстро и заменяет поцедуру вкл/выкл виртуалки. Данные хранятся отдельно.

    Пакеты в виртуалке обновляются на ходу, и максимум, что нужно сделать — перезапустить севис.
    Данные хранятся где угодно.

    > Да, я один из тех хипстеров, которые девопсы.

    Не, ты недостаточно девопс, надо больше безумных терминов.

     
     
  • 5.36, Аноним (-), 00:08, 25/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    1) Не совсем, содержимое последнего слоя надо или обновить, или пересоздать. Он не подтянется за содержимым базовых слоёв.
    2) Тоже хороший вариант.
    3) Таки да, учту на будущее.
     
  • 3.35, Аноним (-), 23:16, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А в виртуалку собственный софт вместе с операционкой запихивают, я так понимаю, чтобы его можно было запустить на любом дистрибутиве. И плевать что он места больше занимает как на диске, так и в оперативке, да и на обеспечение виртуализации ресурсы тратятся (CPU в том числе).

    Но все равно не понятно, почему бы для своего софта не использовать определенный дистрибутив? Кроме того, если раньше админу нужно было обновлять операционку только на физической машине (где работают несколько приложений), то теперь нужно следить за содержимым каждой виртуалки.

    P.S. Я реально пытаюсь осмыслить причину этой новой тенденции, т.к. тенденция есть, активно развивается, значит у нее есть причина. Теперь хочется ее понять, т.е. кому и для чего это надо...

     
     
  • 4.46, Miranda user (?), 02:16, 29/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Но все равно не понятно, почему бы для своего софта не использовать определенный дистрибутив?

    можно, в том числе внутри контейнера (если это дистрибутивы линукс)

    > Кроме того, если раньше админу нужно было обновлять операционку только на физической машине (где работают несколько приложений), то теперь нужно следить за содержимым каждой виртуалки.

    зато меньше шансов сломать работу приложения при обновлении, если разделить их по контейнерам и обновлять отдельно. Также можно разделять общие системные каталоги между контейнерами (через ro bind mount) и обновлять сразу группу контейнеров.

    По сравнению с kvm, xen - низкие накладные расходы без необходимости в hardware virtualization, простая настройка (в том числе легкий проброс железа в контейнер). Зависит от конкретного сценария использования.

     

  • 1.10, Аноним (-), 14:24, 24/06/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот бы ещё контейнеры были не дырявые как в докеровых залежах, и при этом удобные как тот же докер
     
     
  • 2.13, Аноним (-), 14:29, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Вот бы ещё контейнеры были не дырявые как в докеровых залежах, и
    > при этом удобные как тот же докер

    Что то мешает зайти в контейнер и сделать apt-get upgrade||yum update ?

     
     
  • 3.19, Аноним (-), 16:02, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Грех это. Контейнер должен быть иммутабелен.
     
     
  • 4.21, Аноним (-), 16:35, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Образ(Image) должен быть "иммутабелен" контейнер это как раз "мутабеленый" образ.
    Из пропатченного контейнера делается образ с помощью docker commit.
     
     
  • 5.23, Аноним (-), 16:48, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Образ(Image) должен быть "иммутабелен" контейнер это как раз "мутабеленый" образ.
    > Из пропатченного контейнера делается образ с помощью docker commit.

    В том-то и дело, что докероводы против, они у себя на сайте считают, что надо только образы перекачивать, а уязвимостей у них на самом деле нет.

     
  • 3.20, Аноним (-), 16:15, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Оналитеги не знают что так можно делать.
     
     
  • 4.32, Аноним (-), 20:35, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Оналитеги не знают что так можно делать.

    Не, оналитеги про это знают. Но зато они не знают, что оно проживает только до следующей остановки контейнера.

     
     
  • 5.33, Аноним (-), 21:14, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    # docker start
    Start one or more stopped containers
    # docker commit
    Create a new image from a container's changes
    Надо курить маны Карл. Маны.

     
  • 3.28, Старшина Кириллов (?), 19:25, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И толку? Оно сбросится после перезапуска.
    Образ надо заново билдить.
     
     
  • 4.34, Аноним (-), 21:22, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > И толку? Оно сбросится после перезапуска.
    > Образ надо заново билдить.

    ITT люди которые пользуются докером не прочитав даже начальный гайд.
    man docker stop/start/restart
    man docker commit
    man docker push


     
     
  • 5.40, Аноним (-), 12:01, 25/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> И толку? Оно сбросится после перезапуска.
    >> Образ надо заново билдить.
    > ITT люди которые пользуются докером не прочитав даже начальный гайд.
    > man docker stop/start/restart
    > man docker commit
    > man docker push

    https://github.com/docker/docker/issues/1171

     
     
  • 6.42, Аноним (-), 13:46, 25/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >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"?

     
     
  • 7.43, Аноним (-), 14:07, 25/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    AUFS - это бекэнд докера доступеный только для Ubuntu. Для остальных дистрибутивов:
    $sudo docker info
    Containers: 139
    Images: 600
    Storage Driver: devicemapper <- обратите внимание.

    Совет от меня: если хотите сберечь нервы и время, не используйте Ubuntu в "продакшене". Никогда.
    Удачи.

     

  • 1.12, privation (?), 14:29, 24/06/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    пора со стороны сообщества пользователей тоже создавать программы сертификации предлагаемых продуктов и услуг
     
     
  • 2.29, Аноним (-), 20:31, 24/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А какие продукты и услуги может предложить сообщество _пользователей_?

    На ум приходит только услуга по тестированию ПО.

     

  • 1.45, Ku Klux Klan (?), 11:02, 28/06/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    RHEL на утюге и чайнике
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру