Fevereiro 2008


Tive o prazer de ser envolvido no primeiro projeto em RoR (Ruby on Rails) da empresa, o que me colocou em contato pela primeira vez com essa linguagem. Tenho aprendido muita coisa e cada hora surge uma novidade para ver. Resolvi escrever este post para um probleminha que estávamos tendo e que achei interessante compartilhar.

O “problema” que estavámos tendo e achei muito interessante. Estamos usando o subversion para controle de versão do código e íamos usar o capistrano para fazer deploy deste projeto em particular (e de projetos futuros) nos ambientes de desenvolvimento, qa’ s e produção. A questão é que precisávamos passar o nome de uma tag criada no subversion para o projeto diretamente para o capistrano para que ele fizesse o deploy daquela tag específica. Quem já trabalhou com o capistrano, sabe que no capfile precisamos especificar o repositório que vamos estar trabalhando e que para fazermos o checkout de uma tag qualquer, essa variável deve ser setada dinamicamente, mediante algum parâmetro recebido. Não quero me estender muito, por isso vou direto ao assunto. O trecho abaixo serve para passarmos o nome da tag como parâmetro para o capistrano para que a definição do repositório fique correta.

set :application, "blabla";

tag = (ENV["TAG"] || "")
set :repository, "http://svn.url.com/repo/#{application}/tags/#{tag}"
set :repository, "http://svn.url.com/repo/#{application}/trunk" if tag.empty?

puts "tag: #{tag}"

set :port, 22
set :deploy_to, "/seu/diretorio/para/deploy/#{application}"
set :deploy_via, :copy
set :copy_strategy, :export
set :user,"capitaonascimento"

puts "application: #{application}"
puts "repository: #{repository}"
puts "deploy_to: #{deploy_to}"
puts "ssh user: #{user}"

Como trabalho na area da produção, gosto de ver o que está realmente está acontencendo, por isso coloquei os vários puts para que seja printado na tela o valor de algumas variáveis. Além do mais, isso é uma ótima de forma de debug e verificar se tudo está ocorrendo da maneira que você gostaria. Desta forma, para fazer o deploy do projeto TropaDeElite por exemplo deveríamos fazer: cap deploy TAG=’NOME DA TAG’

É isso… espero ter ajuda. Ahhh, para quem está começando no mundo ruby como eu, o comando set :var_name, “var_data” serve para setar uma variável no capistrano. Para ler essa variável devemos usar #{var_name} e o puts é para printar uma mensagem na console do terminal.

Apesar do JBossWorld ter acabado, vou falar de mais um assunto ligado ao que rolou por lá. Assisti uma session intitulada “Introduction to JBoss Application Server 5.0” apresentada pelo Dimitris Andreadis e achei valeria apena eu falar um pouco do que vi nela, sobre as novidades do JBoss 5.

O Dimitris começou a session contando um pouco sobre a história dos realeases do JBoss lá por volta de 2001/02 (começei a trabalhar com JBoss no ano de 2003). Atualmente o JBoss 5 está na versão beta 4 e segundo o apresentador eles não tem mais intenção de lançar mais muito beta, talvez mais um apenas e só. O objetivo da JBoss é lançar um application server certificado com o Java EE5. Vou listar algumas novidades/melhorias mencionadas na session, lembrando é claro, que todas as features do JBoss 5 não se resumem a que vou listar aqui.

Vamos lá…

  1. Melhorias no mecanismo de clustering, que teve a sua arquitetura revista para melhor utilização dos recursos do servidor (memória por exemplo). O JBossClustering irá permitir definir a granularidade do que irá ser replicado e o que podemos chamar de BuddyReplication, que resumidamente consiste de que cada nó do cluster tenha um par com quem irá replicar os dados, evitando que uma informação seja replicado para todos os nós do cluster e consequentemente diminuindo o tráfego na rede. Aqui vale uma observação, acredio que essa feature possa ser utilizada no JBoss 4.0.x ou 4.2.x, bastando atualiazar o JGroups e o JbossCache.
  2. Melhorias no serviço de mensagens (JBoss Messaging v. 1.4.1) que passará a usar a implementação do JMS 1.1, de performance melhor, permitindo cluster das filas (queues) e tópicos (topics) e redistribuições inteligentes de mensagens.
  3. Failover transparente (essa eu quero ver funcionar mesmo! :) )
  4. JBoss Web 2.1.0 como container web, que nada mais é do que um tomcat 6 turbinado, o pessoal da JBoss costumar dizer “Tomcat on stereoids“. Eles pegaram a api APR da apache e portaram para o tomcat, criando o JBoss Web com uma performance superior ao Tomcat.
  5. Houveram mudanças na arquitetura de deploy.
  6. API de configuração. Essa é a uma feature nova e segundo eu entendi ela irá facilitar a replicação de configurações do JBoss

