Page 136 of 164

Przygotowanie kodu aplikacji w Ruby on Rails do deployu – część I

Każdy z Was spotkał się kiedyś na pewno, z problemem przygotowania aplikacji do deployu (umieszczenia na serwerze). Lista rzeczy które trzeba zrobić nie jest duża, ale obejmuje m.in.:

  • Wyczyszczenie cachey, tempów i innych nie potrzebnych plików
  • Usunięcie katalogów repozytoriów (czy to git czy też svn)
  • Usunięcie testów
  • Usunięcie innych plików związanych ze środowiskiem developerskim bądź testowym
  • Ew. "zaciemnienie" kodu

Mówiąc "zaciemnianie" nie mam na myśli stricte obfuscacji. Railsy są środowiskiem gdzie wszystko ma być (i jest) czytelne i przejrzyste. Jednak każdemu z nas (mi na szczęście niezmiernie rzadko) trafiają się klienci którzy chcą mieć aplikacje u siebie.

O ile problem przeniesienia kodu dalej (czyli wyciek) można ograniczyć przy pomocy dobrze napisanej umowy licencyjnej, o tyle "zabaw" z kodem - w wykonaniu klienta już raczej nie.

Dlatego wpadłem na pomysł że "zaśmiecę" kod aplikacji, dużą ilością komentarzy które albo będą wygenerowanymi losowo ciągami znaków, albo kawałkami kodu z innych fragmentów aplikacji. W ten sposób - trzeba będzie się przedrzeć przez gąszcz komentarzy i chaosu aby coś nabrudzić.

Oczywiście nie zabezpieczy to kodu przed osobami które chcą, jednak większość "grzebaczy" widząc takie rzeczy po prostu zrezygnuje z dalszego kombinowania.

Aby uprościć sobie życie, napisałem krótki (300 linijek) skrypt który przygotowuje "minimalistyczną" wersję kodu, na potrzeby wrzucenia na produkcję. Poniżej pokażę Wam jak stworzyć swoją wersję takiego pliku.

Pierwszą rzeczą jaką zrobimy, jest dołączenie do naszego pliku deploy.rb odpowiednich dowiązań. Potrzebujemy biblioteki find do wylistowania plików oraz biblioteki fileutils aby coś z tymi plikami zrobić. Tak więc:

# coding: utf-8
require 'find'
require 'fileutils'

# Skrypt automatyzujący deployment aplikacji
# Usuwa sensowne komentarze, robi taki bałagan w kodzie ;)
# Usuwa to czego klientowi na produkcji nie potrzeba
# Sprzata, czysci i pozostawia absolutne minimum

Dodaliśmy także "magiczny" komentarz mówiący że być może będziemy korzystać z utf-8. Jest to ważne dla Rubiego 1.9.2 i wzwyż. Dodaliśmy także komentarz co nasz skrypt robi.

Mając to minimum, teraz musimy zdefiniować w postaci stałych, co ma być zaciemnione, co usunięte, itp.
Najprościej, tak jak wspomniałem, jest zrobić to w stałych. Zdefiniujmy sobie listę katalogów, z których pliki mają zostać "zaciemnione":

# Które katalogi ma "zaciemniać"
MASK_DIRS = [
  './deploy/app/models',
  './deploy/app/controllers/',
  './deploy/app/mailers/',
  './deploy/db/',
  './deploy/lib/',
  ]

Które katalogi ma usunąć:

# Które katalogi i pliki mają zostać usunięte (ktore nie są potrzebne klientowi)
# Przy okazji usuwa wszystkie katalogi i pliki takie jak temp, cache, .svn
CLEAR_ELEMENTS = [
  './deploy/config/environments/development.rb',
  './deploy/config/environments/test.rb',
  './deploy/db/migrate',
  './deploy/doc',
  './deploy/log',
  './deploy/nbproject',
  './deploy/test',
  './deploy/README',
  './deploy/deploy.rb'
]

I ostatnie, wyrażenia regularne. Niezależnie gdzie dany katalog się znajduje, jeśli będzie zgodny ze wzorcem, to zostanie usunięty:

