-
Notifications
You must be signed in to change notification settings - Fork 361
Support Alpine #1181
Comments
Related to #1166 |
Just to make sure: are you building psol.a yourself? |
Yes, I did (following mostly https://developers.google.com/speed/pagespeed/module/build_ngx_pagespeed_from_source#dependencies):
Then looking at |
curl -L https://dl.google.com/dl/page-speed/psol/${NPS_VERSION}.tar.gz ^^^ This bit is grabbing psol.a as a binary, which is not really workable Sadly you near certainly need to hand-build psol.a for your system the (That probably expects BRANCH to be set...) On Fri, Apr 22, 2016 at 4:53 PM, Werner Beroux notifications@github.com
|
Sounds legit. My point is that a documentation for Alpine would be very welcome because it's where I think the near future lives. Ideally it'd also be package of Alpine. |
@wernight Preliminary work to get this created as an Alpine package is available here https://github.com/cchamplin/alpine-ngx-pagespeed. There is still several things that need to happen before I'll start going through the process of submitting to the Alpine repos. Most importantly is that I need it tested on fresh alpine installs. Ideally we'd also see psol updated at some point to use modern versions of libpng so that we don't have to package an ancient copy of libpng12. |
To test it, just use |
This is super important to have in place! By the way, v3.4.0 is out1 |
Can't you just test on Docker? That should be simple. docker run --rm -it Le mar. 31 mai 2016 à 20:56, Nikolay Kolev notifications@github.com a
|
I'm running https://github.com/cchamplin/alpine-ngx-pagespeed on fresh Alpine for some time now without real issues, however it seems to be not maintained. I see 3 places that would potentially welcome PageSpeed for Nginx on Linux Alpine:
I agree it'd be easier if we could use a modern libpng. |
I've a working updated |
@wernight we (Wunderkraut) would like to work together with this task to get a working version out for everyone. We had a pause in our internal development with this but have now continued with this and would like to cooperate with the effort. cc: @aleksijohansson |
@wernight Very interested, please share! |
|
@wernight Awesome, thanks! Seems to build successfully at least |
@wernight's fix was great but now doesn't play nice with version 1.12.34.1 and spits out;
|
@ciarans It might be that something has changed in the folder structure in version 1.12.34.1. I've fixed it once before in https://github.com/wunderkraut/image-fuzzy-alpine-nginx-pagespeed, but haven't updated that to the most up to date version yet. |
@aleksijohansson thanks for giving me some feedback. I would love to give debugging a the problem myself but my patch knowledge is very basic. |
@aleksijohansson after some research it looks like the following file has is causing the problem - |
I'm running version:
LIBPNG_VERSION=1.2.56
PAGESPEED_VERSION=1.11.33.3
NGINX_VERSION=1.10.1
I still see this plugin as being a great Linux Alpine package or a tag or
the official Nginx (probably harder).
|
@wernight @aleksijohansson from the work you guys did earlier I've managed to generate the following; --- a/src/pagespeed/automatic/Makefile
+++ b/src/pagespeed/automatic/Makefile
@@ -145,8 +145,6 @@
pagespeed/libpagespeed_thread.a \
pagespeed/libpthread_system.a \
pagespeed/libutil.a \
- third_party/apr/libapr.a \
- third_party/aprutil/libaprutil.a \
third_party/base64/libbase64.a \
third_party/chromium/src/base/third_party/dynamic_annotations/libdynamic_annotations.a \
third_party/css_parser/libcss_parser.a \
@@ -158,22 +156,11 @@
third_party/gflags/libgflags.a \
third_party/giflib/libdgiflib.a \
third_party/giflib/libgiflib_core.a \
- third_party/grpc/libgpr.a \
- third_party/grpc/libgrpc_core.a \
- third_party/grpc/libgrpc_cpp.a \
- third_party/hiredis/libhiredis.a \
- third_party/icu/libicudata.a \
- third_party/icu/libicuuc.a \
third_party/jsoncpp/libjsoncpp.a \
- third_party/libjpeg_turbo/libjpeg.a \
- third_party/libjpeg_turbo/src/libjpeg_turbo.a \
- third_party/libpng/libpng.a \
third_party/optipng/libopngreduc.a \
third_party/protobuf/libprotobuf_full_do_not_use.a \
third_party/re2/libre2.a \
- third_party/serf/libopenssl.a \
third_party/serf/libserf.a \
- third_party/zlib/libzlib.a \
url/liburl_lib.a
# The 'gclient' build flow uses 'xcodebuild' on Mac and 'make' on Linux.
However during the build Im now getting this;
My research shows its to do with a limits.h file not being set with PATH_MAX. Have you come across this before? Any ideas on how to get over this? |
@ciarans Haven't seen that before. When I have time to update https://github.com/wunderkraut/image-fuzzy-alpine-nginx-pagespeed I'll let you know how it goes. |
I created a automated build of ngx_pagespeed on Alpine. |
+1 for better alpine support without having to patch all the things! |
Since Google is moving other Docker images to Alpine, like their Cloud SDK, they should be supporting Alpine more broadly. Most of the hacks have fixed PS to an older version. +1 to get this done right. |
FYI, yesterday Alpine 3.6.0 got released. |
I tried to upgrade and got the same issue with __strcpy_chk and similar. It seems that it's because glibc on Alpine is very limited and doesn't implement those. I wonder if there isn't a flag to disable those (really not ideal but better than having an old version). A better option would be to use strcpy_s and such (see https://stackoverflow.com/a/25811493/167897) which might be on Alpine. I tried to disable Fortify source using |
Also, see apache/incubator-pagespeed-mod#1460, tried to build mod_pagespeed 1.12.34.2 on Alpine 3.6. AFAIK, old versions (<1.4) of grpc have problems with Alpine 3.6 |
After 5 days of a very steep learning curve I am finally getting somewhere... @nberlee , It is linked in like this and it compiles well... any ideas ?
|
Everything is working now.... BUT I receive a very wierd error |
I have setup pagespeed on my proxy that passes the requests to the backend app server. The 404 error is generated from the app server. I think the request is looking for the pagespeed cache in the backend (where it isn;t)... but.. how to prevent that ....is the next question |
I just pushed https://github.com/We-Amp/ngx-pagespeed-alpine/tree/dev
|
@nberlee great thing! do you have an idea how to convince pagespeed to link libpng statically? |
@tobsch Are you having problems with my Dockerfile as-is? If this is the case I would like to know. If you only want libpng 1.6 (which i would understand), @ashishk-1 made a commit recently in incubator-pagespeed-mod:master which would make it possible. You can use patch (I haven't tested it) https://github.com/apache/incubator-pagespeed-mod/commit/7ea8d5fc141c7067c54ffa2b9fbc552c15089ca6.patch (just save it with the other patches in my branch) Make sure to add libpng-dev in the apk add section of modpagespeed |
@nberlee it's not "as it is" but in combination with php & such. |
@tobsch could you perhaps share the tweaked patch for 1.13? |
@oschaaf here you go: https://gist.github.com/tobsch/c59b0c9b89f51a412a57c2bf8a4cbb31 I had to change the location of zlib.h, as it is now a submodule. |
@tobsch Thanks for the patch! And sure, I will take a look, but it will be
next week as I am on vacation this week. The required change is not super
straight forward (I already took a quick stab at it)
…On Mon, 26 Feb 2018 at 08:01, Tobias Schlottke ***@***.***> wrote:
@oschaaf <https://github.com/oschaaf> maybe you can help me with #1535
<#1535> in
exchange :-) ? this prevents me from using ps in production currently
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1181 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACIsRKDqZwX0p3VfRbl-9FAWGwk4LBFlks5tYlbQgaJpZM4IN6ge>
.
|
curious if there has been any progress. seems like things were close but got stuck. |
https://github.com/We-Amp/ngx-pagespeed-alpine I will contact @oschaaf to discuss to create something on Dockerhub.. |
@nberlee can you ping me at oschaaf@we-amp.com? |
Any update? Also, will these changes be packaged into the base ngx build or is the model to provide a docker image with patches? Would prefer a stable ngx alpine build without docker wrapper. |
@nberlee so the solution is to use the actual docker build and all the associated patches from https://github.com/We-Amp/ngx-pagespeed-alpine rather than getting a ngx_pagespeed that can be used outside of that setup? In the case of someone having their own nginx docker build process or using an alternate project, we will need to disassemble the docker file and assets from We-Amp to understand how to get this functional. Am understanding that correctly? |
@tspicer Your aim was to have an apk in the alpine store if I read your comment correctly? I am sorry I raised your expectation I would make or maintain such a thing. However, as docker is build on layers you can easily add stuff to the compiled docker image.
|
@tspicer @nberlee So our initial goals with the patches was to incorporate them into mod_pagespeed, but priorities changed and we didn't wrap up. But actually some of the more complex changes already actually landed to make building possible/easier for Alpine (& FreeBSD) (e.g: upgrades for grpc / libpng). Looking at them, the remaining patches seem pretty small and mundane. One of them would have to be upstreamed to Chromium, the others can probably be merged into mod_pagespeed without any problems --- except for the Makefile patch, which may need some consideration. I can't promise any timelines, but I'll see what I can do, hopefully in the next couple of weeks, to get the required level of patching for Alpine down to 0. One concern I have going forward though is that we Alpine is not tested in CI. |
@nberlee not the APK store, but just being able to compile as I would for another OS. At the moment the process to install is tightly coupled into a specific Dockerfile. If you are compiling from nginx source with alternate modules/packages and libraries, your choice is to 1) copy the docker file as provided and modify the nginx build as applicable, then customize any other parts that are warranted or 2) deconstruct the Dockerfile, grab the patches and attempt to incorporate into your own build. So no expectations were set by you :) thanks @oschaaf for clarifying |
PSOL compilation takes way too much time (~35 min on travis), so I moved it out to a separate repository before the official release become available and just download the archive (100M of objects required for nginx module compilation) during nginx build, see example. Useful if you maintain your own alpine-based nginx image and want to add pagespeed module. |
@csandanov If you would implement docker layer caching in travis (which is ok, with a tagged versions in a multi-stage docker file), builds would fly if you change something on the nginx. |
…inline), (directory structure organised for DockerHub build compatibility). (#1598) Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busy box. Alpine is therefor the most logical OS base for Docker Images. Although it does not fix #1181 completely, it helps to overcome the problems of building the PSOL on Alpine,
Accidentally closed this while merging #1598. |
The direction is going towards using Docker, and on Docker the direction is towards using Alpine base images (because they're smaller), and most main packages now support Alpine (Nginx included).
It seems that it almost compiles on
alpine:edge
. I got past the traceback by installinglibunwind@testing
package but some missing references remain:It's worth finding how to make it compile and document it.
The text was updated successfully, but these errors were encountered: