Aconteceu em março de 2012, no cinemark Downtown Barra a premiação da primeira edição do Javali de Ouro Awards. Trata-se de uma premiação anual da Globo.com para premiar os melhores projetos em diferentes categorias, a saber: Projeto do Ano, Inovação, Melhor Experiência Social, Melhor Engenharia de Software, Melhor Solução em Infraestrutura, Melhor Solução de UX, Colaboração entre times e Disseminação do Conhecimento.

E na categoria melhor solução em Infraestrutura “the Javali de Outro goes to…”

Recebendo a premiação das mãos do Diretor de Operações e Datacenter.

Não tinha a menor expectativa de ganhar, mas acabei vencendo com o projeto Automação com Puppet. Sala do cinema lotada… tive que descer lá para receber o prêmio e depois fazer um discurso. Obviamente eu não tinha planejado e treinado discurso nenhum e ele não saiu bem como eu gostaria.

Quem trabalha com infraestrutura em TI sabe o quão difícil é inovar nesta área. Os profissionais dessa área costumam ser muito resistentes a mudança, principalmente para um projeto como este. Este projeto quebrou muitos paradigmas e mudou a forma que os Sysadmin’s da Globo.com trabalham/enxergam infraestrutura. Trouxe mais agilidade para o dia a dia das pessoas e eu arrisco dizer que ele aproximou Dev’s de Op’s. Antes a configuração dos servidores era uma caixa preta para os desenvolvedores . Com o puppet a configuração, mais do que nunca, passa a ser enxergada como código (Infrastructure as A Code). Além disso, houve uma grande difusão de conhecimento sobre esta tecnologia. Foram feitos inúmeros workshops, treinamentos, techtalks… tudo para “evangelizar”, difundir e consolidar o uso do Puppet dentro da organização.

Premiação Javali de Ouro Awards - Discurso

Até a presente data, mais de 1000 servidores (físicos e virtuais) foram puppetizados na empresa. E mais estão por vir!!

e galera…. inovar é preciso!!

Opa!

Essa semana precisei instalar  rvm no meu macbook. Procurei alguns procedimentos na internet (aka google), e alguns não funcionaram como esperado. Juntei o que cada procedimento tinha de melhor e acabei escrevendo um novo procedimento que me atendeu bem.

Um cara aqui do trabalho acabou batendo cabeça com alguns procedimentos inválidos que ele achou e acabei passando meu para ele… e voilá! Funcionou! Pensei: Bem, se ele teve este problema, outras pessoas podem ter… sendo assim resolvi compartilhar o procedimento aqui também. É bem simples. O rvm será instalado no $HOME do usuário.

mkdir -p ~/.rvm/src/ && cd ~/.rvm/src && rm -rf ./rvm/

git clone git://github.com/wayneeseguin/rvm.git
cd rvm
git checkout 1.8.6
./install

vim ~/.bash_profile ou ~/.profile

#RVM
[[ -s "$HOME/.rvm/scripts/rvm" ]] && source “$HOME/.rvm/scripts/rvm”  # This loads RVM into a shell session.

rvm install 1.8.7
rvm system ; rvm gemset export system.gems ; rvm 1.8.7 ; rvm gemset import system
rvm –default 1.8.7

echo “gem: –no-ri –no-rdoc” >> $HOME/.gemrc

Feito isso, basta abri e fechar o terminal (ou digitar source ~/.profile) e começar a trabalhar com o rvm normalmente. Crie um gemset e comece a utilizá-lo.

Ex.:

rvm gemset create test

rvm gemset use test

Dia desses precisei me aprofundar em como criar types e providers no Puppet. Providers são recursos fornecidos pelo Puppet para gerenciar diversos itens de configuração. Um exemplo é o package: provider para gerenciar pacotes. Ok, mas onde entra o “type” nisso? Ele entra para especificar (ou especializar) o tipo de pacote que se deseja gerenciar. O Puppet fornece alguns tipos por padrão: rpm, yum, gem e etc.

A primeira referência, que por sinal foi muito boa, foi o livro Pro Puppet do James Turnbull e do Jeff McCune. Pesquisando mais um pouco (aka, Google), cheguei no excelente link http://www.masterzen.fr/2011/11/02/puppet-extension-point-part-2 que resolvi compartilhar com vocês.

