Ontem eu encontrei um post no Google Plus falando sobre a APP COPY, quando olhei, eu pensei que fosse mais uma dessas APP de CLOUD Storage que vão me oferecer míseros 2 gigas, algo que não vale a pena investir já que uso o Dropbox e tenho cerca de 18 gigas atualmente (tudo na base de invites), contudo, vi que eles anunciaram 15GB de cara, isso me deixou bastante interessado e fui olhar de perto.

Por trás do COPY está a empresa Barracuda Networks que possui uma grande experiência com serviços de segurança, rede, armazenamento e backup. No lançamento do COPY eles estavam oferecendo apenas 5 gigas, mas agora estão mais agressivos oferecendo 15 gigas já de início.

A COPY parece ser o primeiro concorrente para valer do DROPBOX, a aplicação é praticamente um clone, tem todas as features do DROPBOX e oferece uma interface web mais polida, além disto, há uma integração com as principais redes sociais (Google Plus, Facebook e Twitter).

Veja abaixo um vídeo sobre o COPY:

2. Sincronização

De ontem para hoje eu instalei no Macbook Pro, Android, IOS e no IMac, já sincronizei dados entre os dispositivos, subi arquivos pequenos e subi uma discografia de 1 GB com vários arquivos mp3, a discografia subiu em menos de 10 minutos, nem preciso dizer que o DROPBOX fica muito atrás na velocidade de UPLOAD e também na velocidade de DOWNLOAD (apesar de ser um ótimo serviço). O Download da discografia em outro dispositivo levou cerca de 25 minutos, demorou mais para descer do que para subir.

2.1 Notificações

Senti falta dos indicadores e notificações nos ícones como temos no DROPBOX, algo como já foi sincronizado (verde), sincronizando (amarelo), isso o Copy ainda não tem.

2.2 Pause Sync

Esse recurso é essencial, não tem no em várias apps de cloud storage, mas vem nativamente no COPY, com isso, se quisermos parar por alguma razão a sincronização é só clicar no PAUSE, acredite, isto é muito útil.

3. Pastas compartilhadas

Ontem também compartilhei uma pasta com a Jéssica (@jemmacedo), fiz isso rapidinho e sem dificuldades, o compartilhamento funcionou muito bem e continua funcionando.

4. Armazenamento

Outra questão interessante, quando você cria a conta já tem 15 Gigas de cara e chegará a 17 gigas fazendo um simples compartilhamento de link em alguma rede social. Você pode também fazer indicações de amigos, mas não é como o DROPBOX que pede acesso a sua conta do GMAIL e sai mandando convites a torto e direito, no COPY é um por um, você preenche nome, sobrenome e e-mail, contudo, cada pessoa que instalar te dá mais 5 GB de espaço enquanto o DROPBOX dá 500MB para a mesma coisa. No momento já estou com 32 GB de espaço por lá.

5. Arquivos públicos

Quando desejar compartilhar um arquivo de forma pública você pode escolher as redes sociais (Facebook, Twitter, Google Plus ou E-mail), é gerado um LINK e este será postado nas redes sociais ou no e-mail.

Compartilhar por e-mail traz as mesmas vantagens do DROPBOX, vai o link apenas e não o arquivo anexo, evitando limitações de anexo e deixando o coitado do administrador do servidor de e-mail mais feliz, afinal e-mail não é para isto.

6. Company

Ele oferece ainda um recurso chamado company, que te permite criar um folder dentro do seu compartilhamento e definir usuários que podem utilizar esse folder, a versão free é bem simples mas existem planos pagos que habilitam mais recursos de controle, e não é cobrado por pessoa como em outros sistemas, é uma taxa única anual, mais simples e honesto - eu acho.

O que isso resolve?

Sabe quando você tem uma conta Dropbox pessoal e não quer misturar com a conta Dropbox de trabalho (é, tem muita gente que tem duas), pelo o que eu entendi o recurso company existe para resolver isto. Ao invés de ficar trocando de contas, o company trata isso de forma elegante - em minha humilde opinião, claro.

Mas isso não é igual a compartilhar uma pasta? Parecido, mas não é igual, afinal você tem mais recursos de controle, como grupos por exemplo, a versão ‘comercial’ ainda oferece revogação de acesso e além disto, o espaço company não usa seu espaço de usuário, aparentemente é um storage separado.

7. Plataformas suportadas

• Linux
• Windows
• OSX
• Android
• IOS

8. Planos

Eles tem dois tipos de planos, o pessoal e o company.

8.1 Personal Plans

• Free 15 GB => Sem custo e pode aumentar conforme indicações.
• Pro 250 GB => U$ 9.9 dólares por mês ou U$ 99.00 por ano.
• Pro 500 GB => U$ 14.99 dólares por mês ou U$ 149.00 por ano.

8.2 Company Plans

• 100 GB => U$ 399.00 por ano
• 250 GB => U$ 699.00 por ano
• 500 GB => U$ 999.00 por ano

8.3 Planos Copy vs Planos Dropbox

Em relação aos planos PRO que são similares ao Personal do COPY

• DROPBOX FREE => 2 GB
• DROPBOX 100GB => U$ 9.99 por mês ou U$ 99 por ano
• DROPBOX 200GB => U$ 19.99 por mês ou U$ 199 por ano
• DROPBOX 500GB => U$ 49.99 por mês ou U$ 499 por ano

O Dropbox tem planos para empresas mas depende da quantidade de usuários, é necessário solicitar um orçamento, contudo, segundo o site do Dropbox, a partir de U$ 785,00 o uso de disco é ilimitado mas não deixa claros se os usuários também.

9. Screenshots

9.1 Web Interface

9.2 OSX Interface

10. Amarrando as pontas

Ainda é cedo para falar bem ou mal, mas estou gostando, o serviço promete, está estável e funcional, e parece que em breve se tornará viral, e isso será um desafio para a equipe que mantém a infra do serviço.

Vale lembrar que o serviço é novo, tem pouca gente usando em comparação com o DROPBOX, se saturar de usuários, poderá ficar igualmente lento, vamos aguardar e acompanhar a evolução do COPY.

11. Referências

• https://www.copy.com
• https://www.copy.com/about
• https://www.copy.com/about/pr
• https://www.copy.com/developer
• https://www.copy.com/about/tos
• https://www.copy.com/about/dmca

O dokuwiki é um sistema de blog que não usa banco de dados SQL, leve, simples e rápido, foi a minha escolha para aposentar o velho mediawiki.

Esse post é uma nota mental para me lembrar dos passos para atualizar o dokuwiki ;)

2. Atualização do dokuwiki

2.1 Backup

Faça o backup do seu dokuwiki.

tar jcvf dokuwiki-AAAA-MM-DD.tar dokuwiki/

Pronto o backup completo está feito, e como não tem banco SQL, é só isso mesmo, está tudo em disco, arquivos texto.

2.2 Download

Faça o download da versão mais nova.

wget http://www.splitbrain.org/_media/projects/dokuwiki/dokuwiki-2013-05-10.tgz

No momento deste post esta é a versão mais nova.

2.3 Atualização

Acesse o diretório do dokuwiki

cd dokuwiki/

Atualize os arquivos

tar -xzvf ../dokuwiki-2013-05-10.tgz --strip-components=1

Pronto, dokuwiki atualizado, essa foi rápida ;)

2.4 Mensagem de upgrade

Pode ser que ele continue mostrando que há atualização, mesmo após atualizar, então você tem duas opções, limpar o cache, aguardar 1 dia ou rodar um touch no arquivo doku.php, eu faço sempre a terceira.

touch doku.php

E pronto, mensagem a de atualização sumiu.

3. Referências

• https://www.dokuwiki.org/changes
• https://www.dokuwiki.org/install:upgrade
• https://www.dokuwiki.org/install:unpacking

Este post é uma nota mental :)

[s]
Guto

LVM significa “Logic Volume Manager”, em português “Gerenciador de volume lógico”, ele gerencia discos e dispositivos de armazenamento em massa. No LVM um volume é o equivalente a uma partição de um disco.

1.1 Usos do LVM

O LVM é muito utilizado em servidores linux por oferecer uma capacidade de ajuste dinâmico de seus volumes.

Se você por exemplo que refazer o desenho de partições de um disco, no método tradicional você precisaria fazer backup dos dados, apagar as partições, criar um novo layout de partições, formatar as partições, reinstalar o sistema operacional e depois ainda fazer o restore dos dados, algo chato e demorado.

Se você utilizar LVM estará administrando seu armazenamento em uma camada de abstração, você trabalhará com volumes físicos (PV), grupos de volumes (VG) e volumes lógicos (LV), guarde esses nomes.

Quando você cria uma partição do disco destinada a uso via LVM esta partição será um PV (Physical Volume), e fará parte de algum VG (Volume Group), já os LV são ‘fatias’ de algum VG.

Um VG pode ser criado com um ou mais PVs e o LVM lhe permite adicionar outros PVs a um VG para aumentar a capacidade de armazenamento quando for necessário.

Imagine um VG como se fosse um grande dispositivo de armazenamento composto por vários PVs, a capacidade total de armazenamento de um VG é a soma da capacidade dos PVs associados a ele.

LVs (Logical Volumes) são fatias do seu VG (volume group), imagine que você tem um VG com capacidade de 100 GB, você pode ter 10 LVs de 10GB ou dois LVs de 50GB, isso é configurável, para o sistema operacional linux, um LV equivale a uma partição de um disco, pode ser formatada e montada da mesma forma que uma partição de um disco comum.

A grande vantagem do LVM é que você pode redimensionar VGs e LVs, aumentando ou diminuindo seu tamanho, e se estiver utilizando um sistema de arquivos que suporte resize, algo como ext3 ou ext4, poderá também aumentar e diminuir o sistema de arquivos sem precisar reconstruir todas as partições e reinstalar seu ambiente.

1.2 Vantagens

Se o seu /var está quase cheio, e se você estiver utilizando LVM, bastará adicionar um novo PV (Physical Volume) ao VG (Volume Group) que possui o LV (Logical Volume) utilizado para o o ponto de montagem /VAR, após aumentar a capacidade do VG, você poderá com poucos comandos - em poucos minutos - aumentar o tamanho do /var sem grandes impactos em seu ambiente.

Especificamente para aumentar ou diminuir o /var, será necessário parar a máquina, mas dependendo da partição não será preciso.

Você pode também diminuir um LV que não esteja usando muito espaço para aumentar outro que esteja precisando de espaço, desde que estejam no mesmo VG.

O LVM torna a administração de partições algo muito flexível.

1.3 Desvantagens

Um VG é composto por PVs, se um PV quebrar você perde o VG e os LVs, isso pode ser um grande problema, portanto, é importante ter confiança nos discos envolvidos em um ambiente LVM.

Se possível é interessante utilizar RAID para poder perder um ou mais discos de um LVM sem perder seu VG inteiro.

Há quem diga também que por ser uma camada a mais em seu ambiente, haverá perda de performance em relação a gravação e leitura em um PV, contudo, acho que isso é imperceptível na grande maioria dos ambientes.

Normalmente o LVM versão 2 já vem instalado na maioria das distribuições linux, em Debian e CentOS está disponível desde a instalação.

2. Mão na massa

Vamos aprender a trabalhar com LVM, no estilo dicas rápidas.

2.1 Criando partição LVM

Vamos particionar o disco sdb como exemplo

fdisk /dev/sdb

Acesse a ajuda

Command (m for help): m

Acompanhe a saída

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Command action
   a   toggle a bootable flag
   b   edit bsd disklabel
   c   toggle the dos compatibility flag
   d   delete a partition
   l   list known partition types
   m   print this menu
   n   add a new partition
   o   create a new empty DOS partition table
   p   print the partition table
   q   quit without saving changes
   s   create a new empty Sun disklabel
   t   change a partition's system id
   u   change display/entry units
   v   verify the partition table
   w   write table to disk and exit
   x   extra functionality (experts only)

Vamos criar uma nova partição

Command (m for help): n

Escolha o tipo de partição

1
2
3

Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended

Eu escolhi primária, as quatro primeiras partições de um disco podem ser primárias, se você pretende ter mais de quatro partições, crie 3 primárias e uma extendida.

Select (default p): p

Esta será a primeira partição

Partition number (1-4, default 1): 1

Agora o fdisk me pergunta em qual setor essa partição deve começar e depois ele também pergunta o tamanho, eu vou dar ENTER e depois ENTER para usar todo o disco a partir do primeiro setor.

1
2
3
4

First sector (2048-125829119, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-125829119, default 125829119):
Using default value 125829119

Agora vou imprimir as partições

Command (m for help): p

Acompanhe a saída

1
2
3
4
5
6
7
8
9

Disk /dev/sdb: 64.4 GB, 64424509440 bytes
255 heads, 63 sectors/track, 7832 cylinders, total 125829120 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xe61fc21b

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048   125829119    62913536   83  Linux

Veja que uma partição foi criada, agora vamos definir o tipo da partição, veja os tipos disponíveis

command (m for help): l

