Mapeando uma partição do Google Drive no Linux

Padrão

Boa noite pessoal,

Faz um tempo que não posto nada no blog, pois deixei um pouco de lado para me concentrar em alguns dos meus estudos. Mas decidi compartilhar este post com vocês pois é rápido e muito util.

É muito comum encontrar uns clients do google drive para sincronizar os arquivos que estão na nuvem. No meu ponto de vista isso não é tão interessante. Assim como os clients do Google Drive para linux deixam muito a desejar.

E se fosse possível adicionar o disco(“Partição”) do google drive em seu linux, como se fosse uma partição local?

Venho lhe informar que é possível!

Estive pesquisando sobre FUSE e encontrei algumas ferramentas que utilizam o recurso de filesystem in userspace, dentre elas tinham algumas como GlusterFS, VollatileFS, MooseFS e o que vou falar aqui:

google-drive-ocamlfuse

Este é o projeto do software no github https://github.com/astrada/google-drive-ocamlfuse, ele é desenvolvido na linguagem ocaml.

Lá tem todas as informações necessárias de como instala-lo, configura-lo e utiliza-lo.

Por este motivo irei apenas demostrar uma pequena introdução. Usarei como base o operacional Archlinux.

Primeiro você tem que fazer download do software e instalar:

Debian

sudo add-apt-repository ppa:alessandro-strada/ppa
sudo apt-get update
sudo apt-get install google-drive-ocamlfuse

Archlinux

yaourt -S google-drive-ocamlfuse –noconfirm

após o fim da instalação é necessário autenticar a sua conta do google drive:

google-drive-ocamlfuse

Será aberta uma pagina web para permitir a aplicação a autenticar no google drive. É só permitir a sua conta, e aguardar a seguinte mensagem na console:

Access token retrieved correctly.

Por fim, basta fazer o seguinte procedimento para mapear o google drive em um mountpoint.

E pronto! Google Drive está mapeado no seu sistema operacional, sem ficar consumindo sua rede com sincronização, inclusive mantem algumas informações em cache para melhorar a qualidade da performance e diminuir o uso da rede.

Para desmontar basta utilizar a ferramenta fusermount:

Exemplo: fusermount -u /GDMOUNT/DANIELDRIVE

E é isso aí, espero que isso seja de muita utilidade para vocês.

Até outro post!

camelodoido

CoreOS – Servidor para Contêiners

Padrão

Boa noite a todos!!!

Venho aqui falar sobre um sistema operacional muito bom para hospedar os seus containers. O nome dele é:

Não pretendo ir muito a fundo, pois tenho que acordar cedo amanhã.. mas quero deixar um pouco da minha experiencia com ele para vocês.

Primeiramente, este sistema é baseado em linux, especificamente no Gentoo.

Ele possui diversos recursos como:

ETCD – É um recurso para administração de configurações de um Cluster. Ele permite que eu mantenha minhas configurações distribuídas a fim de não necessitar mais de uma ferramenta de gerenciamento em cada nó.

FLEET – Este trabalha para proporcionar disponibilidade e manter um ambiente composto por vários contêineres independente de onde os mesmos estão sendo executados.

RKT – É uma ferramenta cli para execução de contêineres, que tem compatibilidade para executar comandos do docker, porém tem sua própria engine. Ainda está em desenvolvimento e não é recomendado o uso em produção. Atualmente o CoreOS oferece suporte a docker.

FLANNEL – Possibilita a criação de uma Sub-rede para cada host, facilitando o gerenciamento de cada contêiner.

A instalação do coreos é baseado no cloud-init, que é uma ferramenta escrita em python que permite que o sistema operacional seja configurado no momento em que é iniciado. Através de meta-dados em um arquivo de extenção YAML é possível definir os serviços e suas configurações, chaves SSH autorizadas, usuários, hostname e etc.. Durante a inicialização será analisado os metadados novamente e se algo estiver em desacordo é sobrescrito.

Isso permite maior segurança, pois o sistema volta ao seu estado inicial depois de toda reinicialização.

Para iniciar sua configuração é necessário lembrar:

Arquivos YAML são extremamente chatos quanto seu professor na questão de indentação.

Inicialmente você deve gerar uma chave SSH para acesso remoto SSH:

ssh-keygen -t rsa -b 4096 -C “your_email@example.com

Você pode gerar no diretório padrão.

Basta guardar o conteudo da chave pub por enquanto, que vai ser algo como:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC/0MjZn+2OQjo/b9UYXK1ZiQJ98VBglgVhs1QfDf9FJ5uUIRTzWH4REQmB3pt8WKpHv8XqdM5tMEHFjzO9r7UX34J3wAF+hGdPhH+6Yo6DGDNe8op+LiwpRS91eZPdHlWk0aL3nB8KUO9tqXfkX/75yDujBjUa4Zj4xHgOYiQIXlJwaRA3PUvoYtG6Uf2DeBnM7AWZ93WrZg/5UWcf2FKKInZejTuSa8DP2ZTZIpYl1/gw2mMnQzFwjUO9ZSWubGdX4wt3J3EF/VtHPK0q3lGI8v+8rxe/RPj1/wDiZWIANuqYYHX1TIHFFTHmgnJRBD5hLO055dhI9eB2K4bBIf5nn4cwba1FMyn89df1MfIooA+xxShCzuWuRVCGtPeAubEZoGIDwYB8M3EWbJXdWaYbrzvAJmlqjnHZ1N0YEWYVCJtv6wmbzZMNJ4PwYb2Cvm2M6gp1mlmQ+99cv84whjC4iUxLBqTD3t2MvwNpE5+bCyJWNjoD8bkZD6jLCjX2LinVbk1mE9qw/XJ7162SCwtF4rjzjhfEi0Apq7hiBdDPKToSs+kU2JgMIDPvN2TA9XFV/XVFuucrnDWFUzV1ci5OEkCVo9ZHfJ3k3wz4CbsWIQAiePFg3DrV6zePW4FIbKCr3PQ59Ayh6EX9epivCCYA30cY4G5Moo1ZncGFQsDpxw== your_email@example.com

 

Feito isso também você deve gerar um password para os usuário através da ferramenta openssl:

openssl passwd -1

que irá gerar o conteudo parecido como este:

$1$MSUSQ7Tl$h9Z3pCtzOLPQWACudWVP50

Feito isso vamos criar nosso meta-dados das configurações do CoreOS

crie um arquivo chamado cloud-config.yaml. Dentro dele coloque as seguintes configurações:

Neste script iniciamos as seguintes configurações:

  • Hostname do servidor: coreos1
  • Adicionamos senha para o usuário root e coreos.
  • Adicionamos uma chave SSH publica na autorização do acesso ao usuário root e coreos via ssh.
  • Adicionamos o usuário coreos ao sudo e ao docker.
  • Configuramos o serviço ETCD2
    • Em discovery configuramos a seguinte URL: https://discovery.etcd.io/57324e839ea521eca1cd905cfa33614f
      Esta serve para o ETCD gerenciar o nosso cluster.
      Para gerar a url para seu cluster basta abrir no navegador a seguinte URL: https://discovery.etcd.io/news?size=3
      Neste caso solicitamos para uma quantidade de 3 host em cluster.
    • Também informamos o nosso endereço ip com:
      advertise-client-urls: http://$private_ipv4:2379,http://$private_ipv4:4001
      Substitua $private_ipv pelo ip do servidor.
      Este irá informar o endereço do nó para os outros nós do cluster.
    • listen-client-urls para realizar as comunicações de clients através das portas 2379 e 4001 (Portas padrões)
    • listen-peer-urls para comunicação entre os nós através das portas 2380 (Porta padrão)
  •  Units

O CoreOS faz a utilização do SystemD, um gerenciador de inicialização do linux mais atual que é muito bom, e está bastante evoluido. Nele trabalhamos com targets, services, timers, network e etc. Cada um é um arquivo que específica como cada componente ou serviço irá se comportar. Porém não vou explicar sobre o systemd neste post. Pode-se ver o exemplo da configuração de um contêiner como serviço no cloud-config.yaml.

  • Em write_files informamos um arquivo no qual deve ser escrito o contêudo informado, neste caso temos a configuração do fleet.conf. Que também deve ser substituído $private_ipv4 pelo endereço IP privado e public_ipv4 pelo ip publico.

Para conferir se irá funcionar o arquivo devemos acessar a url:

https://coreos.com/validate/

e colocar o nosso arquivo YAML lá e validar.

Feito isso agora é só baixar ISO no endereço: https://coreos.com/os/docs/latest/booting-with-iso.html

Sobe uma virtual box da vida aí, seleciona a ISO e inicializa.

Ela terá que fazer ou o login automático ou terá de conectar com o usuário coreos sem senha.

Digite o comando:

coreos-install -d /dev/sda -C stable -c cloud-config.yaml

-d Dispositivo, seu HD

-C para escolhe se você quer o sistema estável ou não

-c para carregar as configurações do nosso cloud-config.yaml

Recomendo colocar o arquivo no bitbucket.org e baixar ele no coreos através da ferramenta git que já vem com ele.

obs: Outra coisa interessante é que ele já vem com Rsync também.

Depois é só esperar a instalação e pronto.

Para alterar o meta-dados você pode utilizar o coreos-cloudinit -from-file cloud-config.yaml

Caso não resolva após a reinicialização, se não ocorrer nenhum erro grave no cloudinit você pode substituir o arquivo de meta-dados em /var/lib/user_data.

Agora você poderá também subir uma nova instancia de coreos em outra máquina virtual, e acertar as configurações do fleet e do etcd e ipv4 para se comunicar.

Vou mostrar em outro post como funciona essa comunicação em cluster.

Bem espero que tenham gostado do post, pois fiz com um pouco de pressa.

Fique livre para contribuir e comentar.

Abraço!!

cAdvisor – Monitoramento em Tempo Real de Contêiner

Padrão

cadvisor

Boa noite, pessoal!

Gostaria de falar de uma ferramenta muito útil na análise de utilização de recursos do sistema de um contêiner. Como todos nós já estamos carecas de saber. O contêiner isola um sistema de outro. Assim podemos ter um maior controle dos recursos utilizados, processos executados, e utilizar um sistema independente de plataforma, já que a mesma já vem configurada em um contêiner com a distribuição linux de escolha.

De nada adianta isolar um sistema sem que possamos analisa-lo. Para isso podemos utilizar um comando do docker:

docker stats containerName

E assim podemos ter os status:

Porém existe uma ferramenta que a google desenvolveu chamada cAdvisor ou Container Advisor que traz informações em gráficos e permite ter uma visão melhor da utilização de recursos.

Sua utilização é bem simples, basta seguir estes comandos:

sudo docker run \
  --volume=/:/rootfs:ro \
  --volume=/var/run:/var/run:rw \
  --volume=/sys:/sys:ro \
  --volume=/var/lib/docker/:/var/lib/docker:ro \
  --publish=8080:8080 \
  --detach=true \
  --name=cadvisor \
  google/cadvisor:latest

É feito download da imagem, executada, e depois é só acessar o navegador na porta 8080 do seu servidor. Você conseguirá analisar todos os contêiner executando no servidor.

É simples de utilizar e ajuda um monte. Minhas experiencias foram positivas. Além de tudo a ferramente é gratuita e open-source!

Espero que gostem! Até a próxima 😀

Algumas técnicas com Contêiner – Docker

Padrão

Boa noite a todos!

Hoje decidi falar um pouco de algumas técnicas e formas mais corretas na utilização de contêineres com Docker.

Vejo algumas pessoas que se preocupam com a perda de dados de um contêiner. Eu mesmo tenho medo de que em algum momento o sistema dê um problema e quando eu der um docker start XXXXX, o sistema dê erro e não inicie o contêiner.

A reclamação seria esta:
Não posso usar um docker exec XXXXXX /bin/bash, pois o contêiner não vai estar em execução.
Docker run vai criar um novo contêiner…
E etc..

Exportando o conteúdo para um diretório

Uma solução que achei interessante e que salva a vida em um problema desses é exportar o conteúdo de um contêiner para um arquivo .tar e descompacta-lo.

 

Volume From Data Containers

Esta é uma outra técnica utilizada para criar um contêiner de armazenamento de dados. Vamos dizer que você tenha um contêiner com oracle-xe que necessita criar os datafiles. Porém a instalação do oracle por sí só está a utilizar 2GB, e o contêiner tem limitação de 10GB. E você quer utilizar 10GB de datafile.