Foi tudo decidido em cima da hora e cá estou eu para participar da primeira conferência voltada para o Puppet: PuppetConf. Para vocês terem idéia, eu fiquei sabendo que iria vir na sexta-feira, dia 16/09/2011 e depois disso foi aquela correria para fazer inscrição, arrumar as passagens, hospedagem e o adiantamento. Cheguei hoje (quarta-feira, dia 21/09/2011) em Portland e amanhã já começa. Ainda bem que costumo me adaptar rápido ao fuso horário, espero que dessa vez não seja diferente.

Comecei a usar o puppet em 2009, e hoje 2 anos depois, é com muito entusiasmo que fico em poder assistir uma série de palestras dessa tecnologia que mudou a forma com que os servidores são instalados, configurados e mantidos na empresa que trabalho atualmente. Realmente considero o puppet uma ferramenta fantástica e juntamente com o Chef, eles são os big players do mercado para sistemas de gerência de configuração. Já escrevi alguns artigos aqui no blog sobre puppet.

A programação das palestras você encontra aqui. Pela descrição de algumas, vai ter momento que vou querer me dividir em 2!!

Para finalizar este post uma coincidência que aconteceu… Meu aniversário é no dia 6/11, o número do quarto que fiquei é o 611. E eu com isso, certo!? Você deve estar pensando… ))))

Ufa!

problemas com provedor antigo + falta de tempo = site fora do ar por 2 meses!!!

Hoje consegui parar para finalizar a migração para um novo provedor de web hosting.

De volta!!

Ufa! Depois de muita ralação, muitas noites indo dormir tarde, fins de semana estudando e muita dedicação consegui terminar meu mestrado na PUC-Rio no departamento de informática. Devo admitir que foi bastante difícil, pois apesar de atuar no mercado de T.I há anos minha formação é em outra área: Engenharia Eletrônica pela UERJ.

Defendi minha dissertação em junho de 2010, mas só em novembro de 2010 consegui finalizar todos os ajustes que a banca pediu. O título da minha dissertação é: Sobre a Engenharia Semiótica da interação com Sistemas de Monitoração. Tive o prazer de ter sido orientado pela professora Clarisse Sieckenius de Souza, cuja orientação e paciência foram imprescindíveis para a conclusão da minha dissertação.

Apesar de nunca ter estudado ou tido contato na faculdade, a área de concentração da minha pesquisa foi a área de IHC. Para tentar esclarecer um pouco do que se trata, estou copiando um resumo que preparei.

Sistemas de Monitoração de aplicações e serviços na Internet são,
atualmente, fonte de informação e tomada de decisão ágil para Administradores
de Sistemas. Em ambientes com grande volume de acesso e infraestrutura de
centenas de servidores, comunicar eventos com problemas em uma interface
acessível para navegadores Web é um grande desafio de design de interfaces e
interação, principalmente, em situações nas quais informação e decisão sejam
críticas. Nesse sentido, o foco desta dissertação é o estudo de sistemas de
monitoração em uma grande empresa de Internet. Sobre eles, é feita inicialmente
uma avaliação criteriosa e, em seguida, é elaborada, implementada e avaliada a
proposta de um modelo de design para sistemas de monitoração. Este modelo
demonstra como a Engenharia Semiótica, uma teoria semiótica de IHC, pode ser
combinada com elementos de uma teoria da área de fatores humanos e psicologia
ecológica, o Design de Interfaces Ecológicas, para elaborar a comunicabilidade e
interação no projeto de sistemas de monitoração. A combinação destas abordagens
agrega certas características de representação e comunicação às interfaces,
sugerindo que, conforme avaliações realizadas nesta pesquisa, o suporte à decisão
torna-se mais eficiente e ágil para usuários inseridos no domínio estudado.

Caso tenha se interessado ou “curiosidade” basta baixar a dissertação, clicando aqui.

