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.

Mundo Docker: Docker Global Mentor Week – Review

29 de Novembro de 2016, 14:35, por DevOps Brasil - 0sem comentários ainda

Oi Pessoal,

Gostaríamos de trazer hoje um apanhado geral do que foi o Docker Mentor Week esse ano. Quais as percepções dos participantes, conteúdo abordado, dentre muitas outras informações sobre esse grande evento sobre Docker.

Quem participou das edições no Rio de Janeiro, São Paulo, Goiânia e Gravataí, pôde ter a experiência de como é realizar um treinamento tão focado e ao mesmo tempo descontraído, podendo interagir com outros usuários de Docker que tiveram ou tem as mesmas dificuldades, dúvidas e soluções. Esse tipo de experiência reforça cada vez mais a ideia de comunidade aberta, onde todos são bem vindos e todos tem seu papel, sendo você um iniciante ou ainda alguém com uma bagagem maior de conhecimento nessa tecnologia.

Segundo Fernando Ike, um dos organizadores e mentors do evento em São Paulo, é possível descrever o evento como:
“Muito gratificante compartilhar um pouco da experiência com os outros e também aprender alguns truques novos sobre containers.”

Em todos os eventos notamos que o público era o mais variado possível, desde quem nunca tinha trabalhado com Docker, Devs, Ops, etc. E o mais interessante, e que ocorreu em quase todas as edições foi o caso do pessoal de desenvolvimento realizar trilhas de ops e vise-versa, o que acaba gerando ainda mais engajamento por ambas as partes.

Será que todo o mundo pensa da mesma forma?

Nós do MundoDocker não poderíamos ficar sem essa resposta, não é mesmo? ;). Para isso contamos com a ajuda do pessoal do Imasters, que estiveram presentes no evento que ocorreu em São Francisco, na Califórnia mesmo (Durante o DevTrip). O Matheus Moreira e o Romulo Scampini que participaram do DevTrip e foram até o evento na sede do Docker, resumiram a participação deles no evento como:

Romulo:
“Foi o meetup mais produtivo que já fui, pois normalmente em meetups só temos a apresentação de algum conteúdo, e levamos de lição de casa a prática do conhecimento obtido.
No Global Mentor Week, além de aprender pudemos colocar em prática todo o conhecimento obtido, e ainda tivemos o apoio de engenheiros especialistas.”

Matheus:
“Foi bem legal porque tinha um monte de mentores a nossa disposição pra tirar todas as duvidas que quissemos e ai adivinha os mentores eram os devs do core do Docker”.
#sortudos

Separamos algumas fotos dos eventos, em São Francisco.

21c93366-8b36-48c2-82b2-6a4a1d06e211 d732c3d3-b7bc-4813-b33b-3efbc250090b 337e3dc4-894d-4c4b-8e27-a7f2e02f8355 MentoRWeek-Geral b411fe2a-e264-4022-89da-543159351aff f397e6c4-4ed9-479d-b039-1cdba1e296ea fc0214c9-7afe-4db5-893e-0f7465c09f9d fb556af0-e6aa-4de2-a5f8-aba793f82d9b ced00bc4-dc4c-4530-8e4c-a434a96a4f5d 94f01231-2207-444a-b2c9-0eb651d01efa

Em São Paulo:

600_456185871 600_456185886 600_456185900 600_456185926 600_456185944 600_456214932 highres_456269914
Fonte: https://www.meetup.com/Docker-Sao-Paulo/events/235267786/

Em Goiânia:

803711244_141043_6802631868420469985 803712332_139739_11676414205401214099 803729920_104052_816614692202900550 803730915_103105_18360553536299592442

Estivemos presente no evento que ocorreu na sede da Umbler em Gravataí no último sábado (26/11), e claro que registramos tudo :). Foi uma experiência incrível participar como Mentors desse evento, nem tudo foi perfeito, mas a troca de conhecimento e networking foram demais, foi muito gratificante poder ajudar a comunidade e dar nossa contribuição para o esclarecimento de dúvidas e passagem de conhecimento. Vamos ver umas fotos?

