rodrigolima.blog.br

$echo something | sed ‘s/something/Vida geek, Tecnologia da Informação, cotidiano e afins/g’

Eliminando arquivos não gerenciados pelo Puppet

Você sabe o que é o Puppet? Caso você seja um Sysadmin ou um Dev sugiro fortemente que comece a estudar sobre. O Puppet é um utilitário de gerenciamento de configuração de software. O desenvolvimento do Puppet é coordenado pela Puppet Labs. Segue o link: https://puppet.com/.

Não vou me aprofundar sobre os conceitos, vou apenas colocar uma dica que pode ser útil em algumas situações.

Você possui vários arquivos de configurações de vhosts do Apache gerenciados pelo Puppet, por exemplo, mas não quer que sejam criados novos arquivos manualmente no qual esses arquivos não sejam orquestrados/gerenciados pelo Puppet, pois com isso você poderia perder o controle do que está sendo colocado em produção.

Para resolver isso, existe um atributo que pode nos ajudar com isso, e esse atributo é do resource type “file”, o purge

    file { '/etc/httpd/confs.d': 
        ensure  => 'directory', 
        recurse => true, 
        purge   => true, 
    } 

    file { '/etc/httpd/confs.d/www.conf':
        ensure => 'present',
        source => 'puppet://modules/httpd/www.conf',
    } 

Com essa configuração acima, o Puppet irá manter no diretório /etc/httpd/confs.d apenas o arquivo www.conf. Todos arquivos criados manualmente serão removidos após o agente realizar a comunicação com o Puppet server.

Automatizando comandos com Fabric

Este post é apenas uma dica de como automatizar algumas tarefas remotamente em servidores Linux. Hoje em dia, automatizar tarefas é algo extremamente necessário em grandes ambientes e até em pequenos, para evitar trabalho e perda de tempo. Costumo usar o Puppet como gerenciamento de configuração do meu ambiente, juntamente com Github para controle de versões das confs dos servidores. Já se foi o tempo que o Git era utilizado apenas por desenvolvedores, hoje o pessoal de Infra tem usado muito, seguindo o conceito de DevOPS.

Só que o Puppet tem algumas limitações, digamos assim, para execução de comandos remotos. As vezes você quer apenas dar um “restart” em algum daemon nos seus servidores. Isso não é problema caso você possua uns dois ou 3 servidores, mas já imaginou fazer isso em uns 200 servidores? Vai levar um certo tempinho até você terminar isso né? Aí que entra o Fabric. O Python é uma biblioteca Python e um utilitário de linha de comando que utiliza o SSH para executar tarefas administrativas remotamente.

Existe uma boa documentação no site do Fabric, mas o objetivo aqui é só demonstrar um exemplo prático de como utilizar ele para executar algumas tarefas remotamente.

Antes de começarmos, a instalação do Fabric pode ser efetuado com o comando pip:

# pip install fabric

Você define as tarefas que você vai querer executar em um arquivo, chamado “fabfile.py”. Você pode definir várias “funções” nesse arquivo, e depois você apenas “chama” essa função desejada, o que torna bem mais simples definir várias tasks sem a necessidade de estar editando o arquivo para cada execução.

Aqui, um exemplo do conteúdo do arquivo fabfile.py:

from fabric.api import run, sudo, env, settings,    hide, parallel
from fabric.colors import yellow, green
def host_type():
run('uname -s')

def read_hosts():
"""
Reads hosts from sys.stdin line by line, expecting  one host per line.
"""
import sys
env.hosts = [line.strip() for line in sys.stdin.readlines()]
t) 
@parallel

def restart_nginx():
sudo('systemctl restart nginx')
@parallel

Só explicando um pouco o exemplo acima. A função host_type, caso chamada, irá executar o comando uname -s em todos os servidores e irá retornar a saída para o terminal. A segunda função é uma boa opção caso você tenha uma lista dos hostnames ou IPS dos seus servidores em um arquivo txt por exemplo, no qual ele irá ler linha por linha do arquivo e executar o comando remotamente no servidor correspondente. Importante salientar, é necessário que você tenha a sua chave pública SSH exportada em todos os servidores, para que não seja exigido senha no momento da conexão.

Agora, vamos chamar o Fabric para verificar o hostname de todos os servidores que estão listados no arquivo servers.txt por exemplo:

# cat servers.txt |fab read_hosts host_type -P

[server1] Executing task    'host_type'
[server2] Executing task    'host_type'
[server1] run: uname -s
[server2] run: uname -s
[server1] out: Linux
[server1] out:

[server2] out: Linux
[server2] out:


Done.

