Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 464 сообщений
Cообщения с меткой

контейнеры - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Управление контейнерами с LXD

Понедельник, 22 Августа 2016 г. 11:10 (ссылка)

LXD Containers



Продолжаем наш цикл статей о контейнеризации. Если первые две статьи (1 и 2) были посвящены теории, то сегодня мы поговорим о вполне конкретном инструменте и об особенностях его практического использования. Предметом нашего рассмотрения будет LXD (сокращение от Linux Container Daemon), созданный канадцем Стефаном Грабе из компании Canonical.





Имя создателя LXD хорошо известно в профессиональном сообществе: он также является одним из авторв другого популярного контейнерного решения — LXC. Собственно, LXD представляет собой надстройку над LXC, которая упрощает работу с контейнерами и добавляет широкий спектр новых возможностей.



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



LXD и Docker





LXD — инструмент относительно новый: первая версия вышла в свет в 2014 году, когда Docker уже получил широкое распространение и хорошо зарекомендовал себя на практике.

Как и Docker, LXD функционирует на базе LXC.



При этом cфера применения у двух инструментов совершенно разная: если Docker предназначен для запуска в контейнерах приложений, то LXD — для запуска полноценных операционных систем.



С помощью LXD можно создавать даже не контейнеры в буквальном смысле этого слова, а легковесные виртуальные машины. Чтобы подчеркнуть этот момент и одновременно указать на отличие от других инструментов контейнеризации, авторы многих публикаций называют LXD словом lightvisor (на русский язык его уже переводят как «легковизор»).



В публикациях Canonical отмечается, что LXD-контейнеры могут работать в 10 раз быстрее, чем традиционные виртуальные машины на базе KVM.



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



LXD оснащён открытым API; имеются клиенты для различных языков программирования. Создан плагин для OpenStack, позволяющий управлять контейнерами с помощью клиента Nova.



.



Установка и настройка





Здесь и далее мы будем описывать особенности работы c LXD на материале Ubuntu 16.04. В этой ОС LXD включён в официальные репозитории и устанавливается стандартным способом:



apt-get install lxd




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



apt-get install zfsutils-linux




Если ZFS вам по тем или иным причинам не подходит, вы можете воспользоваться BTRFS или LVM (подробнее об этом см. здесь).

По завершении установки выполним команду:



lxd init




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



Создание контейнера





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



 lxc remote list

+-----------------+------------------------------------------+---------------+--------+--------+
| NAME | URL | PROTOCOL | PUBLIC | STATIC |
+-----------------+------------------------------------------+---------------+--------+--------+
| images | https://images.linuxcontainers.org | lxd | YES | NO |
+-----------------+------------------------------------------+---------------+--------+--------+
| local (default) | unix:// | lxd | NO | YES |
+-----------------+------------------------------------------+---------------+--------+--------+
| ubuntu | https://cloud-images.ubuntu.com/releases | simplestreams | YES | YES |
+-----------------+------------------------------------------+---------------+--------+--------+
| ubuntu-daily | https://cloud-images.ubuntu.com/daily | simplestreams | YES | YES |
+-----------------+------------------------------------------+---------------+-------




Для первого знакомства с LXD вполне подойдёт локальный репозиторий (local). Запустим в контейнере ОС Ubuntu 16.04:



lxc launch ubuntu:16.04 container1




В результате выполнения этой команды LXD создаст на базе указанного образа контейнер и запустит его.



Запустить в этом контейнере командную оболочку можно с помощью команды:



lxc exec container1 /bin/bash




Если нужно просто создать контейнер, но не запускать его, достаточно выполнить команду:



lxc init ubuntu:16.04 container1




Для последующего запуска и остановки контейнера используются команды lxc start и lxc stop.



LXC предоставляет хорошие возможности для управления контейнерами «на лету». Вот так, например, можно поместить созданный на основном хосте файл внутрь контейнера:



lxc file push [путь к файлу на основном хосте] [контейнер]/[путь]