dscn2530 dscn2536 dscn2542 dscn2549 dscn2557 dscn2558 dscn2586 dscn2599 dscn2627 dscn2629 dscn2638

Quer contribuir também? Então fique ligado nos meetup de Docker de sua cidade, não sabe onde tem? Comenta ai e vamos achar um o mais próximo de você.

Acabamos por aqui, e como sempre, nos ajude divulgando o blog 😉

Grande abraço a todos!



Mundo Docker: Docker Global Mentor Week

11 de Novembro de 2016, 11:21, por DevOps Brasil - 0sem comentários ainda

Olá Pessoal!

Para quem não viu ainda, na quinzena final de novembro será realizado uma das maiores ações do Docker para treinamento e troca de experiência entre seus usuários, esse evento foi chamado de Docker Global Mentor Week.

Essa é uma ação coordenada diretamente pela equipe do Docker com a ajuda dos organizadores dos grupos de meetup docker pelo mundo, o objetivo é simples: Dar treinamento técnico de alto nível de maneira abrangente e uniforme, ou seja, o conteúdo abordado em Singapura, é o mesmo no México, na Inglaterra e claro aqui no Brasil :). SIM teremos esse evento ocorrendo aqui no Brasil também, vou deixar abaixo os links desses eventos para que você possa se inscrever.

Mas afinal, esse é apenas mais um encontro do grupo de Meetup? Sim e Não, sim porque os canais utilizados para divulgação desse evento são os grupos de meetup e não porque esse evento tem conteúdo definido pela equipe do Docker e é repassado através de seus Mentors, que são pessoas ativas na comunidade docker e que auxiliam na divulgação de conteúdo, disseminação da tecnologia e enriquecimento da comunidade local. Você encontrará em cada evento no mínimo 1 Mentor, então não deixe de tirar suas dúvidas com ele(s).

Ok Cristiano, gostei, mas e valor? Bom, isso é um problema, por ser um evento oficial realizado no mundo inteiro, o valor para realizar esse treinamento é……. ZERO, sim é evento totalmente de graça, e agora, qual a sua desculpa? 😉

E o conteúdo?

A equipe do Docker definiu uma série de trilhas que podem ser abordadas durante o evento, é claro que todas é impossível de serem realizadas num período de 3 a 4 horas, então cada usuário defini o que deverá ver no evento, e os mentor auxiliaram na execução do treinamento e esclarecimento de dúvidas. Os conteúdos em si vão do básico (criação de containers, Dockerfile, etc) até o avançado (orquestração, serviços, rede, volume, etc).

Onde serão realizados aqui no Brasil?

Temos por enquanto, 4 eventos confirmados aqui no Brasil, são eles:

Docker Global Mentor Week – Goiania – 14/11

http://www.meetup.com/pt-BR/Docker-Goiania/events/234750966/?eventId=234750966

 

Docker Global Mentor Week – Rio de Janeiro  – 16/11

http://www.meetup.com/pt-BR/Docker-Rio-de-Janeiro/events/234784863/?eventId=234784863&chapter_analytics_code=UA-48368587-1

 

Docker Global Mentor Week – São Paulo – 19/11

https://www.meetup.com/pt-BR/Docker-Sao-Paulo/events/235267786/?eventId=235267786&chapter_analytics_code=UA-48368587-1

 

Docker Global Mentor Week – Porto Alegre – 26/11

http://www.meetup.com/pt-BR/Docker-Porto-Alegre/events/235451287/?eventId=235451287&chapter_analytics_code=UA-48368587-1

 

O MundoDocker estará presente? Claro! Vamos auxiliar o pessoal do grupo de Porto Alegre!

 

Era isso por hoje pessoal, ajude você também divulgando os eventos e claro o blog 🙂

 

Grande abraço!



Gomex: Uma analise do texto “Docker in Production: A History of Failure”

10 de Novembro de 2016, 14:55, por DevOps Brasil - 0sem comentários ainda

Um texto (em inglês apenas) foi lançado na internet e isso causou um certo alvoroço na comunidade, pois já pelo título é bem impactante “Docker em produção: Uma história de fracasso”.

