Implementación de la aplicación Perl

Question

¿Cuáles son las mejores prácticas para implementar una aplicación Perl? Suponga que se está desplegando en una caja pequeña con poca instalación del módulo CPAN. ¿Cuáles son las construcciones ideales, los métodos de implementación? Module :: Build, ExtUtils :: MakeMaker, otro? Estoy buscando algunas ideas de mejores prácticas de aquellos que han hecho esto repetidamente para aplicaciones a gran escala.

La aplicación se está implementando en un servidor. No es CPAN o un script. En realidad es una aplicación web de PSGI. Es decir, una tonelada de paquetes de Perl.

Actualmente tengo un script de despliegue que usa Net :: SSH :: Expect para SSH en nuevos servidores, instalo algunas herramientas y configuro el servidor, luego selecciono la rama de aplicación deseada desde el control de origen. Esto parece correcto, pero ¿es esta la mejor práctica?

El siguiente paso es crear la aplicación. ¿Cuáles son las mejores prácticas para rastrear y administrar dependencias, instalar esas dependencias de CPAN y garantizar que la aplicación esté lista para ejecutarse?

Gracias

Answer 1

Si tiene algunas dependencias CPAN importantes, entonces es posible que desee o bien escribir un pequeño script que usa CPAN::Shell para instalar los módulos necesarios o editar el Makefile.PL de su aplicación de manera que refleje las dependencias necesarias en la parte BUILD_REQUIRES del archivo.

Answer 2

La empresa en la que trabajo actualmente genera RPM para cada uno de los CPAN & Dependencia interna de una aplicación (¡un montón de paquetes!) Que se instala en el sistema del directorio site_perl. Esto tiene una serie de problemas:

• Lleva mucho tiempo crear RPM a medida que las versiones se ven afectadas por el CPAN.
• Al vincularse al sistema perl, usted queda a merced de su distribución para crear o deshacer su perl (en Centos 5 tenemos una versión perl máxima de 5.8.8).
• Si tiene múltiples aplicaciones implementadas en el mismo host, tener una única biblioteca perl para todas las aplicaciones significa que la actualización de las dependencias puede ser peligrosa sin volver a probar cada aplicación del host. Implementamos una gran cantidad de distribuciones separadas, todas con diferentes niveles de atención de mantenimiento, por lo que este es un gran problema para nosotros.

Nos estamos alejando de crear RPM para cada dependencia y, en su lugar, planeamos usar cartón [1] para crear una biblioteca perl completamente independiente para cada aplicación que implementamos. Estamos construyendo estas bibliotecas en paquetes de sistema, pero podría fácilmente instalarlas y copiarlas manualmente si no desea tratar con un administrador de paquetes.

El problema con la caja de cartón es que tendrá que configurar una réplica interna de CPAN para la que puede instalar sus dependencias internas si su aplicación depende de módulos que no están en el CPAN. Si no quiere lidiar con eso, siempre puede instalar manualmente libs que necesite en local :: lib [2] o perlbrew [3] y empaquetar las bibliotecas resultantes para implementarlas en sus cajas de producción.

Con todas las soluciones prescritas, tenga mucho cuidado con XS perl libs. Tendrá que crear sus cajas de cartón/locales: libs/perlbrews en la misma arquitectura que el servidor en el que está desplegando y asegurarse de que sus cajas de producción tengan las mismas dependencias binarias que las que solía construir.

Para responder a la actualización de su pregunta acerca de si es una buena práctica obtener la fuente e instalarla en su host de producción; Personalmente, no creo que sea una buena idea. Las razones por las que creo que es arriesgado radica en el hecho de que es difícil estar completamente seguro de que el conjunto de bibliotecas que instala se alinea exactamente con las bibliotecas que probó, por lo que las implementaciones tienen el potencial de ser impredecibles. Este problema puede ser exasperado por webapps, ya que es muy probable que tenga el mismo código implementado en múltiples cajas de producción que también pueden desconectarse. Si bien la comunidad Perl hace un trabajo maravilloso al tratar de lanzar un código de buena calidad que sea compatible con versiones anteriores, cuando las cosas van mal normalmente es un gran esfuerzo resolver las cosas. Esta es la razón por la cual se está desarrollando la caja de cartón, ya que crea una memoria caché de todos los archivos comprimidos de distribución que necesita instalar congelados en versiones específicas para que pueda implementar su código de forma predecible. Todo eso dijo sin embargo; Si está contento de aceptar ese riesgo y arreglar las cosas cuando se rompen, entonces la instalación local debería estar bien para usted. Sin embargo, como mínimo, podría recomendar encarecidamente instalar en una :: lib local para que pueda hacer una copia de seguridad de la lib local anterior antes de instalar las actualizaciones para que tenga un punto de reversión si las cosas se estropean.

• [1] https://metacpan.org/module/Carton (tenga cuidado, sino que todavía está en desarrollo pesada)
• [2] https://metacpan.org/module/local::lib
• [3] https://metacpan.org/module/perlbrew

Answer 3

Usted puede echar un vistazo a sparrowdo un Perl6 herramienta de administración de configuración, viene con algunos complementos útiles relacionados con la implementación de perl5, como la instalación de paquetes de cpan o la implementación de la aplicación psgi.

Actualización: este enlace https://dev.to/melezhik/deploying-perl5-application-by-sparrowdo-9mb podría ser útil.

Divulgación: soy el autor de la herramienta.