¿Cuál sería un directorio razonable y lógico en el que implementar mis aplicaciones Rails de producción en un sistema Linux?
Algunos candidatos...
/var/rails <= There's a /var/www so this would be consistent with that
pattern. But I.T. guys have complained about stuff in /var
before.
/home/my_home_dir/rails <= OK, not /var, but I'm not the only developer.
Seems like it really ought to be a systemwide
location.
/home/rails <= I don't know. That just seems weird.
/rails <= Seems even weirder.
¿Qué es lo menos sorprendente y lo más normal que se puede hacer aquí?
(Información básica: una aplicación Rails es un conjunto de código del lado del servidor escrito en Ruby junto con un publicdirectorio que contiene JavaScript, CSS y tal vez un poco de HTML. El publicdirectorio está asignado a un servidor virtual Apache. Apache maneja el código Ruby a través de un módulo llamado Pasajero o mod_rails.)
Gracias por toda la ayuda. Creo que voy a ir con /opt/deployed_rails_apps. (Me gustan los nombres de directorio largos y expositivos y la finalización de pestañas). /var/...También es un buen lugar, pero TI me refunfuñó severamente cuando intenté implementar cosas allí. Si fuera mi propia máquina, podría utilizar /varo /srv.
Respuesta1
Creo/optarsería el lugar para unsolicitudcomo esto. Estoy de acuerdo con seguir el FHS como lo sugiere chmeee, pero no estoy de acuerdo con que una aplicación Rails sea un servicio per se.
Respuesta2
Quizás quieras seguir elEstándar de jerarquía del sistema de archivos (FHS)y colóquelo en
/srv : Data for services provided by this system
EDITAR:
Yo no lo colocaría en /opt:
/opt : Add-on application software packages
Su propósito dice:
/opt está reservado para la instalación de paquetes de software de aplicaciones complementarias.
Un paquete que se instalará en /opt debe ubicar sus archivos estáticos en un árbol de directorio /opt/ o /opt/ separado, donde hay un nombre que describe el paquete de software y es el nombre registrado de LANANA del proveedor.
No creo que una aplicación desarrollada sea un "paquete de software".
La razón /srves
El objetivo principal de especificar esto es que los usuarios puedan encontrar la ubicación de los archivos de datos para un servicio en particular, y para que los servicios que requieren un único árbol para datos de solo lectura, datos grabables y scripts (como scripts cgi) puedan ubicarse razonablemente.
Entiendo que una aplicación Rails es un script cgi y debe colocarse en formato /srv.
Respuesta3
En las distribuciones CentOS Linux (y posteriormente RedHat), cuando instala el paquete httpd (para Apache 2), crea /var/wwwy espera que sus vhosts apunten a su contenido web aquí. El vhost predeterminado generalmente se descarga en /var/www/htdocs, y los sitios/aplicaciones posteriores se deben instalar en /var/www/sitename.
La ubicación real no debería importar mucho, pero es común ver /opt/www/sitename, /var/www/sitenameo simplemente /opt/wwwo /var/www.
Ya has indicado algunas de las razones por las que algunas de las otras ubicaciones (como /home) no son realmente adecuadas para esto.
Personalmente, lo prefiero /var/www/sitenameporque es compatible con Apache y Rails y abarca todo el sistema.
Respuesta4
En el sistema basado en Debian/ubuntu, dichas aplicaciones generalmente se instalan en la carpeta /usr/share (es decir, /usr/share/ruby), ya que son archivos no compilados (que irían a /usr/lib). Dado que su aplicación no es una aplicación estándar, probablemente la colocará en /usr/local/share para evitar que las actualizaciones del sistema la sobrescriban.
/opt ciertamente también es una posibilidad aquí.