Я так делал 2 (3, 5, 7) лет назад и по-другому не буду. Нафиг мне это всё нужно.
Профилировщики/Сонары/Анализаторы — это мне не нужно, я и так знаю, что я пишу
От опытного (10+ лет) ресурс/проджект менджера/тех. лида: программист не должен знать/уметь работать с системами контроля версий, он должен уметь писать код. Кнопку нажал и готово. Зачем тратить время на изучение этих систем, только база: как сделать commit/push/branch
Как следствие предыдущего пункта: git. Я уже всё запушил, а потом закоммитал, забирайте.
Никак не могу переубедить, заставить что-то выучить.
Увидели статью про multi cursors — «это хрень какая-то. На нашем проекте нельзя, запретить! А то ща что-нибудь наделают. Я бы такому девелоперу… бла бла бла...»
Тут вы по сути описали волшебную кнопку, которую надо нажать. А речь шла скорее про то, на сколько тяжело эту самую кнопку сделать. с таким же успехом я бы мог ответить на свой вопрос так:
Лично пока с puppet не работал, но мой друг столкнулся с проблемой организации циклов, которые DSL не поддерживает (во всяком случае я такое от него услышал год назад). И ему пришлось сильно постараться.
Всё-таки puppet основан на DSL, который явно ограничен по сравнению с plain ruby. А сам по себе язык ruby имеет довольно приятный синтаксис.
Но, давайте не будем сравнивать тёплое с мягким, а остановимся на более конкретных вещах.
В последнее время, что в сообществе Chef, что в Puppet (да и других) очень часто тиражируют бесполезные «красивые» примеры применения в стиле «как поставить apache + wordpress» или «добавить юзера в mysql».
Очень не хватает реальных задач, который имеют свои особенности и не являются такими тривиальными. Вот тут-то и начинается самое интересное.
Вот, например, какую мне пришлось решить:
Установить и настроить mongodb cluster с возможностью объединения нод в реплики (replicaset) и добавлением этих реплик или просто нод как shard в общий кластер. При этом нужно уметь:
* держать на одном сервере несколько демонов: config db, mongo router и какой-нибудь mongod инстанс; или MongoDB Arbiter для ReplicaSet1 вместе с Mongod для ReplicaSet2
* Добавлять на лету ноды в реплику, реплики/шарды в кластер
* Иметь возможность дополнительно настраивать реплики (rs.conf())
Вот такая вот интересная задачка. Можно подумать как её решить с использованием Chef, а как с использованием Puppet.
Как только задачи перестаёт быть сферической в вакууме, сразу станет понятнее, что лучше использовать.
В интернете можно найти несколько cookbooks для MongoDB, но есть впечатление, что авторы не читали документацию вообще. И сколько бы там всего заявлено не было, хорошо, если этот cookbook сможет поднять примитивный кластер или реплику.
Поэтому сначала это и делается на dev (тоесть локальной машине)
Не всегда можно воспроизвести всё на локальной машине. Более того, может быть чёткое требование: на PROD1 делай так, а на PROD2 по-другому.
А так, да — сам пытаюсь всё локально проверять и тестить перед отправкой. И все версии зафиксированы строго. Сначала думал, что будет очень тяжело поддерживать все версии. На практике оказалось это очень редкое занятие и отнимает буквально пару минут. Зато не раз спало в сложных ситуациях.
Вот ещё никак руки не дойдут потыкать палочкой vagrant-lxc для поднятия более сложных вещей с меньшими ресурсами…
Не соглашусь с вами. Точнее даже не так: у вас конкретный подход, когда chef-client выключен.
Тогда всё просто: речь идёт о явном запуске и переконфигурации. В большинстве случаев chef-client постоянно крутится на сервере и следит за состоянием серверов. Особенно в клауде.
Добавились 3-4 бэканда — балансер уже «знает» об этом и перенастраивается (без явного вызова chef-client). Именно в таких случаях опасно менять глобальные роли/рецепты и т.д.
Если у вас по 10 серверов на окружение и вы толкнули роль, вероятно, через 3-5 минут 2-3 сервера уже будут перенастроены. Подход выше позволяет контролировать этот процесс и тестировать сначала на отдельных окружениях.
Такая же ситуация и с рецептами: обновил cookbook и везде, где его версия строго не была зафиксирована, он обновится (и что-нибудь сломает).
Кстати, в вашем же случае отключение chef-client как демон — не спасение! Это просто надежда, что «вот пока я буду разрабатывать/тетсить/исправлять баг» никто не додумается запустить chef-client на проде.
PS. В примере выше через knife ssh запускалась команда tail, а не chef-client. Сам по себе knife ssh не запускает реконфигурацию.
Тем, кто захочет заняться шефом вплотную могут помочь следующие keywords:
vagrant (упоминалось в статье и именно с него стоит начать), chef-zero, berkshelf, vagrant-berkshelf, vagrant-omnibus.
Сейчас идёт очень хорошая тенденция к универсальности в плане VM провайдеров: для knife есть масса плагинов для интеграции с различными облаками, vagrant так же интегрируется с различными системами виртуализации, облаками и т.д.
Такая навигация была в KDE 3 (konqueror). Вроде бы, была и в 4, но я что-то найти не могу. Возможно выпилили по каким-то причинам. Плюс она же есть в macos. Очень удобно.
git checkout не создаёт ветки. git checkout -b — это всего лишь shortcut на несколько команд.
git push отправляет/обновляет только состояние веток (указатель) в remote. Удаление указателя — это тоже обновление.
git status — (из мана) Displays paths that have differences between the index file and the current HEAD commit. Никто и не говорил, что должны показываться изменения в файлах, только изменённые файлы. И это ожидаемо: «Гит, скажи мне какие файлы поменялись»
git diff — как и ожидается из названия показывает эту самую разницу. «Гит, покажи мне сделанные изменения»
про push/pull и необязательные аргументы вам ответили. Git децентрализованная система, стало быть remotes у вас может быть несколько. Если вы делаете форк на гитхабе, потом локально редактируете, то наверняка захотите добавить upstream репозиторий для подтягивания изменений к себе. указывать явно репозитоий (origin) — это уже хорошая привычка.
hg incoming — честно, не работал с mercurial, но полагаю что речь идёт про git fetch.
Каждый будет хвалить тот инструмент, в котором он лучше разобрался. Это и закономерно, чем лучше разбираешься — тем более успешный опыт, тем круче кажется сам инструмент.
Единственная проблема (проблема ли?) git — он не поощраяет и не прощает работу по принципу «ну я ща начну работать, мне вот срочно надо, а потом как-нибудь выучу». Разберись, а потом пользуйся и радуйся. Кстати, с линуксами то же самое.
ПС. Фраза на проекте была: «я уже всё запушил, а потом закоммитал то, что нужно. Забирайте».
Спасибо, что заметили.
Мысль ушла вперёд и я записал совершенно не то, что хотел сказать.
Срочно исправлю, т.к. это важно и нельзя вводить людей в заблуждение.
Да, статья сыровата. Добавил в скобках пояснение, что имеется ввиду remote.
И выложил всё на github.
К сожалению, нет пока времени переводитьв markdown, поэтому там лежит исходник статьи.
Добавил в конец статьи, но всё же считаю более важным новичкам сразу объяснить как устроен git — это не займёт много времени, но сразу даст много понимания. Будет ясно почему те или иные вещи делаются именно так, как они делаются.
В течении двух недель по вечерам или когда время было.
Это, конечно, накладывает свой отпечаток — статья слегка сыроватая получилась, надо будет допилить до приличного вида.
Никак не могу переубедить, заставить что-то выучить.
Увидели статью про multi cursors — «это хрень какая-то. На нашем проекте нельзя, запретить! А то ща что-нибудь наделают. Я бы такому девелоперу… бла бла бла...»
Дополню этот вопрос:
Как вы добавите шард в кластер, даже если кол-во нод не будет меняться? Как вы настроите реплику?
Переделанная документация шефа сейчас ОЧЕНЬ качественная.
Огромное уважение разработчикам.
Всё-таки puppet основан на DSL, который явно ограничен по сравнению с plain ruby. А сам по себе язык ruby имеет довольно приятный синтаксис.
Но, давайте не будем сравнивать тёплое с мягким, а остановимся на более конкретных вещах.
В последнее время, что в сообществе Chef, что в Puppet (да и других) очень часто тиражируют бесполезные «красивые» примеры применения в стиле «как поставить apache + wordpress» или «добавить юзера в mysql».
Очень не хватает реальных задач, который имеют свои особенности и не являются такими тривиальными. Вот тут-то и начинается самое интересное.
Вот, например, какую мне пришлось решить:
Установить и настроить mongodb cluster с возможностью объединения нод в реплики (replicaset) и добавлением этих реплик или просто нод как shard в общий кластер. При этом нужно уметь:
* держать на одном сервере несколько демонов: config db, mongo router и какой-нибудь mongod инстанс; или MongoDB Arbiter для ReplicaSet1 вместе с Mongod для ReplicaSet2
* Добавлять на лету ноды в реплику, реплики/шарды в кластер
* Иметь возможность дополнительно настраивать реплики (rs.conf())
Вот такая вот интересная задачка. Можно подумать как её решить с использованием Chef, а как с использованием Puppet.
Как только задачи перестаёт быть сферической в вакууме, сразу станет понятнее, что лучше использовать.
В интернете можно найти несколько cookbooks для MongoDB, но есть впечатление, что авторы не читали документацию вообще. И сколько бы там всего заявлено не было, хорошо, если этот cookbook сможет поднять примитивный кластер или реплику.
Именно это и имел в виду, когда говорил:
Не всегда можно воспроизвести всё на локальной машине. Более того, может быть чёткое требование: на PROD1 делай так, а на PROD2 по-другому.
А так, да — сам пытаюсь всё локально проверять и тестить перед отправкой. И все версии зафиксированы строго. Сначала думал, что будет очень тяжело поддерживать все версии. На практике оказалось это очень редкое занятие и отнимает буквально пару минут. Зато не раз спало в сложных ситуациях.
Вот ещё никак руки не дойдут потыкать палочкой vagrant-lxc для поднятия более сложных вещей с меньшими ресурсами…
Минус: дополнительные расходы на содержание одного сервера.
Плюсы: всё достаточно изолировано, можно ограничивать права разработчиков и не пускать их на прод, оставляя полные права на dev/qa/staging.
Очень хорошо, что вы об этом упомянули.
Тогда всё просто: речь идёт о явном запуске и переконфигурации. В большинстве случаев chef-client постоянно крутится на сервере и следит за состоянием серверов. Особенно в клауде.
Добавились 3-4 бэканда — балансер уже «знает» об этом и перенастраивается (без явного вызова chef-client). Именно в таких случаях опасно менять глобальные роли/рецепты и т.д.
Если у вас по 10 серверов на окружение и вы толкнули роль, вероятно, через 3-5 минут 2-3 сервера уже будут перенастроены. Подход выше позволяет контролировать этот процесс и тестировать сначала на отдельных окружениях.
Такая же ситуация и с рецептами: обновил cookbook и везде, где его версия строго не была зафиксирована, он обновится (и что-нибудь сломает).
Кстати, в вашем же случае отключение chef-client как демон — не спасение! Это просто надежда, что «вот пока я буду разрабатывать/тетсить/исправлять баг» никто не додумается запустить chef-client на проде.
PS. В примере выше через knife ssh запускалась команда tail, а не chef-client. Сам по себе knife ssh не запускает реконфигурацию.
vagrant (упоминалось в статье и именно с него стоит начать), chef-zero, berkshelf, vagrant-berkshelf, vagrant-omnibus.
Сейчас идёт очень хорошая тенденция к универсальности в плане VM провайдеров: для knife есть масса плагинов для интеграции с различными облаками, vagrant так же интегрируется с различными системами виртуализации, облаками и т.д.
Полезное видео (eng): www.youtube.com/watch?v=hYt0E84kYUI
От авторов berkshelf
Если у вас линукс, можно попробовать ещё vagrant-lxc (сам пока не пробовал).
Есть ещё test-kitchen, но он пока сыроват.
Когда сам начал в этом разбираться — знание об этих тулах могло сэкономить мне пару недель.
Изучение и разработка значительно ускоряется.
git push отправляет/обновляет только состояние веток (указатель) в remote. Удаление указателя — это тоже обновление.
git status — (из мана) Displays paths that have differences between the index file and the current HEAD commit. Никто и не говорил, что должны показываться изменения в файлах, только изменённые файлы. И это ожидаемо: «Гит, скажи мне какие файлы поменялись»
git diff — как и ожидается из названия показывает эту самую разницу. «Гит, покажи мне сделанные изменения»
про push/pull и необязательные аргументы вам ответили. Git децентрализованная система, стало быть remotes у вас может быть несколько. Если вы делаете форк на гитхабе, потом локально редактируете, то наверняка захотите добавить upstream репозиторий для подтягивания изменений к себе. указывать явно репозитоий (origin) — это уже хорошая привычка.
hg incoming — честно, не работал с mercurial, но полагаю что речь идёт про git fetch.
Каждый будет хвалить тот инструмент, в котором он лучше разобрался. Это и закономерно, чем лучше разбираешься — тем более успешный опыт, тем круче кажется сам инструмент.
Единственная проблема (проблема ли?) git — он не поощраяет и не прощает работу по принципу «ну я ща начну работать, мне вот срочно надо, а потом как-нибудь выучу». Разберись, а потом пользуйся и радуйся. Кстати, с линуксами то же самое.
ПС. Фраза на проекте была: «я уже всё запушил, а потом закоммитал то, что нужно. Забирайте».
Мысль ушла вперёд и я записал совершенно не то, что хотел сказать.
Срочно исправлю, т.к. это важно и нельзя вводить людей в заблуждение.
И выложил всё на github.
К сожалению, нет пока времени переводитьв markdown, поэтому там лежит исходник статьи.
Это, конечно, накладывает свой отпечаток — статья слегка сыроватая получилась, надо будет допилить до приличного вида.