Switch to Debian to make usage of OpenCV feasible about hydrus-server-docker HOT 8 CLOSED

Is this really to much to build?

I'm in favor of keeping the alpine build, due to it being so slim.

So far I've found two docker files related to images with openCV, here and here.

While I can understand not wanting to use someone else's image, it doesn't look to bad to build. In saying that however, I'm not super versed in making images, so I may not know something that could be considered obvious.

As to hydrus mainly being tested on Debian based distros, has there been an issue with alpine so far? I think it'd be nice to have something where we can show that it's not just limited to those systems. If there's nothing breaking the server, there's no need to shift from something that is providing a nice benefit.

from hydrus-server-docker.

from hydrus-server-docker.

I understand.

Though regarding this: especially since the recent security issues came to light,
wasn't that marked as a non issue as there's nothing to switch users in the base image?

from hydrus-server-docker.

Though regarding this: especially since the recent security issues came to light,
wasn't that marked as a non issue as there's nothing to switch users in the base image?

To quote Cisco:

The likelihood of exploitation of this vulnerability is environment-dependent, as successful exploitation requires that an exposed service or application utilise Linux PAM, or some other mechanism which uses the system shadow file as an authentication database.

So yes, I think you are right in assuming that it's a non issue for our use case. I mainly wanted to give an example of what issues can come up when using outdated base images. Should've probably picked a better one specifically in regards to Docker.

Still, keeping base images as up-to-date as possible is certainly considered best practice and is something I'd like to follow.

from hydrus-server-docker.

I might be missing something here then, isn't the arch image up to date?
It's sounding like you want an update everytime there's a hydrus release, but I think an update isn't warranted if nothing was changed.
Is alphine's image out of date with their releases?

from hydrus-server-docker.

I might be missing something here then, isn't the arch image up to date?

Not sure what you mean with arch image, do you mean base image?

If yes, when you use FROM, you are effectively just pulling the base image, not rebuilding it, which means it will be as up-to-date as the last build of it that was pushed (to Docker Hub or whatever registry you are pulling from).

This means, when you rely on base images, you want to make sure those are updated regularly. That's usually the case with (semi-)officially distributed images (e.g., https://hub.docker.com/_/python) but might not be with user-maintained ones (like the two you've linked before).

It's sounding like you want an update everytime there's a hydrus release, but I think an update isn't warranted if nothing was changed.

I disagree – it's not about never change a running system in this case, we are mainly talking about (security) fixes that you will miss out on if you never (or seldom) update your base image.

And Docker containers are ephemeral by nature – it's not intended that you make extensive changes in a running instance (e.g., running updates manually). You need to update when building the image instead.

Therefore, this project operates in the following way:

• hydrus (server) is included as a submodule
• Whenever a new hydrus release comes out, I pull those changes to my submodule and make a new release
• The autobuild on Docker Hub then builds new images (latest and the current hydrus version number)

I like this approach mainly due to the following two benefits:

• I have full control over the hydrus code and can make adjustments/fixes if necessary (e.g., there was a bug in the past where the server would unnecessarily try to load wxPython – I just commented that import out and let the hydrus dev know about it, he fixed it with the next release)
• The user can just pull the latest image every time there is a new release and can rely on getting an up-to-date build with the latest (security) fixes included

And yes, I want to release a new version with every new hydrus release, even if there were no server-related changes. If just for the already mentioned fixes. The user is free to follow that release cycle or skip releases. :)

from hydrus-server-docker.

Not sure what you mean with arch image, do you mean base image?

I meant Alpine, but I derped.

Now it does seem we got desyned a little.

This means, when you rely on base images, you want to make sure those are updated regularly. That's usually the case with (semi-)officially distributed images (e.g., hub.docker.com/_/python) but might not be with user-maintained ones (like the two you've linked before).

The two links I provided where to the docker files themselves. I apologize, I was trying to imply that you could look at the dockerfiles to see how they where building the openCV stuff, not that you should use those images. That was my mistake, should have explained that better.

This section before is what throws me off a little:

So yes, I think you are right in assuming that it's a non issue for our use case. I mainly wanted to give an example of what issues can come up when using outdated base images. Should've probably picked a better one specifically in regards to Docker.

Still, keeping base images as up-to-date as possible is certainly considered best practice and is something I'd like to follow.

To me that made it seem like you want a base image update alongside every hydrus release. That wasn't making sense to me. Sure, if the base image has an update, or hydrus, yeah that calls for this image to be updated.

My comment:

It's sounding like you want an update every time there's a hydrus release, but I think an update isn't warranted if nothing was changed.

Is meant to say, if there's no base image update, and no hydrus update, then there's no need to update, because there's nothing to update.

I get what you're meaning now though, sorry for the misunderstanding.

from hydrus-server-docker.

Is meant to say, if there's no base image update, and no hydrus update, then there's no need to update, because there's nothing to update.

Sorry, I misunderstood then. Of course, I only make a new release whenever a new hydrus version comes out. Or, if the hydrus dev might take a break for a while and stop his weekly releases, I might still push a new version every month or so, to keep the base image up to date. :)

from hydrus-server-docker.