A comunidade utiliza de imagens super pequenas para criar seus contêineres de dados como a:

busybox(5mb) e a alpine(20mb).

Neste caso use a busybox que é a menor, crie um dockerfile com um volume do diretório dos datafiles:

FROM busybox

RUN mkdir datafiles

VOLUME[“/datafiles”]

docker build -t datafiles diretórioDockerFile

Depois:

docker run –name=datafiles datafiles

docker run –volumes-from datafiles oracle-xe

E criar os datafiles no diretório /datafiles.

Estruturação de projetos dockerfile

Uma outra técnica utilizada é a criação de um diretório que contêm vários subdiretórios com dockerfiles.

Exemplo:

/home/usuario/docker-projetos

/home/usuario/docker-projetos/sistema-web

/home/usuario/docker-projetos/sistema-web2

/home/usuario/docker-projetos/aplicacao

em /home/usuario/docker-projetos/ você cria um arquivo chamado por exemplo de makefile.

Nele o conteúdo será um script de build para construir todas as suas imagens:

docker build -t web sistema-web

docker build -t web2 sistema-web2

docker build -t app aplicacao

Assim ele irá construir todos os dockerfiles dos meus projetos conforme o meu script.

Dockerception

https://github.com/jamiemccrindle/dockerception

O Dockerception é uma técnica utilizada para geração de contêineres run-time que são construídos através de um builder-container. Permitindo imagens menores possíveis.

Um exemplo prático pode ser visto neste projeto:

https://github.com/so0k/mount.cifs_copy

Ele permite que eu instale a ferramenta mount.cifs em qualquer outro sistema linux. Eu fiz uso no CoreOS que não tem gerenciador de pacotes, a ideia é apenas utilizar contêineres.

 

DISPLAY Variável, Xrandr, Xvfb

Padrão

Faz um mês que não publico devido a estar muito ocupado trabalhando em cima de outros estudos. Decidi fazer esse post relacionado a variável de ambiente DISPLAY do linux utilizada para executar aplicações gráficas no linux, pois já tive contato com ela varias vezes e tive de solucionar problemas desse tipo algumas vezes.

A variável de ambiente DISPLAY está presente em qualquer linux que faz o uso do servidor X Windows System aka X11 aka Xorg. Mas para que ela serve?

Essa variável serve para informar o servidor X11 onde ele irá exibir a aplicação gráfica que deseja executar em um terminal.

Se você está utilizando uma área gráfica, e neste mesmo momento abrir um terminal e executar:

echo $DISPLAY

Será retornado o DISPLAY que você está utilizando.

Uma outra forma que encontrei para identificar o valor do display é através desse script:

$ ps u | awk -v tty=$(cat /sys/class/tty/tty0/active) ‘$0 ~ tty { print $2 }’ | while read pid && [[ “$display” == “” ]]; do display=”$(awk -v RS=’\0′ -F= ‘$1==”DISPLAY” { print $2 }’ /proc/$pid/environ)”; if [ “$display” != “” ]; then echo “$display”; fi; done 2>/dev/null
http://www.hackingbits.com/2015/05/how-do-i-find-out-current-in-use.html

Essa variável é composta dos seguintes valores:

host:Display.Screen

host -> Um endereço IP ou HOSTNAME da máquina ao qual está sendo executado um servidor X11.

Display -> É um numero que define qual é o monitor/sessão do X ao qual o usuário está conectado.

Nesse caso se eu tiver feito login no meu gerenciador de display como um GDM, XDM ou outro, por default deverá ser atribuído o valor :0, caso eu vá até o meu gerenciador de display novamente e conecte com um outro usuário ou com o mesmo se possível, o valor para aquela sessão deve ser :1 e assim segue..

É desta mesma forma que o VNC Server trabalha quando você configura uma sessão para determinado usuário, e para conexão remota ele libera com base na porta 5900 + Display. (Claro que tem uma tecnologia por traz e recursos a mais.)

Screen -> O screen representa a tela na qual aquela sessão está ativa, hoje em dia é sempre zero, O que justifica o porque é zero, é essa pergunta:

se eu ter dois monitores, vou utilizar dois screen? Exemplo: localhost:0.0 e localhost:0.1

Para responder a essa pergunta eu tive de fazer alguns testes para ter certeza, e o que ocorre é o seguinte:

Tenho duas saídas de Video:

  • Uma saída LVDS (Conecta o monitor do meu notebook ao circuito da placa mãe)
  • E uma saída VGA (Conecta o monitor ao meu notebook)

Através do Xrandr mais a extensão libXinerama, eu consigo replicar ou Extender a imagem do LVDS para a VGA. E não trabalhar com duas sessões, uma em cada tela. (Se alguém conseguir, comenta aí no blog que eu quero saber como faz).

Exemplo:

xrandr –output VGA1 –auto –right-of LVDS1

 

O Xrandr identifica o screen como se fosse apenas 1 só. E como é um índice sequencial, ele inicia em 0. Por isso você sempre irá ver que ou é :0.0 ou :1.0 ou :10.0 tem casos que ele nem mostra mais o screen na variável.

Mas ainda não cheguei onde quero chegar, geralmente tento ser bastante profundo nos meus posts, pois acredito que pode salvar a vida de alguém por aí. Como o próprio slogan fala: “Um salto a frente de onde tudo se perde”.

Então chegamos ao problema real,

De início vou explicar porque eu achei muito importante abordar esse post, e de onde surgiu o interesse em estudar o X Window System. Atualmente nos meus estudos pessoais estou focando na parte Devops que é o que está mostrando ser algo revolucionário na infra-estrutura e desenvolvimento de software. E dentro de Devops me dediquei a estudar a conteinerização e hoje estou aplicando o Docker.

Um obstaculo que havia até então era executar aplicações gráficas em conteiners, pois o mesmo não possui uma janelinha para execução(Óbvio).

Para isso a comunidade fez o uso de recursos como mapear o X11-unix socket da máquina local para o conteiner, habilitar o X11Forwarding no SSH, utilizar o VNC, porém exite algumas preocupações a serem levadas:

LOCAL

Mapear X11-unix socker: Me parece a melhor solução

REMOTO

