The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Представлен Otto, инструментарий для создания микросервисов из изолированных приложений

28.09.2015 23:23

Компания HashiCorp, известная разработкой системы Vagrant, представила проект Otto, в рамках которого разработан новый инструментарий для создания и развёртывания приложений, упакованных в изолированные контейнеры или образы для различных облачных окружений. Otto продвигает концепцию микросервисов, включающих определённую программу и необходимые для её работы зависимости. При этом микросервисы не привязаны к конкретной технологии изоляции и могут быть сформированы для различных систем. Код проекта написан на языке Go (Vagrant написан на Ruby) и распространяется под лицензией MPL 2.0 (Mozilla Public License).

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

Otto предоставляет инструменты для автоматической сборки самодостаточного окружения, необходимого для работы разрабатываемого приложения, и развёртывания этого окружения в типовых системах виртуализации и контейнерной изоляции. На основании типа приложения Otto автоматически подбирает зависимости: например, для PHP-программ он загрузит, установит и настроит в окружении PHP и связанные с ним средства разработчика. Если приложение зависит от внешних сервисов, таких как СУБД, Otto самостоятельно определит это и установит в окружении нужные версии данных сервисов, а также необходимые для этих сервисов зависимости. Поддерживается интеграция с Docker, который может вызываться для загрузки и запуска подготовленных в Otto микросервисов.

Базовая конфигурация приложения задаётся в форме Appfile. Например, для приложения на языке Ruby 2.1, хранящем данные в СУБД PostgreSQL, Appfile может выглядеть следующим образом:


   application {
     name = "my-app"
     type = "ruby"

     dependency {
        source = "github.com/hashicorp/otto/examples/postgresql"
     }
   }

   customization "ruby" {
     ruby_version = "2.1"
   }

Параметры запуска окружения и лимиты выбираются в соответствии с типовыми требованиями для указанных зависимостей. Конфигурация может быть подобрана автоматически при помощи выполнения команды "otto compile" в директории с кодом приложения. Создать локальное окружение для тестирования и разработки можно командой "otto dev". Для создания инфраструктуры для эксплуатации этого окружения (например, в Amazon Web Services) достаточно выполнить команду "otto infra". Для подготовки образа с приложением для запуска в созданной инфраструктуре следует выполнить команду "otto build". Для запуска окружения в созданной инфраструктуре нужно выполнить команду "otto deploy". Таким образом, разработчику не нужно заботиться о выборе систем изоляции и подбирать зависимости - Otto всё сделает самостоятельно с использованием наиболее хорошо зарекомендовавших себя методов, подходящих для текущих условий.

