Image Image Image Image Image
Scroll to Top

Topo

red hat

03

maio
2012

Sem Comentários

Em Blog

Por Allison

Red Hat abre o código do OpenShift

Em 03, maio 2012 | Sem Comentários | Em Blog | Por Allison

Fonte: IMasters

Com informações de The H

A Red Hat anunciou que abriu o código da Platform-as-a-Service (PaaS) OpenShift. A versão pública do produto, que recebeu o nome OpenShift Origin, pode ser baixada como um live CD baseado no Fedora, que pode ser utilizado para configurar uma instância do OpenShift em uma máquina usando o VirtualBox.

Anunciado há pouco menos de um ano, o OpenShift é baseado na tecnologia da Makara, uma empresa que a Red Hat adquiriu em 2010. A plataforma usa vários aplicativos de código aberto no background e, com o anúncio, a Red Hat abriu o código da interface do usuário e dos componentes que colocam tudo isso junto. A pilha do software do OpenShift é escrita em Ruby e usa YAML para definir os conteiners para aplicativos hospedados na plataforma.

Há várias edições diferentes do OpenShift, que abrangem desde a versão Express, que roda aplicativos escritos em PHP, Ruby e Python, até a versão Flex, que executa aplicativos mais complexos em Java e PHP e os liga ao middleware JBoss da Red Hat. A versão mais completa do OpenShift Power pode rodar qualquer aplicativo que compila no Red Hat Enterprise Linux (RHEL) 4 ou superior. O OpenShift possui opções que unem esses aplicativos em vários bancos de dados, como MySQL, PostgreSQL e MongoDB. Para fazer o deploy na plataforma, os desenvolvedores podem usar Git para colocar seu código na nuvem, e o OpenShift vai lidar com escalonamento e com gerenciamento num segundo plano.

A Red Hat declarou que planeja desenvolver o OpenShift de uma forma parecida com a distribuição Fedora, com o OpenShift Origin sendo o projeto upstream de seu próprio produto comercial. Nessa linha, a empresa está oferecendo facilidades para rastreamento de bugs, hospedagem de projeto e outros suportes para o OpenShift público, como já faz com o Fedora.

O código do projeto OpenShift Origin está disponível no GitHub sob a licença Apache 2.

Tags | , , ,

05

jan
2012

Sem Comentários

Em Blog
Python
Rails
Ruby

Por Allison

Como Ruby vem ganhando a prefrência do Python para administração de sistemas

Em 05, jan 2012 | Sem Comentários | Em Blog, Python, Rails, Ruby | Por Allison

Há cerca de três anos, eu comprei o livro “Python for Unix and Linux System Administration“, e ele me convenceu de que o Python seria a linguagem padrão de scripts para administradores do sistema Linux no futuro próximo. Eu estava trabalhando no projeto One Laptop Per Child (Um Laptop Por Criança) na época, onde o Python era a linguagem comum. Parecia que o Red Hat estava usando o Python para quase todo novo projeto. Além disso, o Unladen Swallow estava fazendo um progresso rápido. Eu não poderia estar mais errado.

Através de uma combinação de acidente histórico e algumas diferenças de recursos aparentemente pequenas, o Ruby está, inexoravelmente, se tornando a linguagem padrão dominante para a administração do sistema Linux.

Antes de eu ir mais adiante, seus administradores de sistema estão provavelmente gritando “Nós já temos uma linguagem de scripts, Bash!”. Mesmo amando Bash e commandlinefu, o Bash se torna uma obrigação, não uma qualidade quando seu script excede 100 linhas, e um completo pesadelo se você precisa analisar ou dar saída em HTML, CSV, XML, JSON etc.

Acidentes históricos

Em 2004, Luke Kanies falou sobre a construção do Puppet, um sistema de gerenciamento de configuração para melhorar as deficiências que ele via na CFEngine. Do excelente blog On Ruby:

