-
Notifications
You must be signed in to change notification settings - Fork 2
Description
As of now EP2 is capable of managing only one HAProxy backend.
The current procedure is:
- mention the name of the backend in the config in haproxy section
- this backend must be present in the template
- there is one orchestrator section (which is only aws) as of now.
However this methodology is limiting us to only one backend. This issue is about allowing EP2 manage multple backends rather than just one.
A sample new conf file with this feature implemented might look like this:
[haproxy]
haproxy_config_file = /etc/haproxy/haproxy.cfg
template_file = /home/deep/elasticpyproxy/etc/haproxy.config.template
backend_port = 6003
haproxy_binary = /usr/sbin/haproxy
start_by = systemd
haproxy_socket_file = /var/run/haproxy/haproxy.sock
pid_file = /run/haproxy.pid
backend_names = haproxynode1,haproxynodes2
update_type = update_by_runtime
node_slots = 5
service_name = haproxy
lock_dir = /home/deep/elasticpyproxy/etc
sleep_before_next_run = 5
log_file = /var/log/ep2/ep2.log
[haproxynode1]
orchestrator = aws
asg_name =
region_name =
[haproxynode2]
orchestrator = aws
asg_name =
region_name =
[AWSCREDS]
aws_access_key_id =
aws_secret_access_key =
Instead of backend_name we now have a param called backend_names which takes a list of comma separated backend names.
For each backend name we have a section, which mentions from where the backend should be fetched and what is the orchestrator (only aws as of now).
A new section is also introduced for aws creds to keep it completely decoupled. However each section might have its own aws creds too. In that case the sectional aws creds will overwrite the global aws creds. In that way we might be able to create backends pertaining to different orchestrator accounts.
All these stuff will require quite some amount of code change and documentation updation.