Можно совершить и обратную операцию — загрузить файл из контейнера на основной хост:



$ lxc file pull [контейнер]/[путь]




Можно и редактировать файлы в контейнере напрямую:



lxc edit [контейнер]/[путь]




Основные команды для создания и запуска контейнеров мы уже рассмотрели; желающих узнать больше отсылаем к подробной статье Стефана Грабе.



Управление ресурсами





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



В LXD можно выделять контейнерам ресурсы при помощи специального набора команд:



# устанавливаем лимит памяти
lxc config set container1 limits.memory 512M

# привязываем контейнер к ядрам CPU
lxc config set container1 limits.cpu 1,3

# ограничиваем потребление ресурсов CPU
lxc config set container1 cpu.allowance 10%

# ограничиваем объём используемого контейнером дискового пространства(работает только с ZFS или btrfs)
lxc config set container1 root size 10GB




Более подробно почитать об управлении ресурсами можно в этой статье.



Просмотреть статистику потребления ресурсов для контейнера можно с помощью простой команды:



lxc info container1

Name: container1
Architecture: x86_64
Created: 2016/08/16 07:55 UTC
Status: Running
Type: persistent
Profiles: default
Pid: 4110
Ips:
lo: inet 127.0.0.1
lo: inet6 ::1
eth0: inet6 fe80::216:3eff:fe18:faa9 vethA2SCMX
Resources:
Processes: 24
Memory usage:
Memory (current): 48.88MB
Memory (peak): 163.26MB
Network usage:
eth0:
Bytes received: 648 bytes
Bytes sent: 648 bytes
Packets received: 8
Packets sent: 8
lo:
Bytes received: 264 bytes
Bytes sent: 264 bytes
Packets received: 4
Packets sent: 4




Работа со снапшотами





В LXD имеется возможность создания снапшотов и восстановления контейнеров из снапшотов. Посмотрим, как это работает на практике (пример взят из интерактивного туториала LXD).



Внесём некоторые изменения в уже созданный нами контейнер container1:



lxc exec container1 -- apt-get update
lxc exec container1 -- apt-get dist-upgrade -y
lxc exec container1 -- apt-get autoremove —purge -y




Сделаем снапшот этого контейнера и назовём его, например, new:



lxc snapshot container1 new




Попробуем что-нибудь «поломать» в нашем первом контейнере:



lxc exec container1 -- rm -Rf /etc /usr




Поcле этого запустим в нём в нём командную оболочку:



lxc exec container -- bash
I have no name!@container1:~#




Выполним команду exit и вернёмся на основной хост. Восстановим работу контейнера container1 из снапшота:



lxc restore container1 new




Запустим командную оболочку в восстановленном контейнере:



lxc exec container1 -- bash
root@container1:#




Всё работает так же, как раньше!



В приведённом выше примере мы рассмотрели так называемые stateless-снапшоты В LXD есть и другой тип снапшотов — stateful, в которых сохраняется текущее состояние всех процессов в контейнере. Со stateful-снапшотами связаны ряд интересных и полезных функций.



Чтобы создавать stateful-снапшоты, нам понадобится установить программу CRIU(CheckPoint/Restore in Userspace). C её помощью можно сохранить текущее состояние всех процессов, а затем восстановить их хоть на текущей, хоть на другой машине.

В Ubuntu 16.04 утилита CRIU устанавливается при помощи стандартного менеджера пакетов:



apt-get install criu




После этого можно переходить к созданию снапшотов:



lxc snapshot container1 snapshot1 --stateful




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



# перед перезагрузкой
lxc stop container1 --stateful

#после перезагрузки
lxc start container1




На базе stateful-снапшотов реализован механизм «живой» миграции контейнеров, который пока что находится в несколько «сыром» состоянии.



Заключение





LXD представляет собой удобную систему управления контейнерами, обладающую целым рядом полезных функций. Надеемся, что   проект LXD будет успешно развиваться и займёт достойное место в ряду современных инструментов контейнеризации.