O comando acima executa um cat no arquivo servers.txt redirecionando saída para o fab ao qual executa a função read_hosts (que lê cada linha do arquivo servers.txt juntamente com a função host_type. O conteúdo do arquivo servers.txt possui o hostname ou o endereço IP dos servidores ao qual o Fab irá executar a função desejada.

A saída para cada consulta é exibido na linha com o hostname do server e mais “out”:

[server1] out: Linux

Obs: O parâmetro “-P” no comando diz que o comando será executado paralelamente, ou seja, ele irá executar o comando ao mesmo tempo em todos os servidores.

Era isso pessoal, é um artigo curto, mas tem o objetivo apenas de apresentar essa pequenha ferramenta que pode fazer toda a diferença no seu dia a dia. A documentação é bem completa e você poderá encontrar diversos exemplos de como montar as suas tasks…

;-)

Alterando o Runlevel no CentOS7

Apenas uma pequena dica para quem deseja alterar o Runlevel no CentOS7 ou RHEL7.

Nas versões anteriores, como por exemplo no CentOS6, bastava editar o arquivo /etc/initab e alterar o runlevel na seguinte linha:

id:3:initdefault:

No exemplo acima, o runlevel está setado para “3”. O runlevel 3 significa “Full multiuser mode”, ou seja, inicia o sistema normalmente com suporte a rede e principalmente em modo texto. Caso deseje alterar para iniciar o sistema com a interface gráfica (KDE, Gnome, etc), basta alterar a linha acima para “5”.