Acompanhe a saída

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

 0  Empty           24  NEC DOS         81  Minix / old Lin bf  Solaris
 1  FAT12           27  Hidden NTFS Win 82  Linux swap / So c1  DRDOS/sec (FAT-
 2  XENIX root      39  Plan 9          83  Linux           c4  DRDOS/sec (FAT-
 3  XENIX usr       3c  PartitionMagic  84  OS/2 hidden C:  c6  DRDOS/sec (FAT-
 4  FAT16 <32M      40  Venix 80286     85  Linux extended  c7  Syrinx
 5  Extended        41  PPC PReP Boot   86  NTFS volume set da  Non-FS data
 6  FAT16           42  SFS             87  NTFS volume set db  CP/M / CTOS / .
 7  HPFS/NTFS/exFAT 4d  QNX4.x          88  Linux plaintext de  Dell Utility
 8  AIX             4e  QNX4.x 2nd part 8e  Linux LVM       df  BootIt
 9  AIX bootable    4f  QNX4.x 3rd part 93  Amoeba          e1  DOS access
 a  OS/2 Boot Manag 50  OnTrack DM      94  Amoeba BBT      e3  DOS R/O
 b  W95 FAT32       51  OnTrack DM6 Aux 9f  BSD/OS          e4  SpeedStor
 c  W95 FAT32 (LBA) 52  CP/M            a0  IBM Thinkpad hi eb  BeOS fs
 e  W95 FAT16 (LBA) 53  OnTrack DM6 Aux a5  FreeBSD         ee  GPT
 f  W95 Ext'd (LBA) 54  OnTrackDM6      a6  OpenBSD         ef  EFI (FAT-12/16/
10  OPUS            55  EZ-Drive        a7  NeXTSTEP        f0  Linux/PA-RISC b
11  Hidden FAT12    56  Golden Bow      a8  Darwin UFS      f1  SpeedStor
12  Compaq diagnost 5c  Priam Edisk     a9  NetBSD          f4  SpeedStor
14  Hidden FAT16 <3 61  SpeedStor       ab  Darwin boot     f2  DOS secondary
16  Hidden FAT16    63  GNU HURD or Sys af  HFS / HFS+      fb  VMware VMFS
17  Hidden HPFS/NTF 64  Novell Netware  b7  BSDI fs         fc  VMware aMKCORE
18  AST SmartSleep  65  Novell Netware  b8  BSDI swap       fd  Linux raid auto
1b  Hidden W95 FAT3 70  DiskSecure Mult bb  Boot Wizard hid fe  LANstep
1c  Hidden W95 FAT3 75  PC/IX           be  Solaris boot    ff  BBT
1e  Hidden W95 FAT1 80  Old Minix

Agora vamos definir o tipo da partição

Command (m for help): t

Escolha LVM (tipo 8e)

Selected partition 1
Hex code (type L to list codes): 8e
Changed system type of partition 1 to 8e (Linux LVM)

Vamos imprimir novamente a tabela de partições do disco

command (m for help): p

Acompanhe a saída

1
2
3
4
5
6
7
8
9

Disk /dev/sdb: 64.4 GB, 64424509440 bytes
255 heads, 63 sectors/track, 7832 cylinders, total 125829120 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xe61fc21b

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048   125829119    62913536   8e  Linux LVM

Ótimo, tudo certo, agora vamos gravar essa configuração no disco

Command (m for help): w

Acompanhe a saída

1
2
3
4

The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

Agora já podemos sair do fdisk

Command (m for help): q

Pronto, para ter certeza que está tudo certo rode o comando abaixo

fdisk -l /dev/sdb

Acompanhe a saída

1
2
3
4
5
6
7
8
9

Disk /dev/sdb: 64.4 GB, 64424509440 bytes
128 heads, 39 sectors/track, 25206 cylinders, total 125829120 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xe61fc21b

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048   125829119    62913536   8e  Linux LVM

Veja que a partição sdb1 foi criada corretamente

2.2 Criando PV

Agora que já temos uma partição LVM, podemos criar um volume físico (PV)

pvcreate /dev/sdb1

Vamos checar os PVs

pvscan

Veja detalhes dos PVs

pvdisplay

Acompanhe a saída

1
2
3
4
5
6
7
8
9
10
11

"/dev/sdb1" is a new physical volume of "60.00 GiB"
  --- NEW Physical volume ---
  PV Name               /dev/sdb1
  VG Name
  PV Size               60.00 GiB
  Allocatable           NO
  PE Size               0
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID               KtmCte-RHtK-XgTi-rLnd-qGL0-0OZe-8KHm4b

Beleza, agora podemos criar um VG

2.3 Criando VG

Depois de criar os volumes físicos, podemos criar os grupos de volume

vgcreate fileserver /dev/sdb1

Verifique os VGs existentes

vgscan

Veja detalhes dos VGs

vgdisplay

Acompanhe a saída

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

--- Volume group ---
  VG Name               fileserver
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  1
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               60.00 GiB
  PE Size               4.00 MiB
  Total PE              15359
  Alloc PE / Size       0 / 0
  Free  PE / Size       15359 / 60.00 GiB
  VG UUID               JYkvTQ-hZ3R-Mib0-tIzm-CXmr-7NWH-UPu8UT

2.4 Adicionando PV a VG

Se você quer expandir o seu VG adicionando outra partição use o comando abaixo

vgextend fileserver /dev/sdc1

2.5 Criando LV

Agora que temos um grupo de volumes, vamos criar um volume lógico

lvcreate --name public --size 40G fileserver

Verique os LVs

lvscan

Veja detalhes dos LVs

lvdisplay

Acompanhe a saída

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

  --- Logical volume ---
  LV Path                /dev/fileserver/fileserver-public
  LV Name                public
  VG Name                fileserver
  LV UUID                Qn8u3P-Olgx-whQE-eLPn-OiaH-eguo-jfM8Vg
  LV Write Access        read/write
  LV Creation host, time debian64, 2013-05-16 11:51:59 -0300
  LV Status              available
  # open                 1
  LV Size                40.00 GiB
  Current LE             39424
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:2

2.6 Formatando a partição

Depois de criar o LV já podemos formatá-lo

mkfs.ext4 /dev/mapper/fileserver-public

2.7 Montando a partição

mkdir /srv/public
mount /dev/mapper/fileserver-public /srv/public   

2.8 Configurando fstab

Verifique o identificador único das partições

blkid /dev/sdb1

Acompanhe a saída

/dev/mapper/fileserver-public: UUID="811782cc-ddc3-43ca-8ba8-f67efa80f229" TYPE="ext4"     

No fstab insira a seguinte linha

UUID=811782cc-ddc3-43ca-8ba8-f67efa80f229 /srv/public               ext4    defaults 0       1

2.9 Aumentando LV (ext4)

Desmonte a partição

umount /srv/public

Vamos estender o volume lógico adicionando mais 114 GB ao LV

lvextend -L +114GB /dev/mapper/fileserver-public

Acompanhe a saída

1
2

Extending logical volume fileserver to 154.00 GiB
Logical volume mirrordata successfully resized 

E depois vamos passar o e2fsck para o verificar o LV

e2fsck -f /dev/mapper/fileserver-public 

Agora vamos aumentar a partição ext4

resize2fs -p /dev/mapper/fileserver-public

Rode novamente o e2fsck para checar a partição que fora estendida

e2fsck -f /dev/mapper/fileserver-public

Monte a nova partição

mount /srv/public

Pronto, partição estendida.

2.10 Diminuindo LV (ext4)

Desmonte o filesystem

umount /srv/public

Antes de prosseguir verifique a partição

e2fsck -f /dev/mapper/fileserver-public

Diminua o LV em 40GB

resize2fs -p /dev/mapper/fileserver-public 40G

Diminua a partição ext4 em 40 gigas

lvreduce -L 40G /dev/mapper/fileserver-public

Verifique a partição

e2fsck -f /dev/mapper/fileserver-public

Rode mais uma vez o o resize para se certificar que partição vai ficar do mesmo tamanho do LV

resize2fs -p /dev/mapper/fileserver-public

Verifique a partição

e2fsck -f /dev/mapper/fileserver-public

Monte a partição

mount /srv/public

Pronto.

3. Referências

• http://www.tldp.org/HOWTO/LVM-HOWTO/

• http://sourceware.org/lvm2/

• http://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux))

• http://pubmem.wordpress.com/2010/09/16/how-to-resize-lvm-logical-volumes-with-ext4-as-filesystem/

• http://www.howtoforge.com/linux_lvm_p2

Primeiro acesse o feed principal e veja que o arquivo chama-se atom.xml

http://gutocarvalho/octopress/atom.xml

Agora ative o feed de categorias no arquivo _config.yml

category_feeds: true

E depois rode um generate e deploy

rake generate && rake deploy

A partir daí basta entrar na página de uma categoria

http://gutocarvalho.net/octopress/categories/puppet

Neste mesmo diretório teremos um arquivo chamado atom.xml, acesse o arquivo para visualizar o feed XML.

http://gutocarvalho.net/octopress/categories/puppet/atom.xml

Simples, rápido e sem gambiarras.

[s]
Guto

1. Instalando chave

1.1 Adicionando chave manualmente

Faça o download da chave e adicionei ao seu chaveiro.

wget http://repo.zabbix.com/zabbix-official-repo.key -O - | apt-key add -

1.2 Adicionando chave via pacote

Faça o download do pacote release

wget http://repo.zabbix.com/zabbix/2.0/debian/pool/main/z/zabbix-release/zabbix-release_2.0-1squeeze_all.deb

Instale o pacote

dpkg -i zabbix-release_2.0-1squeeze_all.deb

Esse pacote além de instalar a chave, já adiciona o repositório, portato se optar por ele, pule o passo 2.

2. Configurando repositório

Adicione a linha abaixo ao sources.list do seu squeeze

deb http://repo.zabbix.com/zabbix/2.0/debian squeeze main

Atualize os índices de pacotes

aptitude update

Pronto, já é possível encontrar os pacotes em uma pesquisa

aptitude search zabbix

Acompanhe a saída

1
2
3
4
5
6
7
8
9
10
11

p   zabbix-agent                                      - network monitoring solution - agent
p   zabbix-frontend-php                               - network monitoring solution - PHP front-end
p   zabbix-get                                        - network monitoring solution - get
p   zabbix-java-gateway                               - network monitoring solution - java-gateway
p   zabbix-proxy-mysql                                - network monitoring solution - proxy (using MySQL)
p   zabbix-proxy-pgsql                                - network monitoring solution - proxy (using PostgreSQL)
p   zabbix-proxy-sqlite3                              - network monitoring solution - proxy (using SQLite3)
p   zabbix-release                                    - Zabbix official repository configuration
p   zabbix-sender                                     - network monitoring solution - sender
p   zabbix-server-mysql                               - network monitoring solution - server (using MySQL)
p   zabbix-server-pgsql                               - network monitoring solution - server (using PostgreSQL)

E podemos verificar a versão

aptitude show zabbix-agent|grep ^Version

Acompanhe a saída

Version: 1:2.0.6-1

Pacotes na última versão

3. Instalando o Zabbix Server

Acompanhe duas formas de instalar o zabbix-server

3.1 Zabbix Server com backend pgsql

Instalando o zabbix server com banco de dados postgresql

aptitude install zabbix-server-pgsql

3.1 Zabbix Server com Backend mysql

Instalando o zabbix server com banco de dados mysql

aptitude install zabbix-server-mysql

4. Instalando Zabbix Agent

Instalando o agente de monitoramento do zabbix

aptitude install zabbix-agent

5. Instalando Zabbix Java Gateway

Instalando o gateway de monitoramento de aplicações JAVA e máquina virtual java.

aptitude install zabbix-java-gateway

6. Instalando Zabbix Proxy

Acompanhe 3 formas de instalar o Zabbix Proxy.

6.1 Proxy com backend mysql

Instalando zabbix proxy com banco de dados mysql

aptitude install zabbix-proxy-mysql

6.2 Proxy com backend pgsql

Instalando zabbix proxy com banco de dados pgsql

aptitude install zabbix-proxy-pgsql

6.3 Proxy com backend sqlite3

Instalando zabbix proxy com banco de dados sqlite3

aptitude install zabbix-proxy-sqlite3

7.Instalando Frontend PHP

Instalando frontend web para configuração e visualização de dados de monitoramento

aptitude install zabbix-frontend-php

8. Instalando Get & Sender

Instalando ferramentas de consulta ao agente (get) e envio de dados (sender) ao servidor.

aptitude install zabbix-get
aptitude install zabbix-sender

Utilizar pacotes facilita e muito a administração de seu ambiente, principalmente em caso de atualização, usar os pacotes mantidos pela zabbix.org é certeza de ter sempre as últimas versões do Zabbix empacotadas.

Se precisa de agilidade use os pacotes/binários, não pense duas vezes.

[s] Guto

1. Criando aside

Vamos criar um arquivo chamado recent_comment.html dentro de /caminho/para/octopress/source/_includes/custom/asides

touch /path/to/octopress/source/_includes/custom/asides/recent_comment.html

2. Adicionando código ao arquivo

1
2
3
4

<section>
  <h1>Recent Comments</h1>
  <div id="dsq-recentcomments" class="dsq-widget"><script type="text/javascript" src="http://disqus.com/forums/gutocarvalho/recent_comments_widget.js?hide_avatars=1;num_items=4"></script></div>
</section>

2.1 Sobre os parâmetros disponíveis

Para esconder avatar

hide_avatars=0 (values : 0 show, 1 hide)

Quantidade de comentários a serem mostrados

num_items=4

Tamanho máximo de caracteres por comentários

xcerpt_length=140

3. Adicione o aside ao _config.yml

Procure o parâmetro default asides e insira após recent_posts.html

custom/asides/recent_comment.html

Após o ajuste a configuração do parâmetro ficará desse jeito

default_asides: [custom/asides/links.html, asides/recent_posts.html, custom/asides/recent_comment.html, asides/github.html, asides/twitter.html, asides/delicious.html, asides/pinboard.html, asides/googleplus.html]

4. Faça o rebuild do seu site

Agora basta fazer o rebuild

rake generate && rake deploy

Após finalizar o comando, você verá o aside funcionando, simples assim.

[s]
Guto

O Festival Latino Americano de Instalação de Software Livre – FLISol é um evento internacional, realizado anualmente, e que ocorre de forma simultânea em diversas cidades da América Latina. O Flisol é um evento descentralizado, onde diversas comunidades organizam e realizam seu festival, de forma voluntária, tendo como principal objetivo promover o uso de software livre, apresentando sua filosofia, alcance, avanços e desenvolvimento ao público em geral.

O Flisol acontece, historicamente, no 4º sábado de abril (em 2006 foi no 25 de março; em 2007, 28 de abril; 2008, 26 de abril; 2009 e 2010, no dia 24 de abril; 2011, no dia 9 de abril; 2012, no dia 28 de abril). O Flisol 2013 está marcado para o dia 27 de abril.

O evento é gratuito e aberto a todo o público: curiosos, interessados e amantes do Software Livre. Nesse dia os voluntários propõe a instalação de Software Livre, como distribuições de Gnu/Linux, sistemas BSD, e aplicativos livres para Windows em geral. Alguns eventos também contam com palestras, oficinas, sala de degustação e gravações de mídias (live-CD/DVD e/ou pendrives).

1.1. FLISOL-DF

A cada ano a organização do FLISOL no Distrito Federal escolhe um local diferente para realização do evento, neste ano o evento será no IESB OESTE – Ceilândia Norte, QNN 31 – Áreas Especiais B/C/D/E, Ceilândia – DF.

Mais detalhes no site http://www.flisoldf.blog.br.

1.2. Lista de atividades

Acesse a lista de atividades do evento e faça sua inscrição nas palestras e oficinas em que deseje participar.

2. Minhas atividades no FLISOL-DF

Eu vou apresentar quatro trabalhos no FLISOL deste ano, veja os detalhes a seguir.

2.1. Monitoramento avançado com Zabbix 2.0

Horário: 11:00hs

Sala: Espaço Ubuntu - Sala BA11 - Bloco B

A palestra tem o objetivo de apresentar a ferramenta de monitoração Zabbix e os seus principais recursos na versão 2.0. A atividade abordará conceitos de monitoramento, fará uma introducão ao zabbix e apresentará os seus recursos comuns. Em um segundo momento demonstrará os novos recursos do zabbix 2.0 como: zabbix distribuído (proxy/node), zabbix monitorando aplicações java com JMX Gateway e tuning de Zabbix para grandes ambientes.

2.2. Oficina de instalação de Zabbix 2.0

Horário: 14:00hs

Sala: Espaço Mandriva - Sala BA5 - Bloco B

Oficina de instalação do Zabbix Server, Zabbix Frontend, Zabbix Agent, Zabbix Proxy e JMX Gateway.

2.3. Infraestrutura ágil

Horário: 15:00hs

Sala: Espaço Fedora - Sala BA6 - Bloco B

Apresentar o conceito de gerência de configurações, orquestração e provisionamento utilizando as ferramentas Puppet e Mcollective. Demonstrar que com o uso destas tecnologias o administrador de sistemas terá condições de administrar centenas de servidores de forma descomplicada, centraliza e ágil. Dentre as principais vantagens no uso de gerência de configurações estão: Diminuição de custos, Diminuição de incidentes, Padronização do ambiente, Diminui o tempo gasto com mudanças, Controle e acompanhamento do ciclo de vida do parque de servidores.

2.4. O que é DevOps afinal?

Horário: 16:00hs

Sala: Espaço Puppy - Sala AA1 - Bloco A

O objetivo é esclarecer de forma objetiva o que significa DevOps, mostrar como esse movimento se iniciou, apresentar suas principais características e indicar um caminho para que se consiga absorver e internalizar essa cultura no ambiente corporativo. DevOps é essencialmente uma cultura que busca entregar sistemas melhores, com menor custo, fazendo isto de forma mais rápida e com menor risco. Dentro de DevOps trabalhamos intensamente automação, principalmente automação de infraestrutura com gerência de configurações, orquestração e provisionamento, falaremos muito de infraestrutura como código.

Nos vemos no FLISOL.

[s]
Guto

Neste post vou agrupar algumas dicas aprendidas no dia-a-dia em produção, são dicas que me ajudaram, espero que lhe seja útil também.

2. Organizando o site.pp

Evite deixar o arquivo site.pp lotado de código, use o recurso import, separe as configurações em arquivos para ficar mais organizado.

1
2
3
4
5
6
7
8
9
10
11
12
13

# /etc/puppet/manifests/site.pp
  
# importando manifests em diretórios

import "nodes/*.pp"      # importando manifest com declaração de nodes
import "classes/*.pp"    # importando classes simples

# importando manifests

import "filebucket.pp"   # importando configurações do filebucket
import "providers.pp"    # importando configurações globais de providers
import "globals.pp"      # importando configuraçoes globais variadas
import "extdata.pp"      # importando configurações de extlookup

Sempre que houver alguma alteração em um manifest importado no site.pp, será necessário reiniciar o puppetmaster ou apache (se estiver usando passenger).

1.1 Arquivo filebucket.pp:

Neste arquivo eu normalmente insiro configurações do filebucket.

1
2
3
4
5
6
7
8
9

# Define the bucket
filebucket { 'main':
  server => puppet,
  path   => false,
  # Due to a known issue, path must be set to false for remote filebuckets.
}

# Specify it as the default target
File { backup => main }

1.2 Arquivo providers.pp:

Neste arquivo normalmente insiro configurações acerca de providers.

1
2
3
4
5
6
7
8
9
10
11
12

case $operatingsystem {
    'Debian': {
        Package { provider => 'aptitude' }
    }
    'RedHat': {
        case $operatingsystemrelease {
            '4'    : {
                Package { provider => 'up2date' }
            }
        }
    }
}

1.3 Arquivo extdata.pp:

Neste arquivo determino o escopo da busca para external data.

1
2

$extlookup_datadir = "/etc/puppet/manifests/extdata"
$extlookup_precedence = ["host/%{fqdn}", "host/%{hostname}", "domain/%{domain}", "env/%{environment}", "common"]

Apesar do recurso extlookup não ser muito utilizado depois da criação do HIERA, ainda tenho módulos que utilizam esse tipo de configuração.

1.4 Arquivo globals.pp:

Neste arquivo coloco configurações globais, normalmente variáveis que possam ser de interesse de vários módulos.

1
2
3
4

$dnssearch = [ 'dominio', 'dominio.com.br', ]
$nameservers = [ '172.16.1.1', ]
$zabbixserver = '192.168.20.134'
$baculaserver = '192.168.20.135'

Lembre-se de declarar corretamente as variáveis de topo de escopo, veja o exemplo abaixo:

$::dnsseearch
$::nameservers
$::zabbixserver
$::baculaserver

1.5 Diretório classes

Neste diretório costumo colocar classes simples, normalmente classes organizacionais que contém outras classes, ou mesmo classes base como a classe linux-server que é carregada em todos os nodes linux sem exceção.

Exemplo de manifest classes/linux-server.pp (classe organizacional):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

class linux-server {

        include hosts             # configura arquivo hosts
        include mailaliases       # configura aliases de correio local
        include utils             # instala pacotes dos sysadmins
        include aptrepos          # configura repositórios apt
        include rcfiles           # empurra screenrc e bashrc do root
        include vimeditor         # instala e configura vim e vimrc
        include ntp               # instala e cofigura ntp server
        include locale            # configura locale
        include timezone          # configure timezone
        include users             # cria usuários dos sysadmins
        include suoders           # configura sudoers
        include ssh:server        # instala e configura ssh server
        include snmp::server      # instala e configura snmp server
        include zabbix::agent     # instala e configura zabbix agent
        include puppet::agent     # configura puppet agent
        include bacula::agent     # instala e configura bacula agent
        include postfix::local    # instala e configura postfix local
}

Exemplo de manifest classes/utils.pp (classe simples):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

class utils { 
 
  # declarando que o tzdata tem que estar sempre em sua ultima versao

  package { 'tzdata': ensure => latest }
 
  # declarando que os seguintes pacotes devem estar presentes (sysadmin packages)

  package { [ 'screen',
    'lynx',
    'elinks',
    'rsync',
    'telnet',
    'ftp',
    'wget',
    'bzip2',
    'unzip',
    'traceroute',
    'tcpdump',
    'iptraf',
    'ccze',
    'htop',
    'less',
    'dnsutils',
    'nmap', ]:
    ensure  => installed,
  }
}

Considero uma classe simples algo que tem um manifest e no máximo um arquivo estático ou dinâmico (template), qualquer coisa maior recomendo construir um módulo, fica mais organizado.

Minhas classes simples utilizam os diretórios abaixo:

/etc/puppet/files      # arquivos estáticos
/etc/puppet/templates  # arquivos dinâmicos

1.6 Diretório nodes

No diretório nodes costumo criar manifests separados para agrupar declarações de nodes em um mesmo contexto, fica mais organizado, fácil de entender e administrar.

Exemplo de manifest nodes/apache.pp:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

node "apache01.dominio" {
   include apache2
   include php5
   include aplicacao
}
node "apache02.dominio" {
   include apache2
   include php5
   include aplicacao
}
node "apache03.dominio" {
   include apache2
   include php5
   include aplicacao
}

Exemplo de manifest nodes/haproxy.pp:

1
2
3
4
5
6
7
8
9
10

node "haproxy01.dominio" {
   include haproxy
   include haproxy::httpmode::phppool
   include haproxy::httmode::phppool
}
node "haproxy02.dominio" {
   include haproxy
   include haproxy::tcpmode::imap
   include haproxy::tcpmode::smtp
}

2 Puppet.conf

Algumas configurações importantes no puppet.conf dos agentes

2.1 runinterval

O parâmetro runinterval define o intervalo entre as checagens que o agente faz ao servidor puppet, neste exemplo ele fará a checagem a cada 3600 segundos ou 60 minutos.

runinterval=3600

2.2 splay & splaylimit

Podemos utilizar o splay para evitar que todos os agentes solicitem o catálogo ao mesmo tempo.

Com esse recurso ativo, o agente vai entrar em sleep quando chegar no momento de consultar o servidor. O agente será acionado dentro da janela splaylimit de forma randômica, isto é fundamental para aliviar a carga no puppetmaster em um cenário com muitos nodes.

Veja um exemplo de configuração de splay:

splay=true
splaylimit=1800
runinterval=3600

No exemplo acima o splay está ligado e o limit está definido para 1800, logo ele vai trabalhar em uma janela de 1800 segundos após o tempo do runinterval ter se esgotado, com isto, o tempo máximo entre checagens poder checar até 5400 segundos ou 90 minutos, lembrando que isso é o tempo máximo uma vez que os acionamentos são randômicos.

3. Módulos

3.1 Pense em bibliotecas

Pense em módulos como se fossem bibliotecas, quando for construir um módulo tente ao máximo construí-lo de forma que se alguém colocar este módulo no diretório /etc/puppet/modules tudo funcione de primeira, sem necessidade de alteração de código, permitindo que alguma funcionalidade nova seja agregada ao seu ambiente de forma simples e direta.

3.2 Carregamento do módulo

Construa módulos que tenham capacidade de serem lidos pelo auto-loader, isto significa que eles devem ter a estrutura recomendada pela puppetlabs.

Módulo que não é carregado pelo auto-loader (jeito antigo):

# /etc/puppet/modules/modulename/init.pp
import "classes/*.pp"
import "definitions/*.pp"

Módulo que é carregado pelo auto-loader (jeito certo):

# /etc/puppet/modules/modulename/init.pp
class modulename {}

Se você construir um módulo incompatível com o auto-loader, você precisa fazer o import no arquivo site.pp

import modulename

Se não fizer isso, o módulo não será carregado, por isto, procure seguir sempre as recomendações e crie módulos compatíveis com o auto-loader.

3.3 Namespace

Ao criar classes em módulos siga a nomenclatura abaixo:

nome_do_modulo
nome_do_modulo::nome_da_classe
nome_do_modulo::nome_do_diretorio::nome_da_classe

Veja o exemplo do módulo apache:

1
2
3
4
5
6
7
8
9

  # /etc/puppetlabs/puppet/modules/apache/manifests
    # init.pp
      class apache { }
    # ssl.pp
      class apache::ssl { }
    # vhost.pp
      define apache::vhost () { }
    # params/confs.pp
      class apache::params::confs { }

Essa estrutura em escopo torna o nome das classes do módulo única, diferenciando dos demais módulos, evitando conflitos e problemas de carregamento, siga sempre esse modelo.

3.4 Forge e Github

Não comece do zero, pesquise e reutilize código existente no Puppet Forge e Github.

3.5 Documentação

Escreva um README detalhado, não deixe de preencher os metadados do seu módulo, crie a documentação de suas classes e definições usando RDoc Markup.

Use os comandos puppet module e puppet doc para lhe ajudar com a documentação.

4. Estilo de código

Acesse a página style guide, ou o meu post guia de estilos para aprender a escrever seus manifests de forma mais eficiente.

4.1 Puppet parser validate

Para validar a sintaxe de código em um manifest você pode utilizar o comando puppet parser, veja abaixo o exemplo:

puppet parser validate manifest.pp

4.2 Puppet-lint

Use o puppet lint para verificar se o seu manifest está com a estrutura de acordo com o style guide do Puppet.

5. ENC (External node classifier)

Instale um ENC em seu ambiente, isto te permite acompanhar o ciclo de vida de seus node, e além disto, oferece controles para associar classes parametrizadas a nodes ou grupos de nodes.

Os ENCs oferecem visualizações de status do seus nodes, é possível visualizar quando ocorreu uma mudança, é possível visualizar erros decorrentes de mudanças, é possível extrair dados (fatos) dos nodes.

Os ENCs mais conhecidos são Puppet Dashboard e Foreman, o que possui mais recursos é o Foreman.

6. Repositório Puppetlabs

Recomendo a utilização de pacotes do repositório oficial da Puppetlabs. Eles oferecem repositórios para Debian, Ubuntu, RHEL, Centos e derivados EL (Enterprise Linux).

Repositório APT

apt.puppetlabs.com

Repositório YUM

yum.puppetlabs.com

7. Passenger

O pacote puppetmaster por default usa um servidor web embutido chamado ‘webrick’, este servidor web deve ser utilizado apenas para fins de desenvolvimento e testes, ele não suportará mais do que 25 conexões simultâneas, e se suportar irá alocar grande quantidade de recursos de seu servidor, gerando extrema lentidão e alto load. Em resumo o puppetmaster usando webrick não escala.

Em ambientes de produção é recomendando utilizar o pacote puppetmaster-passenger que já integra o puppetmaster ao Apache2 com mod-passenger, com isto, sua capacidade e robustez serão equivalentes a capacidade do apache2, este por sua vez é um servidor web reconhecidamente eficaz, rápido e escalável.

O passenger pode ser utilizado inclusive para rodar o puppet-dashboard.

8. Orquestrador e MQ (Message Queue)

É importante ter um orquestrador funcionando, eventualmente pode surgir a necessidade de rodar algum comando de forma paralela e em tempo real em seus nodes, e você não pode ficar na mão nesse momento.

O orquestrador que recomendo é o Marionette Collective (Mcollective ou MCO).

O Mcollective depende de um sistema MQ para funcionar, recomendo o ActiveMQ. É possível utilizar o RabbitMQ, porém o criador do MCO não é muito fã desse projeto, e algumas features do MCO só vão funcionar com ActiveMQ.

Veja o post Intalando o Mcollective em Debian Squeeze para aprender a instalar e configurar este orquestrador.

9. Manuteção em Puppet Dashboard

Se você está utilizando o ENC Puppet Dashboard, tome cuidado como crescimento do banco, se você não configurar o MYSQL corretamente ou não levar em conta espaço em disco, pode ter alguma surpresa depois de alguns meses, além da lentidão, um disk full pode para seu ENC e será trabalhoso resolver o problema.

A puppetlabs oferece um manual com dados e comandos para fazer manutenção na base do dashboard, isto é muito útil e pode te livrar de um grande problema.

9.1 Otimização da base

Para otimizar a sua base, basta rodar o comando abaixo na VM do ENC dentro do diretório do dashboard.

sudo -u puppet-dashboard rake RAILS_ENV=production db:raw:optimize

9.2 Limpeza da base

Para limpar a base e manter os dados dos últimos 30 dias, basta rodar o comando abaixo no diretório do dashboard.

sudo -u puppet-dashboard rake RAILS_ENV=production reports:prune upto=1 unit=mon

9.3 Limpeza agendada

Para inserir uma rotina de limpeza mensal do banco no cron, use o comando abaixo dentro do diretório do dashboard.

sudo -u puppet-dashboard rake cron:cleanup

10. Ambiente Puppet

Dicas gerais:

• Se possível instale o PuppetMaster em uma VM dedicada.
• Se possível instale o ENC em uma VM dedicada.
• Se possível separe o banco do ENC em uma VM dedicada.
• Se possível instale o Orquestrador + MQ em uma VM dedicada.

Não vejo necessidade de rodar o Puppet, ENC ou Orquestrador em máquinas físicas, seu consumo de I/O e recursos não justifica isto, já o banco do ENC é interessante rodar em uma máquina física ligada a um STORAGE com uma LUN em um RAID GROUP com discos rápidos.

10.1 Características

10.1.1 PuppetMaster

Para atender até 1000 nodes.

• 4 Processadores
• 6 Gigas de RAM
• BARRA com 30 GB
• /VAR com 120 GB (no caso de ter storeconfig ligado)
• Distribuição 64 Bits
• Recomendo Debian

10.1.2 ENC (app web sem banco)

Para atender até 1000 nodes.

• 2 Processadores
• 4 Gigas de RAM
• BARRA com 30 GB
• /VAR com 60 GB
• Distribuição 64 Bits
• Recomendo Debian

ENCs: Puppet Dashboard ou Foreman

Dá para colocar o PuppetDB na mesma máquina - se for o caso.

10.1.3 ENC BANCO

Para armazenar dados de até 1000 nodes.

• 4 Processadores
• 6 Gigas de RAM
• BARRA com 30 GB
• /VAR com 300 GB
• Distribuição 64 Bits
• Recomendo Debian

10.1.4 ORQUESTRADOR e MQ

Para orquestrar até 1000 nodes.

• 2 Processadores
• 4 Gigas de RAM
• BARRA com 30 GB
• /VAR com 30 GB
• Distribuição 64 Bits
• Recomendo Debian

ActiveMQ/RabbitMQ, Mcollective Client/Server.

[s]
Guto

Neste post eu vou trazer algumas dicas da puppetlabs sobre estilo de código. No site da Puppetlabs há uma página chamada style guide explicando isto em inglês, eu pretendo me inspirar nesta página e estender as dicas na medida do possível.

O principal objetivo do style guide é apresentar como utilizar a sintaxe do Puppet de forma mais eficiente. Quando usamos a sintaxe coerentemente, temos ganhos na velocidade de processamento de nossos manifests, além disto, nosso código fica mais legível e elegante.

O parser do Puppet é bastante flexível e mesmo quando você produz algo fora padrões esperados, ele consegue entender, processar e aplicar as configurações descritas em seu manifest, contudo, ele levará mais tempo para processar o manifest, logo podemos dizer que certos tipos de código dificultam vida do parser, isto diminui a performance do agente quando ele for aplicar suas configurações, além disto, a aplicação do manifest pode ter algum comportamento inesperado.

Acompanhe o artigo para entender a melhor forma de usar sintaxe do Puppet.

2. Dicas Gerais

2.1 Código de fácil leitura

Se você tiver que optar em escrever um código obscuro e complexo e um código mais legível, procure sempre optar por escrever um código legível, seja para você, seja para outras pessoas. Isto pode parecer subjetivo, mas quando trabalhamos em equipe ou quando compartilhamos nosso código, quanto mais legível melhor. Além disto, isto evita situações em que você relê um código escrito meses atrás e não consegue entender o que estava fazendo.

2.2 Herança em classes

A Puppetlabs em regra geral pede para evitarmos o uso de herança entre classes, eles acreditam que isso dificulta a leitura e o entendimento do código.

Em minha opinião esse recurso pode ser muito útil em alguns casos, logo recomendo que você estude bem como funciona o conceito antes de utilizar, mais a frente voltaremos a falar disto.

2.3 Módulos

Quando for escrever módulos já planeje e desenhe seu módulo primeiro para funcionar com auto loading, segundo para que funcione tanto com um ENC quanto sem um ENC (External Node Classifier). O Foreman e Puppet Dashboard são exemplos de ENC.

Pense também em criar seu módulo utilizando o comando puppet module generate para que você siga a estrutura correta e recomendada, escreva o README bem detalhado e não deixe de preencher os metadados.

2.4 Declaração de classes

Antes de entrar no assunto, vamos entender os conceitos DEFINIR e DECLARAR no universo Puppet.

Quando falarmos definir, significa que vamos escrever nosso manifest, ou seja, vamos colocar código lá.

1
2
3
4
5

class guto {
  user { 'guto':
      ensure => present,
  }
}

Quando falarmos declarar, significa que vamos executar o código de nosso manifest, ou seja, vamos aplicar a configuração.

1

class { 'guto': }

A puppetlabs não recomenda que durante a definição de uma classe, seja feita também declaração de outra classe.

Na minha opinião essa recomendação é feita pois este tipo declaração pode dificultar a ação do parser, aumentando o tempo de processamento do catálogo e além disto, pode gerar algum tipo de comportamento indesejável ao aplicar o manifest.

1
2
3
4
5
6
7
8

class sudo {

  package { 'sudo':
      ensure => present,
  }
  
  class { 'guto': }
}

A declaração de classes deve ser utilizada o mais próximo possível do escopo do node, eles recomendam que sejamos conservadores com isto, contudo, há o recurso include que permite múltipla declaração de classes, se você precisar declarar outra classe, use include ou então verifique se não é melhor utilizar herança.

3. Metadados do módulo

Todo o módulo deve ter um arquivo de metadados, essa é uma recomendação importante principalmente se você deseja compartilhar seu módulo no forge ou github.

Quando você gera seu módulo usando o comando puppet module, o exemplo de metadados abaixo é criado, a partir daí é só ajustar.

1
2
3
4
5
6
7
8

name 'myuser-mymodule'
version '0.0.1'
author 'Author of the module - for shared modules this is Puppet Labs'
summary 'One line description of the module'
description 'Longer description of the module including an example'
license 'The license the module is release under - generally GPLv2 or Apache'
project_page 'The URL where the module source is located'
dependency 'otheruser/othermodule', '>= 1.2.3'

Um guia completo sobre a estrutura de um módulo pode ser encontrado no projeto puppet-module-tool no github.

4. Indentação

Se o seu manifest seguir as recomendações abaixo, estará dentro dos moldes descritos no guia de estilo.

O seu manifest…

• Deve usar two-space soft tab (tab convertida para 2 espaços)
• Não deve usar tab (literal)
• Não deve ter trailing whitespace em seu código
• Não deve extraploar 80 caracteres por linha
• Deve ter todas as setas (comma arrows) => alinhadas

Eu particularmente uso soft tab no vim ou *sublime text 2** com 4 espaços, mas a recomendação deles é clara, 2 espaços para estar dentro dos padrões puppetlabs.

4.1 Puppet-lint

Use o puppet lint para verificar se o seu manifest está de acordo com o style guide do Puppet.

5. Comentários

O Puppet permite vários tipo de comentários, porém o recomendado é utilizar hash.

A forma certa de fazer:

# Este é o tipo comentário recomendado

A puppetlabs não recomenda o uso dos estilos de comentários abaixo:

// Comentário em formato não recomendado
/* Comentário em formato não recomendado */

6. Quoting

Todas as strings que não contenham variáveis devem usar single quotes.

1

'string em single quote'

Quando for necessário interpolar strings e variáveis, use double quoting e chaves nas variáveis para identificá-las.

1

"string e ${variável}"

Valores específicos de atributos não precisam de quote.

1

ensure => present,

O uso de quotes é opcional quando uma string for alfa-numérica e desde que não seja o título de um recurso.

6.1 Interpolação de variável

A forma certa de fazer:

1
2

"/etc/${file}.conf"
"${::operatingsystem} is not supported by ${module_name}"

A forma não recomendada:

1
2

"/etc/$file.conf"
"$::operatingsystem is not supported by $module_name"

6.2 Valor de atributos

A forma certa de fazer:

1

mode => $my_mode

A forma não recomendada:

1
2

mode => "$my_mode"
mode => "${my_mode}"

7. Resources

7.1 Resource names

Todos os resource names devem usar quote, no entanto, o puppet permite o uso de nomes para títulos sem quotes desde que o nome não tenha hífen ou espaços, contudo, para seguir um padrão consistente, use sempre quote.

Variáveis ou fatos não necessitam de quotes quando forem utilizadas como título.

A forma certa de fazer:

1
2

package { 'htop': ensure => present }
package { $package_name: ensure => present }

A forma não recomendada:

1
2

    package { htop: ensure => present }
    package { "${package_name}": ensure => present }

7.2. Alinhamento

Todos os atributos e valores de um recurso devem estar alinhados em seu bloco, as setas devem ter um espaço após o nome do atributo mais longo.

Apesar de ser uma recomendação estética, isto facilita muito a leitura.

A forma certa de fazer:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

package { 'pacote':
       ensure => present,
}

service { 'servico':
  ensure     => running,
  enable     => true,
  hasrestart => true,
  hasstatus  => true,
  require    => Package['pacote'],
}

file { 'main.cf':
  path    => "/etc/pacote/pacote.conf",
  source  => "/root/puppet/pacote.conf",
  owner   => 'root',
  group   => 'root',
  mode    => 644,
  require => Package['pacote'],
  notify  => Service['servico'],
}

A forma não recomendada:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

package { 'pacote':
  ensure => present,
}

service { 'servico':
  ensure => running,
  enable => true,
  hasrestart => true,
  hasstatus => true,
  require => Package['pacote'],
}

file { 'main.cf':
  path => "/etc/pacote/pacote.conf",
  source => "/root/puppet/pacote.conf",
  owner => 'root',
  group => 'root',
  mode => 644,
  require => Package['pacote'],
  notify => Service['servico'],
}

7.3. Ordenação de atributos

Se a declaração de um recurso possuir o atributo ensure, este deve preceder qualquer outro atributo, ele sempre vem primeiro.

1
2
3
4
5
6

file { '/tmp/readme.txt':
  ensure => file,
  owner  => '0',
  group  => '0',
  mode   => '0644',
}

7.4 Múltiplos resources

A puppetlabs só recomenda o uso de múltiplos resources para tornar o código mais legível, portando, evite o uso a não ser que isso seja realmente necessário.

A forma certa de fazer:

1
2
3
4
5
6
7
8
9
10
11

file { '/tmp/a':
  content => 'a',
}

file { '/tmp/b':
  content => 'b',
}

file { '/tmp/c':
  content => 'c',
}

A forma não recomendada:

1
2
3
4
5
6
7
8

file {
  "/tmp/a":
      content => "a";
  "/tmp/b":
      content => "b";
  "/tmp/c":
      content => "c";
}

7.5 Links simbólicos

Apenas para deixar o código mais limpo e legível, recomenda-se declarar o link simbólico de forma explícita.

A forma certa de fazer:

1
2
3
4

    file { '/var/log/syslog':
      ensure => link,
      target => '/var/log/messages',
    }

A forma não recomendada:

1
2
3

    file { '/var/log/syslog':
      ensure => '/var/log/messages',
    }

7.6 File modes

Devemos representar as permissões de arquivos e diretórios com 4 dígitos ao invés de 3 dígitos.

As permissões devem ser declaradas usando single-quote, sempre.

A forma certa de fazer:

1
2
3
4

file { '/var/log/syslog':
  ensure => present,
  mode   => '0644',
}

A forma não recomendada:

1
2
3
4

file { '/var/log/syslog':
  ensure => present,
  mode   => 644,
}

7.7 Resource Defaults

Podemos declarar alguns padrões para uso de recursos, porém, isso deve ser utilizado com cuidado, este tipo de declaração deve ser feita apenas no nível mais alto do seu ecosistema de manifests. Especificamente, eles devem ser declarados:

• No topo de escopo dentro do arquivo site.pp
• Em classes que não serão herdadas
• Em classes em que não você não declara outras classes

Se essas recomendações não forem seguidas poderão ocorrer comportamentos inesperados durante a execução de seus manifests, principalmente se essa configuração for propagada ou herdada de alguma forma.

A forma certa de fazer:

1
2
3
4
5
6

# /etc/puppetlabs/puppet/manifests/site.pp:
File {
  mode  => '0644',
  owner => 'root',
  group => 'root',
}

A forma não recomendada:

1
2
3
4
5
6
7
8
9
10

#/etc/puppetlabs/puppet/modules/ssh/manifests/init.pp
File {
  mode  => '0600',
  owner => 'nobody',
  group => 'nogroup',
}

class {'ssh::client':
  ensure => present,
}

8. Condicionais

8.1 Mantenha suas declarações simples

A Puppetalabs não recomenda misturar resource types e condicionais, isto está bem ligado ao uso de seletores, portanto, faça o tratamento condicional fora do resource type, é mais eficaz do ponto de vista de processamento do catálogo e além disto, fica mais legível e elegante.

A forma certa de fazer:

1
2
3
4
5
6
7
8
9
10

$file_mode = $::operatingsystem ? {
  debian => '0007',
  redhat => '0776',
  fedora => '0007',
}

file { '/tmp/readme.txt':
  content => "Hello World\n",
  mode    => $file_mode,
}

A forma não recomendada:

1
2
3
4
5
6
7

file { '/tmp/readme.txt':
  mode => $::operatingsystem ? {
  debian => '0777',
  redhat => '0776',
  fedora => '0007',
  }
}

8.2 Estado Default em Case e Seletores

Tanto em CASE quanto em SELETORES, podemos utilizar o statement DEFAULT, ou seja, isto determina um valor default se não casar com nenhuma opção do CASE ou SELETOR.

case:

1
2
3
4
5

case $var {
  valor1:  { bloco de código }
  valor2:  { bloco de código }
  default: { bloco de codigo }
}

seletor:

1
2
3
4
5
6

$file_mode = $::operatingsystem ? {
  debian  => '0007',
  redhat  => '0776',
  fedora  => '0007',
  default => '0077',
}

A puppetlabs recomenda que a opção default esteja presente em qualquer tratamento condicional que o suporte, e recomenda ainda que seja associada a função fail, esta função interrompe o processamento do catálogo caso o sistema não seja compatível com o tratamento condicional definido.

exemplo:

1
2
3
4
5

case $::operatingsystem {
  centos, redhat: { $apache = "httpd" }
  debian, ubuntu: { $apache = "apache2" }
  default: { fail("Sistema operacional não reconhecido") }
}

No exemplo acima, o CASE verifica qual é o sistema operacional do node - usando o fato, caso o valor detectado não case com nenhuma das opções do CASE, o default é acionado e executa a função fail, isto interrompe o processamento do catálogo e retorna um erro que poderá ser visualizado em seu ENC ou no log do agente.

9. Classes

Recomenda-se separar classes e definições em arquivos distintos no diretório manifest de seu módulo.

1
2
3
4
5
6
7
8

 # /etc/puppetlabs/puppet/modules/apache/manifests

    # init.pp
      class apache { }
    # ssl.pp
      class apache::ssl { }
    # virtual_host.pp
      define apache::virtual_host () { }

É importante entender que isto não altera em nada o funcionamento do módulo, tem o mesmo efeito de declarar tudo no arquivo init.pp, contudo, separando os arquivos temos uma estrutura que facilita o entendimento e torna o todo mais legível.

9.1 Nomes de classes

Observe que o nome das classes dentro dos arquivos utiliza escopos, a regra é clara, o nome da classe recebe o nome do módulo + o nome da classe, veja o exemplo:

1
2
3

# /etc/puppetlabs/puppet/modules/apache/manifests
 # ssl.pp
  class apache::ssl

Caso você queria criar um diretório para organizar melhor seu módulo a regra passa a incluir o nome do diretório, veja o exemplo:

1
2
3
4

    
# /etc/puppetlabs/puppet/modules/apache/manifests
 # conf/parameters.pp
  class apache::conf::parameters

Essa estrutura em escopo torna o nome das classes do módulo única, diferenciando dos demais módulos, evitando conflitos e problemas de carregamento, siga sempre essa estrutura.

9.2 Organização interna

As classes precisam ser organizadas de forma a manter um estilo e estrutura consistente. Abaixo uma lista com itens importantes encontrados em um classe que foi construída seguindo a lógica do style guide.

A classe…

• Deve definir parâmetros
• Deve validar parâmetros
• Deve interromper a execução em falha de validação
• Deve oferecer parâmetros default
• Pode ter declaração de variáveis locais
• Pode ter relação com outras classes
  • Class[‘apache’] -> Class[‘local_yum’]
• Pode sobrescrever (override) resources
• Pode declarar resources
• Pode declarar relação entre resources dentro de condicionais

Exemplo de uma classe que segue essas recomendações:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

class myservice($ensure='running') {

     # checagem condicional
  
      if $ensure in [ running, stopped ] {
        $ensure_real = $ensure
      } else {
        # interrompendo execução em caso de falta de parâmetro
        fail('ensure parameter must be running or stopped')
      }
      case $::operatingsystem {
        centos: {
          $package_list = 'openssh-server'
        }
        solaris: {
          $package_list = [ SUNWsshr, SUNWsshu ]
        }
        default: {
          # interrompendo execução caso o sistema operacional seja desconhecido
          fail("Module ${module_name} does not support ${::operatingsystem}")

        }

      }

      # variável de uso local
      $variable = 'something'

      Package { ensure => present, }

      File { owner => '0', group => '0', mode => '0644' }

      package { $package_list: }

      file { "/tmp/${variable}":
        ensure => present,
      }

      service { 'myservice':
        ensure    => $ensure_real,
        hasstatus => true,
      }
    }

9.3 Relações encadeadas

O puppet nos oferece duas formas de trabalhar com relações, a primeira é usando meta-parâmetros como require, before, notify e subscribe e a segunda é usando uma cadeia de relações, para entender veja dois exemplos básicos, o primeiro precedência e o segundo notificação.

Precedência via meta-parâmetro

1
2
3
4
5
6
7
8

package { 'httpd':
  ensure => installed,
  before => Service[httpd],
}

service { 'httpd':
  ensure => running,
}

Precedência usando cadeia de relacionamento

1

Package['httpd'] -> Service['httpd']

Notificando via meta-parâmetro

1
2
3
4
5
6
7
8

file { 'httpdconf':
  path   => '/etc/httpd/httpd.conf'
  ensure => present,
  notify => Service[httpd]

service { 'httpd':
  ensure => running,
}

Notificando via cadeia de relacionamento

1

File['httpdconf'] ~> Service['httpd']

Cadeias de relacionamento são recursos úteis mas devem ser utilizados com cuidado, recomenda-se utilizar cadeias com regras da esquera para direta sempre, evite outras variações

A forma certa de fazer:

1
2

Package['httpd'] -> Service['httpd']
File['httpconf'] ~> Service['httpd']

A forma não recomendada:

1
2

    Service['httpd'] <- Package['httpd']
    Service['httpd'] <~ File['httpdconf']

Quando possível, utilize meta-parâmetros ao invés de relacionamento interno.

9.4 Classes internas

No início já falamos disto, devemos evitar criar classes dentro de classes, ou mesmo definições dentro de classes.

A forma não recomendada:

1
2
3

    class apache {
      class ssl { ... }
    }

Outra forma não recomendada:

1
2
3

    class apache {
      define config() { ... }
    }

Prefira sempre criar um arquivo separado e declarar uma única classe ou uma única definição neste arquivo.

9.5 Classes e herança

Herança pode ser usada em módulos, mas deve ser utilizada entre as classes do módulo. Se o seu objetivo é herdar uma classe de outro módulo, pense em usar o include ao invés do inherits. O simples ato de fazer herança entre módulos já viola o proprio conceito de modularidade, evite isto ao máximo.

A forma certa de fazer:

1
2
3
4
5
6
7

    class ssh { ... }

    class ssh::client inherits ssh { ... }

    class ssh::server inherits ssh { ... }

    class ssh::server::solaris inherits ssh::server { ... }

A forma não recomendada:

1
2
3
4
5

    class ssh inherits server { ... }

    class ssh::client inherits workstation { ... }

    class wordpress inherits apache { ... }

9.6 Variáveis e namespace

Quando usarmos váriaveis de topo de escopo ou fatos, devemos declará-las de forma a evitar carregamento de uma variável com o mesmo nome mas em escopo local.

A forma certa de fazer:

1

$::operatingsystem

A forma não recomendada:

1

$operatingsystem

Se não fizermos isto e houver uma variável com o mesmo nome em escopo local, ou seja, se você por alguma razão criou uma variável em um manifest do seu módulo com o nome operatingsystem, por ordem de precedência a variável de escopo local será carregada e não a variável - ou fato - de topo de escopo, desta forma seu código pode ter um comportamento indesejado.

9.7 Nome de variáveis

Quando for definir variáveis, procure usar apenas letras, números e underscore. Não use hífen ou travessão.

A forma certa de fazer:

1

$foo_bar123

A forma não recomendada:

1

$foo-bar123

9.8 Classes e Parâmetros

Em classes parametrizadas e definições, devemos tomar um cuidado especial na hora da declaração. Parâmetros obrigatórios devem ser listados antes de parâmetros opcionais.

A forma certa de fazer:

1
2
3
4
5

    class ntp (
    $servers,
    $options   = "iburst",
    $multicast = false
    ) {}

A forma não recomendada:

1
2
3
4
5

class ntp (
    $options   = "iburst",
    $servers,
    $multicast = false
    ) {}

10. Testes

Todos os manifests de um módulo devem ter um manifest de teste no diretório tests, isso é chamado de smoking test, o objetivo do smoking test é demonstrar como uma classe ou definição deve ser declarada.

exemplo de manifest:

1
2
3
4
5
6

# /etc/puppet/modules/ntp/manifests/init.pp
class ntp {
    package { 'ntp':
        ensure => present,
    }
}

exemplo de smoking test:

1
2

# /etc/puppet/modules/ntp/tests/init.pp
class { ntp: }

11. Puppet DOC

O Puppet Doc é um recurso que nos permite documentar nossas classes e definições utilizando RDoc markup. Esse documentação inline é importante para facilitar a geração de documentação online, isto significa que uma vez gerada, poderá ser extraída pelo própio puppet doc quando desejar informações e comentários das classes e definções de seu módulo.

Modelo para classes:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

# == Class: example_class
#
# Full description of class example_class here.
#
# === Parameters
#
# Document parameters here.
#
# [*ntp_servers*]
#   Explanation of what this parameter affects and what it defaults to.
#   e.g. "Specify one or more upstream ntp servers as an array."
#
# === Variables
#
# Here you should define a list of variables that this module would require.
#
# [*enc_ntp_servers*]
#   Explanation of how this variable affects the funtion of this class and if it
#   has a default. e.g. "The parameter enc_ntp_servers must be set by the
#   External Node Classifier as a comma separated list of hostnames." (Note,
#   global variables should not be used in preference to class parameters  as of
#   Puppet 2.6.)
#
# === Examples
#
#  class { 'example_class':
#    ntp_servers => [ 'pool.ntp.org', 'ntp.local.company.com' ]
#  }
#
# === Authors
#
# Author Name <author@example.com>
#
# === Copyright
#
# Copyright 2011 Your name here, unless otherwise noted.
#
class example_class {

}

Modelo para definições:

“`

# == Define: example_resource
#
# Full description of defined resource type example_resource here.
#
# === Parameters
#
# Document parameters here
#
# [*namevar*]
#   If there is a parameter that defaults to the value of the title string
#   when not explicitly set, you must always say so.  This parameter can be
#   referred to as a "namevar," since it's functionally equivalent to the
#   namevar of a core resource type.
#
# [*basedir*]
#   Description of this variable.  For example, "This parameter sets the
#   base directory for this resource type.  It should not contain a trailing
#   slash."
#
# === Examples
#
# Provide some examples on how to use this type:
#
#   example_class::example_resource { 'namevar':
#     basedir => '/tmp/src',
#   }
#
# === Authors
#
# Author Name <author@example.com>
#
# === Copyright
#
# Copyright 2011 Your name here, unless otherwise noted.
#
define example_class::example_resource($basedir) {

}

“`

[s]
Guto

A proposta da ferramenta é simples, ela indexa suas mensagens de correio do gmail, posts no twitter, status do facebook, dados de arquivos no dropbox, google drive, evernote, dentre outros, e te permite fazer uma busca simples e eficiente de todo o seu conteúdo em nuvem.

Percebi que essa ferramenta ajuda a resolver algumas situações importantes, são elas:

1) Quando você não se lembre exatamente quando você postou um link sobre algum assunto no Facebook ou outra rede social, mas precisa encontrar essa informação.

2) Quando você não consegue encontrar aquele e-mail que você mandou para alguém, o qual havia uma informação importante, porém você se lembra de ter tocado no mesmo assunto em alguma rede social e gostaria de combinar a pesquisa, extrapolando o gmail.

3) Quando alguém disse que você postou algo sobre um assunto mas você não se lembra se foi no twitter, facebook ou por e-mail, e gostaria de rever esse seu post.

Aqui apresentei apenas três situações que já me ocorreram e foram resolvidas usando o CloudMagic.

Atualmente ele consegue pesquisar em muitas redes sociais e serviços CLOUD, abaixo alguns exemplos:

• GMAIL
• GTALK
• EVERNOTE
• DROPBOX
• GOOGLE DRIVE
• GOOGLE APPS
• FACEBOOK
• TWITTER
• ICLOUD
• EXCHANGE
• HOTMAIL
• MSN

Além destas, existem outras redes, acesse o site do cloudmagic para saber mais.

Veja abaixo um vídeo que explica melhor o funcionamento da ferramenta.

A ferramenta é bacana, recomendo.

Até 50 pesquisas por mês é de graça, acima disto custa U$ 4.99 por mês.

Para todas aquelas pessoas que trabalham diariamente em redes sociais (analistas/jornalistas/blogueiros/micro-bloqueiros), esta parece ser uma ferramenta muito eficiente ao preço de um cafezinho expresso por mês.

Fica a dica!

[s]
Guto

Tenho o prazer de anunciar que vamos receber o evento DevOpsDays no Brasil em 2013, o evento irá acontecer no dia 17 de Agosto, a cidade escolhida desta vez foi o Rio de Janeiro.

A chamada de trabalhos está aberta, envie suas propostas, eu já enviei as minhas :)

