Компания HashiCorp, известная разработкой системы Vagrant (http://vagrantup.com/), представила (https://www.hashicorp.com/blog/otto.html) проект Otto (https://ottoproject.io/), в рамках которого разработан новый инструментарий для создания и развёртывания приложений, упакованных в изолированные контейнеры или образы для различных облачных окружений. Otto продвигает концепцию микросервисов, включающих определённую программу и необходимые для её работы зависимости. При этом микросервисы для привязаны к конкретной технологии изоляции и могут быть сформированы для различных систем. Код проекта написан на языке Go (Vagrant написан на Ruby) и распространяется (https://github.com/hashicorp/otto) под лицензией MPL 2.0 (Mozilla Public License).
Otto позиционируется как продолжение развития Vagrant, учитывающее накопленный при создании данного проекта опыт и расширяющее возможности средствами развёртывания и интеграции с циклом разработки ПО. При этом Vagrant не прекращает своё существование и будет поддерживаться и улучшаться в обозримом будущем. Ставя перед Otto более широкие задачи разработчики решили не изобретать колесо и использовали в новом проекте уже проверенные и зарекомендовавшие технологии Vagrant при создании системы автоматического управления окружением разработчика. Со временем Otto заменит собой Vagrant, но это произойдёт не сразу и пока оба проекта будут сосуществовать.Otto предоставляет (https://ottoproject.io/intro) инструменты для автоматической сборки самодостаточного окружения, необходимого для работы разрабатываемого приложения, и развёртывания этого окружения в типовых системах виртуализации и контейнерной изоляции. На основании типа приложения Otto автоматически подбирает зависимости, например, для PHP-программ он загрузит, установит и настроит в окружении PHP и связанные с ним средства разработчика. Если приложение зависит от внешних сервисов, таких как СУБД, Otto самостоятельно определит это и установит в окружении нужные версии данных сервисов, а также необходимые для этих сервисов зависимости. Поддерживается интеграция с Docker, который может вызываться для загрузки и запуска подготовленных в Otto микросервисов.
Базовая конфигурация приложения задаётся в форме Appfile. Например, для приложения на языке Ruby 2.1, хранящем данные в СУБД PostgreSQL, Appfile может выглядеть следующим образом:
<font color="#461b7e">
application {
name = "my-app"
type = "ruby"dependency {
source = "github.com/hashicorp/otto/examples/postgresql"
}
}customization "ruby" {
ruby_version = "2.1"
}
</font>
Параметры запуска окружения и лимиты выбираются в соответствии с типовыми требованиями для указанных зависимостей. Конфигурация может быть подобрана (https://ottoproject.io/intro/getting-started/dev.html) автоматически при помощи выполнения команды "otto compile" в директории с кодом приложения. Создать локальное окружение для тестирования и разработки можно командой "otto dev". Для создания инфраструктуры для эксплуатации этого окружения (например, в Amazon Web Services) достаточно выполнить (https://ottoproject.io/intro/getting-started/infra.html) команду "otto infra". Для подготовки (https://ottoproject.io/intro/getting-started/build.html) образа с приложением для запуска в созданной инфраструктуре следует выполнить команду "otto build". Для запуска (https://ottoproject.io/intro/getting-started/deploy.html) окружения в созданной инфраструктуре нужно выполнить команду "otto deploy". Таким образом разработчику не нужно заботиться о выборе систем изоляции и подбирать зависимости, Otto всё сделает самостоятельно с использованием наиболее хорошо зарекомендовавших себя методов, подходящих для текущих условий.Одновременно с Otto представлена (https://www.hashicorp.com/blog/nomad.html) платформа Nomad, предназначенная для управления кластером серверов и запуска окружений с приложениями в данном кластере. Nomad (https://www.nomadproject.io/) абстрагируется от отдельных серверов и местоположения приложений, предлагая пользователю лишь определить что он хочет запустить, а вопрос где и как будет запущено окружение берёт на себя. Для выполнения окружений может быть использован Docker, но Nomad не ограничивается им и позволяет использовать драйверы для запуска с использованием иных платформ контейнерной изоляции или виртуализации для Linux, Windows, BSD и OS X. Для упрощения работы клиентская и серверная части объединены в один исполняемый файл.
URL: https://www.hashicorp.com/blog/otto.html
Новость: http://www.opennet.me/opennews/art.shtml?num=43055
А есть примеры, где удобно применять?
> ruby
> смузи
> митапыНу может и найдёшь пару весьма специфических use-cases на всю отрасль.
Понимаете ли, отрасль растёт горизонтально. И рубероиды и Go-пники, пьющие смузи на очередном митапе сообразили как это сделать. Конечно же, ретарды, пьющие пиво их возненавидят, и будут голосом тигара и унимана вещать про дэбиллoв и и_дидов. Приятно на это смотреть.По юзкейсам на моих работах:
- Много машин, нужна аппаратная виртуализация
- Много машин, и уже никак без виртуалбох/хипстер-в. Хочу квм
- kvm, xen, lxc. Самодельные чруты - сеть? Разносим по портам. Прихожу к самоизобретённой парадигме, напоминающей DevOps
- kvm, openvz, virsh, proxmox, virt-manager. Cтал девопсом, нравится опенстек, хочу.
- openstack, vagrant, docker.
- openstack, vagrant, docker. Контейнеры рулят. Аппаратная виртуализация не особо нужна. Слишком мало докера, хотя он уже не настолько сырой, работает даже....
- docker, kubernetes и не только... А вот теперь всё это причёсываем.
И так будет бесконечно и все погрязнет в вечном дебаге.
Подтверждаю, не вечно, но иногда бывает.
Если б кто-нибудь внятно описал, зачем всё это надо - ретарды, пьющие пиво, ненавидели бы меньше. Но пока внятных описаний "зачем оно и как именно оно приносит/экономит деньги" не попадалось, особенно про DevOps.Аппаратная виртуализация - понятно зачем. Контейнеры - уже нет.
про системное окружение почитай
> Аппаратная виртуализация - понятно зачем. Контейнеры - уже нет.Если неясно зачем контейнеры и почему они могут быть предпочтительнее, чем виртуализация, может быть стоит поработать где-то ещё кроме хостинга.
Да я вообще от каких-либо серверов уже лет несколько, как далёк. Десктопы, мобилы, эмбед...
Я ничего не имею против того, чтобы меня ненавидели ретарды.Для табя, и прочих тигаро-изено-юниманов:
- Самые лучшие реализации гипервизоров, такие как kvm, дают минимум 15% оверхеда. Остальные, же - намного хуже.
- Концепция микросервисов
- Виртуализируем в основном пингвина на пингвине. А может лучше контейнер?
- Cgroups сегодня нарезает ресурсы даже получше, чем отдельные ВМ.
- Оверхед контейнера незаметен.
- Докер выстрелил в основном не благодаря технологичности и крутой изоляции, которой пока нет, а благодаря управляторам-консолидаторам вокруг него.Понимание философии DevOps приходит при увеличении масштабов информационной системы до такого уровня, когда 1 человек уже не справляется. Мой пример - 300 физик, более 1000 виртуалок, 4 девопса. Несколько тысяч виртуалок на амазоне - 2,5девопса+0,5админа - это у знакомых.
Экономия денег - возможность горизонтального роста инфраструктуры.
Очень все раздуто. Главное много, что бы солидно?
> Очень все раздуто. Главное много, что бы солидно?Зависит от масштабов. И кстати да, на десятке виртуалок с 1 физикой методология DevOps профита не принесёт, а вот если их сотни и тысячи...
Отчего же не принесет.
На микросервисной архитектуре для CI/CD очень даже принесет....
Так, меня с тигарами-иденами путать не надо :-) Другое дело, что я вообще не любитель каких-либо облаков, а на десктопе чем теснее софт интегрирован - тем он удобнее.Из того, что вы написали выходит, что основное - экономия ресурсов в обмен на потерю хорошей изоляции и универсальности.
А вот насчёт микросервисов и особенно DevOps я и спрашивал - что это, чёрт возьми, за штуки, и что в них крутого? А то общих слов веде валом, а чтобы толком описали - не видно.
- Хорошо, не буду.
- Суть микросервисов - на каждый сервис отдельная виртуалка/контейнер дают возможность отдельно их обслуживать/развёртывать/масштабировать
- Концепции DevOps - быстрое развёртывание огромного парка приложений, автоматизация всего, написание рецептов по одному разу на одно приложение(Берём готовый puppet-рецепт для nginx, передаём файлы с сертификатами, параметры конфигов). К чему лично я стремлюсь - Infrastructure as a code. Админскую работу девопс делает 1 раз для 1 сервиса, при написании puppet/chef рецепта или ansible playbook, а потом этот же рецепт вращает и в облаке, и на вагрантах разработчика(в минимальном масштабе), чтобы разраб получил почти такую же инфраструктуру, с такими же настройками.Пример: работая с виртуалками в облаке можно рецепты и конфиги хранить в гите. Этого хватит на поднятие пустой инфраструктуры одним махом. В знакомой конторе вечером по крону уничтожается весь dev-environment, а утром поднимается из шеф-рецептов. Так достигли экономии машинного времени на амазоне, но это побочный эффект, а главный - это воспроизводимость среды.
Ага, ясно. Звучит разумно, вот кто бы раньше это так внятно сформулировал. Спасибо.
Только идее "одна виртуалка - один сервис" сто лет в обед ;-)
Контейнеры кстати тоже, а чрут ещё раньше. Вот только раскрутили эту тему пару лет назад.
- И ещё, по интеграции на десктопе. Именно за это любят варган. Какой-нибудь Dev environment можно склонировать с гита, сказать vagrant up и получить всё в настроеном виде.
- Универсальность как раз только повышается при любом способе виртуализации любого сервиса.
- У докера пока есть проблемы изоляции это лихородочно фиксят. Здесь аппаратная виртуализация лучше, тот же kvm. Но что подкупило сообщество - это простота сборки образа и экономия места за счёт слоёв http://odewahn.github.io/docker-jumpstart/building-images-wi...
Универсальность - я имел в виду, что контейнеры - это linux on linux. Ну а насчёт безопасности - сорри, но не верю, что в обозримом будущем контейнер не сможет, начудив, утянуть за собой хост хотя бы в Denial Of Service.А про десктоп - я имел в виду, что там контейнеры - зло для power user'а. Потому что часто удобно из одного приложения влезть в конфиги или рабочие файлы другого, например. Ну там - "а вот выгребем по крону закладки браузера из определённой папки, загрузим страницы, спроцессим все новые результаты сохраним". Что проще всего делается прямым залезанием в sqlite файрфокса. А кгда все приложения в контейнеры раскладывают - подобное творить затруднительно.
- А вконтейнерах на десктопе можно всякую блобню запускать, типа хромого и скупого.
- Да, я тоже не сторонник такое делать с нормальными приложениями.
- Да, контейнеры никогда не доберутся по безопасности до ВМ. Одно ядро всё-же. Но что касается обычного ддоса, то дисковое и сетевое I/O уже сегодня в докере и lxc нарезается лучше, чем в ВМ.
Собственно, меня и смущает, что контейнеры на десктопе создают иллюзию, что можно безнаказанно блобню запускать, да ещё обычно и мимо пакетного менеджера и с установкой без прав рута. В результате появляются всякие "гномомагазины", да и вообще - это прямая дорожка к виндовому бардаку,Насчёт лучшей нарезки IO - удивлён, мягко говоря. Но наверняка что-то ещё выстрелит. Ну вот, например, само I/O - ладно, а память для файлового кэша же общая?
- С контейнерами на десктопе - ситуация очень двойственная. И согласен и нет. Просто некоторая дрянь таки напрашивается на контейнер. Мне нужны обе возможности.
- Обвалить хост контейнер может, хоть у меня это давно не происходило. С общей памятью файлового кеша - тоже.
> Так, меня с тигарами-иденами путать не надо :-) Другое дело, что я
> вообще не любитель каких-либо облаков, а на десктопе чем теснее софт
> интегрирован - тем он удобнее.Тесная интеграция это хорошо, но начиная с определенной сложности ПО, это уже плохо для развития системы.
Поэтому мы начинаем ПО разбивать на части. Для серверов - это легко.
> Из того, что вы написали выходит, что основное - экономия ресурсов в
> обмен на потерю хорошей изоляции и универсальности.Очень большая экономия ресурсов.
В типичном среднем микросервисном приложении 30-100 отдельных видов сервисов, каждый из которых может запускаться по необходимости в нескольких экземплярах. Это ж сколько виртуалок было бы!!! Огромный оверхед.
Изоляция/универсальность у Докера довольно высокая.
Ограничения - только Linux, зомби (которые чистятся так же как и ненужные переменные в GC - GC выходит на уровень группы серверов!!!)
> А вот насчёт микросервисов и особенно DevOps я и спрашивал - что
> это, чёрт возьми, за штуки, и что в них крутого?Слишком тесная интеграция - разработку усложняет.
Здесь акцент на том, что сначала для удобства/гибкости разработки мы разбили все на части - микросервисы.
А когда у нас возникло 100 сервисов, которые могут на 10-10000 серверах запускаться - возникли проблемы, - а как этим всем рулить.
Лучше бы код писали, чем страдать фигней
> Лучше бы код писали, чем страдать фигнейРазвиваться тоже надо.
Не только кодите - еще и изучайте новшества!!!
Да раньше было удобно юзать вагрант но потом это стало жутко не удобно, да и смысла не много в полуготовых окружениях когда либо собираешь себе готовое либо юзаешь докер. С этой хренью да может быть будет удобно нужно потыкать
> Да раньше было удобно юзать вагрант но потом это стало жутко не
> удобно, да и смысла не много в полуготовых окружениях когда либо
> собираешь себе готовое либо юзаешь докер.А что с ними дальше делаете? Мне-то интересно в контексте http://altlinux.org/m-p (оно умеет и чруты выпекать, и в первом приближении -- образы vm, помимо всего прочего).
Про vagrant интересовались как-то в плане прикручивания сборки .box'ов:
https://lists.altlinux.org/pipermail/devel-distro/2012-Novem...
https://lists.altlinux.org/pipermail/devel-distro/2012-Novem...
...и даже был набросок, но дальше не пошёл.
Варган, конечно очень удобен, как управляющая инфраструктура, даже сам на него перешёл с kvm(делал vagrant+vbox environments для всяких яблосексуалистов и прочих вантузятнегов, у которых ни квм-а, ни линух-чрута нет). Чруты, притом ограниченые, выпекал раньше, с помощью mkjailenv, в генте.Для себя - надо подыскать/наделать недостающих боксов на kvm, чтобы спрыгнуть с виртуалбоха, оставаясь на варгане.
А чруты, по крайней мере для меня, уже давно заменились на доскер, иногда под кубернетесом. Мезос - не осилил, ибо кубернетес+фланнель+openvswitch лучше работают с сетью.
Спасибо. Хотя вместо творческой транслитерации неплохо бы в подобных случаях использовать исходные названия, шоб можно было найти. :)
http://kubernetes.io/
Главное здесь - это объединение ресурсов кластера. Отсюда вытекают и проблемы с сетью, с соответствующим решением(вангую путь openstack, от плоской сети до ovs+VLAN/VxLAN. То, что делают уже и во flannel). Есть ещё много интересных и похожих продуктов, типа flocker.Если же речь идёт о локалхосте - то docker/lxc/rocket/chroot - хватит всем. Возможно даже openvz.
Да полностью с вами согласен вагрант для win и osx. Хотя мне он уже без надобности, несмотря на то что сижу на OSX.
А мне удобен именно на линуксе. К нему деплой среды прикручивать удобно(глубоко вызывается ansible/puppet/chef), так чтобы "vagrant up" и минимально работающий кластер из 2-3 машин получить.Но в основном - то что вы написали.
>А что с ними дальше делаете? Мне-то интересно в контексте http://altlinux.org/m-p (оно умеет и чруты выпекать, и в первом приближении -- образы vm, помимо всего прочего).Ну я разрабатывал веб приложения и тестировал на целевой платформе, (OSX не шибко целевая для веба), а потом пересел на Linux ну, а с qvm весь смысл вагранта испарился, да и если посудить вагрант только вначале был нужен до прихода докера. Думаю вам вагрант не нужен, он собственно сейчас вообще не нужен.
Кстати, как вам virt-install? Меня интересует с точки зрения быстрого поднятия квм-виртуалок.
>>А что с ними дальше делаете? Мне-то интересно в контексте http://altlinux.org/m-p (оно умеет и чруты выпекать, и в первом приближении -- образы vm, помимо всего прочего).
> Ну я разрабатывал веб приложения и тестировал на целевой платформе, (OSX не
> шибко целевая для веба), а потом пересел на Linux ну, а
> с qvm весь смысл вагранта испарился, да и если посудить вагрант
> только вначале был нужен до прихода докера. Думаю вам вагрант не
> нужен, он собственно сейчас вообще не нужен.Для продакшена он и был не нужен, даже вреден.
Для использования на машинах разработчиков - сейчас само то.Мило дело.
git clone какую-то хрень
cd в какую-то хрень
vagrant upИ вот ты уже используешь любую хрень с самой нетривиальной настройкой/требованиями к ОСи.