Pelo título eu imaginei que seria uma extensa e detalhada explicação sobre o que deu errado para eles, e apresentar os caminhos que eles seguiram para contornar, assim como demonstrar em qual momento foi impossível continuar.

Pra contextualizar, quero deixar claro que fui ler o texto realmente pensando em obter dados para me ajudar a trabalhar em projetos futuros. Coisas que eu poderia aprender previamente e ver se tinha soluções alternativas, mas infelizmente não foi isso que vi, ao menos não na maioria do texto.

Pra resumir bem, o texto tem um tom bem irônico e é claramente o desabafo de uma equipe frustada com o uso da tecnologia, que na minha opinião foi usada de forma equivocada e até mesmo sem uma pesquisa mais profunda sobre as possíveis soluções e contramedidas.

Pra organizar a minha argumentação, vou separar elas por tópicos do texto.

Docker Issue: Breaking changes and regressions

Nesse capítulo ele fala basicamente de problemas de retrocompatibilidade, que existe mesmo, mas não apresenta quais os problemas reais ele encontrou na regressão, apenas tocou superficialmente em redes, mas sequer mostrou um caso real.

No Bônus, faltou explicar que o Docker não foi removido do repositório do Debian, ele apenas não entrou na versão nova. Não achei o motivo ainda, mas arrisco dizer que a velocidade de lançamento do Docker não funciona bem com o esquema de empacotamento do repositório estável do Debian.

Aqui o link da situação do pacote no Debian: https://tracker.debian.org/pkg/docker.io.

O Docker oferece repositórios próprios com pacotes Debian, que aparentemente é seguro e a atualização é constante.

Docker Issue: Can’t clean old images

Isso é realmente chato e precisa ser corrigido, mas tem uma solução da Spotify que pode ajudar: https://github.com/spotify/docker-gc

Linux 3.x: Unstable storage drivers

Nesse capítulo ele fala de como os drives AUFS do kernel tem falhas e como causa kernel panic no sistema, ou seja, isso tem muito mais a ver com as versões do kernel que ele usa nas distribuições dele do que o Docker em sí.

Linux 4.x: The kernel officially dropped docker support

Ele explica que o AUFS não é mais suportado nos kernel 4.x e faz uma afirmação falsa:

“How does docker work without AUFS then? Well, it doesn’t.”

Funciona sim desde 2015, inclusive existem artigos falando para não usar mais AUFS. Achei esse no google na primeira página de busca: https://sthbrx.github.io/blog/2015/10/30/docker-just-stop-using-aufs/

The debacle of Overlay

Ele fala que para adotar o Docker você precisa constantemente modificar seu ambiente host, com atualização de kernel e afins. Infelizmente isso é verdade, mas acho que isso se dá mais por conta da velocidade como tudo foi construído nesse curto espaço de tempo. Em todo caso, não acredito que isso seja um problema, pois estamos em um momento de servidores descartáveis, ou seja, refazer um outro host com as configurações ideais, testar ele e então subir os containers nesse novo nó não deveria ser algo custoso para uma empresa moderna.

Bonus: The worldwide docker outage

Nesse capítulo ele fala sobre um grande downtime que o serviço do Docker gerou na instalação dos pacotes, pois a chave estava errada. Infelizmente isso é verdade e foi corrigido com uma certa lentidão. Ponto negativo total mesmo.

Docker Registry Issue: Abandon and Extinguish

Nesse capítulo ele fala como a v1 pra v2 do registry foi completamente reconstruída e ao abandonar a v1 o Docker não fez ofereceu mecanismos para uma migração, o que é mentira, pois existe ferramenta para auxiliar a migração: https://github.com/docker/migrator

Docker Registry Issue: Can’t clean images

Isso de fato é um problema, que tem bug aberto até hoje: https://github.com/docker/docker-registry/issues/1004

Docker Issue: The release cycle

O texto fala muito sobre falta de retrocompatibilidade, mas os poucos exemplos que ele apresentam são fracos ou inexistentes.

Banned from the core

Nesse capítulo ele descreve que aplicação erlang, que é core para o ambiente deles, não funcionou bem no Docker por alguns motivos e eles então concluíram que docker não está pronto para nada crítico. Constatação feita com base em uma única experiência.

