Witam, chciałbym używać capistrano wraz z dodatkiem multistage. Ustawiam:
set :stages, %w(production testing development)
set :default_stage, "development"
require "capistrano/ext/multistage"
Odpalam np: cap development deploy:restart, niestety zmienna stage nie jest ustawiona. Kolejne stejdże różnią sie właściwie tylko bazą danych oraz suffixem stage, dlatego chciałbym móc użyć w kodzie np. czegoś takiego :
set :deploy_to, "#{dir}projects/mojprojekt-#{stage}"
Jeszcze jedno pytanie, czy mógłby mi ktoś rozjaśnić co daje ustawienie tych zmiennych
role :app, application
role :web, application
role :db, application, :primary => true
Czy są to fizyczne adresy servera czy tez bazy danych ?
W tym momencie nie mam tego ustawionego, mam za to taki wpis
server "smart.megiteam.pl", :app, :web, :db, :primary => true
namespace :deploy do
desc “Restarts the application”
task :restart do
run “restart-app #{ application }”
end
end
seban@vk1008:~/apps/mratemymodel/current$ cat config/deploy.rb
set :application, “mratemymodel”
set :repository, “ssh://seban@sebastiannowak.net/home/seban/www/gits/mratemymodel”
set :deploy_to, “/home/seban/www/apps/#{application}”
set :scm, :git
set :user, “seban”
set :use_sudo, false
role :app, “sebastiannowak.net”
role :web, “sebastiannowak.net”
role :db, “sebastiannowak.net”, :primary => true[/code]
To u mnie dziala, w ubieglym tygodniu na takich ustawieniach wypychalem aplikacje na megiteam. Ale nie obejmuje to multistage.
dzięki, wrzuciłem jednak konfigi dla stageów do osobnych pików w /deploy, żeby móc odpalac np. tak: cap development deploy:restart.
Aha, bez linijki o której wspominałem wyżej
ssh_options[:forward_agent] = true
task restart działa ok, ale już pełny deploy zwraca
[xxxx.megiteam.pl] executing command
** [xxxx.megiteam.pl :: err] Permission denied, please try again.
** [xxxx.megiteam.pl :: err] Permission denied, please try again.
** [xxxx.megiteam.pl :: err] Permission denied (publickey,password).
** [xxxx.megiteam.pl :: err] fatal: The remote end hung up unexpectedly
Klucz jest w authorized_keys. Dziwne, ale grunt że działa.
Nie rozumiem tylko czemu jeśli ustawie np :app i :db różne to take restart próbuje odpalić na obu mimo że ten task ma :role => :app
Pytanie może bardziej związane z gitem niż Capistano. Czy są jakieś przeciwwskazania żeby wrzucać vendor/plugins do gita i stamtąd je później pobierać ? Czy może powinny być one instalowane recznie lub jakoś inaczej na produkcji i stage ?
Tutaj http://charlesmaxwood.com/deployment-with-capistrano/ pod koniec jest task dla gemów, jest coś podobnego dla pluginów ?
Jeśli nie będziesz trzymał pluginów w gicie, spowoduje to przede wszystkim, to że na produkcji i każdej maszynie deweloperskiej będziesz musiał instalować te pluginy, a dodatkowo możesz wystąpić, to że wszędzie zainstalujesz inną wersję pluginu. I któregoś dnia się okazuje, że na produkcji masz nowszą, inaczej działającą wersję pluginu, niż u siebie, albo nawet nie masz jakiegoś z nich. To są wady.
Zalet żadnych to nie ma, czyli katalog vendor jak najbardziej powinien być w gicie. Ogólnie poza takimi rzeczami jak logi, katalogi tymczasowe, zasoby uploadowane przez użytkowników czy pliki konfiguracyjne zależne od środowiska i maszyny, wszystko warto trzymać w systemie kontroli wersji.
Dzięki tjeden, tego mi było trzeba. Inne pytanie, mam np baze development która jest inna na localhoscie a inna na serverze. Znalazłem gdzieś taki task, w tym przykładzie dla produkcji, ale może ktoś ma lepsze pomysły
task :after_update_code, :roles => :app do
run "cp #{release_path}/config/production.database.yml #{release_path}/config/database.yml"
end
Tak jak pisze tjeden oczywiście pod żadnym pozorem nie trzymaj katalogu vendor w git! Nie ma nic gorszego niż checkout projektu na Maku i zonk bo w repo są gemy z native extensions na Linuksa. :>
Natomiast dobrym pomysłem jest podawanie konkretnego numer wersji gemu w environment.rb. Dodaj do tego task capistrano, który odpala na serwerze produkcyjnym ‘rake gems:install’ i już wszystko działa.
Jeśli jesteś odważny użyj Bundlera, który za Ciebie skonfiguruje wszystkie gemy i przy okazji rozwiąże parę problemów w stylu kura/jajko czyli co było pierwsze. Na razie nie jest to jednak zbyt stabilne rozwiązanie.
Mówimy o pluginach czy gemach? Artur pytał chyba o pluginy. Bo ja do katalogu vendor wrzucam pluginy i zawsze mi się wydawało(wydaje?), że nie ma osobnych wersji pluginów dla różnych systemów. Co innego z gemami, ale ich nigdy nie zamrażałem ani nie trzymałem w katalogu vendor, ani w gicie, tylko instalowałem osobno, najwygodniej właśnie w oparciu o rake gems:install, przy odpowiednio skonfigurowanym environment.rb. A bundler dla mnie jak na razie to jakieś nieporozumienie.
Braki, ale tjeden napisał, że vendor powinien być w gicie:
ale miał na myśli chyba faktycznie tylko pluginy a nie gemy
Ja trzymam wszystkie gemy i pluginy z vendor w gicie poza tymi gemami, które wymagają kompilacji. Rozwiązanie nie jest idealne, bo trzeba pamiętać które wymagają kompilacji i je ręcznie zainstalować na produkcji. Do zalet tego rozwiązania w stosunku do instalowania wszystkich gem’ów po każdeym “cap deploy” na pewno należy zaliczyć to, że deploy jest o wiele szybszy bo nie wymaga za każdym razem instalowania wszystkich gemów.
Bundlerowi jeszcze nie przyglądałem się bliżej, mam nadzieję, że w końcu rozwiąże ten problem.
Przechodziłem przez temat zależności i wyrobiłem sobie pewne zdanie na ten temat. Miejsce na dysku jest tanie, tak? A więc pakuj do repo tyle ile jesteś w stanie. Pluginy, vendoruj gemy itp. Dlaczego narażać się na ryzyko instalacji gema/plugin w innej wersji u kolegi z zespołu, albo serwerze produkcyjnym lub testowym?
Gorąco polecam bundlera. To jeden z lepszych toolów (nie jest jeszcze idealny, czasem coś potrafi nie działać) z jakich ostatnio korzystałem. Nie wyobrażam sobie by inaczej określać zależności w aplikacjach rubinowych (config.gem to marna proteza).
ale miał na myśli chyba faktycznie tylko pluginy a nie gemy :)[/quote]
Ech. Nie doczytałem. Dla mnie plugin=gem i omijam te, które trzeba instalować do vendor - stąd nieporozumienie.
Nie lubię trzymania pluginów/gemów w katalogu aplikacji, spowalnia to pracę ack i quick open w TextMate.
Kolejne pytanie odnośnie Capistrano. Chciałbym się upewnić co do jednej rzeczy. Capistrano tworzy link /aplikacja/current który wskazuje na katalog z najnowszym deployem w /aplikacja/releases/ . Skąd serwer www gdy wchodzę na stronę będzie w takim razie pobierał pliki, z katalogu /aplikacja tak jak bez Capistrano, czy też sam użyje dowiązania current i pliki bedą z najnowszego deploymentu czy może powinienem przekierować serwer w panelu administracyjnym na link aplikacja/current ? Co jeśli ktoś zmieni jakiś plik ręcznie niekoniecznie na produkcji ale np. w aplikacja-stage/ ?
różnią sie właściwie tylko bazą danych oraz suffixem stage, dlatego chciałbym móc użyć w kodzie np. czegoś takiego :