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


Lançamento do Docker 1.6

20 de Abril de 2015, por PSL-BA Feeds - 0sem comentários ainda

O Docker continua crescendo muito rápido e com pouco mais de 2 meses, lança uma nova versão recheada de novidades.

Entre as novidades desse lançamento temos: Label para containers, cliente Docker para Windows, driver para log. Isso sem contar com os lançamentos do compose 1.2, Swarm 0.2 e machine 0.2. Vamos detalhar um pouco esse mega release.

docker-whales-transparent

Label para containers

Esse recurso é muito interessante a nível de organização e agrupamento. Uma vez que as tags tem um papel quase como “versionamento”, as labels assumem a marcação que pode incluir “assuntos”, “funcionalidades”, “ambiente” e afins nos containers. Pode parecer pouca coisa para quem usa o Docker para uma situação específica, mas para grandes soluções é uma ajuda e tanto.

Quer aprender a usar? Leia aqui.

Cliente Docker para Windows

Finalmente parece que a Microsoft conseguiu entrar em alguma tendência no momento certo, pois está apostando fortemente no Docker. A demonstração disso foi a submissão de 70 pull requests. Assim como no MAC, O Windows somente poderá ser utilizado como cliente remoto que deve ser conectar a um Docker “Server”, que ainda é só pode ser instalado nativamente apenas no GNU/Linux.

Muitos amantes do GNU/Linux podem ficar tristes com essa declaração, mas a grande funcionalidade do Docker que é “Faça uma vez, rode em qualquer lugar” talvez dependa desse suporte nativo mais amplo da Microsoft. Isso levando em consideração que ela cumpra sua promessa de manter a compatibilidade.

Você pode ler mais sobre isso no blog da Azure.

Driver para log

Tem havido um número crescente de propostas para uma API de registro que lhe permitiria enviar logs de containers para outros sistemas, como Syslog ou um terceiro. Esse novo driver de log  segue o mesmo conceito de storage e exec já presente no Docker.

A opção docker run –log-driver tem três possibilidades:

json-file (padrão): Que é basicamente o que já usado no Docker atualmente. Todos os logs dos containers são armazenados na pasta /var/lib/docker/containers/<Containers ID>/<container id>-json.log

syslog: Como o próprio nome já revela, é uma forma de enviar esse log via syslog do host “hospedeiro”. Veja como funciona:

# docker run -d –log-driver=syslog gomex/debian:padrao echo “Hello”
c2ed7a98583c82a90111ffba5fb89e73dcd6e681a03c921da538a84ffd7216d0

No /var/log/syslog estará assim:

Apr 17 23:29:18 gondor docker[15432]: c2ed7a98583c: Hello

Perceba que temos tanto o nome aplicação docker como o ID resumido do container, o que é o suficiente para fazer uma boa gerência desse log. Ótimo para quem deseja minimizar o máximo de processos em execução no container, mas não abre mão de um log centralizado e organizado.

none: Como o próprio nome também já revela, é uma forma de não gerar log do container para o host “hospedeiro”. Essa opção é ótima para containers que geram logs desnecessários.

Outros lançamentos

A comunidade Docker promoverá alguns Meetups para apresentação das novidades do Swarm, Compose e Machine. Não perca!

Referência:

https://blog.docker.com/2015/04/docker-release-1-6/

 



Criação automatizada de imagens Docker (GitHub e Docker Hub)

13 de Abril de 2015, por PSL-BA Feeds - 0sem comentários ainda

Como expliquei no artigo anterior sobre Docker, o processo de criação de imagens no Docker é bem simples, mas requer algum esforço e acompanhamento para saber se ele concluiu corretamente e esse resultado será visualizado em linha de comando, normalmente imagem a imagem. Um trabalha “manual”.

Criação em massa

Quando você trabalha com muitas imagens, e a mudança dessas imagens é constante, você precisará de uma solução mais automatizada e de um processo mais simples pra viabilizar a criação dessas imagens. É nesse momento que entra o serviço de automatização de criação das imagens do Docker Hub junto ao GitHub.

Docker e GitHub, agora juntos! :)

Docker e GitHub, Juntos! :)

Automação de builds