O Brasil já recebeu este evento em 2010 em São Paulo, agora novamente teremos a oportunidade de trocar experiências sobre a cultura DevOPs.

Para maiores informações acesse o site devopsdays e o blog do evento.

Se você não sabe o que significa devops e não conhece este evento, acompanhe o post que eu escrevi explicando o que é devops para entender melhor o termo e o evento em si.

[s]
Guto

Hoje eu recebi um e-mail em que me fora perguntado se valia a pena usar o Puppet em infra pequena. Esta mesma pessoa mencionou que administra uma infra com cerca e 4 servidores LINUX. Para conseguir responder este tipo de questionamento eu faço sempre uma reflexão e me pergunto quanto vale o meu tempo.

No meu caso, meu tempo é precioso, com ele posso fazer coisas maravilhosas, posso estudar, posso pesquisar, posso testar novas tecnologias, posso documentar, posso ensinar, posso executar projetos e além disso posso ter um tempo de qualidade com minha família, portanto, o meu tempo vale muito.

Sabendo que meu tempo vale muito, e principalmente sabendo que ele pode ser aproveitado de diversas formas interessantes - como mencionei acima, penso que investir cerca de 3 a 4 horas deste tempo para preparar um destes 4 servidores, executando tarefas repetitivas e manuais, não é realmente a melhor forma de aproveitá-lo.

