Page 104 of 169

Migracja z Rails 3.0.9 do Rails 3.1 RC5

August 13, 2011 /

Wstęp

Na fali RC5 nowych Railsów (3.1), postanowiłem zmigrować doń Susanoo (CMS pod Senpuu v5). Było to moje drugie podejście do przenosin. Pierwsze (jeszcze bodajże przed RC1) zakończyło się porażką. Głównie ze względu na to, że logika pod v5 nie była skończona i na przenosiny nie miałem zbyt dużo czasu.

Aktualne podejście na szczęście skończyło się dużo lepiej. Działa całość kodu i testów, jedyne problemy jakie występują (ale już niedługo), to niekompatybilność mojego gemu do osadzania obrazków w kodzie CSS (CSS image embedder). Nie powinno być z tym jednak większych problemów, ponieważ nowe Railsy umożliwiają wbicie się w Pipeline.

Wracając jednak do sedna sprawy, bardzo pomógł mi wpis Davida Rice'a dot. właśnie migracji. Duża część poniższych porad pochodzi właśnie z jego bloga.

Gemfile

Pierwszą rzeczą jaką musimy zaktualizować jest Gemfile w którym dodajemy (lub zamieniamy jeśli mieliśmy starsze wersje) następujące gemy:

gem 'rake', '~> 0.9.2'
gem "rails", "3.1.0.rc5"
gem 'mysql2', '0.3.6'
gem 'json'
gem 'sass'
gem 'coffee-script'
gem 'uglifier'
gem "sprockets", :git => 'https://github.com/sstephenson/sprockets.git'
gem 'jquery-rails'
gem "meta_search", '1.1.0.pre'
gem 'kaminari'
gem 'dynamic_form'
gem 'execjs'
gem 'therubyracer'

Oczywiście jest to kawałek gemfile'a z Susanoo, więc jeśli nie korzystacie z któregoś z gemów, to nie dodawajcie go do gemfile'a. Warto też pamiętać o tym, aby zaktualizować gemy (w miarę możliwości) do najnowszych wersji. Na przykład Mysql2 musi być z brancha 0.3.* aby współpracował z Railsami 3.1 (wersja RC5 wymaga wersji 0.3.6 mysql2).

config/boot.rb

Następnym krokiem jest zmiana pliku boot.rb. Usuwamy starą zawartość i wklejamy to co jest poniżej:

require 'rubygems'

# Set up gems listed in the Gemfile.
ENV['BUNDLE_GEMFILE'] ||= File.expand_path('../../Gemfile', __FILE__)

require 'bundler/setup' if File.exists?(ENV['BUNDLE_GEMFILE'])

application.rb

Po pierwsze na początku tego pliku dajemy:

require 'rake/dsl_definition'

Po drugie (to ważna decyzja!) jeśli nie chcemy korzystać z assetsów, tylko mieć (jak w 3.0) wszystkie JSy, Imgi i CSSy w public/ wpisujemy:

config.assets.enabled = false

W przeciwnym wypadku (app/assets), wpisujemy:

config.assets.enabled = true

Initializers

Jeśli korzystaliśmy z Sassa - usuwamy jego initializer (sass:plugin). Tak samo robimy ze wszystkimi innymi które nie są już potrzebne (bądź są niekompatybilne).

Routes w kilku plikach

W jednym z poprzednich wpisów, pokazywałem jak rozłożyć routsy w logiczny sposób. Jeśli uruchomimy nowe Railsy, zobaczymy taki oto warning:

DEPRECATION WARNING: 
config.paths.app.controller API is deprecated 
in favor of config.paths["app/controller"]

Aby go usunąć, zmieniamy linijkę:

config.paths.config.routes << route_file

na następującą:

config.paths['config/routes'] << route_file

ActionMailer

Kolejny warning będzie następujący:

DEPRECATION WARNING: content_type= is deprecated. 
Please pass :content_type as hash key to mail() instead.

Jego likwidujemy usuwając taki (lub podobny wpis) z pliku application.rb:

ActionMailer::Base.content_type = "text/html"

Assets - Pipeline

Jeśli nie włączyłeś assetsów - w tej chwili możesz odpalić swoją aplikację na Rails 3.1 RC5 :)
Jeśli jednak skusiła Cię wizja SCSSa i CoffeScriptu musisz wszystko przenieść do katalogu app/assets. Ja wybrałem trochę łatwiejszą drogę. Przeniosłem Javascripty i SCSSa, pozostawiłem jednak w katalogu public/assets wszystkie obrazki. Z niewiadomego dla mnie powodu, przeniesienie obrazków skutkuje baardzo powolnym ładowaniem się strony w trybie deweloperskim. Jak tylko sytuacja ta zostanie rozwiązana, nic nie stoi na przeszkodzie aby i obrazki leciały przez pipe'a.

