------ Originalnachricht ------
Von: "Bryan Talbot" <[email protected]>
An: "Aleksandar Lazic" <[email protected]>
Cc: "HAproxy Mailing Lists" <[email protected]>
Gesendet: 01.11.2017 21:25:34
Betreff: Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile
On Nov 1, 2017, at Nov 1, 3:28 AM, Aleksandar Lazic <[email protected]>
wrote:
There is now a shiny new docker image with the rc1.
docker run --rm --entrypoint /usr/local/sbin/haproxy
me2digital/haproxy18 -vv
For the past couple of years, I’ve also been maintaining a base docker
image for haproxy. It is interesting to see how other’s structure the
build and configuration.
I see that you include a base / default configuration file while I’ve
left that completely up to the user to provide one. Given how many
different ways people use haproxy, it didn’t seem that there was any
one “basic” config that would work beyond a trivial example. I’m
curious how useful the configuration you’ve packaged is. I use my image
as a base which I then repackage use-case specific configuration files
into for deployments and I assume anyone else using the image does the
same thing, but I do not have any feedback about that.
https://hub.docker.com/r/fingershock/haproxy-base/
-Bryan
Well the reason why I use a default config file is that most enterprise
customer mainly don't know how to configure the haproxy.
They know the destination ip:port and on which port the service should
listen.
This makes the usage of that image much easier, from my point of view.
That's the reason why the openshift template exist.
https://gitlab.com/aleks001/haproxy17-centos/blob/master/haproxy-osev3.yaml
You can use this image easily as ingress or egress proxy with 0
knowledge of haproxy.
I have described the setup a little bit in this blog post.
https://www.me2digital.com/blog/2017/08/openshift-egress-options/#haproxy-generic-proxy
With the environment variable CONFIG_FILE is it possible to use a
complete custom haproxy config file.
This can be provided as you described with -v in docker mode or with
config maps in kubernetes and openshift.
Another point is the logging.
I have added socklog into the image to get haproxy logs to stdout.
Sometimes you have now syslog server where you can send the haproxy logs
therefore the default setup in the image uses the socklog which is
designed to write to stdout and listen to a ip or unix socket.
http://smarden.org/socklog/
This could be easily overwritten by env vars
https://gitlab.com/aleks001/haproxy17-centos/blob/master/containerfiles/container-entrypoint.sh#L5
One of the reason why I have added all this into the image is that the
security level in openshift is quite high, which is good from my point
of view, but due to this fact you can's just use rsyslog image or
something else which requires root privileges.
Another feature is that the prometheus scrapper is there and is used as
sidecar container, at least in my openshift template.
I know there are some options to improve the image, I'm open for
suggestions, issues, pull requests ;-)
I hope I have bring some light to the question why I have build this
image.
Regards
Aleks
