O Projeto Software Livre Bahia (PSL-BA) é um movimento aberto que busca, através da força cooperativa, disseminar na esfera estadual os ideais de liberdade difundidos pela Fundação Software Livre (FSF), possibilitando assim a democratização do acesso a informação, através dos recursos oferecidos pelo Software Livre. Esta busca tem seus alicerces fundados na colaboração de todos, formando um movimento sinérgico que converge na efetivação dos ideais de Liberdade, Igualdade, Cooperação e Fraternidade.
O Projeto Software Live Bahia é formado pela articulação de indivíduos que atuam em instituições publicas e privadas, empresas, governos ou ONGs, e demais setores da sociedade. Além disso o projeto não é subordinado a qualquer entidade ou grupo social, e não estabelece nenhuma hierarquia formal na sua estrutura interna.
Deixando de ser artesão – Repensando a gerência de servidores
18 de Setembro de 2015, 21:01 - sem comentários aindaO 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/
Vídeo – 2º Docker Salvador
14 de Setembro de 2015, 13:06 - sem comentários aindaOlha como foi o nosso 2º Docker Salvador! Aconteceu no dia 12 de setembro de 2015, no Raul Hacker Club:
Evento: http://www.meetup.com/Docker-Salvador/events/224476092
Música: Biomythos (Revolution Void): https://www.jamendo.com/en/list/a2534/thread-soul
Puppet 4 e suas melhores práticas
8 de Setembro de 2015, 19:06 - sem comentários aindaCom 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.
Vídeo – Palestra sobre Docker Básico
3 de Setembro de 2015, 23:29 - sem comentários aindaRealizei uma palestra no Calango Hacker Club, num evento denominado “Docker MeetUp Brasília”. Após algumas edições, ela ficou assim:
Coopercuc e Experimento Beer se unem para criar cerveja artesanal inédita com umbu
2 de Setembro de 2015, 15:02 - sem comentários ainda
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.
