Use containers para aplicar o rigor da engenharia de software às cargas de trabalho de IA

À medida que as cargas de trabalho de IA passam de protótipos experimentais para ambientes de produção, as empresas enfrentam um desafio comum: como proteger, gerenciar e governar esses novos componentes com o mesmo rigor aplicado a aplicações de software tradicionais? Uma peça fundamental desse quebra-cabeça está em algo que sua organização provavelmente já utiliza extensivamente: containers, especificamente containers da Open Container Initiative (OCI).

O que é a Open Container Initiative?

A Open Container Initiative define especificações abertas para formatos de imagem, ambientes de execução de containers e distribuição, ajudando as organizações a evitar a dependência de fornecedor. Os containers OCI são um formato padrão do setor para empacotar aplicações de software. Por isso, eles podem ser executados de maneira consistente em diferentes ambientes, mecanismos de container (como Docker ou Podman) e plataformas de nuvem.

Um artefato OCI é semelhante a um container, mas, em vez de imagens executáveis, os artefatos armazenam outros conteúdos, como arquivos e diretórios.  Os repositórios de artefatos compatíveis com OCI (incluindo Quay, Artifactory, Docker Hub e registros dos principais provedores de nuvem) podem armazenar e gerenciar o controle de versão de containers e artefatos OCI.

A OCI oferece uma maneira padronizada e portátil de empacotar e distribuir software. Ao empacotar seus modelos de IA, servidores do Model Context Protocol (MCP) e IA de agentes utilizando containers OCI, você pode aproveitar seus processos de segurança da cadeia de suprimentos de software, pipelines de CI/CD e infraestrutura de orquestração de containers existentes. Essa abordagem traz a mesma governança e auditabilidade ao seu stack de IA que você já aplica às suas cargas de trabalho de aplicações.

Conteinerize modelos de IA com ModelCar

Large Language Models (LLMs) e outros modelos de IA apresentam desafios únicos de empacotamento. Eles consistem em arquivos binários grandes, metadados de configuração e requisitos específicos de estrutura de arquivos. No passado, as organizações dependiam de armazenamento de objetos compatível com S3 para distribuir modelos, mas essa abordagem cria atrito com os fluxos de trabalho baseados em containers e processos de segurança existentes. Recomendamos criar seus modelos de IA em containers OCI usando uma estrutura de arquivos específica chamada ModelCar.

O que é um container ModelCar?

Um container ModelCar é simples: os arquivos de modelos de IA ficam em uma pasta /models dentro do container. Nenhum pacote ou componente de runtime adicional é necessário; o container simplesmente mantém os artefatos do modelo em um formato compatível com OCI.

Os benefícios dessa abordagem são significativos. Após seu modelo ser empacotado como um container, você poderá gerenciá-lo usando os mesmos processos de segurança da cadeia de suprimentos de software que já utiliza para os containers da sua aplicação. Você pode gerar uma lista de materiais de software (SBOM) e uma lista de materiais de IA (AI-BOM) para o container como uma tarefa no seu pipeline de CI/CD. Você também pode assinar e validar o container, gerar atestados de procedência mostrando que o container foi criado por seu sistema de compilação confiável, armazenar o container em seu repositório interno de artefatos OCI e configurar suas políticas de implantação para extrair containers somente de repositórios aprovados.

O Red Hat Trusted Artifact Signer permite assinar modelos e validar a autenticidade e a transparência de um modelo usando o Sigstore e o Rekor. 

Red Hat OpenShift AI 2.14 e versões posteriores suportam o serviço de modelos diretamente de containers ModelCar usando KServe, eliminando totalmente a dependência de armazenamento compatível com S3. Isso simplifica a implantação, melhora os tempos de inicialização do servidor de inferência, especialmente quando o container está em cache em um nó, e fornece uma abordagem unificada para o gerenciamento de artefatos em toda a organização.

