Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
A plataforma de contêiner do Windows está se expandindo! O Docker foi a primeira parte do percurso do contêiner, agora estamos criando outras ferramentas de plataforma de contêiner.
- containerd/cri – novo no Windows Server 2019/Windows 10 1809.
- runhcs – um equivalente de host de contêiner do Windows ao runc.
- hcs - o Serviço de Computação do Host + shims práticos para facilitar o uso.
Este artigo falará sobre a plataforma de contêiner windows e Linux, bem como cada ferramenta de plataforma de contêiner.
Plataforma de contêiner do Windows e do Linux
Em ambientes do Linux, ferramentas de gerenciamento de contêineres como o Docker são criadas em um conjunto mais granular de ferramentas de contêiner: runc e contêiner.
runc
é uma ferramenta de linha de comando do Linux para criar e executar contêineres de acordo com a especificação de runtime do contêiner OCI.
containerd
é um daemon que gerencia o ciclo de vida do contêiner desde baixar e desempacotar a imagem de contêiner até a execução e a supervisão do contêiner.
No Windows, tomamos uma abordagem diferente. Quando começamos a trabalhar com o Docker para dar suporte a contêineres do Windows, criamos diretamente no HCS (Serviço de Computação de Host). Esta postagem no blog está cheia de informações sobre por que criamos o HCS e por que usamos essa abordagem para contêineres inicialmente.
Neste ponto, o Docker ainda chama diretamente para o HCS. No entanto, daqui para frente, as ferramentas de gerenciamento de contêineres, ao se expandirem para incluir contêineres do Windows e o host de contêiner do Windows, poderão chamar containerd e runhcs da maneira como chamam containerd e runc no Linux.
runhcs
runhcs
é um fork de runc
. Por exemplo runc
, runhcs
é um cliente de linha de comando para executar aplicativos empacotados de acordo com o formato OCI (Open Container Initiative) e é uma implementação compatível com a especificação da Open Container Initiative.
As diferenças funcionais entre runc e runhcs incluem:
runhcs
é executado no Windows. Ele se comunica com o HCS para criar e gerenciar contêineres.runhcs
pode executar uma variedade de tipos de contêiner diferentes.- Isolamento do Hyper-V no Windows e Linux.
- Contêineres de processo do Windows (a imagem do contêiner deve corresponder ao host do contêiner)
Uso:
runhcs run [ -b bundle ] <container-id>
<container-id>
é seu nome para a instância de contêiner que você está iniciando. O nome deve ser exclusivo no host do contêiner.
O diretório do pacote (usando -b bundle
) é opcional.
Assim como acontece com o runc, os contêineres são configurados usando pacotes. O pacote de um contêiner é o diretório com o arquivo de especificação OCI do contêiner, "config.json". O valor padrão para "bundle" é o diretório atual.
O arquivo de especificação OCI, "config.json", precisa ter dois campos para ser executado corretamente:
- Um caminho para o espaço transitório do contêiner
- Um caminho para o diretório de camada do contêiner
Os comandos de contêiner disponíveis em runhcs incluem:
Ferramentas para criar e executar um contêiner
- executar cria e executa um contêiner
- create cria um contêiner
Ferramentas para gerenciar processos em execução em um contêiner:
- iniciar executa o processo definido pelo usuário em um contêiner criado
- exec executa um novo processo dentro do contêiner
- pausar pausa suspende todos os processos dentro do contêiner
- retoma todos os processos que foram pausados anteriormente
- ps ps exibe os processos em execução dentro de um contêiner
Ferramentas para gerenciar o estado de um contêiner
- o estado gera o estado de um contêiner
- kill envia o sinal especificado (padrão: SIGTERM) para o processo de inicialização do contêiner
- delete exclui todos os recursos mantidos pelo contêiner frequentemente usados com o contêiner desanexado
O único comando que pode ser considerado multi-contêiner é list. Ele lista os contêineres em execução ou pausados iniciados por runhcs com a raiz fornecida.
HCS
Temos dois wrappers disponíveis no GitHub para interface com o HCS. Como o HCS é uma API C, os wrappers facilitam a chamada do HCS de idiomas de nível superior.
- hcsshim - HCSShim é escrito em Go e é a base para runhcs. Pegue a última versão do AppVeyor ou compile por conta própria.
- dotnet-computevirtualization – dotnet-computevirtualization é um wrapper C# para o HCS.
Se você quiser usar o HCS (diretamente ou por meio de um wrapper) ou quiser fazer um wrapper Rust/Haskell/InsertYourLanguage ao redor do HCS, deixe um comentário.
Para obter uma visão mais profunda do HCS, assista à apresentação do DockerCon de John Stark.
containerd/cri
Importante
O suporte ao CRI só está disponível no Windows Server 2019/Windows 10 1809 e posterior.
Embora as especificações de OCI definam um único contêiner, CRI (interface de runtime de contêiner) descreve contêineres como cargas de trabalho em um ambiente de área restrita compartilhado chamado pod. Os pods podem conter uma ou mais cargas de trabalho de contêiner. Os pods permitem que orquestradores de contêineres como Kubernetes e Malha do Service Fabric manipulem cargas de trabalho agrupadas que devem estar no mesmo host com alguns recursos compartilhados, como memória e vNETs.
Embora runHCS e containerd possam gerenciar em qualquer servidor do sistema Windows 2016 ou posterior, dar suporte a pods (grupos de contêineres) exigiu alterações significativas nas ferramentas de contêiner no Windows. O suporte ao CRI está disponível no Windows Server 2019/Windows 10 1809 e posterior.