Alpine 3.4 is out, and essentially just wondering if there is a time frame for updating the alpine image (at least the mainline one) to 3.4. I appreciate y'alls time!
Thanks for letting me know!
I'll update the alpine builds for mainline the next time nginx release is out (hopefully in a couple of weeks).
+1
I am using kubernetes with nginx alpine, and there is a bug with Kube-DNS that is resolved with alpine 3.4. Basically when running alpine <3.4, I can't resolve services properly by their hostnames.
Seems like a switch to 3.4 would also fix critical security vulnerabilities (e.g. OpenSSL). At leat that's what I get from comparing
+1
Also, Alpine 3.4 has the new client for Let's Encrypt certbot out of the box!
@mattrobenolt Ah, great :) Just waiting it to be published officially at DockerHub!
Any idea when the 3.4 image will be available on DockerHub?
Sounds like at the next release...though I wish I knew when that was to be honest!
New release nginx 1.11.3 (26 Jul 2016)
When will DockerHub be updated?
Please release new nginx with alpine 3.4. The DNS resolution issue pointed by @zacharynevin is becoming blocker.
It's also committed in master branch. Can we please update on docker cloud and not wait for new nginx version?
@adityapatadia So the 3.4 is already set as you said, it seems the maintainers release new docker images alongside new nginx versions only, the PR #112 has been open since the release of 1.11.3 two weeks ago, but @thresheek seems to be the maintainer on this repo and is MIA. @VBart seems to be a maintainer on the NGINX org so perhaps knows of someone else who can complete the 1.11.3 update and publish the image to Docker Hub.
In the meantime, you could build the image yourself, and there many people who publish their builds publicly on Docker Hub.
My point is that @thresheek should release new version even when there is no nginx version because the alpine version of nginx is critically broken because of the issue of linked service name resolution issue. There are also critical security fixes, ALPN protocol support and certbot inclusion which makes the release worth efforts. By not releasing 3.4 version of alpine, users of this image are exposed to critical security issues which are now public.
Now I can of course build new image myself but that will mean bloating docker-hub without any real reason. I also prefer to use official version of nginx on production server. I expect him to publish new version on docker hub even when new nginx release has some time to go.
I'm not a maintainer of this repository, but I'm going to do what I can to try and handhold it along. See: https://github.com/nginxinc/docker-nginx/pull/115 This script is needed to generate some output that's needed for updating https://github.com/docker-library/official-images
With this script, I can submit a PR over at https://github.com/docker-library/official-images to get it updated, but I feel a bit awkward since this is stepping over my boundaries, since I'm not a maintainer of this image at all. 馃槵
Let's wait for maintainer of this repo to do it. I hope it to get resolved soon.
Unfortunately it appears the maintainer of this repo is unreachable (maybe no longer an NGINX employee?). I suggest @mattrobenolt proceed to submit a PR to docker-library/official-images since you have a fork with the necessary changes already, if you're willing - I can assist if needed. They have a review process before publishing updates.
I'd rather pull in @tianon and @yosifkit for their opinions first. :) Since I have other pending PRs that would need to be merged to make this happen. Also the official repos are linked against shas pointed to a repo. So that'd mean the official locations would change if we were to point it to my fork, which... I wouldn't necessary think is wise.
I'd much prefer other maintainers get added here. I'd be willing to step up to that though, but that's out of my control.
Awesome @mattrobenolt - thanks for jumping on this! I had a quick read of the maintainers info - I think it means the hashes will correlate so long as the original history is kept in whatever new repo (forks, clones etc) if the original repo can't be transfered for whatever reason. But I'm not an expert on the matter. Agree it would be simpler if a team admin for @nginxinc could add you as a contributor to this repo.
I think it means the hashes will correlate so long as the original history is kept in whatever new repo (forks, clones etc) if the original repo can't be transfered for whatever reason.
Yeah, of course. I just don't want an official package pointed to an unofficial fork on my personal account. All around, that's more sketchy for the community as well. And all related metadata would have to be updated to point to my fork. All of which, would de-legitimize the official package itself since people expect that to be coming from Nginx Inc. Not a random person on the internet.
Sorry for the lack of activity - I'm currently on the extended vacation, will take a look about that later in August.
Any idea when will it be released to docker hub?
I am sorry, it's already released. Thanks.
Most helpful comment
Sorry for the lack of activity - I'm currently on the extended vacation, will take a look about that later in August.