O Docker Hub tem um serviço de Automação da criação de imagens (Build), com integração com GitHub, ou seja, toda vez que você efetuar um commit e push no Dockerfile do seu repositório será realizado automaticamente um novo build da imagem, já armazenando no Docker Hub e apresentando o log de criação dessa imagem. Praticamente uma integração contínua da sua imagem :)

Seleção_001

Olha como é fácil a interface!

Para configurar isso é muito simples. Basta seguir os passos abaixo:

  1. Crie uma Conta no Docker Hub e efetue login.
  2. Link sua conta do GitHub através do menu “Link Accounts”.
  3. Configure o build automatizado.
  4. Escolha o projeto GitHub que deseja utilizar. Lembre-se que ele precisa ter um Dockerfile para efetuar a build.
  5. Escolha a branch que você quer efetuar a build (Por padrão é usada a branch master).
  6. Dê um nome a esse build automatizado.
  7. Opcionalmente, aplique uma tag Docker tag para a build.
  8. Especifique onde o Dockerfile está localizado. O padrão é “/".

Uma vez o build automatizado é configurado ele será ativado automaticamente e em poucos minutos você pode visualizar sua imagem Docker Hub. Ela será mantida sincronizada com base no Dockerfile do seu repositório GitHub até que você desative o Build automatizado em questão.

Visualizando a situação da build

Se você quiser visualizar a situação do seu build automatizado, basta acessa o menu “Build detail” na sua imagem dentro da sua conta do Docker Hub, assim conseguirá visualizar o status da sua build e todo o histórico.

Como funciona a atualização

Vale lembrar que você o build automatizado não será ativado com o comando “docker push", você apenas poderá enviar modificação, e por consequência efetuar automaticamente o build dessa imagem, através do git commit e push para o repositório previamente configurado no link entre GitHub e Docker Hub.

Você pode criar múltiplos builds automatizados por repositório e configurar ele para apontar para um específico Dockerfile ou branch diferente.

Build Triggers

É possível ativar o build automatizado a partir de uma url. Basta habilitar o “Build triggers” em sua build automatizada. Agora você conseguirá gerar uma build por demanda e não apenas com base em commit e push. :)

Atenção!

Vale a pena lembrar que todo processo descrito aqui não leva em consideração repositórios e imagens privadas. Caso seja sua situação de não publicizar esse trabalho, tenha cuidado com relação a isso.

Referência

https://docs.docker.com/userguide/dockerrepos/



Docker poderia substituir o gerenciador de pacotes?

3 de Abril de 2015, por Desconhecido - 0sem comentários ainda

A utilização de containers, que tem hoje o Docker como principal representante, tem aumentado rapidamente com sua facilidade e portabilidade de liberação de aplicações prontas. Com base nisso, fica a seguinte pergunta: “Poderia a tecnologia de containers, como o Docker, ser utilizada para resolver o nosso antigo problema com gerenciador de pacotes? Alguns acreditam que containers podem ser um caminho para resolver a “dor de cabeça” no gerenciamento de dependência e incompatibilidade entre distribuições e versões do mesmo sistema.

recording-package-delivery-000005661610-100264112-primary.idge

Gerenciamento de pacotes no GNU/Linux sempre foi uma dor de cabeça para algumas situações.

No campo do “sim”: O pessoal do CoreOS, que são criadores de uma distribuições GNU/Linux, que gira inteiramente em torno de containers, e não dos pacotes, como unidade básica de modularidade.

Kelsey Hightower, Engenheiro Chef do CoreOS, diz que a empresa oferece “prova viva que não é apenas possível, como pode lidar melhor com designer de sistema e eficiência.” Contudo ele acredita que gerenciador de pacotes ainda é utilizável, “principalmente para construção de um sistema operacional a partir de um conjunto discreto de componentes que devem executar em conjunto. Esta é uma área onde os gerenciadores de pacotes do GNU/Linux brilham.” CoreOS não utiliza um gerenciador de pacotes típico, como apt ou yum, mas sim um sistema portage.

Kelsey alega que substituir inteiramente um sistema de gerenciador de pacotes de proposito genérico para o Docker ou outro gerenciador de container pode ser difícil, em parte porque o Docker não tem mecanismo para solucionar dependência. “Onde Docker brilha é no empacotamento e distribuição de aplicações” ele diz. (Docker se recusou a responder esse artigo, alegando restrição de tempo.)

