Guto Carvalho: 1o Treinamento Puppet Fundamentals em Porto Alegre
9 de Abril de 2015, 21:06 - sem comentários aindaPuppet Fundamentals
09, 10 e 11 de Junho de 2015
Horário: 09:00 às 18:00
Local: Porto Alegre/RS
Informações:
https://puppetlabs.com/events/porto-alegrers-puppet-fundamentals-sponsored-instruct-brazil
http://www.unirede.net/treinamentos/treinamento-puppet-fundamentals/
No curso Fundamenals, o aluno irá entender como funciona o Puppet, vai descobrir como tudo começou, qual foi a motivação para ele ser criado, como a PuppetLabs surgiu, o aluno verá aspectos fundamentais de gerência de configurações, aspectos históricos e culturais de administração de servidores e tudo isto o levará a conhecer o Puppet Enterprise.
O curso é 50% prático e 50% teórico, nele você vai aprender como trabalhar com o puppet em modo local (apply) e em modo cliente e servidor (master), vai entender a camada de abstração, vai conhecer, entender e utilizar a DSL do Puppet, vai entender, utilizar e construir módulos e classes, vai aprender, entender e fazer a classificação de nodes, vai conhecer e utilizar os principais recursos do puppet (resource types), vai entender como funcionam relacionamentos e a construção da linguagem.
Toda a construção das classes dos módulos será versionada, durante todo o curso será utilizado o GIT como ferramenta de versionamento, haverá inclusive uma introdução ao GIT para nivelar os alunos.
O curso vai abordar além de tudo isto, templates, defined resource types, parameterized classes, herança, separação de código e dados com HIERA, utilização de módulos do PuppetForge dentre muitos outros assuntos interessantes.
A cada tópico que o aluno completar, um laboratório será executado proposto, possibilitando que ele já aplique o que acabou e estudar e aprender, essa abordagem é bem interessante e produtiva.
[s]
Guto
Ricardo Martins: Docker: Criando suas próprias imagens – Parte III/III
8 de Abril de 2015, 23:02 - sem comentários aindaO post de hoje é pra mostrar como criar suas imagens do docker, publicá-las no Docker Hub (Registry) e depois usar/disponibilizar onde precisar. O primeiro passo é instalar o docker: [root@rmartins /]# yum install docker-io Loaded plugins: fastestmirror Setting up Install Process Loading mirror speeds from cached hostfile * base: mirror.nbtelecom.com.br * epel: mirror.globo.com * […]
O post Docker: Criando suas próprias imagens – Parte III/III apareceu primeiro em Ricardo Martins.
Gomex: Criando imagens Docker (Dockerfile)
5 de Abril de 2015, 11:09 - sem comentários aindaNo artigo anterior sobre Docker, eu expliquei como modificar uma imagem docker usando COMMIT, mas propositalmente não comentei que essa não é a melhor prática 
Evitei tocar nesse assunto para não frustrar o aprendizado, pois é necessário aprender como funciona o COMMIT, com DIFF e afins.
A melhor forma de modificar uma imagem Docker é recriando ela, ou seja, modificando seu Dockerfile, ou criando um Dockerfile novo tendo a imagem escolhida como base e nesse artigo falaremos sobre tudo isso.
Dockerfile
Dockerfile é um arquivo, que contém um conjunto de instruções necessárias para se criar uma imagem Docker, ou seja, com posse do Dockerfile de uma determinada imagem, basta modificar o que deseja e recriar a imagem “do zero”, isso pode demorar um pouco mais, mas essa imagem será muito mais “enxuta” e você terá controle total do seu estado, o que seria bem mais difícil no modelo de efetuar commit de um container.
Caso não tenha o Dockerfile, você pode usar uma imagem a sua escolha como base e então criar a sua imagem como uma camada acima.
Sintaxes básicas
FROM : É a imagem base. Normalmente é usada com nome de distribuição (Debian, Ubuntu e afins), pois não precisaremos criar toda estrutura, certo?
MAINTAINER : É onde se especifica o autor da imagem.
RUN : São as instruções que serão executadas para criação da imagem em questão.
ENTRYPOINT : Especifica o que o que será executado ao iniciar o container. Ele age como precedente a sintaxe CMD, ou seja, caso o ENTRYPOINT seja “top”, o CMD pode ser “-b” que nesse caso ele executaria o top em modo batch. Uma vez que o ENTRYPOINT não seja especificado, e um CMD seja usado, o ENTRYPOINT padrão é “/bin/sh -c“.
EXPOSE : Usado para informar qual porta o container docker irá “escutar”. Docker usa essa informação para interconexão entre containers, ao utilizar links. EXPOSE não define qual porta será exposta para o hospedeiro ou tornar possível o acesso externo para portas do container em questão. Para expor essas portas utilize em tempo de inicialização da imagem a flag -p ou -P.
Para explicação mais exaustiva das sintaxes já explanadas e outras novas, acesse essa documentação.
Exemplo
Crie uma pasta com o comando abaixo:
# mkdir nginx
Entre nessa pasta:
# cd nginx
E então crie um arquivo chamado “Dockerfile” com o seguinte conteúdo:
FROM debian
MAINTAINER Rafael Gomes <gomex@riseup.net>
RUN apt-get update
RUN apt-get install -y nginx
ENTRYPOINT ["/usr/sbin/nginx"]
EXPOSE 80
Com esse Dockerfile, temos:
- Uma imagem com base na imagem do Debian, ou seja, não precisamos nos preocupar com o sistema básico.
- O autor dessa imagem sou eu
- Primeiro eu atualizo a base do apt-get e então instalo o nginx.
- Ao iniciar essa imagem ela executará o nginx automaticamente.
- A porta exposta para possível interconexão entre containers é a porta 80.
Nesse link tem um ótimo documento explicando as boas práticas na criação de um Dockerfile.
Criando a imagem
Com o Dockerfile preenchido, execute o comando abaixo para criar sua imagem:
# docker build -t=gomex/nginx .
No lugar de “gomex” coloque o seu usuário da nuvem pública do docker e no lugar de “nginx” o nome da sua imagem.
Ao terminar, pode efetuar o push para a nuvem pública e assim proporcionar a distribuição da sua imagem:
# docker push gomex/nginx
Pronto! Agora já tem sua imagem prontinha, totalmente “enxuta” e disponível para que outra pessoa possa baixar e utilizar.
Por hoje é só pessoal, logo teremos mais artigos sobre Docker. Fiquem atentos.
Wellington Silva: Docker, do Básico a Orquestração e Clusterização - 5. Ambiente
24 de Março de 2015, 3:00 - sem comentários aindaNessa série de artigos estamos abordando tópicos para uma boa utilização do Docker.
Para entender melhor a orquestração e antes de partirmos para a clusterização precisamos entender bem como usar o docker em nossa máquina de dia a dia, a nossa máquina dev, nosso ambiente de desenvolvimento.
Se sua máquina estiver rodando Linux, qualquer distribuição, tudo fica mais fácil. Por que wsilva? Porque como vimos nos artigos anteriores o Docker trabalha com LXC - Linux Containers. Bom, linux dispensa comentários mas container, fazendo um paralelo com a virtualização tradicional, seria o sistema operacional (Linux também no nosso caso) rodando como guest.
Pô wsilva mas então é Linux rodando em cima de Linux!?
Exatamente. E como também já vimos anteriormente a grande vantagem de usarmos LXC é não precisar do hypervisor (Virtualbox e afins), já que muitos recursos são compartilhados entre o Host e o Guest.
Aaaaa wsilva, então por isso que tem que ser Linux sobre Linux, senão esse compartilhamento não rola, certo!?
Certíssimo, rodar um linux container num host Windows acho quase impossível por causa da arquitetura, do Kernel diferente, etc. O mesmo também seria para o MacOS, mas devemos lembrar que MacOS vem do Unix. E o Linux vem do Minix que vem do Unix. Isso significa que por mais difícil que possa parecer pode pintar algum louco que consiga compartilhar o Kernel, libs e outros recursos de um host MacOS com containers Linux, ou até o contrário.
No Linux
No linux tenho trabalhado apenas com o Docker Compose. Temos um fig.yml, que em breve teremos que renomear para docker-compose.yml, com os container, a instruções de cada container, os links e tudo mais.
Após rodar o fig up / docker-compose up nossos containers sobem como se estivessem em nossa máquina local. Podemos confirmar com o docker-compose ps.
1$ docker-compose up -d 2fig.yml is deprecated and will not be supported in future. Please rename your config file to docker-compose.yml 3 4Recreating projeto_proxy_1... 5Recreating projeto_rabbit_1... 6Recreating projeto_mysql_1... 7Recreating projeto_solr_1... 8Recreating projeto_redis_1... 9Recreating projeto_web_1...
1$ docker-compose ps 2fig.yml is deprecated and will not be supported in future. Please rename your config file to docker-compose.yml 3 4 Name Command State Ports 5-------------------------------------------------------------------------------------------------- 6projeto_mysql_1 /entrypoint.sh mysqld Up 0.0.0.0:3306->3306/tcp 7projeto_proxy_1 forego start -r Up 443/tcp, 0.0.0.0:80->80/tcp 8projeto_rabbit_1 /run.sh Up 0.0.0.0:15672->15672/tcp, 0.0.0.0:5672->5672/tcp 9projeto_redis_1 redis-server Up 0.0.0.0:6379->6379/tcp 10projeto_solr_1 /start-solr.sh Up 0.0.0.0:8983->8983/tcp 11projeto_web_1 /start-web.sh Up 0.0.0.0:49153->80/tcp
Podemos acessar por exemplo o dashboard do rabbit pelo ip de loopback: http://127.0.0.1:15672, o próprio painel do solr pelo http://127.0.0.1:8983/, ou até o redis sem passar o parâmetro com o host:
No MacOS
No MacOS (e creio que no Windows seja parecido) precisamos rodar uma máquina virtual linux com o serviço docker de pé e é esse linux que vai ser o docker host rodar os containers.
Até a postagem desse artigo a instalação oficial de docker para MacOS e para Windows era através do boot2docker.
O boot2docker é um distribuição linux bem leve (aproximadamente 27MB) baseada no Tiny Core Linux que carrega em memória e já tem suporte para o file system (AUFS) requerido pelo docker e o próprio docker service.
Primeiro temos que criar nossa VM com o comando:
1$ boot2docker init
Depois podemos iniciar nossa VM com o comando
1$ boot2docker start
Sempre que iniciarmos uma janela de terminal nova no MacOS devemos exportar as variáveis de ambiente do Docker para que consigamos levantar nossos containers (que neste caso rodarão dentro do boot2docker). Basta rodar o comando:
1$ $(boot2docker shellinit)
Com as variáveis exportadas podemos subir nossos containers:
1$ docker-compose up -d
Para parar nossa VM:
1boot2docker stop
Desvantagem
A desvantagem de não estar usando linux é que para acessar nossos containers temos que usar ip da VM, do boot2docker. Podemos pegar com o comando:
1$ boot2docker ip
E assim acessar nossos containers pelo ip. Ex.: http://{ip.do.boot2docker}:15672 (rabbit) ou http://{ip.do.boot2docker}:8983/ ou até concatenar comandos para acessar o container de redis por exemplo:
1redis-cli -h `boot2docker ip`
Alternativas no MacOS
Docker Machine
Quando disse que a até a data do post a instalação oficial era o boot2docker é porque agora temos uma “alternativa oficial” (sim entre aspas mesmo), o docker-machine que não só provisiona VMs linux em nossa máquina dev através do Virtualbox e VMware ele também provisiona em outros ambientes Linux e em serviços cloud como o EC2 da Amazon, o Azure, a Digitalocean, o Google Engine, Openstack, Rackspace, Softlayer, etc.
Por que alternativa oficial entre aspas? Porque a VM que ele provisiona (pelo menos localmente) é um boot2docker, e sendo o docker-machine mais completo pode vir a substituir o processo de instalação em MacOS e Windows que atualmente na documentação é a instalação do boot2docker puro e simples.
Para criar uma VM na DigitalOcean por exemplo executamos:
1$ docker-machine create --driver digitalocean --digitalocean-access-token=tokenxptoyadaxptoyadatoken nome-da-vm
No nosso caso, para trabalhar localmente podemos criar uma VM no Virtual Box:
1$ docker-machine create -d virtualbox nome-da-vm
Se quisermos criar com mais recursos.
1$ docker-machine create --driver virtualbox --virtualbox-memory=2048 --virtualbox-disk-size=30000 nome-de-outra-vm
Se não passados esses parâmetros os padrões adotados são 20000 MB de disco e 1024 MB de memória.
Para listar as VMs criadas:
Para exportar as variáveis de ambiente em nosso shell:
1$ $(docker-machine env nome-da-vm)
Para parar e retormar uma vm. Se não passarmos o nome da VM ele entenderá que é a VM ativa:
Para mudar a VM ativa:
1$ docker-machine active nome-de-outra-vm
Kitematic
Dois dias depois que escrevi a parte 4 desta série de posts, no dia 12 de março, o pessoal do Docker estava apresentando o Kitematic como alternativa para Mac OS. Acompanhei o meet up online de apresentação do Kitematic no dia 17 de março e vou passar minhas impressões pessoais a respeito.
O Kitematic é um GUI (Graphical User Interface) baseado no docker-machine, escrito em Javascript. Parecido com o Atom é baseado na engine do Google Chrome (da até para inspecionar elemento) e desta maneira pode ser portado para o Windows. Durante a parte das perguntas (Q&A) no meet up eles deixaram escapar que essa portabilidade já está no RoadMap deles (Além de diversas melhorias na integração com dockerhub).
Esse carinha facilita muito a criação e a manutenção de containers, e se tivermos uma orquestração via docker-compose, os container criados também aparecerão também na tela do Kitematic.
A interação se dá por botões simples e intuitivos. Temos a opção para entrar no console de um container que esteja rodando (por debaixo dos panos utiliza o comando docker exec -ti container /bin/bash), temos a opção de abrir no navegador a url, na verdade o ip, do container, temos a opção de alterar as configurações de execução de um containere outras opções.
Abrindo o Kitematic. A VM criada é iniciada por baixo dos panos:
Criando container com base em imagens existentes no Dockerhub:
Iniciando o novo container:
Opções de visualizar log e preview no navegador:
Configurações do container:
Configurações de exposição de portas:
Configurações de volumes a serem montados:
DVM
Alternativa para subir o docker no Mac OS http://fnichol.github.io/dvm/. Também é baseado numa VM rodando boot2docker e os containers dentro da VM.
Ferramentas para gerenciamento de docker containers
São ferramentas para gerenciar a criação e até orquestração de containers
Shipyard
É um container que quando iniciamos consegue gerenciar a criação de novos containers via navegador. Tem algumas ferramentas interessantes que permitem monitoramento e até orquestração. http://shipyard-project.com/.
Docker-UI
Parecido com o Shipyard mas com menos recursos https://github.com/crosbymichael/dockerui.
Panamax
Também parecido com Shipyard te dá a opção de subir um sistema multi containers http://panamax.io/.
Concluindo
Todas as ferramentas que tenho visto para usar containers em Mac OS e Windows esbarram em ter que rodar os containers sobre uma VM (boot2docker). E sempre que rodamos esses containers para conseguirmos acesso via web , logs, e acesso remoto temos que ter em mente que não adianta bater no ip de loopback (127.0.0.1). Temos que bater (ou apontar nossos virtual hosts para) endereço da VM.
O mundo docker está evoluindo muito e bem rápido, é bom acompanhar as novidades sempre no blog deles e nos meet ups das comunidades.
To Be Continued
Para finalizar a série no próximo artigo falaremos sobre clusterização usando Docker Swarm
Té +
Ricardo Martins: OpsWorks: Trabalhando com cookbooks customizadas – Parte III/III
23 de Março de 2015, 19:51 - sem comentários aindaFinalizando a série de artigos sobre o OpsWorks, neste post veremos como utilizar cookbooks customizadas em nosso ambiente. Para começar, entre na console do OpsWorks e vamos criar nossa segunda stack. Clique em Add Stack e preencha os dados necessários: Clique em advanced para abrir mais opções e definir que utilizaremos cookbooks customizadas. No caso, […]
O post OpsWorks: Trabalhando com cookbooks customizadas – Parte III/III apareceu primeiro em Ricardo Martins.
