As imagens de contêiner personalizadas permitem implantar funções como imagens de contêiner no Function Compute, o que viabiliza migração de baixo custo, cache em camadas e integração com CI/CD.
Benefícios
Function Compute aceita imagens de contêiner personalizadas como artefatos de função:
Migração econômica sem alteração de código ou recompilação de binários. Arquivos de objetos compartilhados (*.so) mantêm a consistência entre os ambientes de desenvolvimento e produção.
Simplifique a distribuição e a implantação ao empacotar código e dependências juntos.
Aumente a eficiência de upload e pull de código mediante cache em camadas.
Utilize ferramentas de CI/CD open source para padronizar compilação, compartilhamento e versionamento de bibliotecas de terceiros e códigos.
Interaja com o Function Compute via HTTP.
Execute imagens não interativas.
Como funciona
Antes de o Function Compute inicializar uma instância, ele assume a função de serviço da função e obtém um nome de usuário e senha temporários para baixar a imagem. Após o download, o sistema inicia o contêiner com o Command e os Args especificados.
A imagem de contêiner deve incluir um servidor HTTP. O Function Compute escuta seu servidor HTTP personalizado na CAPort configurada. Esse servidor processa todas as solicitações para o Function Compute, incluindo invocações de API e HTTP. Você pode invocar funções de duas maneiras:
Invoque uma função por chamada de API
Invoque uma função por solicitação HTTP
Limites
Limite de tamanho da imagem
Para o ACR Personal Edition ou Enterprise Edition (Basic, Standard ou Premium), o tamanho máximo da imagem descompactada é de 10 GB para instâncias CPU e 15 GB para instâncias aceleradas por GPU.
Repositório de imagens
O Function Compute oferece suporte a imagens de repositórios do Container Registry Personal Edition e Enterprise Edition.
O ACR Economy Edition não oferece suporte à aceleração de imagens e não é compatível com o Function Compute. Utilize imagens de instâncias do ACR Personal Edition ou Enterprise Edition (Basic, Standard ou Premium).
Acesso à imagem
Apenas imagens públicas no ACR Personal Edition podem ser acessadas entre contas na mesma região. Todas as outras imagens ficam restritas a repositórios privados dentro da mesma conta e região.
Permissões de leitura e gravação de arquivos em contêineres
Os contêineres são executados como root (UID=0) por padrão. Se você especificar um usuário no Dockerfile, o contêiner será executado como esse usuário.
Limite de armazenamento da camada gravável para contêineres
A camada gravável do contêiner tem limite de 512 MB ou 10 GB, dependendo do tamanho do disco na configuração avançada da função. Criar uma função.
Os dados da camada gravável não são persistentes e são excluídos quando o contêiner é destruído. Para armazenamento persistente, monte um sistema de arquivos NAS ou um bucket do OSS no Function Compute. Configurar um sistema de arquivos NAS. Configurar o Object Storage Service. Outros serviços de armazenamento compartilhado, como o Tablestore, também têm suporte.
Limite de arquitetura da imagem
Atualmente, o Function Compute oferece suporte apenas a imagens AMD64. Em máquinas baseadas em ARM (como Macs com chips Apple), especifique a plataforma de compilação como linux/amd64. Exemplo de comando: docker build --platform linux/amd64 -t $IMAGE_NAME ..
Execute docker inspect para verificar. Se a saída incluir "Architecture" : "amd64", a imagem está correta.
Requisitos do servidor HTTP
Estes requisitos aplicam-se a funções de contêiner personalizadas com servidor web:
-
O servidor HTTP deve escutar em
0.0.0.0:CAPortou*:CAPort. Se o serviço escutar em127.0.0.1:CAPort, as solicitações atingirão o tempo limite e ocorrerá o seguinte erro:{ "ErrorCode":"FunctionNotStarted", "ErrorMessage":"TheCA'shttpservercannotbestarted:ContainerStartDuration:25000000000.PingCAfaileddueto:dialtcp21.0.XX.XX:9000:getsockopt:connectionrefusedLogs:2019-11-29T09:53:30.859837462ZListeningonport9000" }A porta de escuta padrão é 9000, configurada pela propriedade
CAPort. Seu servidor HTTP deve escutar na mesma porta. -
O servidor deve oferecer suporte a
Connection: Keep-Alivecom tempo limite de solicitação de 15 minutos ou mais:// For example, when using Express in Node.js. var server = app.listen(PORT, HOST); server.timeout = 0; // never timeout server.keepAliveTimeout = 0; // keepalive, never timeout O servidor HTTP deve iniciar em até 120 segundos.
Cabeçalhos de solicitação comuns
Imagens de contêiner personalizadas usam os mesmos cabeçalhos de solicitação que runtimes personalizados. Cabeçalhos de solicitação comuns no Function Compute.
Formato de log
O projeto do Simple Log Service especificado coleta automaticamente todos os logs stdout de imagens de contêiner personalizadas. Configurar o recurso de logging.
Imagens de contêiner personalizadas utilizam o mesmo formato de log que runtimes personalizados. Formato de log da função.
Otimização de cold start
Imagens de contêiner demoram mais para baixar e descompactar do que pacotes de código. Para reduzir a latência de cold start:
Utilize um endereço de imagem VPC na mesma região do Function Compute para diminuir a latência de pull e melhorar a estabilidade.
Minimize o tamanho da imagem. Adote uma imagem base mínima, como Alpine ou Ubuntu, e inclua apenas as dependências necessárias.
Use instâncias provisionadas para manter os contêineres aquecidos. Configurar uma política de elasticidade de contagem mínima de instâncias.
Para funções thread-safe, ative a concorrência de instância única para reduzir cold starts e custos, caso seus recursos permitam. Criar uma função web.
Faturamento
Imagens de contêiner personalizadas seguem o mesmo modelo de faturamento que outros runtimes. Visão geral do faturamento.
O tempo de download da imagem conta como uso de recursos, calculado do início ao fim do pull. Por exemplo, uma instância de 1.024 MB que leva 10 segundos para baixar uma imagem incorre em 10 GB-segundos.
As imagens permanecem em cache por um período; portanto, as taxas de pull não se aplicam a todos os cold starts.