Ao usar o Puppet, mesmo em uma infra pequena, eu conseguirei investir só o que é realmente necessário para aquela tarefa, e farei isso de forma ágil. Ao invés de consumir horas e as vezes dias do meu precioso tempo, eu consigo fazer a mesma tarefa poucos em minutos e poderei utilizar o tempo restante para outras atividades.

É importante entender que além da diminuição de tempo investido em atividades cotidianas, o uso do puppet oferece um maior controle do meu parque, me permite padronizar meus servidores, me permite automatizar atividades e tarefas, me oferece garantia de integridade de minhas configurações, me permite controlar mudanças de forma ágil e segura, principalmente se for um ambiente crítico. O Puppet me ajuda a diminuir o índice de falhas e incidentes, tornando meus ambientes mais disponíveis e estáveis, não importando se eu tenho 4 ou 4 mil máquinas.

Portanto, seu o seu tempo também é precioso, o Puppet é a ferramenta ideal para você recuperá-lo, permitindo inclusive que você passe a agregar valor ao seu negócio e a sua vida, além de deixar seu ambiente muito mais eficiente, ágil e estável.

[s]
Guto

Quando instalei esta APP, entrei em uma fila para ativação, parece que a procura foi tão grande que eles tiveram que liberar o uso aos poucos para não sobrecarregar sua infra.

Em apenas seis semanas após o lançamento eles atingiram a marca de 1 milhão de contas de e-mail configuradas, algo respeitável.

Ontem especificamente percebi que a APP estava liberada para uso, comecei a usar e confesso que gostei da forma proposta pela APP para processar as mensagens, esta APP torna possível zerar sua inbox diariamente, fica a dica.

Veja o vídeo de divulgação do MailApp

Veja o vídeo “Hands On” do pessoal do site “The Verge”.

Para quem estava triste com o fim o Sparrow, parece que o MailApp é um bom substituto para o IOS.

Acesse o blog deles para saber mais => http://www.mailboxapp.com/blog/

A aplicação é FREE e não há mais fila de espera.

[s]
Guto

No Macbook eu instalei o KIES que é o software da SAMSUNG para sincronizar contatos, agenda e afins entre OSX e Android, porém, o KIES funciona de forma bem instável no OSX, além disto, ele só puxa as coisas do OSX para o Android e não manda as coisas do Android para o OSX, ou seja, crei um contato no S3, terei que criar na mão no OSX para que depois ele apareça no iphone via icloud.

