Ref alpinelinux/docker-alpine#182

If I may, I have a suggestion in order to avoid issues like in the future is to not switch alpine and fpm-alpine tags to the new major Alpine release until the first patch released, i.e. keep it on Alpine 3.13 until 3.14.1 released. The solution to upgrade docker is not really a solution.

Eventually, the release encoded in those unversioned tags would reach EOL, and then we're in the same tough place. As a more extreme example, would you also suggest that php:latest should still point to PHP 5.5 on a very old (long-since EOL) release of Debian?

The more specific aliases exist specifically to give users an escape hatch to stay on a specific underlying distribution release and control their own consumption and upgrade timing. Just like users using :latest, users using a bare alpine tag should expect some degree of breakage over time, and I don't think there's much we can reasonably do about that.

(This is also the common pattern of usage/tagging across all the official images -- PHP is not unique in this regard.)

I think the only thing unique about this particular bump is that the most common breakage is more disruptive than usual, but there's not really much we can do about that, given it's a change in musl/Alpine itself (https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.14.0#faccessat2).

Ok, I see your point, there's no place for tricky logic when you maintain so many images and yes, I can always use more specific tags that include the alpine version. To be clear I didn't mean to never update latest, I meant that some changes are bigger than the others, like a major release of alpine that affects so many images and maybe there's a way to not hurry with those updates but I guess it's all automated in your CI. To be honest, I was under impression that update to the new major Alpine version wasn't usually that fast as it was this time but probably that's just my perception, I don't really know your process in details.

The solution to upgrade docker is not really a solution.

By this I meant the solution to this musl problem suggested in the referenced issue

If I may, I have a suggestion in order to avoid issues like in the future is to not switch alpine and fpm-alpine tags to the new major Alpine release until the first patch released, i.e. keep it on Alpine 3.13 until 3.14.1 released.

Alpine Linux drops support for the community repository when a new release occurs, meaning no security updates for community packages. Point releases are made primarily for the purpose of updating required bootstrap packages such as linux, musl, and apk, not as an arbitrary stability marker. It is expected that the .0 release is stable and suitable for production use.

The solution to upgrade docker is not really a solution.

Docker 20.10 was released 9 months before Alpine 3.14. Docker 19.03 is now officially EOL. It is unreasonable to expect volunteer projects to expend effort to support EOL software. Moreover, the premise is not even correct. As documented in the Alpine Linux 3.14 release notes, there are alternatives available to upgrading Docker, and the majority of Linux platforms do not require Docker 20.10 for faccessat2 support.

I ran into the same issue and opened alpinelinux/docker-alpine#182 with a detailed information of my docker setup

Anecdotally, I have the same problem on Docker 20.10.8 on Ubuntu. 3.13 images work.

Yep, this is https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.14.0#faccessat2.

Options for fixing it are updating Docker / libseccomp / runc or switching to the Alpine 3.13 variants (which have a related/similar issue, but one folks hitting this one are probably less likely to hit: https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.13.0#time64_requirements).