Add ability to override DataPlaneAPI build consumed

[mayankbh]

Today, the packer build process only consumes the DataPlaneAPI binary from a URL.

A URL is passed in via a user variable - https://github.com/haproxytech/vmware-haproxy/blob/master/packer.json#L9

This variable is then used in an Ansible get_url task
https://github.com/haproxytech/vmware-haproxy/blob/master/ansible/roles/haproxy/tasks/main.yml#L15

It would be convenient to be able to use a locally built version of DataPlaneAPI for this process. One approach might be to rename the variable to dataplaneapi_location and allow the Ansible tasks to determine if it's a file/URL, and use copy/get_url appropriately (I have a topic branch with this approach that seems to work, though since I'm new to Ansible, it may not be the cleanest)

FWIW, it's already possible to override the DataPlaneAPI URL by setting up PACKER_FLAGS to set the correct var

PACKER_FLAGS="-var='dataplane_api_url=<url goes here>'"

Use case:

• Using modified (ie. not officially released) DataPlaneAPI binaries in an HAProxy OVA build.

Motivation:

• In cases where a DataPlaneAPI client sets up check-ssl without passing in the check flag, you can end up with a situation where the backend is configured to use SSL for it's health checks, but without 'check', it's always considered up and therefore no health checks are performed.
• In cases where a DataPlaneAPI client is always requesting SSL for health checks, we may want to disable it from a DataPlaneAPI standpoint (As not all backends may be serving SSL traffic) - this could be a workaround until we determine a path forward on such clients. (it could be nice if we allowed end users to hint whether their LB will be serving SSL traffic or not, for instance)

I've been working around the above with a patched DataPlaneAPI build that -

• looks for the presence of 'check-ssl' to determine if health checks should be enabled (which @akutz put together)
• Strips out the check-ssl flag (to avoid enforcing health checks over SSL)

Working with a patched DataPlaneAPI binary, while not a long term fix, allows using health checks in a specific way without requiring modifications to the client. In this case, the client is an operator in a running K8s cluster that won't be upgraded in the short term, even though that operator is where we probably want these kinds of policy decisions coming from in the long run. Still, doing this via DPAPI today gives us a 'break glass' approach to setting up health checks correctly. (it's a fairly simple patch to DataPlaneAPI, see the topic branch linked below, which contains the two fixes I mentioned above.)

Replacing DataplaneAPI binary in live environment

• Build DataplaneAPI (eg. I've been using https://github.com/mayankbh/dataplaneapi/tree/topic/bmayank/disable-ssl-even-if-requested) via the following

dataplaneapi/ $ go version    
go version go1.14 darwin/amd64

dataplaneapi/ $ GOOS=linux make build # you'll want GOOS if you're cross compiling (on a Mac, for instance)

dataplaneapi/ $ file build/dataplaneapi 
build/dataplaneapi: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped

• scp the dataplane API to the running HAProxy instance

dataplaneapi/ $ scp ./build/dataplaneapi root@<HAProxy IP>:/root

SSH into the HAProxy instance for the rest of the steps-

• Stop the existing dataplane API service

systemctl stop dataplaneapi

• Back up the old binary, just in case

cp /usr/local/bin/dataplaneapi /root/dataplaneapi.bak

• Copy the new binary in its place

cp dataplaneapi /usr/local/bin # This should be the new binary you just scp'd in. 

• Restart dataplaneapi

systemctl start dataplaneapi

The new DataplaneAPI build should now be working.

  server <server name> 172.16.0.12:443 check no-check-ssl weight 100 verify none