search

amule-project / amule

'All-platform' P2P client based on eMule
1.01k stars 221 forks source link

Transfer scattered docker attempts to an unified multi-arch building docker image inside the amule project #303

Open viperey opened 3 years ago

viperey commented 3 years ago

Hi there. I'd like to propose to include inside this repository the files and docs needed to make the amule project "officially" support docker.

The dockerization itself is not mine, it's based on the (amazing) work previously made by other devs (check the README).

I'm basically gathering such knowledge, giving it some packaging around a single image/tag with multi-architecture support.

It would be nice also to hear about @tchabaud & @synopsis8 opinions in this regard.

The PR has big areas of improve, but I'd say, this is a valid starting point for this proposal and It will be positive to hear the feedback from the rest of the community before proceeding with any further work and steps.

Best.

synopsis8 commented 3 years ago

For me, it completely makes sense. I'd fully support that, I just had no time after some unsuccessful attempts. It this would also automate the docker builds, that would be awesome

t-chab commented 3 years ago

I totally agree too, it would be a nice improvment if Dockerfile could be merged upstream.

ngosang commented 2 years ago

If you use debian as base image you can build for more architectures. I'm not building from source but it's possible since someone is building official packages.

minnyres commented 2 years ago

It is actually not necessary to write a dockerfile for each CPU architecture. I can build a multi-arch aMule docker image by

docker buildx build -f official-2.3.3/Dockerfile  --platform linux/arm,linux/arm64,linux/amd64  -t minnyres/amule-dlp:official-2.3.3 . --push
Vollstrecker commented 2 years ago

As versions are scattered all over these files, who want's to maintain this stuff? The same guy that wrote upnp-1.6.22 a version that's over 5 years old? And cryptopp-5.6.5 from 6 years ago? If anything goes wrong we get bugreports where we ask for more current versions and the users tell us that they can't influence that?

And why should we distribute a dockerfile that explicitely loads other thems because ours is ugly?

minnyres commented 2 years ago

As versions are scattered all over these files, who want's to maintain this stuff? The same guy that wrote upnp-1.6.22 a version that's over 5 years old? And cryptopp-5.6.5 from 6 years ago? If anything goes wrong we get bugreports where we ask for more current versions and the users tell us that they can't influence that?

And why should we distribute a dockerfile that explicitely loads other thems because ours is ugly?

I agree. There is no need to build from source. To make thing easier, we can maintain a Debian based docker image that install aMule via

apt install amule-daemon

or

apt install amule

I also wonder if it is possible to build a static release for Linux like that: https://github.com/userdocs/qbittorrent-nox-static

Vollstrecker commented 2 years ago

If you want to install via apt, there is a repo (it's the original debian repo), I don't see any point in adding docker around the binary. If the binary doesn't work in the distros that are shipping it, this needs to be fixed, not worked around. You noticed the problems with log4j, Java like to bundle stuff and noone could easily tell where the broken lib was in. Docker has the potential to do the same.

For the static build, with autotools there is an option to do that, with cmake I'm working on dependant libs to make it possbile.

ngosang commented 2 years ago

@minnyres I already did most things you mentioned.

Although I'm not doing it, I think it is a good idea to build aMule and all required libs from source code in the Dockerfile. In that way we don't have to wait for new Debian packages. We can build Docker images automatically in every PR or commit. We can also control the exact versions of the libraries and compile them with specific parameters if required. Docker allows multi-stage builds, so you can install the build dependencies an compile in one stage and include only the final executables in the final image. That is what we are doing in Gerbera (another C++ project) => https://github.com/gerbera/gerbera/blob/master/Dockerfile

Anyway, the main concern with this project is the inactivity. There are several important issues related to memory leaks, bad traces and crashes... no one is taking care of them so this is low priority for me.

I will maintain my repository and Docker images updated. You can copy all you need from my repository too. https://github.com/ngosang/docker-amule

minnyres commented 2 years ago

@ngosang great work! Hope these issues can be solved one day.