Mapear a porta 6000 + Display: Não tem sido utilizado, mas é uma possibilidade. Porém não sei se é seguro e rápido. (Não se aplica tanto ao docker.)

SSH X11Forward:  Se houver uma queda de conexão de acesso remoto, A sessão SSH morre e as aplicação são finalizadas.

Aí vem a lembrança do screen, que permite que uma sessão continue ativa após a desconexão. Porém a mesma acredito que não oferece suporte ao Display que muitas vezes mesmo sem desconectar, o Display já não funciona mais e é necessário reconectar no SSH.

A solução para isso é o XPRA. Ele permite que eu reconecte utilizando o mesmo Display anterior, eu posso desconectar, cair minha conexão que assim como o screen, ele mantem a aplicação ainda ativa. Isso funciona porque essa mesma ferramenta faz o uso do Xvfb que possibilita criar um display virtual que fique ativo assim como um X11 server.

Porém o meu problema não era com as imagens do Docker, mas sim de um servidor de builds que migramos do Windows para o linux. O mesmo possui uma ferramenta de Builds.

Um dos builds de um sistema java estava dando problema após a migração devido a ser um processo automatizado executado com um usuário não havia nenhum Display ativo. Retornando um erro durante a execução.

Para possibilitar o entendimento do porque do erro, tem um caso semelhante com um servidor de poker online que o mesmo necessita de um sessão a um servidor X, pois o java.awt utilizado no server necessita de um Display para execução, segue o erro:

Exception in thread “main” java.lang.InternalError: Can’t connect to X11 window server using ‘:0.0’ as the value of the DISPLAY variable.  http://pokerapp.sourceforge.net/xvfb.html

E acredito que a solução será utilizar o Xvfb, na segunda-feira que vem vou poder  testar para confirmar que funcionou. Porém fiz um teste antes:

A sintaxe é simples:

Xvfb :10 -screen 0 800x600x24&
DISPLAY=:10.0 java -jar exemplo.jar
ou
export DISPLAY=:10.0″ e aí então executar a aplicação

O Xvfb permite eu executar uma aplicação sem que exista uma interface gráfica no meu servidor.

Em relação ao build encontrei também um Plugin para o Jenkins que scredito solucionar o problema que está ocorrendo:

https://wiki.jenkins-ci.org/display/JENKINS/Xvfb+Plugin

Bem, espero tenha ajudado, o que eu queria disseminar é isso!

Ideia – Parque de Ciências Tecnológicas de Jaraguá do Sul

Padrão

Como seria o Parque?

O parque seria um local para o aprendizado tecnológico, contando com palestras de membros(Essas palestras farão parte dos desafios propostos pelo parque), Hackathon, desenvolvimento de projetos, entre outras atividades.

Todo final de semana a comunidade poderia participar, o ambiente seria aconchegante com poltronas ao redor de uma mesa central para discussões. Teriam vários pontos de rede mantidos pela infraestrutura do local que será desenvolvido pelos próprios membros.

Além disso, terão alguns workshops que seriam para quem quiser aprender algo a mais, na prática, onde é possível desenvolver muita coisa.

Todos os projetos que são desenvolvidos são disponibilizados para qualquer pessoa ou instituição através do repositório oficial do park.

Cada pessoa vem com seu notebook e tem uma conexão a rede para poder focar em novos conhecimentos.

Investimento(Esboço):

Hardware:

  • 1 Roteador cisco
  • 3 Switch Cisco
  • 2 Roteadores Wireless
  • Pontos, cabos de rede e tomadas
  • Componentes para desenvolvimento de tecnologias sejam eles robôs, computadores e etc.

 

Ambiente:

  • 4 Poltronas/Sofás aconchegantes
  • 2 mesas redondas aconchegantes
  • 1 refrigerador
  • 1 estante para comida
  • 2 mesinhas pequenas
  • 6 Cadeiras
  • 1 forninho elétrico
  • 1 fogão elétrico
  • 1 churrasqueira
  • 4 Puff
  • 1 Xbox ou Playstation
  • 1 TV grande
  • 1 Projetor
  • som para o ambiente

 

Porque investir nessa ideia?

O investimento dessa ideia faz com que nossa cidade evolua no conhecimento, muita coisa se aprende em curso e faculdade, mas muita coisa que é novidade e que é criado pela comunidade poucos percebem a importância ou benefícios que podem trazer.

O park seria um local para promover ideias, noções sobre diferentes extremos da tecnologia e quem sabe não ser um local de alimento para startups.

Promover a disseminação do conhecimento é algo muito importante.

Isso é algo que nenhum lugar possui, um ambiente para todos que buscam tecnologia crescer junto.

 

Como seria uma visita ao Parque?

No parque todos seriam recebidos muito bem, lembrando que depende do tamanho do ambiente para definir o numero de pessoas. Os eventos iniciarão após as 18h todo sábado, e prosseguirão até as 22h.

O parque possuirá um grupo de cada área, em cada grupo serão abordados vários temas relacionados a área.

Então terá o grupo de Devops, Eletrônica, Base de dados, Redes, Desenvolvimento de software.

 

Como funcionará cada grupo? Exemplos.

Cada grupo terá um tema em cada final de semana, o mesmo poderá se estender a outros finais de semana. As pessoas poderão se inscrever pelo site, e poderá ser considerado um custo de inscrição para manter o ambiente em ordem.

Vamos dizer que vai começar no sábado, então sábado dia X terá uma lista no site da seguinte forma:

Devops:

Tipo evento: Palestra

Docker – Criação de ambientes de desenvolvimento

 

Eletrônica:

Tipo evento: Projeto

Arduino – Desenvolvimento de placa mãe de automação residencial

 

Database:

Tipo Evento: Palestra

NoSQL e BigData – O que é? O que faz? O que come?

 

Redes:

Tipo Evento: Pesquisa

Protocolos de Roteamento – Estudo das melhores formas de se aplicar o roteamento em rede de diferentes escopos.

 

Desenvolvimento de software:

Tipo Evento: Rackathon

RubyOnRails – Desenvolvimento de um sistema de controle de tarefas.

 

Concluindo essa ideia que me veio a mente, seria necessário grande comprometimento das pessoas envolvidas. Poderia fazer parte da comunidade, professores de faculdade, alunos, profissionais interessados e etc.