Era uma situação bem chata e ficou ainda mais difícil quando coloquei uma ROM personalizada no S3 (cyanogenmod), a partir daí o KIES não reconhece mais seu celular.

Estava quase retornando para a STOCK ROM (firmware do fabricante) quando pesquisando na Google Play achei um software sensacional para resolver este problema.

O Software chama-se ”SmoothSync for Cloud Contacts”, ele foi escrito por Martin Gajda. Este software permite two-way-sync entre seu Android e iCloud. Sincronizar utilizando este método (two-way-sync), significa que se eu criar algo no Android ele vai aparecer no IOS, se eu criar algo no IOS ele vai aparecer no Android.

O software é pago, custa o equivalente a um café expresso com um pão de queijo, logo, na minha opinião compensa muito, comprei e recomendo.

[s]
Guto

[s]
Guto

1. Papo sobre DevOps

Hoje vim falar sobre a buzzword DevOPs. Algumas pessoas tem me procurado pelo blog para conversar sobre este termo, e normalmente eles querem que eu responda as seguintes perguntas:

1. O que significa DevOps?
2. DevOps é um movimento?
3. DevOps é uma filosofia, é um conceito ou uma cultura?
4. DevOps é uma metodologia?
5. DevOps é algum tipo de ambiente ou grupo de ferramentas ?
6. O especialista DevOps é um devel que entende de infra?
7. O especialista DevOps é um sysadmin que entende de devel?
8. DevOps é um cargo? é um setor ou um departamento?
9. DevOps só funciona em startups ou serve para o ambiente corporativo?
10. O DevOps é algo novo?

Ao longo do texto eu pretendo responder a todas estas questões, mas para respondê-las vamos precisar entender algumas coisas antes.

2. Como tudo começou?

Para que possamos compreender de forma plena, precisamos ir ao cerne desta história. O movimento DevOPs não começou em um lugar só, existem muitos lugares que dão pistas sobre as origens do termo, mas aparentemente as informações mais concretas sobre as origens deste movimento nos levam ao ano de 2008. Neste ano, começaram a utilizar o termo infraestrutura ágil em algumas listas de discussão com foco em desenvolvimento ágil, e na mesma época durante evento Agile 2008, surgiram conversas que abordavam o tema metodologia ágil para a administração de infraestrutura, inspirada no modelo ágil de desenvolvimento, no entanto, foi a lista de discussão européia com nome agile-sysadmin que começou a abordar o tema com propriedade, com isso ela ajudou a colocar os primeiros tijolos na ponte que faria a ligação entre developers e sysadmins. Um dos participantes desta lista era Patrick Debois (@patrickdebois), além de muito ativo ele era e ainda é um grande entusiasta do assunto.

O termo DevOPS só foi criado de fato em 2009 durante a conferência Velocity da O’Reilly, nesta conferência John Allspaw (Etsy.com) e Paul Hammond (Typekit) apresentaram o trabalho 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr, veja abaixo os slides desta palestra.

A palestra acima deixou Patrick Debois muito animado, foi então que ele teve a ideia de criar um encontro chamado DevOpsDay, este encontro ocorreu em Ghent no final de 2009, foi um encontro de dois dias e aparentemente foi lá que tudo começou.

De lá para cá, Patrick Debois, Gildas Le Nadan, Andrew Clay Shafer, Kris Buytaert, JezzHumble, Lindsay Holmwood, John Willis, Chris Read, Julian Simpson, R.I.Piennar (mcollective) e muitos outros levaram o evento para diversas localidades, dentre elas:

• New York 2012
• Rome 2012
• Mountain View 2012
• India 2012
• Tokyo 2012
• Austin 2012
• Goteborg 2011
• Bangalore 2011
• Melbourne 2011
• Mountain View 2011
• Boston 2011
• Göteborg 2011
• Sao Paulo 2010
• Hamburg 2010
• Mountain View 2010 (video intro)
• Sydney 2010
• Ghent 2009

É importante falar que ao levar o evento para diversos países, estas pessoas foram responsáveis por disseminar a cultura DevOps pelo globo, com isso, direta ou indiretamente eles se tornaram a força motriz de uma discreta revolução no mundo da TI.

Inicialmente a cultura DevOps se mostrou muito presente no ambiente das startups, porém, algum tempo depois começou a fazer parte do mundo corporativo, aqui neste texto procuro trazer a visão da cultura DevOps no meio corporativo.

Na abertura do evento DevOpsDay há sempre um vídeo de intro, veja dois deles:

Ghent 2009

Mountain View 2010

3. DevOps Manifest

Apesar de terem organizado o DevOpsDays em diversos países, não foi estabelecido um manifesto para o assunto, logo existem muitas interpretações acerca deste termo.

Mas antes de argumentar acerca do possível conteúdo de um manifesto DevOps, primeiro temos que entender a dinâmica na relação entre as áreas de infraestrutura (infra) e desenvolvimento (devel).

4. Analisando Infra e Devel

Para entender melhor o que DevOps significa, precisamos então analisar de forma prática e direta a vida de sysadmins, desenvolvedores e o cotidiano destas áreas, eu espero que isto lhe ajude a compreender melhor o assunto adiante.

Vamos imaginar - hipoteticamente - uma empresa de comunicação que desenvolve aplicações web em sua maioria para portais de notícias, e em alguns casos também faz aplicações web internas (rh, financeiro, administrativo), nessa empresa o devel trabalha com PHP, PYTHON, RUBY e JAVA.

Para um melhor entendimento, considere as duas características abaixo como cotidianas nesta empresa fictícia:

1. O Devel está começando a trabalhar com metodologias ágeis (pró-ativo, evolutivo e contínuo).

2. A Infra continua trabalhando no modelo tradicional de administração (manual, caótico e reativo).

4.1 Infra em foco

A infra é composta em parte pelos sysadmins, estes rapazes e moças tem a missão de manter os sistemas funcionando, são eles que fazem os deploys e os rollbacks das aplicações do devel, é responsabilidade deles manter o ambiente de produção intacto.

Os sysadmins tem que rodar as aplicações, monitorar o funcionamento, a performance, avaliar e propor melhorias de forma a manter as aplicações sob seu cuidado a pleno vapor - rodando de forma rápida e estável, além disto, eles devem planejar as mudanças com cautela, tentando minimizar os riscos envolvidos.

Eles se preocupam com segurança, estabilidade e principalmente com o acordo de nível de serviço (SLA) de cada produto sob sua responsabilidade, esta preocupação é fundamental para o negócio.

Entenda que se uma aplicação parar de funcionar isto vai impactar no SLA, podendo significar perdas financeiras significativas relacionadas ao produto, afinal produto fora significa cliente insatisfeito e prejuízo, seja ele financeiro, seja ele institucional, e no caso da sustentação do produto, isto significa que a prestadora do serviço, neste caso a empregadora dos sysadmins, pode ser multada. De toda o jeito, o que ocorre de forma direta é diminuição do valor do negócio.

Em resumo, a infra (sysadmins) se preocupa em proteger o valor do négocio.

4.2 Devel em foco

O devel é composto em parte por desenvolvedores, estas moças e rapazes trabalham com lógica e criatividade, eles passam boa parte de seu tempo codificando soluções, e focam seu trabalho nos requisitos que o analista conseguiu mapear junto ao cliente.

Os desenvolvedores estão constantemente criando e aprimorando suas aplicações, com isto novas versões são criadas e precisam ser disponibilizadas, assim seus clientes poderão usufruir dos recursos solicitados.

Nova versão significa novo deploy, e caso ocorra algum problema, isto irá demandar um rollback, ambos procedimentos envolvem equipes de infra.

Em resumo, podemos dizer que o devel se preocupa em aumentar o valor do negócio.

4.3 Onde está o conflito?

Os desenvolvedores querem colocar suas aplicações no ar o mais rápido possível, no entanto os sysadmins querem ter certeza que a aplicação está estável o suficiente para entrar em produção sem gerar incidentes.

Nos últimos anos esse conflito foi latente no mundo de TI, algumas empresas tinham regras tão rígidas que só permitiam deploy uma vez por semana - em casos mais rígidos apenas uma vez por mês, tudo isto pensando em proteger o negócio.

Com o devel mudando de metogologia, nem preciso dizer que esse método de deploy - uma vez por semana - não combina com desenvolvimento ágil, com isso a infra teve que evoluir a fórceps, e quem antes fazia deploy uma vez por semana, teve que aprender a fazer várias vezes por dia.

É claro que a infra trabalhando com os métodos que estava acostumada (deploy 1 vez por semana e manual) não dava vazão as demandas, e também é óbvio que o devel não possuía uma infra adequada para fazer o desenvolvimento de forma contínua.

Além de tudo isso, normalmente o devel não conhece e não tem como prever aspectos importantes relativos a infra que fica de cara para o cliente, portanto, quando a aplicação vai para produção, normalmente ocorrem - constantes - pequenos incidentes que geram uma enorme perda de valor no negócio. Traduzindo, são aqueles ajustes na aplicação que precisam ser feitos de última hora pois o ambiente devel é completamente diferente da produção.

O cliente por sua vez reclama - com razão - e depois a gerência de TI ficava tentando encontrar o dono do problema (caça as bruxas), de um lado devel dizendo que infra é engessada, lenta e que não oferece um ambiente adequado para desenvolverem suas aplicações, do outro lado a infra dizendo que o devel faz código ruim e instável e que não é culpa deles se a aplicação não funciona.

Eu sou de infra há muitos anos, mas tenho que dizer que a infra devido a culturas arcaicas de administração, heranças do tempo dos mainframes, tem mais culpa no cartório neste cenário, porém o devel também tem seus problemas, afinal, como estão começando a aplicar métodos ágeis, ainda estão criando a cultura de execução de testes e garantia de qualidade (QA).

4.3.1 Incidentes

Quando ocorre algum incidente, você vai ouvir da infra falando para o devel que o problema não são as máquinas, é o código, e certamente o devel vai falar para infra que o problema não é o código, são as máquinas, e provavelmente ainda vão dizer que o sistema está funcionando no notebook deles, e infelizmente isso será algo cotidiano.

Espero que neste ponto você já esteja enxergando o problema.

É preciso entender que infra e o devel trabalham em nichos, cada um no seu quadrado, cada um em sua realidade e nenhum deles está muito disposto a mudar sua cultura, nenhum deles está disposto a ceder. A infra não conhece o devel e não sabe como mudar para ajudá-los, o devel não conhece a infra e não sabe como pedir o que precisam.

No final das contas, as pessoas não conseguem estabelecer uma forma sadia e eficiente de comunicação, e com isso, não existe trabalho colaborativo entre estas duas áreas.

4.4 O combustível do conflito

Acima eu apresentei o conflito comum entre as áreas, porém existe o combustível que o mantém acesso, e esse combustível é o comportamento do sysadmin, portanto, há de fato uma razão para se ter tanto ódio deles, vamos a elas:

• Eles falam não
• Eles falam não pela segunda vez
• Eles falam não pela terceira vez
• Eles falam não o tempo todo por diversas razões, para diversos pedidos
• Eles demoram, atrasam e perdem prazos de atendimento
• Eles se recusam a quebrar as coisas mesmo que seja para encontrar o problema
• Eles se preocupam com UPTIME e não com o negócio
• Eles acham que o devel só quer saber de perfumarias e coisas do gênero
• Eles não se esforçam para ajudar o devel a encontrar o problema
• Eles acham que o problema do devel não é problema deles
• Eles não conseguem enxergar o negócio e não enxergam que infra e devel são parte de um todo

E isso tudo faz parte daquele comportamento arcaico que eu já mencionei, eu quis reforçar isto pois é bom mostrar as raizes de um problema para ajudar na reflexão do que é preciso mudar.

Veja que tal comportamento é inaceitável e incompatível com o mundo de hoje, mesmo assim ainda é muito comum encontrar pessoas que possuem este tipo de atitude e perfil.

4.5 Uma pitada de realidade

Lembra que eu disse que a infra se preocupa em proteger o negócio e o devel se preocupa com as formas de agregar valor ao negócio?

Esqueça o que eu disse, isso funcionava nos anos 70/80/90, mas hoje isso não é suficiente.

A infra deve entender que sua obrigação é oferecer os meios para fazer o negócio fluir, e isso também é papel do devel.

Ambas equipes precisam mudar a forma de pensar e de agir, porém é preciso ter consciência de que mudanças estão associadas a problemas, uma mudança pode quebrar seu produto e afetar o seu negócio.

Então qual é a receita mágica?

Como mudar sem afetar o negócio?

4.6 Mudanças necessárias

A infra previsa evoluir, e precisa fazer isto rapidamente.

O devel predisa ter controle de todas as fases do deploy.

A infra precisa começar a trabalhar de forma automatizada e dinâmica, precisa ser mais veloz para subir novos ambientes ou mesmo reconstruir/duplicar os ambientes existentes para suprir as necessidades do devel, não dá mais para trabalhar de forma manual e usar as mesmas metodologias da época dos mainframes.

O devel precisa conseguir passar para infra suas necessidades de forma clara, e tem que se esforçar para fazer a infra entender isto - e eles não vão entender na primeira vez.

4.6.1 Busca de soluções

E foi a busca de soluções para estas necessidades que motivou importantes discussões no mundo da TI, foi então que começaram a falar de ‘Infraesturura ágil’ no ano de 2008, vamos agora entender o que é isso.

5. Infraestrutura ágil

5.1 Infraestrutua como código

A discussão acerca de infraestrutura ágil ganhou força com o crescimento de duas tendências, são elas virtualization e cloud computing. Desde 2003 empresas começaram a conviver com ambientes virtualizados, logo um parque com poucas máquinas físicas poderia se tornar um parque com dezenas máquinas virtuais, e após o recente advento da Cloud, dezenas de máquinas virtuais podem se tornar centenas ou milhares de instâncias a serem administradas na nuvem.

Não havia mais espaço para se trabalhar infraestrutrua da forma tradicional, foi necessário dar um passo a diante e pensar em infraestrutura como código, principalmente quando paramos para analisar o recente boom das startups, empresas pequenas com produtos de enorme alcance, produtos que rodam em centenas de instâncias na nuvem, atendendo milhões de usuários, e tudo isso é administrado por equipes mínimas.

O objetivo é fazer deploy não só de aplicações, mas deploy de infraestrutura de forma rápida e controlada.

Isso significa que se você precisa subir um ambiente JBOSS você vai fazer isto em poucos minutos e não em dias.

5.2 Ferramentas de infraestrutura ágil

Quando se fala em infraestrutura ágil o que vem a mente são ferramentas, e de fato elas são parte disto.

Basicamente temos três tipos de ferramentas, são elas:

1. Orquestradores
2. Ferramentas para gerenciamento de configurações
3. Ferramentas para bootstrapping e provisionamento

Orquestradores são ferramentas que nos permitem executar comandos e controlar nodes/instâncias de nosso parque em tempo real. Alguns destes são Fabric, Capistano, Func e Mcollective.

Ferramentas de gerência de configuração normalmente controlam estados de seu sistema, ajudam a centralizar toda as configurações e facilitam a administração e criação de novos ambientes. Algumas delas são Puppet, Chef, Cfegine e Salt.

Ferramentas de bootstrapping são aquelas que nos ajudam a instalar um sistema operacional seja em uma máquina física, seja em um máquina virtual, seja em uma instância na nuvem, dentre elas temos alguns provedores de CLOUD como AWS e Rackspace que já oferecem isso nativamente, existem também ferramentas como o Kickstart e Cobbler que atuam neste segmento.

A combinação destes três tipos de ferramentas nos permite ter o que chamamos de infraestrutura ágil.

Mas apesar da qualidade e dos ganhos em utilizar tais tecnologias, a ferramenta sozinha não resolverá seus problemas, é preciso mudar a cultura e a forma de trabalhar a infraestrutura.

5.3 Equipe de infraestrutura ágil

Equipes que trabalham com infraestrutura ágil também precisam de um método diferenciado de organização, normalmente estas equipes estão trabalhando seguindo estes eixos:

1. Versionamento do código e arquivos de configuração (git)
2. Organização de atividades de forma visual (KANBAN BOARD)
3. Trabalho em pares
4. Divisão das atividades em sprints
5. Reuniões ágeis diárias (standup meeting de 10 minutos - em pé)
6. Reuniões ágeis periódicas (retrospectiva e planejamento de sprints).

Parece com SCRUM mas não é, mas é fortemente inspirado nele e no Kanban.

5.4 Então DevOps e Infraestrutura ágil são a mesma coisa?

Não, infraestrutura ágil é parte da cultura DevOps.

DevOps depende de infraestutura ágil, mas ainda tem muito mais.

Apesar da evolução da infra, ainda falta algo que conecte as duas áreas, precisamos de um agente de mudanças principalmente no meio corporativo.

6. Cultura DevOps

Chegou a hora de entrar neste assunto, agora nós vamos aprofundar nossos estudos em relação a cultura DevOps.

6.1 Características da cultura DevOps

Para entender a cultura devops sem fazer um texto muito longo, vou pontuar as suas principais características - em minha opinião.

6.1.1 Em relação as características da cultura

Patrick Debois (foi quem cunhou o termo) diz que DevOPs essencialmente é uma cultura, e a descreve utilizando 4 eixos, são eles:

• Cultura
  • Colaboração
  • Fim das divisões
  • Relação saudável entre as áreas
  • Mudança de comportamento
• Automação
  • Deploy
  • Controle
  • Monitoração
  • Gerência de configuração
  • Orquestração
• Avaliação
  • Métricas
  • Medições
  • Performance
  • Logs e integração
• Compartilhamento
  • O feedback é tudo
  • Boa comunicação entre a equipe

Eu prentendo detalhar um pouco mais estes eixos, vamos lá.

6.1.2 Em relação as características técnicas

Um ambiente DevOps deve ter/possuir/oferecer/permitir:

• Infraestrutura como código
• Orquestração de servidores
• Gerência de configurações
• Provisionamento dinâmico de ambientes
• Controle de versões compartilhado entre infra e devel
• Ambiente de desenvolvimento, teste e produção (no mínimo)
• O ambiente de devel deve possibilitar TDD
• Infra deve participar dos projetos desde o início [1]
• Infra deve participar das reuniões de devel [2]
• Devel deve participar das reuniões de infra [3]
• Ambiente de entrega contínua [4]
• Os desenvolvedores devem conseguir fazer o deploy sem interferência da infra [5]
• Monitoramento eficaz com processamento adequado dos eventos e métricas
• Capacidade de resposta rápida a incidentes e problemas
• Backup e restore confiável