Resolvi escrever sobre uma dica MUITO útil para quem está utilizando o puppet e que com certeza irá evitar alguns problemas no futuro. Trata-se de uma forma para automatizar o teste de sintaxe dos seus arquivos puppet (*.pp) e os templates ERB antes que tais arquivos sejam enviados para o seu puppetmaster. Para fazer isso, você deve utilizar os hooks que tanto quanto o SVN quanto o GIT oferecem. Resumindo, hooks são mecanismos que tais sistemas de controle de versão oferecem para execução de qualquer comando antes ou após a atualização de código no repositório.

git-hooks e puppet

Como utilizo o git como repositório, daqui para frente vou me concentrar apenas nele. O git oferece hooks do tipo pre-commit, post-commit e update. Os primeiros dois hook são do tipo cliente, enquanto que último atua no lado do servidor, isto é, sempre que é feito um git push. Para configurar os hooks do tipo cliente, basta criar o diretório hooks dentro do diretório .git na raiz do projeto e criar os arquivos pre-commit e post-commit. Para habilitar ou desabilitar um determinado tipo de hook, basta adicionar ou remover a permissão de execução do script. Como estamos interessados em rodar um teste de sintaxe nos arquivos puppet e template o hook mais indicado seria o pre-commit, para evitar que sejam comitados códigos com o potencial de quebrar a execução do puppetmaster. O trecho abaixo é o conteúdo do arquivo que venho utilizando.

#!/bin/sh

syntax_errors=0
error_msg=$(mktemp /tmp/error_msg.XXXXXX)

if git rev-parse --quiet --verify HEAD > /dev/null
then
    against=HEAD
else
    # Initial commit: diff against an empty tree object
    against=4b825dc642cb6eb9a060e54bf8d69288fbee4904
fi

# Get list of new/modified manifest and template files to check (in git index)
cmd="git diff-index --diff-filter=AM --name-only --cached $against | egrep '\.(pp|erb)'"
echo "cmd: $cmd"
for indexfile in `git diff-index --diff-filter=AM --name-only --cached $against | egrep '\.(pp|erb)'`
do
    # Don't check empty files
    if [ `git cat-file -s :0:$indexfile` -gt 0 ]
    then
        echo "Arquivo alterado: $indexfile"
        case $indexfile in
            *.pp )
                # Check puppet manifest syntax
                git cat-file blob :0:$indexfile | puppet --color=false --parseonly --ignoreimport > $error_msg ;;
            *.erb )
                # Check ERB template syntax
                git cat-file blob :0:$indexfile | erb -x -T - | ruby -c 2> $error_msg > /dev/null ;;
        esac
        if [ "$?" -ne 0 ]
        then
            echo -n "$indexfile: "
            cat $error_msg
            syntax_errors=`expr $syntax_errors + 1`
        fi
    fi
done

rm -f $error_msg

if [ "$syntax_errors" -ne 0 ]
then
    echo "Error: $syntax_errors syntax errors found, aborting commit."
    exit 1
fi

O script acima irá rodar o teste de sintaxe apenas nos arquivos com extensão pp e erb, que são as extensões mais utilizadas para os arquivos puppet e os arquivos de template do puppet. É necessário ter o puppet instalado na sua máquina. Para isso, veja qual a versão do puppet que o seu servidor puppetmaster está rodando e instale-a com o comando: sudo gem install puppet -v [VERSÃO]

O exemplo de instalação do puppet que dei anteriormente, foi via rubygems, mas ela poderia ser feita de outras formas. (yum/macports/rpm/apt-get e etc).

É isso! Espero ter ajudado!

Se você, assim como eu ficou revoltado em saber que a motorola fez pouco caso dos usuários do milestone na América Latina e no México (vide figura abaixo) e não vai liberar o upgrade do Android 2.2 (AKA Froyo) fique calmo!

Ainda tem uma esperança para ter algumas das principais funcionalidades oferecidas pelo Froyo como por exemplo o Tethering e a possibilidade de instalar aplicativos no cartão de memória. RROOOOTTTTT!!!!!! (Antes de seguir lendo, não custa avisar que essa é uma operação “arriscada” portanto, faça por sua própria conta..  Eu não sou responsável por nada que venha a acontecer no seu milestone, ok? )