Esse não é meu plano nem um sonho, apenas uma ideia para se um dia alguém se interessar, poder aplicar. Eu teria bastante vontade de participar!

Valeu 😀

Docker Firefox+SSH – Criando um dockerfile para execução de aplicações GUI

Padrão

O docker em sí foi feito para hospedar um serviço. Porém foi visto que o docker pode fazer muito mais coisa. Uma delas é a execução de aplicações gráficas remotamente. Isso é possível através do Xorg e do ssh, em qualquer ambiente linux.

De ínicio para entender o que estou explicando vou abordar mais prático.

Esse é o dockerfile que criei para executar o firefox.

FROM centos:6
MAINTAINER Daniel Silva <dap1995@gmail.com>

RUN yum update -y
RUN yum -y install openssh-server xorg-x11-xauth firefox
RUN chkconfig sshd on
RUN service sshd start
RUN mkdir /var/run/sshd
RUN echo ‘root:admin’ | chpasswd
RUN sed -i ‘s/#PermitRootLogin without-password/PermitRootLogin yes/’ /etc/ssh/sshd_config
RUN sed ‘s@sessions*requireds*pam_loginuid.so@session optional pam_loginuid.so@g’ -i /etc/pam.d/sshd
ENV NOTVISIBLE “in users profile”
RUN echo “export VISIBLE=now” >> /etc/profile

EXPOSE 22
EXPOSE 80

CMD [“/usr/sbin/sshd”, “-D”]

Este dockerfile instala o openssh e configura para permitir o acesso remoto com usuário root e senha admin. Porém ele também instala o xorg-x11-xauth para ser possível compartilhar o display através do socket de comunicação de internet. E também instala o firefox para nosso teste.

Basta agora fazer o build do dockerfile:

docker build -t dap1995/centos-firefox-ssh .

Feito o build é só rodar o contêiner:

docker run –name ssh_teste -d -p 12222:22 dap1995/centos-firefox-ssh

através do ssh podemos executar o firefox em nosso ambiente gráfico:

{15-06-15 12:28}archdap[dap]~ % ssh -X root@localhost -p 12222
The authenticity of host ‘[localhost]:12222 ([::1]:12222)’ can’t be established.
RSA key fingerprint is SHA256:i/OWWxwTyoJWrU8lrBhqjjNeqR+vuk3zoI0gHe65ZnY.
Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added ‘[localhost]:12222’ (RSA) to the list of known hosts.

root@localhost’s password:
/usr/bin/xauth: creating new authority file /root/.Xauthority

[root@75b9fe3038ba ~]# firefox
Xlib: extension “RANDR” missing on display “localhost:10.0”.
console.error:
[CustomizableUI]
Custom widget with id loop-button does not return a valid node
console.error:
[CustomizableUI]
Custom widget with id loop-button does not return a valid node

Está funcionando corretamente, mas como queremos deixar o negócio mais simplificado para a inicialização do firefox, iremos complicar um pouco mais o nosso dockerfile:

 

FROM centos:6
MAINTAINER Daniel Silva <dap1995@gmail.com>

RUN yum update -y
RUN yum -y install openssh-server xorg-x11-xauth firefox
RUN yum -y install sudo
RUN chkconfig sshd on
RUN service sshd start
RUN mkdir /var/run/sshd
RUN echo ‘root:admin’ | chpasswd
RUN sed -i ‘s/#PermitRootLogin without-password/PermitRootLogin yes/’ /etc/ssh/sshd_config
RUN sed ‘s@sessions*requireds*pam_loginuid.so@session optional pam_loginuid.so@g’ -i /etc/pam.d/sshd
ENV NOTVISIBLE “in users profile”
RUN echo “export VISIBLE=now” >> /etc/profile

RUN export uid=1000 gid=1000 &&
mkdir -p /home/developer &&
echo “developer:x:${uid}:${gid}:Developer,,,:/home/developer:/bin/bash” >> /etc/passwd &&
echo “developer:x:${uid}:” >> /etc/group &&
echo “developer ALL=(ALL) NOPASSWD: ALL” > /etc/sudoers &&
chmod 0440 /etc/sudoers &&
chown ${uid}:${gid} -R /home/developer

USER developer
ENV HOME /home/developer
ADD init.sh /home/developer/init.sh
EXPOSE 22
EXPOSE 80
CMD [“/home/developer/init.sh”]

Neste caso foram adicionado:

  • yum -y install sudo

Para permitir que o usuário developer possa executar o sshd dentro do script de inicialização init.sh.

  • Criado um usuário chamado developer

Neste caso o usuário developer foi criado com o mesmo UID e GID do meu usuário, para quando eu realizar o mapeamento o usuário do docker e o meu usuário possuam a mesma permissão.

  • USER e ENV HOME

Para execução como usuário developer e definir a pasta home

  • CMD [“/home/developer/init.sh”]

Iniciamos o script de inicialização para que seja possível executar o firefox na inicialização junto com o SSHD.

Segue abaixo conteúdo do script de inicialização:

 

#!/bin/bash
nohup firefox &
sudo /usr/sbin/sshd -D

Com os dois arquivos no mesmo diretório, é só realizar o build e rodar o contêiner:

docker build -t dap1995/centos-initsh .

Após o build crio o contêiner:

docker run -d
-e DISPLAY=$DISPLAY
-v /tmp/.X11-unix:/tmp/.X11-unix
-v /home/$USERNAME/Workspace:/home/developer/Workspace
-p 55522:22
dap1995/centos-initsh-ssh

Para que fosse possível executar o firefox como se fosse um programa comum de nosso ambiente, executamos o run compartilhando o diretório do socket do Xorg(/tmp/.X11-unix). Desta forma o socket do docker é substituido pelo do sistema real.

Também compartilhamos um diretório chamado Workspace no diretório HOME, pois a idéia é executar ambientes de desenvolvimento como um eclipse ou netbeans.

Se voce der um docker stop no conteiner, e depois um start ele re-executa o SSHD e abre novamente o Firefox.

Espero que tenham gostado!

Abraço 😀

Canalização | Encadeamento | Pipe == FiFo | Pipe Nomeado | Socket | IPC Socket | Docker

Padrão

Bom dia à todos,

Vou começar esse post falando sobre canalização e no final quero chegar na conclusão de como ocorre a comunicação de dois hosts em uma execução remota de uma aplicação GUI.

O que é Canalização?

A canalização em sistema operacionais é o famoso Pipe que talvez alguns já conhecem, ele permite que eu envie a saída de um programa por exemplo, e jogue para a entrada de outro.

Exemplo:

echo teste > teste.txt

Neste exemplo, a saída do comando teste é direcionada para um arquivo teste.txt.

Um outro exemplo bem comum é quando queremos pegar identificar um processo em execução que travou ou ficou executando em background. Conforme o exemplo abaixo, listei todos os processos em execução com ‘ps aux’ e através da barra vertical(PIPE) joguei a saida para o ‘grep’ que filtra as linhas que contêm a palavra firefox.

ps aux | grep firefox

dev      16226  1.7  2.5 831212 205048 pts/2   Sl+  11:07   1:19 /usr/lib64/firefox/firefox

Pronto, conseguimos listar a linha que continha as informações do firefox.

Encadeamento

Porém nem sempre queremos todas as informações, apenas uma ou outra, e muitas vezes necessitamos que um outro programa utilize desta unica informação para executar uma tarefa.

Para entender melhor o encadeamento e mostra-lo mais aplicável, utilizarei o mesmo exemplo. Nesta etapa iremos fazer com que através da saída das informações do ‘ps aux | grep firefox’ filtraremos a segunda coluna através do awk, e com xargs iremos executar um ‘kill -9’ até não existir mais nenhum processo.

ps aux | grep firefox | awk ‘{print $2}’ | xargs –no-run-if-empty kill -9

Neste exemplo matamos todos os processos que continham a palavra chave firefox. Para isso foi necessário um encadeamento que consiste em passar a saída de um programa, para outro programa, e depois a outro. Para entender melhor o encadeamento, ele é uma estrutura representativa que define a ligação entre os tuneis que consiste na transferência/canalização de uma saída para uma entrada.

Pipe == FiFo

Para que as canalizações fossem executadas de forma correta, foi necessário a utilização de um conceito chamado FiFo First in, First out. Primeiro a entrar, Primeiro a sair. Esse conceito é muito utilizado pela técnica de Stream. Como exemplo podemos utilizar a transmissão de filmes online do Netflix, PopCorn Time e youtube. O filme pode ser executado mesmo que não tenha concluído o download por inteiro.

Descritor de arquivo

Porém os programas seguem um padrão para as saídas exibidas, e ai então temos o descritor de arquivo. Em linux e unix temos aquele conceito de que tudo é um arquivo, a definição de um arquivo é recurso de armazenamento de informação.

O nome Descritor de arquivo vem do inglês File Descriptor e pode ser associado a sigla FD. Ele é um indicador abstrato.

De acordo com o Padrão POSIX, o FD é um inteiro(int) em C.

Eles são 3 descritores padrões.

0 – Entrada Padrão(stdin)

1 – Saída Padrão(stdout)

2 – Erro Padrão(stderr)

Assim é possível filtrar algumas saídas jogando-as para um outro arquivo. Um exemplo comum é na execução de um programa, que pode jogar erros na console. Porém muitas vezes pretendemos deixa-lo em background sem exibir nenhum erro na console devido a não ter necessidade.

Um exemplo que podemos utilizar é esse:

cat osdjadspoj > /dev/null ou cat osdjadspoj 1> /dev/null

Neste caso o arquivo não existe e será lançado o seguinte erro na console:

cat: osdjadspoj: Arquivo ou diretório não encontrado

Porém se eu jogar a stderr(Erro Padrão) para /dev/null:

cat osdjadspoj 2> /dev/null

Não será retornado nenhum erro.

Para confirmar você pode criar o arquivo e executar o mesmo comando.

echo lala > osdjadspoj

cat osdjadspoj 2> /dev/null

E o saída será lala, pois apenas o stderr está sendo anulado.

Buffer

Depois vem a parte de buffer, que consiste no armazenamento da saída para o processo do programa que vai recebe-lo como entrada. Neste caso se a saída fosse muito grande, seria necessário que o programa terminasse de receber a entrada, para que então pudesse preencher o buffer novamente.

Pipe Nomeado

O pipe nomeado é a criação de um arquivo de fluxo. Ele é muito simples de se implementar com uma ferramenta do linux chamada mkfifo.

Com ela podemos fazer o seguinte:

mkfifo /tmp/teste

Assim criamos um arquivo para fazer a canalização da nossa saída.

Podemos verificar que  ele possui a letra ‘p’ diferente de um arquivo que possui um ‘-‘ ou um diretório que possui um ‘d’, ou um socket que possui ‘s’, ou um link que possui ‘l’.

prw-r–r– 1 dap  users   0 Jun 13 13:39 teste

Mantenha dois terminais abertos.

Execute:

echo teste > /tmp/teste

Você vai perceber que ele mantem o fluxo aberto até que alguém receba a saída que está sendo disponibilizada no tunel. Para receber a saída podemos realizar o ‘cat’ do arquivo de fluxo.

cat /tmp/teste

Pronto, a saída é concluída. E o resultado do cat é: teste.

Pode-se entender agora que ele é o túnel. Se você der um cat antes será necessário que alguma saída entre no túnel para que seja possível concluir a entrada.

Se eu tiver dois programas esperando uma saída como entrada, os dois vão ficar esperando uma resposta, mas apenas 1 irá receber, e os 3 finalizarão a conexão no túnel.

Socket

Diferente de um Pipe Nomeado, porém parecido, são os soquetes. Um soquete nada mais é do que um um ponto final de comunicação, onde pode ocorrer a transmissão de dados.

Aí você se pergunta, qual a diferença entre um socket e um Pipe Nomeado?

A diferença é que um Pipe Nomeado funciona apenas como um stream entre dois programas, sendo o meio(literalmente) de transmissão de dados. Já o soquete, permite ser o canal de trocar dados entre host em rede e local.

O Socket ele necessita de 3 argumentos para ser instanciado:

  1. Domínio:

Define qual é a rede de comunicação. A sigla AF significa “Address Family”,

AF_UNIX: Rede de comunicação de sistema operacional UNIX-like. Utilizado para comunicação de processos, Também determina que o endereço do socket(Nome) é um caminho do sistema de arquivo. Esse nome foi alterado pelo POSIX para ‘AF_LOCAL’.