Se você olhar esse comentário, verá que existe uma outra pessoa falando que roda erlang sem problemas no Docker.

Banned from the DBA

Nesse texto ele descreve o porque não usou Docker como banco de dados, mas novamente sem detalhar o suficiente para podermos inclusive aprender com a falha deles.

Eles provavelmente não usaram volumes para armazenar os dados, pois ele descreve o comportamento das camadas das imagens Docker, que de fato não foram pensadas para armazenar dados variáveis dentro dos containers.

É necessário utilizar volumes para esse tipo de ação.

Para quem quiser saber um pouco mais sobre MySQL no Docker, vejam esse artigo: http://mysqlserverteam.com/mysql-with-docker-performance-characteristics/

Outros capítulos

Ele repete um pouco o que já foi dito e deixar a ironia ficar ainda mais pesada, colocando gifs engraçados para reforçar o clima cômico da coisa.

Em resumo acho esperado que o Docker não funcione bem para a maioria dos casos, pois como já foi muito dito em vários espaços que o Docker NÃO É UMA BALA DE PRATA, ou seja, é possível sim que não será adequado para todos os casos, mas dai com base em uma experiência ruim, que muitas vezes foi fruto de uma má implementação inclusive, dizer que o Docker não está pronto para produção chega a ser hilária.

Novamente, juro que não tinha intenção de ler o texto para formular uma resposta para o artigo, mas foi inevitável dado a tantas pessoas que me marcaram para eu me posicionar sobre o ocorrido.

Agradecimentos

Quero agradecer a Somatório, que sempre me ajuda nas revisões dos artigos e Fukui por ter me marcado em uma postagem e assim me estimulou a de fato divulgar esse material.



Mundo Docker: Desenvolvimento com Docker

3 de Novembro de 2016, 13:24, por DevOps Brasil - 0sem comentários ainda

Oi Pessoal,

A intenção hoje é trazer para vocês um conteúdo mais voltado para as equipes de desenvolvimento, ilustrando como é possível automatizar alguns pontos do seu trabalho utilizando Docker e como ele tornará as equipes mais eficientes naquilo que precisam ser: Entrega de resultado, óbvio.

Neste exemplo abordaremos um pouco sobre como é fácil montar um ambiente de desenvolvimento local utilizando nginx, php e mysql, este será, é claro, o primeiro passo em seu caminho para utilizar docker no seu dia-a-dia. Bom, chega de conversa, mãos a obra :).

Obviamente, nesse post não abordaremos como você deve instalar o Docker, para isso temos esse post que vai lhe ajudar muito, veja também que vamos usar nesse ambiente o docker compose, e claro, levamos em consideração que você está utilizando Docker em seu host de desenvolvimento, seja ele Windows, Linux ou Mac, e não no servidor de produção.

A receita

Ok, atendo a esses requisitos, e agora Cristiano, o que faço?

Primeiramente você deve criar, dentro de seu diretório de trabalho um arquivo para que o Docker Compose possa dar inicio a sua stack, e como você viu no post sobre o docker compose, o formato dele é de um arquivo do tipo Yaml, vamos utilizar a versão 2 do Docker Compose, que trás algumas melhorias, mas que difere um pouco na sintaxe, veja o exemplo que vamos usar nesse post:

# Utilizando sintaxe da versão 2:
version: '2'

volumes:
 database_data:
 driver: local

services:
###########################
# Container Web (Nginx)
###########################
 nginx:
 image: nginx:latest
 ports:
 - 8080:80
 volumes:
 - ./nginx/default.conf:/etc/nginx/conf.d/default.conf
 volumes_from:
 - php

###########################
# Container PHP
###########################
 php:
 build: ./php/
 expose:
 - 9000
 volumes:
 - .:/var/www/html

###########################
# Container de banco de dados (MySQL)
###########################
 mysql:
 image: mysql:latest
 expose:
 - 3306
 volumes:
 - database_data:/var/lib/mysql
 environment:
 MYSQL_ROOT_PASSWORD: senha
 MYSQL_DATABASE: projeto
 MYSQL_USER: projeto
 MYSQL_PASSWORD: projeto

