Comments (16)
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.
from ampache-docker.
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.
from ampache-docker.
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
from ampache-docker.
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 :)
from ampache-docker.
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.
from ampache-docker.
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
from ampache-docker.
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
from ampache-docker.
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.
from ampache-docker.
Sounds good. I assume that can also be done for the "nosql" variant as well?
from ampache-docker.
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?
from ampache-docker.
I'm going to do a source-changes/V5 preview so when those start I'll ping this issue with it.
from ampache-docker.
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.
from ampache-docker.
Preview of source changes is in (nosql only)
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
from ampache-docker.
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).
from ampache-docker.
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.
from ampache-docker.
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
from ampache-docker.
Related Issues (20)
- Database setup seems to fail on install HOT 1
- MariaDB not starting with ampache:5.6.2 HOT 11
- Web browser not playing songs when using non-standard port HOT 3
- Unable to upgrade to 6.0.1 HOT 3
- Multiple Entries per Song after fresh creation HOT 2
- 6.1.0 Docker Images HOT 2
- Reverse proxy for Apache? HOT 1
- Unable to query the database, check your Ampache config (after first run) HOT 6
- Ampache 6.2.0 docker builds needed HOT 1
- Docker image doesn't run on (older) Synology NAS HOT 10
- Apache2 entered FATAL state, too many start retries too quickly HOT 1
- Support for Docker Rootless mode HOT 2
- Config file outdated - ampache 6.x.x ships config_version 62 HOT 3
- Database fails on Compilation custom metadata tag HOT 3
- Setting web_path results in 404 after setup HOT 6
- ampache/ampache:nosql-preview comes with mariadb installation HOT 3
- [Question] about container configuration HOT 7
- To create volume folders or not to HOT 3
- Issue With Data & Media Directory HOT 2
- Is FFMPEG Transcoding available via the :latest Docker image? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ampache-docker.