Ir para o conteúdo
ou

Software livre Brasil

Tela cheia Sugerir um artigo
 Feed RSS

DevOps Brasil

7 de Dezembro de 2009, 0:00 , por Software Livre Brasil - | Ninguém está seguindo este artigo ainda.

Gomex: Lançamento do Docker 1.8

25 de Agosto de 2015, 2:05, por DevOps Brasil - 0sem comentários ainda

Não para de ter novidade no Docker! Mais um lançamento e muitas novidades.

Docker Content Trust

Agora é possínotaryvel assinar as imagens com sua chave privada antes de enviar para nuvem, com isso é possível validar as imagens e evitar que aconteçam fraudes no meio. Isso torna a solução como um todo bem mais segura.

Quer ler um pouco mais sobre o assunto? Veja esse link.

 

 

Docker Toolbox

Novo pacote de instalação para Mac OS X e Windows. Que conta com Docker client, Machine, Compose(Esse só para Max OS X) e virtualbox. Tudo que você precisa.

Mais informações sobre o ToolBox? Leia aqui.

toolboxDocker Engine 1.8

Essa nova versão da engine do Docker trás as novidades mais impactantes desse lançamento! Lembra que no lançamento que divulguei aqui, foi informado que o Docker tinha suporte a logs? Então, agora esse suporte aumentou, é suportado GELF e Fluentd.

Agora está estável a possibilidade de volumes de empresas terceiras! Tal como Blockbridge, Ceph, ClusterHQ, EMC e Portworx.

O binário docker agora tem suporte a enviar arquivos para o container:

docker cp foo.txt mycontainer:/foo.txt

O parâmetro “ps” agora tem suporte a modificação de formato “–format”.

E por fim, agora as configurações de cliente docker são armazenadas em ~/.docker. No caso de precisar executar múltiplas configurações em uma só máquina, você pode usar o parâmetro –config ou a variável de ambiente DOCKER_CONFIG.



Fernando (fike) Ike: building debian images by jigdo

19 de Agosto de 2015, 0:00, por DevOps Brasil - 0sem comentários ainda

A friend asked me how to got a Debian Old Image, she wanted to download Debian Squeeze DVD image. Unfortunately, it’s impossible to download by Debian-CD mirror because Squeeze isn’t more maintainer. So, it’s possible to get a Image by Debian-CD primary server but it’s locate in Sweden. Nothing problem, right? Well, She lives in Brazil and the download time is a little bit more than 8 hours.

A good tool to “download” a Debian image is the Jigdo. It’s a program to synchronize repositories and generate Images. It get packages and build a image locally in your computer.

I made a simple test, I used jigdo to “download” the first Squeeze DVD by brazilian repository (Unicamp) and compare with a download image by PR (Primary Server). The difference was huge, PS download took a long time to finish (8 hours) and Unicamp mirror finished in 100 minutes.

Well, let’s go to practice.

Install jigdo

{% codeblock lang:bash %} #aptitude install jigdo {% endcodeblock %}

Downloading and building image

The jigdo file (.jigdo) is simple list with all packages and hash of a instalation image. You need it to start the downloads. In this case, I used jigdo file to build first Squeeze DVD.

{% codeblock %} $jigdo-lite http://cdimage.debian.org/cdimage/archive/6.0.10/amd64/jigdo-dvd/debian-6.0.10-amd64-DVD-1.jigdo {% endcodeblock %}

Before to begin download, jidgo need some arguments. Fill arguments of your preference but remember that the argument more important is the mirror. If you have doubt what’s mirror is more fast, you can use netselect-apt to discovery. For my test, I’m used Unicamp mirror (http://debian.las.ic.unicamp.br/debian).

My jigdo-lite conf file.

{% codeblock %}

$cat ~/.jigdo-lite

jigdo=” debianMirror=‘http://debian.las.ic.unicamp.br/debian/' nonusMirror=” tmpDir=‘.’ jigdoOpts=‘–cache jigdo-file-cache.db’ wgetOpts=‘–passive-ftp –dot-style=mega –continue –timeout=30’ scanMenu=’ {% endcodeblock %}

Nice, huh?

Take a coffee and forget to download Debian images using others programs (curl, wget, etc.). :)



Ricardo Martins: Como instalar o Jenkins

12 de Agosto de 2015, 17:53, por DevOps Brasil - 0sem comentários ainda

A idéia deste post é criar um “mini-howto” da instalação do Jenkins. Eu não vou entrar em muitos detalhes sobre o que é o Jenkins. Se você quiser saber um pouco mais sobre ele, separei os dois links abaixo, que são uma excelente documentação: http://imasters.com.br/desenvolvimento/serie-integracao-continua-deploy-automatizando-jenkins-tomcat/ http://www.infoq.com/br/presentations/turbinando-testes-com-jenkins A parte de configuração também pode variar muito, e dependerá […]

O post Como instalar o Jenkins apareceu primeiro em Ricardo Martins.



Fernando (fike) Ike: fisl 16