Com a mudança do Init para Systemd apartir do CentOS7 (Caso queira saber mais sobre isso: Leia aqui, a maneira como é alterado o runlevel muda ligeiramente (bastante na real ;-)

Verificando runlevel atual

[root@localhost ~] systemctl get-default
multi-user.target

O multi-user-agent equivale ao runlevel “3”, ou seja, modo texto.

Alterando o runlevel

Caso você queria mudar o runlevel para o modo gráfico, ou “runlevel 5” como era conhecido nas versões anteriores:

[root@localhost ~] systemctl set-default graphical.target

Basta reiniciar o sistema que você verá que iniciará em modo gráfico. Para verificar os outros Runlevels:

[root@localhost ~] systemctl list-units --type=target

Mantendo o blog Octopress em diferentes maquinas

Neste post, explicarei como manter o seu blog com o Octopress em diferentes lugares, ou melhor, em diferentes máquinas. Talvez você precisa escrever seus posts na tua estação no trabalho e ás vezes em casa por exemplo, ou talvez você tenha reinstalado seu SO.

Não basta apenas fazer o clone do seu repositório do Octopress do Github, pois ele apenas “clona” os “renders” do blog localmente. O repositório Octopress no Github possui dois branchs, source e master. O branch source contém os fontes que são usados para gerar o blog, e o branch master possui o próprio blog.

Quado a pasta local é criada seguindo o Octopress Setup Guide, o branch master fica na subpasta _deploy. Como esta pasta começa com um underscore, ela é ignorada quando é feito o push para o repositório: git push origin source. Por isso é necessário seguir os seguintes passos:

Clonando o repositório

Primeiro, crie um diretório vazio e faça um git init do zero:

$ mkdir <directory> && cd <directory> && git init

Adicione o repositório remoto do seu blog e faça o pulldo branch source:

$ git remote add origin git@github.com:username/username.github.io.git
$ git pull origin source

Crie o branch local source e remova o branch local master para evitar confusão com o branch remoto:

$ git checkout -b source
$ git branch -D master

Agora, crie o diretório vazio _deploy e sincronize com o branch remoto master:

$ mkdir _deploy
$ git init
$ git remote add origin git@github.com:username/username.github.io.git
$ git pull origin master

Agora já está tudo pronto para realizar o update do Blog.

Crie um novo post:

$ rake new_post["Novo Post"]
$ rake generate
$ rake deploy

E não esqueça de fazer o push do branch source:

$ git push origin source

Bash Completion for MacOS Sierra

Uma coisa que sinto falta utilizando o MacOS da Apple é o Bash Completion. Com ele instalado, me poupa bastante digitação e tempo durante o meu dia de trabalho. Basicamente, ele preenche automaticamente alguns comandos somente apertando a tecla “TAB”. Isso é natural no bash para completar comandos, mas as opções e demais informações você precisa digitar. Com o Bash Completion, eu consigo digitar por exemplo:

$ ssh <TAB>

Com isso ele lista todos os hosts que eu já digitei anteriormente. Isso é muito útil no dia a dia. É claro que isso pode gerar uma pequena lentidão na execução do comando e também consome maiores recursos do hardware, mas para mim isso vale a pena pela facilidade.

Para instalar é bem simples, você precisa usar o “Port” ou “Homebrew”. Esses caras são os gerenciadores de pacotes compatíveis no MacOS. São como Yum e Apt em sistemas Linux.

Não vou cobrir aqui a instalação desses caras, mas vou deixar abaixo o link para caso você ainda não tenha instalado:

https://www.macports.org/

http://brew.sh/

Para instalar o Bash Completion com o Port:

$ sudo port install bash-completion

Depois de instalado, basta você inserir o seguinte conteúdo no seu .bash_profile:

# bash-completion
if [ -f /opt/local/etc/profile.d/bash_completion.sh ]; then
       . /opt/local/etc/profile.d/bash_completion.sh
fi

Python Editor

Apenas uma dica para quem está começando a desenvolver em Python. Recomendo a utilização do Editor Atom https://atom.io/. Ele é um editor de texto desenvolvido pelo pessoal do Github.

E após a instalação do Atom, instale o plugin linter-pylama: https://atom.io/packages/linter-pylama

Com esse plugin, ele te oferece várias features e te ajuda a desenvolver seguindo as recomendações do PEP8 (Style Guide for Python Code)

Limpando o cache do Java no Linux

Essa é uma pequena dica para limpar o cache do Java no Linux.

É simples. Basta abrir o “Java Control Panel”, para isso, digite o comando “javaws -viewer” no terminal.

$ javaws -viewer

Agora basta clicar no botão Settings em “Temporary Internet Files” e fazer a exclusão do cache.

Existem outras configurações de Java que podem ser realizadas no Java Control Center, porém não vou entrar em detalhes aqui.

Instalação e Configuração Octopress

Eu utilizo geralmente 2 ou 3 equipamentos para escrever meus posts, utilizo meu notebook do trabalho, meu MacBook pessoal e por vezes meu computador em casa. Com isso, achei interessante disponibilizar o código do meu blog em algum drive virtual na nuvem, assim eu consigo postar qualquer artigo em qualquer dispositivo que estiver utilizando, bastando apenas deixá-lo configurado para tal tarefa. Como já utilizo o Dropbox a algum tempo, achei interessante manter meu blog lá.

O objetivo aqui é explicar o processo de instalação e configuração do Octopress. A maioria dos passos aqui estão na documentação oficial do Octopress, porém tem alguns detalhes a mais no qual passei algum trabalho e é importante destacar aqui.

Vamos lá então.

Instalar as dependências do Octopress:

$ sudo yum install git ruby rubygems ruby-devel

Na documentação do Octopress é sugerido a instalação de algum ExecJS runtime JavaScript. Um deles é o nodejs. No caso do Fedora, é necessário instalar o pacote RPM, apenas instalando o Gem não funciona. É necessário também ter instalado e configurado o repositório EPEL

$ sudo yum install nodejs

Baixar a última versão do Octopress

Obs: Já baixar diretamente no seu diretório do Dropbox, geralmente em ~/Dropbox

$ pwd

/home/rodrigo.lima/Dropbox/Blog

$ cd octopress/

$ pwd

/home/rodrigo.lima/Dropbox/Blog/octopress

Instalar também algumas dependências do Ruby necessárias:

$ gem install execjs

$ gem install bundler

$ bundle install

Instalar e configurar agora o tema default do Octopress

$ rake install

Ok, o Octopress neste momento está pronto para ser utilizado. O próximo passo da documentação é como fazer o deploy do site. Existem algumas várias formas de se fazer o deploy, mas escolhi fazer o deploy no Github. O Github oferece um serviço de hospedagem free, e não vi necessidade de utilizar ou contratar um VPS em algum provedor, já que com o Octopress não irei precisar de banco de dados (Mysql, etc.), ou seja, será gerado apenas páginas estáticas e para isso o Github está mais do que suficiente.

Fazendo o deploy para o Github Pages

Caso você ainda não possua, terá que criar uma conta do Github. Faça isso caso você não tenha. Meu usuário no Gitbug é rodrigodlima, logo, ele irá disponibilizar meu blog em http://rodrigodlima.github.io. Antigamente, ele disponibilizada no domínio “.com”, porém agora utiliza o “.io”.

Crie um novo repositório no seguinte formato: username.github.io, onde username é o seu usuário no Github. No meu caso, ficou rodrigodlima.github.io. Caso você tenha algum domínio registrado, o Github oferece uma forma de apontar o seu domínio para lá, depois explico melhor como fazer isso.

Agora, vamos começar a ver algumas vantagens em utilizar o Octopress. Ele já disponibiliza alguns scripts para facilitar a configuração. Então, execute:

$ rake setup_github_pages

O script irá solicitar a você a URL do seu repositório git, com isso informe conforme solicitado. Ex: git@github.com:rodrigodlima/rodrigodlima.github.io.git.

Importante: É necessário inserir a sua chave pública SSH para conseguir fazer o deploy. Caso você não possua uma chave pública SSH, consulte a documentação do Github para inserir a sua chave:

https://help.github.com/articles/generating-ssh-keys/

Tanto no Fedora 20 como no CentOS 7 eu precisei editar o arquivo GemFile do Octopress e adicionar o seguinte:

 gem 'json'

$ cat Gemfile

source "https://rubygems.org"
group :development do
    gem 'rake', '~> 10.0'
    gem 'jekyll', '~> 2.0'
    gem 'octopress-hooks', '~> 2.2'
    gem 'octopress-date-format', '~> 2.0'
    gem 'jekyll-sitemap'
    gem 'rdiscount', '~> 2.0'
    gem 'json'
    gem 'RedCloth', '~> 4.2.9'
    gem 'haml', '~> 4.0'
    gem 'compass', '~> 1.0.1'
    gem 'sass-globbing', '~> 1.0.0'
    gem 'rubypants', '~> 0.2.0'
    gem 'rb-fsevent', '~> 0.9'
    gem 'stringex', '~> 1.4.0'
end
    gem 'sinatra', '~> 1.4.2'

Sem essa linha, dá erro no comando “rake generate”.

Agora sim:

$ rake generate

$ rake deploy

Esses dois comandos irão gerar o blog e fazer o primeiro commit para o Github. Porém, você precisa agora gerar um novo post para que seja publicado. E agora vem a vantagem de utilizar o octopress. É muito simples criar um novo post. Quer ver?

Criando o primeiro post

Para criar um novo post é muito simples:

$ rake new_post["Instalação e Configuração Octopress"]
mkdir -p source/_posts
Creating new post: source/_posts/2015-01-28-instalacao-e-configuracao-octopress.markdown

Veja que ele criou o post no caminho source/_posts/2015-01-28-instalacao-e-configuracao-octopress.markdown. Agora basta você editar o arquivo com o seu editor preferdo de markdown. Eu utilizo o Ramarkable:

Remarkable

Após fazer a edição que você deseja, salve o arquivo. E agora basta gerar a página e enviar ao Gitbub. Esses dois comandos abaixo fazem isso pra você:

$ rake generate

$ rake deploy

Cada vez que quiser criar um novo post, siga esses passos. Simples não? ;-)

