Используем Docker и не волнуемся о vendor-lock

Автор: vik_kr Дата: . Категория: Статьи

Docker в значительной мере изменил подход к настройке серверов, поддержке и доставке приложений. Разработчики начинают задумываться о том, можно ли архитектуру их приложений разделить на более мелкие компоненты, которые будут запускаться в изолированных контейнерах, что позволит достичь большего ускорения, параллелизации исполнения и надежности. Также Docker решает важную проблему снятия облачного vendor–lock и позволяет легко мигрировать настроенные приложения между собственными серверами и облаками. Все что требуется от сервера, чтобы запустить Docker – более-менее современная ОС Linux с ядром не ниже 3.8.

В этой статье мы расскажем о том, как просто использовать Docker и какие преимущества он даст сисадмину и разработчику. Забудьте про проблемы с зависимостями, запускайте на одном сервере софт, требующий разные дистрибутивы Linux, не бойтесь «загрязнить» систему неправильными действиями. И делитесь наработками с сообществом. Docker решает множество актуальных проблем и помогает сделать IaaS гораздо более похожими на PaaS, без vendor-lock.

InfoboxCloud Docker

На облачных VPS от Infobox мы сделали готовый образ Ubuntu 14.04 с Docker. Получите бесплатную пробную версию (кнопка «Тестировать 10 дней») и начните использовать Docker прямо сейчас! Не забудьте поставить галочку «Разрешить управление ядром ОС» при создании сервера, это требуется для работы Docker. В самое ближайшее время у нас появятся и другие ОС с Docker внутри. 

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

Что же такое Docker


Docker – open–source движок, автоматизирующий развертывание приложений в легковесные, переносимые, самодостаточные контейнеры, которые могут без изменений переноситься между серверами. 

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

Основные способы использования Docker:

  • Автоматизация упаковки и развертывания приложений
  • Создание собственных легковесных PaaS окружений
  • Автоматизация тестирования и непрерывной интеграции/развертывания
  • Развертывание и масштабирование веб-приложений, баз данных и сервисов бекенда


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

Можно провести неплохую аналогию из области грузоперевозок. До 1960х большинство грузов перевозились вперемешку. Перевозчикам нужно было заботиться о воздействии одного типа груза на другой (например, если наковальни внезапно положили на мешки с бананами). Смена транспорта, например с поезда на корабль, для груза тоже было испытанием. До половины времени поездки занимала погрузка, разгрузка и перегрузка. Были большие потери в процессе поездки из-за повреждения груза. 

Решением проблемы стал стандартный контейнер для перевозки. Теперь любые типы грузов (от помидоров до автомобилей) могли быть упакованы в контейнеры. Контейнеры не открывались до окончания поездки. Легко было эффективно расположить контейнеры на транспорте и перегружать автоматическими кранами при необходимости, без разгрузки самого контейнера. Контейнеры изменили мир грузоперевозок. Сегодня 18 миллионов перевозимых стандартных контейнеров составляют 90% мировой торговли.


Контейнеры для морских грузовых перевозок в порту Циндао, Китай.

Docker можно представить именно как такие контейнеры в коде компьютера. Практически любое приложение может быть упаковано в легковесный контейнер, позволяющий автоматизацию. Такие контейнеры спроектированы, чтобы запускаться виртуально на любом Linux–сервере (с ядром 3.8 и выше).

Другими словами, разработчики могут упаковать свои приложения один раз и будут уверены, что приложение запускается именно в их протестированной конфигурации. Работа сисадминов также значительно упрощается — о поддержке софта нужно заботиться все меньше.
 

Компоненты Docker

 

Клиент и сервер


Docker – клиент-серверное приложение. Клиенты разговаривают с сервером (демоном), который непосредственно делает всю работу. Для управления Docker можно использовать утилиту командной строки docker и RESTful API. Можно запускать клиент и сервер на одном хосте или удаленно подключаться к Docker-серверу.
 

Образы Docker


Свои контейнеры пользователь запускает из образов, которые являются частью процесса построения контейнера. Образ использует AuFS для прозрачного монтирования файловых систем. С помощью bootfs загружается контейнер в память. Затем bootfs отмонтируется, освобождая память. Далее работает rootfs (от Debian, Ubuntu и т.д.). В Docker rootfs монтируется в режиме «только для чтения». Когда контейнер запущен из образа, монтируется файловая система на запись поверх необходимого слоя ниже.


 

Реестры


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

В Docker Hub уже более 10 000 образов с различными ОС и программным обеспечением. Также можно сохранять приватные образы в Docker Hub и использовать их в рамках вашей организации. Использование Docker Hub необязательно. Возможно создание собственных репозиториев вне инфраструктуры Docker (например на ваших корпоративных облачных серверах).
 

Контейнеры


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

