Si bien paso la mayor parte de mi carrera en la pila de Microsoft como desarrollador web de pila completa, en ocasiones he llegado al lado *NIX de las cosas… construí un servidor web FreeBSD aquí, jugué con Caldera Linux una vez allí, y actualmente estoy haciendo una implementación web usando una máquina virtual en la nube de Google que ejecuta Ubuntu…
TL,DR
Entonces, si bifurqué un repositorio en mi cuenta de GitHub, todo con el fin de clonarlo en mi servidor Ubuntu, donde luego compilaré y ejecutaré la aplicación web.
¿Cuál es la ubicación profesionalmente esperada en la que debo colocar ese código fuente ‘clonado’? Busqué en Google un poco para comprender mejor para qué sirven los distintos directorios de Linux… pero… necesito una buena respuesta SO… así que… ¿dónde la pondrías?
/usr/src/MyGitRepos ..eso me sonó bien.. pero.. ¿qué harías?
viraptor
¿Cuál es la ubicación profesionalmente esperada?
Si, como usted dice, está implementando una aplicación compilada desde la fuente, entonces no existe tal ubicación. En un entorno profesional, sus fuentes no van a los servidores.
Desde la mayoría de las soluciones profesionales hasta las que funcionan:
-
Cree paquetes de sistema fuera de su entorno de producción. Eso significa que tiene un repositorio de ambas versiones implementadas anteriormente y tiene un manifiesto de paquete que incluye dependencias de compilación y tiempo de ejecución. Eso significa que puede reconstruir su aplicación de la misma manera cada vez. Para la instalación, instale el paquete integrado. (esto se aplica a deb, rpm, etc.)
-
Cree tarballs con archivos binarios en un entorno predecible (caja del desarrollador). Eso significa que ejecuta (por ejemplo, si está usando herramientas automáticas)
./configure --prefix=/opt/your_app && make install DESTDIR=/tmp/somedirectory– ahora puedes empacar el/tmp/somedirectory/opt/your_appcontenido, cópielo en un servidor y descomprímalo para/opt/your_app. -
Clónelo donde sea (su directorio de inicio), luego compílelo e instálelo en el destino. Los destinos populares son
/opt/app_namey/usr/local.
La solución depende de cuán profesional sea realmente la implementación, cuántos servidores tiene, si tiene un entorno de prueba/producción, etc.
-
ja, ja… ahora sabía esto por el desarrollo de ASP.NET… solo se publica la carpeta “bin”… simplemente no tenía el estado de ánimo adecuado… me pongo “hacky” cuando estoy haciendo linux cosas y olvidar lo obvio (o, bueno… tal vez… no tan obvio) Realmente aprecio la lista de los pasos con los fragmentos de código de la línea de comandos. Esta es la respuesta que estaba buscando, poniéndome en un camino cuerdo.
– bkwdiseño
21 de enero de 2016 a las 4:55
-
Si lo pones en otro lugar que no sea
$HOMEhay un problema potencial; si aparece un usuario diferente e intenta ejecutar ungitcomando en el directorio, tendrá dificultades (ese usuario podría no tener permisos para modificar los archivos en el.gitsubdirectorio que tiene su identificación de usuario, por ejemplo). Mi sugerencia sería que si pretende un desarrollo colaborativo, cada usuario clone su propia copia en su$HOME; pero si tiene la intención de usar los resultados de una manera de solo lectura, clónelo en algún lugar yrm -rf .git.–MM
21 de enero de 2016 a las 8:22
-
bien, hice un recursivo
chowncomando justo antes de ejecutar elmake..lo que permitió que todas las cosas de gestión de paquetes tuvieran éxito… pero… ya veo lo que estás diciendo… tuvo éxito para mí– bkwdiseño
21 de enero de 2016 a las 17:10
No diría que hay un lugar asumido estándar, especialmente si el servidor es específicamente para esta aplicación. Poner una carpeta para ello en el directorio /home/usuario debería estar bien incluso, u organizarlo de la forma que mejor le parezca a partir de ese punto:
/home/user/app-goes-here/app.js
Solo mantenlo simple 🙂
-
sí, poniéndolo en el
home/user/ubicación… tiene sentido… esa es básicamente la dirección que estaba buscando, junto con su sugerencia de que no hay un lugar estándar. Solo necesitaba una verificación independiente de que mi intuición iba en la dirección correcta. No me considero lo suficientemente *NIX-y como para confiar en mis instintos 😉– bkwdiseño
21 de enero de 2016 a las 4:05
-
Me alegro de poder ser de ayuda 🙂 siempre que no sea una gran implementación de nivel empresarial (y supongo que se le darán instrucciones sobre esto si lo fuera), entonces no veo ninguna razón por la que esto no sea adecuado.
– Nodal
21 de enero de 2016 a las 7:32
Cuando va a ser utilizado por un solo usuario de Unix, en algún lugar de $HOME es bastante razonable para mí. Si el repositorio también está destinado a ser utilizado por otro usuario, /opt es considerable
-
es bueno saberlo, sí, este es un concierto independiente, básicamente estoy armando algunos servidores para un cliente que luego se hará cargo de todo, mi aparición en esta configuración será breve
– bkwdiseño
21 de enero de 2016 a las 4:07
-
Personalmente, no estoy de acuerdo con el uso
/opt(o/local) para almacenar repositorios git, porque están destinados a almacenar software.optgeneralmente se utiliza para almacenar opcional software que se puede eliminar simplemente eliminando su carpeta dentroopt. Similarmente,localestá diseñado para software instalado localmente que es independiente de la propia distribución./usren sí mismo almacena binarios, nuevamente destinados a alojar software. Además, un repositorio de git no está destinado a ser compartido entre usuarios. Si se necesita una condición, el repositorio debe ser clonado por cada usuario que lo use. Para mí,homees la mejor opción.– alelom
10 de marzo a las 12:22
aleloma
yo diría que home es la mejor opción de ubicación para clonar un repositorio.
Personalmente, no estoy de acuerdo con el uso /local o /opt para almacenar repositorios git, porque están destinados a almacenar software:
/usren sí mismo almacena binarios (destinados a alojar software)./localestá destinado a software instalado localmente que es independiente de la distribución en sí./optgeneralmente está destinado a almacenar opcional software que se puede eliminar simplemente eliminando su carpeta dentroopt.
Además, creo que un repositorio de git no está destinado a ser compartido entre usuarios. Si la división es necesaria, el repositorio debe ser clonado por cada usuario que lo use, en lugar de que diferentes usuarios compartan la misma carpeta. Si el uso del disco es una preocupación, probablemente signifique que el repositorio se usa incorrectamente para almacenar archivos grandes en lugar de solo el código fuente, o que es posible que desee ver cosas como git-lfs por ayuda
lo que uso es
$HOME/repos/owner/repo-nameque mantiene las cosas bastante organizadas.– usuario663031
21 de enero de 2016 a las 4:08