AF_INET: É a rede de comunicação de internet IP. Utilizado na comunicação entre hosts e rede. Consequentemente determina que o endereço do socket é um serviço em um host de acordo com o padrão TCP/IP.

AF_NS: Muito parecido com o AF_INET, ele utiliza do endereço do protocolo XNS(Xerox Network System). Não conheço muito bem, sei que a criação do IPX foi baseado no protocolo IDP(Internet Datagram Protocol) do XNS.

2. Tipo:

Define o tipo de comunicação que será realizada, o tipo depende do domínio:

stream socket – Suporte em AF_INET através do TCP/IP e AF_UNIX.

Esse tende a realizar a transmissão Duplex(Comunicação Simultânea) e sem limite de tamanho de mensagem.

sequenced packet sockets – Suporte em AF_NS.

Transmissão Duplex, porém com limitação no tamanho das mensagens.

datagram socket – Suporte em AF_INET.

Nesse tipo de comunicação a transmissão é feita sem que exista a garantia de que os pacotes cheguem no receptor, muito parecido com a transmissão de radio e televisão. Um pacote pode chegar duplicado, em ordem incorreta ou ainda não chegar sem que se saiba. Protocolo UDP tem suporte a este tipo.

reliable delivered message sockets – Nenhum domínio até então suporta

É o datagram socket com confirmação de que as mensagens chegam ao destino.

Raw Socket

É um tipo bruto para transmissão que permite acesso a protocolos de baixo nível de transmissão, é útil no desenvolvimento de novos protocolos de comunicação em rede.

3. Protocolos:

Esse define qual é o serviço que realiza a comunicação. Neste caso seria o HTTP, FTP, TELNET. Assim é a porta de comunicação que será utilizada para a comunicação. O pacote ou datagram irá conter os dados referente a determinado protocolo.

Um pouco sobre o domínio de internet

Protocolo TCP transmite pacotes e UDP transmite datagram.

Assim como a camada 3(Rede) do modelo OSI tem sua PDU packet a camada 2(Enlace de dados) datagram.

TCP é utilizado na comunicação de camada 3, ou seja,  entre hosts e redes. Já a UDP que atua na camada 2, realiza as comunicações apenas entre hosts, um exemplo de uma comunicação de camada 2 é o broadcast.

O IPX atua assim como o UDP transmitindo o datagram, a segurança na transmissão do IPX fica por conta de outros protocolos acima dele.

Então chegamos a uma outra conclusão!

Pipe nomeado pode fazer apenas stream atuando através de uma conexão, já um socket pode atuar com ou sem conexão.

IPC Socket

O IPC(Inter-Process Communication) é o que estávamos falando a pouco, é os socket para comunicação de processos do linux. O IPC nada mais é que um socket AF_UNIX.

Você deve estar se perguntando onde eu quero chegar com essa lorota toda de socket, certo?

Conhecimento nunca é demais, ainda mais um tema tão interessante como este, porém eu quero chegar na comunicação entre processos, mas com relação a um socket no qual é utilizado para a execução de programas com interface GUI no linux. O X.org é o cara que oferece a comunicação gráfica para o linux. Através do socket /tmp/.X11-unix/display é feita a transmissão dos dados. O mesmo pode utilizar um socket TCP/IP para conexões remotas na porta 6000.

Docker executando aplicações graficas

Aí vem o final. Executar aplicações graficas remotamente!

Para executar uma aplicação grafica no docker é bem simples. Basta instalar o server ssh em um contêiner e acessa-la com o comando:

ssh -X usuario@localhost:2222

firefox

2222(Exemplo de porta 22 redirecionada)

Assim você consegue executar o firefox remotamente muito facil!

Porém as vezes queremos simplificar para a distribuição, então criamos um dockerfile para que a aplicação seja executada durante a inicialização do contêiner. No meu caso decidi executar o firefox e o SSH Server junto, que foi possível através de um shellscript.

Como este post está muito extenso, irei colocar a parte prática da criação de um dockerfile no próximo post.

Espero que tenham gostado e entendido.

Abraço!

Quando surgiu o meu amor pela informatica?

Padrão

Boa noite a todos, fiz este post com o intuito de lembrar a todos do porque gostam de fazer o que fazem e quando surgiu essa vontade. Muitas pessoas não tem essa oportunidade que tive na vida de me encontrar com algo que gosto muito e poder produzir coisas maravilhosas que geram orgulho para nós. Isso é tipo o que acontece quando a pessoa cria o primeiro site, primeiro jogo, ou como steve jobs & Cia(Primeiro computador pessoal com área grafica e mouse[Creditos: XEROX]), Mark Zuckerberg(facebook) e Andrew Gower (DeviousMud e Runescape).

Claro, que eu não fui tão longe. Não possuia nenhum curso relacionado a programação. Apenas o caderno do meu primo de uma aula de html.

Eu li todo o caderno dele, e fiquei fissurado! Logo depois pesquisei mais na internet, e fui atrás sobre como fazer sites em HTML. Não me recordo da minha idade agora, mas eu tinha uns 12 anos eu acho e fiz essa coisa linda, meu primeiro site: http://dap1995.xpg.uol.com.br/

Pouco tempo depois eu ia na casa da minha vó, pois o computador de casa meu irmão nunca me deixava mexer. Na casa da minha vó no computador dela eu criei um site chamado: http://chicolokos.xpg.com.br que não existe mais acho que era porque eu migrei para o hd1.com.br da empresa hostdime. Devido a eu utilizar hospedagem gratuita perdi meu site. Também havia criado um site de Jogos que era o gamelokos.hd1.com.br que também não existe mais.

Tempo depois resolvi criar sites em flash, eu não tinha muito conhecimento, mas até que consegui fazer.. Fiz um bem criativo, onde o site era um ambiente totalmente diferente de um site, tinha um balcão e um joão palito, e uns atalhos que redirecionavam pra outros lugares bem feitinho até. Mas enfim.

Fiz um jogo em flash depois de muito tempo, um RPG de turnos, tinha um inventario de itens, e etc.. muito bom, mas já perdi.

Eu não queria fazer um jogo de turno porque eu acho muito chato, precisava fazer algo mais legal. Então eu fiz um que duplicava movieclip, ai eu lançava um monte de ataques. Porém a unica coisa que sobrou foi o prototipo. Botei caminhos fixo para carregar os movieclips. Consegui recuperar do netbook da minha mãe tempos atrás.