É isso mesmo! Só nos resta “rootear” (provavelmente essa palavra não existe…rs) o aparelho. Pesquisando no fórum xda-developers, encontrei um app chamado “Universal Androot”. Basta instalá-lo no seu celular e voialá! Nada de baixa firmware, colocar o celular “recovery mode” ou qualquer coisa parecida… o processo todo é feito pelo próprio aparelho. O passo a passo de como instalá-lo e virar root você encontra no link http://www.addictivetips.com/mobile/how-to-root-android-devices-with-universal-androot-app/. Depois de ter virado root é bom dar um boot no aparelho. Recomendo instalar o programa busybox pelo market… você vai precisar dele no futuro!

Depois quando eu tiver um pouco mais de tempo vou explicar como faz para instalar apps no cartão de memória.. tem vários procedimentos pela internet.. alguns requerem que seja instalada uma ROM específica, mas dá para fazer sem isso.

18/09/2010 (Atualizado) – A motorola (@motorola_br) voltou atrás na sua decisão e informou que lançará a atualização do Froyo (Android 2.2) no primeiro trimestre de 2011.

Fuçando a Internet (AKA Google ) dia desses achei um site que agrega os principais blogs sobre o puppet. Achei a idéia muito interessante e resolvi compartilhar o link aqui no blog. Segue o link: http://www.planetpuppet.org/

Scribe

O scribe é uma aplicação criada e utilizada pelo Facebook para centralização de logs. Existem outras soluções que focam neste mesmo assunto como por exemplo o Splunk e diversas outras com o já conhecido Syslog, ou até o mesmo o Spread. Ainda sobre o syslog, existe um projeto bem legal, o php-syslog ou logZilla, que fornece uma interface web para apresentar as mensagens de log processadas pelo syslog. Essas mensagens são armazenada em um banco de dados MySql.

Já testei o splunk e achei ele excepcional.. com apenas uma ressalva: é pago! O php-syslog também é legal, e dependendo da sua necessidade ele pode atender bem. Para início de conversa acho que uma solução de centralização de logs em um ambiente web e para aplicações que já estão no ar e funcionando, deveria ser não intrusiva na aplicação. Independente da tecnologia que se vá utilizar. O que quero dizer com isso é que deveria-se tentar evitar qualquer alteração na aplicação para que ela enviasse os seus logs para o servidor central A ou B. Se a aplicação já está gerando log em arquivos no filesystem, é bom deixar assim e um outro “processo” por fora se encarrega de enviar o log para o lugar correto.

Bem, voltemos ao scribe… segue a descrição no repositório do próprio facebook.

Scribe is a server for aggregating log data streamed in real time from a large number of servers. It is designed to be scalable, extensible without client-side modification, and robust to failure of the network or any specific machine.

Sua arquitetura é do tipo client-server. Temos um servidor central, ou master, que é responsável por agregar (centralizar) as mensagens enviadas pelos clientes.

No arquivo de configuração, que fica no servidor master, definimos uma série de informações como por exemplo:

• o diretório onde as mensagens serão salvas
• se queremos criar um diretório com o nome do hostname que a mensagem foi enviada
• se vamos querer enviar a mensagem para um outro servidor master
• se vamos querer rotacionar o log
• frequência de rotacionamento
• e etc..etc..etc..

Para saber todos os parâmetros de configuração a melhor forma é consultar o link http://wiki.github.com/facebook/scribe/scribe-configuration

Instalação

A instalação do scribe é meio complicada… ele tem uma série de dependências. Na empresa que trabalho precisei gerar uma série de pacotes rpm para adequar algumas coisas particulares a nossa infra-estrutura. Se você tiver sorte, pode ser que já tenha algum pacote pronto dependendo do SO que você queira instalar o scribe. As principais dependências, na ordem que devem ser instaladas, são:

• python
• libevent
• boost v 1.36
• thrift
• fb303 (incluído no Thrift no diretório contrib/fb303)

Caso precise compilar alguns desses pacotes, é bom dar uma olhada nos argumentos que o ./configure recebe

Configuração do scribe master

A configuração do scribe não é muito complicada (complicado é instalar e compilar as deps). A seguir coloco um exemplo de um arquivo de configuração.

##
## Sample Scribe configuration
##