Com ênfase maior da Red Hat em containers, é lógico que a empresa também poderá ver containers como um substituto para o gerenciamento de pacotes.

Lars Herrmann, gerente geral do “Red Hat Enterprise Linux” e “Red Hat Enterprise Virtualization” na Red Hat, acredita que é possível que o gerenciador de pacote seja substituído por containers, “mas esse não é o melhor caminho”.

Além da gerência de dependência, diz Herrmann em um email, que um gerenciador de pacote provem mais três outros “boons”: Instruções de onde será instalado o software em seu sistema, metadados estruturados para tornar fácil dizer o que e onde será instalado, e um mecanismo para verificar softwares instalados com base no metadado do gerenciador de pacotes.

Herrmann diz “Estes valores aplicam-se ainda em um mundo ‘container-centric’ ” O que significa que todas essas funções precisam ser replicados pelos containers. “Além disso, é preciso haver uma maneira fácil de ‘olhar’ para dentro desses containers, afim de verificar o que está lá dentro, e assim identificar quaisquer problemas conhecidos.”

Da mesma forma, o gerenciamento de pacotes abrange funções internas que os próprios containers ainda não lidam. De acordo com Herrmann, o Docker “agrega os pacotes para uma aplicação ou microservice inteiro; isso não ajuda obter os componentes certos para um container de forma funcional. Obviamente, essa tarefa não requer diretamente os gerenciadores de pacotes existentes, mas eles fazem um grande trabalho, então por que não usá-los?

Bryant Cantrill, CTO da Joyent (outra empresa até o pescoço no mundo do container) Também vê os containers e gerenciadores de pacotes servindo para funções separadas, desde que “uma imagem Docker está em uma camada de abstração mais elevado do que um pacote apt ou yum” Ele escreveu isso por e-mail.

Dito isso, ele acredita que o Docker poder tornar o empacotamento obsoleto, como o gerenciamento de pacote fez obsoleto a forma manual de desempacotar arquivos (como arquivos TAR) e assim se tornar um novo padrão de formato para aplicações. “Um engenheiro que conheço a muito tempo, coloca o Docker de forma diferente: Docker é ELF do século 21. (ELF é o ‘Executable and Likable Format‘ que é como o binário é representado em sistemas UNIX) De qualquer maneira, Docker parece prestes a se tornar o padrão de fato para a forma como se cria imagem para sistemas. Eu acho que isso é uma clara vitória tanto para desenvolvedores, como para os operadores de infraestrutura.”

Esse artigo é uma tradução livre do artigo “Could Docker replace package management?” da Infoworld. Encontrei esse artigo e achei interessante para levantar esse debate. Comentem, o que acham disso? Realmente o Docker, ou qualquer outro gerenciador de containers pode ser um sucessor do gerenciador de pacotes?

Minha opinião

Eu acho que containers é um bom caminho para “tornar” obsoleto o gerenciamento de pacotes, mas ainda não está pronto. As duas soluções vão coexistir durante algum tempo, mas realmente acho que o nível de abstração subirá um pouco mais em médio prazo, pois não acredito que teremos tempo para resolver manualmente instalações de dependência para soluções complexas.

Assim como hoje é possível compilar os pacotes manualmente, acho que no futuro continuaremos podendo instalar “da moda antiga”, mas o uso da solução de containers prontos, customizáveis e portáveis será quase uma necessidade. Talvez isso faça o conceito de distribuição perder relevância, mas é algo que ainda não tenho como certo em minha reflexão ainda e fica para outro texto.



Ressuscitando seu celular após falha em mudança de flash

30 de Março de 2015, por Desconhecido - 0sem comentários ainda

Como sou muito curioso e meu instinto hacker as vezes fala mais alto, comecei a futucar cada vez mais profundamente meu celular e testar algumas loucuras nele.

