Fundamentos: Docker Container

Hello,

Penso que alguns de vós já tem ouvido falar bastante de “buzzwordscontainers, kubernetes, cloud native, e recentemente a VMware introduziu no seu ecossistema novo portefólio de soluções, entre eles Project Pacific que integra kubernetes no vSphere (VMware Cloud Foundation 4), VMware Tanzu (portefólio de soluções para apps modernas). Isso fez o meu alarme soar, reconhecer que esse é o futuro e tenho que aprender, ter essa habilidade no meu arsenal.

Assim começo a série “Evolution” onde vou partilhar toda a minha jornada de aprendizado de containers, orquestração, ferramentas DevOps.

Bom, este é o primeiro poste da série e antes de mergulhar fundo em qualquer tecnologia primeiro é necessário aprender o vocabulário ou terminologia para tornar fácil o aprendizado e formar a base.

Conceitos

Cloud Native: é uma abordagem de desenvolvimento e execução de apps que exploram as vantagens do modelo de computação em nuvem. Encontre mais info sobre cloud native aqui.

Containers: São ambientes isolados que partilham o mesmo SO como um processo isolado, compartilham mesmo kernel do SO, mais ou menos tipo hypervisor tipo 2 mas nesse caso sem necessidade de fazer uso de 1 hypervisor para virtualizar, criar VMs e partilhar os recursos. Os containers fazem uso do Kernel genérico do SO com ajuda de um container runtime, podemos olhar isso como virtualização a nível de SO.

Docker (Software):

O Docker é um conjunto de produtos de plataforma como serviço (PaaS) que usa a virtualização no nível do SO para fornecer software em pacotes chamados contêineres.

Wikipedia

Os containers são uma abstração na camada de aplicativo que empacota código e dependências juntos. Vários containers podem ser executados na mesma máquina e compartilhar o kernel do SO com outros containers, cada um executando como processos isolados no espaço do usuário”.

Docker

Docker é de facto a plataforma de containers mais popular com suporte em nuvens públicas (Amazon EC2, Microsoft Engine, Google Compute Engine, Oracle Cloud Infrastructure).

Build, Ship, and Run Any App, Anywhere – Docker

Componentes

Container Engine: composto por container runtime no nível mais baixo, é o software responsável por executar container (executa Container Image). EX: Docker, RKT, LXC, LXD, CRI-O.

Namespace: camada de isolação dos processos em execução, Limita o que outros processos podem ver.

Control groups (cgroups): agrupa processos e impõe limite na utilização dos recursos, limita recursos (cpu, memory, network) que um processo pode usar.

Container image: Para quem já trabalha com virtualização, uma Image seria equivalente a Template, ou pacote usado para criar containers, uma app pré empacotada. EX: Ansible, nginx, MySQL, Apache, MongoDB, Ubuntu, CentOS.

Os containers são baseados em imagens, assim uma instância de uma imagem em execução é chamada de container.

Para quem é programador ou entende pode olhar container e image como objecto e classe. Container é uma instância de uma imagem em execução.

Container image registry: local de armazenamento/biblioteca de imagens. O container registry pode ser público ou privado, local (on-premises) ou hospedado na nuvem.

Docker Hub é um public registry padrão do Docker (pensem no docker hub como o Google ou Apple store) é biblioteca pública de armazenamento de imagens.

Private registries:  Docker Trusted Registry, harbir, GitLab Container Registry

Public registries: Google Container Registry (CGR), Amazon Elastic Container Registry (ECR), Azure Container Registry (ACR).

Transição

Ao longo dos anos a forma de implantação de apps tem sofrido mutação de forma a oferecer mais flexibilidade e consolidação de recursos. Na imagem abaixo podemos visualizar a transição no modo de implantação de apps:

Na implantação tradicional “Bare Metal” a relação entre Servidor e App era 1:1.

Na era da virtualização “consolidação” a relação Servidor/hw e App passou para 1:N o que trouxe simplicidade na gestão de DC, redução de custos e outros benefícios.

 E agora os containers que não diferem muito de virtualização, a relação entre Servidor e App mantem 1:N mas permitindo em uma única instância de SO executarmos varias apps, 1:N relação entre SO e app. Assim os containers são mais leves que VMs e a sua criação ou implantação leva menos tempo e uma das suas principais vantagens é a portabilidade.

Portanto quando começamos a falar de containers penso que é quase inevitável tentarmos comparar com VMs, e isso também pode acabar nos levando ao pensamento que containers vieram substituir VMs. Na minha opinião, eu acho que a existência de containers não significa fim das VMs, por outra, podem trabalhar juntos para oferecer mais benefícios na gestão, deploy e segurança de app. Mas essa é uma conversa para uma outra altura quando estiver a abordar VMware Project Pacific.

Recomendo leitura: https://neonmirrors.net/post/2020-01/why-k8s-on-vms/

Versões

Docker existe em duas versões: Docker Community Edition (CE) e Enterprise Edition (EE).

A grande diferença entre as duas versões, docker (CE) “suporte da comunidade” e  docker (EE) possui suporte oficial “envolve dinheiro”, web GUI para gestão, RBAC, integração AD/LDAP,  funcionalidades de segurança, etc.

A grande imagem

As apps modernas são desenvolvidas usando arquitectura microsserviços (conjuntos de serviços ou componentes implementáveis independentemente) e cada uma com suas dependência, bibliotecas. Por outro lado o desenvolvimento dessas apps começa no ambiente dev/test ou mesmo na máquina pessoal do dev e só depois é passada para Produção. Esse processo ou fluxo de trabalho é doloroso e por vezes a implementação em prod falha por inconsistência entre os ambientes.

O tempo de configuração de um ambiente e racionalização de recursos necessários pode impactar na agilidade que as equipas devs precisam.

Os containers vem responder a todas estes e outros requisitos das “apps modernas”, pois permitem:

  • Criar ambientes em menos tempo.
  • Fácil/rápida implantação de apps.
  • Portabilidade, migração apps para nuvem privada ou pública.
  • Alta escalabilidade e resiliência (auto healing)…etc,,etc.

Containers oferecem agilidade e se encaixam melhor em ambientes DevOps que precisam desenvolver muito rápido, aumentar produtividade e responder demanda de necessidades de negócio.

Containers tem chance de se tornarem modo padrão de implantação de apps? O que vocês acham? Deixe seu comentário.

Veja o próximo artigo hands on lab DEMO instalação do Docker.

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão /  Alterar )

Google photo

Está a comentar usando a sua conta Google Terminar Sessão /  Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão /  Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão /  Alterar )

Connecting to %s