Это общие ощущение.
Из интересного это вступление Павла, но оно подходит для тех кто не в теме контейнеров вообще.
Управление памятью контейнеров в проекте OpenVZ.
Заголовок многообещающий, я думал раскажу как оно в реальной жизни, под нагрузками и как все эффективно с примерами из жизни.
На деле:
История как мы трудились, что получили и куда движемся дальше. Моментами позновательно.
LibCT и контейнеры на уровне приложений
Ну в общем опять же, больше информациии что мы есть и используйте нас. Все можно вполне найти на сайтах.
Использование контейнерных технологий в DevOps
Вот тут начинается Ехал докер, через докер, докер, докер, докер, докер.
OpenVZ просто прошляпила рынок и пытается дружить с докером, чем лучше докер, чем openvz — тем что он докер.
На мой вопрос Дмитрий не ответил, а вот я собрал кучу людей и не смог пообедать :/
Русоникс — это вообще треш, столько пафоса и маркетинга. Мы убрали все лишнее, держимся на паре крупных клиентов и нам OK.
Ну OK.
CRIU: ускорение запуска PHP в CloudLinux OS
На мой взгляд технологию использует не поназначению и решают свои проблемы через странные костыли.
Но в общем весь мир из костылей и живем, но доклад более чем странен.
Развёртывание приложений Docker в контейнерах Virtuozzo
Криво, косо но мы делаем вид, что очень любим докер. Но все больше складывается озузение кусание локтей об упущенной возможности, теперь выкручиваем как можем.
Проблема фрагментации виртуальных дисков и способы её решения
Тут без претензий, реально хороший и интересный доклад. Таких я бы желал видеть больше.
Да я немного утрирую, но в общем целом у меня ощущение что доклады для галочки/птички.
Кирилл показывал намного интересней доклад по возможностей CRIO живьем на примере игры квейк. Вот такого плана доклады смотреть и слушать интереснее.
>так что на ванильном ядре контейнеры не запустятся, надо будет или использовать их дистрибутив CloudLinux, или устанавливать vzkernel на Red Hat/CentOS 7.
Не совсем верно. Можно будет запустить на ОС которые не завязанны на свое ядро, например в debian, archlinux, возможно что-то еще я не пробовал.
В целом кстати доклады были больше для галочки, чем для пользы и это печально.
Ну и получим мы в итоге, что будет кэш только самого популярного и востребованного. Мы это и наблюдаем в текущий реализации торрентов, когда нужно скачать что-то и сидишь ждешь когда появится кто-то у кого оно есть.
Но подход понятен, это как у MS с обновлениями по P2P, хочешь не хочешь а будишь раздавать.
Получается при заходе на страницу я ее буду качать и хранить у себя как некий кэш, который у меня потом могут взять другие или файл. OK
Что делать если у меня мало место?
При изменении динамики, насколько быстро распространится изменения.
Будет ли полная перекачка файла или только изменения файла?
Как распределяются права к файлам? Можно ли сделать больше одного человека, который имеет RW права на папку?
Как быть, если кто-то удалил все файлы в каталоге или сам каталог?
Как быть с коллизиями?
Направление верное, инструменты не те. Но опять же, тут личное мнение каждого. Если выбирать между никак и как то, лучше как то чем никак ;) Тут я с вами спорить вообще не буду.
На тему железок ситуация разные и много чего надо принимать в расчет. Приходилось помогать интегратору, у которого каждое утро DHCP молча умирал. Клиентов больше 2000. Если коротко, то машина просто не справлялась. Решили в приделах широковищательного домена поднимать DHCP на L2+, а запросы уже перенаправлять на умирающий сервер через option 82.
И да мониторинга там не было, поэтому я вашу боль прекрасно понимаю.
>А какую проблему с построением графиков мы будем решать с помощью L3 коммутатора?
А какая там проблема есть?
Извините, но у вас чисто колхозный подход. Хренак хренак и в продакшен.
Я не хочу ходить со своим уставом в чужой монастырь, если у вас это все работает и устраивает — то ok.
Если у вас есть кошки и кошки нормальные и вызнаете как их готовить, то логично было бы использовать их.
Еще и NetFlow задействовать и собирать все в одно место типа zabbix.
>Не хотелось бы превращать обзорную статью в полноценный гайд по использованию SD. Но можно попробовать кратенько. Итак методология простенького сценария такова:
Я бы хотел лично увидеть и гайд нормальный и примеры под которые консул будет хорошо использовать. Да и примеры где его не надо использовать.
Они там закапались с переносом функций из своего ядра в ванильное. По сути LXC и Docker используют общие наработки.
OpenVZ как по мне вообще держится на двух людях, на Павле и Кирилле.
Можно сделать свой собственный dockerhub и поддерживать обновление. Это несомненно плюс.
В OpenVz есть механизм забора image, но его надо допиливать руками.
>Т.е. вместо инсталлятора/архива с приложением и длинной документацией по настройке и запуску, админ получает от разработчика уже >полностью готовый к запуску образ.
В OPenvz/lxc неожиданно образы.
>Этот образ можно сразу размещать на серверах и запускать. Т.е. это не средство управления ресурсами сервера, а средство поставки ПО.
Ну не сразу, надо поставить docker.
Собсвтенно после установки openvz, вы так же можете сразу использовать контейнер с вашим ПО.
Да бы не схватить кучу минусов, я не имею ничего против докера. Наоборот это хорошо и отлично, что он поднял много шума вокруг виртуализации и вообще в тренде. Я реально хочу понять, как оно в моем случаи поможет жить?
DockerHUB? я не использую публичные вещи, я старпер и все передпочитаю делать руками сам. Я не знаю, что и кто там приготовил в image.
DockerFile? Отлично, я это все так же решаю ansible/chef/puppet.
Единственный плюс, это свежие ядро и все в ядре в отличие от openvz. Но можно смотреть и на LXC, правда с урезанным функционалом.
То, что openvz может в себе запускать докер через костыли, прекрасно.
Я бы с вами согласился, если бы докер мог использовать минимальное окружение для запуска приложения. По сути он так может и были тут уже статьи по минимальному докеру, но дается это тяжело.
еще раз, openvz/virtuozzo/odin просто опоздала к кормушки и теперь приходится просто дружить с докером и развивать другие фишки.
Сильно они опоздали и с открытием ядра итд итп.
Ох, в общем как и на недавней конференции events.yandex.ru/events/yagosti/19-september-2015-linux, вы меня не убидили в нужности докера. Особенно если есть уже инфраструктура на OpenVZ/LXC.
В некоторых моментах пслд намного удобнее, например при работе с сетью. Проект Criu приносит свои плюшки. Можно сказать, что OpenVZ просто опоздал с такими модными плюшками как Docker Hub и DockerFile.
Если поднимать с 0, возможно удобно, если уже все готово — то просто модное веяние.
Вы не поверите. От безисходности в крупных ынтерпрайсах и не такое увидишь, а как увидишь начинают шевелится волосы в разных местах и срочно хочется развидить.
Из интересного это вступление Павла, но оно подходит для тех кто не в теме контейнеров вообще.
Управление памятью контейнеров в проекте OpenVZ.
Заголовок многообещающий, я думал раскажу как оно в реальной жизни, под нагрузками и как все эффективно с примерами из жизни.
На деле:
История как мы трудились, что получили и куда движемся дальше. Моментами позновательно.
LibCT и контейнеры на уровне приложений
Ну в общем опять же, больше информациии что мы есть и используйте нас. Все можно вполне найти на сайтах.
Использование контейнерных технологий в DevOps
Вот тут начинается Ехал докер, через докер, докер, докер, докер, докер.
OpenVZ просто прошляпила рынок и пытается дружить с докером, чем лучше докер, чем openvz — тем что он докер.
На мой вопрос Дмитрий не ответил, а вот я собрал кучу людей и не смог пообедать :/
Русоникс — это вообще треш, столько пафоса и маркетинга. Мы убрали все лишнее, держимся на паре крупных клиентов и нам OK.
Ну OK.
CRIU: ускорение запуска PHP в CloudLinux OS
На мой взгляд технологию использует не поназначению и решают свои проблемы через странные костыли.
Но в общем весь мир из костылей и живем, но доклад более чем странен.
Развёртывание приложений Docker в контейнерах Virtuozzo
Криво, косо но мы делаем вид, что очень любим докер. Но все больше складывается озузение кусание локтей об упущенной возможности, теперь выкручиваем как можем.
Проблема фрагментации виртуальных дисков и способы её решения
Тут без претензий, реально хороший и интересный доклад. Таких я бы желал видеть больше.
Да я немного утрирую, но в общем целом у меня ощущение что доклады для галочки/птички.
Кирилл показывал намного интересней доклад по возможностей CRIO живьем на примере игры квейк. Вот такого плана доклады смотреть и слушать интереснее.
Не совсем верно. Можно будет запустить на ОС которые не завязанны на свое ядро, например в debian, archlinux, возможно что-то еще я не пробовал.
В целом кстати доклады были больше для галочки, чем для пользы и это печально.
Но подход понятен, это как у MS с обновлениями по P2P, хочешь не хочешь а будишь раздавать.
Что делать если у меня мало место?
При изменении динамики, насколько быстро распространится изменения.
Будет ли полная перекачка файла или только изменения файла?
Как распределяются права к файлам? Можно ли сделать больше одного человека, который имеет RW права на папку?
Как быть, если кто-то удалил все файлы в каталоге или сам каталог?
Как быть с коллизиями?
www.ixbt.com/news/hard/index.shtml?17/33/31
Направление верное, инструменты не те. Но опять же, тут личное мнение каждого. Если выбирать между никак и как то, лучше как то чем никак ;) Тут я с вами спорить вообще не буду.
На тему железок ситуация разные и много чего надо принимать в расчет. Приходилось помогать интегратору, у которого каждое утро DHCP молча умирал. Клиентов больше 2000. Если коротко, то машина просто не справлялась. Решили в приделах широковищательного домена поднимать DHCP на L2+, а запросы уже перенаправлять на умирающий сервер через option 82.
И да мониторинга там не было, поэтому я вашу боль прекрасно понимаю.
А какая там проблема есть?
Извините, но у вас чисто колхозный подход. Хренак хренак и в продакшен.
Я не хочу ходить со своим уставом в чужой монастырь, если у вас это все работает и устраивает — то ok.
Если у вас есть кошки и кошки нормальные и вызнаете как их готовить, то логично было бы использовать их.
Еще и NetFlow задействовать и собирать все в одно место типа zabbix.
Я бы хотел лично увидеть и гайд нормальный и примеры под которые консул будет хорошо использовать. Да и примеры где его не надо использовать.
OpenVZ как по мне вообще держится на двух людях, на Павле и Кирилле.
В OpenVz есть механизм забора image, но его надо допиливать руками.
В OPenvz/lxc неожиданно образы.
>Этот образ можно сразу размещать на серверах и запускать. Т.е. это не средство управления ресурсами сервера, а средство поставки ПО.
Ну не сразу, надо поставить docker.
Собсвтенно после установки openvz, вы так же можете сразу использовать контейнер с вашим ПО.
Да бы не схватить кучу минусов, я не имею ничего против докера. Наоборот это хорошо и отлично, что он поднял много шума вокруг виртуализации и вообще в тренде. Я реально хочу понять, как оно в моем случаи поможет жить?
DockerHUB? я не использую публичные вещи, я старпер и все передпочитаю делать руками сам. Я не знаю, что и кто там приготовил в image.
DockerFile? Отлично, я это все так же решаю ansible/chef/puppet.
Единственный плюс, это свежие ядро и все в ядре в отличие от openvz. Но можно смотреть и на LXC, правда с урезанным функционалом.
То, что openvz может в себе запускать докер через костыли, прекрасно.
еще раз, openvz/virtuozzo/odin просто опоздала к кормушки и теперь приходится просто дружить с докером и развивать другие фишки.
Сильно они опоздали и с открытием ядра итд итп.
В некоторых моментах пслд намного удобнее, например при работе с сетью. Проект Criu приносит свои плюшки. Можно сказать, что OpenVZ просто опоздал с такими модными плюшками как Docker Hub и DockerFile.
Если поднимать с 0, возможно удобно, если уже все готово — то просто модное веяние.