Мы в бизнес-подразделении Odin* компании Parallels занимаемся разработкой технологий виртуализации с 1999 года. За прошедшие 15 лет мы превратили концепт в платформу для гипервизорной и контейнерной виртуализации Virtuozzo. Всё это время параллельно с коммерческим продуктом развивался открытый проект OpenVZ, в рамках которого разрабатывались компоненты для создания и управления контейнерами, а исходный код был доступен под лицензией GPL. И, несмотря на то, что проект сильно проигрывал коммерческому продукту по объёму функциональности и производительности, вокруг него сформировалось активное и открытое сообщество пользователей.

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

«Всего» 16 лет назад мы разработали первый концепт технологии контейнерной виртуализации, который позднее стал серверным продуктом мирового класса. В 2005 году стартовал проект OpenVZ, в рамках которого разрабатывалась открытая версия коммерческого продукта. Несмотря на то, что OpenVZ уступает коммерческому продукту по функциональности, это решение часто используют как на рынке хостинга, так и в небольших проектах, где требуется легковесная виртуализация. Сейчас контейнеры становятся намного популярнее: если раньше единственной областью их применения был хостинг (и этот сегмент контейнеры захватили на 90%), то сегодня их все чаще используют на корпоративном рынке — от разработки ПО до промышленных систем (OpenVZ используют в Pixar, Atlassian, Яндекс и др.). В них заинтересованы и «большие» ребята – Google, IBM, Facebook и так далее. В принципе, это уже часть ответа на вопрос «Зачем мы объединили кодовые базы коммерческого и открытого проектов, и анонсировали открытую разработку OpenVZ?», но под катом мы хотели бы подробнее рассказать, зачем это сделали.

Программное обеспечение с открытым кодом имеет своих почитателей, а в последнее время если речь заходит о разработке каких-то «национальных» продуктов, так в основном open-source и подразумевают. Парадоксально, но интерес к этому виду программного обеспечения породил массу искажений и заблуждений, которые на практике мешают его распространению.

Наша компания участвует в открытых проектах с 2005 года – и благодаря разработке собственных open source решений (проекты OpenVZ, CRIU), участвуя в других открытых проектах (QEMU, OpenStack, libvirt, libcontainer, и т.д.). За 10 лет мы собрали несколько наиболее распространённых мифов об открытом программном обеспечении. Я расскажу про каждое из заблуждений и объясню, почему оно ошибочно. Наверняка, вы вспомните еще столько же, но, на мой взгляд, эти пять самые «адовые».

В этом году проекту OpenVZ исполнится 10 лет. Мы разрабатывали технологию изолированных окружений для ОС Linux ещё тогда, когда это было не модно. 19 сентября мы собираем первую встречу людей из OpenVZ-сообщества, тех, кто пользуется нашими технологиями и Linux-контейнерами вообще. Послушать доклады пользователей и разработчиков OpenVZ, задать им вопросы, пообщаться в перерывах.

Только прошла конференция AzureCon, а мы спешим рассказать о том, что там анонсировали. Там, где использование может быть не очень понятным с первого раза, были добавлены примечания, а также добавлены ссылки там, где уже есть что почитать подробнее и как начать использовать.

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



Под катом:
* Самые мощные виртуальные машины с GPU в публичном облаке
* Зарезервированные инстансы
* Платформа для IoT-решений
* Cortana Analytics Suite

И многое другое. И, как обычно, много про Open Source.

В прошлой статье я вкратце рассказал о том, что такое контейнерная виртуализация, LXC в частности, зачем это нужно и как это все по-быстрому настроить.

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

На предыдущих версиях Debian я успешно использовал технологию виртуализации OpenVZ. Она меня полностью устраивала, несмотря на наличие некоторых спорных моментов. На Debian 8 Jessie установка этой технологии не шла ни под каким соусом. Позже мои догадки о невозможности существования OpenVZ на Debian 8 и старше нашли свое подтверждение на toster.ru. Там же была предложена альтернатива — LXC, что я и решил попробовать.

Кратко опишу способ установки и настройки LXC на Debian Jessie.

Разрабатывая CRIU, мы поняли, что текущий интерфейс получения информации о процессах не идеален. К тому же, подобная проблема была успешно решена для сокетов. Мы попытались перенести эти наработки на процессы и получили достаточно хорошие результаты, о которых вы узнаете, дочитав эту статью до конца.