# Przenosiny
mkdir app/assets
git mv public/images /assets
git mv public/javascripts app/assets/javascripts
git mv public/stylesheets app/assets/stylesheets

config/environments/production.rb

Dwie opcje dla produkcji (config/environments/production.rb):

config.assets.js_compressor  = :uglifier
config.assets.css_compressor = :scss

Ścieżki (referencje) do obrazków

Jak nietrudno się domyślić, wszelkie referencje wskazujące na /images/ nie będą działać. Z tego względu musimy zamienić w naszych plikach css/scss:

# Zamieniamy:
/images/
# Na:
/assets/

Manifesty dla plików CSS i JS

W manifeście umieszczamy informacje o tym jakie pliki mają zostać połączone w jeden, który zostanie zaserwowany klientowi.
Przykład dla JSa:

// This is a manifest file that'll be compiled into including all the files listed below.
// Add new JavaScript/Coffee code in separate files in this directory and they'll automatically
// be included in the compiled file accessible from http://example.com/assets/application.js
// It's not advisable to add code directly here, but if you do, it'll appear at the bottom of the
// the compiled file.
//
//= require jquery
//= require jquery_ujs
//= require_tree .

i wersja dla CSSa:

/*
 * This is a manifest file that'll automatically include all the stylesheets available in this directory
 * and any sub-directories. You're free to add application-wide styles to this file and they'll appear at
 * the top of the compiled file, but it's generally better to create a new file per style scope.
 *= require_self
 *= require_tree . 
*/

Warto pamiętać, że ścieżki podajemy od roota assetsów, czyli przykładowo

//= require "layouts/admin/costam.js"

W przypadku SCSSów możemy korzystać z dyrektywy @import. Musimy jednak pamiętać, że ścieżka będzie względna w stos. do położenia naszego pliku.

Dołączanie arkuszy styli do kodu

<%= stylesheet_link_tag    "sciezka/manifest" %>
<%= javascript_include_tag "sciezka/manifest" %>

Podsumowanie

To by było na tyle. Na pierwszy rzut oka wydaje się to proste, jednak jeśli mamy dużo stylów, plików JS oraz rzeczy "pobocznych" w jakiś sposób z nimi powiązanych, przeniesienie może nie być zbyt łatwe. Może okazać się też, że część gemów z których korzystamy nie jest kompatybilna z R3.1. Warto też zdawać sobie sprawę, że bez solidnego obłożenia kodu testami - taka zmiana może źle się dla nas skończyć. Taka zmiana jest też dobrą okazją do refaktoryzacji i uprzątnięcia kodu - a więc, do dzieła!

Problemy

Z poważniejszych to mam póki co jeden który występuje tylko w środowisku produkcyjnym, mianowicie taki oto piękny error:

cache error: File name too long - /home/blabla/sciezka/tmp/cache/http%3A%2F%2Flocalhost%3A3001%2Fassets%2Flayouts%2Fadmin%2Fdefault%2Fmodule%2Fads-190528e5830bd4c5019cd4da9bcdbfdb.css%3F20110812-2214-j2m5kl.lock

Wygląda na to, że nie do końca dobrze tworzone są nazwy w cache'u. Pożyjemy zobaczymy - widziałem już gdzieś po drodze ticket, tak więc ekipa jest świadoma błędu. Pewnie niedługo naprawią.

Podstawy loadbalancingu – nginx + thin (backend, frontend)

August 6, 2011 /

Wstęp

Ostatnimi czasy przyszło mi pracować nad dość zasobożerną aplikacją. Nie wdając się w szczegóły, podzielona jest ona na frontend i backend. Frontend (jak sama nazwa wskazuje) odpowiada za generowanie tego co widzi użytkownik. Backend służy zaś do komunikacji poszczególnych fragmentów systemu oraz za przetwarzanie i gromadzenie danych. Aktualnie w czasie pracy - średnio obciążony system generuje około 10-40 żądań na sekundę na backendzie. Przód zasadniczo nie jest aż tak obciążony. Warto jednak mieć na uwadze to, że aplikacja ta jest w fazie beta i ilość użytkowników jest mocno ograniczona. W związku z tym skalowalność jak najbardziej mile widziana :)

Load balancing

Aby utrzymać wysoką wydajność i responsywność tejże aplikacji, zdecydowałem się na wykorzystanie load balancingu. Czym jest load balancing? Za wikipedią:

Równoważenie obciążenia (ang. load balancing) - technika rozpraszania obciążenia pomiędzy wiele procesorów, komputerów, dysków, połączeń sieciowych lub innych zasobów.

