Switch to hexpm/elixir and Fuly Qualified Tag Names

[restlessronin]

I really like being able to specify the version of every piece of the runtime (elixir, erlang and linux). The official elixir docker image does not tag images with this much information.

However, the hexpm/elixir images do provide this information in the tags. May I suggest that we switch to those images, and provide more detailed tag names on the nicbet images? We should actually even make the tag names longer and include the Node version (which is already parameterized along with the phoenix version).

If this makes sense, I can work on a PR for the dockerfile, but I don't believe I'm able to do the CI work.

[nicbet]

For folks that come across this issue in the future:
hexpm's bob builds the Docker image matrix: https://github.com/hexpm/bob/blob/main/lib/bob/job/docker_checker.ex#L5

As for this repo: I'm not opposed to the idea to add support for more verbose image tags (apart from 'latest' and v<Phoenix Version>) to include Elixir and NodeJS versions.

However, not so sure about the merit of support and building a whole matrix of different versions and combinations thereof. Even with a few variables things can quickly consume a good amount of CI resources:
Let's say we support NodeJS maintenance, LTS, current and pending releases, that's 5 versions, let's say we put that on 3 platforms (Debian, Ubuntu, Alpine) with 3 versions each (lts, current, next), and support that for the previous, current and latest elixir version ... that's a over a hundred images to generate, publish, host and distribute...

One of the core drivers of this project was to preserve your dev, build, runtime environments in the form of what was available (or would have been if you come back in the future) as the stack at the moment when you created your Phoenix project at the time of a given Phoenix framework release. For this reason you will see that perhaps in a given image for a given phoenix release the Elixir version may not be the latest right now, but it was the version of Elixir that was released at the time of that particular Phoenix release.

That said, if you need a combination of runtime deps different from what comes out of the box, you can easily change the Dockerfile to what you need. I really don't see this repo as a staging ground for a whole host of prefab Docker images, but rather starting point for getting a phoenix/elixir environment up and running quickly, especially for dev. With the recent focus on VSCode dev containers, that becomes even more true: you clone this repo, maybe adapt the Dockerfile to your needs, fire up VScode and open the folder in a dev container and you are off to the races.

Imho, the best option would actually be if Phoenix's built-in generators for projects created a .devcontainer folder or at least a 'Dockerfile.dev' out of the box - then this repo could easily become obsolete ;-)