Deixando de ser artesão – Repensando a gerência de servidores

O que seria da área de tecnologia da informação sem suas mudanças? Estamos o tempo todo nos reinventando. Repensando nossos métodos e viabilizando novas formas de melhorar nossa atuação, nossos produtos, entregando valores cada vez mais rápido.
Nesse artigo falarei um pouco de como mudamos completamente a nossa forma de lidar com gerência de servidores.

“Antigo” administrador de servidores, que aqui chamarei de artesão.

Em um determinado momento no “passado”, os técnicos de infraestrutura de TI atuavam de forma bem manual, eles desempenham suas tarefas de forma similar a como faziam os artesãos antes do processo de industrialização. Para levantar um novo serviço, esse profissional era responsável por realizar quase todas partes do processo.

O técnico de TI fazia cabo de rede, preparava instalação elétrica, fazia cotação e comprava o servidor, recebia o pedido, tirava ele da caixa e colocava no rack. Em seguida ele instalava seu sistema básico e então configurava os serviços a serem entregues ao usuário. Com o advento da virtualização, esse trabalho ficou menos oneroso, mas ainda assim o técnico ainda era responsável por manualmente criar as máquinas virtuais, instalar o sistema operacional e os serviços. Mesmo utilizando templates, ainda havia algum trabalho manual e repetitivo a fazer.

As melhores práticas hoje indicam o uso de ferramentas que viabilizam a automatização de quase todo processo de entrega de um novo serviço, ou seja, hoje é possível criar o servidor, instalar os pacotes, configurar os serviços, requisitar e configurar um nome para o serviço de DNS, colocar no backup, adicionar no monitoramento, configurar a VLAN correta, solicitar as regras específicas de firewall , se registrar no balanceamento de carga e até mesmo enviar e-mail para o responsável técnico avisando quando todo esse processo automático finalizar. Todo processo iniciado com o pressionar de um botão.

Robôs virtuais, fazendo o trabalho manual e repetitivo.

Assim como o artesão viu seu trabalho manual ser substituído por máquinas, os técnicos de TI estão vendo seu trabalho braçal ser realizado por ferramentas de automatização. A cultura DevOps viabilizou um terreno fértil no campo das ideias e processos para que essa mudança fosse possível, pois não é somente de ferramentas que consiste uma mudança de paradigma, certo?

Mudanças de paradigmas normalmente são traumáticas e demoraram algum tempo para se popularizar, e mesmo para área de Tecnologia da Informação, que é conhecida por sua propensão a inovação, isso não é diferente.

A cultura DevOps tem como mote principal a entrega de valor, que as equipes de desenvolvimento e infraestrutura trabalhem juntas para entregar o produto. Perceba que para trabalhar junto não necessariamente indica que os desenvolvedores devem fazer o trabalho que antes era de infraestrutura e vice-versa. Estamos falando aqui de colaboração, onde ambas subáreas entendem o processo de entrega de serviço como um todo, mas tem seus papéis bem definidos.

Com a derrubada do muro imaginário que existia entre desenvolvedores e infraestrutura, ambos puderam usufruir do melhor que cada área tinham a acrescentar para a outra. Os desenvolvedores puderam ter acesso a provisionar infraestruturas de forma rápida, estável e segura. Os operadores de infraestrutura puderam ter acesso as melhores práticas de desenvolvimento para que ferramentas de provisionamento, gerência de configuração e afins pudessem ser ofertadas como solução para seus trabalhos repetitivos, ou seja, para aqueles trabalhos que fazer de forma artesanal não traziam nenhuma melhora no valor, apenas impactavam negativamente no seu tempo de entrega.

Os trabalhos manuais ainda serão necessários, porém bem menos frequentes.

Os trabalhos artesanais dependem da atenção, disposição, tempo, humor e habilidade dos artesãos de TI, hoje podem ser feitos de forma automática, altamente parametrizada e até mesmo específica, caso necessário, por softwares de gerenciamento de configuração, provisionamento e afins.

Esses trabalhos não automatizados agora normalmente se restringem, ou deveriam se restringir, a atividades que demandam um cuidado maior, onde a execução manual de fato agrega valor ao produto.

Assim como no caso dos trabalhadores braçais, que no passado eram obrigados a levantar enormes peças pesadas para construir produtos, os técnicos de TI eram forçados a fazer trabalhos repetitivos por falta de uma tecnologia que pudessem lhes auxiliar.

Atenção técnico de infraestrutura! Do mesmo modo, como alguns profissionais braçais se queixavam das máquinas como vetor da falta de emprego, é necessário que os técnicos de TI façam uma autoavaliação do seu trabalho atual e percebam o quão repetitivo e pouco produtivo é seu dia a dia, caso você se encaixe como um artesão para todas as tarefas, talvez o processo industrial na área de gerência de servidores possa tirar seu sono no futuro, sendo assim fica aqui meu conselho: “Estude sobre as novidades do DevOps e caso ainda não saiba desenvolver código, corra, pois em pouco tempo seu chefe lhe cobrará a escrita de um módulo puppet ou receita chef para criação daquele servidor novo que antes você levava quase um dia inteiro para entregar”.