# Nazwy katalogów i plików tymczasowych które mają zostać usunięte
CLEAR_REGS = [
  'temp',
  'tmp',
  'cache',
  '.svn',
  '.git'
]

Zanim przejdziemy dalej, musimy wyjaśnić sobie jedną rzecz. Czym jest subkatalog "deploy" który przewija się w ścieżkach? Otóż jak zobaczycie dalej, nasz skrypt będzie odpalany z głównego katalogu naszej aplikacji. Jednak aby niczego nie zepsuć czy nie usunąć przez przypadek, do celów deployu wykonamy sobie kopię całego systemu, która trafi właśnie do subkatalogu "deploy/". To właśnie na tej kopii będziemy wykonywać operacje zaciemniania oraz usuwania. Dzięki temu w razie wybrania złych katalogów do usunięcia (załóżmy katalogu lib), nie stracimy ważnych kodów źródłowych.

Warto tutaj wspomnieć że o ile będziemy sterować maskowaniem i usuwaniem plików, o tyle oryginalne komentarze zostaną usunięte z każdego pliku z rozszerzeniem rb.

Zajmijmy się więc naszym "backuperem". Jego zadaniem będzie zrobienie kopii całego systemu do katalogu "deploy/". Jeśli taki katalog istniał, zostanie on usunięty a na jego miejsce zostanie przekopiowana aktualna wersja systemu.

  # Robi kopię "deploymentową" do katalogu /deploy/ w aplikacji
  class Backuper
    def self.run
      deploy = './deploy/'
      if File.directory?(deploy)
        puts "Removing old deployment..."
        FileUtils.rm_rf(deploy)
      end

      files = Dir.glob('*')
      FileUtils.mkdir 'deploy'
      puts "Creating new deployment..."
      FileUtils.cp_r files, 'deploy'
    end
  end

Tutaj za bardzo nie ma co tłumaczyć. Sprawdzamy czy istniał katalog, jeśli tak to go usuwamy. Następnie pobieramy listę plików i katalogów naszego systemu i kopiujemy go do deploy/.

Proste, skuteczne i szybkie :)

Kolejnym modelem jakiego potrzebujemy, jest "cleaner". Model usuwający wszystkie pliki które są dla nas, nie dla klienta. Działa on dwuetapowo. Pierwszym etapem jest usunięcie plików "regularnych", czyli tych z CLEAR_ELEMENTS. Robi się to bardzo prosto. Jeśli ścieżka jest katalogiem, to usuń katalog. Jeśli to plik, usuń plik:

      # Najpierw usuń "stałe" elementy
      CLEAR_ELEMENTS.each{ |e|
        # Jeśli to katalog to go usun
        if File.directory?(e)
          puts "Removing: #{e}"
          FileUtils.rm_rf(e)
        end
        # Jesli plik to tez usun ;)
        if File.exists?(e)
          puts "Removing: #{e}"
          File.delete(e)
        end
      }

Drugim etapem jest usunięcie regularnych. Tutaj po prostu porównujemy nazwę katalogu/pliku z nazwą zawartą w CLEAR_REGS. Jeśli pasują, to usuwamy. Dodatkowo "odtwarzaniu" podlegają katalogi "tmp". Są one czyszczone, jednak sam katalog pozostaje. Zrobiłem tak dlatego że część moich testów wymaga by ten katalog istniał. Jeśli nie macie testów tego typu, możecie się bez tego obejść. Kod przeszukuje całą strukturę, katalog po katalogu, razem z subkatalogami.

      # Teraz elementy regexpowe, czyli jakies tam katalogi
      # ktore moga byc w roznych miejscach
      CLEAR_REGS.each{ |r|
        Find.find('./deploy/') { |f|
          name = f.split('/').last
          if name ==  r
            if File.directory?(f)
              puts "Recreating: #{f}"
              FileUtils.rm_rf(f)
	      # tmp odtwórz bo testy nie zostaną zakonczone pomyslnie (kwestia np resetu passengera w tmp)
              FileUtils.mkdir f if f.split('/').last == 'tmp'
            end
          end
        }
      }

Powyższy kod "obudujemy" w naszą klasę:

  # Usuwa to, czego klient nie potrzebuje
  class Cleaner
    def self.run
      # Najpierw usuń "stałe" elementy
      CLEAR_ELEMENTS.each{ |e|
        # Jeśli to katalog to go usun
        if File.directory?(e)
          puts "Removing: #{e}"
          FileUtils.rm_rf(e)
        end
        # Jesli plik to tez usun ;)
        if File.exists?(e)
          puts "Removing: #{e}"
          File.delete(e)
        end
      }

      # Teraz elementy regexpowe, czyli jakies tam katalogi
      # ktore moga byc w roznych miejscach
      CLEAR_REGS.each{ |r|
        Find.find('./deploy/') { |f|
          name = f.split('/').last
          if name ==  r
            if File.directory?(f)
              puts "Recreating: #{f}"
              FileUtils.rm_rf(f)
	      # tmp odtwórz bo testy nie zostaną zakonczone pomyslnie (kwestia np resetu passengera w tmp)
              FileUtils.mkdir f if f.split('/').last == 'tmp'
            end
          end
        }
      }
    end
  end

Tyle w części pierwszej. W części drugiej zajmiemy się stworzeniem "śmieciarza" który będzie nam "brudził" nasze pliki. Nasz skrypt już spisuje się całkiem nieźle:

  • Wykonuje kopię naszego projektu
  • Usuwa wszystkie niepotrzebne pliki

Tutaj możesz zobaczyć pozostałe części tutoriala:

Rails3 + własne dynamiczne strony błędów (404 i 500)

Uwaga! - kod ten działa TYLKO dla Railsów3.
Opis "starego" routingu błędów dostępny tutaj.

Migrując Susanoo na Rails 3.0.0 okazało się że poprzez zmiany w middleware i obsługę błędów w inny sposób - mój system zarządzania renderowaniem błędów nie działa.Szczerze mówiąc niezbyt mnie to martwiło, ponieważ nie był on "aż tak" fajny. Korzystając z okazji (czyt. nie mając wyjścia) zacząłem googlać za sposobami rozwiązania tego problemu. Metody takie jak

rescue_action_in_public
rescue_action_locally

przestały działać.Pierwszą myślą jaka mi się nasunęła, było obsługiwanie błędów przerzucając "złe trafienia" po routsach do kontrolera błędów

match ':action', :to => "errors#index"
match '*anything', :to => "errors#index"

niestety rozwiązanie takie miało jedną wielką wadę - nie obsługiwało internal server error'ów. Błędy 404 mogłem za jego pomocą obsługiwać, jednak w wypadku wystąpienia 500 - nic z tego. Dodatkowo takie rozwiązanie nie działało w wypadku zgłoszenia wyjątkuActiveRecord::RecordNotFound.Nie było więc wyjścia ;) trzeba było napisać własny plugin. Poniżej opiszę jak działa, a tymczasem dla niecierpliwych link do githuba:
http://github.com/mensfeld/custom_errors_handler.

W README jest dokładnie opisane jak go wykorzystać, jednak tutaj wspomnę dla pewności:

  • wrzucamy dop vendor/plugin
  • tworzymy 404.erb, 500.erb w views danego kontrolera/modułu lub w views kontrolera/modułu ale w subkatalogu "layouts"
  • reset serwera
  • "sztuczne" bądź też prawdziwe wygenerowanie 404/500
  • ?
  • profit ;)

A teraz omówienie pluginu.

Cała zabawa w utworzenie tego typu pluginu, polegała na “przejęciu” błędów z ActionDispatch::ShowExceptions. Można to było zrobić, nadpisując metodę render_exception.

Jak widać poniżej, sam kod nie jest wielki. Przechwytuje on błędy i przekazuje je do kontrolera CustomErrorsHandler gdzie nastąpi rozpoznanie błędu i wyrenderowanie odpowiedniego szablonu.

module ActionDispatch
  class ShowExceptions
    private
      def render_exception_with_template(env, exception)
        body = CustomErrorsHandlerController.action(rescue_responses[exception.class.name]).call(env)
        log_error(exception)
        body
      rescue
        render_exception_without_template(env, exception)
      end

      alias_method_chain :render_exception, :template
  end
end

Skoro mamy już przekazywanie błędów, przejdźmy do kontrolera który się tym zajmuje. Jest to CustomErrorsHandlerController.

