Calma! Calma! Calma! Tudo será explicado, Docker, Docker Compose e os poderes dessa maravilhosa ferramenta.

Existem diversos artigos disponíveis na interwebs atualmente, os mais completos e bem explicados estão disponíveis em inglês e em uma linguagem extremamente técnica, pensando nisso resolvi escrever um artigo em um formato mais “amigável” para que independente do nível do profissional seja compreensível.

Bom, vamos começar pelo começo. Vamos entender primeiro qual problema o Docker se propõem a resolver.

A maioria de nós já nos deparamos com a famosa e inesquecível frase: “Na minha máquina funciona!”

❌ PROBLEMA: Diversos desenvolvedores trabalhando na construção de uma aplicação, onde cada máquina tem uma configuração de ambiente diferente, gerando uma grande variabilidade de ambiente de desenvolvimento e produção. O que acaba gerando aquela famosa frase. Logo o salvador da pátria resolve esses problemas.

🆙 SOLUÇÃO: Docker, sistema de containers que abstrai toda a responsabilidade de configuração de ambiente e dependências de projeto para dentro do que chamamos de container (ambiente isolado que contém somente o necessário para o serviço entrar em funcionamento). Permitindo o alto desacoplamento de aplicações e orquestração.

💻 EXEMPLO: Imaginemos que desejamos adicionar na máquina do desenvolvedor o SQL Server e também adicionar no servidores de desenvolvimento e de produção com as mesma configurações, para garantir que tudo esteja conforme definido pelo o arquiteto.

Na abordagem tradicional seria necessário configurar não somente todas as máquinas da equipe de desenvolvimento como os do servidores e garantir que todas estejam idênticas. Isso é um esforço burro e desnecessário quando não usada a abordagem de containers.

Na abordagem com o docker é possível executar a mesma atividade com muito mais agilidade, segurança e facilidade. Sendo assim uma vez configurado o container basta usar ele em qualquer lugar, independente de configurações ou SO (Sistema Operacional). Subir e derrubar um container é tão simples quanto desligar a luz do seu quarto.

Agora vamos para a prática!

Nesse passo a passo iremos criar uma imagem docker, adicionar ela na nossa conta do DockerHub, criar um container e rodar o container. Para isso vamos usar o NGNIX, servidor web para exemplificação desse tutorial.

1. Se não possui o docker instalado na máquina, será necessário instalar. Clique aqui.
2. Se não possui conta no DockerHub será necessário também criar uma. Clique aqui.
3. Abra seu editor de código e crie duas pastas “configs” e “www”.
4. Dentro da pasta configs crie um arquivo chamado “default.conf”. Ele será o arquivo de configuração de hosts do Ngnix.
5. Dentro da pasta www crie um arquivo chamado “index.html”. Ele será a página a ser exibida quando acessado a aplicação.
6. Fora das pastas crie um arquivo com o nome de Dockerfile.

A estrutura de diretório deverá ser a seguinte:

7. No arquivo default.conf vamos adicionar a seguinte configuração abaixo:

8. Dentro do arquivo index.html vamos adicionar uma estrutura básica do HTML.

9. Dentro do arquivo Dockerfile vamos adicionar o seguinte código:

FROM: Indica qual imagem base vamos usar. No caso a oficial do NGNIX na versão lastet.

COPY: Copia os arquivos de configuração que personalizamos para dentro da imagem que iremos construir.

VOLUME: Os diretórios que serão declarados para a persistência dos dados gerados e usados no container.

Agora vamos ao nosso terminal do nosso projeto e vamos digitar o seguinte comando:

docker build -t <nomeusuario>/ngnix -t <nomeusuario>/ngnix:1.0.0 .

no lugar de <nomeusuario> troque pelo nome do seu repositório no Dockerhub

Ex: docker build -t gabrielroque/ngnix -t gabrielroque/ngnix:1.0.0 .

Contextualizando…

Basicamente estamos dizendo ao docker que desejamos construir uma imagem no repositório com o nome de gabrielroque/ngnix.