Custom Domains

Conforme citei no começo do post, o Github oferece uma forma de customizar o seu domínio, caso você deseje. Por exemplo, eu possuo o domínio rodrigolima.blog.br registrado e gostaria que meu “blog” que acabamos de ver hospedados no Github, seja acessado através do meu domínio “rodrigolima.blog.br”. É muito simples de fazer e também está da documentação do Octopress.

echo ‘rodrigolima.blog.br’ >> source/CNAME

Agora, crie um registro “A” no seu DNS server apontando para o IP 192.30.252.153 ou 192.30.252.154 que são os IP’s do Github

Primeiro post

Sempre tive vontade de ter meu blog e publicar coisas que tenho vontade, principalmente na área de TI, já que atuo a algum tempo como Analista de Infraestrutura, e já passei por muita coisa e que seria interessante compartilhar e também algumas coisas de interesse pessoal e alguns hobbies, tais como dicas de viagens, esportes, etc. ;-) Porém, sempre me chateava tendo que criar uma infra para publicar qualquer coisa simples, até mesmo um texto. Sempre tinha que subir um Wordpress da vida, um Apache, etc. E dava mais trabalho ainda para escrever um post de maneira padronizada e simples. Foi aí que um belo dia pesquisando sobre algumas tecnologias li algo sobre Octopress. Antes de ler, pensei: Bom, deve ser mais um do tipo “Wordpress” ou Wiki da vida. Mas me enganei. Comecei a ler algumas características do Octopress e já vi que a proposta era diferente, pois é um framework para geração de páginas estáticas e com uma integração fantástica com o Github, não sendo necessário contratar um VPS para hospedar teu blog. Que maravilha, resolvi testar. Pois bem, posso dizer que não é uma configuração muito simples, levei uns dois dias para “entender” como funciona e para fazer funcionar. Mas depois de pronto, posso dizer: Vale a pena cada minuto perdido na configuração. Agora, em alguns poucos minutos gero um novo post, versiono ele, e o melhor, em texto puro, sem HTML, Javascripts, Templates, etc…

Como é o primeiro post e o meu ambiente ainda está em em fase “Beta”, ainda tem muito o que melhorar.

Eu utilizei como Sistema Operacional o CentOS 7 e Fedora 20 e tem algumas “gambiarras” para fazer o Octopress funcionar, e assim que me familiarizar melhor vou colocar um post explicando como efetuar a configuração.

Até breve!