Если у вас есть практический опыт использования LXD — добро пожаловать в комментарии.

Если вы по тем или иным причинам не можете комментировать посты здесь — добро пожаловать в наш корпоративный блог.



Естественно, в рамках одной статьи рассказать обо всех функциях LXD вряд ли возможно. Для желающих узнать больше приводим несколько полезных ссылок:


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/308208/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Рай77

В Филадельфии запретили использовать мусорные контейнеры в качестве бассейнов. (Видео)   КреатиFF & WTF. • Action News

Воскресенье, 08 Августа 2016 г. 00:32 (ссылка)
rai77.ru/v-filadelfii-zapre...11866.html



После проведения вечеринки под названием Cedar Street Block Party, в которой приняли участие несколько десятков жителей Филадельфии, городские чиновники запретили использовать мусорные контейнеры в качестве бассейнов.
Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Open source инициатива Docker4Drupal.org

Среда, 27 Июля 2016 г. 10:29 (ссылка)





Уже можно твердо констатировать, что контейнеры и, в частности docker, стали стандартом де-факто для разработчиков. Можно еще спорить о применимости контейнеров в продакшене, но уже никто не спорит, что для локальной разработкой и dev инстансов Docker незаменим.



Именно поэтому мы решили раз и навсегда решить головную боль для друпал разработчиков начав open source инициативу Docker4Drupal.org. Тем более, что для друпала окружение довольно стандартизованное.



Собственно в чем заключается иницитива? Мы предоставляем docker compose файл, который содержит описание сервисов (контейнеров), преднастроенных для работы с Drupal (7 и 8 версий). При запуске compose файла (читайте полную инструкцию на сайте) скачиваются и стартуют контейнеры, необходимые для локальной разработки на Drupal. Используются публичные образы, по возможности официальные.



Выглядит все это примерно так:







Весь этот набор контейнеров мы называем bundle и планируем его регулярно обновлять.



Коротко что есть:




  • Бандл можно настраивать изменяя compose файл, например опционально включить redis/memcached контейнеры чтобы использовать как хранилище кэша по умолчанию

  • Можно поднять поисковую машину Apache Solr с админкой, которая популярна среди друпалистов

  • Есть xdebug, composer и drush

  • По умолчанию ставится phpMyAdmin

  • Можно симпортровать базу при первоначальной развертке подложив файл(ы) с дампом в специальный volume для mariadb контейнера

  • По умолчанию есть mailhog для перехвата и просмотра всех писем отправленных с локального окружения

  • Можно менять версию PHP (5.6 или 7)

  • Можно просматривать логи всех контейнеров сразу или по отдельности



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



Всех друпалистов агитирую подписываться на гитхаб репозиторий и репортить баги.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306504/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
vovan1966

Пластиковые контейнеры — можно ли в них хранить пищу?

Пятница, 09 Июля 2016 г. 00:31 (ссылка)
10sovet.ru/plastikovye-kontejnery.html


Полиэтиленовые контейнеры или кульки? Что полезнее и нужнее? Вам думать... Хранение пищи в полиэтиленовых контейнерах будет здоровым и не вредным? 



Сбалансированная еда может сохранить Ваше здоровье, однако, не это имеет смысла, если вы никак не освоите природные методы хранения здоровой пищи.


 








1.

6 (301x167, 38Kb)


Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Лламочка

Дом, построенный из трех морских контейнеров

Пятница, 08 Июля 2016 г. 09:28 (ссылка)

Это цитата сообщения justvitek Оригинальное сообщение

Дом, построенный из трех морских контейнеров




Всего лишь три морских контейнера и все, можно построить дом!



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



1 (600x400, 228Kb)



2 (403x604, 250Kb)



3 (600x600, 378Kb)



4 (600x317, 243Kb)



5 (587x604, 225Kb)

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_etoday

Павильон для отдыха из контейнеров в Китае

Вторник, 28 Июня 2016 г. 09:00 (ссылка)

Пекинская студия People’s Architecture Office спроектировала общественный павильон для отдыха из транспортных контейнеров.