[1] O devel precisa envolver a infra nos projetos desde o início - isso significa participar das reuniões técnicas ou SCRUM, afinal sem a infra não há projeto, e além disto, quanto mais problemas foram resolvidos durante o projeto - com ajuda da infra, menos problemas serão expostos aos clientes.

[2] A infra também precisa observar quais são as metas da empresa a longo prazo, principalmente aquelas ligadas ao devel, pois enxergando onde o devel quer chegar, ela pode se programar melhor para ter certeza que a infraestrutura tecnológica estará preparada para atendê-los quando esse momento chegar.

[3] A infra precisa envolver o devel em suas reuniões técnicas para que o devel entenda e tenha ciência da realidade da infra, assim eles vão conseguir enxergar suas qualidades, atribuições, planos de melhorias, atualizações programadas, agendas de manutenção, eles vão conhecer os recursos disponíveis e também descobrir a limitações da equipe, sejam elas técnicas, sejam materiais. Além disto, o devel pode ser um grande aliado da infra na solução de problemas, afinal o conhecimento que o devel traz pode ajudá-los a melhorar a forma com que administram seu ambiente, tornando este processo mais eficiente.

[4] O devel precisa adotar alguma metodologia de entrega ou desenvolvimento contínuo e a infra precisa entender esse processo para que juntos criem os ambientes com as ferramentas certas.

[5] A infra precisa ceder um pouco e evoluir, precisa oferecer ao devel um ambiente adequado onde eles sejam o dono do produto, onde o devel consiga fazer todo o ciclo de desenvolvimento de forma direta, o devel precisa conseguir gerar e controlar o código, precisa fazer o commit com segurança, precisa fazer o build, testar o build, validar a aplicação e entregar a nova versão de forma transparente sem que para isso precise passar por um burocrático e engessado processo de mudança.

6.1.3 Em relação aos valores humanos

Para a adoção da cultura funcionar, a equipe precisa observar e exercitar os seguintes valores:

• Confiança no trabalho de sua equipe
• Respeito pessoal e profissional por todos da equipe
• Sinceridade sobre eventos e incidentes ocorridos
• Honestidade sobre as causas dos incidentes (não esconda nada da sua equipe)
• Entendimento de que o problema é responsabilidade de todos
• Entendimento de a solução é responsabilidade de todos
• Entendimento de que os resultados são o reflexo do trabalho de toda a equipe
• Comunicação efetiva e dinâmica
• Postura construtiva sempre
• Espírito de colaboração

6.1.4 Em relação a forma de trabalho

É recomendavél que a equipe:

• Internalize e adapte métodos ágeis como KABAN e SCRUM para seu dia-a-dia
• Aprofunde estudos em entrega contínua
• Aprofunde estudos em gerência de configurações e orquestração

Acho que é isso, características técnicas, valores humanos e forma de trabalhar, espero que tenha ficado claro para você.

6.2 Aplicando a cultura

Após observar as principais características deste movimento, normalmente pensamos em como aplicar isto em nosso meio. Para ajudar na reflexão vamos avaliar o meio startup e o meio corporativo.

6.2.1 A realidade no ambiente startup

A cultura DevOPs combina muito com startups, nestes locais normalmente já se trabalha desenvolvimento utilizando metologias ágeis, foi inclusive neste nicho em que começaram a discutir infraestrutura ágil - a precursora do movimento devops, portanto, as pessoas deste meio conseguem absorver os conceitos e a cultura DevOPs sem grandes dificuldades, eles conseguem compreender os preceitos de colaboração e feedback pois já fazem isto em seu dia-a-dia.

Quem está uma startup não tem as amarras e vícios da coporação, este é um grande facilitador e não é necessário nenhum tipo de intervenção para internalizar a cultura, a partir do estímulo de um líder as pessoas começarão a estudar e aplicar DevOPs naturalmente.

Na startup normalmente não existe divisões, departamentos, todos trabalham juntos e isso também é um facilitador, afinal não existem barreiras para se comunicar.

6.2.2 A realidade no ambiente corporativo

A corporação não funciona como a startup, lá existe burocracia e o uso vicioso de métodos ultrapassados, portanto não bastará o estímulo da alta hieraquia para que equipes de infra e devel comecem a vivenciar a cultura DevOPs, neste tipo de ambiente, em minha opinião pessoal e profissional, é necessário intervir cirurgicamente para conseguir internalizar a cultura DevOps.

Em resumo, você precisa trazer alguém - de fora - que conhece DevOP para que esta pessoa passe a contaminar os demais.

Esse processo é lento, mas se o especialista tiver os meios e o apoio do alto escalão, mudanças fantásticas poderão ocorrer.

6.3 O especialista DevOps no meio corporativo

Ele foi trazido para atuar como um agente de mudanças, ele precisa contaminar as áreas e mostrar que a cultura DevOps funciona.

6.3.1 Característica gerais de um especialista DevOps em 2013

• Está na casa dos 30 anos ou mais
• É um profissional sênior em infraestrutura
• Tem um bom background em desenvolvimento
• Tem um bom background em metodologias ágeis
• Tem sólidos conhecimentos em soluções opensource e similares
• Trabalha intensamente com automação e infraestrutura como código

6.3.2 Onde esse especialista atua?

Este especialista em DevOps terá um pé na infra e outro no devel, em alguns casos também terá o pé na área de garantia de qualidade (QA).

Ele é a cola que faltava para unir infra, devel e qualidade.

6.3.3 Como esse especialista atua?

Ele será a ponte entre as áreas de infra e devel, ele conhece a infra a fundo e entede de forma ampla processos de desenvolvimento ágil.

6.3.3.1 Pé no devel

Ele participa dos projetos de desenvolvimento desde o seu nascimento, seu foco é oferecer os recursos para os desenvolvedores trabalhem da forma mais eficiente, além disto, com sua ótica de infra ele toma todas as precauções para que os aspectos de segurança, monitoramento, eficiência e escalabilidade sejam observados desde o início do projeto.

O DevOps vai ainda estudar todo o processo de desenvolvimento e definir - em conjunto com o devel - as ferramentas que irão permitir um processo de desenvolvimento e entrega contínua. Após definir ele vai instalar e manter esse infra.

Alguns DevOps conseguem até avaliar o código do produto e enxergar problemas de performance, esse tipo de visão sistêmica e raciocínio rápido são diferencias importantes para uma entrega com mais qualidade.

6.3.3.1 Pé na infra

Na infra ele é o principal agente de mudanças, é ele que vai puxar a fila para iniciar a implantação de uma infraestrutura ágil, ele domina as ferramentas de orquestração, gerência de configuração e provisionamento e vai usar esse conhecimento para que a equipe passe a trabalhar a infraestrutura como código.

Este profissional também vai ajudá-los a mudar seu comportamento e cultura, ele vai orientá-los nos métodos ágeis de execução de atividades, aqueles inspirados no SCRUM e KANBAN.

6.4 Ele fica na infra ou no devel?

Para internalizar DevOPs, normalmente estas barreiras não existem, infra e devel devem habitar o mesmo espaço, sem paredes, sem divisórias, todos na mesma sala, isso é fundamental para extinguir os nichos e criar uma equipe mais unida e coesa.

Respondendo a pergunta, ele deve ficar junto com as duas equipes se for possível, esse é o melhor dos mundos.

Se não for possível ficarem todos juntos, o especialista deve se esforçar para interagir com as duas equipes diariamente.

Ele vai ser o agente de mudanças até que infra e devel comecem a entender e adotar a cultura de forma natural.

7. Quais os ganhos em adotar a cultura DevOPs?

Vamos avaliar dentro da ótica de cada área o que melhora com a adoção da cultura DevOPs.

7.1 Ganhos para a infra

• Infraestrutua como código (equipe para de administrar e passa a desenvolver a infra)
• Infra mais eficiente e rápida usando métodos ágeis
• Equipe de Infra mais organizada
• Equipe de Infra se comunicando melhor
• Infra fazendo mais em menos tempo com menos gente
• Ambientes de gerência de configuração, orquestração e provisionamento implantados
• Deploys de infra (novos ambientes) mais rápidos e seguros => entrega rápida
• Ambiente padronizado e sob-controle
• Feedback rápido em todas as atividades de infra

7.2 Ganhos para o devel

• Devel tem ambiente mais adequado para trabalhar (dev/teste/prod)
• Devel passa a contar com ambiente de desenvolvimento contínuo
• Devel passa a contar com testes automatizados
• Deploys de apps (novas versões) mais rápidos e seguros => entrega rápida
• Feedback rápido em todas as fases de desenvolvimento

7.3 Ganhos mútuos Infra/Devel

• Acaba a divisão Infra vs Devel (acaba a guerra)
• Infra participa dos projetos e acompanha de perto tudo o que acontece
• Infra participando resulta em melhor planejamento do ambiente de produção
• Infra participando resulta em monitoramento mais eficaz da aplicação
• Devel começa a compreender melhor a infra e isso resulta em um produto melhor
• Equipes trabalhando em conjunto para aumentar o valor do negócio

7.4 Ganhos para a empresa

• Melhor comunicação entre devel e infra (diminuição de conflitos)
• Soluções rodando com maior estabilidade e desempenho
• Entregas mais rápidas
• Menor tempo de paradas
• Diminuição de incidentes
• Diminuição de custos
• Diminuição de riscos
• Aumento do valor do negócio

8. Amarrando as pontas

Vamos partir para perguntas e respostas no melhor estilo FAQ.

8.1 Indo direto ao ponto (e respondendo as perguntas do início)

Respondendo sobre o termo DevOps:

1. DevOps está diretamente relacionado a um melhor feedback entre as áreas de TI.

2. DevOps é um movimento, é um conceito, é uma cultura e uma filosofia, e não existe uma explicação fácil.

3. DevOps possibilita diminuição dos riscos de mudanças através do uso de um ferramental adequado e adoção de uma cultura específica.

4. DevOps busca entregar sistemas melhores, com menor custo, fazendo isto de forma mais rápida e com menor risco.

5. DevOps envolve a área de Infra e Devel primáriamente.

6. DevOps é pura metodologia ágil tando na Infra quanto no Devel.

7. DevOps só funciona se as equipes de infra e devel estiverem dispostas a ceder, mudar sua cultura e método de trabalho.

8. DevOPs não é um cargo, tão pouco um setor ou departamento, é uma cultura.

9. DevOps não está restrito ao ambiente das startups, é possível utilizar essa cultura no meio corporativo.

10. DevOps não é algo novo, as boas práticas estão ai desde de sempre, logo esse ‘juntado’ de práticas não é novidade para muita gente, mas para alguns serve como uma boa referência para aplicar mudanças necessárias.

Respondendo sobre o especialista em DevOps:

1. O especialista em DevOps de hoje é normalmente alguém que conhece muito de infra e tem uma base sólida de devel.

2. O especialista em DevOps também pode ser alguém que veio do devel e que tem uma base sólida de infra (esse geralmente é mais completo).

8.2 Quero ser um DevOps e não sei por onde começar

Não há um tutorial para isto, minha recomendação é que você estude desenvolvimento ágil e procure entender o processo de desenvolvimento do local onde você trabalha, estude ferramentas para desenvolvimento contínuo, estude ferramentas de gerência de configuração, orquestração e provisionamento, fazendo isto você poderá dar os primeiros passos como entusiasta da cultura DevOps e estará apto a atuar em seu ambiente, você poderá agir como uma ponte entre as áreas de devel e infra, e principalmente, poderá modernizar os processos e o ambiente de infra.

8.3 Eu trabalho com infra ágil, sou um DevOps?

Não existe uma entidade certificadora, uma prova ou alguém que possa lhe conceder este título, não existe um manual de conduta para dizer se você é um DevOps ou não, mas em 2013 é bastante comum encontrar profissionais que estão estudando infraestruta ágil e se denominando DevOps.

Se você está buscando melhorar seu ambiente, entregar mais rápido, entregar algo com mais qualidade, algo que minimize custos, algo que diminua riscos, algo que envolva automatização pesada, se você trabalha infraestrutura como código, se você está atuando como um agente de mudanças em sua equipe, penso que DevOps é um termo adequado para descrever o seu trabalho, mesmo que não esteja diretamente envolvido com uma equipe de Devel.

8.4 Não existe receita mágica ou caminho rápido

Como eu já mencionei não existe uma metodologia clara, DevOps ainda é um movimento em constante construção e definição, eu citei uma série de melhorias que fazem parte da cultura DevOps, cabe a cada empresa ou a cada gestor estudar e descobrir a melhor forma de combinar essas pequenas receitas técnicas e aplicar em seu ambiente.

Espero que este artigo tenha te ajudado a entender melhor a cultura DevOPs.

9. Referências

Sites

• http://www.kartar.net/2010/02/what-devops-means-to-me/
• http://itrevolution.com/the-convergence-of-devops/
• http://devopsdays.org/events/
• http://devopsweekly.com

Slides

• http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
• http://www.slideshare.net/KrisBuytaert/devops-the-future-is-here-its-just-not-evenly-distributed-yet
• http://www.slideshare.net/jedi4ever/devops-is-a-verb-its-all-about-feedback-13174519
• http://www.slideshare.net/jedi4ever/devops-the-war-is-over-if-you-want-it
• http://www.slideshare.net/jedi4ever/devops-tools-fools-and-other-smart-things
• http://lanyrd.com/2012/berlindevops-july/swzgt/#link-kryx
• http://www.slideshare.net/wickett/the-devops-way-of-delivering-results-in-the-enterprise

Fonte das imagens

[1] Dev OPs: https://devcentral.f5.com/blogs/us/devops-is-not-all-about-automation
[3] Ops Burn: http://devops.com
[4] Combusível: www.huffingtonpost.com
[5] DevOps Diagram: http://www.skybotsoftware.com/skynews/2012/07/24/why-devops-more-trend

Há alguns meses um leitor me pediu ajuda com o HAPROXY, ele disse que havia visto em minha wiki alguns exemplos de uso, mas queria algo mais focado no JBOSS, este leitor tinha uma necessidade específica e resolvi ajudá-lo, mesmo não sendo especialista e não conhecendo a fundo a ferramenta.

Abaixo segue o roteiro completo de nossos estudos e descobertas.

1. Sobre o HAPROXY

O HAProxy é uma solução - opensource - que oferece recursos de High Availbility, Load Balance e PROXY para aplicações baseadas em TCP e HTTP. Ele foi particularmente desenhado e pensado para web sites com grande carga que necessitam de persistência ou processamentos específicos na camada de aplicação (layer7). Ele suporta milhares de conexões em hardwares muito modestos. É uma ferramenta fácil de instalar, configurar, operar e principalmente fácil de integrar aos ambientes e arquiteturas existentes.

Existem casos documentados de ambientes HAPROXY atendendo demandas que geravam de 3 a 6 Gibabits de tráfego - por segundo. Existem testes de laboratório feitos pelo criador da ferramenta demonstram que ele chegou a atender cerca de 106 mil requisições HTTP por segundo, e encaminhar (HTTP FORWARD) cerca de 40 mil requisições por segundo para backends internos.

Mas quem usa o HAPROXY?

AMAZON, TWITTER, REDDIT, FARMVILLE, GITHUB, TUMBLR, DISQUS, FEDORA, REDHAT CLOUD, STACKOVERFLOW.

* Dados retirados de http://haproxy.1wt.eu/they-use-it.html

2. HAPROXY

2.1 Instalando

A instalação é bastante simples, vou mostrar como instalar no Debian e CentOS.

No Debian

aptitude install haproxy

No CentOS

yum install haproxy

Se preferir compile - recomendado - a última versão disponível, basta fazer o download dos sources no site do haproxy.

2.2 Cenário

O leitor queria balancear uma aplicação de ensino a distância, tipo moodle, porém a ferramenta foi escrita em Java. Em seu ambiente ele tinha dois servidores bem robustos rodando JBOSS, e um servidor mais modesto em standby, estes por sua vez, sustentavam a aplicação de EAD.

2.3 Configuração

O arquivo de configuração tem o nome de haproxy.cfg, ele normalmente está no diretório /etc/haproxy.

A configuração proposta foi a seguinte:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

global
  log 127.0.0.1   local0
  log 127.0.0.1   local1 notice info
  maxconn 25000   # numero maximo de conexoes que ele vai atender
  user haproxy
  group haproxy
  daemon
  nbproc  2 # numero de processadores

defaults
     contimeout      5000
     clitimeout      50000
     srvtimeout      50000
     retries  3

listen  sistema    0.0.0.0:80
 
     log     global
     mode    http
     option httplog
     option dontlognull
     option redispatch
     option forwardfor
     option httpclose
     option forceclose
     option persist
     stats enable
     stats auth admin:proinfo
     stats uri /haproxy_stats
     stats realm HAProxy\ Statistics
     cookie  SERVERID insert indirect nocache
     balance roundrobin
     server  app01 10.1.1.1:8080 cookie A weight 1 maxconn 5000 inter 2s rise 2 fall 3 check
     server  app02 10.1.1.2:8080 cookie B weight 1 maxconn 5000 inter 2s rise 2 fall 3 check
     server  app03 10.1.1.3:8080 cookie B weight 1 maxconn 5000 inter 2s rise 2 fall 3 check backup

2.3.1 section global

A seção global do arquivo de configurações define algumas configurações globais, são elas:

1
2
3
4
5
6

log              => configurações de log
maxconn          => número máximo global de conexões que ele vai atender
user             => usuário que vai rodar o serviço
group            => grupo
daemon           => forma de funcionamento, no caso standalone
nbproc           => número de processadores

2.3.2 section defaults

A seção defaults define algumas configurações padrão para os listeners e backends.

1
2
3
4

contimeout       => tempo máximo que o servidor aguarda para um conexão ser estabelecida
clitimeout       => tempo máximo de inatividade no lado do cliente
srvtimeout       => tempo máximo de inatividade no lado do servidor
retries          => qts vezes o clt ainda deve tentar se conectar após uma falha

2.3.3 section listen