Um catálogo de exemplos de containers ModelCar está disponível no repositório do GitHub, fornecendo templates e práticas recomendadas para empacotar vários tipos de modelos.

Considerações sobre o tamanho do modelo

Embora a especificação OCI não imponha limites rígidos aos tamanhos de imagens, existem restrições práticas. Registros de containers normalmente suportam imagens que variam de alguns GB a dezenas de GB, com a maioria dos registros empresariais lidando com imagens de até 15-20 GB sem problemas. Para modelos muito grandes que excedem esses limites práticos, talvez seja necessário considerar técnicas de quantização de modelo para reduzir o tamanho dos arquivos ou mecanismos de distribuição alternativos. No entanto, para a maioria dos modelos de produção, especialmente variantes quantizadas como Floating Point de 8 bits (FP8) ou número inteiro de 4 bits (INT4), a conteinerização com ModelCar é prática e recomendada.

Artefatos OCI para modelos

O ModelCar usa containers OCI para garantir o máximo de compatibilidade com sistemas legados que não suportam totalmente artefatos OCI, mas os artefatos OCI são indiscutivelmente uma escolha melhor e mais eficiente para o armazenamento de modelos. 

Engenheiros de compilação podem empacotar seus modelos em artefatos OCI em vez de containers e armazená-los em seu repositório de artefatos OCI. No momento da implantação, você pode montar o artefato OCI diretamente no Pod de serviço do modelo como armazenamento, usando um Kubernetes image volume. A montagem de artefatos OCI já está implementada em versões recentes do Podman e do runtime de container CRI-O. O trabalho está em andamento para outros runtimes, incluindo o Containerd.

Conteinerização de servidores MCP para implantação empresarial

O MCP surgiu como um padrão para conectar assistentes e agentes de IA a ferramentas externas, fontes de dados e APIs. Servidores MCP atuam como pontes entre sistemas de IA e recursos empresariais, tornando a segurança e a governança desses componentes cruciais.

Para servidores MCP compartilhados entre equipes ou implantados em produção, recomendamos integrá-los em containers usando as mesmas ferramentas e processos de compilação de outras aplicações. Essa abordagem oferece consistência na gestão, implantação e proteção desses componentes. O processo é familiar para quem já conteinerizou aplicações: escreva um containerfile, compile a imagem, envie-a ao seu registro e faça a implantação usando Red Hat OpenShift, Kubernetes, Podman ou Docker.  Use suas ferramentas de build habituais para assinar e verificar servidores MCP, gerar um SBOM, armazená-los em repositórios de artefatos OCI e realizar outras tarefas.

Como em qualquer software, códigos maliciosos podem se infiltrar em um servidor MCP. Analise e valide continuamente seus servidores MCP usando o Red Hat Trusted Profile Analyzer para identificar vulnerabilidades, dependências maliciosas e violações de políticas.

Benefícios de servidores MCP em containers

Servidores MCP em containers podem ser escalados horizontalmente para lidar com o aumento da carga, monitorados com ferramentas de observabilidade padrão e controlados por suas políticas de segurança existentes.

O OpenShift Kubernetes MCP server demonstra esse padrão. Ele pode ser executado localmente para desenvolvimento ou ser implantado no cluster usando o transporte Streamable HTTP para acesso da equipe. O servidor suporta modos de acesso configuráveis (somente leitura, não destrutivo ou acesso total) e se integra ao controle de acesso baseado em função (RBAC) do Kubernetes para autorização.

Um ecossistema já se desenvolve em torno de servidores MCP em containers. Por exemplo, o MCP lifecycle operator facilita a implantação de servidores MCP em containers e a conexão deles com seus agentes por meio de configuração nativa do Kubernetes. O Kuadrant MCP Gateway oferece recursos avançados de segurança empresarial. Outras ferramentas conhecidas, como o Docker também funcionam com servidores MCP em containers.

Quando não conteinerizar seus servidores MCP