10 de Agosto de 2015, 0:00, por DevOps Brasil - 0sem comentários ainda

#{% img center /images/fisl16.png %} fisl16.png

FISL 16 aconteceu algumas semanas atrás… e depois de nem tão rigoroso inverno consegui rascunhar alguma coisas sobre o evento.

** Impressões **

Como sempre, sempre bom rever os amigos e conhecidos de inúmero projetos que participam. O evento não estava tão lotado como nos últimos anos que participei mas mesmo sim acredito que teve um bom público.

A internet até que funcionou razoavelmente bem, o wifi do evento era usável a maior parte do tempo e também gostei das palestras que assisti. Curti demais participar da Mini-Debconf realizada durante o FISL, fico feliz que em 2015 no Brasil serão (no mínimo) 3 Micro/Mini-Debconf. :)

** As minhas apresentações **

Este ano fiz duas apresentações no FISL16, uma sobre Web Performance e a outra sobre Management 3.0. A apresentação de de Web Performance foi a última vez que apresentei (acho), fiz algumas pequenas atualizações e acréscimo de exemplos que a deixou com +- 100 lâminas (slides). Já tem material suficiente para escrever um livro (quem sabe…). ;)

A apresentação sobre Management 3.0 é sobre como foi descobrir que usamos (equipe de TI que participei) esse conceito antes de saber que existiu um nome. Eu descobri Management 3.0 depois de participar de um curso de Scrum com Manoel Pimentel, isso foi alguns anos depois que já não era mais gerente. Ele me ajudou bastante para avaliar os erros e acertos como gerente. Recomendo para quem se interessar desempenhar o papel de líder de equipe ou chefia a estudar um pouco mais sobre tema.

*** Um milhão de usuários simultâneos ***

O vídeo da apresentação pode ser acessado por aqui e aqui.

*** Management 3.0 ***

O vídeo da apresentação pode ser acessado por aqui.



Ayrton Araujo: Blinking lights when the build status change

5 de Agosto de 2015, 22:10, por DevOps Brasil - 0sem comentários ainda

In Agile methodologies, we learn as good practice to start giving visibility in more efficient ways besides using the typical e-mail method.

For example, a physical kanban board is more suitable for communicating as a digital version. As everyone will see the progress and obstacles as they get close to a team (and, of course, the board should be near the team). The digital version is not bad, but it needs a lot more self-discipline than the physical one.

I will talk more about good practices to give visibility to digital kanbans over the next posts. Today I want to tell a little about how to do this with the continuous integration process.

Throughout continuous integration, we have a distinct scenario because typically only the development team members follow this process, where it is quite common:

  • The build agent starts to send e-mails when someone breaks tests;
  • Developers do not open the mailbox very often throughout the day. Usually, they are focused on making code with due heroic dates that the dev team stipulated themselves (or at least agreed);
  • When devs start to being disturbed by the build agent, they move the related emails to a label and skip the inbox;
  • These emails never will be seen again.

What if we create a physical way to communicate these changes? As the physical kanban, everyone would know what’s going on when they approach the team workspace, instantly.

Here’re some interesting examples:

ci-light01

ci-light02

ci-light03

However, before you start learning basic electronics and buying a bunch of stuff, I would like to teach you a very simple way to get started.

Start small, as people start enjoying it (especially people who sponsor the project), you should starting building complete lights for all your build pipeline.

For my example, I will use this light:

http://www.blynclight.com/products/blync-light?variant=328886579

You will need a machine with a USB port and connectivity to your local network. You could use a Raspberry Pi or a Linux machine that is close to the team.

That parts could be more expensive than buy an Arduino and some lights, however, you will only need 5 minutes to make it work. As the working hours of your team should be more expensive, this will be the cheapest way to get started as start from scratch with the electronic components.

The fun part about this light is a NodeJS library:

https://www.npmjs.com/package/blync

Some examples of usage (finally):

.gist table { margin-bottom: 0; }

Ayrton, what is the build status?

A video posted by Ayrton Araújo (@ayrtonfreeman) on Jul 24, 2015 at 4:47pm PDT

How does it work?

First you need add a user to plugdev group and create the 90-libusb.rules inside this path:

/etc/udev/rules.d/

Reload udev rules:

sudo udevadm control --reload-rules

You could test if everything is working fine with the light-cli.coffee:

coffee light-cli.coffee green
coffee light-cli.coffee red
coffee light-cli.coffee white
coffee light-cli.coffee magenta
coffee light-cli.coffee blue
coffee light-cli.coffee cyan 
coffee light-cli.coffee yellow 
coffee light-cli.coffee off

Expose a REST API:

coffee light-api.coffee

You could use forever to keep the API working after system restart.

Getting the things real:

When a build starts, you could call in the job:

curl http://lightmachineIPorDOMAIN:3333/api/v0/yellow

When a build succeed, you could call:

curl http://lightmachineIPorDOMAIN:3333/api/v0/green

If if fails:

curl http://lightmachineIPorDOMAIN:3333/api/v0/red

Now you can use your imagination. I’m color blind. 😀