Está seção define as portas que o HAPROXY vai abrir e escutar, além disto é aqui que fazemos todas as configurações de balanceamento. Abaixo a explicação de cada parâmetro:

 log                                      => confs de log, no caso confs do global

 mode    http                             => modo de funcionamento (http ou tcp )

 option httplog                           => habilita log http
 option dontlognull                       => não loga conexões de checagem, ajuda a evitar log poluído
 option redispatch                        => limpar o cookie caso o backend caia
 option forwardfor                        => para empurrar o ip do cliente para o backend
 option httpclose                         => ajuda a fechar conexões que já deveriam ter sido encerradas
 option forceclose                        => ajuda a fechar conexões que já deveriam ter sido encerradas
 option persist                           => habilitando persistentica

 stats enable                             => habilita estatísticas
 stats auth admin:password                => usuário/senha para acessar stats
 stats uri /haproxy_stats                 => url das estatísticas
 stats realm HAProxy\ Statistics          => realm de autenticação

 cookie  SERVERID insert indirect nocache => injeta cookie na conexao

 balance roundrobin                       => tipo de balanceamento

2.3.3.1 parâmetro cookie

SERVERID   => nome do cookie que será inserido, caso necessário
indirect   => não insere cookie se o cliente já tiver um cookie válido
insert     => insere um cookie para controle de persistência de sessão caso seja necessário
nocache    => se cookie for inserido (insert) orienta a não fazer cache

2.3.3.2 parâmetro balancer e server

Veja abaixo que a configuração de balanceamento possui três backends com diversos parâmetros definidos para eles.

 server  sistema_01 10.1.1.1:8080 cookie A weight 1 maxconn 5000 inter 2s rise 2 fall 3 check
 server  sistema_02 10.1.1.2:8080 cookie B weight 1 maxconn 5000 inter 2s rise 2 fall 3 check
 server  sistema_03 10.1.1.3:8080 cookie C weight 1 maxconn 5000 inter 2s rise 2 fall 3 check backup

Vamos entender agora para que serve cada parâmetro:

check     => verifica se a porta está aberta no servidor do pool
cookie    => nome do cookie que será injetado no lado do cliente
backup    => essa maquina só vai entrar se uma instância do pool estiver fora
inter     => significa que ele fará checagens no backend a cada 2 segundos
rise      => significa que a maquina só volta para o pool se tiver 2 checagens positivas
fall      => significa que a maquina só sairá do pool se tiver pelo menos 3 checagens negativas
maxconn   => número máximo de conexões que a instância deve receber
weight    => peso que a instância terá no pool, quando maior mais conexões vão para ele

2.4 Estatísticas

Para acessar as estatísticas habilitadas na configuração proposta, basta apontar seu navegador para o endereço abaixo:

http://ip-do-servidor-haproxy/haproxy_stats

Através desta ferramenta de estatística, você terá dados completos sobre o balanceamento.

* Vai pedir o usuário e senha definidos na configuração.

2.5 Entendendo a configuração

Abaixo explico em 6 passos rápidos a configuração criada.

1. A configuração option persist força o acesso a um servidor do balanceamento que esteja demorando a responder, em caso de servidores que atendem muitas requisições isso é importante, as vezes ele não está fora só está lento.
2. Estamos injetando um cookie (cookie SERVERID insert indirect nocache) com nome SERVERID para organizar o balanceamento e manter a persistência de sessão. Quando um cliente chega, o haproxy injeta um cookie SERVERID=A/B/C para ele, assim quando ele voltar a conectar, vai trazer a informação do cookie (SERVERID=A) e a partir disto cair no mesmo servidor que ele iniciou a conexão, assim ele mantém a persistência na sessão.
3. É muito bom ter a persistência configurada, porém se uma máquina do balanceamento sair do ar, alguns clientes não irão conseguir fazer flush no cookie, com isso eles ficarão perdidos, com o option REDISPATCH isso é resolvido, o cookie é resetado caso o backend tenha sido removido do balanceamento e a partir daí a requisição vai para o próximo servidor disponível.
4. O option forwardfor é utilizado para empurrar o IP do cliente para o backend ao invés de empurrar o IP do HAPROXY, isso é bom quando queremos gerar estatísticas usando ferramentas como AWSTATS, estas ferramentas normalmente fazem leitura dos logs dos backends.
5. O option httpclose e option forceclose são utilizados para fechar conexões. Algumas vezes alguns servidores ao receberem o httpclose, mesmo assim ainda mantém a conexão aberta com o cliente, deixando ela cair por timeout, isso pode ocasionar centenas e as vezes milhares de conexões desnecessárias esperando timeout, esses dois parâmetros resolvem isto, fechando a conexão assim que o servidor terminar de responder.
6. Configuramos 3 backends, 2 ativos e um em standby (backup), esse último só entrará no balanceamento caso um dos backends principais seja removido por alguma razão, essa máquina é mais modesta, por isto está em modo backup.

3. Amarrando as pontas

Segundo o leitor, até hoje o balanceamento está funcionando redondinho, e ele por sinal está bastante feliz.

Tive que ler bastante para ajudá-lo na configuração, isso me ajudou a desenferrujar no HAPROXY, e olha que havia um bom tempo em que eu não usava ele para algo, finalmente surgiu uma boa oportunidade.

O HAPROXY ainda tem centenas de recursos para conhecer, alguns muito interessantes para PROXY e LOAD BALANCER, ele tem suporte a ACLs para redirecionamentos especiais, podemos construir regras fantásticas usando ACLs.

Outra questão sensacional é o balanceamento TCP, posso virtualmente criar um balanceamento na camada 4 utilizando apenas esta ferramenta, com isso posso balancear IMAP, POP, SMTP e qualquer outra aplicação que atenda clientes utilizando uma porta TCP.

Logo podemos dizer que com o HAPROXY você pode construir seu próprio SWITCH de conteúdo.

Se quiser criar um ambiente com HA para seu HAPROXY recomendo o uso do KEEPALIVED. Acesse o site do Andy Leonard para ler um bom tutorial sobre esse assunto.

Eu já vi casos de uso do NGINX para fazer proxy reverso e o HAPROXY para balanceamento, afinal ele é especializado nisto.

Já vi cenários com NGINX + HAPROXY + VARNISH (PROXY => BALANCEAMENTO => CACHE).

A grande vantagem do HAPROXY na minha opinião é que ele é uma ferramenta especializada em balanceamento, diferente de outras ferramentas que também fazem balanceamento, mas não são especializadas nisto. O HAPROXY é incrivelmente performatico e usa poucos recursos do servidor (MEM/PROC) para fazer seu trabalho.

Eu particularmente gosto muito desta ferramenta e das possibilidades que ela me oferece, recomendo de olhos fechados.

* Caso alguém que conheça melhor a ferramenta tenha visto algo errado, por favor nos avise e ajude melhorar este estudo, como eu já disse, sou um admirador da ferramenta mas não um grande conhecedor :)

4. Referências

• http://haproxy.1wt.eu/
• https://code.google.com/p/haproxy-docs
• http://gutocarvalho.net/dokuwiki/doku.php/haproxy_exemplos

O Mcollective é um framework que te permite trabalhar com orquestração de servidores ou execução paralela de tarefas em seus nodes.

Em essência, orquestração significa invocar ações em paralelo em todo o seu parque de servidores de uma forma direta, eficiente e além disto em tempo real.

2. Agente Shell

No post anterior, apresentei alguns agentes do Mcollective que executam ações pontuais, no entanto, não é possível através destes agentes rodar comandos arbitários em nossos nodes.

O próprio criador do Mcollective (R.I.Pienaar) não recomenda que sejam escritos plugins para execução de comandos arbitrários, e ele tem razão, é perigoso e você não conseguirá prever a saída do comando no outro lado.

Porém, eventualmente precisamos fazer isto, e neste caso existem alguns plugins disponíveis no GITHUB, aqui neste post vou mostrar como instalar um plugin que contém um agente para execução de comandos em ambiente shell.

2.1 Instalando o agente

Partindo do pressuposto de que você já tem o Mcollective rodando, vamos apenas instalar o agente shell e ver como ele funciona. Aqui neste post vou usar o agente escrito por Jeremy Caroll.

Faça download do arquivo shell.rb

wget https://raw.github.com/phobos182/mcollective-plugins/master/agent/shell/shell.rb

Faça download do arquivo shell.ddl

wget https://raw.github.com/phobos182/mcollective-plugins/master/agent/shell/shell.ddl

Mova os arquivos para o diretório agent do mcollective

mv shell.rb shell.ddl /usr/share/mcollective/plugins/mcollective/agent

Agora faça download do arquivo de aplicação shell.rb (é outro arquivo)

wget https://raw.github.com/phobos182/mcollective-plugins/master/agent/shell/application/shell.rb

Mova o arquivo para o diretório application do mcollective

mv shell.rb /usr/share/mcollective/plugins/mcollective/application

Agora reinicie o agente.

/etc/init.d/mcollective restart

Instale os arquivos em todos os nodes que deseja utilizar o agente shell.

2.2 Utilizando o agente

A utilização é bastante simples, observe a sintaxe:

mco shell <comando>

Vamos a um exemplo

mco shell uptime

Acompanhe a saída

1
2
3
4
5
6
7

Do you really want to send this command unfiltered? (y/n): y
Discovering hosts using the mc method for 2 second(s) .... 2

 * [ ============================================================> ] 2 / 2

[puppet.hacklab] exit=0:
[debian.hacklab] exit=0:

Veja que o comando foi executado em dois nodes, mas repare que apenas fomos informados disto, caso deseje ver a saída, será necessário adicionar um parâmetro.

mco shell uptime --verbose

Acompanhe a saída

1
2
3
4
5
6
7

Do you really want to send this command unfiltered? (y/n): y
Discovering hosts using the mc method for 2 second(s) .... 2

 * [ ============================================================> ] 2 / 2

[puppet.hacklab] exit=0:  13:56:48 up 28 min,  2 users,  load average: 0.00, 0.00, 0.00
[debian.hacklab] exit=0:  13:56:44 up 28 min,  2 users,  load average: 0.00, 0.00, 0.00

2.3 Exemplos de uso do agente

2.3.1 Lendo arquivo /etc/issue

Vamos usar o cat para ler o conteúdo do arquivo issue

mco shell "cat /etc/issue" --verbose

Acompanhe a saída

1
2
3
4
5
6
7
8

Do you really want to send this command unfiltered? (y/n): y
Discovering hosts using the mc method for 2 second(s) .... 2

 * [ ============================================================> ] 2 / 2

[debian.hacklab] exit=0: Debian GNU/Linux 6.0 \n \l

[puppet.hacklab] exit=0: Debian GNU/Linux 6.0 \n \l

2.3.2 Rodando comando df

Vamos rodar o comando df -h para ver dados de uso das partições e disco.

mco shell "df -h" --verbose

Acompanhe a saída

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Do you really want to send this command unfiltered? (y/n): y
Discovering hosts using the mc method for 2 second(s) .... 2

 * [ ============================================================> ] 2 / 2

[puppet.hacklab] exit=0: Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             3.8G  2.1G  1.6G  57% /
tmpfs                 188M     0  188M   0% /lib/init/rw
udev                  184M  124K  184M   1% /dev
tmpfs                 188M     0  188M   0% /dev/shm

[debian.hacklab] exit=0: Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             3.8G 1002M  2.6G  28% /
tmpfs                 125M     0  125M   0% /lib/init/rw
udev                  121M  124K  120M   1% /dev
tmpfs                 125M     0  125M   0% /dev/shm

3. Amarrando as pontas

O criador do Mcollective (R.I.Pienaar) recomenda que você escreva seus agentes usando simpleRPC, agentes que executem tarefas pontais, agentes no quais você tem controle, agentes nos quais você pode confiar, agentes nos quais você conhece o risco de utilizar em sua infra, e tenho que dizer que eu concordo com isto, portanto, use esse agente ssh por sua conta e risco ;)

Eu assumo o risco pois o que preciso fazer com ele é bem simples, mas cada caso é um caso.

3.1 Exemplificando os riscos

Só para você ter uma ideia de tragédias possíveis, imagine o risco potencial de alguém rodar - sem querer - algo como abaixo:

mco shell "rm -rf /"

Isto simplesmente apagaria todo o seu parque, é muito poder para pouca segurança. Espero que este exemplo tenha sido suficientemente claro :)

3.1 Facilitando a instalação

Eu escrevi dois módulos para Puppet que facilitam a instalação do Mcollective e dos agentes, segue abaixo os links.

https://github.com/gutocarvalho/puppet-mcollective-debian

https://github.com/gutocarvalho/puppet-rabbitmq-debian

O agente SSH já está incluso no módulo.

4. Referências

• http://www.devco.net
• https://github.com/phobos182/mcollective-plugins
• https://github.com/puppetlabs/mcollective-plugins
• https://puppetlabs.com/mcollective/introduction

[s]
Guto

O Mcollective é um framework que te permite trabalhar com orquestração de servidores ou execução paralela de tarefas em seus nodes.

Em essência, orquestração significa invocar ações em paralelo em todo o seu parque de servidores de uma forma direta, eficiente e além disto em tempo real.

2. Entendendo a necessidade

Vamos supor que por alguma razão você precise rodar algum comando em todos os seus servidores, seja para atualizar um pacote, seja para desligar um serviço, seja para remover um usuário ou aplicar uma regra e firewall, enfim, por qualquer que seja a razão.

Sabemos que o puppet permite esse tipo de abordagem, porém não te permite fazer isto em tempo real, com o puppet você precisar criar um manifest, declarar a classe de seu manifest para seus nodes e esperar que os agentes consultem o servidor, recebam o catálogo e iniciem a aplicação das mudanças declaradas no manifest. Isto pode levar minutos ou horas dependendo do tamanho do seu parque e de como os agentes estão configurados.

Se sua necessidade é executar algo em tempo real, de forma paralela, o mcollective é a ferramenta certa para fazer isto em seu parque de servidores.

3. Objetivos deste artigo

Aqui pretendo abordar a instalação do Mcollective em ambiente Debian.

4. Ambiente

2 VMs’ Virtualbox - Debian Squeeze - 64 Bits

vm1: 192.168.56.50 puppet.hacklab (puppet master)
vm2: 192.168.56.51 debian.hacklab (puppet agent )

5 Pre-Reqs

5.1 Repositório debian

Nas duas VM’s adicione os repositórios abaixo ao seu sources.list

Edite o arquivo

vim /etc/apt/sources.list

Adicione as linhas ao final do arquivo

deb http://apt.puppetlabs.com squeeze main
deb http://www.rabbitmq.com/debian/ testing main

Salve as alterações

:wq

Atualize os índices

aptitude update

Pronto, agora você poderá instalar o mcollective usando o aptitude.

5.2 Ambiente Puppet

Nas duas VM’s é necessário que já exista um ambiente Puppet instalado e rodando em modo cliente/servidor, não vou entrar em detalhes pois já cobri esse processo de forma completa em minha wiki.

vm1: puppet.hacklab (puppet master)
vm2: debian.hacklab (puppet agent )

Ressalto que é importante ter o puppet funcionando nas VM’s para podermos utilizar o agente puppet, package e service do Mcollective.

6. Configurando VM1 (puppet master)

6.1 Instalando RabbitMQ

6.1.1 Sobre o RabbitMQ

O Mcollective (MCO) depende de algum sistema de mensageria, é possível utilizar tanto o ApacheMQ quanto o RabbitMQ, ambos tem suporte ao protocolo STOMP, necessário para o funcionamento do MCO.

Neste estudo vou utilizar o RabbitMQ, mas é possível - e até recomendado - utilizar o ActiveMQ.

6.1.2 Instalando o ActiveMQ

Instale o rabbitmq 3.0.2 (vigente neste momento)

aptitude install rabbitmq-server

Edite o arquivo /etc/rabbitmq/rabbitmq.config e coloque apenas o conteúdo abaixo, limpe o resto

1
2
3
4

[
  {rabbitmq_stomp, [{tcp_listeners, [{"0.0.0.0", 6163},
                                     {"::1",       6163}]}]}
].

Edite o arquivo /etc/default/rabbitmq-server e descomente a linha abaixo

ulimit -n 1024

reinicie o serviço

/etc/init.d/rabbitmq-server restart

Verfique o status do serviço

/etc/init.d/rabbitmq-server status

Acompanhe a saída

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

Status of node rabbit@puppet ...
[{pid,7390},
 {running_applications,[{rabbit,"RabbitMQ","3.0.2"},
                        {mnesia,"MNESIA  CXC 138 12","4.4.14"},
                        {os_mon,"CPO  CXC 138 46","2.2.5"},
                        {sasl,"SASL  CXC 138 11","2.1.9.2"},
                        {stdlib,"ERTS  CXC 138 10","1.17"},
                        {kernel,"ERTS  CXC 138 10","2.14"}]},
 {os,{unix,linux}},
 {erlang_version,"Erlang R14A (erts-5.8) [source] [rq:1] [async-threads:30] [kernel-poll:true]\n"},
 {memory,[{total,12888616},
          {connection_procs,1344},
          {queue_procs,2688},
          {plugins,0},
          {other_proc,4592340},
          {mnesia,28704},
          {mgmt_db,0},
          {msg_index,7020},
          {other_ets,363324},
          {binary,3680},
          {code,6394787},
          {atom,796661},
          {other_system,698068}]},
 {vm_memory_high_watermark,0.4},
 {vm_memory_limit,157546905},
 {disk_free_limit,1000000000},
 {disk_free,2638680064},
 {file_descriptors,[{total_limit,924},
                    {total_used,3},
                    {sockets_limit,829},
                    {sockets_used,1}]},
 {processes,[{limit,1048576},{used,121}]},
 {run_queue,0},
 {uptime,5}]
...done.

Crie um usuário para o mcollective

rabbitmqctl add_user mcollective senhapuppet

Especifique as permissões para o usuário do mcollective

rabbitmqctl set_permissions -p / mcollective "^amq.gen-.*" ".*" ".*"

Remova o usuário guest

rabbitmqctl delete_user guest

Habilite os plugins stomp e amqp

rabbitmq-plugins enable rabbitmq_stomp
rabbitmq-plugins enable amqp_client

6.2 Instalando MCollective

Instale a biblioteca stomp para ruby

aptitude install libstomp-ruby

Instale os pacotes mcollective da puppetlabs

aptitude install mcollective mcollective-client

Configure o arquivo /etc/mcollective/server.cfg conforme abaixo

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

topicprefix = /topic/
main_collective = mcollective
collectives = mcollective
libdir = /usr/share/mcollective/plugins
logfile = /var/log/mcollective.log
loglevel = info
daemonize = 1

# Plugins
securityprovider = psk
plugin.psk = hacklab

connector = stomp
plugin.stomp.host = 192.168.56.50
plugin.stomp.port = 6163
plugin.stomp.user = mcollective
plugin.stomp.password = senhapuppet