O “-t” significa que desejamos adicionar uma tag nessa imagem, no caso vamos usar a 1.0.0.

O “.”significa que desejamos criar a imagem no diretório atual.

Vamos enviar nossa imagem para o nosso repositório com os seguintes comandos. Porém caso não tenha realizado o login, execute os dois comandos. Caso já esteja logado, execute apenas o segundo comando.

$ docker login

$ docker push <nomeusuario>/ngnix:1.0.0

O resultado deverá ser semelhante a este:

Maravilha! Vamos colocar o container para rodar.

docker run --name my-ngnix -p 80:80 -d <nomeusuario>/ngnix:1.0.0

Estamos dizendo, docker:

• Constrói um container com nome de my-ngnix. “--name”;
• Expõem a porta 80 de dentro do container para a porta 80 da máquina em localhost . “-p 80:80”;
• E rode em backgroud “-d” tendo como referencia a seguinte imagem. “<nomeusuario>/ngnix”.

Digite localhost na url de seu navegador, o resultado deverá ser este:

Congratulations!

Agora vem a seguinte pergunta❗

“Certo, muito útil o Docker, porém como é possível orquestrar diversos containers para trabalharem em conjunto de uma forma simples e organizada?”

Nós temos o que chamamos de DOCKER COMPOSE.

O Docker Compose irá nos facilitar na manipulação de múltiplos containers, permitindo que vários deles interajam entre si. Assim como diversas abstrações que facilitam na hora da construção da arquitetura de uma aplicação.

No site oficial do Docker possui uma documentação completa que descreve tudo que é possível realizar com o Docker Compose.

Vamos ao trabalho!

Iremos criar a seguinte estrutura de diretório semelhante a anterior, porém com pequenas diferenças:

O arquivo docker-compose.yml é o arquivo raiz de leitura do Docker Compose, nele iremos construir toda a arquitetura da aplicação.

Na pasta build ficará o arquivo de “receita” (Dockerfile) de uma versão do php que será utilizada. A pasta www já foi explicado seu propósito anteriormente então vamos em frente.

1. Dentro do arquivo docker-compose.yml vamos anexar o seguinte bloco de código:

Neste arquivo no parâmetro services iremos declarar os serviços e configurações de cada container.

• web: Container com o serviço do NGNIX.
• php: Container com o serviço do PHP-FPM.
• db: Container com o serviço do nosso SGBD MySQL.

Dentro de cada serviço temos alguns parâmetros que podemos declarar.

• image: indicamos qual imagem base será utilizada para a construção do container.
• container_name: indica um apelido para o container, facilitar a identificação.
• depends_on: indicamos que um serviço A depende de um serviço B.

Ex: No container web, ele possui uma dependência do container php, logo o mesmo só irá iniciar após o serviço de php está operante.

• ports: Aponta qual porta de dentro do container deve ser espelhada para fora dele e de acesso externo ao container.
• volumes: Os diretórios que serão declarados para a persistência dos dados gerados e usados no container.
• environment: são as variáveis de ambiente do serviço.

Ex: MYSQL_ROOT_PASSWORD: docker337. Basicamente está sendo declarado qual deverá ser a senha do usuário root do nosso banco de dados.

• build: Declara uma necessidade de build de uma imagem para com o objetivo da construção do container e o serviço operante.

Estamos dizendo que o serviço chamado de php deverá realizar um build de uma imagem antes da construção do container, logo o contexto de localização da nossa receita se encontra em uma pasta chamada de build com o nome de Dockerfile.

Observação importante!

Sempre quando temos o “:” estamos dizendo ao docker o seguinte:

Aqui fora do container : Dentro do container

Ou seja, em volumes dizemos que tudo que está dentro de ./www deverá ser espelhado para a pasta dentro do container de /var/www/html.

2. Vamos para a configuração do NGNIX, insira o seguinte trecho de código no arquivo default.conf

3. Insira qualquer conteúdo ou o trecho de código abaixo no arquivo index.php

4. Vamos adicionar a receita “Dockerfile” da versão do nosso php com algumas dependências. Dentro do arquivo Dockerfile insira o seguinte código:

Agora vamos a parte “mais difícil,” colocar a o nossa aplicação em operação com o seguinte comando:

$ docker-compose up -d

$ docker-compose ps

Com o comando docker-compose up -d vamos rodar os serviços em background, liberando o terminal.

O comando docker-compose ps deverá listar os 3 containers que criamos para a nossa aplicação. Para derrubar todos os serviços, basta executar o comando docker-compose down .

4. Agora vamos acessar http://localhost:8000.

O resultado esperado deverá ser semelhante a este:

Pronto, finalizamos a construção dos nossos containers e todos estão operantes.

Aqui segue links para a lista de comandos mais utilizados e um repositório no GitHub com o código apresentado neste artigo.

Lista de comandos mais utilizados

• Docker
• Docker Compose

GitHub

gabriel-roque/docker-medium

Obrigado pela leitura e bons estudos! 😉

Revisado por:

eduardaalves_

Referencias Bibliográficas

• NGNIX Docs
• Docker Compose Docs
• MySQL Image Docker
• Docker Compose do Linux na web

Este artigo visa explicar de forma simples e direta algumas das siglas e termos das quais estão presentes na vida da maioria dos profissionais de TI, especialmente aqueles que trabalham ou pretendem trabalhar com desenvolvimento de software.

Antes de mais nada, este artigo se embase em um compilado de conteúdo já se encontram na web das quais estão disponíveis no rodapé do artigo.

O artigo está enumerado em ordem de maior para menor em grau de relevância do que acredito ser de suma importância o entendimento.

1. SOA

Trata-se de um arquitetura orientada a serviços.

Ex: Certo cliente vai a padaria, um padeiro o fornece um serviço, no contexto seria fornecimento do pão. Quando a operadora de caixa atende ao cliente ela esta fornecendo um atendimento.

SOA esta ligada intimamente a fornecimento de serviços.

Resumo: Em um contexto de arquitetura de software pode-se compreender em aplicações que deverão ser fornecidas ou disponibilizadas na forma de serviços.

2. Web Service

Nada mais nada menos do que uma solução utilizada para na integração e comunicação entre sistemas.

Em outras palavras, e uma solução que possibilita a comunicação entre aplicações que fazem o uso de diversas tecnologias das quais se comunicam em um “linguagem universal”, nossos queridos JSON e XML.

3. JSON

Podemos apelidar como uma “linguagem universal”. JSON significa Javascript Object Notation, trata-se de uma estrutura chave-valor que possibilita estruturar as informações de forma simples, compacta e de fácil leitura. Os navegadores dão suporte a leitura de JSON justamente para a troca de informações em web services.

Formato de notação Javascript em chave-valor para trocar de informações em web services.

Importante ressaltar que o JSON não é exclusivamente utilizado na arquitetura cliente-servidor.

4. XML

XML significa Extensible Markup Language, trata-se de uma linguagem de marcação, sintaxe semelhante a HTML. O surgimento dele é anterior ao JSON.

Surgimento:

• XML </1996>
• JSON { 2002 }

Trata-se um formato de linguagem de marcação para troca de informações em web services.

XML no ano atual de 2019, é utilizado ainda por muitos serviços para troca de informações, porém cabe uma ressalva, em sua grande maioria dos web services tem adotado o padrão JSON, justamente pela suas vantagens comparado ao XML, dentre elas, tamanho, semântica e sintaxe.

5. Microservices

Tudo que já explicamos está voltado para provimento de serviços. Microservices não diferentemente disso, podemos conceituar da seguinte forma:

Arquitetura de software composta por módulos ou coleção de serviços, ligeiramente acoplados.

Ex: Você não consegue remover o açúcar da coca-cola, porém se colocado um gelo na bebida e tentar remover o gelo, será possível. Logo o açúcar é altamente acoplado, enquanto o gelo e baixamente acoplado.

