[Blog MegiTeam] Dlaczego Ubuntu?

[megi 358]

Blogi na WHT są trochę zaniedbane, nie przyjęły się, ale chcielibyśmy je wykorzystać do publikowania różnych informacji od nas - mniej marketingowych a bardziej merytorycznych, zgodnych z tematyką forum. Właśnie przed chwilą na blogu MegiTeam pojawił się kolejny wpis.

 

 

Podobno Ubuntu to staroafrykańskie słowo oznaczające „Nie umiem zainstalować Debiana”. My Debiana zainstalować umiemy, ale i tak tworząc nową platformę MegiTeam 2.0 zdecydowaliśmy się na zmianę dystrybucji. Dlaczego?

 

Czytaj: http://www.webhostingtalk.pl/blog/84/entry-70-dlaczego-ubuntu/

[Gość Pokuć]

Pierwszego wiernego czytelnika już masz Co prawda są tam tylko dwa wpisy to zapowiada się że będzie to bardzo ciekawy blog. Powodzenia !

[megi 358]

Dzięki

[Pan Kot 1535]

To ja się może nieco bardziej ustosunkuje do tematu, bo blog również uważam za fajny .

 

Ubuntu w wersji serwerowej i Debian w wersji serwerowej niczym się w zasadzie nie różnią, zmiany są minimalne, takie jak chociażby landscape czy ~30 mb ramu więcej zużycia na jakieś tam magiczne światełka. O wyborze danej dystrybucji powinno decydować wsparcie, co też bardzo fajnie ujęłaś . A osoby, które sądzą, że ubuntu jest ciężej skonfigurować/zainstalować niż debiana zawsze mnie śmieszyły .

 

P.S. Tak, osobiście jestem za debianem i stawiam go gdzie tylko mogę z jednej prostej przyczyny. Wiesz jakiej? Ustawiam sobie sync z gałęzią "testing", unattended-upgrades z powiadomieniami na specjalny e-mail i mam z główki jakąkolwiek przyszłą migrację, zawsze nowe pakiety i czasem tylko wejście na serwer, żeby rozwiązać konflikt nowej aktualizacji, która zresztą też pojawia się dość rzadko. A unattended-upgrades niczego w takim przypadku nie rusza i grzecznie czeka na swoją kolej .

 

Pewnie, to nie jest rozwiązanie na produkcję i chyba tylko samobójca by sobie coś takiego zaplikował, ale różnica jest taka, że u mnie pojęcie migracja nie występuje . Poza tym unattended-upgrades, które właśnie pochodzą z ubuntu od kilku lat (jak jeszcze squeeze był w testing) nie rozwaliły mi absolutnie niczego przy dobrej konfiguracji, a jakbym te wszystkie aktualizacje mysqla, nginxa, php-fpm i całej reszty która mi się robi automatycznie podzielił nawet na jedną na miesiąc i miał klikać każdy serwer... boli .

 

Tak więc zarówno Ubuntu jak i Debian to dwie dystrybucje, które lubię najbardziej, a definitywnie pod zastosowania produkcyjne ubuntu ze swoim LTS wygrywa z prostej przyczyny - bo debian jest nieco nieprzewidywalny ze swoimi wydaniami. Jeśli ktoś chce być na bieżąco ustawia debiana w testing tak jak ja i ma z główki, a jak maszyna musi stać to definitywnie ubuntu ze swoim lts bije na głowę zarówno świeżością pakietów, jak i ich wsparciem.

 

A Twój blog zyskał kolejnego czytelnika .

Edytowano Lipiec 27, 2013 przez Gość (zobacz historię edycji)

[megi 358]

Pierwszą platformę postawiliśmy na Debianie i jak ruszaliśmy to akurat Etch świeżo wyszedł. Niestety z perspektywy czasu widać, że na Debianie nie da się robić hostingu nowych technologii. On w momencie jak wychodzi jako stable jest już przestarzały. W tym momencie wszystko, co udostępniamy klientom mamy paczkowane na własną rękę i to jest ból. W pewnym wieku i w pewnej skali przestaje cię kręcić kompilowanie ze źródeł, rozwiązywanie problemów z tego wynikających a chcesz, żeby po prostu działało Przez chwilę rozważaliśmy Archa jako alternatywę ale to był głupi pomysł na produkcyjne serwery - świeżość, świeżością, ale nie kosztem stabilności. Arch ma wszystko_wszystko_wszystko najnowsze, nie wydane jeszcze wersje i ogólnie jazda bez trzymanki.

 

