git/github y la configuración de implementación del servidor web

Question

Estoy ejecutando un servidor web Apache y me preguntaba ¿cuál es la mejor manera de implementar cambios (desde github) al servidor web?

/var/www/ahora solo se puede escribir por root.

¿Debo tener mi proyecto de git directamente en/var/www /? (entonces crea /var/www/.git/?)

Sin embargo, cuando necesito ejecutar comandos (es decir, sudo git push) no funciona (ya que mis claves ssh no están bajo sudo).

¿Sería mejor hacer/var/www/writable solo (y no solo root)? ¿O debería agregar claves ssh al usuario raíz? ¿O debería hacer algo completamente diferente?

Gracias.

Answer 1

Uso rsync para sincronizar los contenidos de mi máquina local con el servidor, y si solo está implementando en un servidor, entonces es bastante simple (y Capistrano es excesivo). Pongo los siguientes alias en ~/.bash_profile:

alias eget='rsync -avie ssh matt@example.com:sites/example.com/www/ ~/Projects/example/example.com/www/ --exclude .DS_Store --exclude ".git*" --delete-after' 
alias edep='rsync -avuie ssh ~/Projects/example/example.com/www/ matt@example.com:sites/example.com/www/ --exclude .DS_Store --exclude ".git*" --delay-updates --delete-after' 

Entonces, desde el repositorio git en mi máquina local. Yo:

git commit -am 'commit some changes' 
git pull --rebase # pull any new changes from remote (--rebase prevents an unnecessary merge commit.) 
eget -n # confirm which files I've changed 

Si se parece a pescado, lo que podía hacer sin el eget -n y luego simplemente hacer un git diff -w. Entonces, podría hacer git checkout -- path/to/file para los archivos para los cuales quiero guardar mis cambios. Luego, confirmo los cambios que estaban en el servidor que aún no recibí. Esto solo ocurrirá si los archivos en el servidor cambian de forma diferente a las implementaciones. De lo contrario, sabrá que su versión local siempre está más actualizada que los archivos en el servidor y, por lo tanto, no tiene que preocuparse por sobrescribir cosas en el servidor que aún no tiene en su servidor local. Continuar ...

edep -n # just see what files will be deployed/updated/etc. 
edep # looks good. Deploy for real. 

¡Hecho!

Consulte la rsync(1) Mac OS X Manual Page para obtener más información.

Otra opción es usar el Git post-receive hook. Pero, tendrás que instalar Git en el servidor para hacer eso. Además, le recomiendo colocar el directorio .git fuera de su directorio público www por motivos de seguridad &. Puede hacerlo con la opción de configuración Git core.worktree. Por ejemplo, desde ~/git/example.com.git, haga git init --bare; git config core.worktree ~/sites/example.com/. Eso hace ~/git/example.com.git como el .git dir para ~/sites/example.com/.

Answer 2

Crea un repositorio central, utiliza la ramificación de git para crear diferentes ramas para diferentes propósitos, y nunca sirva todo tu repositorio públicamente, ni deberías servir públicamente tu directorio .git (ya que eso es lo mismo que servir todo lo que alguna vez lo hizo con el código o lo puso en el repositorio al público). De la parte superior de mi cabeza, aquí están los pasos que recomiendo, por mi propia experiencia:

• Crear un/concentrador repositorio central para el código. (opcional, pero recomendado. Incluso mejor es usar github.com para su repositorio central). Luego puede verificar copias locales para implementaciones locales, p. cuando desee recrear el sitio en su computadora portátil. No es necesario, pero es muy conveniente y se asegura de que su sitio sea portátil.Puede tener un repositorio de etapas y una ramificación de etapas para fines de desarrollo. También puede tener un repositorio y una sucursal para fines de producción.

• Crear un directorio explícitamente público en el repositorio que es no la raíz del repositorio: P. ej. Cree un directorio/www/or/served/or/public/dentro del repositorio. Esto es material que estará públicamente disponible e indexable por los motores de búsqueda, así que tenga cuidado con lo que allí se encuentre. Supongamos que todo lo que ingresa es de conocimiento público, guardado en caché para la eternidad y será el objetivo de los ataques de vulnerabilidad de seguridad (porque podría ser la verdad).

• Crear el repositorio dev: git clone el repositorio central en el servidor (por ejemplo cd /home/tchal continuación git clone git@github.com:tchalvak/ninjawars.git), aunque idealmente en una carpeta que ha compartido permisos para su grupo desarrollador.

• crear un enlace simbólico para usted sitio de desarrollo: cd /var/www/, ln -s /url/to/shared/repository/public/ nickNameForDevSiteHere, creando un enlace simbólico a sólo los archivos servidos/públicas del sitio, la creación de un sitio simple nivel de desarrollo. (opcional, pero recomendado). De esa manera, el sitio de desarrollo puede ser fácilmente accesible a través de una ip y un apodo, p. http://10.0.1.123/publicdevelopmentsitenickname sin la necesidad de un nombre de dominio real.

• Especifique el compromiso & impleiled code en vivo. Es posible que desee crear un live-branch para cualquier código que esté actualmente "activo", solo tenga en cuenta que esta rama probablemente tendrá que ser sobrescrita a la fuerza periódicamente, p. git branch live-branchgit push -f origin live-branch. Considérelo una instantánea de su código, y no una rama que se mantendrá estable.

• Cuando esté seguro de que el sitio de desarrollo se ha probado lo suficiente, implemente el código live-branch manualmente, mediante una secuencia de comandos de implementación personalizada o use un repositorio distinto con la rama activa desprotegida, solo sirviendo el contenido explícitamente público, similar al sitio dev.

  • crear un host virtual en apache para el nombre de dominio. Por ejemplo, podría usar algo como: <VirtualHost *> ServerName greatdomain.com ServerAlias www.greatdomain.com DocumentRoot /srv/greatdomain/www/ </VirtualHost> Ese es un tema enorme, por lo que si no tiene claro todos los detalles, le recomiendo que investigue más sobre cómo configurar un host virtual en apache.

  • Indique su DNS para el nombre de dominio en la ip del servidor.

En resumen, se puede utilizar con bastante facilidad git para desplegar todo su código usando ramas específicas a cada uno de tipo de despliegue. No ayudará con la sincronización, por ejemplo, las bases de datos entre las implementaciones, pero ese es un paso que usted podría descubrir después de ejecutar las cosas, como un segundo nivel de implementación de un sitio, y hacerlo manualmente mientras tanto.