Docker e Jenkins para build de aplicações

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

Melhores praticas Dockerfile

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.

ProjectAtomic.io

Olá pessoal,

Com o passar dos anos as tecnologias vem evoluindo cada vez mais rápido, surgem novos conceitos porém muitos morrem e poucos acabam se tornando tendência. No passado muito se falou sobre “Máquinas Virtuais” muitas empresas apareceram no mercado de virtualização porém apenas algumas se destacaram que é o caso de Microsoft, VMWare e Oracle.

Agora chega a hora da tendência de containers (Sim, LXC existe há um grande tempo já) que cada vez mais vem se popularizando e com isso surgem diversas empresas no mercado oferecendo integrações, plataformas, contentores e entre outros produtos. Com essa gama de ofertas decidi realizar uma série mostrando as empresas que acreditamos que serão as grandes donas do mercado de containers nos próximos anos.

O ProjectAtomic: É um sistema operacional desenvolvido pela RedHat, foi projetado para a execução de aplicações em containers docker. O Project Atomic depende de vários projetos de código aberto as várias distribuições Linux específicas. A comunidade Atomic vai trabalhar para o desenvolvimento do projeto atômico de forma inclusiva, contribuindo para os projetos upstream relacionados, resolvendo problemas de integração nas diversas distribuições sendo usado e desenvolver as ferramentas de gestão específicas necessárias para atualizações de gestão e de sistema. As principais ferramentas utilizadas foram:

– Docker – Implementação dos aplicativos

– Kubernetes – Orquestração

– rpm-ostree – Atualizações

– systemd – Gerencia de serviços

O Project Atomic possui uma ferramenta Web chamada Cockpit para realizar o gerenciamento de containers e hosts, com o Cockpit você pode:

– Visualizar os recursos utilizado pelos containers.

– Limitar recursos dos containers.

– Iniciar, parar, salvar e realizar o commit dos containers.

– Executar e excluir imagens.

– Administrar o host.

– Configurar serviços no host e outras funcionalidades.
cockpit-screenshot

Exemplo de imagem do Cockpit

Aqui possui o link para o download da imagem do sistema operacional http://www.projectatomic.io/download/

Por hoje era isso, espero que tenham gostado e tendo dúvidas nos avisem, e claro ajudem divulgando o https://mundodocker.com.br

Abraço!

Docker e Travis

Olá pessoal,

Hoje vamos demonstrar como é utilizado o Travis CI juntamento com Docker.

Travis CI é um serviço de integração continua na nuvem que pode ser integrado com repositórios do Github, ele é gratuito para repositórios públicos e pago para repositórios privados. Possui suporte as principais linguagens de programação como: C, PHP, Java, Perl, Ruby, Python, Go, C++, Erlang e etc…

O Travis trabalha da forma que a cada push que é dado para o Github:

  • Travis cria uma máquina virtual onde será excutado o código.
  • Pega o seu código do Github.
  • Faz o deploy da aplicação na máquina que ele criou anteriormente.
  • Executa os testes configurados pelo usuário.
  • Notificar o usuário sobre os processos ocorridos no Travis.

O ciclo de build completo do Travis possuindo 10 passos que podem ser executados, possuindo 3 dos passos como sendo opcional:

  1. Installapt addons (Você pode instalar diversos pacotes como gcc,time,make,etc..)
  2. before_install 
  3. install
  4. before_script
  5. script
  6. after_success or after_failure
  7. OPTIONAL before_deploy
  8. OPTIONAL deploy
  9. OPTIONAL after_deploy
  10. after_script

   Como você pode ver nos passos acima, existem diversas configurações que podem ser feitas dentro do arquivo .yml, o tornando um arquivo gigantesco de configuração, em nosso próximo post sobre DevOPS vamos nos deter a criar um ambiente real e dai sm usar muitas dessas opções.

   Mas como podemos utilizar isso com Docker então? Utilizamos o Travis na parte de criar nossas imagens, para que tenhamos um maior controle sobre nossos deploy e também para que nada de errado ocorra em nosso ambiente de produção. A cada modificação em nossa aplicação que é publicada no Github o Travis nos auxilia para a criação de uma nova imagem onde será executada a aplicação, mantendo a imagem sempre atualizada e também sempre nos notificando quando possui algum erro.

Exemplo do arquivo Travis.yml que é onde é feita a parte de configuração para cada aplicação.

#Diz que os comandos serão executados com sudo
sudo: required
#Qual a linguagem será utilizada
language: ruby

#Diz que o docker será utilzado para ser feito o deploy
services:
  - docker

#Irá rodar todos os comandos abaixo antes de fazer o build da aplicação
before_install:
- docker pull carlad/sinatra
- docker run -d -p 127.0.0.1:80:4567 carlad/sinatra /bin/sh -c "cd /root/sinatra; bundle exec foreman start;"
- docker ps -a
- docker run carlad/sinatra /bin/sh -c "cd /root/sinatra; bundle exec rake test"

#Executara o comando de criação do build
script:
- bundle exec rake test

Pessoal demonstrei aqui apenas um pouco de como podemos utilizar o Travis para a integração com Docker, no próximo post sobre DevOps irei fazer um tutorial mostrando como podemos utilizar Travis na pratica mesmo. Fique ligado em nossos posts e tire suas dúvidas.

Ansible

Olá pessoal,

Hoje vamos falar sobre uma ferramenta que cada vez mais quem trabalha com Docker acaba utilizando que é o Ansible. A primeira vista muitas pessoas acham que ambas ferramentas fazem a mesma coisa, apresentando uma solução para gerenciamento de configurações através de meios diferentes. Na realidade a união das duas ferramentas torna o ambiente de implantações de softwares limpo, confiável e rápido.

Ansible

É uma ferramenta de automatização de tarefas semelhante a Puppet e Chef, porém muito mais poderosa e a queridinha do pessoal DevOps hoje. Com ela é possível fazer o deploy de aplicações, provisionando de servidores, automatizar tarefas, e outras funções.

O Ansible trabalha com arquivos YAML,  o principal arquivo de configuração é chamado de PLAYBOOK onde você coloca todas as tarefas que serão executadas “yum”,”mkdir”,”useradd” e no arquivo .ini você adiciona os servidores onde o Ansible irá executar esse PLAYBOOK. Cada Playbook possui roles que são as informações de provisionamento, após definir as roles você definirá em quais hosts essas roles serão executadas.

Dentro das roles existem as tasks, handlers, variaveis e templates:

       – Tasks: Tarefas de provisionamento que serão executadas

       – Handlers: Tarefas para manipular serviços e arquivos.

       – Templates: Arquivos para serem transformados em configurações dentro das máquinas.

       – Variaveis: Valores que são definidos para serem usados dentro das tasks, handlers e templates

O Ansible é uma ferramenta muito mais simples que seus concorrentes citados anteriormente, já que ele não precisa que seja instalado agents nos servidores na qual ele irá executar.

É possível utilizar Docker e Ansible em conjuntos para resolver duas situações: Implantação de Containers e Criação de Imagens.

Implantação de containers: É possível fazer toda a parte de orquestração, configuração e provisionamento com containers, sem precisar fazer a instalação de agents dentro dos containers

Criação de Imagens:

Exemplo de Playbook:

# Mysql service name for drupal application
mysqlservice: mysqld

# Mysql port for drupal application
mysql_port: 3306

# Database name for the drupal application
dbname: databasename

# Mysql Username for drupal application
dbuser: root  

Exemplo de Configuração do arquivo do Ansible:

[defaults]
inventory = /etc/ansible/inventory
host_key_checking = False
priva_key_file = ~/.sh/id_rsa
callback_plugins   = /opt/ansible-plugins/callbacks
connection_plugins = /opt/ansible-plugins/connections

Então tá pessoal, hoje fizemos apenas uma pequena introdução ao Ansible, em nossos próximos posts estaremos trazendo algo como Jenkins, Travis e também faremos um grande post mostrando como podemos criar um ambiente com Docker, Jenkins e Ansible. Obrigado

Referência: http://docs.ansible.com/ansible/playbooks_intro.html e http://www.ibm.com/developerworks/br/cloud/library/cl-provision-docker-containers-ansible/

Kubernete parte III

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.

Kubernetes parte II

Olá pessoal,

Hoje vamos continuar a demonstração de como podemos utilizar Kubernetes para nos auxiliar na administração de containers. Para conseguirmos realizar todos os procedimento vamos criar uma estrutura com quatro servidores:

  • Node – Master   (CentOS7)
  • Node – Minion1 (CentOS7)
  • Node – Minion2 (CentOS7)
  • Node – Minion3 (CentOS7)

 

Agora vamos instalar alguns componentes em nosso servidor Master.

//Instalando o Kubernetes e o etcd (Serviço de descoberta)
yum install kubernetes etcd -y

// Vamos editar o conf do etcd para liberarmos as portas de acesso a esse serviço. Você vai ver que o arquivo de // conf possui diversas linhas comentadas, vamos tirar o comentário apenas dessas linhas:
vi /etc/etcd/etcd.conf
ETCD_NAME=default
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:2379"
ETCD_ADVERTISE_CLIENT_URLS="http://localhost:2379"

//Agora vamos fazer a configuração da API do Kubernetes
vi /etc/kubernetes/apiserver
KUBE_API_ADDRESS="--address=0.0.0.0"
KUBE_API_PORT="--port=8080"
KUBELET_PORT="--kubelet_port=10250"
KUBE_ETCD_SERVERS="--etcd_servers=http://127.0.0.1:2379"
KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16"
KUBE_ADMISSION_CONTROL="--admission_control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ResourceQuota"
KUBE_API_ARGS=""

//Depois de mexer nos conf da API do Kubernetes e do etcd, vamos dar um start neles agora

 systemctl restart etcd
 systemctl restart kube-apiserver
 systemctl restart kube-controller-manager
 systemctl kube-scheduler

etcdctl mk /atomic.io/network/config '{"Network":"172.17.0.0/16"}'






Agora nos servidores Minions vamos executar os seguintes comandos:

yum -y install flannel kubernetes

//Vamos editar o conf do flannel agora em /etc/sysconfig/flanneld
FLANNEL_ETCD="http://IPMASTER:2379"

//Editando o conf do Kubernetes para conectar na API do master. /etc/kubernetes/config
KUBE_MASTER="--master=http://IPMASTER:8080"

//Agora vamos editar o conf do serviço de cada minion, então em cada servidor você vai colocar o seu respectivo IP. /etc/kubernetes/kubelet
KUBELET_ADDRESS="--address=0.0.0.0"
KUBELET_PORT="--port=10250"
KUBELET_HOSTNAME="--hostname_override=IPMINION"
KUBELET_API_SERVER="--api_servers=http://IPMASTER:8080"
KUBELET_ARGS=""


systemctl restart kube-proxy 
systemctl restart kubelet
systemctl restart docker 
systemctl restart flanneld



Agora no server Master é só executar:

//Você receberá o status de nossos nó
kubectl get nodes

Por hoje era isso pessoal, em nosso próximo post vamos demonstrar como podemos criar aplicações altamente disponíveis dentro do nosso Kubernetes.

Espero ter ajudado, e já sabe, tendo dúvida entre em contato conosco ou deixe sua dúvida no fórum que o pessoal pode te ajudar :), quer nos ajudar? Divulgue o mundodocker.com.br e vamos conversando.

Abraço!

Referência: http://severalnines.com/blog/installing-kubernetes-cluster-minions-centos7-manage-pods-services