Udostępniony został nowy obraz Ruby on Rails na http://rootbox.com do instalacji jednym kliknięciem. Ze względu że jest on stworzony dla developerów z których wymaganiami się liczymy, chętnie poznamy Wasze opinie i wrażenia z jego wykorzystania. Mam gratisowe doładowania dla osób które chciałby podzielić się z nami swoim doświadczeniem oraz opinią z użytkowania, wystarczy napisać na info@ Na podstawie Waszych opinii obraz będzie odpowiednio modyfikowany dla developerów Ruby on Rails.
@essepl serwery rootbox.com posiadają zasoby dedykowane w odróżnieniu od większości hostingu podobnego typu które bazują na para wirtualizacji (np. OpenVZ, Virtuozzo, etc.). Zasoby które otrzymujesz nie są współdzielone przez innych użytkowników i są dedykowane jedynie dla serwera.
Pisząc o serwerach dedykowanych, zapewne miałeś na myśli serwery fizyczne, których http://rootbox.com nie udostępnia. Zapraszam do rozmowy na irc #rootboxpl, obecnie w przygotowaniu jest informacja na ten temat zatem rozmowa będzie dla nas cenna.
Chętnie poznalibyśmy Twoją opinię dotyczącą udostępnionego obrazu Ruby on Rails który jest tematem tego wątku. Napisz na info@ a prześlemy gratisowe doładowanie.
Zastanawiam się czemu w udostępnionym obrazie macie unicorna (przynajmniej wpisanego) a nie np. puma, przy wielu rdzeniach, efektywność byłaby większa, chyba, że wspomniany obraz dedykowany jest dla planów Developer i Small.
Po drugie nie za bardzo rozumiem sens stawiania testowej aplikacji railsów, która tak naprawdę nic nie ma. W znacznej większości wypadków (jak nie wszystkich) i tak ludzie będą wrzucać swoje aplikacje a nie modyfikować tą istniejącą, “dzięki czemu możesz od razu zacząć tworzenie aplikacji.” aplikację tworzy się zwykle lokalnie a nie odrazu na serwerze. Ale rozumiem, że chcecie w tym obrazie pokazać użytkownikowi że to jednak działa.
Config dla unicorna dałbym wewnątrz aplikacji, bo to jest serwer aplikacji, tak samo logi, przeniósłbym do katalogu z logami aplikacji.
Może inaczej, puma daje większe możliwości od unicorna, a ktoś uruchamiając taki obraz na serwerze raczej na pewno będzie serwer później przystosowywał pod siebie, równie dobrze w tym wypadku można uruchomić w webricka, bo to jest w końcu demonstracyjna aplikacja.
W sumie chyba wiem skąd wybór unicorna, jest on juz domyslnie wpisany w Gemfilu, wprawdzie zakomentowany ale jest. Więc pomijając dywagacje na temat pumy, nie widze większego sensu w ustawieniu unicorna w takiej aplikacji, przynajmniej na tym etapie.
ale to jednak nadal nie jest serwer dedykowany - to wciąż wirtualizacja pewnie bardzo dobra i dająca separację zasobów, ale jednak.
Nie zrozumcie mnie źle: nie ma naprawdę nic złego w dobrych serwerach wirtualnych, trochę jednak nie ma miejscu wydaje mi się nazywać to serwerami dedykowanymi - gdy w ten sposób określa się fizyczne, osobne serwery.
Jakie macie rzeczywiste podejście do większego obciążenia CPU (~30% przez kilkanaście h dziennie)? Pytam o rzeczywiste, bo w teorii nikomu to nie przeszkadza, ewentualnie są jakieś nieostre kryteria ‘dobrego sąsiedztwa’, ale w praktyce różnie to wychodzi. Czy w razie jakichś problemów dostanę najpierw info, że coś jest nie tak i staję się persona non grata (ile czasu wtedy mam na przenosiny), czy ucinacie takie konto bez ostrzeżenia?
Tak jak wcześniej wspominałem w http://rootbox.com zasoby są dedykowane zatem to co kupujesz możesz obciążyć w 100% przez 100% czasu
Czasami możemy się skontaktować jeśli widzimy, że wykorzystanie któryś zasobów odbiega od normy aby upewnić się że są to celowe działania, a nie wynikające na przykład z ataku lub kwestii bezpieczeństwa.
Jeśli ktoś chciałby podzielić się z nami opinią z wykorzystania nowego obrazu z Ruby on Rails, proszę o założenie konta na http://rootbox.com i informację na PW z nazwą konta a doładujemy konto środkami.
Wynajmuję u was dwa serwery wirtualne. Akurat mam pecha i oba trafiły na tę samą fizyczną maszynę (zdarza się). Nagle trach - fizycznę maszynę trafia szlag. Tracę obie wirtualki.
Przypadek podobny - ale mam dwa serwery fizyczne. Jeden z nich trafia szlag - tracę jeden serwer (a nie dwa).
Ależ oczywiście masz rację, to nie są fizyczne serwery, jak już wcześniej pisałem. Tak samo można zapytać czy czy kupując dwa fizyczne serwery będą one w jednej szafie rackowej, podpięte do jednego zasilania, switcha lub czy są w tym samym pomieszczeniu lub nawet centrum danych. Obecnie jak zapewne sam dokładnie wiesz tendencja jest aby kwestie niezawodności rozwiązywać nie na poziomie fizycznym a programowym.
Jednak w kwestii rozdzielania serwerów http://rootbox.com na fizyczne maszyny to scheduler posiada już logikę która stara się zadbać aby jeden klient posiadał swoje serwery na różnych fizycznych maszynach. Także obecnie w labie testowana już jest funkcjonalność ad-hoc i automatycznych backupów bez konieczności wyłączania serwerów, jednocześnie są prowadzone prace nad utrzymaniem backupu w dwóch lokalizacjach. Odzyskanie z backupu maszyny będzie bardzo szybkie. Takie możliwości już niedługo będą dostępne w http://rootbox.com
Natomiast za dłuższą chwilę będzie dostępna funkcjonalność która pozwoli na replikowanie on-line serwera na inną fizyczną maszynę, co pozwoli w opisywanym przykładzie na szybkie przełączenie. Wcześniej jednak kilka innych nowych ciekawych funkcjonalności
Hypervisor zapewnia gwarancje oraz QoS zasobów, jednak nie mylmy tego z serwerem fizycznym. Choć należy pamiętać że serwery fizyczne coraz częściej oferowane przez centra danych nie są pojedynczymi maszynami, a “krowami” które współdzielą liczne komponenty, szyny, dyski, etc.
Do dalszej dyskusji zapraszam na irc #rootboxpl, natomiast @Tomash & @essepl zapraszam do założenia konta na http://rootbox.com i zapoznania się z nowym obrazem Ruby on Rails który jest tematem wątku. Po założeniu kont proszę o informację na PW a doładujemy konta środkami, założenie konta nie wymaga dokonywania płatności.
@gb1 obawiam sie ze obraz w tym przypadku to rozwiazanie tak nowoczesne, jak Polonez Kombi Jesli chcecie przekonac ludzi, to polecam wziac przyklad z dokumentacji DigitalOcean, powinniscie napisac tutorial, w jaki sposob stworzyc poprawnie srodwisko do deploymentu railsow uzywajac np Ansible, a kod umiescic w githubowym repo z Vagrantfile, tak by kazdy mogl to sobie odpalic.
To Wy pierwsi zaczęliście używać słowa “dedykowany” do określenia wirtualek więc nie dziw się wytykaniu błędu (który, co gorsza, z Twoich wypowiedzi wygląda na w pełni świadomą manipulację).
Zacząłeś wątek na forum to dyskutujemy na forum. Jeśli wolisz rozmawiać na ircu to guzik wylogowania znajdziesz po wejściu na swój profil.
Jak trafnie zauważyłeś obraz zawiera podstawowe środowisko Ruby on Rails, wykorzystujące bardzo podobne mechanizmy i narzędzia jak przywołany przez Ciebie obraz dostępny w DO. Natomiast właśnie poprzez poznanie potrzeb developerów Ruby on Rails chcemy go modyfikować lub tworzyć nowe bardziej dopasowane do różnych potrzeb. W kwestii narzędzi do deployment’u otrzymaliśmy już kilka bardzo konstruktywnych sugestii na PW lub od osób które pozwoliły sobie na przetestowanie obrazu. Dziękuję także za twoją ciekawą opinię.
Tutoriale są na pewno bardzo ciekawe dla początkujących, zatem zapraszamy do ich tworzenia, wynagrodzimy to przelewem lub konkretnym doładowaniem środków na http://rootbox.com, zapraszam na info@ z Waszymi propozycjami.
w przypadku DigitalOcean są nie tyle ‘ciekawe’, co kierują masę ruchu na ich stronę (który się podobno dobrze konwertuje) - przynajmniej tak twierdzi jeden z wspołzałożycieli w niedawnym wywiadzie.
Kulawy marketing + kłamanie na głownej stronie (możecie mówić co najwyżej o dedykowanym hostingu, ale na pewno nie o serwerach) nie wróży niczego dobrego.
Policzcie może, ile razy na stronach Digital Ocean pojawia sie fraza ‘dedicated server’ i zastanówcie się, dlaczego z rozmyslem promują hasło ‘SSD Cloud Server’
Póki co wyglądacie na ‘szemraną wersję Digital Ocean’, która jest droższa. Poprawcie przekaz - taka moja konkretna propozycja.
pewnie bardzo dobra i dająca separację zasobów, ale jednak.