We're trying to automaticaly load service accounts depending on the App Engine environment running (dev, staging, prod)
The thing is we are using a custom docker image based on
FROM node:15.14.0-alpine
Does anyone know how we would load the service account json automatically?
With App Engine (and the other Google Cloud product) the service account is loaded automatically and accessible through the metadata server. With some product you can choose the service account that you want to use with your service, with other not (such as Cloud Build and App Engine).
With App Engine, the default (and unique) service account is <project-id>#appspot.gserviceaccount.com. If you want to have 3 different services, for 3 different environments with 3 different permissions, you have to create 3 different projects.
Note: if you use custom App Engine runtime environment, have a close look to Cloud Run
Related
How can one build/configure single authentication for apps built by SpringBoot and running under different contexts in Tomcat? It seems to me very common scenario, we have multiple apps that we maintain separately but they have to share the same login, so user can switch among them without authenticate to each one with the same credentials. Any idea how to make it done easily?
Lets say there is some static variables in a class and when user on device 1 store some data on it and at the same time some other user on device 2 open the web page then he/she also gets the same data store in that variable,,insted of the deafult data i store .
I think cloud Foundry provide different isolated environment to every user that goes on the website but in that case that is not happening.
Please do tell if this the same behavior what cloud foundry really provide or i am missing something .
cloud Foundry provide different isolated environment to every user that goes on the website
That statement is absolutely not true. Each instance of an application does get an isolated execution environment, but CF creates exactly as many application instances as you tell it to (e.g. via the -i parameter on cf push or cf scale). The platform does not scale up instances per user. No platform I know of does that, as it would be incredibly inefficient.
If your web application needs to keep unique data for each user of the app, it will need to implement session management logic inside the app. You can't do this with static fields in classes. Exactly how you implement session management is dependent on the language and frameworks you are using.
I know about elastic search and run a server in Command prompt in Windows 10 and Work in ASP.NET MVC.
I just want to host in Azure platform. as i have been using shared hosting with SQL server before. so i Need help
What will be minimum requirement or features i have to get to host asp.net mvc application compatible with mobile apps ( providing Apis , not for large scale only for 1 , 2 application ) , with elastic search running at the end ?
Do i have to get virtual machine , documentDB etc features.
You have multiple solutions to your scenario.
Using ElasticSearch
1) To run ElasticSearch you need an Azure Virtual Machine, this could be one from the Marketplace, like, an Ubuntu Server. The size of the VM will depend on the load that it has to manage, maybe you can work with an S1 or you might need an S2. In this case, it's your responsability to expose the network interfases for the elastic search service.
2) For your Web App, you'd need an Azure Web App (App Services). Depending on the load, you can go with an S1/S2 and define your scaling strategy if you need to. There are plenty of tools to measure how your Web App is handling load (NewRelic / AppInsights).
3) Finally, it depends on your Data, but you might need to store it in a persistent storage, like Azure SQL or Azure DocumentDB (depends on the nature of the data) in case you need to rebuild your Elastic Search indexes (and thus reindex from the persistent store).
Using Azure Search
1) Instead of Elastic Search, you can use Azure Search, it will simplify the whole scenario, since it's SaaS (Soft-as-a-Service) and you don't need to maintain and configure a VM, just use the service API from your Web App. Under the hood, it's basically Elastic Search/Lucene with added things.
2) You still need the App Service for your Web App.
3) You still need the persistent storage (Azure SQL, DocumentDB) in case you need to reindex your information or create new indexes.
Basically it all boils down to 3 services (VM/Azure Search + App Service + SQL/DocumentDB) + the Network usage that your App consumes, that's how you'd calculate your costs.
We are currently using both solutions on our products (ElasticSearch for an ELK Logging platform / Azure Search for our main client products) and both work well, but it depends really on your wallet and the kind of implementation times you have, the Azure Search approach might be faster.
I have a single MVC.net web project that will be deployed for multiple customers
The code base and database structure is identical for each customer however on deployment, different CSS and images are used giving each customer their own look and feel.
Each application needs to have the same root url, mydomain.com. I would like to be able to configure so that when a user navigates to mydomain.com/site1 then they are shown customer A's specific deployment of the application. I would also like these deployments to be running on separate app pools (or similar).
mydomain.com/site1
mydomain.com/site2
mydomain.com/site3
I'm currently deploying to an Azure cloud service and using SQL Azure for the database (one DB shared by each cloud service).
How can I setup the above structure using Azure cloud services and ensure that all our customers can use the same root URL but have different complete applications for all of the multiple sites?
Can this be done using virtual directories on an Azure cloud service?
If not, what would be the best way of achieving this?
There is an option for us to have 2 or more web roles in a single deployment. But each deployment can be either be staging or production i.e. by extension, we get only 1 URL to access that deployment.
Considering this case how to access the different webroles, what will be the URLs for those.Also what is the use for having multiple webroles in a single deployment.
Why multiple web roles in a single deployment? Consider an application with a public-facing (customer-oriented) website, as well as an administrative website (maybe on port 8000). There are two basic ways to handle this:
Place both sites in the same web role. This means they now share the VM instances, network cards, memory, etc. It also means that, should you need to scale to handle traffic, both sites are scaled together as a single unit.
Place each site in its own role. Now, they're in their own VM instances and may be scaled separately.
Option #1 is more cost-effective because you can get by with only two role instances (minimum two needed for SLA). Option #2 is better for independent scaling. for instance: If you get a huge spike in customer traffic, this could cause trouble for you when trying to access the administrative website, whereas if your admin website is in its own role, it won't be affected by customer traffic.
In both cases, you get one IP addres, one *.cloudapp.net name (and you can map a custom domain name to it with a CNAME).
Staging vs. Production: Your entire deployment may be published to either Staging or Production (or both, as two separate publishes). Staging is not meant for external users - it's really meant for a pre-live area, where you can verify that a new deployment works as expected. You can then perform a virtual IP swap with your currently-running system in Production, which effectively swaps your staging and production deployments. This results in a near-instant upgrade of your software with no customer downtime.
Keep in mind: Every role in a deployment must stay together - you can't deploy one role to one service and the other role to another service. If you want to do this: Separate your roles into separate deployments. Then you can publish them to different URLs.
In a production deployment your webrole can be accessed by the URL with a prefix you defined previously for example myapp.cloudapp.net; web roles in staging deployment on the other hand can be accessed by automatically generated URL for example 205521014d8c440a83852b62e0df9db5.cloudapp.net
I am afraid there is no way to access web role instance directly, bypassing AppFabric router. Why would you ever need to do it anyway?
If you need get access from one web role instance to another, consider using a queue or distributed cache instead of direct communication.