Re: Architecture guide reworked

[Willy Tarreau]

Hi Olivier,

On Thu, Jan 07, 2016 at 05:08:46PM +0100, Olivier Doucet wrote:
> I created a shared text file on framapad here :
> https://annuel.framapad.org/p/haproxy-architecture-guide

Thanks for this. I think you should simplify the "introduction" section by
simply referencing intro.txt, configuration.txt and management.txt. If you
start to re-describe overlapping parts, you can be sure these ones will
diverge again over time. Remember that it took 8 years to get rid of the
old haproxy.txt after configuration.txt was introduced!

I have nothing else to say, you plan looks good.

Thanks,
Willy

Re: Architecture guide reworked

[Olivier Doucet]

Hello,

2015-12-03 0:07 GMT+01:00 bjun...@gmail.com :

> 2015-12-02 17:31 GMT+01:00 Olivier Doucet :
>
>>
>>
>> 2015-12-02 17:25 GMT+01:00 Olivier Doucet :
>>
>>>
>>> 2015-12-02 15:44 GMT+01:00 Michel Blanc :
>>>
 You might be interested in https://www.gitbook.com/ or
 https://readthedocs.org for the automated builds and the various output
 formats they provide.
>>>
>>>

I created a shared text file on framapad here :
https://annuel.framapad.org/p/haproxy-architecture-guide

It can be edited by everyone, and there is an history if needed. Once we
have a fairly good version, I will export it to text file (compatible with
dconv script) and make a pull request to HAProxy sources. Further
modifications will be made by patches as usual.

I will see if this kind of collaborative work is efficient or not :)



> very good proposal and i would like to contribute also.
>
> I would like to see a chapter on healthchecks:
>
>
I added it to the current table of contents.



Olivier

[SPAM] Re: Architecture guide reworked

[Olivier Doucet]

2015-12-02 17:25 GMT+01:00 Olivier Doucet :

>
> 2015-12-02 15:44 GMT+01:00 Michel Blanc :
>
>> Very good idea.
>>
>> Do you plan creating a git repo somewhere so people can contribute
>> and/or create issues ?
>>
>> You might be interested in https://www.gitbook.com/ or
>> https://readthedocs.org for the automated builds and the various output
>> formats they provide.
>>
>
> I intend to create the guide with text format that works so well for the
> original documentation. I will also use haproxy-dconv project to test html
> version.
>
> I think I'll create a repo on github to start the rewrite (will be easier
> for contribs) but when rewrite is over this guide will of course get back
> into haproxy project.
>
>
> I did not know gitbook or readthedocs. Any other opinion on this ?
>

 Hi again,

So gitbook format is specific (using Github markdown format) if I
understand correctly. I'm not sure having a different format from other doc
file in HAProxy is a good ideay ...

[SPAM] Re: Architecture guide reworked

[Olivier Doucet]

2015-12-02 15:44 GMT+01:00 Michel Blanc :

> On 02/12/2015 15:17, Olivier Doucet wrote:
>
> > To avoid any long and non-productive discussion, here is my plan
> to
> > success :
> > * let's agree on a very generic plan
> > * then, use one mailing-list thread for each part. People that
> > feel at
> > ease with one part can help without being burried through dozens
> of
> > emails
> >
> > Do you have any more feedback ? Anyone ? I'll have some time to start
> > working on it tomorrow, so if you want to share your point of view, now
> > is the time.
>
> Olivier,
>
> Very good idea.
>
> Do you plan creating a git repo somewhere so people can contribute
> and/or create issues ?
>
> You might be interested in https://www.gitbook.com/ or
> https://readthedocs.org for the automated builds and the various output
> formats they provide.
>

I intend to create the guide with text format that works so well for the
original documentation. I will also use haproxy-dconv project to test html
version.

I think I'll create a repo on github to start the rewrite (will be easier
for contribs) but when rewrite is over this guide will of course get back
into haproxy project.


I did not know gitbook or readthedocs. Any other opinion on this ?






>
> Cheers,
>
> M
> --
> Michel Blanc
> { :github => "@leucos", :gpg => "0X24B35C22" }
>
>

Re: Architecture guide reworked

[Michel Blanc]

On 02/12/2015 15:17, Olivier Doucet wrote:

> To avoid any long and non-productive discussion, here is my plan to
> success :
> * let's agree on a very generic plan
> * then, use one mailing-list thread for each part. People that
> feel at
> ease with one part can help without being burried through dozens of
> emails
>
> Do you have any more feedback ? Anyone ? I'll have some time to start
> working on it tomorrow, so if you want to share your point of view, now
> is the time.

