I'm looking to leverage Azure deployment slots for a production Web App (with Azure SQL DB).
I also use a Fortiweb WAF-as-a-Service for production app.
If I use deployment slots, will I need a separate Fortiweb WAF-as-a-Service instance to point to new name of "ProductionApp/Staging"?
I suspect I would need DNS entries as well for new Staging name, along with a separate WAF to have the client successfully connect to staging deployment slot.
Any comments, pointers or other would be most welcomed.
Regards,
Paul
Thank you to #PDorenberg for your question, and the subsequent solution that you provided in your comment.
For the sake of the community, I'm posting your comment as an answer, as it will benefit many others who are facing the same issue and are searching for a solution. Also, I've adding some points that I feel should be included and considered in the answer.
Deployment slots can’t swap custom client domain, associated private TLS/SSL certificates and scale settings as these settings are directly related to virtual network and private endpoints and these are ultimately related to the IP address space and DNS records created for them which are unique for every instance of resource that is routable, mappable and can be found over the internet through public IP addresses
Also, do keep in mind that only app settings, connection strings, language framework versions, web sockets, HTTP version, and platform bitness can be swapped between a deployment slot and a production slot. Please see the documentation for all the information regarding the deployment slot configuration and swapping.
Please also take note that you won’t need the Fortiweb WAF-as-a-service instance when pointing to the production slot of the app for a deployment that is already deployed in the staging slot of the App Service. But if the App Service instances are different for different apps in production, then you surely would need the Fortiweb WAF-as-a-service to route the traffic accordingly to each App Service instance separately.
Related
I have a Quarkus application already deployed on Google Cloud Run.
It depends on MySQL, hence there is an instance started on Cloud SQL.
Next step in my deployment process is to add keycloak. From what I've read the best option seems to be Google App Engine.
The approved answer in this question gave me some good insight of what needs to be done ... mostly.
What I did was:
Locally I made a sub-directory in the main project.
In that directory I added the app.yaml and the Dockerfile (as described here for instance).
There I executed the said two commands: gcloud init and gcloud app deploy.
I had my doubts about this set up and they were backed up by the error I got eventually:
ERROR: (gcloud.app.deploy) INVALID_ARGUMENT: The first service (module) you upload to a new application must be the 'default' service (module). Please upload a version of the 'default' service (module) before uploading a version for the 'morph-keycloak-service' service (module).
I understand my set up breaks the overall structure of the project but I'm not sure how to mix those two application with the right services.
I understand keycloak is a stateful application, hence cannot live on Cloud Run (by the way the intention is for keycloak to use the same database instance shared with the application).
So does any one know a more sensible set up, or what can I move in mine in order to fix it?
In short:
The answer really is in reading the error message (thanks #gaefan) - about the error itself it explains enough. So I just commented out the service: my-keycloak-service line in the app.yaml (thus leaving gcloud to implicitly mark it as the default one) and the deployment continued.
Eventually keycloak didn't connect to the database but if I don't manage to adjust the configurations that would probably be a subject to a different question.
On the point of project structure and functionality:
First off, thanks #NoCommandLine and #guillaume-blaquiere for your input!
#NoCommandLine the application on Cloud Run is sort of a headless REST API enabled backend. Most of the API calls are secured by keycloack. A next step in the deployment process would be to port an existing UI (React) client on the Firebase hosting (or on another suitable service - I'm still not completely sure which approach is best) and in order for the users to work with this client properly they must make an SSO through keycloak first.
I'm quite new to GCP and the number and variants of the available options are still overwhelming to me - one must get familiar with the nuances but I guess it takes time. So I'm still taking suggestions on how to adjust my project structure to fit better the services stack. Thanks!
We are a sales partner of GCP.
We are aware that when using GTM's server container
In order to use GTM server containers, you need to provision (connect and link) with GCP's AppEngine.
If we, as a reseller, install GCP for our customers, can we do the setup?
Is it possible for us to configure the settings?
Since the GCP configuration itself will be done in the customer's environment, will the customer be responsible for the configuration?
Yes, you will have to in one way or another do the setup of GCP for server-side tracking. Otherwise you're not derlivering an MVP product, which is definitely a reasonable expectation from the client.
It's odd that this question is asked here. It's not a technical question, but rather a business ethics question. There's no value in reselling GCP if you're not providing some level of setup and support.
Problem. I'm looking for an agile way to shoot a docker container (stored on GCR.IO) to a managed service on GCP:
one docker container gcr.io/project/helloworld with private data (say, Cloud SQL backend) - can't face the real world.
a bunch of IPs I want to expose it to: say [ "1.2.3.4" , "2.3.4.0/24" ].
My ideal platform would be Cloud Run, but also GAE works.
I want to develop in agile way (say deploy with 2-3 lines of code), is it possible run my service secretly and yet super easily? We're not talking about a huge production project, we're talking about playing around and writing a POC you want to share securely over the internet to a few friends making sure the rest of the world gets a 403.
What I've tried so far.
The only think that works easily is a GCE vm with docker-friendly OS (like cos) where I can set up firewall rules. This works, but it's a lame docker app on a disposable VM. Machine runs forever and dies at reboot unless I stabilize it on cron/startup. Looks like I'm doing somebody else's job.
Everything else I've tried so far failed:
Cloud Run. Amazing but can't set up firewall rules on it, or Cloud Director, .. seems to work only with IAP which is painful to set up.
GAE. Works with multiple IPs and can't detach public IPs or firewall it. I managed to get the IP filtering within the app but seems a bit risky. I don't [want to] trust my coding skills :)
Cloud Armor. Only supports a HTTPS Load Balancer which I don't have. Nor I have MIGs to point to. I want simplicity.
Traffic Director and need a HTTP L7 balancer. But I have a docker container, on a single pod. Why do I need a LB?
GKE. Actually this seems to work: [1] but it's not fully managed (I need to create cluster, pods, ..)
Is this a product deficiency or am I looking at the wrong products? What's the simplest way to achieve what I want?
[1] how do I add a firewall rule to a gke service?
Please limit your question to one service. Not everyone is an expert on all Google Cloud services. You will have a better chance of a good answer for each service if they are separate questions.
In summary, if you want to use Google Cloud Security Groups to control IP based access you need to use a service that runs on Compute Engine as security groups are part of the VPC feature set. App Engine Standard and Cloud Run do not run within your project's VPC. This leaves you with App Engine Flex, Compute Engine, and Kubernetes.
I would change strategies and use Google Cloud Run managed by authentication. Access is controlled by Google Cloud IAM via OAuth tokens.
Cloud Run Authentication Overview
I have agreed with the John Hanley’s reply and I have up-voted his answer.
Also, I’ve learned that you are looking how to restrict access to your service through GCP.
By setting a firewall rules, You can limit access to your service by limiting the Source IP range as Allowed source, so that only this address will be allowed as source IP.
Please review another thread in Server Fault [1], stating how to “Restrict access to single IP only”.
https://serverfault.com/questions/901364/restrict-access-to-single-ip-only
You can do quite easily with a Serverless NEG for Cloud Run or GAE
If you're doing this in Terraform you can follow this article
I'm trying to get a proof of concept going for a multi-tenancy containerized ASP.NET MVC application in Service Fabric. The idea is that each customer would get 1+ instances of the application spread across the cluster. One thing I'm having trouble getting mapped out is routing.
Each app would be partitioned similar to this SO answer. The plan so far is to have an external load balancer route each request to the SF Reverse Proxy service.
So for instance:
tenant1.myapp.com would get routed to the reverse proxy at <SF cluster node>:19081/myapp/tenant1 (19081 is the default port for SF Reverse Proxy), tenant2.myapp.com -> <SF Cluster Node>:19081/myapp/tenant2, etc and then the proxy would route it to the correct node:port where an instance of the application is listening.
Since each application has to be mapped to a different port, the plan is for SF to dynamically assign a port on creation of each app. This doesn't seem entirely scaleable since we could theoretically hit a port limit (~65k).
My questions then are, is this a valid/suggested approach? Are there better approaches? Are there things I'm missing/overlooking? I'm new to SF so any help/insight would be appreciated!
I don't think the Ephemeral Port Limit will be an issue for you, is likely that you will consume all server resources (CPU + Memory) even before you consume half of these ports.
To do what you need is possible, but it will require you to create a script or an application that will be responsible to create and manage configuration for the service instances deployed.
I would not use the built-in reverse proxy, it is very limited and for what you want will just add extra configuration with no benefit.
At moment I see traefik as the most suitable solution. Traefik enables you to route specific domains to specific services, and it is exactly what you want.
Because you will use multiple domains, it will require a dynamic configuration that is not provided out of the box, this is why I suggested you to create a separate application to deploy these instances. A very high level steps would be:
You define your service with the traefik default rules as shown here
From your application manager, you deploy a new named service of this service for the new tenant
After the instance is deployed you configure it to listen in a specific domain, setting the rule traefik.frontend.rule=Host:tenant1.myapp.com to the correct tenant name
You might have to add some extra configurations, but this will lead you to the right path.
Regarding the cluster architecture, you could do it in many ways, for starting, I would recommend you keep it simple, one FrontEnd node type containing the traefik services and another BackEnd node type for your services, from there you can decide how to plan the cluster properly, there is already many SO answers on how to define the cluster.
Please see more info on the following links:
https://blog.techfabric.io/using-traefik-reverse-proxy-for-securing-microservices-on-azure-service-fabric/
https://docs.traefik.io/configuration/backends/servicefabric/
Assuming you don't need an instance on every node, you can have up to (nodecount * 65K) services, which would make it scalable again.
Have a look at Azure API management and Traefik, which have some SF integration options. This works a lot nicer than the limited built-in reverse proxy. For example, they offer routing rules.
When customers signup to my service (myservice.com), they get assigned a subdomain. So customer A would get a url to customerA.myservice.com, customer B would get a url like customerB.myservice.com etc.
I am working on a new version of the service, and would like to redirect some of the new customers to the new version to test the new version.
I know I can create different versions of the service, and split the traffic by ip and cookie between them. It is also possible to split traffic based on routing, but it seems, that in the end GAE still relies on either ip or cookie information to split the traffic: https://developers.google.com/appengine/docs/adminconsole/trafficsplitting#Routing. So if my customer accesses the my service on desktop, ipad and smartphone, he might sometimes get one version of my service on his desktop (at home) and another on his smartphone (on the road).
So my question is if it is possible to always direct customerA.myservice.com to one version of my service and customerB.myservice.com to another version, regardless of device, cookie or ip?
thanks
Thomas
It's not possible with Traffic Splitting feature of App Engine, but you can implement this logic yourself. When users hit your domain, you can choose which version of the app to serve them. There are three drawbacks:
It won't look pretty - the URLs pointing to individual versions may be confusing.
Users might bookmark the version URL, and later they will get an error when they hit it, if the version is no longer available.
You have to make sure that all URLs in your app are relative, if they point to your domain. Otherwise you might link across different versions.
Also, some versions may not be compatible due to the changes in the data model, i.e. you cannot run them in parallel.
Similar issues also arise with the App Engine's splitting - or any other traffic splitting. This is why I recommend to have a trusted group of your most enthusiastic users. Send them a new version as a "preview" and ask for their feedback. They will appreciate you reaching out to them, and they will not be confused if they hit a different version on a different device.