Комментарии 45
Буду рад ответить на все возникшие вопросы, не стесняемся и идем в комментарии! :)
Цикл статей очень интересный, но исходный тезис совершенно неверен. Будущее облаков — и не полная виртуализация, и не контейнерная. Мне нужно развернуть wordpress — я думаю поставить его в OpenVZ или в KVM, и понимаю что в обоих случаях мне придётся ещё одну полноценную linux машину администрировать. А мне всего-то нужен wordpress. Соответственно от облака нужно только wordpress+mysql — и всё, без остального мусора. Вот когда в контейнере останется только wordpress, всем будет глубоко наплевать что там только linux — потому что линукс будет только в host системе.
Спасибо за позиивнй фидбэк!
Прямой ответ на Ваш вопрос (с многими подробностями в комментариях) есть в первой части статьи, там как раз описывается, что не обязательно развертывать полноценное окружение и заботится о поддержании в нем актуального состояния ПО!
Как в случае Upstream Linux Containers, так и в случае OpenVZ как раз можно запереть Wordpress в определенной папке, изолировать его IPc и сеть, а также обрезать память, диск и процессор не создавая полноноценного контейнера, а просто наложив лимиты поверх текущей конфигурации. Примерно так, например, работает CloudLinux (к слову, есть идея его препарировать по аналогии с OpenVZ).
Прямой ответ на Ваш вопрос (с многими подробностями в комментариях) есть в первой части статьи, там как раз описывается, что не обязательно развертывать полноценное окружение и заботится о поддержании в нем актуального состояния ПО!
Как в случае Upstream Linux Containers, так и в случае OpenVZ как раз можно запереть Wordpress в определенной папке, изолировать его IPc и сеть, а также обрезать память, диск и процессор не создавая полноноценного контейнера, а просто наложив лимиты поверх текущей конфигурации. Примерно так, например, работает CloudLinux (к слову, есть идея его препарировать по аналогии с OpenVZ).
можно запереть Wordpress в определенной папке, изолировать его IPc и сеть, а также обрезать память, диск и процессор не создавая полноноценного контейнера, а просто наложив лимиты поверх текущей конфигурации
Вся идея облаков в том, чтобы дать пользователю возможность решать его проблемы не тратя время на поддержку серверов. А тут — какой-то ад админский. Это конечно весело, когда заняться нечем, но лучше использовать инструменты по прямому назначению, а не пытаться из куска хлеба соорудить троллейбус.
Почему ад? Посмотрите, например, на Python uWSGI, там можно в конфигурации приложения настроить его помещение в отдельные namecpas'ы с наложением требуемых cgroups.
В итоге Вы получаете:
В итоге Вы получаете:
- Настройку в три клика, все что нужно — указать пару параметров и иметь ядро выше 3.8
- Изолированное по ресурсам приложение (да, теперь утечка в памяти не приведет к смерти сервера)
- Полностью изолированное от хостовой системы приложение (да, теперь взлом одного окружения не приведет ни к каким проблемам соседнего приложения)
Да конечно можно. Просто человеку, который хочет раздеплоить wordpress в облако рассказывать про Python uWSGI, указывание параметров, проверку и обновление ядра Linux немного не правильно. Понятно например зачем это делать, если вы хотите запереть воркер от билд-сервера, но для wordpress есть гораздо более простые и удобные пути в 1 клик.
Тут я, конечно, соглашусь, что с нуля собирать контейнеризацию для любого софта — задача нетривиальная. В этом плане — контейнеры — лишь вспомогательный механизм, но не конечный продукт. До того, как они превратятся в конечный продукт — потребуется по меньшей мере пару лет (да и то, лишь в случае, если будет активная поддержка со стороны дистрибутивов), если не больше.
Я же правильно понимаю, что у вас там под капотом запускается полноценный контейнер?
Это разве это возможно — наложить by OpenVZ/LXC какие-то ограничения на что-то запускаемое в отдельной папке? Только же на контейнер (со всеми кишками, системой, вебсервером) целиком. А CL решает эту проблему совсем не этими контейнерами, а хитрыми эвристиками на уровне апача («псевдоконтейнеры»).
Это называется application container. Есть еще OSv, которая в ту же сторону двигается. В первом есть контейнеры, а во втором гипервизор. Так что на счет «в корне», хочу не согласиться.
Если быть ещё точнее, то вам нужен wordpress и вся инфраструктура для обработки запросов, балансировки нагрузки, хранения логов и мониторинги. С технической точки зрения именно контейнеры хорошо подходят для этой задачи, так что тут статья очень даже актуальна, но, в данном контексте, для разработчиков PaaS систем. А вам же уже нужны готовые решения, GAE, OpenShift, Heroku, Cocaine. Мне не раз приходилось рассказывать людям, что им не нужны виртуалки, и очень здорово, что вы сами поднимаете такие вопросы.
это уже PaaS, а тут разговор об IaaS
Проблема уже решена:) Администрировать ОС не нужно! Идеально для вашего сценария. Все необходимое ставится в 1 клик http://infobox.ru/jelastic/ (и PHP, и база и все, что только пожелаете. Можно даже Wordpress в 1 клик поставить из раздела «приложения». При этом внутри будет OpenVZ и куча автоматизации, но пользователя это все волновать не будет). А зарегистрировавшись по следующей ссылке можно получить еще и 201.4 руб на счет после перехода в коммерческий режим http://infobox.ru/promo/tryjelastic2014/. Будут вопросы — пишите в комменты или на trukhinyuri@infoboxcloud.com P.S. Извините, коллеги. Отличная статья, не собирался делать тут рекламу, но помочь человеку нужно.
Вот мой первый опыт.
"""
Notice: unserialize(): Error at offset 35 of 39 bytes in variable_initialize() (line 916 of /var/www/webroot/ROOT/includes/bootstrap.inc).
Доступно обновление системы безопасности для вашей версии Drupal. Чтобы обеспечить безопасность вашего сервера, вам следует немедленно выполнить обновление. Смотрите страницу доступных обновлений для дополнительной информации и установки обновлений.
Необходимо обновление вручную
Обновления ядра Drupal в настоящее время не поддерживаются.
"""
Как обновлять в ручную не понятно. Как вы изолируете пользователей друг от друга. Вы пришли в технический топик, вывалили рекламу, а технические моменты своей платформы не прояснили.
"""
Notice: unserialize(): Error at offset 35 of 39 bytes in variable_initialize() (line 916 of /var/www/webroot/ROOT/includes/bootstrap.inc).
Доступно обновление системы безопасности для вашей версии Drupal. Чтобы обеспечить безопасность вашего сервера, вам следует немедленно выполнить обновление. Смотрите страницу доступных обновлений для дополнительной информации и установки обновлений.
Необходимо обновление вручную
Обновления ядра Drupal в настоящее время не поддерживаются.
"""
Как обновлять в ручную не понятно. Как вы изолируете пользователей друг от друга. Вы пришли в технический топик, вывалили рекламу, а технические моменты своей платформы не прояснили.
Потому что это — не их платформа, Jelastic — суровый проприетарный black box, построенный на морально устаревшей Virtuozz'a (и это при живом Parallels Cloud Server) :)
«морально устаревшей Virtuozz'a» — что в ней морально устарело?
На этот вопрос сложно ответить без привлечения маркетинга, но кратко — по всей публичной информации, что есть в сети, четко видно, что будущее в Linux виртуализации от Parallels в продукте PCS, там много инновационных вещей — поддержка гипервизоров, поддержка облачного стораджа, общие оптимизации производительности.
Но это все для Jelastic, конечно же, не нужно. А нужно лишь — срок «жизни» платформы, а для PCS он на порядки больше и можно надеяться на по меньшей мере лет 5-7 апдейтов без реинсталла =)
А если ударяться в технику, то страница 34 вот этой презентации красноречиво отвечает на этот вопрос из самого авторитетного источника — от авторов системы.
Привожу ее здесь:
Но это все для Jelastic, конечно же, не нужно. А нужно лишь — срок «жизни» платформы, а для PCS он на порядки больше и можно надеяться на по меньшей мере лет 5-7 апдейтов без реинсталла =)
А если ударяться в технику, то страница 34 вот этой презентации красноречиво отвечает на этот вопрос из самого авторитетного источника — от авторов системы.
Привожу ее здесь:
Да, старая версия немного медленнее. Но как еластик привязан к виртуозе? PCS — это практически виртуоза на рхеле, т е еластик должен без проблем на нем подниматься.
Ну и виртуоза не устарела и официально поддерживается. Может переезд на более свежую версию не оправдывает себя пока финансово.
Ну и виртуоза не устарела и официально поддерживается. Может переезд на более свежую версию не оправдывает себя пока финансово.
PCS конечно гораздо больше, чем Virtuozzio на RHEL, если смотреть на него в полном боекомплекте вместе с PACI и Parallels Cloud Storage. Jelastic — PaaS, насколько эффективно он использует ресурсы — точно не проблема пользователей (использует эффективно), пользователь получает ровно столько ресурсов, сколько заказал и мыслит в контексте окружений, а не ОС. При этом Jelastic – не панацея, есть много случаев когда IaaS лучше (например если необходима сложная настройка нетипичных приложений). Просто в конкретном сценарии он работал бы идеально и не заставлял пользователя думать о настройке ОС.
PCS во времена релиза Jelastic был «с пылу с жару, неделя после релиза», так что просто выбора в те времена не было.
Вообще интересный вопрос, почему она (PVC 4.7) медленнее, чем PCS, ведь ядро поидее тоже самое. Единственное на что есть подозрения — отличия в userspace, которые могут давать такой провал в скорости. Но кроме numabalanced и pfcache ничего в голову не приходит.
Вообще интересный вопрос, почему она (PVC 4.7) медленнее, чем PCS, ведь ядро поидее тоже самое. Единственное на что есть подозрения — отличия в userspace, которые могут давать такой провал в скорости. Но кроме numabalanced и pfcache ничего в голову не приходит.
PCS во времена релиза Jelastic был «с пылу с жару, неделя после релиза»
Если бы у нас стоял Jelastic версии 0.1, то это был бы сильный аргумент. Однако со времен первого релиза платформа постоянно совершенствовалась и технология развивается. Поэтому не стоит пытаться в качестве аргумента приводить Jelastic «со времен первого релиза».
Напишите пожалуйста на trukhinyuri@infoboxcloud.com свой логин в Jelastic и мы посмотрим, в чем дело с drupal при обновлении и решим проблему. Jelastic – не blackbox. Фактически это автоматизация над контейнерной виртуализацией, позволяющая пользователю не думать о настройке серверов, а мыслить в категории стандартных окружений с автоскейлингом и абстракцией гораздо высокого уровня, чем IaaS. И конечно у нас в компании используется Parallels Cloud Server :)
Да, кстати, забыл упомянуть наше решение по реализации кастомного шейпера для OpenVZ, может быть кому пригодится. Правда, до «красивого» двухстороннего шейпинга нашему решению далеко.
Поэтому вопрос в реализации удобного, грамотного, гибкого и отлично спроектированного фреймворка для управления контейнерами в Linux открыт и Вы можете изменить мир, написав его
Поддержка и lxc и openvz есть в libvirt что там плохо?
Там плохо почти все, поддерживаются лишь базовые операции — создание, удаление. Ни о какой серьезной кастомизации, например, о пробросе устройств, рисайзе диска наживую, гранулярной настройки лимитов памяти речи просто не идет, к сожалению.
для LXC будут допиливать все, это стратегическое направление.
Не думаю, за 2+ года ситуация не поменялась ни на шаг, честно говоря, при огромное шаге в развитии Linux Containers. Нужен другой инструмент :)
были другие приоритеты. red hat не такая уж и огромная фирма, и им надо поддерживать и развивать уже существующее портфолио продуктов, которых немало. Не буду вдаваться в детали — во первых это не этично, а во вторых я ушел оттуда почти год назад, и многое могло измениться, но я знаю наверняка что LXC будет среди приоритетных направлений на определенных этапах развития RHEL7.
ну а то что RHT, когда берутся за проект, делают из него конфетку, я думаю секретом не является
ну а то что RHT, когда берутся за проект, делают из него конфетку, я думаю секретом не является
У вас пункт 2 и пункт 8 в списке проблем контейнеров про одно и то же.
Давно уже не пользовался контейнерами, может мой вопрос будет не актуален.
Как обстоят дела с shared memory? Раньше, помнится, одна гостевая машина на ноде могла исчерпать весь лимит. В результате страдали соседние контейнеры. Часто проявлялось как отказ apache запускаться со странной ошибкой: «port already in use».
Как обстоят дела с shared memory? Раньше, помнится, одна гостевая машина на ноде могла исчерпать весь лимит. В результате страдали соседние контейнеры. Часто проявлялось как отказ apache запускаться со странной ошибкой: «port already in use».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Контейнеризация на Linux в деталях — LXC и OpenVZ Часть 2