Продолжаем цикл статей о контейнеризации. Сегодня мы поговорим о runC — инструменте для запуска контейнеров, разрабатываемом в рамках проекта Open Containers. Цель этого проекта заключается в разработке единого стандарта в области контейнерных технологий. Проект поддерживают такие компании, как Facebook, Google, Microsoft, Oracle, EMC, Docker. Летом 2015 года был опубликован черновой вариант спецификации под названием Open Container Initiative (OCI).
Читать полностью »
Недавно мы добавили в сервис «Виртуальное приватное облако» новый образ с операционной системой RancherOS и обновили образ CoreOS.
Эти операционные системы будут интересны пользователям, которым необходим инструмент для простого управления большим количеством приложений в контейнерах и использования различных систем кластеризации контейнеров — Kubernetes, Docker Swarm, Apache Mesos и других.
Сегодня мы рассмотрим тему, которая не в полной мере раскрыта в современном мире ИТ: живая миграция контейнеров, как она работает за кулисами и какие проблемы решает. Спрос на данную технологию продолжает стремительно расти, поскольку она открывает новые возможности, предоставляя больше свободы в управлении жизненным циклом приложений.
Живая миграция контейнеров подразумевает собой процесс перемещения приложения между разными физическими машинами или облаками без прерывания работы приложения и разрыва связи с пользователем. Память, файловая система и сетевое соединение контейнеров, запущенные поверх «голой» аппаратуры, передаются от исходного хост-компьютера к месту назначения, поддерживая рабочее состояние без прерывания работы.
Читать полностью »
В мае этого года вышел релиз ГитЛаба 8.8. Частью этого релиза был запуск встроенного Docker Container Registry. Ниже перевод майской статьи, посвященной этому.
Недавно нами был выпущен GitLab версии 8.8, в которой поддержка CI стала еще лучше. Теперь в GitLab можно строить конвейеры (pipelines) для визуализации сборок, тестов, развертывания и любых других этапов жизненного цикла вашего ПО. Сегодня мы представляем вам следующий этап: GitLab Container Registry .
GitLab Container Registry — это безопасный приватный реестр для образов (images) Docker, разработанный с помощью ПО с открытым кодом. GitLab Container Registry полностью интегрирован в GitLab.
Ключевыми особенностями GitLab являются непрерывность процесса разработки и взаимная интеграция различных элементов; эти принципы сохраняются и при работе с нашим реестром. Теперь при помощи GitLab Container Registry вы можете использовать ваши Docker-образы для GitLab CI, создавать специальные образы для отдельных тегов и веток, а также многое другое.
Стоит отметить, что GitLab Container Registry является первым реестром Docker, полностью интегрированным в систему управления Git-репозиториями. Кроме того, GitLab Container Registry не требует отдельной установки, так как является частью GitLab 8.8; c его помощью можно легко скачивать и загружать образы на GitLab CI. И еще он бесплатный.
Для того, чтобы узнать, как включить использование GitLab Container Registry, обратитесь к документации для администратора.
Продолжаем наш цикл статей о контейнеризации. Если первые две статьи (1 и 2) были посвящены теории, то сегодня мы поговорим о вполне конкретном инструменте и об особенностях его практического использования. Предметом нашего рассмотрения будет LXD (сокращение от Linux Container Daemon), созданный канадцем Стефаном Грабе из компании Canonical.
Читать полностью »
Недавно была опубликована информативная статья Мэтта Уильямса о 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 и других.
Читать полностью »
Работа в Twitter одновременно под рабочим и личным аккаунтами. Фото: Mozilla
Ходят слухи, что на некоторых сайтах какие-то пользователи пишут одновременно под несколькими аккаунтами. Они якобы оставляют однотипные комментарии под разными никами. Игроки в покер и другие онлайн-игры жалуются, что соперники играют как будто сообща, словно договорившись разорить жертву.
Правда это или нет, но в экспериментальной сборке браузера Firefox Nightly только что реализована технология, которая сильно упрощает одновременную работу под несколькими аккаунтами. Теперь для этого не придётся заводить несколько виртуальных машин или открывать несколько браузеров: изоляция окружений реализована непосредственно между вкладками!
Читать полностью »
Продолжаем цикл статей о механизмах контейнеризации. В прошлый раз мы говорили об изоляции процессов с помощью механизма «пространств имён» (namespaces). Но для контейнеризации одной лишь изоляции ресурсов недостаточно. Если мы запускаем какое-либо приложение в изолированном окружении, мы должны быть уверены в том, что этому приложению выделено достаточно ресурсов и что оно не будет потреблять лишние ресурсы, нарушая тем самым работу остальной системы. Для решения этой задачи в ядре Linux имеется специальный механизм — cgroups (сокращение от control groups, контрольные группы). О нём мы расскажем в сегодняшней статье.
Читать полностью »
Сегодня многие технологические компании обращают пристальное внимание на технологию контейнеров. В их числе – Google, IBM, Microsoft и конечно HPE. Контейнеры позволяют «упаковать» в один физический сервер намного больше приложений, чем это позволяют сделать виртуальные машины. Контейнерные технологии не новы, например, многие знают о них по разработкам компании Parallels, но они играют все более важную роль в центрах обработки данных и облаках. О них и пойдет речь.
Немножко не те контейнеры, о которых речь, но надо же привлечь внимание :)
Как и многие компании мира высоких технологий, компания Hewlett Packard Enterprise занимается венчурными инвестициями. Один из недавних примеров – инвестиции в разработчика лидирующих на рынке программно-определяемых объектных хранилищ Scality. Другой пример инвестиций в передовые технологии – поддержка стартапа Mesosphere, разработчика так называемой DC/OS.
Читать полностью »
Docker — инструмент автоматизации развертывания и управления приложениями в среде виртуализации на уровне операционной системы. Docker позволяет развертывать приложения в переносимых контейнерах и управлять такими контейнерами. Распространяется компанией Docker как свободное программное обеспечение.
Мы поговорили с Никитой Цукановым из компании Promarket о том, в чем преимущества Docker и как его использовать для развертывания серверных приложений и управления ими.
— В чём актуальность контейнерной виртуализации приложений, как она упрощает развертывание приложений и управление ими?
Корпоративные ИТ-команды очень часто сталкиваются с трудностями в развертывании приложений. Вполне «нормальна», к сожалению, ситуация, когда между разработчиками приложений и ИТ-администраторами отсутствует диалог, когда только один человек в компании знает, какие кнопки надо нажать, чтобы приложение развернулось, а администратор сам ничего сделать не может — потому что существует один-единственный человек, у которого есть сакральные знания о том, как нужно развертывать проект. Случается и такое, что нужно запустить, например, четыре разные версии (иногда почти одинаковые, но все же разные) на разных конфигурациях, на разных машинах, а потом это все поддерживать.
У меня довольно большой опыт подобных проектов, и я выделяю следующие основные проблемы с развертыванием приложений. Первая: очень длинная инструкция по развертыванию, очень сложный процесс развертывания, никто не понимает, что в каком порядке нужно развертывать. Вторая: одно приложение необходимо тиражировать для работы с разными клиентами. Третья: несколько серверных приложений должны работать на одном и том же сервере, и их окружение несовместимо между собой, к примеру, вы решили использовать у себя Linq2Excel, но он требует установки Access Database Engine, 32- и 64-битные версии которого не могут быть установлены одновременно.
Читать полностью »
