Ну, Амазон самые лучшие, однозначно — заказываю 1 карту памяти — получаю упаковку из 10. Такая же ботва с защитными пленками :) То ли везучий, то ли они с такими темпами ошибок скоро обанкротятся :)
С Праймом была беда — не уложились в 2 дня, тыщи аполоджайзов, вот вам в подарок подписка на месяц+.
Приятные ребята.
Да тезка, врапперы это наше все, учитывая, что есть возможность пользовать chef-rewind + аттрибуты. И да, редко что-то кардинально случается в community-cookbook, так что рисков мало.
Хорошо, когда есть команда DevOps и время, чтобы выверить update, пусть даже поверхностно. А езе лучше — есть отлаженный механизм тестирования кукбуков — всякие kitchen, rspec и пр.
А вообще, если верить Chef, то их скоро доступный Chef Delivery может оказаться хорошим соратником в создании полноценного flow из нативных Chef-у инструментов. И не нужно особо ничего выдумывать.
высокий уровень жизни, и при этом – расходы на жилье, образование и культурные мероприятия ниже, чем в большинстве стран Западной и Восточной Европы.
В свете растущих цен в Беларуси — скоро этого фактора не будет. Германия спокойно поспорит в свете цен на жилье и культурные мероприятия (особенно если пересчитывать в соотношении с ЗП). При этом Германия является куда более популярным технологическим хабом Европы, особенно в свете оживления старт-ап сцены в Берлине.
Достаточно спорные преимущества, одним словом.
Ну и overall — статья уж совсем PR направления, уж простите, не-Хабр стиль, совсем…
Не посылаем. Мердж — рисковое дело. Есть пару аспектов:
— комьюнити кукбук меняется, но без критических правок, тогда можно было бы рискнуть;
— скелет кукбука меняется — надо руками мерджить это дело либо оставать на старом варианте.
Из практики — мы замораживаем все версии кукбуков, по возможности. Смысл в обновлении кукбука есть только если:
— что-то не работает и это нельзя пофиксить (редкое дело, мне кажется);
— вышло обновление, приносящие необходимые нам фичи (ну тож сомнительно).
Мерджить можно, использовать потом TestKitchen, прогонять тесты (спеки и пр.) — и принимать решение годный ли мердж.
В нашем варианте — обновление можно и руками сделать, не частый это процесс.
Но вариант с тестированием — тоже хорош, кошерен.
Как-то так, надеюсь смог ответить развернуто. Пишите, ежели что.
Согласен, но опять же — речь тут шла о том, что все stays in cloud. Да и о методах DR, для которых писалось сие — не спорят. У каждого свои ресурсы. On-premises HDD — не был вариантом.
О простоте решения никто не говорит, снапшот — проще всего. Может у вас не проблема, но отдать 18-20 гб. под хранение бэкапов не самое разумное решение. 2 гб. — уже другой разговор.
Элементарно — конкретно в нашем клауде — она деплоится быстрее всего, т.к. ее чаще всего используют другие тимы. + большинство комьюнити наработок показывают себя хорошо оптимизированными под бубунту.
Ровно одно — команда загрузить шаблон для стека. В нем все описано. Что там и как работает — не касается конечного пользователя.
Кому понадобился HaaS — не важно, наше дело — реализовать :) Ну и заодно обкатать новые для себя технологии.
Много. Расскажу вкратце как.
Есть кукбук, в нем рецепты, соответствующие частям кластера.
Есть Chef роли. Запускаем (через template) наши виртуалки, назначаем роли, соблюдаем последовательность и тайминги при запуске — получаем кластер.
Как настроить или внести изменение? Все параметры (хочется верить что все) из файлов core-site, hdfs-site, etc. — вынесены в атрибуты кукбука (их там порядка тыщи, чтоб не соврать), то есть доступны нам для назначения.
Если я хочу изменить, к примеру, defaultFS — я устанавливаю атрибут node['hadoop_cluster']['core_site']['defaultFS'] и при следующем запуске Chef-клиента — ВУАЛЯ, он попадает на место.
Ambari? Включен, как вариант. Но опять же — есть свои особенности, связанные с приватным облаком, согласно которых попросили сделать это исключительно на Chef. Ставить при помощи Chef — Ambari и руководить ним — не оч хорошо. А так — имеем решение, при котором запуск стека приводит к развертыванию кластера. С 1 нажатия кнопочки :)
1. Ага, забыл уточнить, это чисто для приватных/внутренних дел :) Для девелоперов, которым нужно иногда. Да и учитывая легкость поднятия кластера через template для клауда — не проблема, даже если внезапно умрет. Естественно реальные аналитические задачи никто туда кидать не будет.
2. А у нас кросплатформенное решение, так что Убунту не показатель. Просто для примера выбрано, как самая популярная ОС в нашем клауде.
3. А вот это уже интересная интеграция, есть над чем подумать. На самом деле, этот таск из self-education только начинает превращаться в боевое задание, так что — спасибо, попробуем!
База порядка 3 гб, если я не ошибаюсь. Времени — я не дождался, ибо производилось это все на AWS инстансе, не самом шустром. Сомневаюсь, что быстрее, чем упаковка (порядка 30 мин.)
С Праймом была беда — не уложились в 2 дня, тыщи аполоджайзов, вот вам в подарок подписка на месяц+.
Приятные ребята.
при попытке docker-compose up.
Дебаг не помогает.
yml файл простой:
Docker 1.7.1, Compose 1.3.3. Гугл не особо помогает, как и багтрекер Compose.
Help :)
Хорошо, когда есть команда DevOps и время, чтобы выверить update, пусть даже поверхностно. А езе лучше — есть отлаженный механизм тестирования кукбуков — всякие kitchen, rspec и пр.
А вообще, если верить Chef, то их скоро доступный Chef Delivery может оказаться хорошим соратником в создании полноценного flow из нативных Chef-у инструментов. И не нужно особо ничего выдумывать.
В свете растущих цен в Беларуси — скоро этого фактора не будет. Германия спокойно поспорит в свете цен на жилье и культурные мероприятия (особенно если пересчитывать в соотношении с ЗП). При этом Германия является куда более популярным технологическим хабом Европы, особенно в свете оживления старт-ап сцены в Берлине.
Достаточно спорные преимущества, одним словом.
Ну и overall — статья уж совсем PR направления, уж простите, не-Хабр стиль, совсем…
— комьюнити кукбук меняется, но без критических правок, тогда можно было бы рискнуть;
— скелет кукбука меняется — надо руками мерджить это дело либо оставать на старом варианте.
Из практики — мы замораживаем все версии кукбуков, по возможности. Смысл в обновлении кукбука есть только если:
— что-то не работает и это нельзя пофиксить (редкое дело, мне кажется);
— вышло обновление, приносящие необходимые нам фичи (ну тож сомнительно).
Мерджить можно, использовать потом TestKitchen, прогонять тесты (спеки и пр.) — и принимать решение годный ли мердж.
В нашем варианте — обновление можно и руками сделать, не частый это процесс.
Но вариант с тестированием — тоже хорош, кошерен.
Как-то так, надеюсь смог ответить развернуто. Пишите, ежели что.
Добавил, гляну на Sahara, спасибо!
популярные кукбуки практически лишены такого.
Кому понадобился HaaS — не важно, наше дело — реализовать :) Ну и заодно обкатать новые для себя технологии.
Есть кукбук, в нем рецепты, соответствующие частям кластера.
Есть Chef роли. Запускаем (через template) наши виртуалки, назначаем роли, соблюдаем последовательность и тайминги при запуске — получаем кластер.
Как настроить или внести изменение? Все параметры (хочется верить что все) из файлов core-site, hdfs-site, etc. — вынесены в атрибуты кукбука (их там порядка тыщи, чтоб не соврать), то есть доступны нам для назначения.
Если я хочу изменить, к примеру, defaultFS — я устанавливаю атрибут node['hadoop_cluster']['core_site']['defaultFS'] и при следующем запуске Chef-клиента — ВУАЛЯ, он попадает на место.
2. А у нас кросплатформенное решение, так что Убунту не показатель. Просто для примера выбрано, как самая популярная ОС в нашем клауде.
3. А вот это уже интересная интеграция, есть над чем подумать. На самом деле, этот таск из self-education только начинает превращаться в боевое задание, так что — спасибо, попробуем!