O açúcar é um módulo do serviço não desacoplável enquanto o gelo é totalmente desacoplável, a coca-cola seria sua aplicação por completa.

Importante ressaltar as vantagens de se utilizar tal arquitetura:

• Possibilidade de entregas incrementais de módulos da aplicação;
• Rápido acoplamento e desacoplamento de módulos;
• Evolução em forma de pilha dos serviços e maior escalabilidade;
• Menor impacto na aplicação como um todo, na falha do provimento de algum dos serviços.

A ideia do micro serviço é dividir pra conquistar.

6. Métodos HTTP

Este é um tópico que daria um artigo completo. Porém eu vou ajudar a mastigar esse assunto aqui.

De acordo com a rede MDN (Rede de Desenvolvedores da Mozilla)

O protocolo HTTP define um conjunto de métodos de requisição responsáveis por indicar a ação a ser executada para um dado recurso. Embora esses métodos possam ser descritos como substantivos, eles também são comumente referenciados como HTTP Verbs (Verbos HTTP).

HTTP (Hypertext Transfer Protocol) ou Protocolo de Transferência de Hiper Texto.

De forma resumida o HTTP, prove em seu protocolo ao que chamamos de verbos, cada verbo tem seu objetivo e serve para uma determinada tarefa.

Segue a lista com os métodos mais comuns e uma breve descrição:

• GET

Essa é a requisição mais comum de todas. Através dessa requisição nós pedimos a representação de um recurso: que pode ser um arquivo HTML, XML, JSON, etc.

• POST

O método POST é utilizado quando queremos criar um recurso. Quando usamos POST, os dados vão no corpo da requisição e não na URI.

• PUT

Requisita que um recurso seja “guardado”. Se o recurso já existir, ele deve ser atualizado. Em caso de não existir, pode ser criado.

• PATCH

Semelhante ao PUT, porém serve para atualizar partes de um recurso, e não o recurso todo.

Também contamos com o STATUS CODE de cada requisição realizada com alguns do métodos HTTP. A lista de código é muito maior dos que apresentado na imagem.

7. REST

Gênio, bilionário, playboy e filantropo! Apresento-lhes REST.

Representational State Transfer ou REST, não é de comer e nem muito menos de passar no cabelo….não é uma tecnologia, um framework nem tampouco resolução de todos os problemas. Poxa então o que sobrou?!

REST trata-se de uma coleção de boas práticas, princípios e regras a serem adotadas afim de beneficiar as aplicações dentro dos padrões da web.

• Utilização correta dos códigos HTTP;
• URI’s legíveis;
• Utilização dos métodos HTTP para manipulação dos recursos;
• Não uso de dados de autenticação/autorização em sessão;
• Comunicação Stateless;
• HATEOAS (Hypermedia As The Engine Of Application State);
• Suporte diferentes representações (HTML, XML, JSON);
• Autenticadores como OAUTH ou JWT (JSON Web Token)

Não se resume em apenas nestes tópicos, mas podemos levar em consideração com os principais para este artigo em sua forma resumida. Iremos abordar REST mais profundamente em outro artigo separado deste.

REST que foi descrito por Roy Fielding, em sua tese de doutorado do qual foi adotado como evolução arquitetural do protocolo HTTP e amplamente adotado pelos padrões da web atual.

8. API

Interface de Programação de Aplicativos no inglês (Application Programming Interface).

Trata-se de um conjunto de padrões de programação em sua interoperabilidade, permitindo comunicação com diversos aplicativos sem a necessidade do conhecimento de fato da implementação real da aplicação.

Ex: No site da minha empresa desejo ter um mapa de todas as filias utilizando a API do Google Maps, do qual é possível a integração com a app sem a necessidade de conhecer os detalhes de sua implementação para que seja possível a comunicação para a construção dos mapas em meu site.

Também podemos ouvir falar de API RESTful, trata-se de uma interface de aplicativo que aplica todos os princípios previstos em sua totalidade pelo REST no provimento da API. O que pode ser encontrado e definido como “The Glory of REST”

9. FRAMEWORK

