InfraKit от Docker основан на GoP и первое, что мне пришлось сделать — установить пакеты golang. Проект рекомендует использовать версию не ниже 17,1, но в Ubuntu 16.04 по умолчанию доступна только 1.6. У меня не было личного опыта работы с Go, но загрузка последнего архива с https://golang.org/dl, проверка его контрольной суммы sha256sum (не забывайте об этом) и последующая распаковка в каталог/usr/local не показались чем-то особенным. По крайней мере, на моей свежеразвернутой виртуальной машине для тестирования:n
curl -0 https://storage.googleapisxorn/gQlang/go1.7.З.linux-amd64.tar.gznsha256sum go1.7.3.Linux-amd64.tar.gznsudo tar -С /usr/local -zxf go.1.7.3.linux-amd64.tar.gzn$ export PATH=SPATH:/usr/local/go/binngo version
Разумеется, эту переменную PATH нужно было на постоянной основе добавить в мой пользовательский профиль. Потребовалось изменить еще кое-какие параметры:n
mkdir -p ~/gonexport GOPATH=!$nexport PATH=$GOPATH/bin:$PATHnmkdir -p -/go/src/github.com/dockerncd !$ngit clone htTps://github.com:docker/infrakit.git n$cd infrakit
Переменная GOPATH также была добавлена в мой профиль. После клонирования релозиториев в локальный каталог можно собрать двоичные файлы (которые появятся в подкаталоге binaries), выполнив следующие команды:
nnНаряду с самим infraKit я увидел набор файлов group’ (группы), ‘instance’ (экземпляры) и flavor’ (дистрибутивы). Если указать их с аргументом ‘help’, вы увидите удобную, хотя и краткую, справку по ним.nВместе с InfraKit есть руководство, которое я употребил в остальной части этой статьи (расширив и предоставив чуть больше полезных сведений). Я хотел создать группу и выполнить некоторое онлайн-масштабирование, а также ознакомиться с частью свойств самовосстановления, которыми Docker наделил infraKit Идеальный плагин для тестирования — instance-file, рекомендуемый специально для этой цели. Для простейшей конфигурации мне также понадобились плагины group-default и flavorvanilla;n
$ build/infrakit-group-defaultnINFO[000Q| Listening at: /home/jolyon/Jnfrakit/plugins/groupn$ mkdir -p testn$ build/infrakit-instance-file -dir ./testnIMFO[0000] Listening at:/home/joiyon/.infrakit/pljgins/instance-fflen$ build/infrakit-fiavor-van i I lanIMFO[0000] Listening at:/home/jolyon/.infrakit/plLjgins/flavor-vanilla
Здесь я запустил плагин для группы по умолчанию, создал каталог test для хранения тестовых экземпляров, затем запустил файл instance и плагины flavor-vanilla. Я убедился, что плагины слушают web-сокет, выпопнив командуn
$ netstat -a I grep infrakit
Обратите внимание, что все три команды слушают в фоновом режиме, поэтому мне потребовалось открыть новое окно терминала для каждой из них. Для тестирования это удобно, так как я вижу вывод каждой команды в соответствующем окне. Я также смог вывести список плагинов командойn
$ build/infrakit plugin ls
Чтобы заставить InfraKit сделать нечто по-настоящему полезное, мне надо передать ему некоторые данные о конфигурации. B/flfratfrtдля этого используется JSON. Лично я предпочитаю YAML. Формат не слишком сложен — воспользуйтесь рисунком на этой странице. Создав этот файл и сохранив его как cattle.json, я выполнил следующую команду:n
$ build/infrakit group watch cattle.json
В сеансе терминала, где была запущена команда group-default, я сразу же увидел сообщения о том, что за группой «скота» осуществляется наблюдение и что в нее добавлены пять экземпляров для достижения необходимого общего количества. Я смог вывести список этих экземпляров, выполнив в «запасном» терминале командуn
build/infrakit group inspect cattle
Одновременно в подкаталоге test появилось пять файлов, имена которых начинались с ‘instance’. Команда inspect показала одинаковое значение SHA для всех элементов одной и той же группы. У плагина группы есть Все это хорошо, но как проверить функцию самовосстановления? Проще всего для этого удалить файл из каталога test командой rm (например, rm test/instance-2778212816405166139). После наикратчайшей из пауз в окне терминала плагина группы появилось сообщение о том, что был добавлен экземпляр для восстановления желаемого уровня. Разумеется, это простой пример, но на том месте с той же легкостью могла быть выполнена повторная подготовка виртуальной машины из AWS с подходящим набором плагинов Тут мне захотелось попробовать расширить группу, Я отредактировал файл cattle.json, изменив количество экземпляров в параметре ‘size’ с пяти до семи и сохранив файл. Выполнив командуn
$ build/infrakit group update cattle.json
я увидел, что выполняется план обновления с приостановкой масштабирования и увеличением целевого размера согласно моим инструкциям. Вскоре после этого добавилась пара новых экземпляров (всё произошло менее чем за секунду). Уменьшение количества экземпляров до четырех и повторное выполнение команды имело обратный эффект. Мне понравилось, что в обоих случаях на довольно простом языке плагин сообщил о том, что план обновления вступил в действие: Executing update plan for cattle1: Terminates 3 instances to reduce the group size to 4nПотом я решил выполнить обновление другого рода — изменить свойства группы, Я скопировал файл caltlejson (в файл cattle2,json) и изменил значение свойства/примечания на версию 2.0 (‘version 2.0/). Я также снова увеличил количество экземпляров до пяти. Затем я смог получить описание обновленного файла на английском языке перед применением этого файла, выполнив командуn
buiid/infrakit describe cattle2json
Performs a rolling update on 4 instances, then adds 1 instances to increase the group size to 5nСнова выполнив команду group update, на сей раз с файлом cattle2.j5on в качестве аргумента, я расшевелил плагин группы. Он определил «нежелательные» экземпляры и поочередно заменил их экземплярами с новой конфигурацией (и добавил один экземпляр, который я запрашивал). Это заняло некоторое время, но в итоге я получил пять экземпляров с обновленными значениями SHA, которые смог просмотреть командой group inspect cattle. Это было бы удобно с точки зрения обслуживания — здесь я фактически выполнил плавающее обновление запущенных экземпляров, что довольно часто требуется с точки зрения приложений.nПри выполнении таких тестов легко забыть, что InfraKit пред-назначен преимущественно для уровня инфраструктуры. Здесь есть пересечения с функциями управления приложениями, расположенными выше в стеке, например, Docker Swarm. Продукт еще находится на ранней стадии развития — из документации к коду обновления сейчас явно видно, что некоторые функции отсутствуют — например, автоматизированный откат изменений или поддержка «канареечного» [canary release] и «зелено-синего [blue-green deployment] развертывания новых версий. В последних типах обновлений второй стек переводится в рабочий режим, и в него поступает трафик балансировщика нагрузки, чтобы легко его тестировать без старого стека. Даже в текущем состоянии InfraKit пригоден для таких задач — наличие двух файлов конфигурации с практически идентичным содержимым (за исключением идентификатора группы) позволит запускать их одновремен но друг с другом, хотя это достигалось и с помощью балансировщика нагрузки. Так каков же вердикт? Мне нравится InfraKit. Мои примеры были тривиальными, но у продукта есть потенциал. Я могу предположить недовольства после слияния с движком Docker Engine, учитывая объем работы, предпринятый е этой области. Но зато каждый, кто пользуется Docker, получит InfraKit в готовом виде.n
Внедрение и поддержка инфраструктуры Docker, Infrakit, Ansible и другие, обращайтесь [email protected]