Nem todos os servidores MCP se beneficiam da conteinerização. A especificação do MCP suporta dois mecanismos de transporte principais: stdio (entrada/saída padrão) e transportes baseados em HTTP (incluindo Streamable HTTP e o transporte legado Server-Sent Events (SSE)). Essa distinção é importante para as decisões de implantação.

Servidores MCP baseados em stdio se comunicam por meio de fluxos de processos, com o cliente de IA gerando o servidor como um processo filho. Esse modelo funciona bem para cenários de usuário único: um assistente de codificação de uma pessoa desenvolvedora, uma ferramenta de produtividade local ou um script de automação pessoal. Nesses casos, o servidor MCP é executado no laptop da pessoa, acessa arquivos e recursos locais e encerrado quando não é mais necessário. A conteinerização de servidores MCP stdio adiciona complexidade sem benefícios significativos para esses casos de uso locais de usuário único.

Por outro lado, servidores MCP baseados em HTTP são executados como processos independentes que podem lidar com várias conexões de clientes simultaneamente. Eles expõem endpoints de rede e operam de forma mais parecida com serviços web tradicionais. Esses servidores são candidatos naturais para a conteinerização e se beneficiam de implantação, escala e gerenciamento centralizados.

O framework de decisão é o seguinte: 

• Para ambientes compartilhados/de produção: Se o servidor MCP for compartilhado por uma equipe, acessado por uma rede ou implantado em um ambiente de servidor, conteinerize-o.
• Para agentes em containers: Se o agente estiver sendo executado em um container, um servidor MCP baseado em stdio deverá ser executado no mesmo container que o agente, enquanto um servidor MCP baseado em HTTP deverá ser executado em um container separado.
• Para uso local por uma única pessoa: Se um servidor MCP for executado localmente na máquina de um único desenvolvedor usando transporte stdio, a conteinerização será opcional e poderá adicionar custos indiretos desnecessários. 

Conteinerização de Agent Skills

Agent Skills surgiram como uma alternativa e um complemento aos servidores MCP. Elas são "pastas de instruções, scripts e recursos que os agentes podem descobrir e usar para realizar tarefas com mais precisão e eficiência". A especificação das habilidades as define como empacotadas como arquivos zip. 

Você pode estender seu sistema de compilação para empacotar suas habilidades em containers ou artefatos OCI, assim como modelos e servidores MCP. Em seguida, você pode assinar e verificar habilidades, gerar uma SBOM, armazená-las em repositórios de artefatos OCI, baixá-las e anexá-las a Pods como modelos. Como as habilidades podem conter scripts específicos da plataforma, o OCI também tem recursos para fornecer um conjunto diferente de arquivos para cada plataforma. Se suas aplicações habilitadas para habilidades ainda não funcionarem com containers ou artefatos OCI, use o utilitário de linha de comando ORAS para extrair uma habilidade para o diretório correto. 

Como alternativa, as habilidades podem ser gerenciadas usando gerenciadores de pacotes no futuro, de forma semelhante ao gerenciamento de outras bibliotecas compartilhadas para várias linguagens de programação. Nesse caso, as habilidades seriam importadas e usadas dentro de containers, mas não necessariamente distribuídas como containers. 

Essa é uma tecnologia emergente, portanto, acompanhe os desenvolvimentos futuros. 

Conteinerização agentes de IA

Agentes de IA — sistemas autônomos que podem planejar e executar tarefas de várias etapas usando modelos de IA e outras ferramentas — representam a próxima evolução das aplicações de IA. À medida que os agentes passam dos protótipos à produção, as empresas precisam de uma abordagem estruturada para criá-los, implantá-los e gerenciá-los.

O projeto Kagenti oferece um framework nativo do Kubernetes exatamente para essa finalidade. O Kagenti funciona com qualquer framework de agente ou SDK e oferece componentes modulares para implantação em produção. Basicamente, o Kagenti trata os agentes como cargas de trabalho em containers que podem ser definidas de maneira declarativa usando recursos personalizados do Kubernetes.

