Реших да си преместя блога на нов сървър и да направя няколко бая закъснели upgrade-а. Като страничен ефект смених темата и оправих форматирането на по-старите постове. Ударих няколко камъка докато преместя и upgrade-на WordPress. Новата машина пък е конфигурирана с Chef. По тази причина може лесно да се пусне виртуална машина със същата конфигурация.

Искам да разкажа накратко за тези неща.

Конфигурация с Chef

Исках цялата конфигурация на сървъра да е в git хранилище, за да мога да следя какво съм правил. Исках да лесно да се подкарва същата машина във VirtualBox, за да мога да експериментирам с настройки. Исках и всичко това да е автоматизирано.

Спрях се на Chef Solo. Това е доста сложна система, която може да прави много повече от „малък домашен сървър“. Далеч по-подходяща е за клъстери от стотици сървъри, които се пипат често. Въпреки това, overhead-а не е твърде голям и си струва да се използва дори за единстев сървър. Ако човек знае Ruby се ползва относително лесно. Дава и голямо количество готова функционалност. Като цяло съм доволен.

Големият проблем е learning curve-а – усещането е като да се блъснеш в стена. Chef е предвиден да управлява голяма бройка сървъри, вариращи по различни начини, с централна конфигурация. Трябва да могат да се правят преизползваеми модули (например за PostgreSQL), които да се конфигурират различно на различни машини. Всяка дистрибуция има собствени виждания за някои неща (например имена на потребители) и готовите рецепти трябват да ги вземат предвид. Това резултира в немалко абстракции. Документацията е хубава, но няма подходящ tutorial за Chef Solo. Съответно, учи се трудно.

За щастие, веднъж научен е лесен за ползване. Кодът на готовите рецепти е разбираем. Веднъж ориентиран, човек се оправя лесно. Това е втората такава конфигурация, която правя – първата бяха сървърите на LOOKK. Струва ми се изключително полезен дори да не управлявате ферма

Vagrant

Vagrant е страхотен проект, който позволява лесно да се пускат development виртуални машини. Например, ако имате сложен setup със ZeroMQ, PostgreSQL, Redis и Solr, може да автоматизирате създаването на среда за разработка. Дефинирате машината с малко shell script (или Chef), хвърляте тази конфигурация с git и всеки може да си подкара виртуалка с проекта лесно.

Аз използвам Vagrant за да пусна виртуална машина, която впоследствие да конфигурирам с Chef. Стандартните виртуалки на Vagrant имат излишен софтуер – Ruby, Puppet, Chef. Исках минималистична машина, която да е максимално близка до истинския сървър. За това ползвах Veewee – друг подобен проект, който автоматизира създаването на виртуални машини.

Как работи всичко това

Ето какво става ако искам да подкарам виртуалка със сървъра:

1. Check out-вам едно git хранилище и изпълнявам една rake задача
2. Veewee изтегля .iso с дистрибуцията и прави минимална виртуална машина, която подготвя за Vagrant
3. Vagrant пуска виртуалната машина и ѝ дава IP в локалната мрежа
4. Chef настройва цялата машна – създава потребители, качва пакети, поставя конфигурационни файлове и прочее
5. Финално, тегли се последния backup на WordPress и MySQL и се поставя на съответните места

След това добавям един ред в /etc/hosts и на http://skanev.vm/ мога да видя този блог, работещ във виртуална машина.

Споделяне

Иска ми се да публикувам repo-ото с тази конфигурация в GitHub. В момента съм го направил така, че да няма нужда от пароли в хранилището, но не съм напълно сигурен колко добра идея е да правя конфигурацията на тази машина публична. Ако някой, по-разбиращ от сигурност, иска да погледне и се уверим, че няма голям проблем, ще се радвам да го направя.

Също така, научих разни неща за тези технологии, които ми се иска да споделя. Може би ще направя презентация в initLab в един момент. Дотогава ако някой иска да си говорим за Chef – да пише. Ако някой мисли, че има смисъл да блогвам още по темата – да ме сръчка. Ще се радвам да помогна 🙂

WordPress

Бях изоставил WordPress-а на един сървър. Уикенда седнахме с Ники и се опитахме да го мигрираме локално. Хубавото бе, че WordPress се обнови безпроблемно от 2.7 до 3.7. Това ме впечатли – малко софтуер може да се похвали с това. Лошото бе докато стигнем до там.

Любимия ми момент: encoding-а пробем. Отваряйки страницата, текста изглеждаше така:

Искам да систематизирам и споделя неща, над които съм

„Аха“, казахме си ние, „трябва да сменим от latin1 на UTF-8“. Отворихме wp-config.php, но там стоеше UTF-8. Още по-интересно – когато го променихме на latin1, текста изглеждаше правилно.

Последва доста забавен час и нещо. Бях забравил колко „интересна“ е работата с MySQL. Случвало ли ви се е да имате „двойно encode“-нат Unicode? Отново, малко софтуер може да се похвали, че постига такива неща. Детайли как и защо може да намерите в този блог пост.

Отвъд това имаше други забавни моменти като подкарването на POW и Nginx на 80 порт, но няма да задълбавам.

Следващи стъпки

Всъщност, меракът ми от край време е да си направя собствена платформа за блогване. Тази миграция е нещо като първа стъпка. Вместо да започвам с код и да приключвам с конфигурация на сървър, реших да го направя наобратно. Така хем ще имам къде да качвам работни версии, хем ще имам адекватен блог докато (ако изобщо) това стане.

Съответно, въпреки че не обичам да завършвам с клишета: очаквайте да започна да пиша по-често.