Fonte: http://pt.slideshare.net/randybias/architectures-for-open-and-scalable-clouds

Quer ficar antenado sobre notícias acerca essa nova cultura DevOps? Não deixe de visitar sempre (ou assinar o feed) desse site: http://devops-br.org/

Puppet 4 e suas melhores práticas

Com o lançamento do Puppet 4, algumas práticas serão depreciadas e outras são apenas desaconselhadas, sendo assim pretendo nesse texto fazer um resumo delas, afim de indicar quais as melhores práticas para evitar problemas no futuro.

Esse texto presume que você já sabe usar puppet, caso não saiba nada de puppet,  aconselho que leia um pouco sobre ele antes. Existe um máquina virtual com um ambiente perfeito para aprendizado. Você segue um guia PDF praticando nessa máquina, que foi projetada pra isso. Muito bom. Aconselho!

Vamos as práticas:

Herança de classe

Esse tipo de prática só é aconselhado para módulos do tipo “params”:

Má prática:

class foo {

}

class foo::baz inherits foo {

}

Prática aceitável:

class ssh (

$server = $ssh::params::server,

) inherits ssh::params {

}

class ssh::params {

server => false,

}

Chamada de módulo

Não use mais “import”. Essa função foi depreciada no Puppet 4.

Má prática:

# foo/manifests/init.pp

class foo {

import ‘bar.pp’

}

# foo/manifests/bar.pp

class foo::baz {

}

# foo/manifests/baz.pp

class foo::baz {

}

Qual classe foo::baz será usada?

Boa prática:

Use include ao invés de import

# foo/manifests/init.pp

class foo {

include ‘foo::baz’

}

# foo/manifests/bar.pp

class foo::baz {

}

Agora sabemos exatamente o que será utilizado.

Módulos remotos

Não é aconselhável alterar localmente módulos remotos (Aqueles retirados do forge e outros repositórios externos)! Caso precise modificar algo, use o módulo remoto parametrizável, crie seu próprio módulo com base nesse uso, mas caso seja uma melhoria genérica para todos, submeta sugestões ao upstream. Lembre-se, somos uma comunidade!

Lembre-se  também que você pode precisar atualizar esse módulos depois do upstream!

Variável não local

Pare de usar variável não local sem estabelecimento de escopo! É péssimo para o tratamento de problemas no futuro, pois quando existirem muitos módulos, você não terá ideia de onde esse valor é recebido.

Má prática:

class foo (

$bar = ‘baz’

){

}

class foo::baz {

notify { $bar },

}

Boa prática

class foo (

$bar = ‘baz’

){

}

class foo::baz {

notify { $foo::bar: },

}

Variável de template

Não use variável de template sem escopo, pois algumas delas conflitavam com métodos ruby e a utilização delas sem o “@” como prefixo foi depreciada.

Má prática

key = <%= var %>

Boa prática

key = <%= @var %>

Variável factor

Evite usar variável factor sem escopo superior.

Má prática:

class foo {

notify {“We are on OS: $operatingsystem”:}

}

Boa prática

class foo {

notify {“We are on OS: ${::operatingsystem}”:}

}

A sintaxe “::” especifica que a variável está no escopo superior, assim evitando que alguma variável local de um outro módulo possa afetar o seu valor.

Validação de valor

Sempre faça validação de valor da variáveis, pois dados errados podem impactar seu ambiente.

Má prática

class foo (

$server = hiera(‘server’,’localhost’)

){

notify {“We will use Server: ${server}”:}

}

Use a função “validate_string” do módulo stdlib para verificar se o valor recebido na variável de fato é uma string.

Boa prática

class foo (

$server = hiera(‘server’,’localhost’)

){

validate_string($server)

notify {“We will use Server: ${server}”:}

}

Caso tenha outras sugestões, coloque como comentário!

Esse texto foi feito com base nessa apresentação. A minha ideia foi descrever as melhores práticas e explicar um pouco sobre elas.

Coopercuc e Experimento Beer se unem para criar cerveja artesanal inédita com umbu

Sim, temos novidade no 7º Festival do Umbu: árvore da caatinga que deu de beber a Antônio Conselheiro agora dá cerveja também! Batizada de Saison Umbu, a bebida é resultado da associação de uma cooperativa baiana de agricultura familiar e uma empresa mineira especializada em cervejas com frutas e especiarias brasileiras cultivadas em comunidades nativas. A cerveja foi lançada nos dias 6 e 7 de março/2015, na sétima edição do Festival Regional do Umbu, na cidade de Uauá, na Bahia, e seus fabricantes pretendem distribuí-la em todo o país, além de destinar uma parte à exportação.