Павильон для отдыха из контейнеров в Китае


Продолжение поста...




ВКонтакте

Facebook

http://feedproxy.google.com/~r/etoday/~3/J_jqw8KLE5g/pavilyon-dlya-otdyha-iz-konteynerov-v-kitae.php

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
oryoberta

Комплексы С-400 и С-500 станут невидимыми Политикус InfoPolk.ru

Вторник, 14 Июня 2016 г. 18:37 (ссылка)
infopolk.ru/1/U/events/7850...144a12aa01


Чего не хватало нашим «воздушным стражам» и военной технике, так это надежной системы, способной «спрятать» оборудование от глаз врага
...

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Бесплатный вебинар «Сервер приложений WebLogic 12.2: мультиарендность, высокая доступность, Docker-контейнеры»

Пятница, 10 Июня 2016 г. 13:02 (ссылка)

23 июня в 11:00 приглашаем вас на бесплатный вебинар «Сервер приложений WebLogic 12.2: мультиарендность, высокая доступность, Docker-контейнеры». Количество участников не ограничено.





Мы рассмотрим следующие темы:

• Мультиарендность как облачная парадигма. Революционный подход к консолидации приложений и снижению стоимости владения средами;

• Непрерывность и отказоустойчивость. Новые возможности WebLogic 12.2.1 для построения безотказных систем;

• Акселерация циклов разработки. Новые горизонты продуктивности облачной интеграции.



Зарегистрироваться для участия в вебинаре можно по ссылке

Original source: habrahabr.ru.

https://habrahabr.ru/post/303068/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

HPE инвестирует в контейнеры

Среда, 08 Июня 2016 г. 13:46 (ссылка)

Сегодня многие технологические компании обращают пристальное внимание на технологию контейнеров. В их числе – Google, IBM, Microsoft и конечно HPE. Контейнеры позволяют «упаковать» в один физический сервер намного больше приложений, чем это позволяют сделать виртуальные машины. Контейнерные технологии не новы, например, многие знают о них по разработкам компании Parallels, но они играют все более важную роль в центрах обработки данных и облаках. О них и пойдет речь.



image

Немножко не те контейнеры, о которых речь, но надо же привлечь внимание :)



Как и многие компании мира высоких технологий, компания Hewlett Packard Enterprise занимается венчурными инвестициями. Один из недавних примеров – инвестиции в разработчика лидирующих на рынке программно-определяемых объектных хранилищ Scality. Другой пример инвестиций в передовые технологии – поддержка стартапа Mesosphere, разработчика так называемой DC/OS.



Что такое DC/OS и чем она хороша?



Операционная система DC/OS (Data Center Operating System), известная ранее как DCOS, недавно перешла в разряд Open Source. Компания-разработчик Mesosphere из Сан-Франциско решила открыть исходный код ее ядра.



Mesosphere разработала коммерческую версию DCOS пару лет назад. Основанная на ядре Apache Mesos, DC/OS упрощает управление разнородными нагрузками на таких платформах как Hadoop, Spark, Kafka и Docker. К настоящему времени Mesosphere DC/OS стала коллективным проектом, в котором участвуют более 50 компаний, включая Autodesk, Canonical, Cisco, Citrix, EMC, HPE, Joyent, Microsoft, NetApp и Verizon.



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



Чем же хороша в этом плане DC/OS? Хотя контейнеры позволяют достичь хорошей масштабируемости, у них есть недостаток – сложно добиться тесной интеграции с существующими приложениями, такими как базы данных, хранилища данных и платформы для больших данных. DC/OS как раз и разработана для того, чтобы можно было управлять приложениями разного типа в одной среде. Она устраняет разрыв между традиционными бизнес-приложениями и современными облачными приложениями, обеспечивает оркестрацию.



Например, в DC/OS можно работать с горизонтально-масштабируемыми Web-приложениями в контейнерах, взаимодействующих с кластерами Apache Hadoop или Cassandra, использовать Marathon для оркестрации контейнерных приложений и Chronos – для планирования длительных задач. Такая унифицированная среда позволяет наряду с традиционными выполнять масштабируемые контейнерные приложения. Это главная особенность DC/OS.



Хотя для создания и развертывания контейнеров традиционно используется Docker, нужен дополнительный уровень для оркестрации контейнерных приложений. Такими решениями для управления контейнерами на более высоком уровне являются Docker Swarm и Kubernetes. ПО Docker Swarm разрабатывается и поддерживается компанией Docker, а Kubernetes – результат перевода в Open Source подмножества разработанного Google инструмента управления ЦОД под названием Borg. Интересно, что DC/OS может управлять как средами Docker Swarm, так и Kubernetes.



Операционная система DC/OS охватывает все серверы в ЦОД или в облаке и реализует мощный уровень абстрагирования ресурсов. Лежащее в основе DC/OS ядро Apache Mesos для распределенных систем включает в себя планировщик, создающий пул ресурсов, автоматически распределяющий их и планирующий задания согласно запросам и политикам.



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







DC/OS предоставляет гибкие возможности развертывания приложений, сервисов и инфраструктуры больших данных, использующих общие ресурсы. В такой масштабируемой среде можно выполнять разные приложения и нагрузки – от PaaS до приложений больших данных и СУБД. Работает DC/OS в любой современной среде Linux, в частном и публичном облаке, в виртуальных машинах, на «голом железе» x86, обеспечивая эффективное использование ресурсов.



Отраслевая поддержка



В прошлом году для продвижения нативных облачных приложений под руководством Google был сформирован консорциум Cloud Native Computing Foundation (CNCF). Его членами стали Joyent, CoreOS, IBM, VMWare, Cisco, Weaveworks и др. Консорциумом CNCF управляет Linux Foundation. Mesosphere – один из основателей этого консорциума.



Отдельного консорциума по DC/OS компания Mesosphere не создавала, но она поддерживает сообщество разработчиков соответствующего ПО. Если консорциум CNCF в большей степени ассоциируется с Kubernetes, то на повестке дня сообщества, возглавляемого Mesosphere и Microsoft, – вопросы развития и продвижения DC/OS. Эксперты считают, что со временем DC/OS может стать реальной альтернативой Kubernetes.



HPE и Microsoft – ключевые инвесторы Mesosphere. Их инвестиции составили 73,5 млн. долларов, причем ведущая роль принадлежит Hewlett Packard Enterprise. Технология DC/OS будет играть важную роль в гибридных облаках Microsoft и может быть задействована в будущей платформе для частного облака Microsoft Azure Stack. Благодаря сервису Azure Container Service в публичном облаке и DC/OS в частном облаке Microsoft сможет предложить корпоративным заказчикам возможности гибридного облака. В корпоративных ЦОД возможности DC/OS могут также использовать другие технологии, такие как HDInsight в Windows Server.



Разработки Mesosphere нашли отражение в Microsoft Azure Container Service (ACS). Azure Container Service значительно ускоряет разработку ПО. Корпорация Microsoft сделала доступным свой сервис оркестрации контейнеров одновременно с анонсом Mesosphere DC/OS. ACS – это сервис CaaS («контейнеры как сервис»), конкурирующий с Google Container Engine и Amazon EC2 Container Service. Однако ни Amazon, ни Microsoft не являются членами Cloud Native Computing Foundation. В Amazon CaaS применяется проприетарный механизм оркестрации, а Azure Container Service поддерживает Docker Swarm и DC/OS. Kubernetes они не используют.



Компания Verizon применяет Mesosphere DC/OS для управления своими дата-центрами, а Apple, Twitter и Airbnb используют эту технологию для работы с большими объемами данных. Например, Apple задействовала ее в своем виртуальном ассистенте Siri.   



