Google cloud engine connection with Bucket socket and instance - wordpress

I have a bucket in Google Cloud which I have upload Angular template i.e. http://digitaldevnet.appspot.com
then I have VM instance IP where I have WordPress website i.e.
http://35.200.194.201
I found different tutorials where you can connect domain to Google Cloud hosting
but I want to connect appspot link i.e. http://digitaldevnet.appspot.com to WordPress site
can be connected and once we browse it should work as VM may be offline sometime.
Any recommendation and tutorial, please let me know

You would need to set up a Load balancer in order to direct your traffic between the GCE instance and the bucket, you can find the instructions for this over here.
Nevertheless, it would be a bit complicated as you would need to set up the configuration and some health checks so that the GCE instance is not accessible when it's down.
Hope you find this useful.

Related

Redirect traffic when Firebase Hosting is down

I know by experience that with load balancers L7 we can redirect traffic to others endpoints if applications become unhealthy.
As Firebase Hosting is using CDN to deliver static content, is there a way to redirect traffic if this static content becomes unavailable?
I thought of using DNS rules that uses redirect but I am concerned about the propagation time that may be too much. (and that could even take more time then Google resolving the incident)
Is there a way to manage that with this service or should I switch to another kind of architecture?
This would depend on your DNS manager itself, Firebase Hosting is delivered via Fastly and if Fastly is down, a good ~30% of the internet is down in general. This was seen a few weeks ago when multiple social media sites and apps broke. As such, you should ensure your host is not on Fastly as the first condition.
From there, you would have to manage some basic logic through a 3rd party DNS manager. A popular one is Cloud Flare which allows the configuration of load balancer pools where if your primary pool is unavailable, you can connect to your backup pool (costs do apply)
https://developers.cloudflare.com/load-balancing/create-load-balancer-ui

Make firebase domain point to EC2 GCP Instance Ip Address

I am having a domain from firebase hosting that looks like this below
discourse-314707.web.app
I am also having an EC2 instance with the following ip address below
54.163.205.15
how can i make "discourse-314707.web.app" in firebase hosting to point to "54.163.205.15" in my EC# instance for example if i have installed an apache it displays the apache page
The discourse-314707.web.app is a subdomain on Firebase's web.app domain that it automatically sets up for any Firebase project.
Since the DNS for all web.app subdomains is managed by Firebase itself, there is no way for you to configure this to point to your own IP address.
The closest you can get it setting up your Firebase web site as a proxy for the one on EC2 with a micro-service. But you'll need to be on the paid plan for that, and it'll quite some hassle for the auto-generated subdomain.
If you register your own domain for the web app, you control the DNS settings for that domain and can point to whatever hosting service you want.

Putting "staging" instance behind VPN - Google Cloud + Firebase

I have a web app with a React frontend on Firebase that connects to a Django backend running on Google App Engine.
I have this setup duplicated for a "staging" environment. The problem is that anyone can access this staging environment.
I'd like to set this up so that you need to be on our VPN to access it.
Can someone point me in the right direction to setup this VPN and move the staging environment behind it?
If you are using Firebase Hosting I believe there's no other way to restrict the access and it does not have a firewall feature. You should use authentication method to restrict and limit who can access your web app.
In App Engine, you can restrict the access of your web server/application by using the following:
App Engine Firewall - #JohnHanley answer, control which using IP addresses can connect to the app.
Identity Aware Proxy - without using VPN you can limit who can access of your App Engine by using their user account. IAP is free but when used with Compute Engine, the required load balancing and firewall configuration may incur additional costs.
App Engine with Load Balancer - to secure and make your App Engine(Standard & Flexible) receives only internal and Cloud Load Balancing traffic
I'd like to set this up so that you need to be on our VPN to access
it.
You cannot limit access to just your VPN. App Engine is in Google's network and you cannot limit access based upon a VPN.
You can use App Engine firewall rules to control which IP addresses can connect to the service. Firebase however does not have firewall rules.
If the public side of your Internet router has a static IP address, then this is simple to setup.
I recommend using authorization to limit who can access your services.

Firebase Functions cannot connect to Azure SQL Database [duplicate]

