[SP-pm] Deployment - [Era - Teen sells Perl cloud startup to ActiveState]

[Solli Honorio]

---------- Mensagem encaminhada ----------
>De: Tiago Peczenyj <tiago.peczenyj em gmail.com>
>Data: 15 de junho de 2011 11:27
>Assunto: Re: [SP-pm] Teen sells Perl cloud startup to ActiveState
>Para: saopaulo-pm em mail.pm.org
>
>
>Aproveitando para mudar um pouco de assunto mas dentro do tema.
>
>Qual seria a melhor forma de fazer deploy do Catalyst (ou Dancer, ou
>Mojo) em produção? Eu poderia instalar via .deb ou .rpm OU preciso
>instalar todos os pacotes "na mão"? Dentro das dependências do
>Catalyst tem algo que existe build essencials (gcc)?

Não sei como é a melhor maneira de fazer um deploy de uma aplicação
Catalyst. A minha primeira alternativa era o local::lib, e agora estou
pensando com carinho no perlbrew, mas realmente não sei.

>Pergunto pq eu trabalho fazendo deploy em maquinas CentOS e sempre
>tenho que fazer RPMs para fazer deploy de aplicações em Perl mas todos
>eram scripts standalone ou serviços rodados via crontab.

Eu tenho a vontade de fazer um repositório de todos os módulos do cpan para
todas as distros (inclusive o Windows), assim já estaria tudo empacotado.

>Atualmente estamos usando para web Python, Ruby e Java e em cada um a
>gerência de pacotes é estressante: no caso do Python podemos utilizar
>o pip mas recentemente tivemos uma divergencia com a versão de libcurl
>que consumiu 2 dias inteiros. Com rubygems ocorre a mesma coisa e Java
>ficou abandonado (com todos os jars no mesmo diretorio... adivinhem o
>que acontece? ClassLoaderHell! mas isso é erro de projeto...).
>

Recentemente a Mac fez uma coisa que 'congelou' e dificultou muito a
instalação de módulos via cpan. Na london.pm teve uma longa thread sobre o
assunto e uma das explicações (a de que o Mac depende do perl em algumas
partes críticas, e por isto eles querem que vc utilize um perl diferente dos
deles - se é que isto é verdade) me fez concluir que eu também quero isto no
meu sistema. Eu como sysadmin gostaria que a aplicação ficasse contida
inteira no diretório dela, e para isto parece que o perlbrew é o caminho
para isto.

>Não vejo como o CPAN poderia resolver o meu problema e estou inclinado
>a gerar RPMs (preferia gerar .deb mas fazer o que...). Sinto que estou
>olhado o problema pela perspectiva errada, mas começo a concordar que
>servidor de produção não deve ter gcc ou build-essencials e utilizar
>multiplos gerenciadores de pacotes num ambiente sem a disciplina de
>gerência de configuração (pelo menos começamos a usaro Puppet! um
>passo de cada vez...) é complicado para dizer o mínimo.
>

Eu acho que os pacotes deveriam ter alguma inteligência para saber que estou
utilizando local::lib ou perlbrew e instalar o módulos na estrutura local e
não tentar instalar de maneira fixa na área de sistema.

>Sugestões?

=begin disclaimer
  Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
 SaoPaulo-pm mailing list: SaoPaulo-pm em pm.org
 L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
=end disclaimer




-- 
"o animal satisfeito dorme". - Guimarães Rosa
-------------- Pr?xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20110615/bec07b89/attachment.html>