Tag versions

[PaulWalkerUK]

One of the standards I see when on hub.docker.com is using tags for version numbers. This is useful because it allows people to specify which version of the application they want and enables reproducible builds.

Is this something that could be considered here please?

[kuzi-moto]

I agree, this would make a lot of sense. This and creating automated builds are high on the priorities for me with the Docker image. Just haven't had a lot of time lately to mess around with it.

[lachlan-00]

beyond bugfixes there won't be anything major happening with the 4.2 branch. when 5 comes out it's going to change a lot of things so we'll probably need to tag a difference between 4&5

[PaulWalkerUK]

Just to elaborate a little for the sake of clarity, I'm meaning that the Dockerfile should install a specific version of Ampache (and dependencies where appropriate) and be tagged on Docker Hub with that version. That way, if anyone runs docker run ampache/ampache:4.2.4 today, they'll get exactly the same application as they will if they run it next year etc.

As it is today, the image gets built with whatever is current at the time. I can see why this might be seen as advantageous (always have the current version), but I think it's preferable to have reproducible builds. The latest tag can be used to always point to the current version

[lachlan-00]

it's definitely going to start being relevant once we get ready for 5 and it will actually be a good way of providing a beta/preview release for things.

[lachlan-00]

now that i'm using the release zip files we should be able to make a variable for releases and set their label.

something like this. i'll test after making the new builds

[PaulWalkerUK]

Sounds good. I assume that can also be done for the "nosql" variant as well?

[kuzi-moto]

To be honest, I'd prefer that be the default, and drop the integrated SQL server since it's a new major version and we can introduce breaking changes like that :)

[lachlan-00]

I just did a 4.2.5 build with the Arg (takes forever on my docker server to build arm) so I'll update the config with the arg

I'm not a docker person but it does seem to be anti-docker to include the webserver and MySQL in the same image?

[kuzi-moto]

I'm not a docker person but it does seem to be anti-docker to include the webserver and MySQL in the same image?

I'm at least above-beginner level, but I have done quite a bit of research on it. According to Docker's Best practices for writing Dockerfiles:

Each container should have only one concern. Decoupling applications into multiple containers makes it easier to scale horizontally and reuse containers. For instance, a web application stack might consist of three separate containers, each with its own unique image, to manage the web application, database, and an in-memory cache in a decoupled manner.

It seems like it would be a good idea to follow these as much as possible. I'd be willing to write up a guide or something to go along with it, so that the transition could be easier for others. If we are going to do this, would be a good idea to give plenty of heads up beforehand though.

[lachlan-00]

I'm going to do a source-changes/V5 preview so when those start I'll ping this issue with it.

[jmtd]

I'm not a docker person but it does seem to be anti-docker to include the webserver and MySQL in the same image?

It’s not a settled matter, really. For consumer end users, there’s a lot of appeal having a one-container-just-works solution.

[lachlan-00]

Preview of source changes is in (nosql only)

https://hub.docker.com/layers/ampache/ampache/preview/images/sha256-b30a46caa6835bf9f30cb09c8d559985152211227bf8d04168827ea031fab14d?context=repo

So then the question is do we just keep it as latest/nosql or do we change to latest/plussql?

I'm okay with keeping things the way they are unless there's a decent reason to change.

We only added nosql this year so is that too big of a change to what we've had for years before or is that okay to do for 5 if we keep 4 tags

[PaulWalkerUK]

I think the "docker way" would be to have the Ampache application in one container and the database in another. One way to co-ordinate this would be with Docker Compose.

There are already official MySQL containers on Docker Hub, so it should be possible to just use one of those.

Because the dependency would be maintained in the docker-compose.yml file, for anyone like @jmtd who wants it to "just work", it's all there (just run docker-compose up). For anyone who wants to use a different database solution, it's simple to modify the compose file as required but still have the benefit of using the same standard Ampache application container (which isn't bloated with a database they don't need).

[jmtd]

Because the dependency would be maintained in the docker-compose.yml file, for anyone like @jmtd who wants it to "just work", it's all there (just run docker-compose up).

That's not sufficient, I'm afraid. The number of people who have docker-compose installed or are familiar with it is a small fraction of the total users of Docker. And a fair chunk of the ecosystem have moved to docker-alternatives (podman, etc.) which don't (yet) have a working analogue for docker-compose. I use it, but I work on containers full-time. I've also had a load of stuff break when they totally overhauled the specification for the input YAML file. With the single-container solution, even having the container (re)start on boot is as simple as a docker run --restart=always…

Besides docker-compose there is (or was) also docker stack, which at one point was an attempt to do compose but inside Docker itself, but I don't see much talk about that in recent years so I don't know what's happening or happened to it. (and I doubt podman etc have grown support for that)

Of course implement what you are prepared to support but don't be under the illusion that a multi-container solution addresses the needs of people who want a turn-key solution.

[PaulWalkerUK]

I have no particular involvement in this project, so it certainly isn't up to me. I was just putting forward my understanding of the docker way of doing things/best practices, but I don't claim to be an expert.

For my own particular use-case, I have a separate database solution, so don't want my application container bloating with a database I don't need. Now there is the "nosql" tag, that should satisfy my requirements (if/when it is also tagged with specific version numbers - which is what this ticket was about in the first place). How the maintainers of this project go about maintaining these variations is, of course, up to them

[lachlan-00]

So to me it seems like keeping mysql in the latest tag is a good thing.

Then if you have the inclination and the knowledge the nosql tags are available.