Olivier,

Very good idea.

Do you plan creating a git repo somewhere so people can contribute
and/or create issues ?

You might be interested in https://www.gitbook.com/ or
https://readthedocs.org for the automated builds and the various output
formats they provide.

Cheers,

M
-- 
Michel Blanc
{ :github => "@leucos", :gpg => "0X24B35C22" }

Re: [SPAM] Re: Architecture guide reworked

[bjun...@gmail.com]

2015-12-02 17:31 GMT+01:00 Olivier Doucet :

>
>
> 2015-12-02 17:25 GMT+01:00 Olivier Doucet :
>
>>
>> 2015-12-02 15:44 GMT+01:00 Michel Blanc :
>>
>>> Very good idea.
>>>
>>> Do you plan creating a git repo somewhere so people can contribute
>>> and/or create issues ?
>>>
>>> You might be interested in https://www.gitbook.com/ or
>>> https://readthedocs.org for the automated builds and the various output
>>> formats they provide.
>>>
>>
>> I intend to create the guide with text format that works so well for the
>> original documentation. I will also use haproxy-dconv project to test html
>> version.
>>
>> I think I'll create a repo on github to start the rewrite (will be easier
>> for contribs) but when rewrite is over this guide will of course get back
>> into haproxy project.
>>
>>
>> I did not know gitbook or readthedocs. Any other opinion on this ?
>>
>
>  Hi again,
>
> So gitbook format is specific (using Github markdown format) if I
> understand correctly. I'm not sure having a different format from other doc
> file in HAProxy is a good ideay ...
>
>
>
>
Hi Oliver,

very good proposal and i would like to contribute also.

I would like to see a chapter on healthchecks:

  - simple HTTP healthchecks
  - check specific applications (linux, via xinetd script)
  - check specific applications (windows, via powershell + simple webserver
(HttpListener))
  - tcp healtchecks (cleartext protocols)
  - tcp healtchecks (binary protocols)
  - how do you “chain” healthchecks  or create healtcheck dependencies


--
Best Regards,

Bjoern

Re: [SPAM] Architecture guide reworked

[Olivier Doucet]

Hi,


2015-11-29 10:30 GMT+01:00 Aleksandar Lazic :

> Dear Olivier
>
> Am 27-11-2015 17:18, schrieb Olivier:
>
>> Hello everyone !
>>
>> I'm a huge fan of HAProxy. In my mind, this is a great toolbox. Like all
>> toolbox, to use it at 100%, you need good examples.
>> HAProxy blog is a great start. There are some code snippets in
>> documentation too. But a long time ago (in a galaxy not so far away),
>> there was a dedicated guide on this matter, that has been forgotten :
>> The architecture guide. Yes, here:
>> http://www.haproxy.org/download/1.3/doc/architecture.txt
>>
>> It gives many examples that are great to start with, but :
>> - it was written 10 years ago !
>> - absolutely not up to date (regarding keep-alive for example)
>> - real word has changed since
>> - it is not compatible with HTML doc
>>
>
> Full ack.
>
> With 1.6 now out, it is now time to rewrite this guide from scratch. The
>> first features I could think of are:
>> - having general details on how a good config should be organized (I was
>> personnaly confused by backend, frontend, listen, bind ...)
>> - examples compatible with latest version, with workarounds if not
>> backward compatible)
>> - keep good ol' txt format, but make it HTML compatible, so that tools
>> like haproxy-dconv can make it readable (and nice)
>> - avoid paraphrasing the official doc. We really want to focus on real
>> world examples that can be applied immediately and easily, and point to
>> the documentation on keywords.
>>
>> I volunteer to provide a generic plan, and I'm sure many people around
>> will be glad to provide some really good examples. We all have different
>> experiences of HAProxy and different use, so we really want to show that
>> many things are possible (and sometimes, there are different ways to
>> solve one problem too. It can be great to show this with pros and cons
>> for each !).
>>
>> To avoid any long and non-productive discussion, here is my plan to
>> success :
>> * let's agree on a very generic plan
>> * then, use one mailing-list thread for each part. People that feel at
>> ease with one part can help without being burried through dozens of
>> emails
>>
>
> Sounds good.
>
> Here is draft 0.1 :
>>
>> 1) Introduction
>> a) Introduction on HAProxy config file
>>how it is organized (sections)
>>99% backward compatible through 1.x branch
>> b) How to check a config file
>>focus on check mode, how to read warnings, ...
>> c) Efficient reloading of HAProxy (hot reload)
>>
>> 2) Simple HTTP load balancing
>> a) Simple HTTP Load balancing
>>round robin
>>cookies
>>source balancing
>>
> b) session stickiness
>   .) L4
>   .) L? (ssl which layer is SSL?!)
>   .) L7
>   .)  with peers
>
> 3) Adding High-Availability
>> a) With keepalived
>> b) wih another L4 load balancer (Alteon ?)
>> c) other implementations ?
>>
> d) distributed ssl load example
>
> 4) HTTPS examples
>> a) Generic HTTP/HTTPS config
>>
> b) Secure recommendations (pfs, ecc, ...)
>
>
>> 5) Load balancing other protocols
>> a) Generic TCP protocols
>> b) Exchange load balancing real world example
>>
>> 6) Security hardening
>> a) chroot
>> b) protecting stats block
>>
> c) conatinering (docker, ...)
>
> 7) DDOS fighting
>> a) Level 4 limits
>> b) Level 7 limits
>>
>> 8) Using HAProxy command line
>> maintenance mode, manipulating backends, ssl-related commands ...
>>
>> 9) Multi-site load-balancing with local pref
>> (see example in current architecture.txt)
>>
>> 10) Advanced tuning
>> a) client-side
>> b) server-side
>> c) OS tuning
>> d) Hardware tuning
>>
>> All constructive comments are of course welcome. I'm aware this is quite
>> a large task, but I'm sure it can be done :)
>>
>
> Cheers
> aleks
>

