Про Chef и Ansible
Кажется я наконец могу сформулировать внутренне ощущение по поводу сравнения Chef и Ansible после двух месяцев погружения.
Ansible - OpsOps тулза. Именно поэтому она так популярна у простых админов. Она очень хорошо ложится на их модель мышления и действий. Просто запускаем разные команды по SSH на серваках в зависимости от входных параметров, продолжаем сидеть в уютном Operations мирке, но автоматизируем свою деятельность не меняя кардинально привычного подхода к работе. И это хорошо, юниксвейно, и даже просто замечательно, если сравнивать с бестиариями башово-перлово-питонячих скриптов.
Chef - DevOps тулза. Да, её можно использовать и как чисто OpsOps, но больше пользы Шеф приносит когда работает клеем между разными частями проекта, позволяя сращивать управление конфигурацией с CI, assets management, аудитом безопасности, процессом доставки приложения, тестирования, etc. Именно случай Infrastructure as a Code в комплексном её восприятии, когда вовлечены не только Ops и Dev, но и Sec, QA, аналитики, продуктологи и офисная массажистка. И желательно что бы всё строилось от Программного продукта, который есть основное дело компании. Тогда все эти сложности обретают смысл и Chef приносит максимальную пользу.
Как известно, хороший инженер отличается от плохого в том числе тем, что рассматривает свои задачи системно, глядя на несколько уровней выше и ниже непосредственно уровня текущей проблемы. Желаю всем быть хорошими инженерами и смотреть на проблему управления инфраструктурой несколько шире, чем запуск командочек на серверах и рендеринг конфигов по темплейтам.
P.S. Важное замечание. Мы тут говорили про стек инструментов/экосистему Ansible и Chef, а не только про Chef-client и ansible-playbook, если это не очевидно по тексту.
Такие дела.
Ansible - OpsOps тулза. Именно поэтому она так популярна у простых админов. Она очень хорошо ложится на их модель мышления и действий. Просто запускаем разные команды по SSH на серваках в зависимости от входных параметров, продолжаем сидеть в уютном Operations мирке, но автоматизируем свою деятельность не меняя кардинально привычного подхода к работе. И это хорошо, юниксвейно, и даже просто замечательно, если сравнивать с бестиариями башово-перлово-питонячих скриптов.
Chef - DevOps тулза. Да, её можно использовать и как чисто OpsOps, но больше пользы Шеф приносит когда работает клеем между разными частями проекта, позволяя сращивать управление конфигурацией с CI, assets management, аудитом безопасности, процессом доставки приложения, тестирования, etc. Именно случай Infrastructure as a Code в комплексном её восприятии, когда вовлечены не только Ops и Dev, но и Sec, QA, аналитики, продуктологи и офисная массажистка. И желательно что бы всё строилось от Программного продукта, который есть основное дело компании. Тогда все эти сложности обретают смысл и Chef приносит максимальную пользу.
Как известно, хороший инженер отличается от плохого в том числе тем, что рассматривает свои задачи системно, глядя на несколько уровней выше и ниже непосредственно уровня текущей проблемы. Желаю всем быть хорошими инженерами и смотреть на проблему управления инфраструктурой несколько шире, чем запуск командочек на серверах и рендеринг конфигов по темплейтам.
P.S. Важное замечание. Мы тут говорили про стек инструментов/экосистему Ansible и Chef, а не только про Chef-client и ansible-playbook, если это не очевидно по тексту.
Такие дела.