O Kagenti usa Shipwright e Buildah para criar agentes em containers. Se a sua organização usa Tekton ou Jenkins para CI/CD, você pode adicionar uma tarefa semelhante do Buildah aos seus pipelines existentes. Assim como acontece com os modelos de IA e os servidores MCP, use suas ferramentas de build típicas para assinar e verificar containers de agente, gerar um SBOM, armazená-los em repositórios de artefatos OCI e assim por diante.

Assim como os servidores MCP, você pode escalar os agentes em containers horizontalmente para lidar com o aumento da carga, monitorá-los com ferramentas de observabilidade padrão e controlá-los pelas suas políticas de segurança existentes.  Analise e valide continuamente seus agentes usando o Red Hat Trusted Profile Analyzer para identificar vulnerabilidades, dependências maliciosas e violações de políticas.

Agentes e subagentes de usuário único

Assim como os servidores MCP, nem todos os agentes exigem o uso de containers. Os agentes executados localmente no laptop de um único usuário — como subagentes gerados por um assistente de codificação ou agentes de automação pessoais — podem não precisar dos custos indiretos do empacotamento de containers e da implantação do Kubernetes. Esses agentes lightweight são geralmente executados como processos filhos de uma aplicação pai e compartilham o contexto de segurança dessa aplicação.

Nesses cenários de usuário único, o foco deve ser verificar se a aplicação pai (o IDE, o assistente de codificação ou a ferramenta de automação) está adequadamente protegida, em vez de colocar cada subcomponente em containers. O gerenciamento corporativo desses agentes locais é uma área em evolução, e as organizações devem monitorar os desenvolvimentos em frameworks e ferramentas de agentes.

Containers para sandbox

Como agentes, servidores MCP e modelos que escrevem e executam código introduzem novas vulnerabilidades, uma prática recomendada é restringir o acesso deles aos sistemas e conter os danos que podem causar. Às vezes, isso é chamado de "sandbox do agente" ou "sandbox do código". 

Implante o software em containers com políticas de rede que restringem a comunicação com serviços externos, desde a abertura e bloqueio de portas até a inclusão de sites e serviços específicos em listas de permissões. Os recursos de RBAC e service mesh do Kubernetes oferecem controle de acesso de alta granularidade. Normalmente, os containers do OpenShift são executados sem permissões de raiz, restringindo seu acesso aos dados e recursos de computação.  

Os containers também têm limites de uso de CPU e memória. Nas estações de trabalho do desenvolvedor, o Podman executa seus containers sem permissões de raiz por padrão e também restringe o acesso do container à sua rede e sistema de arquivos. Há muito tempo, o OpenShift oferece isolamento de containers, e o Red Hat build of Podman Desktop também permite o isolamento em estações de trabalho de desenvolvedores.

Outra preocupação é o processamento descontrolado pelos agentes, levando a um ataque de negação de serviço. Com o OpenShift, os administradores de cluster podem definir cotas de recursos para cada namespace, limitando os recursos de GPU, CPU, memória e armazenamento que qualquer projeto pode consumir. Com cotas de recursos razoáveis em vigor, um agente descontrolado não pode esgotar os recursos de cluster de outras cargas de trabalho.

Embora eles possam ser executados em um laptop pessoal, descobrimos que executar assistentes de codificação e agentes pessoais em um container geralmente vale o esforço. Quando um agente é executado em um container em sandbox, ele não pode danificar os documentos importantes no seu laptop nem acessar dados que você não quer que ele use. Isso significa que você pode pré-aprovar ações comuns, como leitura/gravação de arquivos, deixar o agente ser executado com menos supervisão e revisar o resultado final da tarefa atribuída.