Eu tentei implementar minha ideia em Perl, mas eu simplesmente não conseguia fazer os relacionamentos de classe funcionar (todos atributos e tipos de recursos precisavam ser classes, de acordo com o design na minha cabeça). Isso era quando o Python era o melhor, então eu naturalmente o experimentei, mas o Python simplesmente faz meus olhos sangrarem (e não, não era o espaço em branco, eram coisas como o fato de que `print` era uma instrução em vez de uma função, e `len` era uma função ao invés de um método).

Eu tinha um amigo que tinha ouvido falar que o Ruby era legal, mas não tinha de fato testado. Como eu estava simplesmente à toa na época, pensei em dar uma olhada. Quatro horas depois, nunca tendo visto uma linha de Ruby antes, eu tinha um protótipo funcional.

Dois anos depois, muitos desenvolvedores Puppet sentiram que o Puppet não satisfazia suas necessidades. Eles começaram suas própria ferramenta de configuração de gerenciamento, Chef, largamente inspirada pelo Puppet. A grande diferença entre Puppet e Chef é que Chef utiliza Ruby puro como “receita”, enquanto o Puppet usa sua própria linguagem de configuração baseada no Ruby.

Ambos Puppet e Chef estão sendo adotados rapidamente por grandes empresas, de acordo com a BusinessWeek. Se você ainda não estiver usando Puppet ou Chef, você deve começar a planejar a usá-los no futuro. Seja escolhendo Chef ou Puppet, você terá efetivamente o script da sua infraestrutura em Ruby. Depois de gastar 25% do seu tempo trabalhando com Puppet, você estará muito mais inclinado a escolher o Ruby para sua própria tarefa de scripting.

Projetos populares


Aqui está uma lista não definitiva de projetos sysadmin/devops em ruby

  • puppet
  • chef
  • vagrant
  • mcollective
  • cucumber (behavior-driven testing)
  • capistrano
  • rake (ruby Make)
  • aeolus project/openshift
  • cloud foundry
  • graylog2
  • logstash
  • travis-ci

e em Python:

  • openstack
  • cobbler
  • fabric
  • func
  • buildbot

O que é importante aqui não é o comprimento das respectivas listas, mas a importância dos projetos individuais. Chef, Puppet e Vagrant são os novos martelos e chaves-de-fenda da administração de sistemas. Se você for um administrador de sistema e ainda não está usando essas ferramentas, não se preocupe, você irá, cedo ou tarde.

O Openstack merece uma atenção especial, e é um projeto muito animador, mas ainda está no seu estágio inicial. Ele pode representar um papel importante no seu futuro como administrador do sistema.

Por favor, me notifique de projetos devops significantes que estão faltando nessa lista.

O que um administrador de sistema quer

Aqui estão os recursos em uma linguagem script que um administrador de sistema quer:

  • Um DSL para o problema do domínio
  • Alta produtividade, por exemplo, sintaxe expressiva e concisa
  • Fácil interação com comandos shell
  • Expressões regulares
  • Comandos de linha poderosos

Note que desempenho não está na lista de necessidades. O Ruby é acentuadamente mais lento que o Pyhton, e isso era particularmente verdade para a série 1.8.* do Matz Ruby Interpreter (MRI). No entanto, desempenho simplesmente não é algo crítico para 90% do nosso trabalho como administradores de sistema. Nós nos importamos mais com produtividade do que com desempenho. Legibilidade é legal, mas está um segundo distante de produtividade.

O Python não tem expressões regulares nativamente, provavelmente para melhorar a legibilidade. Ele também limita o número de variáveis globais de alto nível embutidas. De uma perspectiva de design de linguagem, isso é muito mais limpo. Da perspectiva do seu administrador de sistema padrão, treinado na rua, estressado, viciado em VI, é irritante.

Essas variáveis de alto nível também deixam as ONE_LINERS mais concisas. Aqui estão algumas.