O umbu, de polpa suculenta e aromática, ganhou seu nome do tupi-guarani ymbu, “árvore que dá de beber”, por sua capacidade de armazenar água no ambiente árido da caatinga. Reconhecida nesse batismo pelos indígenas, a generosidade do umbuzeiro chega, no século XXI, aos apreciadores de cerveja, pelas artes da economia criativa.

Uauá é uma pequena cidade no Norte baiano, palco da primeira batalha da Guerra de Canudos. Antônio Conselheiro, líder de Canudos, socorria-se das reservas de água nas grossas raízes do umbuzeiro, para resistir ao cerco das tropas federais. Hoje, a Cooperativa Agropecuária Familiar de Canudos, Uauá e Curaçá (Coopercuc), exporta produtos feitos com umbu para a Europa, onde fazem sucesso nas redes de comércio justo e em feiras gastronômicas promovidas pelo Slow Food, movimento internacional de valorização da gastronomia e defesa da sociobiodiversidade.

O trabalho de beneficiamento do umbu e a divulgação dos seus produtos teve grande impulso com o apoio do Slow Food, que deu suporte à criação de minifábricas para processamento do fruto no sertão da Bahia, fortalecendo o trabalho realizado pelas comunidades integrantes da Coopercuc. O umbu é uma das Fortalezas do Slow Food no Brasil e essas ações de apoio e suporte acontecem para defender a espécie de potenciais riscos de desaparecimento.

A Coopercuc decidiu ampliar a linha de produtos Gravetero e experimentar a fruta no mercado das cervejas artesanais. Os escolhidos para a criação da receita e desenvolvimento da bebida foram os cervejeiros da Experimento Beer, de Belo Horizonte, Minas Gerais, fundada com a missão de criar cervejas especiais que valorizam a origem e a qualidade dos ingredientes nativos dos diversos biomas brasileiros. Para isso a Experimento Beer atua em parceria com cooperativas e comunidades de agricultura familiar e ecoextrativismo de todas as regiões do Brasil.

Integrantes das cooperativas Coopercuc (BA), Agreco (SC) e Coocaram (RO) visitam a Experimento Beer (MG), celebram parcerias e brindam com a primeira edição da cerveja artesanal Saison Umbu

Quem alinhavou a parceria da Experimento Beer com a Coopercuc foi o premiado estúdio DoDesign-s, escritório especializado em design e marketing que trabalha com comunidades no Brasil e na América do Sul desde 2003. A articulação da cervejaria com outras cooperativas seguem o mesmo caminho, tendo as costuras feitas pela DoDesign-s.

A associação da Coopercuc com a Experimento Beer é um exemplo do que vem sendo conhecido em todo mundo como “economia criativa”, termo criado pelo britânico John Hawkins para a capacidade de traduzir novas ideias e conceitos em produtos inovadores. Olhar sob um ângulo diferente e inovador, práticas às vezes milenares – como a preparação de alimentos e bebidas – é uma das formas encontradas pela economia criativa para trazer ao mundo outros tipos de produtos, de meios de produção e de consumo.

Instalando o docker host no Windows Server

Já tínhamos divulgado no lançamento da versão 1.6 que o cliente Docker já estava disponível para instalação no Windows, agora vamos demonstrar que é possível instalar o docker host no Windows Server 16 TP3.

O ambiente ainda está em beta, tanto o Windows Server 16 TP3, quanto a compatibilidade do Docker para Windows. A função push por exemplo ainda não está habilitada.

Mesmo sendo beta, acho que vale a pena testar pra ao menos entender como funciona.

Caso você use GNU/Linux e não queira instalar o Windows no seu disco rígido, você pode usar o virtualbox pra isso, mas não se esqueça de instalar a versão mais nova dele. Eu precisei instalar o VirtualBox da Sun na versão 5.0.2.

Primeiro baixe o CD do Windows Server 16 TP3.

Depois crie uma nova máquina virtual do tipo “Windows” e versão “Other Windows 64-bit”

Monte a ISO que acabou de baixar e inicie a instalação.

Quando solicitar qual o tipo de instalação, instale a que não requer experiência de usuário.

A instalação será bem rápida. (Por mais incrível que pareça). Ele solicitará a mudança de senha, para alternar entre campos de senha use “tab” e não “enter”.

Quando lhe for concedido acesso ao console digite:

powershell

Depois digite:

wget -uri http://aka.ms/setupcontainers -OutFile C:\ContainerSetup.ps1

Após baixar o script, digite o comando abaixo para instalar o docker:

C:\.\ContainerSetup.ps1