Inicie vários agentes ao mesmo tempo e deixe-os trabalhar em paralelo, sem interferir uns nos outros. Implante agentes de longa execução em seu namespace pessoal no OpenShift, feche o laptop e vá para casa enquanto os agentes continuam trabalhando para você. Você pode até mesmo salvar o container do agente para preservar seu estado e retomá-lo mais tarde. Dois projetos emergentes nessa área são o Paude, para agentes de codificação, e openclaw-installer, para OpenClaw.

Benefícios do uso de containers em cargas de trabalho de IA

A conteinerização dos componentes de IA (modelos, servidores MCP e agentes) traz benefícios significativos que se somam em toda a organização.

Segurança da cadeia de suprimentos de software

Os containers podem ser assinados, atestados e verificados antes da implantação. Você pode exigir que todos os componentes de IA sejam criados por seus sistemas de CI/CD de confiança, verificados quanto a vulnerabilidades e armazenados em registros aprovados. Os atestados de procedência oferecem uma trilha de auditoria que mostra exatamente como cada artefato foi produzido.

Controle de versão e rollback

As imagens de containers são imutáveis e marcadas. Você pode implantar versões específicas, reverter para versões anteriores se surgirem problemas e manter um histórico claro do que foi implantado e quando.

Implantação consistente

A mesma imagem de container é executada de maneira idêntica nos ambientes de desenvolvimento, staging e produção. Isso reduz o risco de arquivos serem copiados incorretamente de um ambiente para outro.

Observabilidade

As cargas de trabalho em containers se integram à infraestrutura de monitoramento e geração de logs existente. O Kagenti, por exemplo, é compatível com o rastreamento OpenTelemetry (OTEL) pronto para uso, permitindo que você monitore as operações do agente usando seu stack de observabilidade padrão.

Isolamento e controle de acesso

Por fim, os containers oferecem recursos avançados para sandboxing, ajudando a controlar o raio de impacto de qualquer problema.

Perspectivas para o futuro: Identidade de carga de trabalho e zero trust

A conteinerização também estabelece a base para padrões de segurança mais avançados. O projeto Kagenti está explorando a integração com SPIFFE/SPIRE para identidade de carga de trabalho e arquitetura de confiança zero para agentes e servidores MCP.. Embora esses recursos ainda estejam surgindo, ter seus componentes de IA em containers e em execução no Kubernetes facilita muito a adoção dessas funcionalidades de segurança à medida que elas amadurecem.

A identidade da carga de trabalho garante que cada agente ou servidor MCP tenha uma identidade verificável criptograficamente, permitindo a comunicação segura entre serviços sem segredos compartilhados. Os princípios de zero trust (nunca confiar, sempre verificar) tornam-se práticos de implementar quando os componentes de IA estão em containers e podem ser integrados à infraestrutura de gerenciamento de identidade e acesso existente.

Considerações finais

Os containers OCI oferecem uma abordagem padronizada e comprovada para empacotar e distribuir software que se estende naturalmente às cargas de trabalho de IA. Ao conteinerizar seus modelos de IA, servidores MCP e agentes, você traz a mesma governança, segurança e maturidade operacional para o stack de IA que já aplica às suas aplicações.

O insight fundamental é reconhecer quando a conteinerização agrega valor. Os containers são essenciais para implantações de produção em rede e compartilhadas. Para uso local de usuário único, os containers são opcionais, mas oferecem sandboxing e portabilidade entre dispositivos: crie uma vez, execute em qualquer lugar. Essa abordagem pragmática permite aplicar o nível certo de governança a cada componente, evitando complexidade desnecessária.

O Red Hat OpenShift AI, o Red Hat Trusted Artifact Signer, o Red Hat Trusted Profile Analyzer e o Red Hat build of Podman oferecem uma base sólida para gerenciar suas cargas de trabalho de IA, do protótipo à produção. A Red Hat adiciona suporte empresarial a ferramentas open source com comunidades ativas para ajudar você a acompanhar os desenvolvimentos mais recentes em IA.