Category: Tutoriais

Tutorais de como implementar algo com Docker.

Docker Service

2 Comments

Oi Pessoal,

Hoje queremos trazer em detalhes para vocês uma das features implementadas no Docker 1.12 (que foi lançado no último dia 29), e que já mencionamos aqui, que é o Docker Service. Para quem ainda não leu o nosso post sobre as novidades do Docker 1.12, o Docker Service é uma feature que foi incorporada pela engine Docker em sua última versão e que permite ao administrador criar e administrar sua stack de serviço dentro de um cluster Swarm, sem precisar utilizar uma segunda ferramenta para isso. Ela é parte integrante de uma série de melhorias que permitiram ao Docker 1.12 ter a camada de orquestração nativa em sua engine.

Mas afinal, como isso me ajuda? Bem, nas versões anteriores do Docker, para você ter algum tipo de orquestração você teria que utilizar uma série de ferramentas, como por exemplo: Docker Swarm, Docker Compose isso sem falar, que, se você quisesse provisionar isso em larga escala mesmo, o recomendado era utilizar Kubernetes, Mesos ou alguma outra forma de orquestração mais adequada. Agora está tudo dentro da própria engine do Docker, o que permite você ter maior controle sob o que está utilizando, e claro, permite você manipular esse ambiente de forma mais simples.

Para serviço especificamente, foi adicionado o sub-comando: docker service, e dentro dele alguns itens, veja:

  1. docker service create: Possibilita a criação de sua stack de serviço, é ele o que você mais vai ver hoje ;)
  2. docker service inspect: Verifica as informações sobre seu serviço e retorna informações sobre parametro utilizados para inicialização do mesmo, imagem utilizada, etc.
  3. docker service ls: Lista todos os serviços que você tem criado, e lhe retorna informações sobre nome, quantidade de replicas, etc.
  4. docker service rm: Remove o serviço desejado do cluster
  5. docker service ps: 2° comando mais útil, retorna para você o status de cada container que atende um serviço, é muito parecido com o docker ps, com a diferença de lhe trazer apenas informações sobre os container que fazem parte de um serviço criado, você pode ainda utilizar filtros para ter um retorno mais simplificado.
  6. docker service scale: Com o scale é possível realizar o escalonamento de seu serviço, é possível você aumentar a quantidade de containers que atenderão o seu serviço.
  7. docker service update: Comando que lhe permite realizar modificações no serviço criado, através dele é possível modificar informações sobre quantidade de memória, cpu, dentre muitas outras coisas em seu serviço.

Tudo certo com a teoria? Então vamos a prática :), nosso problema: Queremos criar uma stack para nosso ElasticSearch, nosso objetivo é escalar esse ambiente quantas vezes eu quiser e atualiza-lo de forma consistente.

Primeiro temos que criar nosso service:

docker service create --replicas 1 --update-delay 10s --update-parallelism 1 --name elasticsearch elasticsearch

O que isso quer dizer? Vamos lá:

  • Replicas – Número de containers que eu quero criar nesse momento, deve ser no mínimo um (por motivos óbvios);
  • Update-delay – Quando for realizado uma procedimento de atualização do ambiente, qual será a cadência de atualização dos containers.
  • Update-parallelism – Quantidade de containers que desejamos atualizar por vez
  • Name – Nome do serviço e por último a imagem que vamos utilizar para esse serviço.

O retorno do comando será algo parecido com isso:

docker-service1

Certo, meu serviço está criado, como escalono ele agora? Fácil, olha o print 🙂

docker-service2

Note que para escalar, basta executar o comando: docker service scale $(seu-servico)=numero. Agora vamos atualizar o nosso ambiente, certo? Muito fácil, basta executar o comando: docker service update, com ele é possível modificar diversos atributos do serviço, como por exemplo: Portas publicadas, limites de recursos, número de replicas, imagem, politica de escalonamento, etc.

Em nosso exemplo vamos atualizar a imagem que nosso serviço utiliza, veja que quando criamos, a imagem utilizada era a elasticsearch:latest, agora queremos testar a última versão do elasticsearch, que está em alpha (no dia da criação desse post) que é a 5.0, para isso basta executar: docker service update –image elasticsearch:5.0 elasticsearch, veja o que aconteceu:

docker-service3