Недостатки текущего интерфейса

Прочитав заголовок, возникает вопрос:”A чем же старый интерфейс не угодил”? Многие из вас знают, что сейчас информация о процессах собирается по файловой системе procfs. Здесь каждому процессу соответствует директория, которая содержит несколько десятков файлов.

$ ls /proc/self/ 
attr             cwd      loginuid    numa_maps      schedstat  task
autogroup        environ  map_files   oom_adj        sessionid  timers
auxv             exe      maps        oom_score      setgroups  uid_map
cgroup           fd       mem         oom_score_adj  smaps      wchan
clear_refs       fdinfo   mountinfo   pagemap        stack
cmdline          gid_map  mounts      personality    stat
comm             io       mountstats  projid_map     statm
coredump_filter  latency  net         root           status
cpuset           limits   ns          sched          syscall

Несмотря на то, что изначально Linux Deploy задумывался как приложение для Android, со временем появляются и другие варианты его применения. С появлением Linux Deploy CLI стал доступен ряд возможностей, открывающих новые сферы применения этого инструмента.

Недавно была опубликована информативная статья Мэтта Уильямса о Java в Docker и существующих ограничениях памяти. Автор поднимает интересную тему о скрытой проблеме ограничения памяти, с которой пользователи могут столкнуться во время работы с контейнерами.

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

Поэтому хотелось бы более подробно проанализировать данную проблему и определить возможные пути ее решения.

Проблема

Мэтт описывает свое ночное «путешествие» в контейнере Docker со стандартным поведением памяти JVM. Он обнаружил, что ограничения RAM отображаются некорректно внутри контейнера. В результате, приложение Java, или любое другое, видит общий объем ресурсов оперативной памяти, выделенной для всей хост-машины, а JVM не может указать, сколько ресурсов было предоставлено родительскому контейнеру для работы. Это приводит к ошибке OutOfMemoryError, вызванной неправильным поведением динамической памяти JVM в контейнере.

Фабио Кунг, из Heroku, подробно описал основные причины возникновения этой проблемы в своей недавней статье "Память внутри контейнеров Linux. Или почему в контейнере Linux не работает free и top?"

Большинство инструментов Linux, предоставляющих метрики ресурсов системы, были созданы в то время, когда cgroups еще не существовали (например: free и top, как у procps). Они обычно читают метрики памяти из файловой системы proc: /proc/meminfo, /proc/vmstat, /proc/PID/smaps и других.

Преамбула

Некоторе время назад перед нами стала задача спроектировать и развернуть систему для потокового видео. Суть была в массовом запуске/остановке инстанций, на которых происходит обратная сборка потокового видео и стриминг на множество media cdn провайдеров (youtube, livestream, ustream итд ) а также на собственные rtmp и ts точки назначения. Каждая инстанция требовала настройки перед запуском т.к. содержала специфическую для каждого клиента информацию. Также было понятно, что система должна работать в большом количестве регионов (как минимум во всех точках, где присутствует Амазон, а как максимум — в любом месте где можно арендовать сервер). Также основное требование — запуск инстанции в течении 1-2 секунд максимум, чтобы это было прозрачно для пользователя.

Я искал self-hosted мониторинговое решение с открытым кодом, которое может предоставить хранилище метрик, визуализацию и оповещение для физических серверов, виртуальных машин, контейнеров и сервисов, действующих внутри контейнеров. Опробовав Elastic Beats, Graphite и Prometheus, я остановился на Prometheus. В первую очередь меня привлекли поддержка многомерных метрик и несложный в овладении язык запросов. Возможность использования одного и того же языка для графических изображений и уведомления сильно упрощает задачу мониторинга. Prometheus осуществляет тестирование по методу как черного, так и белого ящика, это означает, что вы можете тестировать инфраструктуру, а также контролировать внутреннее состояние своих приложений.

Как вы думаете насколько реально зайти на машину по ssh, обновить систему, загрузить новое ядро и при этом оставаться в той же ssh сессии. Сейчас есть модное движения по обновлению ядра на лету (ksplice, KernelCare, ReadyKernel, etc), но у этого способа есть много ограничений. Во-первых, он не позволяет применять изменения, которые меняют структуру данных. Во-вторых, объекты в памяти могут уже содержать неверные данные, которые могут вызвать проблемы в дальнейшем. Здесь будет описан более «честный» способ обновить ядро. На самом деле, сам способ уже давно известен [1], а ценность этой статьи в том, что мы разберем все в деталях на реальном примере, поймем, насколько это просто или сложно, и чего стоит ждать от подобных экспериментов.