Ubuntu wydaje się być takim kompromisem pomiędzy stabilnością a świeżością. Dla nas super rozwiązaniem są PPA - jeżeli klienci chcą nowszej wersji node.js, mongodb itp. to podpinamy PPA z paczkami tego konkretnie oprogramowania. Ktoś, kto prowadzi to repo dba o to, żeby było aktualne. Nierzadko te repozytoria są prowadzone przez producenta oprogramowania. Jeżeli PPA nie jest bezpośrednio od dostawcy oprogramowania to warto się przyjrzeć jak często wychodzą aktualizacje, bo to zdanie się na osoby trzecie może być minusem w przypadku błędów w bezpieczeństwie. Wtedy z aktualizacją czekasz, aż pojawi się w repo załatana wersja.

 

BTW. Jakby komuś przyszło do głowy korzystać z Linux VServer do wirtualizacji (projekt podobny do OpenVZ) to niech tego nie robi. Z perspektywy czasu chyba największa nasza pomyłka. Dobry temat na następny wpis

 

 

 

A Twój blog zyskał kolejnego czytelnika

 

Jupi

[Gość mpm1122]

Dokładnie osiemdziesiąt jeden dni temu wystawiłem niezbyt pozytywną ocenę i skrytykowałem was. Jednak patrząc jak prezentujecie się dziś, myślę że popełniłem ogromny błąd

 

Macie już kolejnego czytelnika Tylko proszę o więcej wpisów

[megi 358]

Tylko jakie są z tego realne korzyści dla końcowego użytkownika?

 

Końcowy użytkownik to klient hostingu?

 

W przypadku zmiany systemu to dla naszych klientów to są też realne zmiany.

 

- chętniej zainstalujemy coś, co jest w PPA niż gdy na własną rękę będziemy musieli to paczkować i się tym opiekować, poza tym możemy częściej robić aktualizację, bo wymagają mniej zachodu. Dzięki temu łatwiej oferować hosting nowych technologi. Mniej pracy dla nas = mniejsze koszty dla klienta.

 

Przez aktualizacje mam na myśli zmiany dużych wersji np. gita z 1.7 do 1.8 - dla stabilnej wersji takie zmiany nie są wypuszczane przez developerów danej dystrybucji. Jak Ubuntu czy Debian wyjdą jako stabilne to już tylko o małe wersje są aktualizacje.

 

- lxc* w takiej formie, w jakiej my je wykorzystujemy, to dla klientów konkretne rozwiązania. Można z tego robić całe VPSy (jak na OpenVZ), ale my używamy tych rozwiązań do wirtualizacji pojedynczych kont. Zamykamy pojedyncze konto w kontenerze - dzięki temu użytkownik ma własną przestrzeń, jest odizolowanych od innych kont, z jego punktu widzenia jest sam na serwerze. To przekłada się na wzrost bezpieczeństwa. Użycie lxc pozwala też nakładać ograniczenia zużycia zasobów na poszczególne konta. Można limitować zużycie pamięci, cpu, dostępu do dysków i parę innych rzeczy zapewniając użytkownikom, że jedno konto nie zajedzie całej maszyny. Przy odpowiednio dobranych limitach można gwarantować konkretne zasoby na hostingu współdzielonym. To są korzyści lxc a nie samego Ubuntu, ale tak, jak pisałam na blogu, wybraliśmy Ubuntu, bo obecnie ma najlepsze wsparcie dla lxc.

 

- jakąś tam korzyścią, ale trochę naciąganą, może być użycie LTSa. Tak, jak wspomniał Archi, terminy wydań Debiana są nieprzewidywalne, nie wiadomo ile dana wersja będzie jeszcze wspierana i ile mamy czasu na migrację. Migracja na hostingu to zawsze jest jazda po bandzie, bo ile różnych klientów, tyle różnych aplikacji, pluginów itp. i tyle różnych potencjalnych problemów. Mając z góry znane terminy możesz sobie zaplanować, przetestować, rozciągnąć w czasie tę migrację.

 