Bem isso foi tudo que anotei e que me lembro da session. :)

Ahh! outra coisa que falaram é que eles não pretendem mais lançar mais nenhuma versão da família do JBoss 4.0.x (a versão 4.0.5 é a última) e que a família 4.2.x é uma versão intermediária entre as versões do JBoss 4.0.x e o JBoss 5 que está para ser lançado.

Esse link aqui também tem umas informações adicionais: http://www.theserverside.com/news/thread.tss?thread_id=43175

Comprou um iphone com o firmware 1.1.3?

Já fez o desbloqueio dele com o ziphone e ficou eufórico com o unlock?

Já instalou a aplicação de terminal?

Está tendo problemas para logar na console do iphone e ele fica te pedindo a senha toda hora apesar de já ter tentado a alpine e a dottie?

Se sua resposta foi sim para as perguntas acima, pode continuar lendo o post. :) Não vou me estender explicando o motivo para que isso esteja acontecendo e vou apenas dar a solução do problema, que pelo menos funcionou comigo, ou seja, vou direto ao ponto. :) . Obs.: Este procedimento só funciona no 1.1.3

Abra o installer e adicione o source http://trejan.com/irepo. Em seguida instale o “SUID Lib Fix” e o “Term-vt100“.

Feito isso, abra o terminal e se pedir a senha, no meu caso pediu, é só digitar: alpine

Ahhh!! Não se esqueça de alterar a senha padrão do usuário root digitando passwd na console. Não utilize o comando passwd para mudar a senha pois ele não está funcionando corretamente no firmware 1.1.3 e irá quebrar o SpringBoard, ou em outra palavras, ele irá ficar doidão, impossibilitando a utilização do iphone a menos que o formate novamente e instale tudo novamente.

Espero ter ajudado!

Assisti um hands on alucinante sobre o JON, também conhecido como JBoss Operation Network. No hands on foi uma prática sobre os procedimetos básicos para a instalação e operação do JON. Recebemos um DVD com os arquivos a serem instalados durante o laboratório.

Já havia falado do JON, porém não sabia muito bem o que ele podia fazer e se ele realmente iria agregar algum valor na área de Produção. Vamos lá, com o JON podemos…

  • Inventário
  • Automatically discover
  • Cria grupos lógicos de JBoss instalados para facilitar a administração. Ex.: um grupo para o aplicativo A, outro grupo para o aplicativo B e por aí vai
  • Monitoração (Utilizacao de CPU, FileSystem, utilizacao da rede, metricas especificas para o Jboss AS, tomcat, hibernate, apache, postresql)
  • Operação (Start/stop/restart e etc)
  • Configuration (cria/atualiza servicos, i.e, datasources)
  • Deploy de application archives
  • Aplica patchs quando necessário

Fica claro na lista que o JON é uma ferramenta de monitoração e adminstração de Jboss, facilitando e muito a vida de quem precisa lida com o JBoss no dia a dia. Além disso, ele pode ser utilizado para relatórios, plano de capacidade/ocupação, uma vez que os dados coletados pelo JON são guardados num banco de dados (Oracle, Mysql ou Postgresql), havendo portanto um histórico. Basicamente o JON é composto de 2 componentes: o jon server que deve ser instalado em um servidor central qualquer e os agentes que ficam espalhados pelo parque de servidores que rodam JBoss. Como já mencionei antes, só é necessário um agente, mesmo que tivemos mais de uma instância de JBoss instalado. Outra feature interessante, é o que o JON permite a geração de alertas baseadas em thresholds pre-definidos, enviado a notificação por email.

Ele também pode exportar traps SNMP para serem coletados por algum outro serviço, o que em tese permitiria uma integração com o cacti apesar de no fim das contas termos 2 ferramentas para fazer a mesma coisa.

Vamos ao HandsOn!!!

Para instalar o JON precisamos instalar o JON (óbvio!!), o agente do JON, ter o jdk 5 (que eu felizmente já tinha no meu macbook) e um banco de dados. No laboratório acabamos usando o postgresql. O postgresql acabou fazendo com que que eu perdesse um pouco tempo, pois tive que instalá-lo (felizmente o macports me ajudou aí :) ) e configurá-lo. Tive que chamar um dos monitores para dar uma mão, pois eu nao tenho muita experiência com ele e tive que criar um usuário e database para o jon usar na munheca.

Os passos feitos estão na foto acima. Por fim, foi preciso carregar a liçenca fornecida, a qual é válida por 1 mês. Ahhh sim! O JON não é free, e apesar de ser pago, me parece que vale o investimento.

Instalando agente