Przykładowy system load balancing mógłby zapewniać bezawaryjną i optymalną pracę na N-aplikacjach znajdujących się na bliźniaczych M-serwerach (zawierających równoważne aplikacje). Podczas gdy wielu użytkowników wysyła wiele żądań, trafiają one najpierw do SLB, który analizuje obciążenie na poszczególnych M-serwerach. Następnie dokonuje optymalnego wyboru - odsyłając użytkownika do jednego z serwerów do konkretnej aplikacji - według żądania.

W moim wypadku zasobem jest instancja Thina. Rozkład obciążeń ma u mnie "zrównoleglić" przetrwarzanie tak, aby dane napływające przez API nie musiały "czekać" aż konkretna instancja Thina skończy przetwarzać poprzednie informacje. Dodatkowo chciałem odseparować jak najbardziej wpływ backendu na frontend. Wszelkie "zasobożerne" obliczenia zamykają się w mocniejszej z maszyn, zaś na świat wystawiona jest ta "lżejsza". Dodatkowo cała komunikacja między-serwerowa leci po vlanie.

nginx

Jako load balancer wybrałem nginx'a ponieważ jest lekki, szybki i wykrywa jak któryś z thinów jest niedostępny (np. padnie). Jego konfiguracja aby działał jako proces do równoważenia obciążeń nie stanowi większego problemu. Całość konfiguracji wykonujemy w przestrzeni http:


http{
# Konfiguracja
}

Zacznijmy od zdefiniowania sobie tego gdzie znajdują się nasze instancje thinów. Load balancer stoi na maszynie pierwszej, tam gdzie frontend. Dlatego też odwołujemy się do serwerów leżących na nim poprzez localhost:

    upstream frontends {
        server localhost:3001;
        server localhost:3002;
        server localhost:3003;
    }

    upstream backends {
        server serwer2:3001;
        server serwer2:3002;
        server serwer2:3003;
        server serwer2:3004;
        server serwer2:3005;
        server serwer2:3006;
    }

Oczywiście zamiast nazwy zdefinowanej w hostach (server2), możemy wskazywać bezpośrednio na IP i port, np: 192.168.1.10:3001. Porty zostały wybrane ze względów sentymentalnych i nie mają wpływu na działanie nginxa (no chyba że wpiszemy adres pod którym nic nie ma).

Dalej ustawiamy (bądź nie) kilka opcji związanych z timeoutami i gzipem:

    include       mime.types;
    default_type  application/octet-stream;

    keepalive_timeout 165;
    proxy_read_timeout 400;
    sendfile on;
    tcp_nopush on;
    gzip on;
    gzip_min_length 1000;
    gzip_proxied any;

    proxy_next_upstream error;

Ich dokładny opis można znaleźć np. w dokumentacji do nginxa.

Dalej musimy ustalić które żądania (skąd przychodzące) mają być realizowane przez którą z maszyn (frontend czy backend). Zajmijmy się najpierw backendem:

    server {
        listen 192.168.1.3:81;
        server_name server2;

        client_max_body_size 5M;

        location / {
            proxy_pass_header $server;
            proxy_set_header Host $http_host;
            proxy_redirect off;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Scheme $scheme;
            proxy_pass http://backends;
        }

    }

Ustawiamy nasłuch (192.168.1.3:81), kilka innych parametrów i najważniejsze czyli proxy_pass który przekierowywać będzie żądania na zdefiniowany przez nas upstream. To samo robimy dla frontendu:

    server {
        listen 192.168.1.2:80;
        server_name jakasnazwa;

        client_max_body_size 5M;

        location / {
            proxy_pass_header $server;
            proxy_set_header Host $http_host;
            proxy_redirect off;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Scheme $scheme;
            proxy_pass http://frontends;
        }
        
        error_page 502 /502.html;  
        location = /502.html {  
            root  /home/sciezka/error_templates;  
        }  

	error_page 500 /500.html;  
        location = /500.html {  
            root  /home/sciezka/error_templates;
	}
        error_page 404 /404.html;  
        location = /404.html {  
            root  /home/sciezka/error_templates;  
        }

    }

Jedyną różnicą jest ustawienie stron błędów tak aby były ustawiane przez nas. Na backendzie jest to zbędne, jednak tutaj w przypadku downtime'u miło byłoby móc powiadomić użytkowników wyświetlając stosowną stronę z komunikatem.

Na sam koniec ustawiamy nasłuch samego nginxa na świat:

    # Nginx status
    server {
      listen 80;
      server_name localhost;
      location /nginx_status {
        stub_status on;
        access_log off;
        allow 127.0.0.1;
        deny all;
      }   
    }

I możemy działać :)

Copyright © 2025 Closer to Code

Theme by Anders Noren — Up ↑