A grande diferença entre a versão 1 e 2 do Docker Compose está relacionado a utilização de algumas tags especiais, entre elas: services e volumes. Essas tags obviamente foram adicionadas por um bom motivo, e esse motivo é você poder ter múltiplos serviços dentro de uma stack, mas ter a flexibilidade de escalonar ou modificar atributos de um único serviço dentro de sua stack, sem precisar mexer em toda ela, isso é muito bom, não?

Outro motivo está relacionado ao uso de volumes para a persistência de dados, você não quer perder todo seu trabalho se seu container for acidentalmente removido, certo? E uma das grandes vantagens nesse caso é que você pode especificar um driver para volume que seja persistente não apenas em seu host, mas distribuído em um cluster de volume, explicamos um pouco sobre isso aqui e aqui, em nosso exemplo vamos usar local mesmo.

Inside

Note que nas linhas que referem-se ao container PHP, não há referência para imagem, o motivo é simples, faremos o build da imagem no mesmo momento de subir a stack, ou seja, quando rodarmos o docker-compose up -d o docker realizará o build do Dockerfile que encontra-se dentro da pasta php e utilizará a imagem gerada por esse build para iniciar o container php.

Mas e o que tem nesse Dockerfile? Calma, não íamos deixar isso de lado, veja abaixo como é esse Dockerfile:

FROM php:7.0-fpm 
RUN docker-php-ext-install pdo_mysql \ 
&& docker-php-ext-install json

Em nosso lab, usaremos como base a imagem do php 7.0 em fpm, e baseado nisso instalaremos algumas extensões, para que posteriormente possamos utilizá-las. Note que não é algo muito elaborado, mas poderia, caso você tenha essa necessidade. Na imagem em questão, há um binário responsável pela instalação das extensões, que é o docker-php-ext-install, ele realiza o download e instalação da extensão e sua ativação no php.ini global.

Note também que definimos expor a porta 9000 do container php para que o container do serviço web possa acessa-lo e assim processar as requisições. O arquivo de configuração do servidor web deve ser assim:

server {

 # Set the port to listen on and the server name
 listen 80 default_server;

 # Set the document root of the project
 root /var/www/html/public;

 # Set the directory index files
 index index.php;

 # Specify the default character set
 charset utf-8;

 # Setup the default location configuration
 location / {
 try_files $uri $uri/ /index.php;
 }

 # Specify the details of favicon.ico
 location = /favicon.ico { access_log off; log_not_found off; }

 # Specify the details of robots.txt
 location = /robots.txt { access_log off; log_not_found off; }

 # Specify the logging configuration
 access_log /var/log/nginx/access.log;
 error_log /var/log/nginx/error.log;

 sendfile off;

 client_max_body_size 100m;

 # Specify what happens when PHP files are requested
 location ~ \.php$ {
 fastcgi_split_path_info ^(.+\.php)(/.+)$;
 fastcgi_pass php:9000;
 fastcgi_index index.php;
 include fastcgi_params;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 fastcgi_param APPLICATION_ENV development;
 fastcgi_intercept_errors off;
 fastcgi_buffer_size 16k;
 fastcgi_buffers 4 16k;
 }

 # Specify what happens what .ht files are requested
 location ~ /\.ht {
 deny all;
 }
}

Veja que na opção: fastcgi_pass definimos como php:9000 ou seja, o nome do container na porta que expomos no docker-compose. Lembrando que você pode ter acesso a stack completa baixando esse exemplo de nosso repositório no gitub.

Para o Container de banco de dados, utilizamos a imagem oficial do MySQL, definimos apenas os dados de acesso e nome do banco de dados que gostaríamos de criar, e claro definimos um volume onde serão persistidos os dados desse banco.

Agora finalmente basta você subir a sua stack, para isso:

docker-compose up -d

Depois do docker compose realizar todo o processo de build da sua stack, basta você acessar o ambiente web pelo endereço: http://localhost:8080 e você terá como retorno a pagina inicial do seu site (que em nosso teste é apenas um phpinfo).

