Знакомимся с Otto, наследником Vagrant

    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 к пониманию, что нужен новый подход к проблеме.

    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
    • +21
    • 30,1k
    • 9
    Поделиться публикацией
    Комментарии 9
      +7
      Вы прописываете все необходимое для разработки вашей программы, все настройки, ссылки и команды, и это гарантирует, что даже через 10 лет, любой разработчик сможет поднять ту же среду разработки, что и сейчас, один в один.
      Для этого нужно хранить образ системы, а не вагрант файл с провизией. Потому что репозитории через некоторое время начинают отваливаться, особенно на не LTS релизах.
        0
        Ну вопрос же в стоимости этого «хранить образ системы». В git не положишь.
        +4
        Спасибо за познавательную статью, но, на мой взгляд, назвать otto наследником vagrant не совсем честно. otto не ставит себе задачу заменить vagrant, а лишь упростить работу с ним и с остальными инструментами от hashicorp. Я недавно сделал обзор всего их инструментария, поэтому расскажу про свои впечатления:
        vagrant Активно пользуюсь им, умеет деплоить, но очень ограничено.
        vault — мне как php разработчику не совсем ясно как с ним работать, кроме вызова консольных команд не обнаружил никакого api. Продукт стабильный, но очень ограниченный в этом плане.
        otto — еще очень сырой
        terraform — по нему не могу сказать, вроде как может многое, но ощущается острый недостаток реальных примеров использования. Я не про aws и прочих что идут из коробки, а кастомных, например, у нас есть парк из 8 серверов. Хостер не из списка поддерживаемых. Как нам поможет terraform? Ответов на эти вопросы я не нашел.
        consul отличный проект, но его надо как-то настроить на всех серверах, если otto справится с этим, то будет прекрасно.
        nomad на данный момент не увидел смысла в его практическом применении.

        Итого в остатке: хорошие инструменты, которые из коробки поддерживают крупных хостеров (aws и прочие), но о применимости при наличии собственного парка серверов ничего не известно.
          0
          otto не ставит себе задачу заменить vagrant, а лишь упростить работу с ним и с остальными инструментами от hashicorp.

          Ну, на данный момент otto и vagrant вполне себе существуют параллельно, но в будущем otto будет использоваться как единый тул (с вагрантом под капотом, но люди ничего об этом знать не обязаны). Этому даже отдельная страничка посвящена на сайте otto: www.ottoproject.io/intro/vagrant-successor.html

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

          Он не ограниченный, просто сфера ваших занятия не пересекается с тем, для чего делался vault. Основные клиенты vault — это большие организации, сложные инфраструктуры, энтерпрайз и так далее, где количество людей, машин, сервисов и требований велико, и чем больше, тем очевидней необходимость в решении, подобном Vault.
          API у него через HTTP: vaultproject.io/docs/http/index.html

          nomad на данный момент не увидел смысла в его практическом применении.

          Сейчас главная драка идет уже не за контейнеры, а за средства для их оркестрации. Микросервисы (и не очень мини-) пишут все налево и направо, но правильно менеджить и управлять этим все также сложно. Есть масса решений — Mesos(+Marathon), Docker Swarm, Kubernetes, AWS ECS и тд, но у всех еще большой порог вхождения и высокая сложность. Nomad — это еще один игрок на этом рынке, и хотя еще совсем необкатанный, но с очень мощным бэкграундом (он основан на трех научных работах от Google и Беркли), и выглядит очень приятно, особенно на фоне других решений.
            0
            consul отличный проект, но его надо как-то настроить на всех серверах


            Собственно, что там настраивать? Другое дело, что нужно либо допиливать софт, либо писать для него обвязки типа docker-registrator и consul-template, чтобы запускаемые службы регистрировались в consul, а зависящие от них оперативно реагировали на запуск-регистрацию и краши с даунами.
            0
            Опаздывают они, особенно после выхода Docker Mashine
              0
              Ну, Otto несколько другие цели преследует, чем Docker Machine.
                0
                так в чем же разница? Можете подробно осветить, а то в статье не освещены альтернативы
                  0
                  Ну, могу лишь пересказать то, что написано на сайте Otto — там целый раздел есть «Otto vs other software», и, в частности, страничка про сравнение Otto и Docker: www.ottoproject.io/intro/vs/docker.html

                  Вкратце — docker(-machine,-swarm,-compose) завязано только под Docker (что логично). Otto — универсальное решение, которое может использовать Docker в том числе. Плюс это одна команда, один конфиг-файл, гораздо проще workflow, это специализированный инструмент со своим подходом и философией.

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

            Самое читаемое