$_ last line read from STDIN
$? last exit code from a child process
$stdin reference to stdin
$stderr reference to stdout
$stdout reference to stdout

Aqui está uma sessão IRB para mostrar esses valores em ação.

hitman@hiroko:~/pr$ irb
irb(main):001:0> %x[ ls -a ]
=> ".\n..\nfoo1\nfoo2\nfoo3\n"
irb(main):002:0> puts $?
0
=> nil
irb(main):003:0> %x[ ls xys ]
ls: cannot access xys: No such file or directory
=> ""
irb(main):004:0> puts $?
512
=> nil

“IRB?” você me zomba, “Você terá que arrancar o IPython das minhas mãos mortas geladas.”

Eu adoro o IPython. Eu usei o IPython por mais de quatro anos, e o IRB não tem comparação a ele. Dito isso, os atalhos do Ruby são bastante úteis, o suficiente pra compensar as deficiências do IRB. Existe algo chamado wirble que eu ainda não tentei, mas ele pode deixar o IRB bem mais produtivo.

Aqui está algum código Python para detectar se uma máquina é VMware VM.

# edit: fixed python code tks to kstrauser

import os
  if 'vmware' in os.popen('dmidecode').upper():
    print 'this is a vmware vm'
  else:
    print 'this is not a vmware vm'

Aqui está o mesmo código em Ruby:

`dmidecode`
if $_ ~= /vmware/i
   puts 'this is a vmware vm'
else
   puts 'this is not a vmware vm'

Francamente, esse tipo de código faz meus olhos sangrarem. O exemplo do Python é muito mais legível e mais fácil de manter. Dito isso, muitos dos administradores de sistema iriam gostar de quão conciso é o exemplo do Ruby.

Vamos ver como escrever comandos de linha em ambas as linguagens.

O código imprime as primeiras 10 linhas em um arquivo usando Python.

python -c "import sys; sys.stdout.write(''.join(sys.stdin.readlines()[:10]))" < /path/to/your/file

Aqui está o mesmo código em ruby:

ruby -ne 'puts $_ if $. <= 10 ' < /path/to/your/file

Compare você mesmo essas coleções de oneliners no Python e no Ruby. Se o Ruby te lembra o Perl, seus olhos não te enganam. Em muitas maneiras, ele é o filho querido do Perl e do Smalltalk.

DSLs FTW

Há algum tempo, eu tentei assistir a todas as palestras da Structure and Interpretation of Computing. Todo esse esforço falhou miseravelmente, mas eu me lembro de Harold Abelson dizendo que todo grande programa deveria ter seu próprio DSL interno adequado para o problema de espaço. Isso é debatível devido ao grande mundo da programação, mas eu acredito estar apto para a administração de sistemas. Passamos toda nossa carreira com vários DSLs diferentes. Cada formato de arquivo com configuração diferente é seu próprio DSL.

Se você comparar o rake (Ruby Make) ao código rails, eles parecem muito diferentes, quase linguagens diferentes. Se você comparar o código fabric a uma classe django, eles se parecem muito. Isso é uma força e uma responsabilidade. Não sou nenhum advogado de linguagem, mas parece muito mais fácil criar DSLs (Domain Specific Languages). O Ruby certamente gera DSLs com uma frequência muito maior do que o Python. Nenhuma ferramenta de construção do Python domina o problema de espaço como o rake faz na comunidade Ruby. A maioria dos projetos Python parece usar setup.py para tarefas administrativas, mesmo este não sendo seu objetivo explícito.

Ambos, Puppet e Chef são DSL para administração de sistemas. O Capistrano é uma DSL para deploy de aplicações. Sobrecarga de operadores e os blocos do Ruby facilitam a criação de DSLs.

Em resumo