Одновременно с Otto была представлена платформа Nomad, предназначенная для управления кластером серверов и запуска окружений с приложениями в данном кластере. Nomad абстрагируется от отдельных серверов и местоположения приложений, предлагая пользователю лишь определить, что он хочет запустить, а вопрос "где и как будет запущено окружение" платформа берёт на себя. Для выполнения окружений может быть использован Docker, но Nomad не ограничивается им и позволяет использовать драйверы для запуска с использованием иных платформ контейнерной изоляции или виртуализации для Linux, Windows, BSD и OS X. Для упрощения работы клиентская и серверная части объединены в один исполняемый файл.

  1. Главная ссылка к новости (https://www.hashicorp.com/blog...)
  2. OpenNews: Проект CoreOS представил Rocket, конкурирующий с Docker инструментарий управления контейнерами
  3. OpenNews: Docker и CoreOS объединили усилия в разработке единого формата контейнеров
  4. OpenNews: Выпуск Kubernetes 1.0, системы управления кластером изолированных контейнеров
  5. OpenNews: Доступен Docker 1.8. Представлена система для запуска Docker-контейнеров поверх гипервизора
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/43055-otto
Ключевые слова: otto
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (36) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.3, Аноним (-), 02:04, 29/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А есть примеры, где удобно применять?
     
     
  • 2.5, Аноним (-), 02:20, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > ruby
    > смузи
    > митапы

    Ну может и найдёшь пару весьма специфических use-cases на всю отрасль.

     
     
  • 3.11, Аноним (-), 15:20, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Понимаете ли, отрасль растёт горизонтально. И рубероиды и Go-пники, пьющие смузи на очередном митапе сообразили как это сделать. Конечно же, ретарды, пьющие пиво их возненавидят, и будут голосом тигара и унимана вещать про дэбиллoв и и_дидов. Приятно на это смотреть.

    По юзкейсам на моих работах:
    - Много машин, нужна аппаратная виртуализация
    - Много машин, и уже никак без виртуалбох/хипстер-в. Хочу квм
    - kvm, xen, lxc. Самодельные чруты - сеть? Разносим по портам. Прихожу к самоизобретённой парадигме, напоминающей DevOps
    - kvm, openvz, virsh, proxmox, virt-manager. Cтал девопсом, нравится опенстек, хочу.
    - openstack, vagrant, docker.
    - openstack, vagrant, docker. Контейнеры рулят. Аппаратная виртуализация не особо нужна. Слишком мало докера, хотя он уже не настолько сырой, работает даже....
    - docker, kubernetes и не только... А вот теперь всё это причёсываем.

     
     
  • 4.12, grec (?), 17:16, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    И так будет бесконечно и все погрязнет в вечном дебаге.
     
     
  • 5.13, Аноним (-), 17:31, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Подтверждаю, не вечно, но иногда бывает.
     
  • 4.14, Crazy Alex (ok), 19:06, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Если б кто-нибудь внятно описал, зачем всё это надо - ретарды, пьющие пиво, ненавидели бы меньше. Но пока внятных описаний "зачем оно и как именно оно приносит/экономит деньги" не попадалось, особенно про DevOps.

    Аппаратная виртуализация - понятно зачем. Контейнеры - уже нет.

     
     
  • 5.15, аноним2 (?), 19:40, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    про системное окружение почитай
     
  • 5.16, Аноним (-), 19:59, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Аппаратная виртуализация - понятно зачем. Контейнеры - уже нет.

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

     
     
  • 6.22, Crazy Alex (ok), 00:26, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Да я вообще от каких-либо серверов уже лет несколько, как далёк. Десктопы, мобилы, эмбед...
     
  • 5.17, Аноним (-), 22:02, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Я ничего не имею против того, чтобы меня ненавидели ретарды.

    Для табя, и прочих тигаро-изено-юниманов:
    - Самые лучшие реализации гипервизоров, такие как kvm, дают минимум 15% оверхеда. Остальные, же - намного хуже.
    - Концепция микросервисов
    - Виртуализируем в основном пингвина на пингвине. А может лучше контейнер?
    - Cgroups сегодня нарезает ресурсы даже получше, чем отдельные ВМ.
    - Оверхед контейнера незаметен.
    - Докер выстрелил в основном не благодаря технологичности и крутой изоляции, которой пока нет, а благодаря управляторам-консолидаторам вокруг него.

    Понимание философии DevOps приходит при увеличении масштабов информационной системы до такого уровня, когда 1 человек уже не справляется. Мой пример - 300 физик, более 1000 виртуалок, 4 девопса. Несколько тысяч виртуалок на амазоне - 2,5девопса+0,5админа - это у знакомых.

    Экономия денег - возможность горизонтального роста инфраструктуры.

     
     
  • 6.18, grec (?), 22:20, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Очень все раздуто. Главное много, что бы солидно?
     
     
  • 7.19, Аноним (-), 22:26, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Очень все раздуто. Главное много, что бы солидно?

    Зависит от масштабов. И кстати да, на десятке виртуалок с 1 физикой методология DevOps профита не принесёт, а вот если их сотни и тысячи...

     
     
  • 8.36, Имячко (?), 16:53, 12/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Отчего же не принесет На микросервисной архитектуре для CI CD очень даже принес... текст свёрнут, показать
     
  • 6.23, Crazy Alex (ok), 00:30, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Так, меня с тигарами-иденами путать не надо :-) Другое дело, что я вообще не любитель каких-либо облаков, а на десктопе чем теснее софт интегрирован - тем он удобнее.

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

    А вот насчёт микросервисов и особенно DevOps я и спрашивал - что это, чёрт возьми, за штуки, и что в них крутого? А то общих слов веде валом, а чтобы толком описали - не видно.

     
     
  • 7.25, Аноним (-), 09:13, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    - Хорошо, не буду.
    - Суть микросервисов - на каждый сервис отдельная виртуалка/контейнер дают возможность отдельно их обслуживать/развёртывать/масштабировать
    - Концепции DevOps - быстрое развёртывание огромного парка приложений, автоматизация всего, написание рецептов по одному разу на одно приложение(Берём готовый puppet-рецепт для nginx, передаём файлы с сертификатами, параметры конфигов). К чему лично я стремлюсь - Infrastructure as a code. Админскую работу девопс делает 1 раз для 1 сервиса, при написании puppet/chef рецепта или ansible playbook, а потом этот же рецепт вращает и в облаке, и на вагрантах разработчика(в минимальном масштабе), чтобы разраб получил почти такую же инфраструктуру, с такими же настройками.

    Пример: работая с виртуалками в облаке можно рецепты и конфиги хранить в гите. Этого хватит на поднятие пустой инфраструктуры одним махом. В знакомой конторе вечером по крону уничтожается весь dev-environment, а утром поднимается из шеф-рецептов. Так достигли экономии машинного времени на амазоне, но это побочный эффект, а главный - это воспроизводимость среды.


     
     
  • 8.27, Crazy Alex (ok), 10:37, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, ясно Звучит разумно, вот кто бы раньше это так внятно сформулировал Спаси... текст свёрнут, показать
     
     
  • 9.30, Crazy Alex (ok), 13:21, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Только идее одна виртуалка - один сервис сто лет в обед - ... текст свёрнут, показать
     
     
  • 10.34, Аноним (-), 11:21, 01/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Контейнеры кстати тоже, а чрут ещё раньше Вот только раскрутили эту тему пару л... текст свёрнут, показать
     
  • 7.26, Аноним (-), 09:27, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    - И ещё, по интеграции на десктопе. Именно за это любят варган. Какой-нибудь Dev environment можно склонировать с гита, сказать vagrant up и получить всё в настроеном виде.
    - Универсальность как раз только повышается при любом способе виртуализации любого сервиса.
    - У докера пока есть проблемы изоляции это лихородочно фиксят. Здесь аппаратная виртуализация лучше, тот же kvm. Но что подкупило сообщество - это простота сборки образа и экономия места за счёт слоёв http://odewahn.github.io/docker-jumpstart/building-images-with-dockerfiles.ht


     
     
  • 8.28, Crazy Alex (ok), 10:46, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Универсальность - я имел в виду, что контейнеры - это linux on linux Ну а насчё... текст свёрнут, показать
     
     
  • 9.29, Аноним (-), 11:42, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    - А вконтейнерах на десктопе можно всякую блобню запускать, типа хромого и скупо... текст свёрнут, показать
     
     
  • 10.31, Crazy Alex (ok), 13:29, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Собственно, меня и смущает, что контейнеры на десктопе создают иллюзию, что можн... текст свёрнут, показать
     
     
  • 11.32, Аноним (-), 13:49, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    - С контейнерами на десктопе - ситуация очень двойственная И согласен и нет Пр... текст свёрнут, показать
     
  • 7.37, Имячко (?), 17:03, 12/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Так, меня с тигарами-иденами путать не надо :-) Другое дело, что я
    > вообще не любитель каких-либо облаков, а на десктопе чем теснее софт
    > интегрирован - тем он удобнее.

    Тесная интеграция это хорошо, но начиная с определенной сложности ПО, это уже плохо для развития системы.

    Поэтому мы начинаем ПО разбивать на части. Для серверов - это легко.

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

    Очень большая экономия ресурсов.

    В типичном среднем микросервисном приложении 30-100 отдельных видов сервисов, каждый из которых может запускаться по необходимости в нескольких экземплярах. Это ж сколько виртуалок было бы!!! Огромный оверхед.

    Изоляция/универсальность у Докера довольно высокая.

    Ограничения - только Linux, зомби (которые чистятся так же как и ненужные переменные в GC - GC выходит на уровень группы серверов!!!)

    > А вот насчёт микросервисов и особенно DevOps я и спрашивал - что
    > это, чёрт возьми, за штуки, и что в них крутого?

    Слишком тесная интеграция - разработку усложняет.

    Здесь акцент на том, что сначала для удобства/гибкости разработки мы разбили все на части - микросервисы.

    А когда у нас возникло 100 сервисов, которые могут на 10-10000 серверах запускаться - возникли проблемы, - а как этим всем рулить.

     
  • 4.35, Аноним (-), 11:33, 02/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Лучше бы код писали, чем страдать фигней
     
     
  • 5.38, Имячко (?), 17:04, 12/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Лучше бы код писали, чем страдать фигней

    Развиваться тоже надо.
    Не только кодите - еще и изучайте новшества!!!

     

  • 1.4, Аноним (-), 02:12, 29/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Да раньше было удобно юзать вагрант но потом это стало жутко не удобно, да и смысла не много в полуготовых окружениях когда либо собираешь себе готовое либо юзаешь докер. С этой хренью да может быть будет удобно нужно потыкать
     
     
  • 2.7, Michael Shigorin (ok), 12:27, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Да раньше было удобно юзать вагрант но потом это стало жутко не
    > удобно, да и смысла не много в полуготовых окружениях когда либо
    > собираешь себе готовое либо юзаешь докер.

    А что с ними дальше делаете?  Мне-то интересно в контексте http://altlinux.org/m-p (оно умеет и чруты выпекать, и в первом приближении -- образы vm, помимо всего прочего).

    Про vagrant интересовались как-то в плане прикручивания сборки .box'ов:
    https://lists.altlinux.org/pipermail/devel-distro/2012-November/001147.html
    https://lists.altlinux.org/pipermail/devel-distro/2012-November/001062.html
    ...и даже был набросок, но дальше не пошёл.

     
     
  • 3.8, Аноним (-), 13:20, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Варган, конечно очень удобен, как управляющая инфраструктура, даже сам на него перешёл с kvm(делал vagrant+vbox environments для всяких яблосексуалистов и прочих вантузятнегов, у которых ни квм-а, ни линух-чрута нет). Чруты, притом ограниченые, выпекал раньше, с помощью mkjailenv, в генте.

    Для себя - надо подыскать/наделать недостающих боксов на kvm, чтобы спрыгнуть с виртуалбоха, оставаясь на варгане.

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

     
     
  • 4.9, Michael Shigorin (ok), 13:42, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо.  Хотя вместо творческой транслитерации неплохо бы в подобных случаях использовать исходные названия, шоб можно было найти. :)
     
     
  • 5.10, Аноним (-), 14:18, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    http://kubernetes.io/
    Главное здесь - это объединение ресурсов кластера. Отсюда вытекают и проблемы с сетью, с соответствующим решением(вангую путь openstack, от плоской сети до ovs+VLAN/VxLAN. То, что делают уже и во flannel). Есть ещё много интересных и похожих продуктов, типа flocker.

    Если же речь идёт о локалхосте - то docker/lxc/rocket/chroot - хватит всем. Возможно даже openvz.

     
  • 4.21, Аноним (-), 22:32, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Да полностью с вами согласен вагрант для win и osx. Хотя мне он уже без надобности, несмотря на то что сижу на OSX.

     
     
  • 5.24, Аноним (-), 08:56, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А мне удобен именно на линуксе. К нему деплой среды прикручивать удобно(глубоко вызывается ansible/puppet/chef), так чтобы "vagrant up" и минимально работающий кластер из 2-3 машин получить.

    Но в основном - то что вы написали.

     
  • 3.20, Аноним (-), 22:29, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >А что с ними дальше делаете?  Мне-то интересно в контексте http://altlinux.org/m-p (оно умеет и чруты выпекать, и в первом приближении -- образы vm, помимо всего прочего).

    Ну я разрабатывал веб приложения и тестировал на целевой платформе, (OSX не шибко целевая для веба), а потом пересел на Linux ну, а с qvm весь смысл вагранта испарился, да и если посудить вагрант только вначале был нужен до прихода докера. Думаю вам вагрант не нужен, он собственно сейчас вообще не нужен.

     
     
  • 4.33, Аноним (-), 13:52, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Кстати, как вам virt-install? Меня интересует с точки зрения быстрого поднятия квм-виртуалок.
     
  • 4.39, Имячко (?), 17:08, 12/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >>А что с ними дальше делаете?  Мне-то интересно в контексте http://altlinux.org/m-p (оно умеет и чруты выпекать, и в первом приближении -- образы vm, помимо всего прочего).
    > Ну я разрабатывал веб приложения и тестировал на целевой платформе, (OSX не
    > шибко целевая для веба), а потом пересел на Linux ну, а
    > с qvm весь смысл вагранта испарился, да и если посудить вагрант
    > только вначале был нужен до прихода докера. Думаю вам вагрант не
    > нужен, он собственно сейчас вообще не нужен.

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

    Мило дело.
    git clone какую-то хрень
    cd в какую-то хрень
    vagrant up

    И вот ты уже используешь любую хрень с самой нетривиальной настройкой/требованиями к ОСи.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру