W firmie korzystamy z Chefa, niby robi swoją robotę, ale nie przepadam za nim z różnych względów. Jedna z rzeczy, która mnie drażni, to wersjonowanie i niekompatybilność (bardziej: pozorna kompatybilność) pomiędzy wersjami. W Debianie Jessie, którego mam na desktopie jest chef w wersji 11, który generalnie działał. Na serwerach mamy Chefa 12.
Ostatnio instaluję cookbook nodejs:
knife cookbook site install nodejs
Installing nodejs to /home/rozie/chef-repo/cookbooks
Checking out the master branch.
Pristine copy branch (chef-vendor-nodejs) exists, switching to it.
Downloading nodejs from the cookbooks site at version 2.4.2 to /home/rozie/chef-repo/cookbooks/nodejs.tar.gz
Cookbook saved: /home/rozie/chef-repo/cookbooks/nodejs.tar.gz
Removing pre-existing version.
Uncompressing nodejs version 2.4.2.
removing downloaded tarball
No changes made to nodejs
Checking out the master branch.
ERROR: IOError: Cannot open or read /home/rozie/chef-repo/cookbooks/nodejs/metadata.rb!
Zacząłem szukać i widywać różne dziwne rozwiązania na nieistniejące metadata.rb, przez chwilę przyszło mi dogenerowanie „brakującego” pliku na podstawie obecnego metadata.json, ale… coś mnie tknęło i postanowiłem najpierw spróbować z nowszym Chefem u siebie na lapku.
Ależ oczywiście, że instalacja Chefa w wersji 12 rozwiązała problem.
Co w takim razie preferujesz? Z Puppetem którego używamy do OpenStacka łączy mnie „love/hate relationship”, a Ansible bardziej przypomina narzędzie do tzw. orchestracji niż typowego zarządzania konfiguracją. Salt Stack?
SaltStacka i Ansible w praktyce nie używaliśmy, choć o obu słyszałem dobre opinie. Bawić się, aby się bawić nie bardzo jest czas. 🙁
Moja przygoda z systemami tego typu zaczęła się z CFEngine, ale wtedy nie bardzo było coś innego. No dobrze, był bardzo wczesny Puppet, który miał być fajny, ale niezbyt działał. 😉 Potem poszło dwutorowo – w jednej ze spółek był w użyciu Puppet, w drugiej Chef. Ten drugi okazał się lepszy.
Chef nie jest złym narzędziem, tylko właśnie… love/hate relationship. Generalnie da się go zaprząc do działania i działa dobrze, ale ma parę wad (chyba temat na osobny wpis…). W praktyce najbardziej wkurza mnie dziwny debug (Ruby way) oraz praktycznie losowej jakości cookbooki – dziwne, nieustandaryzowane zależności, funkcjonalności, struktura cookbooka i danych. Pamiętam, że wziąłem cookbook do Zabbiksa, niby wspiera Debiana. Odpaliłem na testowej wirtualce na domyślnych ustawieniach to… pobrał źródła Zabbiksa, w dodatku jakieś stare. Następnie doinstalował środowisko do kompilacji i tak zainstalował, przy okazji z dziwnie postawionym MySQL.
Ja piszę tylko swoje instrukcje a dokładniej role/moduły w Ansible. Nie wiem czy bym polecił bo nie korzystałem z innych, ale słyszałem, że jest najmłodszy i najłatwiejszy, chociaż nie dziwi mnie, jak ktoś już zainwestował czas wcześniej w ten temat i siedzi przy puppecie/chefie. Co więcej wydają się one bardziej dojrzałe i też z większą społecznością.
Inny temat, który chciałem poruszyć to Debian. Zaczyna mnie irytować jego przestarzałość i podejście społeczności do naprawiania bugów dopiero przed zamrażaniem. Widać to fajnie na wykresie otwartych bugów. Takie rzeczy w dystrybucjach ze wsparciem komercyjnym (SUSE, RHEL, Ubuntu) chyba nie wchodzi w grę. Przejechałem się kilka(naście) razy na backportach i ich jakości, a bez nich niestety chyba ciężko. Chyba zacznę powolne przejście do Ubuntu, szczególnie od wydawania z systemd. Szczególnie mnie naglą stacje robocze, serwery zajmą pewnie trochę więcej czasu.
Mam nadzieję, że chociaż trochę zmieściłem się w temacie posta 🙂
@nnb Jakbym startował teraz, to prawie na pewno sprawdziłbym Ansible na początku. Chociaż ma jedną wadę: z tego co wiem, jest push only. Chef czy Puppet są o tyle fajne, że mają swojego demona, więc teoretycznie, nawet jak się coś zepsuje tak, że nie sposób się dostać do maszyny, to będą w stanie poprawić (sprawdzić, czy nie konfiguracja sieci/firewall).
Co do przestarzałości – czego używasz i do czego? Na serwerach mam i Debiana, i Ubuntu LTS. Trochę stabilniej w Debianie, jednak i lepiej pokuładane (ale mogę być stronniczy). Ostatnio Ubuntu LTS miało cudowny bug w kernelu – traciło się dostęp do maszyn w przypadku sieciówek Intela…
Debian przestarzały był zawsze, jakby z założenia, zwłaszcza stable. Coś za coś. Ja wychodzę z założenia, że na produkcji i tak najważniejsze pakiety masz w nowszych wersjach z upstreamu/paczkowane samodzielnie. Z backportami nie miałem nigdy problemów (poza tym, że czasem ich nie było ;-)), ale to pewnie kwestia używanych pakietów. W każdym razie u mnie zarówno stable + backports, jak i unstable dają radę na desktopach.
Naprawianie bugów – Debian jest community driven. A z community jest… różnie. Co mi znowu o pewnej rzeczy przypomina…
@rozie: na desktopie przeszedłem drogę stable->testing->stable+backports. Ostatnio był paskudny bug w kernelu 4.2 o ile dobrze pamiętam, który przeszedł do testing a potem do backports. Wywalał firewalla totalnie. Moim zdaniem powinien być pilnie naprawiony, ale trzeba było poczekać aż fix przejdzie tą samą drogę z testing do backports. Dziękuję bardzo. Mogę mieć ubuntu 15.10 z kernelem 4.2 gdzie raczej błędy tego typu są traktowane poważnie. I takie błędy to dla mnie to dowód, że nie warto używać backportów, chyba że do 1, 2 strasznie ważnych paczek.
Tak samo obiecywanie squida skompilowanego z gnutls (bo przecież z openssl nie wolno), nie wiem czy się coś zmieniło bo już mam dosyć czekania. Kolejna sprawa: Libreoffice 5 w backporcie używany w i3-wm się wywala na amen. Moje bugi wiszą w bugtrakerze i jak już odparłem pierwszą próbę zamknięcia to pewnie zostaną naprawione/zaktualizowane dopiero przed wydaniem stretch.
Moja refleksja na temat społeczności Debiana jest następująca: filozofia wydania „jak będzie gotowe” wynika z braku zasobów i chęci społeczności i braku wsparcia kogoś, kto liczy pieniądze.
Miałem okazje raportować bugi w RHEL wynikające z pospiesznego wydania wersji 7 i wolę takie podejście, czyli wydanie i łatanie na bieżąco, niż wydanie raz na 5 lat i zachwycanie się jakie stabilne.
I ta stabilność Debiana też jest przereklamowana moim zdaniem. Jeżeli liczyć stosunek świeżości do stabilności to jednak inne dystrybucje wypadłyby lepiej. A jak ktoś lubi starocie to RHEL/Centos jest bardziej konserwatywny i bardziej stabilny niż Debian.
Do tego testing i stable+backports porównałbym w kwestii stabilności do Archa (byłem swego czasu fanem, takim jak teraz Debiana). Można sobie superfajny system urządzić, ale co jakiś czas z aktualizacją coś przestaje działać aż w końcu zostaje zaoranie.
Koniec żali wracam do wirtualek z Ubuntu.
Co do napraw – zależy od maintainera, jednak. Zdarzało mi się podpinać do zgłoszeń bugów, które miały kilkanaście (albo i kilkadziesiąt) miesięcy, po czym po kolejnych kilku wzbudzały zainteresowanie (na zasadzie „o, faktycznie, to TAK działa?! to nie, błąd, poprawić trzeba!”), ale miałem i szybkie reakcje i duże zaangażowanie, typu, nietypowy setup, wersja pakietu z nowego wydania nie działa (a ze starego – owszem, nawet na nowym systemie), logi, logi, niespecjalnie coś widać, maintainer prosi o zrzut ruchu w celu analizy, poprawia.
Ten bug o którym piszesz w kernelu – z tego co wiem, do backports trafiają pakiety z unstable, nie z testing. Więc o ile na poprawkę błędu w testing trzeba czasem czekać, ze względu na okres karencji (jeden z powodów dla których warto rozważyć unstable na desktopie), to w przypadku backports takiego wymogu chyba nie ma. Zresztą, get real – kernel z unstable to nie jest artykuł pierwszej potrzeby – do czasu rozwiązania problemu można skorzystać z ostatniej działającej wersji (plus hold na pakiet).