Несомненно, DC/OS должна сыграть важную роль в управлении корпоративными облачными дата-центрами. Именно этим объясняются инвестиции HPE. Будучи задействованной в таких продуктах как HP Helion и Microsoft Azure Stack, она должна помочь корпоративным заказчикам перейти к облачной модели, сохраняя свои инвестиции в ЦОД.



Развертывая Apache Spark, Kafka, Cassandra и Zeppelin в DC/OS, можно получить оптимизированную среду для масштабной обработки данных, ресурсы которой одновременно доступны для других нагрузок, например, для Web-серверов или Java-приложений.



DC/OS на серверах HPE ProLiant и Cloudline



Что же дает развертывание DC/OS на серверах HPE ProLiant и Cloudline? Преимуществ немало:



Масштабируемость, гибкость и автоматизация. Планировщик DC/OS позволяет создавать пул распределенных нагрузок (сервисов DC/OS). Задачи развертывания сервисов, их масштабирования и управления ими сводятся к простым командам, значительно упрощается обеспечение безопасности и непрерывности бизнеса. Серверы HPE ProLiant имеют гибкую архитектуру и расширяемую подсистему ввода-вывода, поэтому они хорошо подходят для такой среды. Гипермасштабируемые серверы семейства HPE Cloudline разработаны специально для провайдеров. Они предусматривают быстрое развертывание, гибкость эксплуатации и имеют низкие показатели TCO.



Ускоренное получение результатов от новых сервисов. DC/OS позволяет предприятиям легко развертывать и масштабировать сервисы (причем в этом может участвовать несколько команд), применять инструменты интеграции типа Jenkins, использовать репозитории объектов и средства контроля кода.



Гибкое управление инфраструктурой. Серверы ProLiant поддерживают такие инструменты управления и обновления ПО как HPE OneView и Smart Update, встроенное удаленное управление и мониторинг средствами HPE iLO. Серверы Cloudline рассчитаны на открытые инструменты управления и стандартные интерфейсы, легко вписываются в неоднородную среду с платформами разных вендоров. HPE – один из основателей открытой спецификации Redfish для программно-определяемых ЦОД. Этот стандарт в значительной степени базируется на реализации RESTful API для HPE iLO. Redfish API можно использовать при работе с серверами HPE ProLiant и Cloudline.



Перемещение, интеграция и доставка приложений между разными средами. HPE придерживается открытых стандартов, архитектур на базе API и Open Source, включая Cloud Foundry, DC/OS и OpenStack. Какой бы ни была облачная среда – частной, публичной или гибридной, для нее доступна обширная экосистема аппаратного, программного обеспечения и услуг.



Быстрый анализ разнородных данных. DC/OS поддерживает такие сервисы как Kafka, Spark и Cassandra, часто используемые в интернете вещей и аналитике больших данных. Это позволяет предприятиям получить простое и готовое решение для приложений больших данных.



Пример: оркестрация контейнеров





В данном примере для оркестрации контейнеров использовались серверы ProLiant DL380 Gen 9 следующей конфигурации:







Логическая архитектура DS/OS с Marathon выглядит так:







Marathon – планировщик ресурсов в кластере. Он обеспечивает высокую масштабируемость приложений и сервисов в среде DC/OS. Marathon работает поверх DC/OS, где есть собственный планировщик для запуска/останова задач или сервисов приложений. В данном случае Marathon выполняет функции более высокого уровня – осуществляет мониторинг и оркестрацию.



DC/OS поставляется с отказоустойчивой службой Marathon для приложений с продолжительным временем работы. В данном примере именно она используется для оркестрации контейнеров – Container Orchestration. Служба marathon-lb обеспечивает балансирование нагрузки для приложений Marathon. Запускается она так:



$ dcos package install –yes marathon-lb


Теперь можно использовать кластерную среду DC/OS с marathon-lb в DC/OS Public Agent. Приложения Marathon, настроенные на балансирование нагрузки, будут видеть соответствующие адреса и порты. Пользовательский интерфейс Marathon выглядит следующим образом:







DC/OS поддерживает как нативные контейнеры Linux, так и контейнеры Docker. Язык спецификации приложений Marathon при этом один и тот же.