Na versão 2.0, que ainda é beta, mas que será liberada ainda este ano, não é preciso passar o parâmetro de start. No fim, basta acessar o endereço no qual foi instalado para entrar no JON novamente. Infelizmente, fui nao pude avançar muito no laboratório pois havia perdido um certo tempo no início e quando eu ia começar a brincar com o JON instalado o tempo acabaou! :(

Minha opinião é que o JON é uma ferramenta que iria agregar muito valor na administração e operação dos Jboss, principalemente quando se fala de dezenas de instâncias rodando. :)

Orlando, Florida. Hoje começou o JBossWorld. Agora estou no meio de um brake e aproveitei para escrever um pouco desse primeiro dia. Assisti 3 palestras hoje, 1 muito boa, outra boa e outra ruim.

A palestra muito boa foi a primeira que assisti foi apresentada pelo Bela Ban e era sobre JBoss Clustering. Para quem sabe o Bela Ban é o “pai” do jboss cache. Já havia assistido algumas palestras sobre cluster em outros eventos que participei, mas mesmo assim resolvi ir lá conferir. A palestra começou com o Bela Ban falando um pouco do conceito de jboss clustering para sessões http dentro do JBoss.

Algumas coisas que ele falou já são bastantes conhecidas para quem já configurou um tomcat em cluster, ou seja, colocar a cláusula <distributble/> dentro do web.xml. Ao contrário do que algumas pessoas pensam, não precisamos replicar todos os dados da sessão http a torto e a direita e sim apenas algumas partes da sessão, a partir do que chamamos de granularidade da sessão. No Jbossweb isto deve ser feito no arquivo jbossweb.xml. Outro ponto importante é que se temos um cluster com 8 nós por exemplo e um dos nós tem sua sessão alterada, o dado alterado será replicado para todos os nós do cluster. Isto é ruim, a medida que o cluster se torna maior, devido ao grande número de dados sendo gerados na rede. Como exemplo, tome uma sessão com 2,5kb. No cenário sugerido, teremos a geração de 25kb de tráfego a mais rede, num sistema que na maioria das vezes já está “under pression“. Para tenuar o volume de dados na rede, podemos configurar cada nó do cluster para replicar um dado apenas para um par, o que seria seu backup, no que chamamos de “buddy replication“. Voltando ao papo de granularidade da sessão, podemos configurar o cluster para replicar apenas um atributo da sessão e nao todos os dados da sessão. E ainda, podemos e devemos configura o cluster para replicar uma sessão apenas quando o método SET é invocado, indicando que algum atributo foi alterado. A segunda parte da palestra foi marcada pela apresentação de um benchmark que foi feito com diferentes tipos de configurações. Ficou evidente que o attribute replication foi mais perfomático em conjunto com o buddy replication. Uma observação deve ser feita, o buddy replication gera stress no sistema quando um dos nós cai, pois o cluster precisa ser reorganizado, quem vai replicar para quem, quais são os membros do cluster e etc… Na terceira parte da apresentação foi apresentado algumas dicas para melhorar a performance de um cluster jboss que irei procurar resumir aqui.

  1. MaxClients (Apache) = maxThreads (Jbossweb)
  2. Usar a biblioteca native da APR desenvolvida para o jbossweb
  3. Usar JBoss EAP (JBoss Enterprise Application), dependendo da natureza e criticidade da aplicação
  4. Utilizar a console JMX para obter informações de utilização de cpu e thread dump (kill -3)
  5. Setar timetou para a sessão http
  6. Dar um call invalidate quando terminar de mexer na sessão
  7. Tune logging
  8. Remover do jboss serviços que não serão utilizados
  9. Ter uma rede para as requisições de clientes http, outra para o AJP e outra para o tráfego sendo replicado
  10. Utilizar a feature de domains do mod_jk para criar sub clusters dentro de um cluster

Ufa! Isso foi tudo sobre a primeira palestra, desculpem por ter me estendido tanto. :)

A segunda palestra que assisti foi sobre EJB3. Não gostei da didática do palestrante e ficou tudo muito confuso. A terceira palestra achei muito boa, sobre um produto chamado JON, ou JBoss Operation Networks. Não sei quão estável está esta ferramenta, mas sei que seria muito útil num ambiente de produção, pois ela permite gerenciar instâncias de JBoss instaladas ao longo do parque de servidores de uma empresa, permitindo verificar versão do jboss (fazer um inventário), se a vm está de pé, atualizar a versão do software, entre outras coisas. Sexta-feira, dia 15/02/2008 , haverá um Hands-On sobre esta ferramenta. Basicamente, ela consiste de um agente que é instalado no servidor, responsável pela monitoração da vm do jboss e uma interface web onde são visualizados os dados gerados e/ou obtidos.

Vale ressaltar, que mesmo que tenhamos mais de um jboss instalado só é necessário um único agente rodando, e em tese, eu disse em tese :) , ele iria detectar automaticamente qualquer novo jboss que fosse instalado.