A maior força do Ruby é sua grande flexibilidade. Existe muita “mágica” no Ruby, e às vezes essa magia é negra. O Python intencionalmente tem o mínimo de mágica. Sua maior força é a capacidade de reforçar as boas práticas através da sua comunidade. Essas práticas tornam o Python bastante legível em vários projetos. Eles garantem alta qualidade de documentação, fazendo sua biblioteca padrão arrasar. Mas o fato é que nós sysadmin precisamos de flexilidade mais do que precisamos de poder ou consistência. Mesmo assim, esses não são os motivos reais pelos quais o Ruby está tomando o lugar do Python.

O Ruby está rapidamente se tornando a linguagem de script para os administradores de sistema porque, em 2004, Luke Kanies olhou para o Python e se sentiu doente (eu tive a reação oposta). Como um administrador de sistema, você ou está ou logo estará usando o Puppet ou o Chef diariamente, gastando muito tempo essencialmente codificando em Ruby. Pessoalmente, eu prefiro em Python, mas estou mudando a escrita dos meus scripts para Ruby porque passo muito tempo no Chef.

Texto original em inglês de Bryan Berry, disponível em http://devopsanywhere.blogspot.com/2011/09/how-ruby-is-beating-python-in-battle.html

Fonte: Bryan Willson Berry/IMasters

Tags | , , , , , ,

28

out
2011

Sem Comentários

Em Blog

Por Allison

Zend Apresenta Plataforma de Desenvolvimento phpcloud.com

Em 28, out 2011 | Sem Comentários | Em Blog | Por Allison

Durante a Conferência Zend PHP, que foi realizada em Santa Clara, na Califórnia, a Zend anunciou uma plataforma de desenvolvimento livre de PHP em nuvem, a phpcloud.com. Essa plataforma consiste em dois componentes integrados:o Zend Developer Cloud, um sandbox de desenvolvimento e um conjunto de ferramentas para criar aplicações Web PHP, e o Zend Application Fabric, uma plataforma de aplicativos com base na Amazon Web Services e tecnologias próprias da Zend.

Depois de concluídos, os apps web desenvolvidos em phpcloud.com, podem então ser exportados para outras plataformas em cloud, para a implantação; plataformas suportadas incluem, além da Amazon, IBM SmartCloud, Rackspace e Red Hat. Apps também podem ser implantados em nuvens privadas usando o ZendServer.

O Zend Application Fabric é baseado em tecnologias Zend Server, e é projetado para oferecer desempenho elevado com tempos de resposta rápidos de aplicativos, e para minimizar o uso dos recursos. O sistema suporta um escalonamento on-demand para lidar com processo “on flotation” (demanda flutuante).

Fonte: Under-Linux

Tags | , , , , , , ,

25

out
2011

Sem Comentários

Em Blog

Por Allison

Zend anuncia plataforma de desenvolvimento de PHP em nuvem

Em 25, out 2011 | Sem Comentários | Em Blog | Por Allison

Na Conferência Zend PHP, realizada em Santa Clara, na Califórnia, a Zend anunciou uma plataforma de desenvolvimento livre de PHP em nuvem.

Chamada de phpcloud.com, a plataforma consiste em dois componentes integrados:o Zend Developer Cloud, um sandbox de desenvolvimento e um conjunto de ferramentas para criar aplicações Web PHP, e o Zend Application Fabric, uma plataforma de aplicativos com base na Amazon Web Services e tecnologias próprias da Zend.

O Zend Application Fabric é baseado em tecnologias Zend Server, e tem como objetivo oferecer desempenho elevado com tempos de resposta rápidos de aplicativos, e minimizar o uso dos recursos. O sistema suporta um escalonamento on-demand para lidar com processo “on flotation” (demanda flutuante).

Depois de concluídos, os apps web desenvolvidos em phpcloud.com podem ser exportados para outras plataformasem cloud, para a implantação. As plataformas suportadas incluem Amazon, IBM SmartCloud, Rackspace e Red Hat. Os aplicativos também podem ser implantados em nuvens privadas usando o ZendServer.

Texto publicada em Under-Linux

Fonte: IMasters

Tags | , , , ,