Segue o link: http://16hop.com.br/Arvores/dave.html

Esse aí eu desenhei o personagem no paint, pixel por pixel. Seguem imagens abaixo:

dave

Nevo_06 Nevo_05 Nevo_04 Nevo_03 Nevo_02 Nevo_01

NEW_DAPguerrero

water_05 water_04 water_03 water_02 water_01 fire_02 fire_01

ward   wolcortado favicon vaso ana gamelogo

Isso é uma parte do que tenho salvo que eu fiz no paint.

Durante esse tempo minha criatividade estava muito boa, essa borboleta eu fui desenhando com a opnião da Ana(Minha ex-namorada) eu achei que ficou o mais legal.

Diria que foi um joguinho artesanal.

Minha paixão se estendeu, fiz uns sites estáticos para mostrar o meu amor pela minha namoradinha nessa época, utilizando CSS, ficaram bem bons, só não postar aqui porque eram romanticos demais.

Quais rumos eu segui?

Bem eu sempre quis ser programador, mas acabei fazendo curso de redes de computadores e vez de informática, hoje pelo menos estou fazendo faculdade de sistemas de informação. Trabalho atualmente em uma empresa de software, gosto do que faço,

Qual futuro quero ter?

Meu sonho mesmo é ter minha própria empresa de software, que não vai ser um local massante para trabalhar, e sim um lugar onde todos poderão usar a criatividade e fazer coisas boas, outro detalhe é que quero ter um escritório de frente pro mar onde todos programam olhando pra praia.

O que eu ganhei nesta caminhada?

Desde que comecei a estudar, desenvolvi meu aprendizado, consigo aprender muita coisa com facilidade, tenho um conhecimento geral, desde banco de dados, java, flash, cisco, e até um pouco de devops :D.

O que eu perdi nessa caminhada?

Essa é simples! Minha namorada.

Espero que tenham gostado de ler, quis expor um pouco da minha vida pessoal, e qualquer coisa comentem..

Abraço!

Sobre a TheDevConf

Padrão

Boa tarde

Como todos sabem, nesta quarta-feira dia 13 compareci a TDC(The Developers Conference) com meu amigo Jean, o evento possui patrocínio de diversas empresas como Oracle, Microsoft(Bléh), IBM, locaweb, Google, Amazon, Intel e entre outros. O Evento ele aborda diversas áreas ligadas ao desenvolvimento de um software.

IMG_2712

Agora vamos ao que interessa!
Eventos como a TDC ajudam e muito a abrir os horizontes de nossas capacidades, visões e nos levam a ver possibilidades antes não tão claras. Participei do evento e uma coisa que senti é que mais pessoas deviam estar lá, mesmo você fazendo a trilha de DevOps, Web, Testes e etc, todos acabam levando um pouco de tecnologia, gestão, e acreditando em soluções para aquilo que as vezes é impossível de se resolver.

Você talvez se perguntou, “eu não sou desenvolvedor, porque eu iria na conferência de desenvolvedores?”, eu lhe respondo o seguinte:

A TDC não é para desenvolvedores, a conferencia é para quem está ligado ao desenvolvimento de software. Muito do que é comentado na TheDevConf pode ser absorvido na gestão de um software, o aprimoramento do conhecimento das fases de desenvolvimento de um software, é algo que não se aplica só ao engenheiro de software, ao desenvolvedor ou a parte técnica, mas sim também para a parte business, o processo de entrega de um software, uma noção sobre qualidade, novas tecnologias que poderiam ser utilizados e estar a par do que há de mais atual no meio Dev.

Entre tudo isso ainda havia uma trilha de análise de negócios que chegou a esgotar e tem se ouvido muito bem.

Como participei da trilha DevOps vou citar o que encontrei de importante.

No inicio foi abordado o tema DevOps, sobre o que é essa nova cultura, e como que um DevOps deve se ater em um ambiente de desenvolvimento.

Nessa parte pode ser visto no meu post anterior sobre o que é DevOps 

Outro tema muito interessante foi sobre ROI(Return of Investment) ligado a área de DevOps e também a parte de automação de testes. Isto é algo geralmente definido para reduzir custos com testes, diminuir as chances de erros em produção, dando uma maior garantia na liberação de versões de um sistema. Que requer um grande investimento também, porém deve-se levar sempre em conta os benefícios que testes automatizados trazem para uma empresa.

ROI de DevOps que chega mais próximo da implantação e testes automatizados. Para definir algumas métricas pode-se fazer uso dos seguintes itens:

  • Tempo de criação do ambiente de produção;
  • Redução de atrasos ao meio;
  • Rapidez de entrega de aplicações com garantia de qualidade;
  • Redução de defeitos de produção;

Outro foi muito abordado é o Docker, uma explicação de um colombiano referente ao básico do Docker e como ele utilizava em sua startup. Complementando após teve apresentação sobre o Docker Compose para execução de vários serviços ao mesmo tempo que são dependentes um do outro. Também foi explicado como realizar as configurações que são bem simples utilizando apenas um arquivo YML.

Também foi abordado a utilização de ferramentas para build, deploy e testes como o Jenkins. Teve uma apresentação bem legal onde foi utilizado um plugin workflow ao invés de jobs onde era possível realizar testes em paralelo e onde os testes seguiam um fluxo.

Além disso teve no final uma palestra sobre testes, Feature Toggles, Ansible, e o resto não achei tão interessante como TFS(Team Fundation Server) e um sobre Kitchenplan e boxen.

Teve uma apresentação perto do final com o tema “Piratas do DevOps: Navegando em Águas Misteriosas” que tratou bastante sobre como ser um Pirata(Um cara que se arrisca e vai atrás de suas ideologias) e a dificuldade que ele as vezes enfrenta. Muito boa!

No final contamos com uma apresentação de um cara da Taller que trouxe muita informação relacionada ao DevOps e ferramentas que podem ser utilizadas entre outras coisas muito úteis. (Não falaram sobre Drupal)

Esse foi um pouquinho do que aprendi lá.

Para encerrar uma foto da minha presença e do meu amigo Jean na TheDevConf 2015.

devconf

Até mais 😀