Veja que nosso serviço não foi atualizado de uma vez só, esse processo foi sendo realizado conforme os containers iam sendo atualizados, isso devido a nossa politica de update que definimos na criação do serviço. Com o update você pode realizar diversas ações, veja mais em: docker service update –help, ele lhe mostrará todas as opções disponíveis.

Como removemos um serviço? Bem, você já deve ter imaginado como: docker service rm nome_do_servico.

Ahh, você se lembra que falamos aqui que no Docker 1.12 era possível criar um serviço distribuído dentro Swarm e acessá-lo de qualquer lugar? Pois bem, quando você criar um serviço você pode especificar qual será a porta publica dele, no exemplo acima não utilizamos isso, mas você pode definir (através do parâmetro -p) que a porta 8080 seja a porta de seu serviço, com isso todo o trafego enviado para a porta 8080 nos ips de seus nós do cluster de Swarm será redirecionado para os containers que atendam esse serviço. Lembrando que para você criar um serviço distribuído é necessário ter um cluster de Swarm ativo.

Gostaram do post? Deixe seu feedback e novamente, nos ajudem divulgando o blog.

Grande abraço!

 

Docker e Jenkins para build de aplicações

5 Comments

Olá pessoal,

Hoje queremos demonstrar para vocês como podemos utilizar Docker e Jenkins para o build de aplicações de forma rápida e fácil, primeiro vamos entender como é o ambiente de diversas empresas de TI hoje e você que estiver lendo este post possivelmente estará se identificando com isso.

Hoje diversas empresas utilizam a ferramenta Jenkins para build e deploy de aplicações, muitas vezes (Se não forem todas) essa maquina de Jenkins é compartilhada entre diversos times, Java, PHP, Python, Rails e NodeJS acabam utilizando. O que deixa essa máquina com ferramentas desnecessárias para as equipes, sobrecarregando o sistema e qualquer problema acaba parando todas as equipes.

Porém existem alguns casos mais organizados que a maquina onde irá ocorrer o build será uma máquina para cada equipe, o que torna o processo um pouco melhor, porém sempre que sair uma nova versões de softwares alguém precisa ficar atualizando essa máquina, o que pode acabar por muitas vezes impactando em prazos do projeto.

Então existe o que acreditamos que seja a melhor solução que seria a utilização de containers para o build de suas aplicações. mas porque usar containers?

  • Só dependências para aquela aplicação
  • Fácil manutenção
  • Ambiente de produção e local iguais.
  • Escabilidade

Então visto o porque que devemos utilizar containers para realizar o build, vamos mostrar como podemos utilizar essas duas ferramentas em sincronia.

Primeiramente vamos até as configurações do nosso repositório e clicar em “WebHooks & Services:4

Vamos até “Add Service” e adicionar o “Jenkins (Github Plugin)”
5
Agora em nosso servidor com Docker instalado, vamos iniciar o container que terá o Jenkins Master instalado.

############# SERVIDOR1 #################
docker run -p 8080:8080 -p 50000:50000 -d jenkins

Iniciado, agora vamos até o nosso browser e digitar http://ipserver:8080 e vamos fazer a configuração base do Jenkins.

1

Para pegar a senha você irá executar

docker exec idcontainer cat /var/jenkins_home/secrets/initialAdminPassword

Na pŕoxima página você pode escolher a opção de usar os plugins recomendados, então depois irá pedir para você criar um usuário.

2

Feito isso agora estamos na página inicial do jenkins.

3

Esse será nosso servidor de Jenkins Master que sera o responsável por avisar e mandar rodar alguns comandos no nosso servidor onde estará o Docker. Para isso, vamos acessar o servidor 2 e realizar a instalação do Jenkins:

############# SERVIDOR2 #################
sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
sudo rpm --import https://jenkins-ci.org/redhat/jenkins-ci.org.key
sudo yum install jenkins -y
sudo yum install java -y 
sudo service jenkins start/stop/restart
sudo chkconfig jenkins on
firewall-cmd --zone=public --add-port=8080/tcp --permanent
firewall-cmd --zone=public --add-service=http --permanent
firewall-cmd --reload
sudo yum install java-1.7.0-openjdk -y

Após realizar a instalação do servidor2, vamos até o nosso servidor de Jenkins Master e adicionar o outro nó nele, colocando o IP e a forma pela qual o agente fosse instalado: Para isso você deve ir até “Gerenciar Jenkins” >> “Gerenciar nós”