Thanks for your feedback. I also want to focus on how to write a config
file with nbproc > 1 and points to focus on. I'll see where I can put this
in my plan.

Do you have any more feedback ? Anyone ? I'll have some time to start
working on it tomorrow, so if you want to share your point of view, now is
the time.

Olivier

[SPAM] Architecture guide reworked

[Olivier]

Hello everyone !

I'm a huge fan of HAProxy. In my mind, this is a great toolbox. Like all
toolbox, to use it at 100%, you need good examples.
HAProxy blog is a great start. There are some code snippets in
documentation too. But a long time ago (in a galaxy not so far away), there
was a dedicated guide on this matter, that has been forgotten : The
architecture guide. Yes, here:
http://www.haproxy.org/download/1.3/doc/architecture.txt

It gives many examples that are great to start with, but :
- it was written 10 years ago !
- absolutely not up to date (regarding keep-alive for example)
- real word has changed since
- it is not compatible with HTML doc

With 1.6 now out, it is now time to rewrite this guide from scratch. The
first features I could think of are:
- having general details on how a good config should be organized (I was
personnaly confused by backend, frontend, listen, bind ...)
- examples compatible with latest version, with workarounds if not backward
compatible)
- keep good ol' txt format, but make it HTML compatible, so that tools like
haproxy-dconv can make it readable (and nice)
- avoid paraphrasing the official doc. We really want to focus on real
world examples that can be applied immediately and easily, and point to the
documentation on keywords.

I volunteer to provide a generic plan, and I'm sure many people around will
be glad to provide some really good examples. We all have different
experiences of HAProxy and different use, so we really want to show that
many things are possible (and sometimes, there are different ways to solve
one problem too. It can be great to show this with pros and cons for each
!).

To avoid any long and non-productive discussion, here is my plan to success
:
* let's agree on a very generic plan
* then, use one mailing-list thread for each part. People that feel at ease
with one part can help without being burried through dozens of emails

Here is draft 0.1 :


1) Introduction
a) Introduction on HAProxy config file
   how it is organized (sections)
   99% backward compatible through 1.x branch
b) How to check a config file
   focus on check mode, how to read warnings, ...
c) Efficient reloading of HAProxy (hot reload)

2) Simple HTTP load balancing
a) Simple HTTP Load balancing
   round robin
   cookies
   source balancing

3) Adding High-Availability
a) With keepalived
b) wih another L4 load balancer (Alteon ?)
c) other implementations ?

4) HTTPS examples
a) Generic HTTP/HTTPS config

5) Load balancing other protocols
a) Generic TCP protocols
b) Exchange load balancing real world example

6) Security hardening
a) chroot
b) protecting stats block

7) DDOS fighting
a) Level 4 limits
b) Level 7 limits

8) Using HAProxy command line
maintenance mode, manipulating backends, ssl-related commands ...

9) Multi-site load-balancing with local pref
(see example in current architecture.txt)

10) Advanced tuning
a) client-side
b) server-side
c) OS tuning
d) Hardware tuning


All constructive comments are of course welcome. I'm aware this is quite a
large task, but I'm sure it can be done :)

Olivier