É um conjunto de ferramentas , bibliotecas e plugins, com o objetivo de agilizar o processo de desenvolvimento de software.

Ex: Imagine que você tem várias caixas pequenas separadas com todos os seus brinquedos, todos vez que vai para cada do seu primo você deseja levar todos eles, porém são muitas caixas para ficar carregando todas as vezes. Então sua mãe decide colocar todos os seus brinquedos dentro de uma caixa maior, logo todas as vezes que desejar ir a casa de um amigo ou de seu primo, basta levar a caixa maior, que contém já todos os seus brinquedos.

Assim é a ideia de um Framework, aglomerar um conjunto de ferramentas em um único PACOTÃO central.

10. MVC

É um padrão de arquitetura de software divido em 3 camadas.

• Model

É a camada responsável pela persistência e manipulação dos dados.

• View

Camada de apresentação final ao usuário, onde ocorre a interação com o usuário, podendo ser sua interface.

• Controller

Camada de recebimento de requisições, chamadas e direcionamento dos serviços requisitados pelo usuário.

O diálogo das camadas

View: Fala Controller ! O usuário acabou de pedir para acessar o Facebook ! Pega os dados de login dele ai. Controller: Blz. Já te mando a resposta. Ai model, meu parceiro, toma esses dados de login e verifica se ele loga. Model: Os dados são válidos. Mandando a resposta de login. Controller: Blz. View, o usuário informou os dados corretos. Vou mandar pra vc os dados dele e você carrega a página de perfil. View: Vlw. Mostrando ao usuário…

Nota: os próximos trés tópicos correlacionam entre si, os compreenda como um todo.

11. SOAP

SOAP (Simple Object Access Protocol), de forma resumida é um protocolo baseado em XML para para troca de informações em ambiente distribuídos e está ligado diretamente com o conceito de interoperabilidade.

Interoperabilidade: Capacidade de um sistema de se comunicar de forma transparente com outro sistema.

Caberia um artigo completo explicando as especificidades sobre SOAP, porém não é o objetivo deste artigo esta abordagem. Para os mais interessados no assunto saiba mais aqui.

12. WSDL

WSDL (Web Services Description Language) o próprio nome já diz quase tudo. Beleza! Próximo! 📣………… Não tão rápido assim.

É uma tecnologia que descreve e padroniza a interface de comunicação de um Web Service que faz uso do SOAP, através de formato XML.

Para não ficar no campo do abstrato, cabe aqui um exemplo.

Mais detalhes na apresentação de Natália dos Santos aqui.

Ex: Como se fosse um contrato onde diz a forma como um cliente deve me comunicar com determinado Serviço Web. Entenda por cliente, seu navegador.

Por meio de um WSDL informa ao cliente como cada serviço em um end-point deve ser invocado: quais os parâmetros e tipo de dados de cada end-point é esperado, e qual o tipo de dado do retorno será enviado como resposta.

13. UDDI

O que precisamos compreender sobre UDDI no espoco deste artigo é um repositório de registros, onde podemos publicar ou encontrar Web Services já registrados.

Mas por qual motivo?

Você pode, naturalmente, oferecer um web service sem registrá-lo na UDDI, assim como você pode abrir um negócio no porão da sua casa e contar com a propaganda boca a boca, mas se você quiser alcançar um mercado significativo, você precisará do UDDI, assim seus clientes poderão encontrá-lo.

Mais informações sobre UDDI.

Conclusão

O mundo da tecnologia avança muito rapidamente, logo devemos está rotineiramente nos atualizando. É um artigo voltado para profissionais em formação inicial, no início de carreira. Talvez um especialista já esteja calejado de saber deste conceitos. Porém é de suma importância para os iniciantes a compreensão destes termos.

Vale uma dica: Não se assuste pela quantidade imensa de conhecimento presente na área de tecnologia.

Bons estudos! 😉

Referencias Bibliográficas:

• Boas práticas REST
• Métodos HTTP
• Arquitetura MVC
• WSDL, SOAP, UDDI