Status Update
No update yet.
Comments
tn...@google.com
an...@google.com
do...@gmail.com
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]:
ch...@google.com
As I can see - internal load balancer don't work with VPN tunnel.
aa...@gmail.com
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.
ad...@gmail.com
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.
aa...@gmail.com
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.
ch...@gmail.com
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.
ch...@google.com
Exactly, its road block for us too. very simple thing shouldn't take this long.
da...@gmail.com
This has been an issue we have made known to GCP since December as well.
Description
OS version: OS X 10.9.4
Java JRE/JDK version: Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
I was using Eclipse in projet with tess two lib (
But when i switch to Android Studio i get fail in "assembleDebug" task:
* What went wrong:
Execution failed for task ':tesstwo:compileReleaseNdk'.
> com.android.ide.common.internal.LoggedErrorException: Failed to run command:
/Users/kh3dr0n/Library/Android/android-ndk-r9d/ndk-build NDK_PROJECT_PATH=null APP_BUILD_SCRIPT=/Users/kh3dr0n/AndroidStudioProjects/QuickRecharge1/tesstwo/build/intermediates/ndk/release/Android.mk APP_PLATFORM=android-17 NDK_OUT=/Users/kh3dr0n/AndroidStudioProjects/QuickRecharge1/tesstwo/build/intermediates/ndk/release/obj NDK_LIBS_OUT=/Users/kh3dr0n/AndroidStudioProjects/QuickRecharge1/tesstwo/build/intermediates/ndk/release/lib APP_ABI=all
Error Code:
2
Output:
In file included from /Users/kh3dr0n/AndroidStudioProjects/QuickRecharge1/tesstwo/src/main/jni/com_googlecode_leptonica_android/box.cpp:17:0:
/Users/kh3dr0n/AndroidStudioProjects/QuickRecharge1/tesstwo/src/main/jni/com_googlecode_leptonica_android/common.h:22:24: fatal error: allheaders.h: No such file or directory
compilation terminated.
make: *** [/Users/kh3dr0n/AndroidStudioProjects/QuickRecharge1/tesstwo/build/intermediates/ndk/release/obj/local/armeabi-v7a/objs/tesstwo//Users/kh3dr0n/AndroidStudioProjects/QuickRecharge1/tesstwo/src/main/jni/com_googlecode_leptonica_android/box.o] Error 1
I builded the Lib using ndk-build from the terminal it completed successfully.