# This file configures Scribe to listen for messages on port 1463 and write
# them to /tmp/scribetest

port=1463
max_msg_per_second=2000000
check_interval=3

# DEFAULT

category=default

#file
type=file
fs_type=std
file_path=/tmp/scribetest
use_hostname_sub_directory=yes
rotate_period=daily
rotate_hour=23
rotate_minute=59
write_meta=yes
base_filename=test_scribe
max_size=1000000000
add_newlines=0

Acho que o arquivo é autoexplicativo. Copie o conteúdo e salve o arquivo em algum lugar da sua máquina. Em seguida, inicie o daemon do scribe no master com o seguinte comando:

scribed -c [CAMINHO PARA O ARQUIVO]

Configuração do scribe client

Beleza, você já tem o scribe master escutando na porta 1463. Agora precisa enviar mensagens para ele. Aqui vem o pulo do gato. Para enviar mensagens para o master, você deve utilizar a api do scribe para isso. Se você procurar no google vai achar alguns exemplos. Uma solução é criar um script python utilizando uma classe python para tail e a própria api em python do scribe. Desta forma, você poderia utilizar o script como se fosse o comando tail do unix. A medida que novas linhas vão sendo escritas no arquivo elas vão sendo enviadas diretamente para o scribe server.

Ao enviar as mensagens para o scribe master, você precisará especificar no cliente qual categoria no master você estará enviando. O scribe permite você agrupar os logs em categorias. Desta forma logs de um servidor apache poderiam ser enviadas para uma categoria apache por exemplo. Desta forma, quando o master receber mensagens da sua categoria apache, ele vai salvá-las dentro da pasta apache. Isso permite uma melhor organização e estruturação da informação no seu servidor central.

A seguir listo um exemplo de utilização da api python, obtido do próprio repositório do scribe.

#!/usr/bin/python

##  Copyright (c) 2007-2008 Facebook
##
##  Licensed under the Apache License, Version 2.0 (the "License");
##  you may not use this file except in compliance with the License.
##  You may obtain a copy of the License at
##
##      http://www.apache.org/licenses/LICENSE-2.0
##
##  Unless required by applicable law or agreed to in writing, software
##  distributed under the License is distributed on an "AS IS" BASIS,
##  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
##  See the License for the specific language governing permissions and
##  limitations under the License.
##
## See accompanying file LICENSE or visit the Scribe site at:
## http://developers.facebook.com/scribe/

'''scribe_cat: A simple script for sending messages to scribe.'''

import sys
from scribe import scribe
from thrift.transport import TTransport, TSocket
from thrift.protocol import TBinaryProtocol

if len(sys.argv) == 2:
  category = sys.argv[1]
  host = '127.0.0.1'
  port = 1463
elif len(sys.argv) == 4 and sys.argv[1] == '-h':
  category = sys.argv[3]
  host_port = sys.argv[2].split(':')
  host = host_port[0]
  if len(host_port) > 1:
    port = int(host_port[1])
  else:
    port = 1463
else:
  sys.exit('usage (message is stdin): scribe_cat [-h host[:port]] category')

log_entry = scribe.LogEntry(category=category, message=sys.stdin.read())

socket = TSocket.TSocket(host=host, port=port)
transport = TTransport.TFramedTransport(socket)
protocol = TBinaryProtocol.TBinaryProtocol(trans=transport, strictRead=False, strictWrite=False)
client = scribe.Client(iprot=protocol, oprot=protocol)

transport.open()
result = client.Log(messages=[log_entry])
transport.close()

if result == scribe.ResultCode.OK:
  sys.exit()
elif result == scribe.ResultCode.TRY_LATER:
  print >> sys.stderr, "TRY_LATER"
  sys.exit(84)  # 'T'
else:
  sys.exit("Unknown error code.")

Uma vez o log centralizado, fica mais fácil para você tratar o dado bruto armazenado e extrair informações e métricas importantes para a regra de negócio da empresa. Para mais informações, consulte as referências que listo logo a seguir.

Referências

1. http://wiki.github.com/facebook/scribe
2. http://groups.google.com/group/scribe-server/
3. http://github.com/facebook/scribe