Inna sprawa, że nie wszystko musi być realną korzyścią dla użytkownika końcowego. W tym poście chcieliśmy się podzielić doświadczeniami z punktu widzenia adminów Inspiracją było zapytanie Aliena jakiś czas temu dlaczego przesiadamy się z Debiana na Ubuntu.

 

 

*tak stricte lxc to są narzędzia userspace'owe do zarządzania kontenerami (odpowiednik vzctl i util-vserver), ale w miarę przyjęło się też to określenie na namespaces i cgroups (w połączeniu z userspace'owymi narzędziami ale i same sobie)

Edytowano Lipiec 27, 2013 przez megi (zobacz historię edycji)

[alien 345]

Potwierdzam, lxc wykształciło się w naprawdę fajną technologię. Używamy produkcyjnie od 2009 do sandboxowania pojedynczych kont hostingowych w hostingu współdzielonym. Z początku było jeszcze co nieco niedociągnięć (głównie narzędziowych), ale wszystko poszło w dobrą stronę. Lxc jest fajne, bo jest proste i fajne.

Inna sprawa, że nie wszystko musi być realną korzyścią dla użytkownika końcowego. W tym poście chcieliśmy się podzielić doświadczeniami z punktu widzenia adminów Inspiracją było zapytanie Aliena jakiś czas temu dlaczego przesiadamy się z Debiana na Ubuntu.

 

Bo i inspirująca była sama przesiadka. Ze swej strony miałem duży dystans do serwerowego Ubuntu. Wiem co Ubuntu potrafi zrobić z laptopem, w zasadzie oduczyłem się aktualizować nowych wydań wcześniej niż pół roku po ich wydaniu, bo _zawsze_ coś się psuło. Serwerowy Ubuntu to jednak coś innego, ale człowiek obawia się przełożenia pewnej filozofii funkcjonowania także na gałąź serwerową.

 

A tu MegiTeam przechodzi na Ubuntu i sobie chwali... Więc po jakimś czasie dopytałem czy im to tak naprawdę, naprawdę działa. Jeśli działa i rozwiązuje więcej problemów niż generuje to osobiście zaczynam być przekonany. Zwłaszcza, że zanim sami zmigrujemy (o ile) minie jeszcze sporo czasu i pewnie Megi zdoła zaraportować ewentualne problemy :-).

Edytowano Lipiec 30, 2013 przez alien (zobacz historię edycji)

[Miłosz 2311]

A tu MegiTeam przechodzi na Ubuntu i sobie chwali... Więc po jakimś czasie dopytałem czy im to tak naprawdę, naprawdę działa. Jeśli działa i rozwiązuje więcej problemów niż generuje to osobiście zaczynam być przekonany. Zwłaszcza, że zanim sami zmigrujemy (o ile) minie jeszcze sporo czasu i pewnie Megi zdoła zaraportować ewentualne problemy :-).

U części klientów Ubuntu Server używam od chyba wydania 10.04 LTS. Wszystko śmiga jak należy. Problemów z aktualizacjami nie ma.

[Pan Kot 1535]

Generalnie to zależy od samego systemu. Jeśli się prawidłowo aktualizuje system via ich własne release-upgrade, a nie apt-get'a to problem na ogół nigdy nie ma. P.S. przez apt-get'a też aktualizowałem wielokrotnie i wszystko było cacy.

[megi 358]

Generalnie to zależy od samego systemu. Jeśli się prawidłowo aktualizuje system via ich własne release-upgrade, a nie apt-get'a to problem na ogół nigdy nie ma. P.S. przez apt-get'a też aktualizowałem wielokrotnie i wszystko było cacy.

 

Realising the upgrade involves upgrading Ruby

Ja się boję Cieszyłabym się jakby po release-upgrade wszystko wszystkim klientom działało, ale podejrzewam, że w środowisku w którym ludzie samodzielnie instalują sobie dodatkowe oprogramowanie to nie będzie takie proste.