Следующий пример на Python показывает конфигурирование приложения Marathon для Web-сервера внутри нативного контейнера Linux. Данное приложение обслуживает Corporate Cafeteria Menu из Load Balancer VIP. Используется балансировщик Marathon Load Balancer. Как показано ниже, определение приложения Marathon – это простой файл simple.json.







Приложение можно запустить из Marathon UI или из DC/OS CLI командой:



$ dcos marathon app add 0c-python-corpmenu-lb.json




Так выглядит Container Orchestration Marathon UI с приложением Web Menu. Определение приложения Corporate Menu содержит инструкции для подключения данного приложения к балансировщику Load Balancer и указывает, какой порт TCP открыт для Web Service.



Теперь протестируем приложение, обращающееся к Load Balancer VIP через заданный сервисный порт (10001). Для выполнения Load Balancer используется DC/OS Public Agent по адресу 10.250.40.138. Балансировщик нагрузки Marathon показывает следующий пользовательский интерфейс Container Orchestration приложения Web Menu:







Теперь можно масштабировать приложение до 1000 экземпляров. Marathon будет запускать их, отслеживая выполнение каждого и показывая статус в UI. Экземпляры распределяются по всем доступным агентам DC/OS Agent. Нагрузка на кластер DC/OS увеличивается:







Теперь протестируем Java-приложение, используя Docker. После запуска 1000 экземпляров в Corporate Web Menu создадим второе приложение Marathon. Оно использует образ Docker, который инсталлирует Java Runtime Environment. Данное приложение будет запускать Apache FTP Server. Определение приложения Marathon для Java-приложения в контейнере Docker выглядит так:







Запустим приложение командой DC/OS CLI:



$ dcos marathon app add 10b-apacheftp-java-docker.json


После запуска одного экземпляра Java-приложения для Docker получим в Marathon UI:





Масштабируем его до 250 экземпляров:







В отличие от примера с Web-сервером, балансировщик Load Balancer для данного приложения не используется. В данном случае в качестве инструмента Service Discovery применяется Mesos-DNS в составе DC/OS. Для определения IP-порта задействован Marathon UI. Для одного экземпляра Java-приложения Marathon UI показывает следующую информацию:







Теперь используем FTP-клиента для тестирования одного из 250 экземпляров Java-приложения:







Container Orchestration: результаты



Итак, в данном примере в кластере DC/OS с использованием двух разных технологий контейнеров было запущено большое число экземпляров приложений. Это делается за считанные минуты, а масштабирование приложений – дело нескольких секунд.







Кроме того, достигается высокий коэффициент использования кластера DC/OS, улучшается показатель ROI.











Контейнерное будущее — сегодня



Итак, подведем итоги. Datacenter Operating System (DC/OS) – открытая платформа для выполнения приложений корпоративного класса, основанная на ядре Apache Mesos. Использование DC/OS корпоративными заказчиками и облачными провайдерами с серверами серии HPE ProLiant и Cloudline позволяет создать гипермасштабируемую среду с СПО. Предприятия получают возможности гибкого развертывания распределенных приложений на надежных системах HPE. DC/OS помогает справиться с растущей сложностью абстрагированной (виртуализованной, контейниризованной и проч.) инфраструктуры ИТ, может оркестрировать любые типы ресурсов в ЦОД, включая физические и виртуальные серверы.



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



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



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



ВМ требуют значительных системных ресурсов. Каждая виртуальная машина содержит не просто копию ОС, а виртуальную копию всех необходимых аппаратных средств. А это требует ресурсов ЦП и ОЗУ. Контейнеру для выполнения конкретного приложения достаточно операционной системы, поддерживающих программ и библиотек. На практике это означает, что сервер сможет поддерживать в два-три раза больше приложений, чем в случае ВМ. А вы уже используете контейнеры в своем ЦОД?
Original source: habrahabr.ru.

https://habrahabr.ru/post/302892/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<контейнеры - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda