GithubHelp home page GithubHelp logo

libvips-lambda's Introduction

libvips : Executable for AWS Lambda

libvips is a 2D image processing library. Compared to similar libraries, libvips runs quickly and uses little memory. libvips is licensed under the LGPL 2.1+.

We use libvips for image manipulation, primarily tiling image pyramids for blueprints and other construction industry artifacts, which results in about seven thousand vips executions a day for the past several years. We have long wanted to move that processing to AWS Lambda, and were hung up on getting a vips executable into AWS.

In the fall of 2016, I had a good chat with @jcupitt and @lovell about the issue in jcupitt/libvips#492 and @lovell pointed out that they were building vips libraries for the Node.js module Sharp. Sharp builds the shared libraries that have a single runtime dependency of glibc v2.13+ and the latest Amazon Linux is further along than that.

If we were looking for a Node.js solution in AWS Lambda, we could have simply used the sharp module. If you are using Node.js, you should probably stop here and just go use Sharp. However, we required an executable that we could call directly. So I adapted the sharp vips build tools to allow us to get what we are after, an executable.

It really didn't take much once I dug around the Sharp Repository a bit and found how they are building for the latest vips. We are ultimately just adding the /bin directory to the resulting archive.

Over time, I expect we will diverge from the Sharp code base significantly, but if nothing else, this is a handy place for us to quickly get the binary we desire for AWS Lambda.

Using libvips for AWS Lambda

We keep some pre-baked tarballs on the release page:

https://github.com/stechstudio/libvips-lambda/releases

You can simply untar that and skip the entire build process if you like.

Building libvips for AWS Lambda

The process depends on Docker being installed.

Clone this repository and run:

$ ./build-vips.sh 8.5.6

When all is said and done you should have something like dist/libvips-8.5.6-linux-x64.tar.gz in your working directory.

Building libvips with php-vips-ext for AWS Lambda

The process depends on Docker being installed.

It is important to note that for running in Lambda we need to ensure that PHP is compiled against the exact same libraries that we use for VIPS and the subsequent compilation of the PECL extension needs to build against those as well. Simply using PECL will not work because PECL gets easily confused with other system libraries that we are overriding.

Clone this repository and run:

$ ./build-phpvips.sh 8.5.6 7.1.6 1.0.7

When all is said and done you should have something like dist/vips-8.5.6_php-7.1.6_ext-php-1.0.7-lambda.tar.gz in your working directory.

Using libvips in an AWS Lambda Package

Creating a Lambda Deployment Package is beyond the scope of this read me. However, you need to be familiar with the process.

Go about creating your Deployment Package as normal, and extract the libvips tarfile into your base directory. This will result in new directories (assumes PHP build )if they didn't previously exist:

  ./bin         Our Binaries
  ./etc         Pear configuration
  ./include     Headers for everything we built
  ./lib         All the Shared Libraries
  ./modules     PHP Module Config Dir

You will find vips at ./bin/vips along with all the other executables we created. If you were to add everything to your lambda package it would be about 30M zipped and 86M on disk. However, you probably only want one or two of the executables in which case you should cherry pick only the executables your lambda function needs. The entire ./bin directory is about 45MB on disk.

There is probably no reason to deploy the ./include (15M on disk) to lambda at all. It is only packaged to allow additional compilation if desired.

The ./lib (27M on disk) directory is the big one. Just assume you need every file in the root directory for vips or php to work properly at all. However, there are a number of subdirectories that you don't need at all, and you can effectively delete all of them prior to lambda deployment to save a little space.

Note that there are a large number of symlinks in the ./lib directory and it is important that those be maintained when creating your lambda package. Not all operating systems nor zipping programs properly handle the symlinks. You are warned.

In your code you can reference /var/task/bin/vips and you will need to ensure you customize the Lambda Function Environment Variables:

LD_LIBRARY_PATH=${LAMBDA_TASK_ROOT}/lib:LD_LIBRARY_PATH
PATH=${LAMBDA_TASK_ROOT}/bin:${LAMBDA_TASK_ROOT}:${PATH}

This will ensure our libraries and binaries get preference.

libvips-lambda's People

Contributors

bubba-h57 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

libvips-lambda's Issues

Wrong URL on downloading png16

I tried to build the current version and ran into the following error:

-------------------------------------------------------------------------------------------------
|   Begin Building png16
-------------------------------------------------------------------------------------------------
curl -Ls http://netix.dl.sourceforge.net/project/libpng/libpng16/1.6.28/libpng-1.6.28.tar.xz | tar xJC /deps/png16 --strip-components=1
xz: (stdin): File format not recognized
tar: Child returned status 1
tar: Error is not recoverable: exiting now

The given URL http://netix.dl.sourceforge.net/project/libpng/libpng16/1.6.28/libpng-1.6.28.tar.xz, redirects to https://sourceforge.net/projects/libpng/files/, not to the .xz file required.

This one https://ftp.osuosl.org/pub/blfs/conglomeration/libpng/libpng-1.6.28.tar.xz seems to work, but don't know how trusted the provider is.

I did not try to replace it yet.

Prebuilt libvips 8.14.4 binaries are not yet available for linux-arm64v8

Hello

this issue is related to
sst/open-next#292

I'm encountering an issue with sharp/libvips installation by open-next

I'm on Windows WSL 2 Ubuntu x86_64
packaging for AWS Lambda
I've installed brew install vips without success

$ npm install --arch=arm64 --platform=linux --target=18 --libc=glibc --prefix="/home/john/workspace/app/apps/web/.open-next/image-optimization-function" [email protected]

npm ERR! code 1
npm ERR! path /home/john/workspace/app/apps/web/.open-next/image-optimization-function/node_modules/sharp
npm ERR! command failed
npm ERR! command sh -c (node install/libvips && node install/dll-copy && prebuild-install) || (node install/can-compile && node-gyp rebuild && node install/dll-copy)
npm ERR! sharp: Downloading https://github.com/stechstudio/libvips-lambda/releases/download/v1.0.1/libvips-8.5.5-lambda.tar.gz/v8.14.4/libvips-8.14.4-linux-arm64v8.tar.br
npm ERR! sharp: Please see https://sharp.pixelplumbing.com/install for required dependencies
npm ERR! sharp: Installation error: Prebuilt libvips 8.14.4 binaries are not yet available for linux-arm64v8

npm ERR! A complete log of this run can be found in: /home/john/.npm/_logs/2023-10-23T15_51_06_478Z-debug-0.log
node:internal/errors:865
  const err = new Error(message);
              ^

Error: Command failed: npm install --arch=arm64 --platform=linux --target=18 --libc=glibc --prefix="/home/john/workspace/app/apps/web/.open-next/image-optimization-function" [email protected]
    at checkExecSyncError (node:child_process:890:11)
    at Object.execSync (node:child_process:962:15)
    at createImageOptimizationBundle (file:///home/john/.npm/_npx/ab9ffda21675e838/node_modules/open-next/dist/build.js:231:8)
    at build (file:///home/john/.npm/_npx/ab9ffda21675e838/node_modules/open-next/dist/build.js:33:5)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  status: 1,
  signal: null,
  output: [ null, null, null ],
  pid: 29241,
  stdout: null,
  stderr: null
}

Node.js v18.18.2

Thank you for your time

Build error

./build-vips.sh 8.6.1
Building ...
Sending build context to Docker daemon  2.048kB
Step 1/6 : FROM stechstudio/aws-lambda-build:1.2.2
1.2.2: Pulling from stechstudio/aws-lambda-build
953654fc84df: Pull complete
766f9c23e423: Pull complete
19e4847e352d: Pull complete
02facedc15c1: Pull complete
979fce385656: Pull complete
3a099cdecbe0: Pull complete
859f6150aff8: Pull complete
f96df33ed052: Pull complete
a976311f5780: Pull complete
02aac3603254: Pull complete
edf9a446a2db: Pull complete
be6d327a6092: Pull complete
Digest: sha256:2918a8285c21918faad22101f4be0f74353399685990ef32710706fd9e9b4d51
Status: Downloaded newer image for stechstudio/aws-lambda-build:1.2.2
 ---> cf704dcc4e02
Step 2/6 : LABEL authors="Bubba Hines <[email protected]>"
 ---> Running in 5b4d396056d3
Removing intermediate container 5b4d396056d3
 ---> 4cf68e00aba3
Step 3/6 : RUN mkdir -p /deps
 ---> Running in dc261e86aafb
Removing intermediate container dc261e86aafb
 ---> b1ceaa3c058e
Step 4/6 : RUN mkdir -p /target
 ---> Running in 3bbd18abccea
Removing intermediate container 3bbd18abccea
 ---> 88075666a361
Step 5/6 : RUN mkdir -p /target/modules
 ---> Running in 4b6366aaffcc
Removing intermediate container 4b6366aaffcc
 ---> eeb079e266ee
Step 6/6 : ENV FLAGS="-O3"
 ---> Running in e331ec8f0208
Removing intermediate container e331ec8f0208
 ---> 8b39cf5b1324
Successfully built 8b39cf5b1324
Successfully tagged dev-lambda:latest
-------------------------------------------------------------------------------------------------
|   Begin Building zlib
-------------------------------------------------------------------------------------------------
	Downloading to /deps/zlib
	Configuring
	Building
-------------------------------------------------------------------------------------------------
|   Begin Building pcre
-------------------------------------------------------------------------------------------------
	Downloading to /deps/pcre
	Configuring
	Building
-------------------------------------------------------------------------------------------------
|   Begin Building ffi
-------------------------------------------------------------------------------------------------
	Downloading to /deps/ffi
	Configuring
	Building
-------------------------------------------------------------------------------------------------
|   Begin Building png16
-------------------------------------------------------------------------------------------------
	Downloading to /deps/png16
xz: (stdin): File format not recognized
tar: Child returned status 1
tar: Error is not recoverable: exiting now

g++: error: ../vendor/lib/libffi.so: No such file or directory

This error occurs when building sharp with the outputted .tar.gz

package build using ./build-vips.sh 8.5.5

make: Entering directory `/var/task/build/node_modules/sharp/build'
  TOUCH Release/obj.target/libvips-cpp.stamp
  CXX(target) Release/obj.target/sharp/src/common.o
  CXX(target) Release/obj.target/sharp/src/metadata.o
  CXX(target) Release/obj.target/sharp/src/operations.o
  CXX(target) Release/obj.target/sharp/src/pipeline.o
  CXX(target) Release/obj.target/sharp/src/sharp.o
  CXX(target) Release/obj.target/sharp/src/utilities.o
  SOLINK_MODULE(target) Release/obj.target/sharp.node
g++: error: ../vendor/lib/libffi.so: No such file or directory
make: *** [Release/obj.target/sharp.node] Error 1
make: Leaving directory `/var/task/build/node_modules/sharp/build'
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/var/lang/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:276:23)
gyp ERR! stack     at emitTwo (events.js:106:13)
gyp ERR! stack     at ChildProcess.emit (events.js:191:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:215:12)
gyp ERR! System Linux 4.9.41-moby
gyp ERR! command "/var/lang/bin/node" "/var/lang/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /var/task/build/node_modules/sharp
gyp ERR! node -v v6.10.3
gyp ERR! node-gyp -v v3.4.0
gyp ERR! not ok

When inspecting the build .tar.gz instead of seeing lib/libffi.so I see a dir lib/libffi-3.2.1

lib
- libffi-3.2.1
- - include
- - - ffi.h
- - - ffitarget.h

Build error

I am making a build with vips version 8.7.4 and getting error in ghostscript.

In file included from ./base/sjpegc.c:29:0:
./base/jmemcust.h:21:21: fatal error: jmemsys.h: No such file or directory
#include "jmemsys.h"
^
compilation terminated.
make: *** [obj/sjpegc_1.o] Error 1

Error from Python bindings: undefined symbol: g_variant_dict_ref

I'm trying to use the libs you have available with pyvips but I always get this error:

cannot load library libgobject-2.0.so: /var/task/libgobject-2.0.so: undefined symbol: g_variant_dict_ref.  Additionally, ctypes.util.find_library() did not manage to locate a library called 'libgobject-2.0.so': OSError
Traceback (most recent call last):
  File "/var/task/lambda_function.py", line 2, in lambda_handler
    import pyvips
  File "/var/task/pyvips/__init__.py", line 39, in <module>
    gobject_lib = ffi.dlopen(_gobject_libname)
  File "/var/task/cffi/api.py", line 140, in dlopen
    lib, function_cache = _make_ffi_library(self, name, flags)
  File "/var/task/cffi/api.py", line 786, in _make_ffi_library
    backendlib = _load_backend_lib(backend, libname, flags)
  File "/var/task/cffi/api.py", line 781, in _load_backend_lib
    raise OSError(msg)
OSError: cannot load library libgobject-2.0.so: /var/task/libgobject-2.0.so: undefined symbol: g_variant_dict_ref.  Additionally, ctypes.util.find_library() did not manage to locate a library called 'libgobject-2.0.so'

This errors means that the .so was found but failed to load.

Here's a copy of the packaged project (literally all it does is import pyvips): https://drive.google.com/file/d/0BzTQ-TolcOhSTkZrUk9KQ01qS3M/view?usp=sharing

My guess would be it's something to do with how the cffi Python module has been built. Amazon requires Python 3.6 on lambda but only has 3.5 on their AMIs. So Python 3.6 has to be built from source and then cffi has to be built from source.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.