чт, 16 мая 2019 г. в 23:22, Tim Düsterhus <[email protected]>:
> Aleks, > > Am 16.05.19 um 01:04 schrieb Aleksandar Lazic: > >> As a avid Docker user: I tend to absolutely avoid any Docker images that > >> are not built using Docker Hub's autobuilder, because I cannot verify > >> the Dockerfile myself (or cannot verify that the resulting image > >> actually matches the Dockerfile). And for the images using the > >> autobuilder: They are super crap more often than not. > > > > Sorry, I don't understand this statement, what do you mean? > > Compare these two images: > https://hub.docker.com/r/me2digital/haproxy20-centos > https://hub.docker.com/r/timwolla/znc > > You'll note that for mine the source repository and the Dockerfile is > shown. Mine uses Docker Hub's autobuilder, which builds the Dockerfile > on Docker Hub, instead of pushing an externally built image. > > For me the ones from the autobuilder are more trustworthy, because I > know that the "contents match the labeling" if I trust Docker Hub. The > others could contain anything and I could not verify this, I need to > trust every maintainer. > > >> I don't see any benefit whatsoever for HAProxy to provide image > >> themselves. The image in the docker-official-images program is timely > >> updated using a scraper [1], it is of high quality (of course )and the > >> fact that it's part of the DOI program makes it highly trusted among > >> Docker users. Also I keep half an eye on that image to make necessary > >> adjustments. > > > > Well why I build the images by myself because I need newer libraries, for > > example openssl with tls 1.3, which is not part of the official build. > > TLS 1.3 is supported with the :alpine image: > > [timwolla@~]docker run -it --rm haproxy:alpine haproxy -vv |grep TLSv > OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3 > alpine is evil, it uses musl which claims to be libiconv, but actually it misses several things. do you run reg-tests after build ? do we run valgrind or some sanitizer on that images ? > > It will be supported for the Debian one once Debian Buster is released > (I expect that to happen before August, but don't quote me on that). > > Personally I think that TLS 1.3 is nice to have, but I don't *need* TLS > 1.3, because many users won't benefit from it, yet. I also don't run > HAProxy in a container, but that's a different matter ... > > > Does "they" accept pull requests which changes a lot in the docker file > or how > > they behave. > > The policy from them is: Do what upstream recommends and be conservative > otherwise. The images should fit the majority of users and I believe > they do. Everyone else is free to create their own image (like you do). > > Regarding TLS 1.3 specifically see this issue: > https://github.com/docker-library/haproxy/issues/74 > > > I have not a very good feeling about this docker-official-images program > as from > > my point of view docker have change in the past so much parts (apis, > gui, ...) > > that I'm not sure how they behave in the future. > > I am personally a maintainer of two of these images (adminer, spiped) > and I contribute pull requests, issues and opinions on the others and I > believe that the images are as good as they can possibly get without > jumping through a bunch of hoops such as manually compiling OpenSSL. Any > piece of software that is self-compiled needs to be monitored for > security vulnerabilities to update the image and especially OpenSSL does > not have a good track record regarding security. > > > But you know I'm open for suggestions, so if we agree that the > > docker-official-images is the image which the haproxy community can > commit to it > > I'm fine with it. > > As a Docker user (and official image maintainer) and HAProxy user (and > code contributor) I believe that the docker-official-images HAProxy > image is the best general purpose (!) image you can find and I believe > that the DOI team does a good job maintaining those images to be useful > for the majority of users. > > Best regards > Tim Düsterhus > >
