Chef vs Ansible vs Salt за configuration management

[Sava Chankov]

Привет,

един бърз devops въпрос – освен Chef и Puppet, някой от вас ползвал ли е Ansible или Salt за управление на конфигурации?

с пролетен поздрав,

Сава

[Evgeni Dzhelyov]

Аз пробвах ansible като алтернатива да замести puppet манифестите. Като цяло идвайки от ruby background, идеята да пиша YAML по-скоро беше минус накрая. Това което ми хареса беше това, че нещата са по simple и push стратегията ми позволява да имам инвентар на всички машини, да правя ad-hoc команди, да деплойвам и управявам конфигурацията от едно място. Как това да стане в puppet, хич не ми е ясно, въпреки че знам, че те имат решения за подобни проблеми, но с други tools, които не ми беше много очевидно как да сетъпна.

Накрая така и не го вкарахме в употреба, поради редица причини, но аз лично имам мнение по няколко аспекта за тези tools:

1. Идеята да се ползва някакъв custom език, накрая отива до това да си направим наш DSL, според мен най-добре да се изполва реален скирптов език и DSL отгоре - т.е Руби. Затова най-много ми допада Chef в това отношение.

2. После трябва да се преоткрие цялата package management инфраструктура, модулизация, re-use. Пак не виждам смисъл, да има собствени открития.

3. Важно е да имаш възможност за push команди, централна информация за всички сървъри, да можеш да си интегрираш деплоймънта по някакъв начин.

Като цяло Chef изглежда да пасва най-добре на моите виждания към момента, но не съм го ползвал в реална продукция. Ansible поне е нов, което е и плюс и минус, и автора като цяло има идея какви са проблемите в бранша, но идеята за YAML базиран език, не ми допада (накрая се измислят loop структури, if-ове...). Puppet, не знам, според мен там нещата са доста ... complicated, всичко е custom, а за Salt нямам наблюдения.

Това е от мен,

Евгени

[Stefan Kanev]

Аз ще бъда по-кратък.

Имам опит с Chef и съм бая доволен, но (1) има сериозно дебел learning curve и (2) е два пъти по-зор ако търсиш Chef Solo.

В текущата фирма вероятно ще сме на Ansible, защото е доста по-прост за научаване.

Puppet не съм пробвал, а и нямам интерес, защото си измислят собствен език.

[Dimitar Panayotov]

Един от проектите в които съм налят в момента ползва 10+ EC2 сървъра в AWS и всеки един от тях има по няколко Docker контейнера вътре. Когато започнахме да правим това, си скубехме косите с Puppet поне по два пъти на час, денонощно -- Евгени е споменал част от неприятностите по-горе. После хванахме Ansible -- беше много трудно в началото, но само за седмица двамата важни човеци по deployment-а настигнахме и сега всичко е просто въпрос на писане на няколко bash scripts с които си изразяваш намерението почти на чист английски (и които вътре викат няколко Ansible команди) -- работи се в мир сега и сме свободни да си направим health checks, DB backups, вече направихме и load balancing (с Ansible е лесно просто да си вдигнеш още един сървър временно и след известно време да го убиеш), и още сума благинки.

Горещо препоръчвам Ansible -- it almost never gets in the way and it gets sh*t done без да те занимава с детайли които най-малко искаш да четеш когато имаш да оправяш deployment-и.

// Дими.

--

Dimitar Panayotov
http://www.linkedin.com/in/dpanayotov

[Valentin Mihov]

И аз рацъквах ansible преди време и направих няколко рецепти за
сетъпване на сървъри по един open source проект. Общо взето съм доволен.
На няколко пъти съм се опитвал да задълбая в chef, но learning curve-а
ми идва стръмен особенно като се има предвид, че искам да правя доста
прости неща (инсталиране на пакети, ъпдейтване на код и рестартиране на
сървиси).

Ansible беше доста по-лесен за научаване и интегриране. Има модули за
доста неща. Сещам се че имах малко проблем с подкарване на RVM, но
накрая успях. Доволен съм от него, но и не съм го тествал на
конфигурации със много машини в клъстер.

--Вальо

On 3/30/15 5:27 PM, Dimitar Panayotov wrote:
> Един от проектите в които съм налят в момента ползва 10+ EC2 сървъра в
> AWS и всеки един от тях има по няколко Docker контейнера вътре. Когато
> започнахме да правим това, си скубехме косите с Puppet поне по два пъти
> на час, денонощно -- Евгени е споменал част от неприятностите по-горе.
> После хванахме Ansible -- беше много трудно в началото, но само за
> седмица двамата важни човеци по deployment-а настигнахме и сега всичко е
> просто въпрос на писане на няколко bash scripts с които си изразяваш
> намерението почти на чист английски (и които вътре викат няколко Ansible
> команди) -- работи се в мир сега и сме свободни да си направим health
> checks, DB backups, вече направихме и load balancing (с Ansible е лесно
> просто да си вдигнеш още един сървър временно и след известно време да
> го убиеш), и още сума благинки.
>
> Горещо препоръчвам Ansible -- it almost never gets in the way and it
> gets sh*t done без да те занимава с детайли които най-малко искаш да
> четеш когато имаш да оправяш deployment-и.
>
> // Дими.
>
> 2015-03-30 17:16 GMT+03:00 Stefan Kanev <stefan...@gmail.com

> <mailto:stefan...@gmail.com>>:

[Sava Chankov]

Благодаря на всички за изчерпателните отговори! В крайна сметка май ще разуча Chef Solo, защото струва ми се  единствен позволява правенето на custom RPM пакети с точната версия на ruby.