Когда Docker запускает контейнер, слой для записи пуст. При изменениях они записываются в этот слой. Например при изменении файла он копируется в слой, доступный для записи (copy on write). Копия «только для чтения» по-прежнему существует, но скрывается. После создания контейнера Docker выстраивает набор read–only образов и подключает слой для записи.
 

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


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


Полный список доступных команд можно получить командой docker help.

Давайте построим контейнер с Ubuntu. 

sudo docker run -i -t ubuntu /bin/bash


Флаг -i оставляет STDIN открытым, даже, когда вы не присоединены к контейнеру. Флаг -t назначает псевдо-tty контейнеру. Таким образом создается интерактивный интерфейс к контейнеру. Так же мы указываем название образа (ubuntu — базовый образ) и шелл /bin/bash.

Давайте установим nano в контейнер. 

apt-get update
apt-get install -y nano


Выйти из контейнера можно командой exit. 

Команда docker ps показывает список всех запущенных контейнеров, а docker ps -a – список всех, включая остановленные.


В списке запущенных контейнеров нет. Когда вы вышли из контейнера, он остановился. На скриншоте выше (docker ps -a) видно имя контейнера. Когда вы создаете контейнер, имя генерируется автоматически. Вы можете указать другое имя при создании контейнера:

docker run --name habrahabr -t -i ubuntu


Обращаться к контейнеру можно не только по ID, но и по имени. 
Давайте запустим контейнер:

docker start stupefied_lovelace


Для подключения к контейнеру необходимо использовать команду attach:

docker attach stupefied_lovelace


(может понадобиться нажатие Enter до появления приглашения).
 

Создаем контейнер-демон


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

docker run --name city -d ubuntu /bin/bash -c "while true; do echo hello world; sleep 1; done"

, где city – имя контейнера. 
Посмотреть, что происходит внутри контейнера можно командой docker logs <имя контейнера>.
Остановить контейнер можно командой docker stop <имя контейнера>. Если после этого запустить контейнер снова docker start <имя контейнера>, выполнение цикла while продолжится в контейнере.

Увидеть детали контейнера можно командой docker inspect <имя контейнера>.
Чтобы удалить контейнер, используйте docker rm <имя контейнера>.
 

Как достать и положить данные?


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

docker cp <путь к данным на хосте> <имя контейнера>:<путь>


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

docker run -v /tmp:/root -t -i <имя образа>

,
где /tmp – путь к папке на хосте, а /root – путь к папке на сервере. Таким образом можно работать из контейнера с данными на хосте и исключить необходимость копирования данных в обе стороны.
 

Работаем с образами


Давайте посмотрим список всех наших образов docker images



Изменения в существующем контейнере можно закоммитить в образ для дальнейшего использования.

docker commit <id контейнера> <имя образа>

.

Перенос образа на другой хост


Наконец-то о главном. Допустим, вы настроили свое приложение в Docker и закоммитили в образ. Теперь можно сохранить образ в файл 

docker save имя_образа > ~/transfer.tar


Копируем этот образ на другой хост например с помощью scp и импортируем его в Docker.

docker load < /tmp/transfer.tar


Вот и все, можно легко переносить свои приложения между хостами, облаками и собственными серверами. Никакого vendor–lock. Только ради этого стоит использовать Docker! (если вы сохраняли данные на примонтированную файловую систему, не забудьте перенести и их).
 

Устанавливаем nginx в Docker


Давайте для примера установим nginx в Docker и настроим его автозапуск. Конечно можно просто скачать образ с nginx для Docker, но мы посмотрим, как это делается с самого начала.

Создайте чистый контейнер с Ubuntu 14.04 с открытыми 80 и 443 портами:

docker run -i -t -p 80:80 -p 443:443 --name nginx ubuntu:trusty


Добавьте в /etc/apt/sources.list официальный репозиторий стабильной версии nginx:

deb http://nginx.org/packages/ubuntu/ trusty nginx
deb-src http://nginx.org/packages/ubuntu/ trusty nginx



Установите nginx:

apt-key update
apt-get update
apt-get install nginx



Можно проверить, что nginx запускается, выполнив:

/etc/init.d/nginx start


Мы увидим страницу приветствия, зайдя на ip сервера на порт 80:


Для различных применений настройки nginx могут отличаться, имеет смысл сохранить контейнер с nginx в образ <ваш логин на hub.docker.com>/nginx:

docker commit nginx trukhinyuri/nginx


Здесь мы впервые встретились с Docker Hub. Время создать аккаунт в этом сервисе и залогиниться с помощью команды docker login. 

Теперь вы можете поделиться образом с другими пользователями или просто сохранить образ для повторного использования на других хостах. Мы не просто так сохраняли образ в формате <имя пользователя>:<тэг образа>. Попытка отправить образ, именнованный в другом формате будет неуспешной. Например если вы попробуете отправить образ, просто названный nginx, вам вежливо сообщат, что в root репозиторий сохранять образы могут только избранные. 