I would like to develop a Google Cloud Function that will subscribe to file changes in a Google Cloud Storage bucket and upload the file to a third party FTP site. This FTP site requires allow-listed IP addresses of clients.
As such, it is possible to get a static IP address for Google Cloud Functions containers?
Update: This feature is now available in GCP https://cloud.google.com/functions/docs/networking/network-settings#associate-static-ip
First of all this is not an unreasonable request, don't get gaslighted. AWS Lambdas already support this feature and have for awhile now. If you're interested in this feature please star this feature request: https://issuetracker.google.com/issues/112629904
Secondly, we arrived at a work-around which I also posted to that issue as well, maybe this will work for you too:
Setup a VPC Connector
Create a Cloud NAT on the VPC
Create a Proxy host which does not have a public IP, so the egress traffic is routed through Cloud NAT
Configure a Cloud Function which uses the VPC Connector, and which is configured to use the Proxy server for all outbound traffic
A caveat to this approach:
We wanted to put the proxy in a Managed Instance Group and behind a GCP Internal LB so that it would dynamically scale, but GCP Support has confirmed this is not possible because the GCP ILB basically allow-lists the subnet, and the Cloud Function CIDR is outside that subnet
I hope this is helpful.
Update: Just the other day, they announced an early-access beta for this exact feature!!
"Cloud Functions PM here. We actually have an early-access preview of this feature if you'd like to test it out.
Please complete this form so we can add you..."
The form can be found in the Issue linked above.
See answer below -- it took a number of years, but this is now supported.
https://cloud.google.com/functions/docs/networking/network-settings#associate-static-ip
For those wanting to associate cloud functions to a static IP address in order to whitelist the IP for an API or something of the sort I recommend checking out this step by step guide which helped me a lot:
https://dev.to/alvardev/gcp-cloud-functions-with-a-static-ip-3fe9 .
I also want to specify that this solution works for Google Cloud Functions and Firebase Functions (as it is based on GCP).
This functionality is now natively part of Google Cloud Functions (see here)
It's a two-step process according to the GCF docs:
Associating function egress with a static IP address In some cases,
you might want traffic originating from your function to be associated
with a static IP address. For example, this is useful if you are
calling an external service that only allows requests from whitelisted
IP addresses.
Route your function's egress through your VPC network. See the
previous section, Routing function egress through your VPC network.
Set up Cloud NAT and specify a static IP address. Follow the guides at
Specify subnet ranges for NAT and Specify IP addresses for NAT to set
up Cloud NAT for the subnet associated with your function's Serverless
VPC Access connector.
Refer to link below:
https://cloud.google.com/functions/docs/networking/network-settings#associate-static-ip
As per Google, the feature has been released check out the whole thread
https://issuetracker.google.com/issues/112629904
It's not possible to assign a static IP for Google Cloud Functions, as it's pretty much orthogonal to the nature of the architecture being 'serverless' i.e. allocate and deallocate servers on demand.
You can, however, leverage a HTTP proxy to achieve a similar effect. Setup a Google Compute Engine instance, assign it a static IP and install a proxy library such as https://www.npmjs.com/package/http-proxy. You can then route all your external API calls etc through this proxy.
However, this probably reduces scale and flexibility, but it might be a workaround.

For an app hosted on meteor.com, would it be reasonable to use a proxy to add SSL and a custom domain?

First, let me explain why. I've had some rough luck with third party meteor hosting providers. But I'd really rather not run my own servers (I have a meteor app running with SSL on digital ocean, so I know how to do that, I just would rather dedicated professionals run as much of my infrastructure as possible). From what I can see, meteor.com hosting is wonderful, with the caveat of not being able to have a custom domain with ssl.
So, would it make sense to put up an nginx server that just proxied https://example.com to https://example.meteor.com? For starters, would that work, and if it did, would it be performant?
For your info, Meteor has a roadmap to roll out Galaxy (managed "meteor deploy" to your own servers) in list Under consideration for 1.1+. And it should be a perfect choice for you. Here is their Trello
This is MDG's commercial product -- a managed cloud platform for
deploying Meteor apps. You have control of the underlying hardware
(you own the servers or the EC2 instances, and Galaxy manages them for
you).
General Availability for Galaxy will be sometime after 1.0, since we
want to focus on Meteor 1.0 and get it out as quickly as possible.
So in the mean time if you just care about using your own domain, you can use something like Domain name forwarding which lets you automatically direct your domain name's visitors to a different website. And Masking prevents visitors from seeing your domain name forwarding by keeping your domain name in the Web browser's address bar.
Also in your case, you don't necessarily need to add SSL as Meteor has already got one when you deploy your apps. Just try input the url in your browser with https://yourappnamehere.meteor.com and you can see a SSL certificate is already in place.

Resources