Ele reiniciará sua máquina virtual e demorará um pouco nessa tela (Caso sua internet seja tão lenta quanto a minha):

Essa é a tela que demonstra que o Docker foi instalado com sucesso:

Obs: Caso apresente um erro de “timeout” tente o comando novamente Isso aconteceu comigo e logo em seguida funcionou tranquilamente. Apenas demorou um pouco

Para iniciar uma máquina é muito simples

docker.exe run -it windowsservercore cmd.exe

Infelizmente ainda não é possível executar containers do GNU/Linux no Docker Host Windows, nem vice-versa, porem é possível usar os comandos docker e Dockerfile da mesma forma, apenas usando os as chamadas de comandos “RUN” equivalentes com cada sistema operacional.

O Docker funciona no Windows de forma semelhante ao GNU/Linux, ou seja, a promessa é que ele execute os containers de forma isolada também.

Divirta-se!

Fonte:

http://www.virtualclouds.info/?p=3393

https://blog.docker.com/2015/08/tp-docker-engine-windows-server-2016/

Como adicionar virtualhost aos logs do Varnish

Há algum tempo atrás escrevi um post mostrando como configurar o Varnish para escrever logs num formato modificado do Combined Log Format do Apache, esta modificação foi feita para adicionar o virtualhost %v no início de cada registro do log e na sintaxe do Apache se parece com o seguinte:

LogFormat "%v %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined

Isto foi feito com o varnishncsa-vhost, um script que faz o Varnish armazenar logs seguindo o formato acima, este script deveria estar obsoleto já que versões recentes do Varnish suportam customizar o formato dos logs através da opção -F, mas um problema no pacote Debian impede de fazer isto do “jeito certo”™.

Este problema foi citado em Workaround for broken varnishncsa logging due to shell mishandling of spaces in LOG_FORMAT variables e algumas soluções foram sugeridas, mas todas elas tem um “ar” de armengue. O problema já foi relatado no Debian em #657449 varnishncsa: please add a config option to allow a custom logging format (patch) mas ainda não foi solucionado.

Porque estou contando esse “blá blá blá”?

Recentemente precisei alterar o formato dos logs do Varnish em um servidor de produção e acabei utilizando o varnishncsa-vhost novamente e ele funcionou muito bem, isto me salvou dos sedutores “armengues que quebram na próxima atualização”.

Então se isto for útil para você de alguma forma utilize o repositório abaixo, eu subi uma nova versão do pacote Debian do varnishncsa-vhost lá:

deb http://debian.joenio.me unstable/

c3video for debconf #4

This is a follow-up to my previous post related the DebConf videoteam using a new software stack for the next conferences: http://acaia.ca/~tiago/posts/c3video-for-dc-take-3/.

As mentioned before, C3TT provides a set of scripts which will work in background for most reviewing and video processing tasks. The first will just check if the talk is done and mark the related ticket as recorded.

The second script, B-mount4cut, does a nice job by mounting a custom fuse filesystem providing the following files (more detailed explanation here:

uncut.dv: full original dv file used as input file for the final trimming.

project.kdenlive: Kdenlive project file for the operator. Once it's saved with the trim marks, fuse-vdv will do a parse on it and use the marks for cutting.

cut.dv: contains only the frames between the trim marks extracted from project.kdenlive.

cut-complete.dv: contains the frames between the trim marks extracted from project.kdenlive, plus a prepended intro and an appended video. Paths for these files should be previously set in the web interface as properties Processing.Path.Outro and Processing.Path.Intros. The outro file can be, for instance, an appended video file with a common thanks for sponsors. The intro files is usually an individual frame for each talk, being a colorful presentation poster. We can also set the intro duration in the Processing.Duration.Intro property.

cut.wav: demuxed audio from cut.dv

Note: in fact, fuse-vdv provides virtual video files as a concatenation of original input files, so avoiding copying large and redundant data. Ideally, these fuse mountpoints will be shared over the network for operators via glusterFS, but I'll skip that for now.

After adding the trimming marks and saving the project using Kdenlive, the operator should go to the web interface and mark the ticket as cut:

Mark ticket as cut

Note: I've been able to do the marks in Kdenlive using double-click in the video, then editing the crop start/end options. The buttons "[" and "]" didn't work in my Kdenlive version for some unknown reason.

In the current DebConf video environment I had to make a link builder for translating the path/file names to the C3TT format. So, for the Amsterdam/2015-08-13/09:57:02.dv we should have a amsterdam-2015.08.13-09_57_02.dv symlink.

From now the system will delivery the next tasks to C-cut-postprocessor script. This script will just check the marks from the Kdenlive project file and do the cutting job. So far it has worked perfectly here for the first video sessions in DebCamp, with zero hack in the original code, wow!

Next post will be about the encoding script, named D-encoding.