Em uma dessas tentativas, mesmo após ter feito backup, meu celular ficava com tela toda preta e nem aparecia a logo da empresa fornecedora no meu celular :( Pensei logo: “Pronto, perdi meu celular. Ganhei um peso de papel bem caro”.

Eu modifiquei o boot.img dele por uma imagem possivelmente defeituosa, mas eu jurava que ainda assim eu conseguiria acessar o recovery e ao menos restaurar o backup. Me enganei! :P

Acessando o fórum XDA Developers eu pude encontrar MUITA documentação do que poderia ser feito para resolver e tentei de tudo, mas nada parecia funcionar e meu nervosismo pela minha falha tornou minha busca no fórum bem mais complicada.

Felizmente eu consegui recolocar a flash de fábrica de volta no meu celular, eu segui os passos abaixo.

Firmware

Baixe o firmware relacionado ao seu celular, o meu é Xperia M e você pode pegar ele aqui aqui, mas caso o seu seja outro, basta procurar. A extensão dele é “ftf” e o meu firmware tinha 710 MB de tamanho.

Flasthtools

Primeiro precisamos baixar ele! Apenas baixe e coloque em uma pasta a sua escolha.

Ele vai reclamar que precisa da biblioteca libusb. Que pode ser obtida aqui. Depois de baixar vamos compilar e instalar com os comandos abaixo:

# tar xjvf libusbx-1.0.18.tar.bz2

# cd libusbx-1.0.18

# ./configure

# make

# make install

# ldconfig

O Flashtools precisa das bibliotecas no /usr/lib, mas a instalação da lib coloca ela no /usr/local/lib. Você pode mover para o local desejado, eu preferi criar link simbólico:

# ln -s /usr/local/lib/libusb-1.0.so /usr/lib/libusbx-1.0.so
# ln -s /usr/local/lib/libusb-1.0.so.0.1.0 /usr/lib/libusbx-1.0.so.0.1.0

Coloque o firmaware obtido no passo anterior na pasta firmawares do Flashtools.

Pronto! Agora inicie o seu flashtools como root. Ele abrirá uma tela pedindo pra mover a pasta firmwares de onde você baixou para /root/.flashTool/firmwares. Pode mover, isso mesmo mover, pois caso ele perceba que ainda existe a pasta firmawares no local hoje você executa o flashtools ele não abrirá o software corretamente.

Ele vai abrir uma tela mais ou menos assim:

v8

Clique no ícone do raio e selecione a opção “flashmode”:

Sele&#xe7;&#xe3;o_010

Na próxima tela selecione o firmware desejado:

Sele&#xe7;&#xe3;o_011

Caso queira mudar mais alguma coisa, fique a vontade, eu não precisei mudar nada :) Basta clicar no botão “Flash”.

Agora aparecerá uma tela como essa, solicitando que seu celular entre em flashmode:

No caso do meu celular, eu arranquei a bateira, recoloquei ela, coloquei o cabo USB e pressionei o botão de volume para baixo até que o software flashtool reconhece ele :)

Depois ele começou o envio da flash. Bastou e esperar e meu celular estava prontinho para eu recomeçar tudo de novo :)

Muito obrigado a Nicklas Van Dam, que me ajudou MUITO lá no fórum XDA :)



Embarque na viagem das cooperativas do ano

29 de Março de 2015, por Desconhecido - 0sem comentários ainda

Desenho interc&#xe2;mbio cooperativista

Em Novembro de 2014 a Colivre, cooperativa de tecnologias livres, empresa na qual sou sócio ganhou o prêmio de cooperativa do ano 2014 na categoria de Inovação e Tecnologia, este prêmio nos deu o direito a uma viagem de integração entre as cooperativas vencedoras, nesta viagem a Colivre foi representada por mim e Daniela Feitosa, neste post faço um breve relato desta viagem.

No dia 24 de Março chegamos a Brasília, lá visitamos a OCB, fomos recepcionados por Fernanda Belisário e Gabriela Prado, elas nos deram boas-vindas e convidaram para assistir a uma palestra de Martha Gabriel sobre estratégia de marketing, Marta falou da importância de cuidar da sua marca, pegadas digitais, sombra e diversos outros conceitos de marketing.

No mesmo dia, à noite, houve o lançamento da Agenda Institucional do Cooperativismo 2015 com a presença de representantes da Ocergs-Sescoop/RS, sistema OCB, senadores, deputados, presidentes e superintendentes de unidades estaduais. A agenda apresenta as principais demandas do sistema cooperativo Brasileiro aos poderes Legislativo, Executivo e Judiciário para o ano de 2015.

No dia 25, já em Porto Alegre, visitamos a Escoop - Faculdade de Tecnologia do Cooperativismo, lá ouvimos uma bela apresentação do senhor presidente do Sistema Ocergs-Sescoop/RS, Vergilio Perius, explicou sobre o sistema cooperativista, explanou sobre o surgimento das cooperativas no Brasil e nos ensinou bastante sobre os 7 princípios do cooperativismo, dando destaque especial a importância da intercooperação.

Em seguida o coordenador Derli Schmidt detalhou o funcionamento e a missão da escola, mostrando os cursos disponíveis e a metodologia de ensino altamente preocupada com a qualidade do ensino, com um viés acadêmico, preocupada em produzir conhecimento inédito e de qualidade sobre cooperativismo no Brasil. Nossa visita foi noticiada no site da Ocergs/RS.

No dia seguinte, 26 de Março, visitamos a Sicredi Pioneira, fomos recebidos pelo senhor Mário José Konzen, vice-presidente da cooperativa, ele nos falou sobre o início do sistema Sicredi e a força do movimento cooperativista na cidade de Nova Petrópolis/RS, a “Capital Nacional do Cooperativismo”. Citou detalhes do programa “A união faz a vida”, uma iniciativa do Sicredi com o objetivo de promover práticas de educação focadas nos princípios da cooperação e cidadania.

Em seguida, Mário Konza, nos convidou a conhecer a Cooebompa, uma cooperativa escolar formada por alunos da Escola Bom Pastor, uma iniciativa interessantíssima que deixou todos os representantes das cooperativas campeâs com os olhos brilhando de emoção. Tivemos a oportunidade de assistir a Assembléia Geral Ordinária e ver um show de organização e determinação! O professor e coordernador do projeto, Everaldo Marini, faz um belo trabalho e merece todo o apoio possível para continuar com o projeto.

Da lá seguimos ao Memorial Padre Amstad, o senhor Mário nos falou da vida desde padre, criador do sistema de crédito cooperativo no Brasil.

Na sequência visitamos a Cooperativa Piá, uma cooperativa agropecuária de leite e frutas, o presidente, Gilberto Kny, relatou a história da cooperativa e destacou a preocupação com os seus associados, em sua maioria pequenos produtores. A nossa comitiva experimentou alguns dos produtos da Piá, como iogurte e leite achocolatado, todos acharam uma delícia, infelizmente não pude experimentar já que não consumo leite ou derivados. A Piá bem que poderia produzir algo à base de soja ou alguma alternativa ao leite.

Saindo da Cooperativa Piá fomos conhecer um dos produtores associados, conhecemos a fazenda “Sítio do Leite”, eles produzem leite e dizem que fazer parte da cooperativa facilita a vida pois não precisam se preocupar com a venda já que a Piá garante a compra de toda a produção.

Dia seguinte, 27 de Março, último dia de viagem, visitamos o CAS, Centro Admistrativo Sicredi, vimos o funcionamento da cooperativa, seus princípios e valores, conhecemos a Biblioteca do sistema e o Datacenter. O Datacenter ocupa um andar inteiro do prédio e tem uma infraestrutura impressionante, mantida inteiramente pela equipe do Sicredi.

Ainda no Sicredi, seguimos para um almoço em grupo e partimos para o aeroporto de volta para casa chegando ao fim desta viagem ao mundo cooperativista na presença de ótimas pessoas, dedicadas a criar um mundo melhor, mais humano, mais justo, mais cooperativo.

Deixo um agradecimento especial ao sistema OCB pela ótima organização do evento e pelo convite, Belmira Oliveira, Fernanda Belisário, Gabriela Prado, Igor Vianna, Patricia Resende e Sheila Malta Santos.

Muito obrigado!

Agradeço também a todos os membros da nossa comitiva, representantes das cooperativas campeâs, foram momentos de muito aprendizado:

Um agradecimento especial a Sheila Malta Santos (OCB) pela imagem utilizada no título deste post, este desenhado foi criado por ela durante o vôo de ida ao evento.

Valeu Sheila, ficou muito bom!