sbt-native-packager icon indicating copy to clipboard operation
sbt-native-packager copied to clipboard

Default Docker permission strategy should be Run

Open TimMoore opened this issue 6 years ago • 6 comments

Very simple reasoning. Current code works only with docker >=17.09. Run version works with any docker version.

That's why default version should be Run, because it works everywhere. Then if there's an extra option provided for how to deal with 'chown' or explicit strategy to use - it should switch to '--chown' version.

It is bad to make backward incompatible changes from feature requests, always think about majority, if one wants to save 130MB from 2GB footprint -> sure that's a great thing, but make it so it requires an extra config option if you can't provide a reliable switch mechanism (read Regex version parser, which is unreliable in my opinion).

Originally posted by @kotdv in https://github.com/sbt/sbt-native-packager/issues/1230#issuecomment-495535204

TimMoore avatar May 29 '19 01:05 TimMoore

This is a though one. Typically this would be the way to go for sbt-native-packager (batteries included, all works out-of-the-box). However we add issue after issue and question after question why the docker image is so big.

My point would be that the "my docker version is too old" issue will solve itself, while the "image is too big" won't. I have no idea what the current distribution of docker versions is, but hopefully people update :stuck_out_tongue_winking_eye:

Does this make sense?

muuki88 avatar Jun 12 '19 18:06 muuki88

It doesn't make sense, because Ubuntu 16.04 is LTS release which is and will be supported for a very long time still, and it's current docker version is 17.05. It's not like people are running some rolling releases or Arch Linux in production, right? I bet there are similar issues with stable Debian, or let's say latest or prior version of Red Hat as well.

kotdv avatar Jun 12 '19 22:06 kotdv

Maybe it could default to the more compatible behaviour, but when validating that the permission strategy is compatible with the current Docker version, if it detects a newer Docker version that supports better permission strategies than what's set, it could log a warning saying "to get smaller images, set dockerPermissionStrategy…" etc.

TimMoore avatar Jun 13 '19 04:06 TimMoore

t doesn't make sense, because Ubuntu 16.04 is LTS release which is and will be supported for a very long time still, and it's current docker version is 17.05

Still you can upgrade your docker version. LTS doesn't mean all versions are frozen, right?

Maybe it could default to the more compatible behaviour, but when validating that the permission strategy is compatible with the current Docker version, if it detects a newer Docker version that supports better permission strategies than what's set, it could log a warning saying "to get smaller images, set dockerPermissionStrategy…" etc.

That would be a good solution :+1: The steps would be then if I got this right:

  1. Default DockerPermissionStrategy.Run
  2. if docker version supports
    1. MultiStage use it
    2. CopyChown use it

Change the docker permission strategy validator to give a warning, when a better permission strategy is available.

muuki88 avatar Jun 14 '19 07:06 muuki88

Still you can upgrade your docker version. LTS doesn't mean all versions are frozen, right?

You can build it from sources, use some incompatible apt source distribution, or maybe some PPA with some luck, 17.05 is the latest version which is coming from official docker apt sources repository for 16.04 and is what you get if you follow official docker installation docs and fully updated. I'm not saying it's impossible to upgrade, I'm saying that forcing everybody to upgrade to something is not the best strategy to use by default.

kotdv avatar Jun 14 '19 08:06 kotdv

I'm saying that forcing everybody to upgrade to something is not the best strategy to use by default

I understand your point :smiley: What I tried to say was that currently people need to configure sbt-native-packager to work with older docker versions, but in the future (1-2 years maybe) this won't be the case anymore.

However @TimMoore convinced me that a warning when a better image size is possible via configuration, we should warn the user and hope it doesn't get ignored :smile:

muuki88 avatar Jun 14 '19 09:06 muuki88