Próximos passos

 Bom, agora você só precisar criar :), quando você ficar alguma modificação na pasta onde está o projeto, elas serão refletidas no site, ou seja, modificando o seu index.php será alterado no site que está rodando nos container, isso porque mapeamos a pasta local como sendo a public do servidor web/php. O mais interessante dessa abordagem é poder movimentar esse ambiente para onde quiser, imagem que isso tudo faz parte de seu código versionado no git, basta chegar em basta e rodar um git clone do seu projeto (ou pull) e você terá o mesmo ambiente de desenvolvimento.

Gostou? Não gostou? Tem dúvida? Deixa nos comentários que vamos conversando! E como sempre, nos ajude divulgando o blog.

Grande abraço!



Gomex: Escrevendo um livro digital como entrega contínua parte 1

3 de Novembro de 2016, 1:26, por DevOps Brasil - 0sem comentários ainda

Objetivo

A ideia dessa série de artigos é compartilhar a minha experiência de escrever um livro digital sem esforço sobre-humano, ou seja, você não se sentirá necessariamente pressionado a depender de um resultado financeiro do seu livro, pois a ideia é que ele não impacte muito nas suas horas livres.

download-2

No meu caso a falta de tempo foi fruto de uma má distribuição e priorização das minhas atividades, e depois que organizei previamente minhas tarefas diárias e assim eu consegui realizar mais atividades no fim do dia. Eu não vou aprofundar nesse assunto, pois já existem diversas técnicas de como fazer isso disponível na internet.

Um outro assunto que pretendo falar é sobre a entrega contínua do material, pois eu entregava um livro atualizado a cada artigo produzido e assim ter um rápido retorno de críticas sobre o produto.

Com esse rápido retorno é possível inclusive você mudar a estrutura do conteúdo apresentado. Exemplo: Caso seu público já domine o conteúdo que você está construindo, você pode aumentar o nível nos próximos artigos.

Escolhendo o tema do livro

Antes de escrever, eu precisei decidir qual assunto seria tratado no livro. Não apenas superficialmente falando (Ex. Docker, NodeJS e afins), pois é necessário saber para qual foco será esse material.

Utilizando o exemplo do Docker, podem ser criados diversos livros, cada um com um foco distinto. No meu caso eu fiz um focado para o desenvolvedor, ou seja, a minha ideia era explicar o mínimo necessário para ele entender o que estava utilizando e então explicar como uma aplicação simples escrita em python deveria ser modificada para ser “Dockerizada”.

Escolher o foco é importante, inclusive para você saber se seu livro é relevante ou não, pois nada é mais frustrante do que dedicar tempo para algo e depois descobrir que já tem um produto igualzinho pronto. Não quero com isso desestimular que você escreva livros iniciantes, caso já existam vários para esse público.

Não menospreze conteúdo básico

A maioria das pessoas normalmente está sempre começando a aprender algo novo, sendo assim dedique um tempo para trabalhar em um conteúdo bem estruturado para transmitir de forma didática, simples, direta e com exemplos práticos o que você sabe.

A maioria do conteúdo que tenho lido pela internet são ótimos materiais de referência e consulta, mas normalmente não são bons para quem tá começando “do zero”. Se você realmente está interessado em compartilhar o que você sabe, para alguém que não realmente não sabe nada do assunto, dedique um pouco de tempo para organizar um conteúdo que apresente gradualmente novos conceitos e ideias, sempre contextualizando termos e paradigmas novos. Evite achar que o leitor tem conhecimento intermediário em alguma parte do seu conteúdo técnico.

Organize seu conteúdo em um índice

Antes de começar a escrever qualquer artigo eu fiz um índice e me preparei psicologicamente para mudá-lo no futuro, caso necessário. E ele mudou bastante.

Ordenei os assuntos pensando no meu público alvo, ou seja, apresentei cada conteúdo e termo novo de forma gradual. Isso quer dizer que você deve pensar as dependências entre os capítulos. Exemplo: Caso seu público seja iniciante, e você precise falar de comunicação entre contêineres, é importante falar sobre redes no docker e afins.

Nos próximos artigos dessa série falarei mais sobre a estruturação de conteúdo e algumas dicas de como usar bem seu tempo para produzir de forma constante e não perder o ritmo.