6

Após isso você irá clicar em novo nó, colocar o ip desse novo servidor e clicar na opção de “Permanent” e OK. Após isso irá aparecer algo parecido com a tela abaixo então, você tera que fazer download do slave.jar, ir até o outro servidor e executar o comando do java que é mostrado na imagem abaixo, porem com as suas configurações.

7

Feito isso, vamos até a tela da esquerda na opção de configurações e configurar parecido com a imagem abaixo: A parte mais importante dessa tela é a configuração do “rótulo” que é o apelido que vamos dar a esse servidor, e também o “uso” que estamos dizendo que vamos executar esse servidor apenas como jobs.

8

Agora vamos até a página inicial do nosso jenkins e então criar o nosso build. Vamos até “Novo Build”

9

Após selecionar “Novo Build” vamos até a opção de configuração:

10

Vamos colocar o nome do nosso servidor de slave na opção de “Restringe onde este projeto pode ser executado”

11

Abaixo vamos colocar o nosso caminho do “GitHub” e também de qual branch irá baixar o código.

12

Vamos marcar  a opção de “Build when a change is pushed to github” e também a opção de quanto em quanto tempo vamos ir consultar o nosso “SCM”.

14

Em nosso ultimo passo, vamos colocar os comandos que iremos executar em nosso servidor. Vamos criar uma imagem a partir do Dockerfile que está em nosso GitHub e após isso vamos iniciar o container com essa imagem.

15

Então por hoje era isso pessoal, espero que tenham gostado do post e gostaríamos que vocês interagissem através de comentários propondo novos posts e arquiteturas que vocês gostariam que a gente fizesse com Docker. Em breve teremos mais posts nesse estilo.

Obrigado!

Referências: https://www.docker.com/sites/default/files/RA_CI%20with%20Docker_08.25.2015.pdf

: https://jenkins.io/solutions/docker/

: https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins

Escalando o MySQL com Docker e MaxScale

Leave a comment

Oi Pessoal,

Não, hoje o post não é nosso :). Mas queremos divulgar um ótimo conteúdo criado por um de nossos parceiros, o MySQLBox, que é um dos maiores blogs sobre o SGBD MySQL e é mantido por um grande amigo nosso.

Então não deixe de ler o post: Escalando Mysql com Docker e Maxscale e veja como o Docker pode ajudar a escalar seu ambiente de banco de dados de forma fácil e rápida.

Grande abraço!

Docker Machine

6 Comments

Olá!

Umas das ferramentas mais interessantes do ecossistema Docker, e que é mantido pela própria Docker é o Docker Machine, com ele é possível você fazer deploy de seu ambiente na infra-estrutura que desejar, você pode portar sua aplicação do seu notebook para AWS, Digital Ocean, ou o que for. Veja no vídeo um exemplo prático disso:

Você pode ainda integrar com Docker Compose, e automatizar ainda mais essas tarefas, legal né? Espero que tenham gostado, tendo dúvidas nos contatem, estamos dispostos a sanar todas as dúvidas.

Abraço!

Melhores praticas Dockerfile

3 Comments

Muitas pessoas pensam que construir uma imagem é apenas iniciar um container, realizar algumas alterações e assim realizar o commit da mesma. Ou até mesmo escrever um Dockerfile do jeito que quiser e pronto a imagem está pronta e agora é só colocar em produção. Com algumas técnicas na criação do Dockerfile é possível fazer o seu Build passar de 10 minutos para apenas 10 segundos.

Baseado nas dúvidas que o pessoal acaba tendo no dia a dia resolvemos a equipe do mundodocker.com.br resolveu dar algumas dicas referentes a como deixar o seu Dockerfile o mais otimizado possível.

Use o .dockerignore

O .dockerignore possui a mesma funcionalidade do .gitignore, fazendo com que você possa gerar a sua imagem excluindo alguns arquivos que estejam no diretório do seu Dockerfile.

Não instale pacotes desnecessários

Para reduzir o tamanho de sua imagem e o tempo de construção dela, não instale pacotes que você acha que poderá usar um dia, instale apenas o necessário para que sua aplicação possa rodar de forma integra e segura. Muitas vezes pacotes desnecessários possuem uma série de dependências o que pode acarretar um tempo maior de construção da imagem.

Construa o minimo de camadas possíveis

Cada comando “RUN”, “COPY”, “ADD” acaba adicionando uma camada a mais em sua imagem, então quanto mais comandos conseguir executar de uma vez só melhor.

Use tags

Quando você for realizar o docker build utilize o parâmetro -t para que você possa organizar melhor sua estrutura de imagens e no desenvolvimento ficará mais fácil para saber o qual release essa imagem representa.
docker build . -t php:56-0-4

apt-get

Nunca utilize apenas apt-get update utilize sempre apt-get update && apt-get install. Por exemplo você tem o seguinte Dockerfile:


FROM UBUNTU
apt-get update
apt-get install wget

Você executa isso e depois de algum tempo você altera o Dockerfile e coloca assim:


FROM UBUNTU
apt-get update
apt-get install wget vim

Ao executar o build o Docker não irá executar o apt-get update fazendo com que o vim esteja desatualizado no momento da instalação.

Nunca mapear a porta pública no Dockerfile

Você NUNCA deve mapear a porta do seu host em seu Dockerfile:


#Não faça isso
EXPOSE 80:8080

#Faça isso
EXPOSE 80

Deixe sempre o que mais será alterado para o final

Como o Dockerfile trabalha com camadas, então você sempre devera deixar para o final a parte que é mais dinâmica em seu Dockerfile, pois ao rodar o seu Dockerfile pela segunda vez, o Docker irá olhar onde foi modificado o arquivo e irá refazer as camadas abaixo da modificação. Então se você tem uma parte que demora algum tempo e você não irá precisar modificar ela constantemente então é melhor você deixar essa parte no topo.


FROM ubuntu
RUN apt-get install -y nodejs
RUN mkdir /var/www
ADD app.js /var/www/app.js


FROM ubuntu
RUN apt-get install -y nodejs
RUN mkdir /var/www
ADD package.json /var/www/package.json

Nessa alteração de Dockerfile o Docker irá apenas refazer a camada do ADD e não irá baixar novamente o node e criar o diretorio /var/www. Assim economizando tempo de Build e também tamanho em disco.

Então tá pessoal espero que tenham gostado desse post referente a dicas de como criar melhor o seu Dockerfile. Qualquer dúvida é só deixar um comentário que iremos reponder o mais rápido possível.

Kubernete parte III

Leave a comment

Olá pessoal,

 

Depois de algum tempo sem falar sobre Kubernetes hoje vamos mostrar como podemos criar um ambiente altamente disponível de servidores web.

Conforme comentado nos posts anteriores, podemos criar um service Web e dentro desse service eu posso ter milhões de containers, onde o Kubernetes fará toda a parte de Balanceamento de carga com o que chamamos de Replication Controller.

Vamos criar então o Replication Controller:

 

vim web-rc.yml

apiVersion: v1
kind: ReplicationController 
metadata:
 name: web-controller
spec:
 replicas: 2
 selector:
   name: nginx
 template:
   metadata:
     labels:
       name: nginx
   spec:
     containers:
       - name: nginx
         image: nginx
         ports:
           - containerPort: 80

kind: É o tipo de objeto que o Kubernetes ira criar, nesse caso ele vai criar

Replicas: Quantos pods dessa imagem sempre deve existir, caso exista um número menor que o indicado, o Kubernetes irá criar outros pods até chegar ao número determinado em replicas.

 

Para criar o Replication Controller execute:

kubectl create -f web-rc.yml

 

Você poderá ver RC criado com o comando:

kubectl get replicationcontrollers

 

Agora vamos criar o Service que é aquele que faz com que o usuário consiga criar a aplicação:

 

vim web-service.yml

kind: Service
apiVersion: v1
metadata:
  name: web-service
spec:
  selector:
    name: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
kubectl create -f web-service.yml

Feito isso você pode executar o comando abaixo e verá que existe 2 pods de Nginx rodand:

kubectl get pods

Com tudo isso pronto você pode pegar e testar executando um curl no ip do seu servidor, no meu caso estou executando a partir do minion1, então vou acessar o minion2 e executar:

curl -qa http://seuip

E a página inicial do nginx será mostrada, você pode pegar e parar um pod e notará que o Kubernetes irá criar outro, pois no Replication Controller colocamos como 2 replicas.

Então tá pessoal por hoje era só, continue ligado em nosso canal e em breve estaremos fazendo um vídeo mostrando mais sobre o Kubernetes.