Отправим наш образ trukhinyuri/nginx на docker hub для повторного использования на других серверах в будущем. (здесь trukhinyuri – имя репозитория автора):

docker push trukhinyuri/nginx


Для того, чтобы nginx стартовал при запуске хоста, добавим скрипт инициализации upstart по адресу /etc/init/nginx.conf:

description "Nginx"
author "Me"
start on filesystem and started docker
stop on runlevel [!2345]
respawn
script
  /usr/bin/docker start -a nginx
end script

 

Заключение


В этой статье вы смогли попробовать Docker и оценить, как просто упаковывать приложение и мигрировать между различными хостами. Это только вершина айсберга, очень многое осталось за кадром и будет рассмотрено в будущем. Для дополнительного чтения рекомендуем книгу The Docker Book.

Попробовать образ с Docker в на облачных VPS от Infobox в Амстердаме можно, получивпробную версию бесплатно (кнопка «Тестировать 10 дней»).

Если вы обнаружили ошибку в статье, автор ее с удовольствием исправит. Пожалуйста напишите в ЛС или на почту о ней.
В случае, если вы не можете оставлять комментарии на Хабре — напишите комментарий к статье в Сообществе InfoboxCloud.

Успешного использования!

Увеличение производительности дисковой подсистемы в следующем выпуске гипервизора XenServer

Автор: vik_kr Дата: . Категория: Статьи

Последние тестовые сборки XenServer Creedence Alpha отличаются повышенной производительностью дисковой подсистемы по сравнению с XenServer 6.2 (подробности в блоге Маркуса Гранадо (Marcus Granado) – Performance Improvements in Creedence). В основном, улучшения связаны с внедрением новой архитектуры дисковой подсистемы — tapdisk3. Мы опишем эту технологию организации виртуального хранилища, а также приведем и объясним результаты экспериментов, в которых достигается производительность примерно 10Gb/s одним хосте с подключенным кластерным хранилищем.

RDP vs RemoteFX

Автор: vik_kr Дата: . Категория: Статьи

Введение


В группе предприятий «Х» используют терминальные сервера.
Начался новый сезон и на одном из представительств загрузка cpu начала достигать 100 процентов, что есть плохо, особенно после того, как пользователи начали жаловаться на скорость работы.
Причина возникновения проблемы была не понятна, количество сотрудников не менялось, софт не менялся… Все представительства в одинаковых условиях.

Собрал тестовый стенд и начал искать решение…

Сервер:
HP ML350 G6, 1*Xeon5620, 42gb RAM.
DX аппаратная видеокарта отсутствует.
СХД:
HP MSA P2000 G3 SAS, из 4х дисков SAS собран массив R5.
ПО:
На сервера установлен ESXi 5.1.
Терминальные сервера представляют из себя VM, выделено 4 vcpu(8000мгц) и 20gb RAM, в качестве гостевой ОС используется Windows Server 2008R2 SP1.



Долго перебирал разные настройки сервера и клиентских мест, это отдельная тема. 
 

В творческом поиске сравнил работу протокола RDP и RemoteFX, результаты решил опубликовать


Сравнивалась работы в трех приложениях, IE11, Adobe PDF Reader 11, 1c8. 
Делал 8-10 замеров, в момент замеров на сервере работал только подопытный пользователь и пользователь администратора.
В качестве клиентских мест использовал два ноутбук с Windows XP и Windows 7 SP1, и тонкий клиент HP t510 c установленной ОС HP Smart Zero 4.4.
 

Результаты


IE11, запускался тестовый ролик, который находился на youtube.
В случае работы на ноутбуке по RDP нагрузка на процессор сервера достигает 21-23%.
Если включить RemoteFX, получается 11-18%.

После замены ноутбуков на тонкий клиент HP, в случае RDP намерял 17-21%.
Если включить RemoteFX, получается 10-12%.

В лабораторных условия разница составила 5-10% процесорного времени в пользу RemoteFX.
Добавлю, что RDP по плавности проигрывания видео и рядом не находится с RemoteFX, при включенном RemoteFX, на первый взгляд, разницы в сравнении с обычным ПК не видна.

Все дальнейшие измерения решил проводить на тонком клиенте HP.

Переходим к тестовому документу PDF и скроллингу.
В случае RDP намерял 16-20%.
Если включить RemoteFX, получается 12-17%.
Разница в пользу RemoteFX составила 3-4%.

Настала очередь 1с8, опять будем заниматься скроллингом списка документов.
В случае RDP намерял 14-17%
Если включить RemoteFX, получается 17-18%.
Разница в пользу RDP составила 1-3%.

