Otto — это новый продукт от Hashicorp, логический наследник Vagrant, призванный упростить процесс разработки и деплоя программ в современном мире облачных технологий. Концептуально новый подход к проблеме, проверенные технологии под капотом и открытый исходный код. Персональный DevOps ассистент разработчика.
Первый продукт Митчелла Хашимото, основателя Hashicorp — всем хорошо известный Vagrant — положил начало целой цепочке качественных продуктов по автоматизации процессов разработки и деплоя программ. Packer помогает создавать финальные образы виртуальных машин, будь это VirtualBox, Docker или Google Cloud. Terraform создаёт и выносит на уровень конфигурации сложнейший процесс построения целых инфраструктур в облаке, тоже без привязки к конкретному провайдеру. Consul и Serf отвечают за коммуникации в облаке — обнаружение сервисов, мониторинг падений и так далее. Vault является надёжным распределенным хранилищем секретов, паролей и чувствительных данных, с возможностью аудита, контроля доступа и отзыва ключей.
Все эти продукты с открытым исходным кодом, очень качественно написаны, отлично документированы, просты в установке, поскольку написаны на Go, обладают интуитивным интерфейсом и API и хорошо делают те задачи, для которых создавались. Если их правильно использовать, то в связке они очень облегчают жизнь современному разработчику, который работает с микросервисами, облаками, виртуальными машинами и контейнерами.
Разработчикам больше не нужно быть devops-профи, чтобы выполнять простые вещи в облаке — вышеприведенные программы стараются забрать основную головную боль на себя и/или переложить её на отдельный devops-отдел. Но всё-таки, это 6 отдельных программ, которые всё-равно нужно осваивать, читать документацию и изучать. Это приводит к тому, что всё равно самым распространенным способом деплоя в облако того или иного стека остаётся старый добрый копипаст из первых страниц выдачи Google на запрос «как задеплоить [ruby/php/etc] на [aws/gae/do/etc]».
Более того, будь то копипаст или написанный кем-то Packer/Terraform-конфиг или Vagrantfile — все они рано или поздно устаревают, по мере смены версий, изменении URL-ов, переходу на новые протоколы и так далее. Плюс, пользователи Vagrant с самых первых версий просят добавить возможность деплоить приложение. Но Vagrantfile это совсем другой уровень абстракции, чтобы описывать подобные вещи.
Всё это привело Hashicorp к пониманию, что нужен новый подход к проблеме.
Не знаю, как правильно эти термины перевести, но пусть будет «кодирование» против «мумификации». Мне посчастливилось быть на презентации Otto (и Nomad, шедулера от Hashicorp) в офисе DigitalOcean в Нью-Йорке, буквально через пару дней после анонса обоих продуктов на конференции Hashiconf, и именно этими терминами Хашимото описывал основную идею Otto и концептуальное отличие его от Vagrant.
То, что делает Vagrant, Packer и Terraform — это «мумификация» среды разработчика. Вы прописываете все необходимое для разработки вашей программы, все настройки, ссылки и команды, и это гарантирует, что даже через 10 лет, любой разработчик сможет поднять ту же среду разработки, что и сейчас, один в один.
Но что, если через 10 лет, URL-ы, откуда тянется нужный компилятор или фреймворк, уже изменились? Или мир перешёл на новый протокол YTTP3? Все должны обновлять свои Vagrant-файлы. Сейчас Packer знает, как заливать образ на Amazon и DigitalOcean и как создавать VPC, вы это внимательно прописали, но что, если через год Amazon поменяет API, введёт новую модель безопасности внутри сетей или добавит ещё какие-нибудь новшества, которые автоматически делают ваш Packer/Terraform-файл устаревшим?
Otto предлагает концептуально новый подход к вопросу и это «кодирование» процесса создания среды разработки и деплоя. Вы говорите otto, что вы хотите («мое приложение на Go и должно запускаться на AWS, общаться с mysql-базой и смотреть наружу на порту таком-то») и otto дальше делает всю магию за вас, зная, лучше большинства, как это делать правильно.
Звучит пугающе? Давайте разберемся подробнее.
Под капотом otto использует тот же Vagrant, Packer, Terraform, Consul и Vault, и, фактически, избавляет вас от надобности даже знать про их существование. Если что-то не установлено — otto в удобной форме сам спросит, скачать ли их и установить за вас или нет.
Далее, стандартный workflow очень похож на работу с Vagrant:
Otto использует только один файл — Appfile, который для простых случаев даже не обязателен, так как otto умеет, к примеру, угадывать тип проекта. Формат файла — хашикорповский HCL, который легко читается и пишется. Пример Appfile:
Этап «компиляции» (otto compile) читает Appfile и (пере)создает поддиректорию .otto, которая выглядит примерно так:
Это важный момент, который отражает отличие «кодирования» от «мумификации». Каждый раз когда будет меняться Appfile или обновляться otto — команда `otto compile` будет обновлять все эти подкапотные внутренности, создавая нужную конфигурацию для Vagrant, Packer и Terraform. Если изменились «лучшие практики» того, как устанавливать зависимости и подготавливать среду — то на этапе компиляции ваша otto-среда будет обновлена. Если же не запускать команду compile, otto будет работать с уже скомпилированной версией Appfile.
Этап подготовки среды — otto dev — фактически заменяет собой vagrant init и vagrant up. Поднимается виртуальная машина (пока что только Ubuntu hashicorp/precise64, но в будущем OS будет также на выбор), настраивается сеть, SSH-ключи, устанавливаются зависимости и необходимые пакеты — вобщем, вся магия, которая даёт возможность любому новоприбывшему в проект разработчику выполнить простую команду `otto dev ssh` и попасть в готовую среду разработки.
Когда программа готова, otto может взять на себя и задачу по деплою приложения в облако. Разработчику теперь не обязательно знать все тонкости настройки веб-серверов, виртуальных приватных сетей и прочих подробностей. Цикл деплоя с otto состоит из трех шагов — построения инфраструктуры, билда имиджа приложения и, собственно, деплоя:
Под «инфраструктурой» тут подразумевается все ресурсы, связанные с каждым конкретным провайдером облачных сервисов. `otto infra` создает подсети, настраивает роутинги, bastion-хосты, gateways, VPC и прочее, о чём обычно нужно читать много и долго, чтобы вообще понять, как оно работает. Otto забирает весь этот груз на себя — он «знает», как работать со всем этим и делает наиболее оптимальным образом, с соблюдением всех best practices. Различные варианты инфраструктур называются «flavors» и описывают разные варианты — «простая машина в облаке с доступом по SSH», «приватная сеть с IP смотрящим наружу» и т.д. Под капотом этим всем занимается Terraform.
Дальнейшие шаги — `otto build` и `otto deploy` — собирают образ, готовый для запуска в облаке и запускают инстанс. Это может быть AMI или Docker-контейнер, или что-нибудь ещё, что otto будет поддерживать в будущем.
Вот так просто. Теперь, даже дизайнер веб-сайта на PHP может синхронизировать проект, запустить otto, и запустить сайт в облаке, без единого знания, как это устроено и как работает.
Ну и последнее, в типичном workflow разработчика — команда `destroy`.
Ещё раз хочу сделать акцент на том, что otto будет развиваться по мере того, как развиваются и меняются облачные технологии, языки и фреймворки, но последовательность действий и алгоритм работы с otto будет оставаться неизменным.
Современные приложения для облака часто используют архитектуру микросервисов в той или иной форме, и каждое приложение зачастую зависит от других и может быть очень сложно поднять все зависимости правильно. Otto тоже старается забрать на себя этот вопрос, и использует понятие зависимостей (dependencies), которые прописываются в Appfile и имеют вид URL на зависимость, представляющую собой тоже проект otto. К примеру, если в проекте есть зависимость на MongoDB:
Залогинившись в свое dev-окружение, мы сможем обратиться к mongodb по DNS адресу `mongodb.service.consul`.
Всё это должно в теории очень упростить разработку сервисов, у которых есть много непростых зависимостей.
Otto вышел всего неделю назад, находится в версии 0.1, и пока что много чего не поддерживает. На данный момент реализована поддержка (магия тоесть) для Go, PHP, Docker (для зависимостей), Node.js и Ruby, хотя тоже ещё очень ограничено. Деплоймент пока поддерживается только для Amazon, но вскоре будут добавлены и другие провайдеры. Тут можно быть оптимистами, так как otto сам по себе этим не занимается, а использует Terraform и Packer, в котором поддерживаются Azure, CloudFlare, DigitalOcean, GAE, Heroku, OpenStack и потенцально много чего ещё.
Везде есть возможность указывать свои кастомные Vagrantfile или Terraform-конфиги, что делает otto очень легко расширяемым и применимым даже для очень нестандартных и изощренных схем.
На момент написания статьи otto — ещё диковинка, хоть и использующая под капотом достаточно хорошо проверенные временем инструменты. Насколько сама идея otto — магического DevOps-ассистента для разработчиков — себя зарекомендует, покажет время.
Лично у меня деятельность Hashicorp давно уже оставляет одно впечатление — они знают что делают, и медленно, но уверенно двигаются к этой цели. Митчелл говорил в выступлении, что идея Otto была у него давно, но он понимал, что такого уровня проект не создать с нуля. Поэтому год за годом готовил почву, кубики для её реализации. Кстати, nomad — тоже один из таких кубиков, и очень скоро будет также поддерживаться в otto.
Более того, разработка ведётся очень активно, код у Hashicorp очень качественный, о продуктивности Хашимото в народе слагают легенды, и последние несколько лет ребята показывали впечатляющий прогресс. Hashicorp создают целую экосистему для удобства работы в облаке.
Так что держите руку на пульсе.
У Otto отличный сайт и документация: www.ottoproject.io
Сайт Hashicorp: hashicorp.com
Введение
Первый продукт Митчелла Хашимото, основателя Hashicorp — всем хорошо известный Vagrant — положил начало целой цепочке качественных продуктов по автоматизации процессов разработки и деплоя программ. Packer помогает создавать финальные образы виртуальных машин, будь это VirtualBox, Docker или Google Cloud. Terraform создаёт и выносит на уровень конфигурации сложнейший процесс построения целых инфраструктур в облаке, тоже без привязки к конкретному провайдеру. Consul и Serf отвечают за коммуникации в облаке — обнаружение сервисов, мониторинг падений и так далее. Vault является надёжным распределенным хранилищем секретов, паролей и чувствительных данных, с возможностью аудита, контроля доступа и отзыва ключей.
Все эти продукты с открытым исходным кодом, очень качественно написаны, отлично документированы, просты в установке, поскольку написаны на Go, обладают интуитивным интерфейсом и API и хорошо делают те задачи, для которых создавались. Если их правильно использовать, то в связке они очень облегчают жизнь современному разработчику, который работает с микросервисами, облаками, виртуальными машинами и контейнерами.
Разработчикам больше не нужно быть devops-профи, чтобы выполнять простые вещи в облаке — вышеприведенные программы стараются забрать основную головную боль на себя и/или переложить её на отдельный devops-отдел. Но всё-таки, это 6 отдельных программ, которые всё-равно нужно осваивать, читать документацию и изучать. Это приводит к тому, что всё равно самым распространенным способом деплоя в облако того или иного стека остаётся старый добрый копипаст из первых страниц выдачи Google на запрос «как задеплоить [ruby/php/etc] на [aws/gae/do/etc]».
Более того, будь то копипаст или написанный кем-то Packer/Terraform-конфиг или Vagrantfile — все они рано или поздно устаревают, по мере смены версий, изменении URL-ов, переходу на новые протоколы и так далее. Плюс, пользователи Vagrant с самых первых версий просят добавить возможность деплоить приложение. Но Vagrantfile это совсем другой уровень абстракции, чтобы описывать подобные вещи.
Всё это привело Hashicorp к пониманию, что нужен новый подход к проблеме.
Codification vs. Fossilization
Не знаю, как правильно эти термины перевести, но пусть будет «кодирование» против «мумификации». Мне посчастливилось быть на презентации Otto (и Nomad, шедулера от Hashicorp) в офисе DigitalOcean в Нью-Йорке, буквально через пару дней после анонса обоих продуктов на конференции Hashiconf, и именно этими терминами Хашимото описывал основную идею Otto и концептуальное отличие его от Vagrant.
То, что делает Vagrant, Packer и Terraform — это «мумификация» среды разработчика. Вы прописываете все необходимое для разработки вашей программы, все настройки, ссылки и команды, и это гарантирует, что даже через 10 лет, любой разработчик сможет поднять ту же среду разработки, что и сейчас, один в один.
Но что, если через 10 лет, URL-ы, откуда тянется нужный компилятор или фреймворк, уже изменились? Или мир перешёл на новый протокол YTTP3? Все должны обновлять свои Vagrant-файлы. Сейчас Packer знает, как заливать образ на Amazon и DigitalOcean и как создавать VPC, вы это внимательно прописали, но что, если через год Amazon поменяет API, введёт новую модель безопасности внутри сетей или добавит ещё какие-нибудь новшества, которые автоматически делают ваш Packer/Terraform-файл устаревшим?
Otto предлагает концептуально новый подход к вопросу и это «кодирование» процесса создания среды разработки и деплоя. Вы говорите otto, что вы хотите («мое приложение на Go и должно запускаться на AWS, общаться с mysql-базой и смотреть наружу на порту таком-то») и otto дальше делает всю магию за вас, зная, лучше большинства, как это делать правильно.
Звучит пугающе? Давайте разберемся подробнее.
Подробности
Под капотом otto использует тот же Vagrant, Packer, Terraform, Consul и Vault, и, фактически, избавляет вас от надобности даже знать про их существование. Если что-то не установлено — otto в удобной форме сам спросит, скачать ли их и установить за вас или нет.
Далее, стандартный workflow очень похож на работу с Vagrant:
- otto compile
- otto dev
- otto dev ssh
Otto использует только один файл — Appfile, который для простых случаев даже не обязателен, так как otto умеет, к примеру, угадывать тип проекта. Формат файла — хашикорповский HCL, который легко читается и пишется. Пример Appfile:
application {
name = "otto-getting-started"
type = "ruby"
}
project {
name = "otto-getting-started"
infrastructure = "otto-getting-started"
}
infrastructure "otto-getting-started" {
type = "aws"
flavor = "simple"
}
Этап «компиляции» (otto compile) читает Appfile и (пере)создает поддиректорию .otto, которая выглядит примерно так:
Это важный момент, который отражает отличие «кодирования» от «мумификации». Каждый раз когда будет меняться Appfile или обновляться otto — команда `otto compile` будет обновлять все эти подкапотные внутренности, создавая нужную конфигурацию для Vagrant, Packer и Terraform. Если изменились «лучшие практики» того, как устанавливать зависимости и подготавливать среду — то на этапе компиляции ваша otto-среда будет обновлена. Если же не запускать команду compile, otto будет работать с уже скомпилированной версией Appfile.
Этап подготовки среды — otto dev — фактически заменяет собой vagrant init и vagrant up. Поднимается виртуальная машина (пока что только Ubuntu hashicorp/precise64, но в будущем OS будет также на выбор), настраивается сеть, SSH-ключи, устанавливаются зависимости и необходимые пакеты — вобщем, вся магия, которая даёт возможность любому новоприбывшему в проект разработчику выполнить простую команду `otto dev ssh` и попасть в готовую среду разработки.
Когда программа готова, otto может взять на себя и задачу по деплою приложения в облако. Разработчику теперь не обязательно знать все тонкости настройки веб-серверов, виртуальных приватных сетей и прочих подробностей. Цикл деплоя с otto состоит из трех шагов — построения инфраструктуры, билда имиджа приложения и, собственно, деплоя:
- otto infra
- otto build
- otto deploy
Под «инфраструктурой» тут подразумевается все ресурсы, связанные с каждым конкретным провайдером облачных сервисов. `otto infra` создает подсети, настраивает роутинги, bastion-хосты, gateways, VPC и прочее, о чём обычно нужно читать много и долго, чтобы вообще понять, как оно работает. Otto забирает весь этот груз на себя — он «знает», как работать со всем этим и делает наиболее оптимальным образом, с соблюдением всех best practices. Различные варианты инфраструктур называются «flavors» и описывают разные варианты — «простая машина в облаке с доступом по SSH», «приватная сеть с IP смотрящим наружу» и т.д. Под капотом этим всем занимается Terraform.
Дальнейшие шаги — `otto build` и `otto deploy` — собирают образ, готовый для запуска в облаке и запускают инстанс. Это может быть AMI или Docker-контейнер, или что-нибудь ещё, что otto будет поддерживать в будущем.
Вот так просто. Теперь, даже дизайнер веб-сайта на PHP может синхронизировать проект, запустить otto, и запустить сайт в облаке, без единого знания, как это устроено и как работает.
Ну и последнее, в типичном workflow разработчика — команда `destroy`.
- otto deploy destroy
- otto infra destroy
- otto dev destroy
Ещё раз хочу сделать акцент на том, что otto будет развиваться по мере того, как развиваются и меняются облачные технологии, языки и фреймворки, но последовательность действий и алгоритм работы с otto будет оставаться неизменным.
Микросервисы
Современные приложения для облака часто используют архитектуру микросервисов в той или иной форме, и каждое приложение зачастую зависит от других и может быть очень сложно поднять все зависимости правильно. Otto тоже старается забрать на себя этот вопрос, и использует понятие зависимостей (dependencies), которые прописываются в Appfile и имеют вид URL на зависимость, представляющую собой тоже проект otto. К примеру, если в проекте есть зависимость на MongoDB:
application {
name = "otto-getting-started"
type = "ruby"
dependency {
source = "github.com/hashicorp/otto/examples/mongodb"
}
}
Залогинившись в свое dev-окружение, мы сможем обратиться к mongodb по DNS адресу `mongodb.service.consul`.
Всё это должно в теории очень упростить разработку сервисов, у которых есть много непростых зависимостей.
Текущие ограничения
Otto вышел всего неделю назад, находится в версии 0.1, и пока что много чего не поддерживает. На данный момент реализована поддержка (магия тоесть) для Go, PHP, Docker (для зависимостей), Node.js и Ruby, хотя тоже ещё очень ограничено. Деплоймент пока поддерживается только для Amazon, но вскоре будут добавлены и другие провайдеры. Тут можно быть оптимистами, так как otto сам по себе этим не занимается, а использует Terraform и Packer, в котором поддерживаются Azure, CloudFlare, DigitalOcean, GAE, Heroku, OpenStack и потенцально много чего ещё.
Везде есть возможность указывать свои кастомные Vagrantfile или Terraform-конфиги, что делает otto очень легко расширяемым и применимым даже для очень нестандартных и изощренных схем.
Выводы
На момент написания статьи otto — ещё диковинка, хоть и использующая под капотом достаточно хорошо проверенные временем инструменты. Насколько сама идея otto — магического DevOps-ассистента для разработчиков — себя зарекомендует, покажет время.
Лично у меня деятельность Hashicorp давно уже оставляет одно впечатление — они знают что делают, и медленно, но уверенно двигаются к этой цели. Митчелл говорил в выступлении, что идея Otto была у него давно, но он понимал, что такого уровня проект не создать с нуля. Поэтому год за годом готовил почву, кубики для её реализации. Кстати, nomad — тоже один из таких кубиков, и очень скоро будет также поддерживаться в otto.
Более того, разработка ведётся очень активно, код у Hashicorp очень качественный, о продуктивности Хашимото в народе слагают легенды, и последние несколько лет ребята показывали впечатляющий прогресс. Hashicorp создают целую экосистему для удобства работы в облаке.
Так что держите руку на пульсе.
Ссылки
У Otto отличный сайт и документация: www.ottoproject.io
Сайт Hashicorp: hashicorp.com
