Status Update
Comments
yo...@gmail.com <yo...@gmail.com> #2
Hello,
You can control the traffic based on the request/response headers of the Target proxies [1] [2]. However, there is already a feature request to allow this directly on the LB, but I can't provide you with an ETA or guarantee its implementation.
Another way of doing it, will be by creating an internal Load Balancer [3], and have a VPN tunnel from the office to your instances. This will guarantee a secure connection, and the load will be balanced among your instances but it might add extra cost.
Keep in mind that the internal Load Balancer is still in Alpha and is not recommended in production.
Should you have any other Feature requests that you would like them to be implemented for a certain use case, please do not hesitate to open a new thread. We will be more than happy to assist in any way we can.
Any updates about this feature will be posted here as well.
Sincerely,
George
[1]:https://cloud.google.com/compute/docs/load-balancing/http/#components
[2]:https://cloud.google.com/compute/docs/load-balancing/http/target-proxies
[3]:https://cloud.google.com/compute/docs/load-balancing/internal/
You can control the traffic based on the request/response headers of the Target proxies [1] [2]. However, there is already a feature request to allow this directly on the LB, but I can't provide you with an ETA or guarantee its implementation.
Another way of doing it, will be by creating an internal Load Balancer [3], and have a VPN tunnel from the office to your instances. This will guarantee a secure connection, and the load will be balanced among your instances but it might add extra cost.
Keep in mind that the internal Load Balancer is still in Alpha and is not recommended in production.
Should you have any other Feature requests that you would like them to be implemented for a certain use case, please do not hesitate to open a new thread. We will be more than happy to assist in any way we can.
Any updates about this feature will be posted here as well.
Sincerely,
George
[1]:
[2]:
[3]:
yo...@gmail.com <yo...@gmail.com> #3
As I can see - internal load balancer don't work with VPN tunnel.
sa...@gmail.com <sa...@gmail.com> #4
Another use case: I want to test and benchmark my site in its production configuration, including the load balancer. As it stands, I either have to write some code to drop requests based on X-Forwarded-For or just have it open to the public and hope nobody finds it. Firewall rules on the LB would make my life easier.
jo...@gmail.com <jo...@gmail.com> #5
We would like to be able to apply firewalls to our load balancers to stop the outside world from being able to hit our dev/stg environments, and our CDN origins.
jo...@gmail.com <jo...@gmail.com> #6
We would like to be able to apply firewall rules to the Load Balancer to apply a blacklist of IP addresses that have been detected as attempting to run injection attacks against our websites.
Seeing as the Firewall Rules that are currently in place apply after the IP address has been changed by the load balancer, there is nowhere to kill the "bad" IP addresses.
Seeing as the Firewall Rules that are currently in place apply after the IP address has been changed by the load balancer, there is nowhere to kill the "bad" IP addresses.
ba...@gmail.com <ba...@gmail.com> #7
We are using GCE with kubernetes. So far everything was going smoothly and effortless. Https load balancer allows us to do a lot of cool stuff out of the box with minimal administration -- global ips, ssl termination, ssl certificate management with access restrictions etc.
And bump -- no ability to whitelist/restrict ips. It is really a show stopper for us. Other option for us could be creating TCP load balancer and manually terminate ssl and manually manage ssl certs via kubernetes secrets store. It really feels like workaround and it is not intended to work that way. Please implement this feature asap, we cannot go to prod without it.
And bump -- no ability to whitelist/restrict ips. It is really a show stopper for us. Other option for us could be creating TCP load balancer and manually terminate ssl and manually manage ssl certs via kubernetes secrets store. It really feels like workaround and it is not intended to work that way. Please implement this feature asap, we cannot go to prod without it.
Description
Right now, you have to know the build tools version to install it:
E.g. this works but, it assumes that I know that 21.1.0 exists.
android update sdk -t build-tools-21.1.0 -a --no-ui
Please add "build-tool" to this list of accepted filters:
-t --filter : A filter that limits the update to the specified types of
packages in the form of a comma-separated list of
[platform, system-image, tool, platform-tool, doc, sample,
source]. This also accepts the identifiers returned by
'list sdk --extended'.
I would like to be able to do this and have it install ALL versions of the build-tool:
android update sdk -t build-tools -a --no-ui