Lock dependency and Mondernize project structure

There are no functional changes, and developer using this for the library should not be affected.

Load certificate from origin

Ye shall store certificate securely

You can better distribute certificate in a controlled access environment.

To use this feature, simply state your resource schema

go-proxy tls-client --src :16379 --dst your-redis-server:6379 \
    --tlscertpath s3://devops.org/client-cert

The assumption here is that you have ca.pem, cert.pem, and key.pem under that resource.

Worker process downloads certificate into current working directory .cert. Do remember to delete them when you're done.

You could also be pedantic and do

go-proxy tls-client --src :16379 --dst your-redis-server:6379 \
    --tlscacert s3://devops.org/client-cert/ca.pem \
    --tlscert s3://devops.org/client-cert/cert.pem \
    --tlskey s3://devops.org/client-cert/key.pem

Works for file too

go-proxy tls-client --src :16379 --dst your-redis-server:6379 \
    --tlscertpath file://path/to/client-cert

See more info and example https://godoc.org/github.com/jeffjen/go-proxy

My miserable failure at reading reflect usage

Fix to check validity of outbound net.Conn object.

1. It is not a zero Value
2. It is not a nil

Now with TLS client and server mode

Ye shall have security

An Ambassador needs not only send data to the right correspondents, but also send it discreetly.

Now with TLS connection available, you can establish encrypted tunnel between services that consumes data, and services that provide data with your own keys.

• Encrypt outbound connection from you app

go-proxy tls-client \
    --tlscacert ca.pem --tlscert cert.pem --tlskey.pem \
    --src :6379 --dst 10.0.2.144:16379

• Decrypt and forward to provider

go-proxy tls-server \
    --tlscacert ca.pem --tlscert server-cert.pem --tlskey server-key.pem \
    --src :16379 --dst 127.0.0.1:6379

A little benchmark on the side

Setup

• Running redis-benchmark on an AWS t2.small instance.
• Running a Redis node on AWS t2.small on 10.0.3.202:6379.
• go-proxy running along side redis-benchmark on 127.0.0.1:6379
  • go-proxy --src :6379 --dst 10.0.3.202:6379

Numbers

• Connecting directly

redis-benchmark -h 10.0.3.202 -t ping,set,get --csv
"PING_INLINE","15375.15"
"PING_BULK","12817.23"
"SET","14579.38"
"GET","15923.57"

• Connecting through go-proxy

redis-benchmark -t ping,set,get --csv
"PING_INLINE","13089.01"
"PING_BULK","14662.76"
"SET","14541.22"
"GET","14396.78"

Go for go-proxy

In this release I present the basic features of a typical tcp proxy, with an added twist using etcd as the discovery backend.

go-proxy when setup with a discovery backend will continue to track published services under a service key. This enables granular deployment setup and quick swapping to different cluster endpoints.

go-proxy was designed to facilitate Ambassador Pattern, which because of the difficulty in setup makes the approach rather obscure and difficult to see beyond the "proxy" aspect. While in many cases using a DNS SRV record will be easier (in that you had setup bind or other DNS providers who doesn't want to give a damn to your "dynamic and timely deployment needs").

The ability to hot swap services on the go without relying on DNS infrastructure is great, not to mention going from dev to deploy does not need to muck with endpoint changes, or grief the developers with changing between dev DB and production DB.

A complete ambassador implementation ambd is available for you to try.