[Radoslav Stankov]

Аз съм ползвал Chef и Puppet. Като цяло и двата вършат работа. Но, наскоро на работа минахме изцяло на Docker. И сме доста доволни как работят нещата. Поне според мен доста по-лесно се работи с него от колкото с Chef и Puppet.

[Sava Chankov]

Благодаря, Стефан Кънев също ми го препоръча и така се зарибих, че една нощ четох документация =) Наистина изглежда като инструмента, който ми трябва.

Имам два въпроса:

Как точно инсталирате ruby в docker image-а?

Искам да инсталирам на една машина gitlab и redmine. Два docker image ли да направя, поотделно за gitlab и redmine, или един общ? Ако са отделни ми се струва, че ще хабят повече ресурс (всеки ще си има собствен nginx и postgresql), обаче ще са независими един от друг и ъпгрейда на всеки компонент май ще е по-лесен. Какво ще препоръчате?

[Dimitar P. Dimitrov]

015-04-01 10:36 GMT+03:00 Sava Chankov <sava.c...@gmail.com>:

Благодаря, Стефан Кънев също ми го препоръча и така се зарибих, че една нощ четох документация =) Наистина изглежда като инструмента, който ми трябва.

Имам два въпроса:

Как точно инсталирате ruby в docker image-а?

Бих използвал ruby-build standalone за това.

Искам да инсталирам на една машина gitlab и redmine. Два docker image ли да направя, поотделно за gitlab и redmine, или един общ? Ако са отделни ми се струва, че ще хабят повече ресурс (всеки ще си има собствен nginx и postgresql), обаче ще са независими един от друг и ъпгрейда на всеки компонент май ще е по-лесен. Какво ще препоръчате?

Бих препоръчал два отделни image-а. Реално, дублираният "ресурс" ще дойде само от PostgreSQL, тъй като Nginx е доста компактен. Ако искаш да избегнеш това дублиране, може да имаш трети Docker image с PostgreSQL.

Отговорът ми се базира на опита ми с Linux containers (LXC), но Docker стъпва на LXC и смятам, че е приложимо и тук. 

[Evgeni Dzhelyov]

Аз нямам опит с docker, но от опита ми с менажирането на инфраструктура според мен е най-удачно да си разделиш нещата според това дали имат state или нямат. Примерно за gitlab бих направил един image със всички компоненти които нямат state - ruby, nginx, gitlab и т.н. Този image се ъпдейтва супер лесно и просто го заменям, докато с базата е по-пипкаво. Затова базата бих я рънвал отделно, с редовни бекъпи и като цяло ще я ъпдейтвам доста по-рядко.

Сподели после как се е получило, защото ми е интересно.

[Evgeni Dzhelyov]

Забравих да добавя, че за redmine също ще направя отделен image с всички stateless компоненти и най-вероятно ще ползвам същата база, тъй като няма смисъл да менажирам две бази и да се чудя за бекъпи и така нататък, особенно в случаите когато не очаквам голямо натоварване на базата.

[Dimiter Shalvardjiev]

Малко допълване:

Docker, yay. Лесно за основните задачи, трудно за mastery. Но от всички опции, според мен най-гъвкавото. Аз лично бих разделил всеки апликейшън (NGINX, Postgres, Redmine, Gitlab) на отделна докер инстанция, за най-lean. И най-удобно за променяне.

Алтернативата е да се сложат отделни конфигурационни файлове за всеки демон и, реално, само една машина - както го правят Discourse: https://github.com/discourse/discourse_docker/tree/master/templates. Голям минус на този подход е иинременталния build time: Discourse отнема 20-ина минути.

Друг интересен похват е да се ползва shared storage на повече контейнери. После само се бекъпва сториджа и не се провизионират отделни сториджи за базата данни, за апликацията и т.н.

[Dimitar P. Dimitrov]

(Между другото, тази дискусия е подходяща за https://discuss.ruby.bg/)

[Dimiter Shalvardjiev]

(Добавих я тук: https://discuss.ruby.bg/t/chef-vs-ansible-vs-salt-vs-docker-configuration-management/41, ще си поиграя да я ъпдейтвам, ако се налага.)

[Stefan Kanev]

Между другото, хайде без такива, моля. Как ще реагирате, ако някой влезе и под дискусиите там започне да пише "Тази дисукисия е подходяща за Facebook групата/пощенския списък/forums.dir.bg"? Не е ОК, нали?

Ако смятате, че има хляб в идеята да затворим този пощенски списък и да мигрираме дисуксиите другате, моля пуснете ново писмо, където да изразите това и да видим какво мислят всички.

[Dimitar P. Dimitrov]

Имаш право, че това трявбаше да е питане в отделна тема, а не вмъкнато тук.

[Sava Chankov]

2015-04-01 11:28 GMT+03:00 Evgeni Dzhelyov <evgeni....@gmail.com>:

Сподели после как се е получило, защото ми е интересно.

За да пусна gitlab и redmine използвах:

postgres
redis
sameersbn/gitlab
sameersbn/redmine
jwilder/nginx-proxy

Това са готови image-и от docker registry-то. Файловете на базата данни, на git и на redmine са извън контейнерите, както го изисква здравия разум. Скритата лимонка е jwilder/nginx-proxy, който прави обратното проксиране към redmine и gitlab обидно лесно. Цялата таз галимация стартирах само с 11 (!) команди (все още не е в production).

Docker е като концерт на Лепа Брена в София през 1990, ако ме разбирате правилно ;-)