Docker e .Net

5 Comments

Oi pessoal!

Rodar .Net em container? SIM!! é possível, e vamos mostrar hoje como você pode fazer esse ambiente funcionar e testar sua aplicação. Bem, antes de tudo você precisa entender todo o movimento que a Microsoft vem fazendo para que sua linguagem de programação torne-se cada vez mais utilizada pelos desenvolvedores, para isso eles repensaram tudo que já fizeram, e lançaram uma versão do .Net com features muito parecidas como as encontradas em node e ruby on rails, e a batizaram de ASP.NET Core. Conceitualmente o ASP.NET Core é uma plataforma open source de desenvolvimento leve e eficiente para aplicação escritas em .net, veja abaixo uma lista dos principais pontos do asp.net Core:

  • Suporte integrado para criação e utilização de pacotes NuGet;
  • Pipeline de request mais leve e modular;
  • Ambiente configurado para cloud;
  • Suporte a injeção de dependência;
  • Novas ferramentas que facilitam o desenvolvimento web;
  • Capacidade de hospedar o processo no IIS ou em um Self-Host;
  • Suporte para desenvolvimento de aplicação asp.net em Windows, Linux e Mac;
  • Open Source e com comunidade ativa;
  • Todos os pacotes do .Net no NuGet;
  • .Net Core construido com suporte a versionamento side-by-side;
  • Uma unica Stack para Web UI e Web APIs;

Por que a Microsoft vem tomando esse rumo? Simples, para atrair mais pessoas para o seu produto, tendo em vista que as principais linguagens, ou as que mais crescem tem nativas todas essas features, a melhor alternativa para a Microsoft foi mudar a abordagem e atrair pessoas para melhorar seu produto/serviço e claro, isso consolida ainda mais o Windows Azure, fazendo com o desenvolvimento e deploy de Apps em .net torne-se menos doloroso.

Vamos ver isso rodando em um container?

Simples, tendo o Docker instalado (em qualquer host, seja ele Windows, Linux ou Mac), execute:

docker run -it microsoft/dotnet:latest

Dentro do container, você deve criar sua aplicação, de forma parecida com o que ocorre com o ruby on rails, para isso o .net core disponibiliza um utilitário chamado: dotnet, veja:

mkdir app
cd app
dotnet new

O comando dotnet new criará toda a estrutura necessária para rodar uma aplicação hello world básica, ele criará um arquivo chamado project.json com o seguinte código:

{
 "version": "1.0.0-*",
 "compilationOptions": {
 "emitEntryPoint": true
 },
 "dependencies": {
 "Microsoft.NETCore.Runtime": "1.0.1-beta-*",
 "System.IO": "4.0.11-beta-*",
 "System.Console": "4.0.0-beta-*",
 "System.Runtime": "4.0.21-beta-*"
 },
 "frameworks": {
 "dnxcore50": { }
 }
}

Esse arquivo project.json contém as informações de dependência que sua aplicação precisará para rodar, é fundamental que você informe nesse aquivo todos os pacotes que necessita. Nessa mesma estrutura será criado um arquivo chamado Program.cs com este código:

using System;
namespace ConsoleApplication
{
 public class Program
 {
 public static void Main(string[] args)
 {
 Console.WriteLine("Hello World!");
 }
 }
}

Agora basta realizar a instalação das dependências:

dotnet restore

E pronto, sua aplicação estará pronta para rodar, basta executar o comando:

dotnet run

 Fácil certo? E é possível deixar ainda mais fácil, para isso, basta criar Dockerfile e gerar uma imagem com esse ambiente:

FROM microsoft/dotnet:latest
RUN mkdir /app
WORKDIR /app
RUN ["dotnet", "new"]
RUN ["dotnet", "restore"] 
ENTRYPOINT ["dotnet", "run"]

Agora crie a imagem: docker build -t myapp .

E crie um container baseado nessa nova imagem: docker run -d myapp , quer ver o que retornou nessa execução? docker logs iddocontainer, ele deverá retornar algo desse tipo: Hello World!.

É claro que você pode aprimorar esse ambiente, principalmente se quiser rodar uma aplicação web, mas esse ambiente básico já serve como inicio para seus testes ;).

Gostou? Então nos ajude divulgando o mundodocker.com.br, grande abraço!