Obsługuje on 3 rodzaje błędów:

  1. :internal_server_error (500)
  2. :not_found (404)
  3. :unprocessable_entity (403)

Korzysta także z 3 metod pomocniczych:

  1. error_layout
  2. template?
  3. translate_error

Zanim opiszę kod odpowiedzialny za działanie, opiszę każdą z tych metod.

Pierwszą będzie translate_error:

  def translate_error(e)
    case e
    when :internal_server_error then '500'
    when :not_found then '404'
    when :unprocessable_entity then '500'
    else '500'
    end
  end

Metoda ta zwraca "liczbowy" odpowiednik danego błędu. Potrzebujemy tego, ponieważ w naszych szablonach nie chcemy używać szablonuinternal_server_error.erb ale raczej 500.erb.

Druga czyli template? zwraca nam informację czy dany plik szablonu istnieje. Ścieżkę podajemy zaczynając od widoków, czyli nie app/views/jakis_kontroler/, ale /jakis_kontroler/. Kod tej metody jest dość prosty:

  def template?(template)
    FileTest.exist?(File.join(Rails.root, 'app', 'views', "#{template}.erb"))
  end

Ostatnią metodą jest error_layout. Odpowiada ona za znalezienie szablonu błędu, przeszukując strukturę katalogów, zaczynając od ścieżki "najgłębszej", stopniowo idąc wyżej w hierarchii katalogów.

  def error_layout(path, e)
    e = <strong>translate_error</strong>(e)
    path= path.split('/')
    path.size.downto(0) do |i|
      VALID_ERRORS_SUBDIRS.each { |lay_path|
        template_path = File.join((path[0,i]).join('/'), lay_path, e)
        return template_path if template?(template_path)
      }
      template_path = File.join(path[0,i], e)
      return template_path if template?(template_path)
    end
    e
  end

Metoda ta przyjmuje dwa argumenty - pierwszym z nich jest path. Path jest ścieżką skąd wywołany był błąd. Czyli przykładowo: jeśli błąd wystąpił w kontrolerze MyTest w module Samples (Samples::MyTest), w akcji index, to będzie następujący:

/samples/my_test/index

Parametr e jest to nazwa błędu, którą następnie tłumaczymy naszą metodą translate_error.

Mając ścieżkę rozbijamy ją tak, aby mieć jej kolejne "stopnie".

    path= path.split('/')

Następnie "przelatujemy" całą strukturę sprawdzając takie katalogi (w kolejności):

/samples/my_test/index/layouts
/samples/my_test/index
/samples/my_test/layouts
/samples/my_test/
/samples/layouts/
/samples/
layouts

Skąd się wzięło "layouts"? Otóż w stałej VALID_ERRORS_SUBDIRS mamy zdefiniowane podkatalogi katalogów które sprawdzamy, tak by sprawdzić także je. Dzięki temu, layouty błędów możemy umieszczać w podkatalogach layouts danych kontrolerów/modułów, nie zaś w katalogach głównych.

Zdefiniowane jest to jako stała, ponieważ może ktoś z Was zapragnie mieć inne podkatalogi na błędy (np podkatalog errors). Wtedy wystarczy sobie takowe dopisać.

Następnie łączymy ścieżkę oraz kod błędu i sprawdzamy metodą template? czy taki szablon istnieje. Odpowiada za to, ten fragment kodu:

      VALID_ERRORS_SUBDIRS.each { |lay_path|
        template_path = File.join((path[0,i]).join('/'), lay_path, e)
        return template_path if template?(template_path)
      }
      template_path = File.join(path[0,i], e)
      return template_path if template?(template_path)

Na samym końcu, jeśli żaden z naszych "dynamicznych" 404/500 nie został znaleziony, zwracamy standardowy 404/500. Skutkuje to wyrenderowaniem layoutu znajdującego się w /public.

To by było na tyle. Jeśli chodzi o testy do tego pluginu, to nie bardzo wiem jak przetestować ActionDispatch::ShowExceptions. Jeśli ktoś z Was to potrafi, prosiłbym o kontakt.

Copyright © 2024 Closer to Code

Theme by Anders NorenUp ↑