На хабре уже писали про Docker swarm mode (режим роя), который является новой фичей версии 1.12. Данная опция внесла небольшую путаницу в головы тех, кто знаком с отдельно стоящей реализацией Docker Swarm имевшей распространение ранее и не отличавшейся удобством настройки и использования. Однако, после добавления Swarm в коробку с Docker все стало намного проще, очевиднее и функциональнее.

Подробнее о том, как устроен новый кластер Docker контейнеров с точки зрения пользователя, а также о простом и удобном способе разворачивания сервисов Docker на произвольной инфраструктуре далее под катом.

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

В этой статье рассматривается простой способ создания и тестирования образов docker. По ходу повествования, используя Goss, мы напишем тесты, с помощью которых можно проверить официальный образ Nginx всего за ~0,5 с.

Про использование Docker и Docker-compose последнее время написано очень много, например рекомендую недавнюю статью на Хабре, если вы до сих пор не прониклись. Это действительно очень удобно, а в связке в ansible особенно. И я его использую везде. От разработки, до автоматического интеграционного тестирования на CI. Про использование в тестировании, тоже писали. Это здорово и удобно. Однако, для локальной разработки, для траблешутинга данных "как в продакшене" или тестирование производительности, на "объёмах близких в продакшену", хочется иметь под рукой образ, содержащий базу, "как в продакшене"!

Соответственно, хочется, чтобы каждый разработчик, приступая к работе над проектом, мог запустить его одной командой, например:

./gradlew dockerRun

и приложение поднялось бы сразу со всеми необходимыми связанными контейнерами? А главное чтобы в нём уже были бы данные для большинства кейсов разработки и багфиксинга, стандартные пользователи и большинство работающих сервисов, над которыми сразу можно было бы приступить работать, не тратя времени на экспорт-импорт каких-то там образов или демоданных!

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

Разумеется мы поговорим о написании Dockerfile для такого образа с данными, и некоторых подводных камнях этого процесса.

Предисловие

Примерно 9 лет назад, когда в моем городе появились первые безлимитные тарифы (что-то вроде 128 кбит/сек за 500 руб.), я принял решение держать в квартире собственный «сервер» для решения различных задач. Одной из первых идей было поднятие зеркала для проекта FreeBSD.org. Проработало оно где-то 2 года. Далее в этом уже не было смысла, ввиду расширения каналов и других причин.

Помимо этого, сервер принимал на себя в разные периоды времени и другие задачи:

• Хранение резервный копий данных, документов и дистрибутивов;
• Закачка торрентов;
• Раздача торрентов по DLNA и SMB на различные устройства;
• VPN-клиент к провайдеру (был даже период, когда сервер держал два PPTP соединения через MPD – для работы локального трафика и медленного безлимита);
• VPN-сервер и подключение до офисного шлюза (канал до работы);
• Asterisk сервер для IP-телефонии (в дальнейшем в доме появились всякие SPA-3112, радио-трубки и т.д.);
• FTP-служба для получения данных с IP-камеры, для сброса бекапов с Mikrotik-ов скриптами;
• И т.д. и т.п.

Общая мысль – в руках был конструктор с кучей разноцветных деталей и большое желание прикрутить еще что-нибудь эдакое. В общем то обычная ситуация для большинства системных администраторов, знающих и любящих *nix-системы.

Жизнь в движении. Поэтому мы не устаём экспериментировать с новыми форматами проведения мероприятий для достижения более высоких целей (Круто звучит, да?). Сначала мы отказались от проведения обычной конференции DevCon и перешли в формату DevCon School: эксперты индустрии и их реальный опыт в реальных проектах. За время эксперимента мы провели 6 школ и поняли, что этот формат позволяет «пощупать» новые технологии, получить о них общее представление, вернуться в рабочую рутину с обычной нехваткой времени и остановиться.



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

Привет, Хабр! Неделю назад я рассказывал вам о новой возможности, которая доступна в предварительных выпусках Docker и Windows Server/Windows 10 — запуск Linux контейнеров c Hyper-V изоляцией, аналогично Windows контейнерам с Hyper-V изоляцией. В этом пошаговом руководстве речь пойдёт про аналогичный запуск контейнеров с Ubuntu в этом окружении.