Como criar seu próprio serviço de processamento seguro de imagens com o Imaginary e o Kubernetes

Roffe Blocked Unblock Seguir Seguindo 13 de janeiro

Algum tempo atrás me pediram para olhar o artigo Resizing Images com o Amazon CloudFront & Lambda @ Edge e ver se era algo que poderia ser útil.

Eu tive alguns pensamentos sobre isso, pois envolvia funções lambda que seriam executadas em cada solicitação de imagem e leitura e gravação de arquivos em um bucket s3

O Lambda conta uma solicitação toda vez que inicia a execução em resposta a uma notificação de evento ou chamada de chamada, incluindo chamadas de teste do console. Você é cobrado pelo número total de solicitações em todas as suas funções

A duração é calculada a partir do momento em que seu código começa a ser executado até que ele retorne ou seja encerrado, arredondado para os 100ms mais próximos.
O preço depende da quantidade de memória que você aloca para sua função

As funções Lambda @ Edge são medidas com granularidade de 50 ms

Também estaríamos enchendo a unidade S3 com mais e mais imagens para cada resolução solicitada, pois elas seriam gravadas de volta ao armazenamento pela função Lambda após o processamento da imagem e servindo-a

Com um pouco de CPU sobrando e queimando dinheiro, não seria legal processar nossas próprias imagens com ele?

Eu encontrei o Imaginary , ele tinha todas as coisas docker já feitas, então colocá-lo em Kubernetes foi uma brisa e então este PoC nasceu

Imaginário

Microservice HTTP rápido escrito em Go para processamento de imagem de alto nível respaldado por bimg e libvips . imaginary pode ser usado como serviço HTTP privado ou público para processamento massivo de imagens com suporte de primeira classe para o Docker & Heroku . É quase livre de dependência e usa apenas net/http pacote nativo net/http sem abstrações adicionais para melhor desempenho

Suporta várias operações de imagem expostas como uma API HTTP simples, com recursos opcionais adicionais, como autorização de token de API, proteção de assinatura de URL, estratégia de aceleração de tráfego HTTP e suporte a CORS para clientes da web

imaginary pode ler imagens de cargas HTTP POST, caminho local do servidor ou servidores HTTP remotos, suportando formatos JPEG, PNG, WEBP e, opcionalmente, TIFF, PDF, GIF e SVG se libvips@8.3+ for compilado com as devidas vinculações de biblioteca

imaginary é capaz de produzir imagens como formatos JPEG, PNG e WEBP, incluindo a conversão transparente entre eles

imaginary também suporta opcionalmente mecanismo de fallback de placeholder de imagem em caso de erro de processamento de imagem ou erro de servidor de qualquer natureza, portanto uma imagem será sempre retornada pelo servidor em termos de corpo de resposta HTTP e tipo MIME de conteúdo, mesmo em caso de erro, tamanho e formato de imagem esperados de forma transparente

Ele usa internamente libvips , uma biblioteca poderosa e eficiente escrita em C para processamento de imagem que requer pouca memória e é tipicamente 4x mais rápida do que usar as configurações mais rápidas ImageMagick e GraphicsMagick ou pacote de image nativa Go e, em alguns casos, é até 8x mais rápido. Imagens JPEG

Para começar, dê uma olhada nas etapas de instalação , nos casos de uso e nos documentos da API

Implantando-o no Kubernetes

Minha implantação do Imaginary se parece com isso

Há muito mais opções se você consultar os documentos Imaginary

E precisamos de um serviço para poder conectar um ingresso a ele

E termine com um ingresso (não se esqueça de atualizar o domínio)

URL da imagem de assinatura

A documentação do Imaginary contém um bom exemplo em como assinar suas URLs (não esqueça a ordem dos campos de solicitação)

Aqui está a minha versão com um pequeno toque para me dar uma melhor URL para copiar / colar

Uma vez aplicado ao seu cluster, você deve ser capaz de testar seu serviço de imagem carregando

http: // <seu endereço de serviço> /resize?nocrop=true&type=jpeg&url=https%3A%2F%2Fwww.google.com%2Flogos%2Fdoodles%2F2015%2Fgoogles-new-logo-5078286822539264.3-hp2x.gif&width=200&sign= 9Rawdy5gEmqGTRgxUOO7fFMYegivSQd1jNSuJljY2PM

Observe que o URL de exemplo acima pressupõe que você use o signKey no meu exemplo. Se você usou uma chave diferente, precisará gerar uma nova assinatura de URL

Cache tudo isso!

Se você estiver na AWS, pode colocar uma distribuição do CloudFront na frente de toda a instalação e aproveitar o cache de imagens na borda para tirar muita carga do back-end. Operações de imagem só aconteceriam quando as imagens caíssem do cache devido a LRU, então a imagem mais popular, menos ela teria que ser solicitada do backend

Eu imagino que o Google tem algum serviço semelhante ao CloudFront e CloudFlare provavelmente seria capaz de frontear o serviço bem

Palavras de encerramento

Eu casualmente referencio o manifesto de ingresso neste artigo. Na realidade, pode ser uma configuração complexa e tranquila para fazer com que o ingresso no Kubernetes funcione, dependendo do seu ambiente, e sugiro que você gaste o tempo necessário para pesquisar adequadamente qual solução será melhor no seu caso de uso.

Eu pessoalmente recomendo Skipper de Zalando . Está me servindo bem em nosso ambiente de produção no trabalho. Que você pode ler sobre aqui

Texto original em inglês.