Guto Carvalho: Nova Vagrant BOX com CentOS 7.2.1511 e GitLab CE 8.12.0
24 de Setembro de 2016, 14:07 - sem comentários aindaDivulgando nova box CentOS 7.2 com GitLab CE 8.12.0 no atlas. Agora fica mais fácil testar a última versão do Gitlab com o menor esforço possível :)
1. Instalando a box
Se você usa vagrant 1.8.x para fazer download da box digite
vagrant box add gutocarvalho/centos7x64-gitlab-ce
Crie um diretório para o projeto
mkdir centos7-gitlab-ce; cd centos7-gitlab-ce
Crie um arquivo Vagrantfile no diretorio com o conteúdo abaixo
# -*- mode: ruby -*-
# vi: set ft=ruby :
VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
config.vm.hostname = "gitlab.hacklab"
config.vm.box = "gutocarvalho/centos7x64-gitlab-ce"
config.vm.network "private_network", ip: "192.168.250.44"
config.vm.provider "virtualbox" do |virtualbox|
virtualbox.customize [ "modifyvm", :id, "--cpus", "1" ]
virtualbox.customize [ "modifyvm", :id, "--memory", "2048" ]
virtualbox.gui = true
end
if Vagrant.has_plugin?("vagrant-cachier")
config.cache.scope = :box
end
end
Inicie o projeto
vagrant up
Acesse a vm
vagrant ssh
Acesse o GitLab
http://192.168.250.44
2. Refs
Para acessar a box no atlas
https://atlas.hashicorp.com/gutocarvalho/boxes/centos7x64-gitlab-ce
O repo git com o código para build da box
https://gitlab.com/gutocarvalho/packer-centos-gitlab
É isso, divirta-se.
[s]
Guto
Guto Carvalho: Vagrant 1.8.5 ssh retrying bugfix
24 de Setembro de 2016, 13:31 - sem comentários aindaO Vagrant 1.8.5 tem um bug crítico em guests linux, o vagrant simplesmente não consegue terminar o vagrant up por causa de um bug na geração do arquivo authorized_keys que contém as chaves permitidas para acesso ssh por chaves no guest. O problema é que o vagrant está gerando o arquivo com a permissão errada e o subsistema ssh — neste casos — ignora o arquivo por questões de segurança.
Você provavelmente está tendo uma saíde similar após atualizar para o 1.8.5
centos: Waiting for machine to boot. This may take a few minutes...
centos: SSH address: 127.0.0.1:2222
centos: SSH username: vagrant
centos: SSH auth method: private key
centos: Warning: Remote connection disconnect. Retrying...
centos:
centos: Vagrant insecure key detected. Vagrant will automatically replace
centos: this with a newly generated keypair for better security.
centos:
centos: Inserting generated public key within guest...
centos: Removing insecure key from the guest if it's present...
centos: Key inserted! Disconnecting and reconnecting using new SSH key...
centos: Warning: Authentication failure. Retrying...
centos: Warning: Authentication failure. Retrying...
centos: Warning: Authentication failure. Retrying...
centos: Warning: Authentication failure. Retrying...
centos: Warning: Authentication failure. Retrying...
centos: Warning: Authentication failure. Retrying...
centos: Warning: Authentication failure. Retrying...
centos: Warning: Authentication failure. Retrying...
centos: Warning: Authentication failure. Retrying...
centos: Warning: Authentication failure. Retrying...
A solução é simples edite o arquivo public_key.rb
/opt/vagrant/embedded/gems/gems/vagrant-1.8.5/plugins/guests/linux/cap/public_key.rb
Procure a linha
mv ~/.ssh/authorized_keys.tmp ~/.ssh/authorized_keys
Adicione abaixo dela
chmod 0600 ~/.ssh/authorized_keys
Salve, e suba a VM novamente, isso deve resolver o problema.
Refs
No vagrant 1.8.6 isto estará resolvido, mais info sobre o bug abaixo
[s]
Guto
Wellington Silva: Acessando a VM do Docker for Windows e Docker For Mac
23 de Setembro de 2016, 2:22 - sem comentários aindaTenho usado o Docker for Mac desde que lançaram seu beta, já nas versões 1.11.* e agradeci muito por facilitarem minha vida no OS X, só que o processo de Debug nas VMs ficou um pouco mais oneroso.
VMs Debian e Ubuntu
Quando comecei com o Docker tive que subir muita VM na mão: Ubuntu, Debian, CentOS. Depois passei a usar o boot2docker e seu client que facilitava apontar o Docker Client para o Docker Daemon rodando dentro da VM.
Com Vagrant
Os problemas de performance me levaram a customizar o boot2docker com arquivos shell script para montar as shared folders manualmente e usando NFS. Acabei usando Docker por um tempo dentro do Vagrant para automatizar este processo.
Docker Machine
O Docker Machine foi uma baita invenção, com ele conseguia usar mais de uma VM na mesma máquina de maneira mais fácil e customizava cada uma delas conforme minha necessidade, além de poder rodar Docker remotamente em máquinas na Cloud usando minhas credenciais da Amazon Web Service ou meu token da Digital Ocean por exemplo.
Docker for Mac e Windows
Após este post da Docker https://blog.docker.com/2016/06/docker-mac-windows-public-beta rodar no OS X era bem parecido com rodar no Linux, mas alguns detalhes como a url para testar (local.docker) ou acesso apenas a pasta Home para montagem de volumes sempre me lembravam que estávamos em uma VM.
Na segunda frase deste mesmo post eles mencionam:
“Our major goal was to bring a native Docker experience to Mac and Windows, making it easier for developers to work with Docker in their own environments”.
Naquele momento a cabeça de muito Dev achava que o Docker estava rodando nativo no OS X e no Windows, o que na minha opinião seria uma mágica já que o kernel do OS X, o Darvin, e o kernel do Windows são fechados e não temos ideia se existe recurso para isolar recursos da máquina host.
Quando questionados como eles funcionavam a Docker sempre abriu o jogo e contou que havia uma máquina virtual rodando Alpine Linux mas que os aplicativos e a experiência de uso eram nativos. Nativos também eram os hypervisors utilizados para rodar essa mini VM com Linux e Docker, Hyper-V no Windows e xhyve no OS X.
Como debugar
Umb belo dia estava tentando fazer rodar um container que permitia acesso via http e não consegui acessar a porta da aplicação no navegador.
Depois de muito bater a cabeça achei que poderia ser algum problema na VM rodando o Docker, já tinha passado por algo parecido e dentro da VM rodando um simples curl no endereço da aplicação ela respondia. Mas como acessá-la para fazer esse teste? Com o Docker Machine bastava rodar o comando:
docker-machine ssh nome-da-vm
e bum, estava no shell da VM. Ai era só instalar os pacotes do boot2docker que precisava para debugar e testar. Por exemplo o htop:
tce-load -wi htop
No OS X
Com o Docker for Mac tive que buscar na documentação e acabei achando uma maneira de acessar a VM na página https://beta.docker.com/docs/mac/troubleshoot/ que já não existe mais, somos redirecionados para a página https://docs.docker.com/docker-for-mac/troubleshoot/ desde que encerrou o beta público e o Docker for Mac e Windows foram liberaram para o público em geral, nesta página a informação de acesso a VM foi removida.
Para acessar a VM no OS X basta utilizar o comando screen para anexar (attach) o terminal da VM:
screen $HOME/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty
Para sair devemos rodar os seguintes comandos em outro terminal para desanexar e limpar as sessões de screen terminadas.
screen -D
screen -wipe
Exemplo mostrando o acesso:
No Windows
No Windows até hoje não achei uma maneira fácil, tipo ssh ou screen então apelei por usar um container Docker e compartilhar a maioria dos namespaces do host:
docker run --net=host --ipc=host --uts=host --pid=host -it --security-opt=seccomp=unconfined --privileged --rm -v /:/host alpine /bin/sh
Em seguida assumimos o controle do host (VM) rodando Docker.
chroot /host
Vale lembrar que esta maneira também funciona no OS X como no exemplo a seguir.
É isso ae galera, em algum próximo post explico melhor esse lance de namespaces e cgroups que faz toda a mágica de isolamento dos containers.
Bons debugs !!!
Vídeos com exemplos adicionados em 28 de setembro.
Guto Carvalho: Rsync Unicode entre Mac e Linux
21 de Setembro de 2016, 22:37 - sem comentários aindaO problema
Case você use MacOS para trabalhar — com é o meu caso, e também para publicar sites em servidores Linux utilizando rsync, tenho uma dica preciosa para vocês.
Há alguns meses eu criei um novo blog utilizando Hugo, neste blog quando eu criava posts com palavras com acento eu percebia que o link no site quebrava após a cópia para o servidor linux. Inicialmente eu achei que era um problema no Apache HTTPd, eu até setei default chartset e nada de resolver, estava quase jogando a toalha quando resolvi usar o Google de verdade, após alguma pesquisa entendi o problema.
No FAQ ( https://rsync.samba.org/FAQ.html ) do projeto RSYNC já tem a dica de como resolver isso, mas é um pouco obscuro de entender.
rsync recopies the same files
Some people occasionally report that rsync copies too many files when they expect it to copy only a few. In most cases the explanation is that you forgot to include the --times (-t) option in the original copy, so rsync is forced to (efficiently) transfer every file that differs in its modified time to discover what data (if any) has changed.
Another common cause involves sending files to an Microsoft filesystem: if the file's modified time is an odd value but the receiving filesystem can only store even values, then rsync will re-transfer too many files. You can avoid this by specifying the --modify-window=1 option.
Yet another periodic case can happen when daylight-savings time changes if your OS+filesystem saves file times in local time instead of UTC. For a full explanation of this and some suggestions on how to avoid them problem, see this document.
Something else that can trip up rsync is a filesystem changeing the filename behind the scenes. This can happen when a filesystem changes an all-uppercase name into lowercase, or when it decomposes UTF-8 behind your back.
An example of the latter can occur with HFS+ on Mac OS X: if you copy a directory with a file that has a UTF-8 character sequence in it, say a 2-byte umlaut-u (\0303\0274), the file will get that character stored by the filesystem using 3 bytes (\0165\0314\0210), and rsync will not know that these differing filenames are the same file (it will, in fact, remove a prior copy of the file if --delete is enabled, and then recreate it).
You can avoid a charset problem by passing an appropriate --iconv option to rsync that tells it what character-set the source files are, and what character-set the destination files get stored in. For instance, the above Mac OS X problem would be dealt with by using --iconv=UTF-8,UTF8-MAC (UTF8-MAC is a pseudo-charset recognized by Mac OS X iconv in which all characters are decomposed).
If you think that rsync is copying too many files, look at the itemized output (-i) to see why rsync is doing the update (e.g. the 't' flag indicates that the time differs, or all pluses indicates that rsync thinks the file doesn't exist). You can also look at the stats produced with -v and see if rsync is really sending all the data. See also the --checksum (-c) option for one way to avoid the extra copying of files that don't have synchronized modified times (but keep in mind that the -c option eats lots of disk I/O, and can be rather slow).
Em resumo, quando você copia um arquivo do MacOS que usa sistema de arquivos HFS+ para um sistema linux há um problema pois o MacOS usa Unicode do tipo NFD enquanto o Linux usa Unicode do tipo NFC, com isso, dependendo do nome do arquivo, o Linux pode não reconhecer, em especial no meu caso em que um arquivo HTML possuia caracteres especiais.
Como resolver?
Eu copiava os arquivos dessa forma entre meu mac e o servidor linux
rsync -avz --stats --progress --delete /Mac/origem/* usuario@fqdn:/Linux/destino/
O segredo é acrescentar alguns parametros de conversão ao comando
--iconv=utf-8-mac,utf-8
O comando final ficará assim
rsync -avz --stats --progress --delete --iconv=utf-8-mac,utf-8 /Mac/origem/* usuario@fqdn:/Linux/destino/
Com isso meus arquivos são convertidos e transferidos corretamente.
Agora posso usar acento nos títulos dos posts sem receio de quebrar os links.
[s]
Guto
Guto Carvalho: Inscreva-se no DevOpsDays Brasília
20 de Setembro de 2016, 10:08 - sem comentários aindaÉ isto mesmo que você leu, vai ter DevOpsDays em Brasília e as inscrições para o evento já estão abertas, são apenas 280 vagas a venda, não perca a oportunidade de participar do evento que criou o termo “devops”.
Site do evento
http://brasilia.devopsdays.com.br
Agenda no site devopsdays.org
https://www.devopsdays.org/events/2016-brasilia/welcome/
Caso queira palestrar no evento o CFP também está aberto
http://brasilia.devopsdays.com.br/about/cfp/
Site para inscrições (eventize)
http://brasilia.devopsdays.com.br/post/registration_open/
Use o código DC61975969 para ganhar 20% de desconto na inscrição (Early Bird), esse desconto é limitado, aproveite!
O que é o DevOpsDays?
O DevOpsDays Brasília, associado e reconhecido pelo DevOpsDays.org, tem como objetivo reunir os interessados no assunto DevOps através da apresentação de palestras, painéis, minicursos e outras atividades. Considerando o aumento do interesse no desenvolvimento de software e cultura Ágil no Brasil, acreditamos que falar sobre DevOps é uma necessidade. O DevOpsDays Brasília 2016 vem preencher essa lacuna, uma vez que esse assunto ainda não foi tratado de forma sistemática em um evento próprio, mesmo com a atual e crescente demanda no Brasil. Pretendemos para esse evento convidar profissionais de empresas e organizações conhecidas no cenário de tecnologia da informação, para assim motivar a ampla participação, não somente de pessoas que já conhecem a cultura DevOps, mas também despertar o interesse daqueles que ainda não conhecem.
Nos vemos lá!
[s]
Guto
