imaginary
imaginary copied to clipboard
How to deploy imaginary to AWS Lambda?
Hi there,
I am switching from hosting imaginary in docker to AWS lambda serverless microservices. I am quite new to Lambda, can anyone share their experience on deploying imaginary on Lambda and combine it will Amazon API gateway?
Thanks!
I'm not sure if it's possible to host Imaginary on Lambda, the point of the new "serverless" construct is that you can run code, without having the notion of a "service" of sorts. So you need to think of it more as "running functions in the cloud" rather than applications. I might be playing with terminology here, but I'm trying to make a clear point.
Imaginary is largely written in Go, ~AWS Lambda doesn't support Go (yet)~. However if you just want to run an image scaling service on Lambda, you could just try things like: https://serverlessrepo.aws.amazon.com/applications/arn:aws:serverlessrepo:us-east-1:526515951862:applications~image-resizer-service
@Dynom Thank you for your response. AWS Lambda actually have give support of running Golang natively since Jan 2018 (https://aws.amazon.com/cn/blogs/compute/announcing-go-support-for-aws-lambda/), which make me rethink whether the possible way to deloy Imaginary on Lambda and serve it with AWS API Gateway.
You should be able to run it on AWS. My only doubt is about the C compilation and dependencies. I think you can bypass native Lambda limitations by injecting a shim, as Apex does: https://github.com/apex/apex
You can also inject already compiled binaries too that can run on AWS Lambda VMs, so you don't have to deal with function deploy compilation at all, which may exceed the time limit of Lambda.
Take a look at this as well: https://github.com/stechstudio/libvips-lambda https://github.com/jcupitt/libvips/issues/492 http://sharp.readthedocs.io/en/stable/install/#aws-lambda
I've made it work in https://github.com/lambci/docker-lambda , here are the changes need to be made:
- Replace
flag
withgithub.com/namsral/flag
to get settings from environment variables instead of command line flags - In
func Server
, mount the handler withgithub.com/apex/gateway
- Place compiled libvips dependencies (like https://github.com/stechstudio/libvips-lambda or so) aside the binary in deployment package, and make them the first in
LD_LIBRARY_PATH
.
See my branch for an example of the build process: https://github.com/h2non/imaginary/compare/master...arthow4n:lambda-support Haven't test it in a live Lambda deployment, but I believe it's a great starting point.
Actually lambda supports go :)
@arthow4n Have you managed to finish it?
Sorry @sheerun I ended up hosting this on EC2 because I found it would be too costly to host on Lambda in my production scenario.
Actually lambda supports go :)
Yes you're right, since januari 2018 my bad. However in all honesty I'm not feeling the "serverless" thing with services like Imaginary. bimg, on the other hand, would make more sense imo.
Functions / Lambda are (typically) designed for short-lived execution. Imaginary is designed as long-running service.
Wanted to share some methods I used while working on using libvips with Ruby and AWS Lambda. Might be some usefulness here if others are interested in taking a look. https://github.com/customink/ruby-vips-lambda