Ir para o conteúdo
ou

Thin logo

Tela cheia Sugerir um artigo
 Feed RSS

Grupo de Usuários Debian da Bahia - GUD/BA

6 de Dezembro de 2009, 22:00 , por Desconhecido -

Seja bem vind@, se você é um debiano (um baiano que usa debian) faça parte de nossa comunidade!


Vídeo interessante sobre DevOps, com legenda em pt-br

1 de Outubro de 2015, 11:01, por PSL-BA Feeds - 0sem comentários ainda

Desde que comecei a estudar sobre DevOps, encontrei um vídeo que me ajudou muito a entender como funciona essa nova cultura. Como o inglês ainda é uma barreira para alguns técnicos no Brasil, resolvi criar legendas em português do Brasil para esse vídeo:

Caso não apareça a legenda, habilite na barra de configuração do vídeo.



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

18 de Setembro de 2015, 18:01, por PSL-BA Feeds - 0sem comentários ainda

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.

sysadmin_artesao

“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.

automaçã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 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, 10:06, por PSL-BA Feeds - 0sem comentários ainda

Olha 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, 16:06, por PSL-BA Feeds - 0sem comentários ainda

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.

Puppet_Labs_Logo

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, 20:29, por PSL-BA Feeds - 0sem comentários ainda

Realizei uma palestra no Calango Hacker Club, num evento denominado “Docker MeetUp Brasília”. Após algumas edições, ela ficou assim: