2010-06-01 16 views
9

estamos buscando una manera de apuntar nuestro Apache DocumentRoot a un enlace simbólico. P. ej. DocumentRoot/var/www/html/finalbuildEstablecer apache documentRoot para enlace simbólico (para una fácil implementación)

finalbuild debe apuntar en algún lugar como/home/usuario a una carpeta/build3

cuando nos movemos una nueva construcción a/home/usuario/build4 queremos usar una concha secuencia de comandos que cambia el enlace simbólico "finalebuild" a este nuevo directorio/home/user/build4 y hacer un apache agradecer a reiniciar para tener una nueva versión de la aplicación web en marcha con poco riesgo.

¿Cuál es la mejor manera de crear este enlace simbólico y de cambiar este enlace después usando el script de shell?

+1

I Estoy pensando "rm/var/www/html/finalbuild && ln -s/home/user/build4/var/www/html/finalbuild". Es posible que ni siquiera necesites reiniciar Apache. – barrycarter

+0

gracias, he cambiado el docroot y lo he apuntado a un enlace simbólico, pero Apache no parece estar escuchando ... He reiniciado apache con éxito, ¿alguna idea? – Jorre

+0

También he estado tratando de encontrar una respuesta para esto. Apache me está dando un error 403. Sin suerte hasta ahora. Presumiblemente porque es una mala práctica hacerlo en producción. Sin embargo, quiero hacerlo en mi caja de desarrollo. – nedned

Respuesta

3

He usado enlaces simbólicos como Apache DocumentRoot en producción sin necesidad de un elegante reinicio. En general, la idea debería funcionar. Un error 403 probablemente indica un error de permisos no relacionado con el cambio de enlace simbólico. Una arruga agregada que desearía agregar es making the symlink switch atomic por lo que el enlace simbólico siempre existe. Es decir, en ningún momento el enlace simbólico no existe, ni siquiera por un momento.

La solución a este problema es efectuar el cambio creando un nuevo enlace simbólico y luego cambiarle el nombre por el enlace simbólico anterior. En sistemas tipo Unix, el cambio de nombre es una operación atómica, y por lo tanto el "cambio" de enlace simbólico también será atómico. Por parte, el proceso es el siguiente:

$ ln -s new current_tmp && mv -Tf current_tmp current 
+1

Para contradecir a mí mismo, veo este enlace que experimentó problemas: http://www.mikebrittain.com/blog/2009/05/12/case-against-using-symlinks-for-code-promotion/ – defmikekoh

7

Estamos utilizando Capistrano emplear una configuración similar. Sin embargo, nos hemos encontrado con algunos problemas:

Después de cambiar a la configuración, las cosas parecían ir bien, pero luego comenzamos a notar que después de ejecutar cap deploy, aunque el enlace simbólico había sido cambiado para señalar hacia la cabeza revisión, el navegador aún mostraría las páginas anteriores, incluso después de varias actualizaciones y la adición de diferentes parámetros GET.

Al principio, pensamos que era el almacenamiento en caché del navegador, por lo que para el desarrollo desactivamos el almacenamiento en caché del navegador a través de encabezados HTTP, pero esto no cambió nada. Luego verifiqué para asegurarme de que no estuviéramos haciendo caching de página completa en el servidor, y no lo estábamos haciendo. Pero luego noté que si borraba un archivo en la revisión a la que solía apuntar el enlace simbólico, obtendríamos un 404, por lo que Apache estaba publicando nuevas páginas, pero aún seguía el "enlace simbólico antiguo" y publicaba las páginas desde el directorio equivocado

Esto es en alojamiento compartido, por lo que no pude reiniciar Apache. Así que traté de eliminar el enlace simbólico y crear uno nuevo cada vez. Esto pareció funcionar a veces, pero no confiablemente. Funcionó probablemente el 25 ~ 50% del tiempo.

Finalmente, he encontrado que si I:

  1. quitado el enlace simbólico existente (eliminarlo o el cambio de nombre);
  2. hizo una solicitud de página, causando Apache para intentar resolver el enlace simbólico, pero no lo encuentre (lo que resulta en un 404)
  3. continuación, se crea un nuevo enlace simbólico al nuevo directorio

que causaría la docroot a actualizarse apropiadamente la mayor parte del tiempo.Sin embargo, incluso esto no es perfecto, y alrededor del 2-5% del tiempo, cuando el script de implementación ejecutó wget para recuperar una página justo después de cambiar el nombre del enlace simbólico antiguo, devolvería la página anterior en lugar de 404.

Parece que Apache está almacenando en caché el sistema de archivos, o quizás el comando mv solo cambió el sistema de archivos en la memoria mientras Apache estaba leyendo desde el sistema de archivos en el disco (realmente no tiene sentido). En cualquier caso, he retomado la recomendación de alguien de ejecutar sync después de que el enlace simbólico cambie, lo que debería hacer que el sistema de archivos en el disco esté sincronizado con la memoria, y quizás el ligero retraso también ayude al wget a devolver un 404.

+2

Si alguien entiende el por qué detrás de este comportamiento sería maravilloso documentarlo. – ThorSummoner

Cuestiones relacionadas