Como containers usam volumes de storage? Saiba mais

Índice:

• Como containers usam volumes de storage?
• A natureza efêmera das aplicações containerizadas
• Volumes Bind Mounts e sua conexão com o host
• Volumes nomeados para gerenciamento simplificado
• A persistência em ambientes orquestrados com Kubernetes
• Qual o papel do storage externo na estratégia?
• Protocolos NFS e iSCSI para acesso aos dados
• Segurança e controle no acesso aos volumes
• Gerenciando backups e a recuperação em containers
• Otimizando a infraestrutura para containers

Containers nascem efêmeros porque executam aplicações sem estado. Todo dado gerado internamente some quando eles param, reiniciam ou atualizam.

Essa característica inviabiliza o uso em sistemas que exigem gravação de dados, como bancos de dados, uploads do usuário ou logs persistentes. Sem planejar o armazenamento, muitos projetos ficam inviáveis.

Garantir a persistência exige separar o ciclo vital dos dados do ciclo das aplicações.

Como containers usam volumes de storage?

Containers usam volumes para conectar um diretório interno a uma área de armazenamento externa ao seu ciclo vital. Os dados persistem mesmo após o encerramento ou recriação da aplicação, pois residem em um local independente no sistema de arquivos do host ou em um storage na rede. Essa separação viabiliza executar aplicações stateful, como bancos de dados ou sistemas de arquivos complexos, em ambientes containerizados.

Na prática, o motor do container, como o Docker, mapeia um caminho interno para um caminho externo. Qualquer operação de leitura ou escrita no caminho interno vai para o local externo. Essa técnica simples resolve a volatilidade dos dados, pois o armazenamento sobrevive a qualquer alteração no estado do container.

Existem tipos diferentes de volumes com características próprias. Os volumes nomeados contam com gerenciamento direto do Docker e servem muito bem na maioria dos casos. Já os bind mounts conectam um diretório específico do host ao container, oferecendo menos abstração e maior controle em cenários de desenvolvimento.

A natureza efêmera das aplicações containerizadas

A agilidade das aplicações containerizadas vem da construção em camadas somente para leitura. Quando um container inicia, o sistema cria uma camada superior gravável sobre as camadas imutáveis. Todas as modificações, como criar ou alterar arquivos, ocorrem apenas nessa camada temporária.

Ao parar ou remover o container, essa camada gravável some por completo. Qualquer informação sem salvamento externo desaparece para sempre. Esse comportamento intencional garante que cada nova instância comece em um estado limpo e previsível, simplificando a escalabilidade e a implantação.

No entanto, essa característica impõe uma limitação severa para muitas aplicações. Um banco de dados seria inútil se perdesse tabelas e registros a cada reinicialização. A solução para esse paradoxo está no uso de volumes que externalizam o armazenamento.

Volumes Bind Mounts e sua conexão com o host

Os bind mounts representam a forma mais direta para persistir dados. Eles funcionam mapeando um arquivo ou diretório existente no sistema de arquivos do host para dentro do container. Diferente dos volumes nomeados, o desenvolvedor tem controle total sobre a localização exata dos dados no host, ajudando no desenvolvimento para editar códigos ou arquivos de configuração imediatamente.

Por exemplo, um desenvolvedor pode mapear o diretório do projeto local para o diretório `/app` dentro do container. Qualquer alteração no código feita na máquina local reflete imediatamente na aplicação em execução, sem precisar reconstruir a imagem. Essa agilidade acelera o ciclo de desenvolvimento e os testes.

Ainda assim, essa abordagem tem desvantagens. A principal delas é o forte acoplamento com a estrutura de diretórios do host. Um bind mount que funciona em uma máquina pode falhar em outra se o caminho não existir, prejudicando a portabilidade da aplicação entre diferentes ambientes.

Volumes nomeados para gerenciamento simplificado

Volumes nomeados são a alternativa mais moderna e recomendada para a maioria das aplicações. Com eles, o Docker assume a responsabilidade de criar e gerenciar a área de armazenamento no host. O usuário apenas especifica um nome para o volume, e o Docker cuida dos detalhes sobre onde os dados ficam fisicamente.

Essa abstração resolve o problema de portabilidade dos bind mounts. Como o Docker gerencia o ciclo de vida do volume, fica muito mais fácil migrar aplicações e dados entre diferentes hosts. Comandos como `docker volume create`, `docker volume ls` e `docker volume rm` facilitam a administração, o backup e a limpeza desses volumes.

Além disso, vários containers podem usar o mesmo volume nomeado simultaneamente. Essa funcionalidade ajuda em cenários onde uma aplicação precisa compartilhar arquivos com outra, como um servidor web que acessa arquivos enviados por um serviço de upload. Por essas razões, os volumes nomeados são quase sempre a escolha correta para ambientes de produção.

A persistência em ambientes orquestrados com Kubernetes

Quando a complexidade aumenta e passamos a usar orquestradores como o Kubernetes, o gerenciamento de armazenamento também evolui. O Kubernetes introduz dois conceitos importantes chamados PersistentVolume (PV) e PersistentVolumeClaim (PVC). Essa dupla de recursos abstrai ainda mais a forma como o armazenamento é provisionado e consumido.

O PersistentVolume é um recurso no cluster que representa uma peça de armazenamento, como um disco em um provedor de nuvem ou um compartilhamento em um storage NAS. Geralmente, um administrador de sistemas provisiona vários PVs com diferentes características de desempenho e tamanho. O PV existe independentemente de qualquer pod.

