Комментарии 59
мотивирующая статья, если не сказать больше. первый пункт хорош пинок, пойду осиливать, хорошо ведь не только для администрирования но и для виртуалочек (комманда, тестирование).
не ходить на сервер по ssh самостоятельно.
Самый лучший способ контрацепции — воздержание!
Не могу назвать себя администратором, но пару вэдээсок админить приходится. Соблюдаю 4 анти-паттерна из пяти. До того, чтобы в /etc устроить mercurial репозиторий додумался. Теперь бы ещё не забывать коммитить и пушить (закоммитил 183 файла...)
Заинтересовал первый антипаттерн — это что-то вроде capistrano/phing? Имеет смысл использовать на паре независимых вэдээсок? Или это для настоящих админов с 16+ фронтендами?
Заинтересовал первый антипаттерн — это что-то вроде capistrano/phing? Имеет смысл использовать на паре независимых вэдээсок? Или это для настоящих админов с 16+ фронтендами?
capistrano — это для деплоя по одному приложению. А тут скорее речь про системы настройки сервера в целом.
До того, чтобы в /etc устроить mercurial репозиторий додумался. Теперь бы ещё не забывать коммитить и пушить (закоммитил 183 файла...)
Для этого есть обвязка удобная, etckeeper называется (в Дебиане есть в пакетах).
На паре вэдэсок имеет смысл скорее для опыта. Реальная польза ощутима на большом парке машин (особенно с типовыми задачами).
Chef / Puppet и им подобные – не совсем похожи на capistrano. Capistrano — хорошее дополнение для этих инструментов, хотя и не обязательное. Cap позволяет выполнять команды на удаленных серверах. По сути — обёртка над ssh, особенно удобная для развертывания приложений.
Системы управления конфигурациями служат для того чтобы выполнить начальную(и повседневную) настройку сервера — установить ПО, развернуть нужные конфигурационные файлы и т.д. Особенно, когда таких(особенно однотипных) серверов больше двух.
А стоит ли использовать в малых системах — это личное дело каждого.
Мое мнение — да. Мне удобнее сначала написать рецепт, внимательно его прочитать, а потом запустить chef-client на нужных узлах и применить изменения. Плюс некоторая централизованность есть. Плюс возможность протетстировать предстоящие изменения на тестовой площадке.
Системы управления конфигурациями служат для того чтобы выполнить начальную(и повседневную) настройку сервера — установить ПО, развернуть нужные конфигурационные файлы и т.д. Особенно, когда таких(особенно однотипных) серверов больше двух.
А стоит ли использовать в малых системах — это личное дело каждого.
Мое мнение — да. Мне удобнее сначала написать рецепт, внимательно его прочитать, а потом запустить chef-client на нужных узлах и применить изменения. Плюс некоторая централизованность есть. Плюс возможность протетстировать предстоящие изменения на тестовой площадке.
Спасибо, надо попробовать. Cap и использую для деплоя своих приложений. Судя по всему порекомендуете Chef поизучать?
Это вопрос религиозный больше.
Лично я — пользуюсь Chef по ряду причин:
— мне нравится ruby и писать рецепты на ruby больше чем DSL у puppet
— мой начальник — один из известных тренеров по chef в европе
— исходя из предыдущего пункта — chef у нас — стандарт на работе.
Если сравнивать с puppet — то у puppet немного более длинная история — а значит и немного больше литературы. а вскидку могу назват 2-3 англоязычных книги. chef пока не может этим похвастаться. Но у chef — просто прекрасная wiki и отличное коммьюнити где можно получить ответы на вопросы, а так же найти рецепты, советы и т.д.
На самом деле самый правильный метод выбора — так же как с linux-дистрибутивом первым. Лучше пользоваться тем, в чем разбирается соседский гуру. Но когда я начинал — у меня такого гуру еще не было, по этому меня выручили запросы в гугл вроде «chef vs. puppet» и «configuration management systems comparison» и просто интуиция совмещенная с авантюризмом, которые подсказали «chef перспективнее, моложе и интереснее для изучения»
Лично я — пользуюсь Chef по ряду причин:
— мне нравится ruby и писать рецепты на ruby больше чем DSL у puppet
— мой начальник — один из известных тренеров по chef в европе
— исходя из предыдущего пункта — chef у нас — стандарт на работе.
Если сравнивать с puppet — то у puppet немного более длинная история — а значит и немного больше литературы. а вскидку могу назват 2-3 англоязычных книги. chef пока не может этим похвастаться. Но у chef — просто прекрасная wiki и отличное коммьюнити где можно получить ответы на вопросы, а так же найти рецепты, советы и т.д.
На самом деле самый правильный метод выбора — так же как с linux-дистрибутивом первым. Лучше пользоваться тем, в чем разбирается соседский гуру. Но когда я начинал — у меня такого гуру еще не было, по этому меня выручили запросы в гугл вроде «chef vs. puppet» и «configuration management systems comparison» и просто интуиция совмещенная с авантюризмом, которые подсказали «chef перспективнее, моложе и интереснее для изучения»
зоопарк из 16 front-end серверов на которых стоят разные версии debian, centos и gentoo
в таком случае далеко не всегда возможны пункты (1) и (2)
Совершенно не согласен с первым пунктом. Для массовых изменений или каких-только-угодно действий на сервере SSH подходит ни крайней мере не хуже Puppet и Chef. Заход по ключу, группы серверов с одинаковыми функциями и привычные shell/perl/python скрипты для автоматизации действий.
Не вижу смысла изучать дополнительные инструменты со своими ограничениями, новые синтаксисы, шаблоны и пр, особенно осознавая то, что когда-то вам потребуется сделать что-то, и вы это сделать этим инструментом не сможете.
Да и, спасибо Майкрософту, уже выросло не одно поколение администраторов, не понимающих как можно отправить GET/POST телнетом, или там почту по SMTP отправить через него же. Все эти гуевые прибамбасы, управления кофигурациями при помощи мышки — ровно из той же оперы.
Не вижу смысла изучать дополнительные инструменты со своими ограничениями, новые синтаксисы, шаблоны и пр, особенно осознавая то, что когда-то вам потребуется сделать что-то, и вы это сделать этим инструментом не сможете.
Да и, спасибо Майкрософту, уже выросло не одно поколение администраторов, не понимающих как можно отправить GET/POST телнетом, или там почту по SMTP отправить через него же. Все эти гуевые прибамбасы, управления кофигурациями при помощи мышки — ровно из той же оперы.
Поясню еще немного, раз уж есть несогласные. Использование систем такого рода накладывает ограничения на инфраструктуру. Преставьте себе, что у вас не просто убунтушечка, а система на которой стоит панель управления хостингом, например Plesk. Которая требует определенного почтового клиента, определенного его конфига, определенных каталогов где лежат юзерские сайты, и пр. Для начинающего админа — мечта. В два клика настраивается (и неплохо настраивается) сервер, автоматизируются до двух кликов рутинные операции и делегируются еще кому-то. Идилия? Кому как.
То же до систем управления. Как система управления может отслеживать уязвимость (а это одна из функций Puppet enterpize) в пакете, если он собран или взят из неофициального репозитория? Ну и обвес. Я понимаю, сейчас уже не модно ставить юникс без гуя. В минимальной инсталляции ставится столько софта, сколько раньше на рабочей станции то не стояло — и иксы, и апачи, и джава. Конечно, в этом зоопарке, и руби и агенты не так уж заметны.
Лирическое отступление: приходили тут интеграторы с одной американской системой мониторинга. Не осилили установить агента — не хватило ей 1 гигабайта места в корневом разделе. Видать, жадные мы, раз место на диске экономим.
То же до систем управления. Как система управления может отслеживать уязвимость (а это одна из функций Puppet enterpize) в пакете, если он собран или взят из неофициального репозитория? Ну и обвес. Я понимаю, сейчас уже не модно ставить юникс без гуя. В минимальной инсталляции ставится столько софта, сколько раньше на рабочей станции то не стояло — и иксы, и апачи, и джава. Конечно, в этом зоопарке, и руби и агенты не так уж заметны.
Лирическое отступление: приходили тут интеграторы с одной американской системой мониторинга. Не осилили установить агента — не хватило ей 1 гигабайта места в корневом разделе. Видать, жадные мы, раз место на диске экономим.
Тоесть вы предлагаете заменить готовые инструменты самописными скриптами?
Простите, а какие у вас есть периодические задачи, которые нужно выполнять на серверах? У меня раскатка сервера выполняющего роль X делается автоматически, скриптами (да, предпочитаю стягивать конфиги из репозитория одной командой). Скрипты эти — на полтора экрана текста, понятны любому юникс админу, документация на любой из вышеупомянутых инструментов занимает на два порядка больше страниц
все правильно, у вас есть свой велосипед, аналогичный предложенным инструментам и покрывающий часть их функций. и вы им гордитесь.
Нет, правда — столько текста вокруг простой идеи — вы зачем-то связали отсутствие навыков ручного troubleshooting с использованием системам управления конфигурациями.
Не подменяйте понятия. Это две разных области, и применение инструментов из одной совсем не лишает знаний в другой.
А на практике — вы все равно используете систему управления конфигурациями. Только свою, самописную. Это, кстати, тоже вариант решения проблемы описанной в первом пункте. И его право на жизнь никто не оспаривает. (Ну по крайней мере я не оспариваю)
Нет, правда — столько текста вокруг простой идеи — вы зачем-то связали отсутствие навыков ручного troubleshooting с использованием системам управления конфигурациями.
Не подменяйте понятия. Это две разных области, и применение инструментов из одной совсем не лишает знаний в другой.
А на практике — вы все равно используете систему управления конфигурациями. Только свою, самописную. Это, кстати, тоже вариант решения проблемы описанной в первом пункте. И его право на жизнь никто не оспаривает. (Ну по крайней мере я не оспариваю)
не буду спорить. Но повторюсь, что такой инструмент гибче и написан на понятном каждому админу bash ;)
плох тот админ, которому рецепты для chef на ruby непонятным языком кажутся
Есть только одна проблема, количество людей которые умеют писать правильно на bash вообще мало. Я вот себя не отношу к тем кто умеет. И наверно могу сказать что знаю только двоих которые умеют писать на нём правильно. И мой опыт подсказывает что проще найти человека который разбирается в ruby чем в bash.
Поддерживаю данного оратора. Puppet или Chef имеет смысл когда у тебя не 16 а 16000 серверов. А когда у тебя два-три сервера Puppet — это сильный оверкилл, для этого отлично подходит SSH, а главное требует меньше времени и сил на настройку и работу.
Спасибо за подборку полезных ссылок. Может кто еще что-то посоветует почитать?
Из серьезных книг — пожалуй вот эти:
DevOps: High-impact Strategies — What You Need to Know: Definitions, Adoptions, Impact, Benefits, Maturity, Vendors
Roebuck, Kevin
Web Operations: Keeping the Data On Time
Allspaw, John, Robbins, Jesse
Cloud Computing Architected: Solution Design Handbook
Rhoton, John, Haukioja, Risto
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))
Farley, David, Humble, Jez
Pro Puppet
Turnbull, James, James Turnbull, Jeffrey McCune December 8, 2011
Pulling Strings with Puppet: Configuration Management Made Easy
Turnbull, James
Configuration Management: High-impact Strategies — What You Need to Know: Definitions, Adoptions, Impact, Benefits, Maturity, Vendors
Roebuck, Kevin
А из статей и блогов:
Стоит обрать внимание на этот и этот блоги. А так же на хэштеги #opschef, #puppet и #devops и прочие тематические в твиттере.
DevOps: High-impact Strategies — What You Need to Know: Definitions, Adoptions, Impact, Benefits, Maturity, Vendors
Roebuck, Kevin
Web Operations: Keeping the Data On Time
Allspaw, John, Robbins, Jesse
Cloud Computing Architected: Solution Design Handbook
Rhoton, John, Haukioja, Risto
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))
Farley, David, Humble, Jez
Pro Puppet
Turnbull, James, James Turnbull, Jeffrey McCune December 8, 2011
Pulling Strings with Puppet: Configuration Management Made Easy
Turnbull, James
Configuration Management: High-impact Strategies — What You Need to Know: Definitions, Adoptions, Impact, Benefits, Maturity, Vendors
Roebuck, Kevin
А из статей и блогов:
Стоит обрать внимание на этот и этот блоги. А так же на хэштеги #opschef, #puppet и #devops и прочие тематические в твиттере.
Все понимают как хорошо, а делается обычно как быстрее, временно.
Нет ничего более постоянного, чем временное.
самому стыдно
Нет ничего более постоянного, чем временное.
самому стыдно
> Представьте себе зоопарк из 16 front-end серверов на которых стоят разные версии debian, centos и gentoo c подключенными нестандартными репозиториями сомнительного происхождения?
А что плохого в разных версиях CentOS? В локальном репозитории со своими пакетами просто нужно учесть, что в 5-ой ветке CentOS младшие версии поддерживают только md5 для пакетов.
А что плохого в разных версиях CentOS? В локальном репозитории со своими пакетами просто нужно учесть, что в 5-ой ветке CentOS младшие версии поддерживают только md5 для пакетов.
Я сам к этому пришел не так давно, но есть в планах на этот год внедрение puppet+git и остановка на одном дистрибутиве — ubuntu 12.04 lts для инфраструктуры + oracle linux для oracle db (сейчас используем как ubuntu 10.04, так и freebsd разных версий + немного centos и oracle linux). для мониторинга внедрить — zabbix + cacti (сейчас используем самописные скрипты для уведомлений и cacti для наглядности графиков). Вообщем планов уйма, дошли бы до всего руки.
у меня сначала глаз дернулся от вашего ника
а так планы хорошие, только наверное очень смелые в той части где 12.04. Вот правда. Очень смелые.
а так планы хорошие, только наверное очень смелые в той части где 12.04. Вот правда. Очень смелые.
у меня сначала глаз дернулся от вашего ника
:)
а так планы хорошие, только наверное очень смелые в той части где 12.04. Вот правда. Очень смелые.
Ну почему же. я на 10.04 перешел с 8.04 через пару месяцев с его выхода — проблем не наблюдал. Как правило, в первый месяц, свежий выпуск латается до приемлемого уровня.
Вроде речь о сервере, а там Unity по дефолту не ставится :)
Всё-таки. Кого лучше брать для централизованного управления?
Паппет съел мне мозг и ушел в помойку сразу. А между шефом и цфе — кого лучше выбирать и почему?
Паппет съел мне мозг и ушел в помойку сразу. А между шефом и цфе — кого лучше выбирать и почему?
я там выше ответил на похожий вопрос
если вкратце — то какая вам лично больше нравится. Лучше всего попробуйте обе. Первое впечатление бывает редко бывает обманчиво.
если вкратце — то какая вам лично больше нравится. Лучше всего попробуйте обе. Первое впечатление бывает редко бывает обманчиво.
Пытался разбираться со всеми тремя, больше всех пожевал мозг cf, а папетка показалась более ли менее логичной.
В общем каждому свое.
Если есть время почитайти холивары Чиф vs Паппет, особенно начинается инетерсно когда появлюятся 50 летние мужики и рассказывают, что cf не зря 17 лет на рынке, а вы все в киндергарден
В общем каждому свое.
Если есть время почитайти холивары Чиф vs Паппет, особенно начинается инетерсно когда появлюятся 50 летние мужики и рассказывают, что cf не зря 17 лет на рынке, а вы все в киндергарден
Есть ещё spacewalk/sattelite от RH.
НЛО прилетело и опубликовало эту надпись здесь
вам возможно будет интересно прочитать эту статью
Если я перестану программировать, то мне свой свой сервер админить незачем будет. А если все перестанут программировать…
а какие фишки Circonus?
Спасибо, почитал статью после чего подписался на блог Agile сисадмин и книгу Test Driven Infratructure with Chef купил для Kindle, вечером почитаю.
Если что, есть еще сравнительно-легковесная альтернатива Шефу — Sprinkle (он построен поверх capistrano), раньше использовал его для автоматизации настройки новых серверов.
Сейчас смотрю в сторону Chef, потому что у него развитое сообщество и куча готовых рецептов (которые можно либо просто использовать, либо слегка модифицировать под свои нужды).
Puppet (и ShadowPuppet) когда-то пробовал но сломал мозг, наверное просто не могу заставить себя мыслить в контексте «что я хочу получить в результате» и довериться автоматике вместо «что нужно сделать».
Если что, есть еще сравнительно-легковесная альтернатива Шефу — Sprinkle (он построен поверх capistrano), раньше использовал его для автоматизации настройки новых серверов.
Сейчас смотрю в сторону Chef, потому что у него развитое сообщество и куча готовых рецептов (которые можно либо просто использовать, либо слегка модифицировать под свои нужды).
Puppet (и ShadowPuppet) когда-то пробовал но сломал мозг, наверное просто не могу заставить себя мыслить в контексте «что я хочу получить в результате» и довериться автоматике вместо «что нужно сделать».
Совсем забыли написать про централизованную аутентификацию на серверах. Когда на 100+ серверах зоопарк учетных записей это ужасно с точки зрения безопасности.
А вот про системы контроля и распространения конфигураций не соглашусь. У меня в ведении много серверов и ни разу нужны в них не было. В отделе есть сектор развития, который готовит внедренческую документацию, типовые решения и т.д., а также сектор эксплуатации, который по этой документации настраивает реальное оборудование. Получается проще и надежнее, нежели городить единый центр конфигурирования с псевдо-языком. Плюс представьте что его скомпрометируют — можно смело переставлять ОС на всем парке оборудования.
А вот про системы контроля и распространения конфигураций не соглашусь. У меня в ведении много серверов и ни разу нужны в них не было. В отделе есть сектор развития, который готовит внедренческую документацию, типовые решения и т.д., а также сектор эксплуатации, который по этой документации настраивает реальное оборудование. Получается проще и надежнее, нежели городить единый центр конфигурирования с псевдо-языком. Плюс представьте что его скомпрометируют — можно смело переставлять ОС на всем парке оборудования.
А если хранилище внедренческой документации скомпрометируют?
Может стоит спросить сектор эксплуатации, как им работается, удобно или нет. Если написать внедренческую документацию, а в ней указать, что необходимо на всех 47 серверах обновить ruby до версии 1.8.7patchlevel 251, то это не значит, что сектору эксплуатации так удобно. Это лично вам скорее удобно.
Проблема у единого центра конфигурации одна — его надо один раз настроить и вбухать кучу времени. Потом все превращается в одну кнопку для всех единиц или десятков машин.
Концепция DevOps (и chef в частности) позволяет вообще отказываться от таких центров внедренческой документации. Прошлый век какой-то. Сам центр конфигурации и будет таким хранилищем. Рецепты прекрасно документируются в процессе написания, все понятно и доступно, логика прослеживается. Процесс работы не превращается в графики составления графиков и документирование документации по написанию документации. Простите, выдыхаю ))
Проблема у единого центра конфигурации одна — его надо один раз настроить и вбухать кучу времени. Потом все превращается в одну кнопку для всех единиц или десятков машин.
Концепция DevOps (и chef в частности) позволяет вообще отказываться от таких центров внедренческой документации. Прошлый век какой-то. Сам центр конфигурации и будет таким хранилищем. Рецепты прекрасно документируются в процессе написания, все понятно и доступно, логика прослеживается. Процесс работы не превращается в графики составления графиков и документирование документации по написанию документации. Простите, выдыхаю ))
Третий антипаттерн напомнил цитату с баша
Puppet очень хорошая штука. Но тут она упомянута не к месту немного, т.к. на наворотить дел, наделать ошибок и т.д. при помощи Puppet можно не меньше, а порой и больше, чем просто через SSH.
Каждый выбирает свой путь imgur.com/KO5ke
Немного не пойму про сложности языка программирования который вроде как навязывают пользователю в системе управления серверами, к примеру chef, казалось бы необходимо учить ruby. Далее башерам посвящается: Я хочу посмотреть как вы будете автоматизировать мониторинг, систему рееврного копирования да и другие сервисы в которых есть API (почти во всех сейчас), вы будете с API работать через *sh или передавать курлу кучу аргументов прям в ссылку? Можно конечно перейти на python bash script в пользу не руби к примеру, что поменялось? Аналогично с взаимосдействием самописных скриптов с использованием разных языков, развертка серверов, его заселение, уровне взаимодействия тех или иных конфигураций между сервисами.
Немного не пойму про сложности языка программирования который вроде как навязывают пользователю в системе управления серверами, к примеру chef, казалось бы необходимо учить ruby. Далее башерам посвящается: Я хочу посмотреть как вы будете автоматизировать мониторинг, систему рееврного копирования да и другие сервисы в которых есть API (почти во всех сейчас), вы будете с API работать через *sh или передавать курлу кучу аргументов прям в ссылку? Можно конечно перейти на python bash script в пользу не руби к примеру, что поменялось? Аналогично с взаимосдействием самописных скриптов с использованием разных языков, развертка серверов, его заселение, уровне взаимодействия тех или иных конфигураций между сервисами.
а я как лох винды админю(((
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
5 основных анти-паттернов системного администрирования