I'm attempting to move an App Service from one service plan to another. When I use the portal to do so, the other App Service plan is not displaying.
Both App Services are in the same Location and Resource Group.
The two App Services Plans are in the same location and have the same pricing tier.
I use the "Change App Service Plan" option for the web app. The only App Service Plan that is displayed is the current one. There is also a "Create New" option.
So, in summary:
1) Why is the other App Service Plan not able to be selected.
2) How can I move the App Service (Web App) to the other App Service Plan.
The reason why you are not able to see the other App Service Plan when you try to change the App Service Plan is due to current limitations in moving the Azure web app resources.
The other App Service Plan which you intend to move your Web Apps to is in another resource group with existing Azure Web Apps, which is not supported currently
Azure Web Apps current move limitations updated 01/04/2016
Hope this answer your question.
Not sure if it is something recent, but it seems it is finally possible. The option is in the main resource menu as "Change App Service plan". See:
I was able to move an app service(website) and also its deployment slot to a different plan (with same parameters and location - but did not try if this is a requirement).
Yes, we can now move the App Service Plan using the Change App Service Plan.
But sometime you will get No App Service Plan Found as this is the known restriction for the moving App Service plan.
Restrictions
We can move the App service plan only if the new plan is in the same resource group and geographical location.- These two conditions is is to ensure the new plan is in same webspace
Webspace
Azure deploys each new App Service plan into a deployment unit, internally called a webspace. Each region can have many webspaces, but your app can only move between plans that are created in the same webspace. An App Service Environment is an isolated webspace, so apps can be moved between plans in the same App Service Environment, but not between plans in different App Service Environments.
You can’t specify the webspace you want when creating a plan, but it’s possible to ensure that a plan is created in the same webspace as an existing plan. In brief, all plans created with the same resource group and region combination are deployed into the same webspace. For example, if you created a plan in resource group A and region B, then any plan you subsequently create in resource group A and region B is deployed into the same webspace. Note that plans can’t move webspaces after they’re created, so you can’t move a plan into “the same webspace” as another plan by moving it to another resource group.
You can find this in the official doc here and here
You can also refer this SO
You can configure a backup and restore on the new App Service under the new APp Service Plan.
Backup an app: https://learn.microsoft.com/en-us/azure/app-service/manage-backup#:~:text=The%20Backup%20and%20Restore%20feature,or%20restoring%20to%20another%20app.
Put your code in DevOps and deploy it to the new service plan and point DNS.
thank you for the tips
i found a work around. you can move app service plan to the same resource group, and then you can move apps from one plan to another.
Move resource first will do a check, after that you can review and finally move.
Related
I am looking for a way to create a custom UI definition, which I will use with Terraform to create resources and the terraform arguments/parameters will be provided from the UI. Basically the requirement is like
Creating a customized UI and pass parameters from there ex: Name for Web App Service
Deploy a Web App using terraform which requires name argument and it'll come from the UI input
I'm thinking if that is possible with Azure or AWS.
I'm thinking if that is possible with Azure or AWS.
Yes, its possible with Azure and AWS, or any other cloud provider. Obviously you have to develop a fully custom web application for that with backend running and managing your TF. There is no read-made tools for that.
I've been reading the Google Cloud documentation and can't exactly figure out what the difference between these two are. I know that both of them are automatically created in GCP, but I really don't know much more.
You aren't alone, and that's why google has started a new video series on this topic. To summarize,
The Google managed service account are account created on Google side (managed by Google, you can't delete them) but that you can grant on your project to allow them to perform actions. They are also named service agent. They are used when you used serverless product, such as Cloud Build for example, or Cloud Run (to pull the image, not to run the instance)
The default service account (mainly Compute Engine default service account and App Engine default service account) are service account created automatically in YOUR project (so managed by you, you can delete them if you want) when you activate some APIs. They are used by default when you create some service's instance.
I have a question what is the difference if I just use a Oracle/MySQL service provided by PCF without binding it? What difference will it create. I can anyway access DB using the credentials
There are two differences that come to mind:
When you create a service through the Cloud Foundry marketplace, that will create backing resources for the service but in most cases it does not create credentials. The act of binding a service to your app, in most cases with most service brokers, will actually create service credentials for you. When you unbind, again with most brokers, the service credentials are destroyed. This makes it easy to regenerate your service credentials, just unbind/rebind the service and restart your app. The net result is that if you don't bind, there are no credentials.
Most people do not want to include credentials with the actual application (see https://12factor.net/ for details why). They want to be able to provide configuration external to the app. On Cloud Foundry this commonly amounts to binding a service.
Having said that, how do you want to provide the credentials to your application?
Service bindings are there to try and make life as a developer easier but you don't have to use them. If you want to pass in the configuration some other way, like via environment variables, a config file, or using a config service (Spring Cloud Config Server or Vault) those are fine options too.
If you do not want to bind a service to your app, the only thing you'll need to do is to create a service key instead. A service key is like a binding, but not associated with an application. It will also generate a set of unique credentials. You can then take the credentials from your service key and feed them to your app in the way that works best for you.
Ex:
cf create-service-key service-instance key-name
cf service-key service-instance key-name
The first command creates the service key, the second will display its credentials.
I receive an error message while attempting to deploy anything from the marketplace into a specific GCP project.
You must have a valid default service account in order to create a
deployment, but this account could not be detected. Contact support
for help restoring the account.
Things I've Tried:
Every VM from the marketplace shows the same error message
I can deploy regular VM instance
I can see there is an enabled service account for the project with the name "Compute Engine default service account".
I am able to deploy VM's from the marketplace into other projects under the same organization
I've contacted GCP Billing support and they cannot find anything wrong from a billing perspective
Researching online shows that others that have had this issue have just rebuilt the project. It appears that service account is created by default when the project is spun up.
I'm hoping there is another way around it as this project is a host for a shared VPC deployment. There are already other projects with deployed VM's that are utilizing the host projects networks.
Thank you!
Looks like you deleted a default service account.
As mentioned in one comment some can be recreated by disable/enable the corresponding API
Below are the default service accounts I have in my project, hope it helps you to find the root cause. (these service accounts let me deploy a wordpress solution depending on what you are trying to deploy you might need more service accounts)
PROJECT-NUMBER-compute#developer.gserviceaccount.com Compute Engine
default service account
PROJECT-NUMBER#cloudservices.gserviceaccount.com Google APIs Service
Agent
PROJECT-ID#appspot.gserviceaccount.com App Engine default service
account
service-ORG-ID3#gcp-sa-cloudasset.iam.gserviceaccount.com Cloud Asset
Service Agent
service-PROJECT-NUMBER#cloud-ml.google.com.iam.gserviceaccount.com Google
Cloud ML Engine Service Agent
service-PROJECT-NUMBER#compute-system.iam.gserviceaccount.com Compute
Engine Service Agent
service-PROJECT-NUMBER#container-engine-robot.iam.gserviceaccount.com Kubernetes
Engine Service Agent
service-PROJECT-NUMBER#containerregistry.iam.gserviceaccount.com Google
Container Registry Service Agent
service-PROJECT-NUMBER#dataflow-service-producer-prod.iam.gserviceaccount.com Cloud
Dataflow Service Account
service-PROJECT-NUMBER#service-networking.iam.gserviceaccount.com Service
Networking Service Agent
The service account was intact and had the same permissions as other service accounts for working projects.
We purchased and opened a case with GCP technical support. After a little more than a week of them troubleshooting the issues, they determined there was no way to correct the problem. Their root cause was that something happened during the initial project deployment that caused some backend configuration issues. For what its worth, the project was deployed using Terraform, but its uncertain if that was a factor.
After recreating the host project, we were able to deploy from the marketplace again successfully.
If you run into this problem, save yourself the hassle and time and just recreate the project.
After we created a new project in Google developer console, we see one App Engine service account and one Google APIs service account already there in "Permission" page. But we have no client Ids in credential. Those two accounts seems to be dummy, what are they for?
They are not exactly dummy.
Those are "service" accounts meant to be used if you want an application or utility/tool that is sitting inside/on your app engine VM or compute engine VM, to perform actions that will require authentication ... having service accounts should ideally let you can skip the oauth step which would otherwise require browser access and user intervention ... things that an automated process in a VM should not have to deal with.
I'm guessing they were provisioned automatically with ease of use (? shrug) in mind so folks wouldn't have to go about creating them.
https://cloud.google.com/compute/docs/faq#serviceaccounts
https://cloud.google.com/compute/docs/authentication