# Facts
factsource = yaml
plugin.yaml = /etc/mcollective/facts.yaml

Configure o arquivo /etc/mcollective/client.cfg conforme abaixo

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

topicprefix = /topic/
main_collective = mcollective
collectives = mcollective
libdir = /usr/share/mcollective/plugins
logger_type = console
loglevel = warn

# Plugins
securityprovider = psk
plugin.psk = hacklab

connector = stomp
plugin.stomp.host = 192.168.56.50
plugin.stomp.port = 6163
plugin.stomp.user = mcollective
plugin.stomp.password = senhapuppet

# Facts
factsource = yaml
plugin.yaml = /etc/mcollective/facts.yaml

Reinicie o mcollective

/etc/init.d/mcollective restart

Faça o teste de ping em nodes ativos usando o mco

mco ping

Acompanhe a saída

puppet.hacklab                           time=89.34 ms
---- ping statistics ----
1 replies max: 89.34 min: 89.34 avg: 89.34

Faça o teste de find em nodes ativos usando o mco

mco find

Acompanhe a saída

puppet.hacklab

Podemos ver que o MCO está funcionando corretamente, por hora detectando apenas um node.

7. Configurando VM2 (puppet agent)

Para instalar o Mcollective na VM2, siga as referências da seção 1.2 e tenha os repositórios devidamente configurados.

Após a instalação e a configuração do mcollective, faça o teste de ping em nodes ativos com mco

mco ping

Acompanhe a saída

1
2
3
4

debian.hacklab                           time=188.49 ms
puppet.hacklab                           time=191.91 ms
---- ping statistics ----
2 replies max: 191.91 min: 188.49 avg: 190.20 

Faça uma busca por nodes ativos com o mco

mco find

Acompanhe a saída

1
2

puppet.hacklab
debian.hacklab

Solicite o inventário de uma máquina

mco inventory debian.hacklab

Acompanhe a saída

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

Inventory for debian.hacklab:

   Server Statistics:
                      Version: 2.2.2
                   Start Time: Wed Feb 06 14:39:55 -0200 2013
                  Config File: /etc/mcollective/server.cfg
                  Collectives: mcollective
              Main Collective: mcollective
                   Process ID: 1744
               Total Messages: 19
      Messages Passed Filters: 18
            Messages Filtered: 1
             Expired Messages: 0
                 Replies Sent: 17
         Total Processor Time: 0.52 seconds
                  System Time: 0.27 seconds

   Agents:
      discovery       puppet          rpcutil        

   Data Plugins:
      agent           fstat           puppet         
      resource                                       

   Configuration Management Classes:
      apt                            apt::params                   
      debian.hacklab                 hostname                      
      hosts                          linux-server                  
      openssh-server                 puppet-agent                  
      repos                          resolv                        
      salt-minion                    settings                      
      usuarios                       utils                         

   Facts:
      mcollective => 1

Podemos ver que o MCO está funcionando corretamente e detectando os dois nodes.

8. Agentes para Mcollective

O Mcollective possui vários agentes que nos ajudam a manipular os nodes de nosso parque de forma direta, aqui vou abordar a instalação e utilização de alguns destes agentes.

Instale os pacotes em ambos os nodes

aptitude install mcollective-puppet-agent mcollective-puppet-client mcollective-package-agent mcollective-package-client mcollective-service-agent mcollective-service-client

Reinicie o mcollective em ambos os nodes

/etc/init.d/mcollective restart

8.1 Agente puppet

8.1.1 runonce/runall

Após instalar, podemos mandar executar o puppet em um node

mco puppet runonce -I debian.hacklab

Acompanhe a saída

1
2
3

* [ ============================================================> ] 1 / 1

Finished processing 1 / 1 hosts in 112.56 ms

Podemos mandar executar o agente em todos os nodes

mco puppet runonce -v

Acompanhe a saída

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Discovering hosts using the mc method for 2 second(s) .... 2

 * [ ============================================================> ] 2 / 2

puppet.hacklab                          : Puppet is currently applying a catalog, cannot run now
    {:summary=>"Puppet is currently applying a catalog, cannot run now"}

debian.hacklab                          : OK
    {:summary=>"Signalled the running Puppet Daemon"}

---- rpc stats ----
           Nodes: 2 / 2
     Pass / Fail: 1 / 1
      Start Time: Wed Feb 06 18:08:20 -0200 2013
  Discovery Time: 2013.47ms
      Agent Time: 43.72ms
      Total Time: 2057.18ms

Existe ainda o parâmetro runall onde você pode especificar a quantidade de ações simultâneas que serão executadas, ou seja, quantidade de agentes que serão executados de forma paralela.

mco puppet runall 10

Neste caso ele vai executar o agente em todos os nodes, rodando de 10 em 10, essa pode ser um estratégia para evitar esgotamento dos recursos do servidor em parques muito grandes, desta forma, ao invés de deixar o agente ligado e consultando o servidor a cada N minutos, você pode usar o MCO para rodar o agente de forma controlada em todos os seus nodes.

8.1.2 enable/disable

Desabilitando puppet em um node

mco puppet disable -I debian.hacklab

Acompanhe a saída

1
2
3
4
5
6
7

 * [ ============================================================> ] 1 / 1

Summary of Enabled:

   disabled = 1

Finished processing 1 / 1 hosts in 126.27 ms

Habilitando puppet em um node

mco puppet enable -I debian.hacklab

Acompanhe a saída

1
2
3
4
5
6
7

 * [ ============================================================> ] 1 / 1

Summary of Enabled:

   enabled = 1

Finished processing 1 / 1 hosts in 91.71 ms    

Desabilitando puppet em todos os nodes

mco rpc puppet disable message="doing some hand hacking"

Acompanhe a saída

1
2
3
4
5
6
7
8
9

Discovering hosts using the mc method for 2 second(s) .... 2

 * [ ============================================================> ] 2 / 2

Summary of Enabled:

   disabled = 2

Finished processing 2 / 2 hosts in 201.09 ms

Habilitando puppet em todos os nos nodes

mco rpc puppet enable

Acompanhe a saída

1
2
3
4
5
6
7
8
9

Discovering hosts using the mc method for 2 second(s) .... 2

 * [ ============================================================> ] 2 / 2

Summary of Enabled:

   enabled = 2

Finished processing 2 / 2 hosts in 45.02 ms

8.1.3 summary

Solicitando o relatório last run

mco puppet summary

Acompanhe a saída

1
2
3
4
5
6
7
8
9

Summary statistics for 2 nodes:

                  Total resources: ▇▁▁▇▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁  min: 62.0   max: 66.0  
            Out Of Sync resources: ▇▇▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁  min: 0.0    max: 2.0   
                 Failed resources: ▇▇▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁  min: 0.0    max: 2.0   
                Changed resources: ▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁  min: 0.0    max: 0.0   
  Config Retrieval time (seconds): ▇▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁  min: 0.7    max: 1.5   
         Total run-time (seconds): ▇▁▁▁▁▇▁▁▁▁▁▁▁▁▁▁▁▁▁▁  min: 4.4    max: 12.5  
    Time since last run (seconds): ▇▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▇  min: 791.0  max: 1.5k  

8.1.4 count

Solicitando contagem dos nodes habilitados, desabiliados e em execução

mco puppet count

Acompanhe a saída

1
2
3
4
5
6
7
8
9
10
11

Total Puppet nodes: 2

          Nodes currently enabled: 2
         Nodes currently disabled: 0

Nodes currently doing puppet runs: 0
          Nodes currently stopped: 2

       Nodes with daemons started: 2
    Nodes without daemons started: 0
       Daemons started but idling: 2

8.1.5 stats

Solicitando status dos agentes

mco puppet status

Acompanhe a saída

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

 * [ ============================================================> ] 2 / 2

   debian.hacklab: Currently idling; last completed run 30 minutes 34 seconds ago
   puppet.hacklab: Currently applying a catalog; last completed run 6 hours 37 minutes 18 seconds ago

Summary of Applying:

    true = 1
   false = 1

Summary of Daemon Running:

   running = 2

Summary of Enabled:

   enabled = 2

Summary of Idling:

    true = 1
   false = 1

Summary of Status:

               idling = 1
   applying a catalog = 1


Finished processing 2 / 2 hosts in 67.61 ms

8.2 Agente service

8.2.1 agente service: stop

Parando um serviço em um node específico

mco rpc service stop service=ssh -I debian.hacklab

Acompanhe a saída

1
2
3
4
5
6
7

 * [ ============================================================> ] 1 / 1

Summary of Service Status:

   stopped = 1

Finished processing 1 / 1 hosts in 1166.06 ms

Parando um serviço em todos os nodes

puppet@root ~]# mco rpc service stop service=ssh

Acompanhe a saída

1
2
3
4
5
6
7
8
9

Discovering hosts using the mc method for 2 second(s) .... 2

 * [ ============================================================> ] 2 / 2

Summary of Service Status:

   stopped = 2

Finished processing 2 / 2 hosts in 2546.92 ms

8.2.2 plugin service: start

Iniciando o serviço em um node específico

mco rpc service start service=ssh -I debian.hacklab

Acompanhe a saída

1
2
3
4
5
6
7

 * [ ============================================================> ] 1 / 1

Summary of Service Status:

   running = 1

Finished processing 1 / 1 hosts in 1204.95 ms

Iniciando um serviço em todos os nodes

mco rpc service start service=ssh

Acompanhe a saída

1
2
3
4
5
6
7
8
9

Discovering hosts using the mc method for 2 second(s) .... 2

 * [ ============================================================> ] 2 / 2

Summary of Service Status:

   running = 2

Finished processing 2 / 2 hosts in 3271.52 ms

8.2.3 plugin service: restart

Reiniciando um serviço em um node específico

mco rpc service restart service=ssh -I debian.hacklab

Acompanhe a saída

1
2
3
4
5
6
7
8

 * [ ============================================================> ] 1 / 1


Summary of Service Status:

   running = 1

Finished processing 1 / 1 hosts in 1015.66 ms

Reiniciando um serviço em todos os nodes

mco rpc service restart service=ssh

Acompanhe a saída

1
2
3
4
5
6
7
8
9

Discovering hosts using the mc method for 2 second(s) .... 2

 * [ ============================================================> ] 2 / 2

Summary of Service Status:

   running = 2

Finished processing 2 / 2 hosts in 5466.57 ms

8.3 Agente package

8.3.1 agente package: install

Instalando o pacote em um node específico

mco rpc package install package=htop -I debian.hacklab

Acompanhe a saída

1
2
3
4
5
6
7
8
9
10

 * [ ============================================================> ] 1 / 1

debian.hacklab                           Unknown Request Status
   Package is already installed

Summary of Ensure:

   0.8.3-1 = 1

Finished processing 1 / 1 hosts in 856.85 ms

Instalando um pacote em todos os nodes

mco rpc package install package=htop

Acompanhe a saída

1
2
3
4
5
6
7
8
9

Discovering hosts using the mc method for 2 second(s) .... 2

 * [ ============================================================> ] 2 / 2

Summary of Ensure:

   0.8.3-1 = 2

Finished processing 2 / 2 hosts in 4972.04 ms

8.3.2 plugin package: uninstall

Removendo um pacote de um node específico

mco rpc package uninstall package=htop -I debian.hacklab

Acompanhe a saída

1
2
3
4
5
6
7

 * [ ============================================================> ] 1 / 1

Summary of Ensure:

   absent = 1

Finished processing 1 / 1 hosts in 7515.24 ms

Removendo um pacote em todos os nodes

mco rpc package uninstall package=htop

Acompanhe a saída

1
2
3
4
5
6
7
8
9

Discovering hosts using the mc method for 2 second(s) .... 2

 * [ ============================================================> ] 2 / 2

Summary of Ensure:

   absent = 2

Finished processing 2 / 2 hosts in 4230.82 ms

8.3.3 plugin package: status

Verificando o status de um pacote em um node específico

mco rpc package status package=htop -I debian.hacklab

Acompanhe a saída

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

 * [ ============================================================> ] 1 / 1

debian.hacklab                           
       Arch: nil
    desired: install
     Ensure: 0.8.3-1
      Epoch: nil
      error: ok
       Name: htop
     Output: nil
   Provider: :apt
    Release: nil
     status: installed
    Version: nil

Summary of Arch:

     No aggregate summary could be computed

Summary of Ensure:

   0.8.3-1 = 1

Finished processing 1 / 1 hosts in 391.55 ms

Verificando o status de um pacote em todos os nodes

mco rpc package status package=htop

Acompanhe a saída

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

Discovering hosts using the mc method for 2 second(s) .... 2

 * [ ============================================================> ] 2 / 2

debian.hacklab                           
       Arch: nil
    desired: install
     Ensure: 0.8.3-1
      Epoch: nil
      error: ok
       Name: htop
     Output: nil
   Provider: :apt
    Release: nil
     status: installed
    Version: nil

puppet.hacklab                           
       Arch: nil
    desired: install
     Ensure: 0.8.3-1
      Epoch: nil
      error: ok
       Name: htop
     Output: nil
   Provider: :apt
    Release: nil
     status: installed
    Version: nil

Summary of Arch:

     No aggregate summary could be computed

Summary of Ensure:

   0.8.3-1 = 2

Finished processing 2 / 2 hosts in 174.41 ms

8.3.4 plugin package: update

Atualizando um pacote em um node específico

mco rpc package update package=facter -I debian.hacklab

Acompanhe a saída

1
2
3
4
5
6
7
8
9

 * [ ============================================================> ] 1 / 1

Summary of Ensure:

   1.6.17-1puppetlabs1 = 1


Finished processing 1 / 1 hosts in 11307.56 ms

Atualizando um pacote em todos os nodes

mco rpc package update package=htop

Acompanhe a saída

1
2
3
4
5
6
7
8
9

Discovering hosts using the mc method for 2 second(s) .... 2

 * [ ============================================================> ] 2 / 2

Summary of Ensure:

   0.8.3-1 = 2

Finished processing 2 / 2 hosts in 2999.96 ms

8.4 Agente facter facts

O Mcollective possui suporte a mostrar certos fatos do sistema, mas se quisermos utilizar os fatos do facter, precisamos fazer alguns ajustes na configuração e adicionar um plugin manualmente, isto é necessário pois infelizmente o plugin facter facts não está empacotado para o debian.

Acesse do diretório tmp

cd /tmp

Faça o clone do repo mcollective-plugins

git clone https://github.com/puppetlabs/mcollective-plugins.git

Copie o plugin para o diretório do mcollective

cp mcollective-plugins/facts/facter/facter_facts.rb /usr/share/mcollective/plugins/mcollective/facts/

Ajuste o arquivo client.cfg e server.cfg do mcollective, remova ou comente o trecho abaixo

1
2
3

# Facts
factsource = yaml
plugin.yaml = /etc/mcollective/facts.yaml

E insira o seguinte no lugar

1
2

# Facts
factsource = facter

Após alterar, reinicie o mcollective

/etc/init.d/mcollective restart

Consulte o fato virtual em um node específico

mco facts virtual  -v -I debian.hacklab

Acompanhe a saída

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Report for fact: virtual

        virtualbox                              found 1 times

            debian.hacklab


---- rpc stats ----
           Nodes: 1 / 1
     Pass / Fail: 1 / 0
      Start Time: Wed Feb 06 20:57:39 -0200 2013
  Discovery Time: 0.00ms
      Agent Time: 136.37ms
      Total Time: 136.37ms    

Consulte o fato ipaddress do facter em todos os nodes

mco facts ipaddress -v

Acompanhe a saída

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Discovering hosts using the mc method for 2 second(s) .... 2
Report for fact: ipaddress

        192.168.56.50                           found 1 times

            puppet.hacklab

        192.168.56.51                           found 1 times

            debian.hacklab

---- rpc stats ----
           Nodes: 2 / 2
     Pass / Fail: 2 / 0
      Start Time: Wed Feb 06 20:52:29 -0200 2013
  Discovery Time: 2007.25ms
      Agent Time: 54.72ms
      Total Time: 2061.97ms

Consulte o fato kernelversion do facter em todos os nodes

mco facts kernelversion -v

Acompanhe a saída:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Discovering hosts using the mc method for 2 second(s) .... 2
Report for fact: kernelversion

        2.6.32                                  found 2 times

            debian.hacklab
            puppet.hacklab


---- rpc stats ----
           Nodes: 2 / 2
     Pass / Fail: 2 / 0
      Start Time: Wed Feb 06 20:52:47 -0200 2013
  Discovery Time: 2008.67ms
      Agent Time: 59.92ms
      Total Time: 2068.59ms

Podemos ver que o MCO está conseguindo trazer os fatos do facter corretamente.

9. Amarrando as pontas

Essa foi uma instalação básica do Mcollective em ambiente debian - usando RabbitMQ, além disto, apresentei alguns comandos iniciais usando o agente/client puppet criado pela Puppetlabs para o MCO.

Mas não pense que é só isto, ele é muito mais poderoso, existem diversos outros agentes para utilizar e você pode construir seus próprios agentes usando RPC se achar necessário, e ainda existem os plugins em ruby, ele é muito extensível.

Vale comentar que apesar de ter utilizado o RabbitMQ, o criador do MCO recomenda o uso do ActiveMQ a partir da versão 2.x.x, aparentemente alguns dos recursos desta versão só irão funcionar com o ActiveMQ. Em breve espero tratar o uso do ActiveMQ também.

Preciso explicar que esse post apenas agrupa o que eu estudei até o momento, a partir daqui é hora de aprofundar ainda mais.

10. Referências

Plugins Github

• https://github.com/puppetlabs/mcollective-plugins
• https://github.com/puppetlabs/mcollective-puppet-agent#readme

Introdução ao MCO

• https://puppetlabs.com/mcollective/introduction/
• http://docs.puppetlabs.com/mcollective/reference/basic/gettingstarted_debian.html
• http://docs.puppetlabs.com/mcollective/reference/basic/gettingstarted.html
• http://docs.puppetlabs.com/mcollective/reference/basic/configuration.html

Construindo Agentes e Clientes com SimpleRPC

• http://docs.puppetlabs.com/mcollective/simplerpc/

Slides MCO

• http://www.slideshare.net/PuppetLabs/presentation-16281121

RabbitMQ

• http://www.rabbitmq.com/stomp.html

O livro Pro Puppet da Puppetlabs também foi uma ótima referência de estudo.

[s]
Guto