Честно говоря, результат 1с8 мне не понравился. Решил все проверить и сделать дополнительные замеры. 
Повторно замерял результаты, вроде все ок, укладываюсь в ошибку при измерениях, примерно 1-2%.
Результаты 1с можно списать на ошибку измерения, в итоге получается, что 1с все равно, как подключается пользователь — по RDP или RemoteFX.
 

Если подвести предварительные итоги


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

Раньше я пробовал смотреть на PCoIP, результат мне не понравился, может, нужно посмотреть снова, но как не крути, а RemoteFX будет стоить меньше PCoIP, да и концепция VDI мне нравится меньше терминальных серверов.

В случае предприятия «Х» на одном процессоре Xeon5620 с нагрузкой в 40-80% работают 18-24 пользователей, и параллельно с терминальным сервером работает домен контроллер, и еще некоторые мелкие vm.

Как мне видится, внедрение RemoteFX позволит снизить на 20-30% нагрузку на процессор сервера, или позволит добавить примерно 5-7 пользователей.
 

Интерес к RemoteFX начал расти, и замеры решил продолжить


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

Смотрим ролик на ютюбе(RDP), нагрузка на процессор 18-22%, с стандартними настройками результат 17-21%.
Смотрим ролик на ютюбе(RemoteFX), нагрузка на процессор 10-16%, с стандартними настройками результат 10-12%.

Делаю вывод, что разница минимальная и при желании можно смело выставить высокое качество.

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

Далее, как RemoteFX будет работать при изменении настроек, частота кадров, качество картинки, оптимизация кодека

 

Screen capture rate = Lowest
Screen Image Quality = Medium (default)



Ролик на ютюбе:
Нагрузка на процессор 5-8%

PDF и скроллинг:
Нагрузка на процессор 14-18%

1с8 и скроллинг:
Нагрузка на процессор 12-18%.

В случае медиа получаем выигрыш, но сразу заметно, что видео играет не так плавно и видны подергивания, аналогичные как при RDP.
Если задуматься, в этом нет нечего плохого, все зависит от задач, которые должны выполнять пользователи.

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

Screen capture rate = Medium (default)
Screen Image Quality = Lowest



Ролик на ютюбе
Нагрузка на процессор 5-11%

PDF и скроллинг
Нагрузка на процессор 12-16%

1с8 и скроллинг
Нагрузка на процессор 18-21%.

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

Screen capture rate = Lowest
Screen Image Quality = Lowest



Ролик на ютюбе
Нагрузка на процессор 5-10%

PDF и скроллинг
Нагрузка на процессор 12-16%

1с8 и скроллинг
Нагрузка на процессор 16-19%.

Без комментариев.
 

Screen capture rate = Highest (best quality)
Screen Image Quality = Highest (best quality)



Ролик на ютюбе:
Нагрузка на процессор 9-13%.

Для получения результатов для 1с и PDF, как оказалось, у меня не хватило терпения.

От настроек Highest (best quality) я ожидал другой результат, а полученный можно списать на ошибку измерения.
 

Далее на очереди ооптимизация кодека, Text vs Rich Multimedia


Стандартная настройка кодека Rich Multimedia.

PDF и скроллинг:
Нагрузка на процессор 13-16%

1с8 и скроллинг:
Нагрузка на процессор 16-19%
 

Сводная таблица






 

Итого


На всех терминальных серверах я включил RemoteFX, хуже точно не будет.
Стало интересно, как изменится результат, если добавить аппаратную видеокарту.

Полное отключение синхронизации времени между виртуальной машиной и гипервизором VMware ESXi

Автор: vik_kr Дата: . Категория: Статьи

Небольшая, но довольно полезная статья. Надеюсь поможет кому-нибудь избежать проблем в будущем.
Недавно на одном из наших проектов случился неожиданный шторм инцидентов, вызванный рассинхронизацией времени между виртуалками и NTP-серверами. Причину нашли довольно быстро: в это время происходила массовая онлайн-миграция vMotion между хостами, вызванная обновлением BIOS гипервизоров. Причем хосты тоже получали время с NTP-сервера, но виртуалки на них начинали мигрировать сразу после включения гипервизоров, когда последние еще не успевали полностью синхронизировать время, соответственно возникала разница во времени между хостами между которыми происходила миграция. Очевидно, что это была ошибка со стороны команды виртуализации, однако это вызвало шторм инцидентов на нас, UNIX команде.

Ситуация вызвала большое удивление, ведь настройка “Synchronize time with host” была отключена на всех виртуалках. Причина была найдена в КБ-шке VMware
Особого внимания заслуживают строчки: 

Способ обхода VMware ACE

Автор: vik_kr Дата: . Категория: Статьи

Однажды ко мне попал в руки USB-hdd с программным обеспечением.

Нужноe ПО было установлено в виртуальную машину и запаковано в контейнер 
VMware ACE. Рядом лежала небольшая инструкция по установке и настройке.