Edytowano Lipiec 30, 2013 przez megi (zobacz historię edycji)

[elcct 159]

Ubuntu używam od paru lat, z tego co pamiętam ze względu na nowsze paczki - wcześniej używałem Debian (a jeszcze wcześniej wiele innych dystrybucji, ale nie były wygodne).

 

O lxc dziwne, nigdy nie słyszałem - pewnie dlatego, że klientom tworzyłem wirtualizacje KVM zwykle.

 

Możecie coś więcej napisać o lxc jakie są wady i zalety w porównaniu do KVM? (które na Ubuntu jest proste)

[Gość patrys]

KVM to odrębny system, a w LXC masz fajną "klatkę" opartą na kernelu.

 

Linux Containers take a completely different approach than system virtualization technologies such as KVM and Xen, which started by booting separate virtual systems on emulated hardware and then attempted to lower their overhead via paravirtualization and related mechanisms. Instead of retrofitting efficiency onto full isolation, LXC started out with an efficient mechanism (existing Linux process management) and added isolation, resulting in a system virtualization mechanism as scalable and portable as chroot, capable of simultaneously supporting thousands of emulated systems on a single server while also providing lightweight virtualization options to routers and smart phones.

 

 

[megi 358]

Na pierwszym spotkaniu Anonimowych Adminów kolega miał prezentację o LXC właśnie i chyba dzisiaj będziemy mieć gotowe filmy, to podrzucę.

[elcct 159]

Dziękuję

[wygodad 31]

Na pierwszym spotkaniu Anonimowych Adminów kolega miał prezentację o LXC właśnie i chyba dzisiaj będziemy mieć gotowe filmy, to podrzucę.

 

o fajnie, czekamy więc na linki do filmów

[megi 358]

Nagranie jest tutaj

 

http://www.youtube.com/watch?v=69C5dHAFS38

 

A tu są slajdy i artykuł na ich podstawie z zeszłego roku

 

http://www.megiteam.pl/blog/2012/03/12/lxc-kontener-pingwinow/

[T 6]

P.S. Tak, osobiście jestem za debianem i stawiam go gdzie tylko mogę z jednej prostej przyczyny. Wiesz jakiej? Ustawiam sobie sync z gałęzią "testing", unattended-upgrades z powiadomieniami na specjalny e-mail i mam z główki jakąkolwiek przyszłą migrację, zawsze nowe pakiety i czasem tylko wejście na serwer, żeby rozwiązać konflikt nowej aktualizacji, która zresztą też pojawia się dość rzadko.

Tyle, że takie rozwiązanie nadaje się ew. tylko na prywatnego Kimsufi, chociaż osobiście bym go nie stosował nawet w takim miejscu.

[Pan Kot 1535]

Tyle, że takie rozwiązanie nadaje się ew. tylko na prywatnego Kimsufi, chociaż osobiście bym go nie stosował nawet w takim miejscu.

Nie zawsze. Unattended-upgrades bardzo się zmieniły od starych wersji i teraz mają tą zaletę, że symulują update i jeśli nowa wersja wymaga zmiany configów, a takowa zmiana nie może zostać wykonana przez sam system (popularne install new version / keep current / examine situation) to nie ruszają tego pakietu. A szansa, że nowa wersja nie wprowadza nic do configu i coś się rozjedzie tak czy siak jest... bardzo niska.

 

Pewnie, tak jak piszę czym więcej klientów tym większa przepaść, ale naprawdę stosuje taką politykę już od kilku lat, jak jeszcze squeeze był w testing i uwierz mi od tamtego czasu mój serwer do dziś stoi bez żadnych zgrzytów w międzyczasie, czasem sam muszę zmergować nowe configi (jak mam czas) i to tyle, a i owszem stoi tam parę stron nawet produkcyjnych. Trzeba tylko umieć dobrze to skonfigurować . Do dziś myślę jak zaincludować tam gitowy 3-way merge, żeby nawet samemu nie mergować.

Edytowano Lipiec 31, 2013 przez Archi (zobacz historię edycji)