Já o PersistentVolumeClaim é uma solicitação de armazenamento feita por um usuário ou aplicação. No arquivo de configuração do pod, o desenvolvedor especifica quanto armazenamento precisa e quais características ele deve ter, como acesso de leitura e escrita. O Kubernetes então tenta encontrar um PV compatível para atender a essa solicitação. Essa separação de papéis simplifica a vida dos desenvolvedores e centraliza o controle da infraestrutura com os administradores.

Qual o papel do storage externo na estratégia?

Para ambientes com vários hosts, depender apenas do armazenamento local é inviável. Se um container precisa ser movido para outro nó do cluster, seus dados precisam acompanhá-lo. É aqui que um storage externo, como um Network Attached Storage (NAS) ou uma Storage Area Network (SAN), ganha importância.

Esses equipamentos centralizam o armazenamento em um local acessível pela rede. Com o uso de drivers de armazenamento específicos, tanto o Docker quanto o Kubernetes podem criar e gerenciar volumes diretamente nesses sistemas. Um volume pode ser montado por um container em qualquer host do cluster que tenha conectividade com o storage.

Um NAS, por exemplo, pode fornecer volumes através do protocolo NFS, enquanto uma SAN pode usar iSCSI. A escolha entre eles depende muito da carga de trabalho. Essa integração com o storage de rede garante não apenas a persistência, mas também a alta disponibilidade dos dados, pois eles não estão mais presos a um único servidor físico.

Protocolos NFS e iSCSI para acesso aos dados

O NFS (Network File System) é um protocolo de armazenamento baseado em arquivos. Ao usar um volume NFS, o storage compartilha um diretório na rede, e vários containers podem montar e acessar esse mesmo diretório simultaneamente. Isso é ideal para aplicações que precisam de acesso compartilhado a um conjunto de arquivos, como sites com conteúdo estático ou sistemas de gerenciamento de documentos.

Por outro lado, o iSCSI (Internet Small Computer System Interface) é um protocolo de armazenamento baseado em blocos. Ele funciona de maneira diferente, apresentando um volume como se fosse um disco rígido local para o container. Geralmente, apenas um container pode montar um volume iSCSI no modo de leitura e escrita por vez. Essa exclusividade faz dele a escolha preferida para bancos de dados, que gerenciam seu próprio sistema de arquivos e exigem baixa latência e alto desempenho em IOPS.

Segurança e controle no acesso aos volumes

Conectar containers a volumes de armazenamento introduz novas preocupações com segurança. É fundamental garantir que apenas os containers autorizados possam acessar determinados dados. Uma das primeiras linhas de defesa é o uso de volumes no modo somente leitura sempre que possível. Se uma aplicação precisa apenas ler dados de configuração, montá-los sem permissão de escrita reduz drasticamente a superfície de ataque.

Outro ponto importante é o gerenciamento de permissões no nível do sistema de arquivos. Frequentemente, surgem conflitos entre o ID do usuário (UID) dentro do container e o proprietário dos arquivos no host ou no storage. Mapear corretamente esses IDs ou usar políticas de segurança específicas no orquestrador é essencial para evitar problemas de acesso negado ou, pior, acesso indevido.

Ao utilizar um storage de rede, a segurança alcança a própria rede. É uma boa prática isolar o tráfego de armazenamento em uma VLAN separada e usar firewalls para restringir o acesso ao storage apenas aos nós do cluster. Em conjunto, essas medidas protegem a integridade e a confidencialidade dos dados persistentes.

Gerenciando backups e a recuperação em containers

A persistência de dados resolve um problema, mas cria outro que é a necessidade de backup. Se os dados são importantes o suficiente para serem persistidos, eles também são importantes o suficiente para serem protegidos contra falhas, corrupção ou ataques de ransomware. Felizmente, o uso de volumes em um storage externo simplifica essa tarefa.

Muitos sistemas de storage NAS modernos, como os da QNAP, incluem ferramentas para snapshots e backup. Um snapshot captura o estado de um volume em um ponto específico no tempo, com impacto mínimo no desempenho. É possível criar vários snapshots ao longo do dia e restaurar o volume para um estado anterior em questão de minutos, caso algo dê errado.

Além dos snapshots, é possível configurar rotinas de backup que copiam os dados dos volumes para outro storage, para um serviço de nuvem ou para uma fita. Como os dados estão centralizados no storage, o processo de backup é muito mais eficiente do que tentar fazer backup de cada container individualmente. Essa estratégia garante um plano de recuperação de desastres sólido para as aplicações containerizadas.

Otimizando a infraestrutura para containers

A adoção de containers transformou a maneira como desenvolvemos e implantamos software, mas seu sucesso em produção depende diretamente de uma estratégia de armazenamento bem planejada. Ignorar a persistência dos dados limita o uso da tecnologia a aplicações simples e sem estado, deixando de fora sistemas críticos como bancos de dados e aplicações legadas.

A jornada desde a compreensão da natureza efêmera dos containers até a implementação de volumes em um storage de rede com alta disponibilidade é um passo fundamental para a maturidade de qualquer ambiente de TI. A escolha correta entre bind mounts, volumes nomeados, NFS ou iSCSI define a performance, a escalabilidade e a resiliência das suas aplicações.

Caso precise de suporte especializado para implementar ou otimizar o armazenamento e a infraestrutura de TI em sua empresa, conte com a nossa consultoria técnica para garantir projetos com alta performance e disponibilidade.