jbossworld2008.png
Logo mais estarei embarcando para o JbossWorld, que irá ser sediado em Orlando na Flórida. Pela agenda, parece ter algumas palestras interessantes. Separei algumas de SOA para ver, perfomance tuning e JbossWeb, que alias já estou um pouco familirizado com ele, mas mesmo assim vou lá para ver o que o Mladen Turk vai falar e ver se alguma coisa mudou. Falando no JbossWeb, ainda vou escrever um post dizendo por que usá-lo no lugar do Tomcat.

Será que conseguiram realmente desbloquear o novo firmware do iphone, de número 1.1.3 via software??? Segundo um post que acabou de sair no engadget parece que sim, e o feito foi feito por George Hotz. Nem o anySim havia conseguido o desbloqueio.

Para mais informações desta notícia juntamente com o procedimento para o desbloqueio, clique aqui. Não sei se realmente funciona, portanto, quem tentar poste aqui dizendo se funcionou ou não. :)

*UPDATE*

Eu havia adicionado um comentário nest mesmo post falando do desbloqueio via ziphone. Resolvi editar o post e colocar mais algumas informações aqui a respeito. O ziphone é uma aplicação gráfica para desbloqueiro do iphone 1.1.2 e 1.1.3. Existem versões para o windows e o para o mac do Ziphone. Para baixar o ziphone, basta clicar aqui.

screenshot2.jpg

O procedimento é bem simples, basta conectar o iphone (em recovery mode) no computador com o cabo usb que vem nele e abrir o programa. Deverá ser selecionado as ações a serem tomadas. Se tudo ocorrer bem, o iphone irá ficar com a tela preta e um monte de mensagens irão aparecer na tela.

Quando o procedimento de desbloqueio terminar, o iphone irá bootar e já irá vir com o aplicativo installer, que server para instalar outros programas. Basta colocar o seu sim card e partir pro abraço!

Ahhh, uma coisa… o iTunes deve ficar desligado durante o procedimento.

Cheers!

Estou usando o apache 2.2.x em alguns projetos novos que estou envolvido na empresa que trabalho. Achei que seria interessante explicar como é feita a configuração para encaminhar as requisições dinâmicas, sejam elas para jsp’s, servelts, ssp’s e etc, para um servidor no backend, podendo ser o Jboss (tomcat) ou o Weblogic utilizando o mod_proxy.

No apache 2.2.x é muito simples e fácil fazer isso, não necessitando nenhum módulo de terceiros como o mod_jk ou o módulo da bea. Podemos usar dois módulos para isso:

  1. mod_proxy_http
  2. mod_proxy_ajp

Particularmente, prefiro usar o mod_proxy para encaminhar requisições para o Jboss/Tomcat. O mod_jk é cheio de burocracia com aqueles seus dois arquivos (worker.properties e jk.conf). :)

Para encaminhar requisições para o jboss podemos usar o mod_proxy_http ou o mod_proxy_ajp. Já para o weblogic, nossa única opção é o mod_proxy_http, visto que o weblogic não suporta o protocolo AJP.

Sugiro que a configuração seja feita no arquivo httpd-vhosts.conf (ou num arquivo a parte) e depois dar um include dele no arquivo httpd.conf, apenas para deixar as coisas mais organizadas.

Segue um exemplo simples utilizando o mod_proxy_http:

ProxyPreserveHost On
ProxyPass /ghi !
ProxyPass /abc http://localhost:8080/abc min=256 smax=512 max=1024 timeout=10 ttl=10
ProxyPass /xyz http://localhost:8080/xyz min=256 smax=512 max=1024 timeout=10 ttl=10

A cláusula ProxyPreserveHost On faz com que o proxy preserve (como o prório nome sugere) o host enviado na requisição. O mapeamento para o Jboss ou Weblogic é feita usando a diretiva ProxyPass, que contém a seguinte sintaxe:

ProxyPass [path] !|url [key=value key=value ...]]

Caso se queira negar uma determinada uri, basta adicionar o sinal de ! no final, caso contrário será necessário especificar para onde será encaminhado a requisição. Lembrando que as urls negadas, e que portanto não deverão ser processadas pelo backend, devem ser definidas primeiro. No exemplo dado, a uri /ghi nao será processada pelo backend. Caso fóssems usar o mod_proxy_ajp basta substituir o http:// por ajp:// e substituir o LoadModule do mod_proxy_http para mod_proxy_ajp.

A partir do Apache 2.2.6 uma nova cláusula foi criada, chamada ProxyPassMatch, permitindo especificar uma expressão regular na definação dos paths que serão jogados para o backend.

Espero que tenha ficado claro…qualquer dúvida, deixe seu comentário.

Ahh!! Mais uma coisa… o módulo mod_proxy existe no apache 2.0.x, porém ele ainda está meio bugado. :)