Ciao Ragazzi,
ho a disposizione dello spazio in una web farm su di un server niente
male ed ho pensato di offrire hostig ruby on rails gratuitamente.
Secondo voi cosa dovrei offrire?
Pensavo prima di tutto di offrire un account ftp alla propria
applicazione fornendo l’accesso alle seguenti cartelle:
app config doc log Rakefile script tmp
components db lib public README test vendor
Ovviamente farei partire ogni applicazione su di una porta a mia scelta
( tipo: 3001, 3002 o altro ).
Ho già installato ruby, apache, mongrel e ruby on rails sul server.
Poichè programmo solitamente in java e sono un pò a digiuno di ruby on
rails ( ma con linux me la caso benino anche coem sistemista ) qualcuno
può guidarmi a riguardo?
Ciao!
Siamo tutti (chi più chi meno) in ferie… non disperare.
La community italiana di Ruby è una delle più attive, non disperare…
a settembre ti “bombarderanno” di richieste/supporto…
indirizzo del tipo USERNAME.miodominio.it ( l’indirizzo in realtÃ
maschera il fatto che la propria applicazione gira su una ben
determinata porta - il mascheramento è eseguito mediante apache
utilizzato come proxy )
1 account ftp alla propria applicazione
mongrel come server dietro apache
Penso che per adesso basti per caricare la propria applicazione online o
sbaglio?
E’ indispensabile offrire la possibilità di stoppare / riavviare la
propria instanza di mongrel?
On Sat, 11 Aug 2007 01:02:59 +0200, Magnus M. [email protected]
wrote:
E’ indispensabile offrire la possibilità di stoppare / riavviare la
propria instanza di mongrel?
In quanto novizio non ne ho la certezza, ma forse
modificando i modelli il server andrebbe riavviato.
Puo’ darsi che sia una str***ata. Sono le 2 di notte.
Ivan
On Sat, 11 Aug 2007 01:02:59 +0200, Magnus M. [email protected]
wrote:
E’ indispensabile offrire la possibilità di stoppare / riavviare la
propria instanza di mongrel?
In quanto novizio non ne ho la certezza, ma forse
modificando i modelli il server andrebbe riavviato.
Puo’ darsi che sia una str***ata. Sono le 2 di notte.
Ivan
Non ho nessun problema a dare la possibilità di riavviare il proprio
mongrel. Però vorrei fornire questa opzione solo se è strettamente
necessario
Il giorno Sat, 11 Aug 2007 12:04:55 +0200
Magnus M. [email protected] ha scritto:
Ho notato che è necessario riavviare il server anche quando viene
cambiato il file database.yml
Quindi questa funzione la devo dare.
è un idea mia o per il deploy di rails bisogna fare un casino immenso???
mettere n server più uno di frontend, dare la possibilità di riavviare
il server se cambio un file; cioè non si è mai visto che bisogna
riavviare un server perchè ho cambiato un file di un applicazione
che ci gira sopra.
Rails è un ottimo framework, ma dovrebbero semplificare di molto il
deploy.
Pero’ ora mi hai fatto venire la curiosita’… come dovrebbe
funzionare
il “tuo” sistema di deploy ideale ?
A questa domanda rispondo anche io, e credo che il buon Michele
Franzin possa concordare con me
Per quanto riguarda il mio sistema di deploy ideale, esiste già:
capistrano.
Capistrano è mal documentato, pecca enorme, ma a parte quello ha
tutto ciò che si possa chiedere ad un sistema di deploy. Granulare,
flessibile, estendibile, manca solo che faccia il
caffé.
Il mio consiglio è quello di perdere il tempo necessario ad
approfondire capistrano, non ve ne pentirete.
Pero’ ora mi hai fatto venire la curiosita’… come dovrebbe
funzionare
il “tuo” sistema di deploy ideale ?
A questa domanda rispondo anche io, e credo che il buon Michele
Franzin possa concordare con me
Per quanto riguarda il mio sistema di deploy ideale, esiste già:
capistrano.
sottoscrivo pienamente!
Capistrano è mal documentato, pecca enorme, ma a parte quello ha
qualche piccolo passo avanti lo hanno fatto qui [1], ma non ti
fare troppe illusioni, mentre la documentazione uffciale [2] è più
estesa ma largamente obsoleta (ancora buona per farsi un’idea
generale)
Il giorno mar, 21/08/2007 alle 15.01 +0200, [L]ash ha scritto:
il server se cambio un file; cioè non si è mai visto che bisogna
riavviare un server perchè ho cambiato un file di un applicazione
che ci gira sopra.
Magari non si fosse mai visto…sarebbe un mondo bellissimo, ma ti
assicuro che il 99% dei framework/application server/blah blah
funzionano cosi’ a partire da tomcat per arrivare a zope (ed entrambi
hanno un frontend web per forzare il riavvio)
Rails è un ottimo framework, ma dovrebbero semplificare di molto il
deploy.
Secondo voi??
Secondo me e’ una parte che va gestita con un’ applicazione esterna (ad
esempio via web) perche’ rails gia’ ti fornisce dei canali per
effettuare la rilettura delle modifiche di configurazione (anche se sei
sotto mongrel) che vanno solo utilizzati.
Non c’e’ motivo di appesantire la struttura.
Pero’ ora mi hai fatto venire la curiosita’… come dovrebbe funzionare
il “tuo” sistema di deploy ideale ?
Il giorno Wed, 22 Aug 2007 09:19:43 +0200
Roberto De Ioris [email protected] ha scritto:
Pero’ ora mi hai fatto venire la curiosita’… come dovrebbe
funzionare il “tuo” sistema di deploy ideale ?
non avere un server web separato per applicazione + 1;
un qualcosa di più facile come php, python, perl sarebbe l’ideale
probabilmente uno che cerca più sicurezza e vuole separare tutto e
allora gli va bene avere n server che girano con utenti diversi; mi
piacerebbe che ci fosse la possibilità di scegliere tra le due opzioni,
anche perchè la mia macchinina n server non li tiene
non avere un server web separato per applicazione + 1;
un qualcosa di più facile come php, python, perl sarebbe l’ideale
probabilmente uno che cerca più sicurezza e vuole separare tutto e
allora gli va bene avere n server che girano con utenti diversi; mi
piacerebbe che ci fosse la possibilità di scegliere tra le due opzioni,
anche perchè la mia macchinina n server non li tiene
Il giorno mer, 22/08/2007 alle 12.42 +0200, [L]ash ha scritto:
Il giorno Wed, 22 Aug 2007 09:19:43 +0200
Roberto De Ioris [email protected] ha scritto:
Pero’ ora mi hai fatto venire la curiosita’… come dovrebbe
funzionare il “tuo” sistema di deploy ideale ?
non avere un server web separato per applicazione + 1;
fastcgi, scgi e se vuoi farti del male (e hai tanto tempo libero) cgi
un qualcosa di più facile come php, python, perl sarebbe l’ideale
la logica di funzionamento e’ diversa, (qualcuno ti dira’ che stai
paragonando un linguaggio a un framework ma ho capito cosa vuoi dire),
la parte piu’ evidente e’ che l’applicazione rails deve rimanere
residente pronta a ricevere richieste, l’alternativa e’ avere un sistema
lento (lentissimo…).
Probabilmente le perplessita’ che hai derivano tutte da questo aspetto.
probabilmente uno che cerca più sicurezza e vuole separare tutto e
allora gli va bene avere n server che girano con utenti diversi; mi
piacerebbe che ci fosse la possibilità di scegliere tra le due opzioni,
anche perchè la mia macchinina n server non li tiene
Il giorno 21/ago/07, alle ore 15:01, [L]ash ha scritto:
mettere n server più uno di frontend, dare la possibilità di riavviare
il server se cambio un file; cioè non si è mai visto che bisogna
riavviare un server perchè ho cambiato un file di un applicazione
che ci gira sopra.
Rails è un ottimo framework, ma dovrebbero semplificare di molto il
deploy.
Secondo voi??
Rails non richiede un riavvio se “cambi un file”.
Richiede un riavvio quando
Modifichi roba che viene caricata dall’initializer - ovvero
plugin, librerie sotto lib/, configurazioni in config/
Sei in production mode, quindi cachi il cachabile. Un grosso hint
ti arriva da RAILS_ROOT/config/environments/production.rb dove trovi
config.cache_classes = true
Quasi tutti i framework richiedono un riavvio. Rails no, nel momento
in cui sviluppi in development mode e vai in produzione in production
mode.
Mai visto applicazioni di un certo rilievo non andare in produzione
con un server che proxa le richieste a n server di backend - certo,
per il blog puoi anche usare fastcgi, ma il blog non è una
applicazione di un certo rilievo
Il giorno 22/ago/07, alle ore 12:42, [L]ash ha scritto:
non avere un server web separato per applicazione + 1;
un qualcosa di più facile come php, python, perl sarebbe l’ideale
probabilmente uno che cerca più sicurezza e vuole separare tutto e
allora gli va bene avere n server che girano con utenti diversi; mi
piacerebbe che ci fosse la possibilità di scegliere tra le due
opzioni,
anche perchè la mia macchinina n server non li tiene
Lighty + fastcgi.
Chi ti ha detto che non è possibile ?
Il giorno 11/ago/07, alle ore 02:10, Magnus M. ha scritto:
Non ho nessun problema a dare la possibilità di riavviare il proprio
mongrel. Però vorrei fornire questa opzione solo se è strettamente
necessario
Dipende.
Se l’applicazione gira in dev mode no, se è in production (e credimi,
tu non vuoi tutte le applicazioni in dev mode sulla tua macchina) si.
Anche la roba sotto lib/ richiede un restart di mongrel.
Il giorno mer, 22/08/2007 alle 18.22 +0200, [L]ash ha scritto:
Il giorno Wed, 22 Aug 2007 13:05:09 +0200
Roberto De Ioris [email protected] ha scritto:
fastcgi, scgi e se vuoi farti del male (e hai tanto tempo libero) cgi
come performance come siamo messi con cgi?
a mio modesto parere e’ praticamente inaccettabile su qualsiasi hardware
e configurazione, e te lo dice uno che userebbe cgi per ogni cosa
sopracitato framework, ma secondo me il meccanismo di funzionamento non
dovrebbe cambiare più di tanto. Invece mi trovo a dover avviare un
demone dedicato interamente ad una applicazione.
il problema e’ che stai paragonando un contesto in cui hai php embedded
in apache (con mod_php presumo).
Puoi usare rails in maniera molto simile con mod_ruby ma come gia’
emerso piu’ volte in questa lista ci sono dei problemi di stabilita’ (o
presunti tali) abbastanza fastidiosi (senza contare la base di utilizzo
infima rapportata a mod_php)
la parte piu’ evidente e’ che l’applicazione rails deve rimanere
residente pronta a ricevere richieste, l’alternativa e’ avere un
sistema lento (lentissimo…).
Probabilmente le perplessita’ che hai derivano tutte da questo
aspetto.
quindi rails è talmente lento che deve rimanere caricato in memoria per
avere dei tempi di risposta accettabili? e quanto di questa lentezza
dipende da rails e quanta da ruby stesso?
Detto cosi’ e’ abbastanza brutto, ma essendo pragmatici e’ un analisi
abbastanza veritiera.
Io ho una pessima opinione delle performance di ruby (sono un perlista,
quindi sono abituato a scrivere male e in fretta, ma con la certezza di
avere un overhead dell’interprete praticamente nullo), ma e’ un fattore
che viene totalmente eclissato dalla velocita’ di sviluppo e l’eleganza
del codice.
usa semplicemente webrick e hai risolto.
non posso ne voglio usare webrick come IL server web della mia
macchina, credo non tenga il confronto con apache
Eh ma cosi’ vuoi la botte piena e la moglie ubriaca comunque per il
background che hai ti consiglio di dare un occhio a mod_ruby
Il giorno Wed, 22 Aug 2007 13:05:09 +0200
Roberto De Ioris [email protected] ha scritto:
fastcgi, scgi e se vuoi farti del male (e hai tanto tempo libero) cgi
come performance come siamo messi con cgi?
un qualcosa di più facile come php, python, perl sarebbe l’ideale
la logica di funzionamento e’ diversa, (qualcuno ti dira’ che stai
paragonando un linguaggio a un framework ma ho capito cosa vuoi dire),
ok è un framework, ma un framework è sempre implementato con un
linguaggio per usare ad esempio lo ZendFramework (il primo che mi
viene in mente, non lapidatemi) devo solo metterlo sotto una directory e
fare l’include dei file e usarlo. Rails ha e fa molto di più del
sopracitato framework, ma secondo me il meccanismo di funzionamento non
dovrebbe cambiare più di tanto. Invece mi trovo a dover avviare un
demone dedicato interamente ad una applicazione.
la parte piu’ evidente e’ che l’applicazione rails deve rimanere
residente pronta a ricevere richieste, l’alternativa e’ avere un
sistema lento (lentissimo…).
Probabilmente le perplessita’ che hai derivano tutte da questo
aspetto.
quindi rails è talmente lento che deve rimanere caricato in memoria per
avere dei tempi di risposta accettabili? e quanto di questa lentezza
dipende da rails e quanta da ruby stesso?
usa semplicemente webrick e hai risolto.
non posso ne voglio usare webrick come IL server web della mia
macchina, credo non tenga il confronto con apache
