Docker 1.3

23 de Outubro de 2014, 15:02, por Software Livre Brasil - sem comentários ainda

<img src="http://www.fernandoike.com/images/solomon-keynote-penguin-authentication-300x235.png" /> A <a href="https://blog.docker.com/2014/10/docker-1-3-signed-images-process-injection-security-options-mac-shared-directories/">versão 1.3</a> do <a href="http://www.docker.com">Docker</a> foi lançada recentemente. Eu gostei dela por duas razões. <h2>Verificação da assinatura digital</h2> O pessoal da DotCloud já tinha <a href="https://blog.docker.com/2014/09/docker-hub-official-repos-announcing-language-stacks/">anunciado</a> alguns repositórios oficiais de alguma ferramentas e linguagens de programação (C(++)/GCC, PHP, Go, Java, Nodejs, Python, Perl, Ruby, etc.). O Docker verifica se os repositórios oficiais estão íntegros, eles (os repositórios) são assinados com chave criptográficas. (Obs. procurando que tipos de chaves são e como são assinados) Antes disso eu tinha um pouco de restrição com os repositórios de terceiros. Até então, preferia criar meus templates de containers. <h2>Entrar num container em execução</h2> Nas versões anteriores era um pouco trabalhoso para você entrar num container e analisar um problema que estivesse ocorrendo, exemplo: identificar um problema de permissão num diretório. Na versões anteriores teria que ser feito assim: Na criação do container deveria compartilhar os diretórios de log e da aplicação. Supondo que seja um servidor web simples, o dockerfile seria como o abaixo: Dockerfile <div><table><tr><td><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 </pre></td><td><pre><code>FROM debian:wheezy MAINTAINER fike at midstorm.org RUN apt-get udpate && apt-get install apache2 ADD mysite /var/www/ RUN apt-get autoremove -y && rm -rf /tmp/* /var/tmp/* ENV APACHE_RUN_USER www-data ENV APACHE_RUN_GROUP www-data ENV APACHE_LOG_DIR VOLUMES ["/var/log/apache2", "/var/www"] CMD ["/usr/sbin/apache2", "-D", "FOREGROUND"] </code></pre></td></tr></table></div> <h3>Criando o container</h3> <div><table><tr><td><pre>1 </pre></td><td><pre><code>fike@kamino:~$ docker build -t="mysimplesite" . </code></pre></td></tr></table></div> <h3>Executando</h3> <div><table><tr><td><pre>1 </pre></td><td><pre><code>fike@kamino:~$ sudo docker run -d -p 80:80 mysimplesite </code></pre></td></tr></table></div> <h3>Putz! Os internautas não estão conseguindo acessar meu site, ele está retornando 403.</h3> Se não tiver uma versão mais recente do util-linux (> 2.27) <a href="http://jpetazzo.github.io/2014/03/23/lxc-attach-nsinit-nsenter-docker-0-9/">não poderá usar</a> o nsenter. Outra forma seria executar um segundo container e acessar os diretórios compartilhados do primeiro. <div><table><tr><td><pre>1 2 3 </pre></td><td><pre><code>fike@kamino:~$ CONTAINERID=$(docker ps |grep mysimplesite|awk '{ print $1}' fike@kamino:~$ docker run -it --volumes-from=$CONTAINERID /bin/bash </code></pre></td></tr></table></div> Se estiver usando um <a href="http://www.fluentd.org/">Fluent</a> ou outro agregador de logs não precisaria disso, certo? Nesse caso, sim. Entretanto pode ocorrer de precisar inspecionar um container para verificar um vazamento de memória ou algo que necessite analisar a aplicação em produção. Se o problema estiver relacionado a rede, a abordagem era parecida. Um bom exemplo, alterar uma zona DNS no Bind9 usando o rndc. <div><table><tr><td><pre>1 2 3 </pre></td><td><pre><code>fike@kamino:~$ CONTAINERID=$(docker ps |grep mysimplesite|awk '{ print $1}' fike@kamino:~$ docker run -it --volumes--from=$CONTAINERID --net='container:$CONTAINERID' mysimplesite /bin/bash </code></pre></td></tr></table></div> No 1.3 é bem mais simples. <div><table><tr><td><pre>1 2 3 </pre></td><td><pre><code>fike@kamino:~$ CONTAINERID=$(docker ps |grep mysimplesite|awk '{ print $1}' fike@kamino:~$ docker exec -it $CONTAINERID /bin/bash </code></pre></td></tr></table></div>

Docker 1.3

23 de Outubro de 2014, 15:02, por Software Livre Brasil - sem comentários ainda

<img src="http://www.fernandoike.com/images/solomon-keynote-penguin-authentication-300x235.png" /> A <a href="https://blog.docker.com/2014/10/docker-1-3-signed-images-process-injection-security-options-mac-shared-directories/">versão 1.3</a> do <a href="http://www.docker.com">Docker</a> foi lançada recentemente. Eu gostei dela por duas razões. <h2>Verificação da assinatura digital</h2> O pessoal da DotCloud já tinha <a href="https://blog.docker.com/2014/09/docker-hub-official-repos-announcing-language-stacks/">anunciado</a> alguns repositórios oficiais de alguma ferramentas e linguagens de programação (C(++)/GCC, PHP, Go, Java, Nodejs, Python, Perl, Ruby, etc.). O Docker verifica se os repositórios oficiais estão íntegros, eles (os repositórios) são assinados com chave criptográficas. (Obs. procurando que tipos de chaves são e como são assinados) Antes disso eu tinha um pouco de restrição com os repositórios de terceiros. Até então, preferia criar meus templates de containers. <h2>Entrar num container em execução</h2> Nas versões anteriores era um pouco trabalhoso para você entrar num container e analisar um problema que estivesse ocorrendo, exemplo: identificar um problema de permissão num diretório. Na versões anteriores teria que ser feito assim: Na criação do container deveria compartilhar os diretórios de log e da aplicação. Supondo que seja um servidor web simples, o dockerfile seria como o abaixo: Dockerfile <div><table><tr><td><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 </pre></td><td><pre><code>FROM debian:wheezy MAINTAINER fike at midstorm.org RUN apt-get udpate && apt-get install apache2 ADD mysite /var/www/ RUN apt-get autoremove -y && rm -rf /tmp/* /var/tmp/* ENV APACHE_RUN_USER www-data ENV APACHE_RUN_GROUP www-data ENV APACHE_LOG_DIR VOLUMES ["/var/log/apache2", "/var/www"] CMD ["/usr/sbin/apache2", "-D", "FOREGROUND"] </code></pre></td></tr></table></div> <h3>Criando o container</h3> <div><table><tr><td><pre>1 </pre></td><td><pre><code>fike@kamino:~$ docker build -t="mysimplesite" . </code></pre></td></tr></table></div> <h3>Executando</h3> <div><table><tr><td><pre>1 </pre></td><td><pre><code>fike@kamino:~$ sudo docker run -d -p 80:80 mysimplesite </code></pre></td></tr></table></div> <h3>Putz! Os internautas não estão conseguindo acessar meu site, ele está retornando 403.</h3> Se não tiver uma versão mais recente do util-linux (> 2.27) <a href="http://jpetazzo.github.io/2014/03/23/lxc-attach-nsinit-nsenter-docker-0-9/">não poderá usar</a> o nsenter. Outra forma seria executar um segundo container e acessar os diretórios compartilhados do primeiro. <div><table><tr><td><pre>1 2 3 </pre></td><td><pre><code>fike@kamino:~$ CONTAINERID=$(docker ps |grep mysimplesite|awk '{ print $1}' fike@kamino:~$ docker run -it --volumes-from=$CONTAINERID /bin/bash </code></pre></td></tr></table></div> Se estiver usando um <a href="http://www.fluentd.org/">Fluent</a> ou outro agregador de logs não precisaria disso, certo? Nesse caso, sim. Entretanto pode ocorrer de precisar inspecionar um container para verificar um vazamento de memória ou algo que necessite analisar a aplicação em produção. Se o problema estiver relacionado a rede, a abordagem era parecida. Um bom exemplo, alterar uma zona DNS no Bind9 usando o rndc. <div><table><tr><td><pre>1 2 3 </pre></td><td><pre><code>fike@kamino:~$ CONTAINERID=$(docker ps |grep mysimplesite|awk '{ print $1}' fike@kamino:~$ docker run -it --volumes--from=$CONTAINERID --net='container:$CONTAINERID' mysimplesite /bin/bash </code></pre></td></tr></table></div> No 1.3 é bem mais simples. <div><table><tr><td><pre>1 2 3 </pre></td><td><pre><code>fike@kamino:~$ CONTAINERID=$(docker ps |grep mysimplesite|awk '{ print $1}' fike@kamino:~$ docker exec -it $CONTAINERID /bin/bash </code></pre></td></tr></table></div>

docker 1 dot 3

23 de Outubro de 2014, 0:00, por Fike's Mnemonics - sem comentários ainda

{% img center /images/solomon-keynote-penguin-authentication-300x235.png %}

A versão 1.3 do Docker foi lançada recentemente. Eu gostei dela por duas razões.

Verificação da assinatura digital

O pessoal da DotCloud já tinha anunciado alguns repositórios oficiais de alguma ferramentas e linguagens de programação (C(++)/GCC, PHP, Go, Java, Nodejs, Python, Perl, Ruby, etc.). O Docker verifica se os repositórios oficiais estão íntegros, eles (os repositórios) são assinados com chave criptográficas. (Obs. procurando que tipos de chaves são e como são assinados)

Antes disso eu tinha um pouco de restrição com os repositórios de terceiros. Até então, preferia criar meus templates de containers.

Entrar num container em execução

Nas versões anteriores era um pouco trabalhoso para você entrar num container e analisar um problema que estivesse ocorrendo, exemplo: identificar um problema de permissão num diretório.

Na versões anteriores teria que ser feito assim:

Na criação do container deveria compartilhar os diretórios de log e da aplicação. Supondo que seja um servidor web simples, o dockerfile seria como o abaixo:

{% codeblock Dockerfile lang:bash %}

FROM debian:wheezy

MAINTAINER fike at midstorm.org

RUN apt-get udpate && apt-get install apache2

ADD mysite /var/www/

RUN apt-get autoremove -y && rm -rf /tmp/* /var/tmp/*

ENV APACHE_RUN_USER www-data

ENV APACHE_RUN_GROUP www-data

ENV APACHE_LOG_DIR

VOLUMES [“/var/log/apache2”, “/var/www”]

CMD [“/usr/sbin/apache2”, “-D”, “FOREGROUND”]

{% endcodeblock %}

Criando o container

{% codeblock lang:bash %}

fike@kamino:~$ docker build -t=“mysimplesite” .

{% endcodeblock %}

Executando

{% codeblock lang:bash %}

fike@kamino:~$ sudo docker run -d -p 80:80 mysimplesite

{% endcodeblock %}

Putz! Os internautas não estão conseguindo acessar meu site, ele está retornando 403.

Se não tiver uma versão mais recente do util-linux (> 2.27) não poderá usar o nsenter. Outra forma seria executar um segundo container e acessar os diretórios compartilhados do primeiro.

{% codeblock lang:bash %} fike@kamino:~$ CONTAINERID=$(docker ps |grep mysimplesite|awk ‘{ print $1}’

fike@kamino:~$ docker run -it –volumes-from=$CONTAINERID /bin/bash

{% endcodeblock %}

Se estiver usando um Fluent ou outro agregador de logs não precisaria disso, certo? Nesse caso, sim. Entretanto pode ocorrer de precisar inspecionar um container para verificar um vazamento de memória ou algo que necessite analisar a aplicação em produção.

Se o problema estiver relacionado a rede, a abordagem era parecida. Um bom exemplo, alterar uma zona DNS no Bind9 usando o rndc.

{% codeblock lang:bash %} fike@kamino:~$ CONTAINERID=$(docker ps |grep mysimplesite|awk ‘{ print $1}’

fike@kamino:~$ docker run -it –volumes–from=$CONTAINERID –net=‘container:$CONTAINERID’ mysimplesite /bin/bash

{% endcodeblock %}

No 1.3 é bem mais simples.

{% codeblock lang:bash %} fike@kamino:~$ CONTAINERID=$(docker ps |grep mysimplesite|awk ‘{ print $1}’

fike@kamino:~$ docker exec -it $CONTAINERID /bin/bash {% endcodeblock %}

Eu fui: TDC 2014- Edição POA

19 de Outubro de 2014, 20:40, por Software Livre Brasil - sem comentários ainda

Participar de eventos é sempre uma boa oportunidade de aprender coisas novas, aumentar o networking e repassar conhecimento ou algumas lições aprendidas. :)

Acredito que o pessoal da organização do TDCtdc gostou da minha apresentação na edição de São Paulo (Você está preparado para um milhão de usuários?) porque eles aprovaram as três proposta que inscrevi.

Gostei bastante desta edição de Porto Alegre porque vi algumas coisas novas bem interessantes. As que destacam: (para mim)

Visual Thinking (Diogo Lucas e Guilherme Lacerda)

No meu trabalho atual, costumo usar um quadro branco ou papel em detrimento à apresentações em Power Point/LibreOffice Impress para discutir com os clientes produtos e serviços, como também, definição de arquitetura.

Não sabia que isso era chamado de Visual Thinking, eu costumava chamar de “Quer que eu desenhe?” Aliás, alguns meses atrás comecei esboçar uma apresentação falando disso, vou aumentar a prioridade dela no meu TODO.

Análise de sentimento durante a Copa usando Big Data (Alan Braz) A IBM chama isso de FAMA mas me pareceu coisa do Watson. Gostei muito e fiquei ainda mais com a sensação do Big Brother (1984, George Orwell)
Software Delivery like a Boss (Guilherme Elias e Fabrízio Mello)

Nunca iria imaginar que uma apresentação sobre Software Delivery poderia ter encenação teatral, foi animal!

Carregue seus ambientes no bolso com Vagrant e Docker (Diogo Lucas)

Foi muito interessante porque o Diogo usou o mesmo termo que eu para definir o Docker: “Disruptivo”. Bom, falei sobre ele na apresentação: “Docker na vida real”

As outras apresentações foram sobre Web Performance – “Será que seu site está preparado para um milhão de usuários simultâneos?” e “Managenment 3.0 – a vida pós-agilidade”

Software livre Brasil

Posts do blog

2 amigos

1 comunidades

Docker 1.3

Docker 1.3

docker 1 dot 3

Verificação da assinatura digital

Entrar num container em execução

Criando o container

Executando

Putz! Os internautas não estão conseguindo acessar meu site, ele está retornando 403.

Eu fui: TDC 2014- Edição POA

Será que seu site está preparado para um milhão de usuários simultâneos?

Docker na vida real

Managenment 3.0 – a vida pós-agilidade

Conheça

Colabore

Compartilhe

Apoio

Entrar

Software livre Brasil

Posts do blog

2 amigos

1 comunidades

Blog

Docker 1.3

Docker 1.3

docker 1 dot 3

Verificação da assinatura digital

Entrar num container em execução

Criando o container

Executando

Putz! Os internautas não estão conseguindo acessar meu site, ele está retornando 403.

Eu fui: TDC 2014- Edição POA

Será que seu site está preparado para um milhão de usuários simultâneos?

Docker na vida real

Managenment 3.0 – a vida pós-agilidade

Conheça

Colabore

Compartilhe

Apoio