The below snippet is a block from arm template for function app.
"variables": {
"linuxFxVersion": {
"python":"DOCKER|microsoft/azure-functions-python3.6:2.0",
"dotnet":"DOCKER|microsoft/azure-functions-dotnet-core2.0:2.0",
"node": "DOCKER|microsoft/azure-functions-node8:2.0",
"java":"",
"powershell":""
},
"FX":"[variables('linuxFxVersion')[parameters('runTimeStack')]]"
},
{
"linuxFxVersion": "[if(equals(parameters('osType'),'windows'),json('null'),variables('FX'))]"
},
According to the documentation for automating function resource deployment, the linuxFxVersion is required when deploying to a Linux App Service Plan.
When deploying code, you have to use the provided images as in the template that you've shared.
If you are using a custom container, then it should be your container instead as shown in the docs. Here is the same for reference
"linuxFxVersion": "DOCKER|myacr.azurecr.io/myimage:mytag"
Related
I'm starting to build out an API using nextjs with Vercel deployments. It's quite simple to get setup, simply create files under pages/api/. For example the create endpoints /shows, /movies, /sports I have:
./pages/api/
/shows
/movies
/sports
This is fine, but I'd like to version the API like this: /v1/shows/, /v1/movies, etc.
Even better if I could version based on git commit tag. That is, when I merge to the main branch, Vercel either deploys to current production env (e.g. v1 env), or if there's a new git tag, it deploys to a new production env (e.g. v2 env). After deploying, two production environments will be live (v1 and v2) and hence old clients will not break.
Is there a way to do this with Vercel? Or is there a simpler approach I'm missing? How are other people handling API versioning using nextjs? I'm open to ideas!
If you want to use the same endpoints and serve a different response based on v1/v2, you can add rewrites to your next.config.js file.
module.exports = {
async rewrites() {
return [
{
source: '/v/:version/:rest*',
destination: '/api/:rest*?version=:version',
}
]
}
}
Then when you visit /v/1/shows, it will be the same as visiting /api/shows?version=1.
That means you can check req.query.version in your API to determine the appropriate response.
I have a maybe stupid question. I have an app that runs in the launchpad. When running it from WebIDE, my style.css file is loaded and everything works fine. When I run it from the launchpad, the css-file is empty.
In SDK I found :
Caution!
As stated in the Compatibility Rules, the HTML and CSS generated by SAPUI5 is not part of the public API and may change in patch and minor releases. If you decide to override styles, you have the obligation to test and update your modifications each time SAPUI5 is updated. A prerequisite for this is that you have control over the version of SAPUI5 being used, for example in a standalone scenario. This is not possible when running your app in the SAP Fiori launchpad where SAPUI5 is centrally loaded for all apps. As such, SAP Fiori launchpad apps should not override styles.
Does that mean, that I can not use my css-file in the app that should run in Launchpad? What is the official way to get some style into a launchpad-app?
In addition:
I embedded it in manifest: "resources": { "css": [ { "uri": "css/style.css" } ] },
and in Component.js:
manifest: "json",
includes : [ "css/shell.css", "css/style.css" ]
// includes : [ "css/shell.css" ]
},
/**
* The component is initialized by UI5 automatically during the startup of the app and calls the init method once.
* #public
* #override
*/
init: function () {
jQuery.sap.includeStyleSheet(sap.ui.resource("op/VA_Splitapp_op", "css/style.css"));
Do I need to embed it at another place?
I started the Amplify project using
amplify init
I created an environment and name it as env and chose AWS profile default.
It seems like env is pointing to the default profile.
Is there any way for me to make env pointing to different AWS profile?
For example, if I have two profiles:
default
personal
Can I make env pointing to personal AWS profile?
Thanks!
I know this question is a couple of years old, but I had a similar issue and came across it.
The relevant configuration is in <your-project>/amplify/.config/local-aws-info.json, which will look something like this:
// <your-project>/amplify/.config/local-aws-info.json
{
"develop": {
"configLevel": "project",
"useProfile": true,
"profileName": "SomeNamedProfile"
},
"main": {
"configLevel": "project",
"useProfile": true,
"profileName": "SomeOtherNamedProfile"
}
}
Changing the value of profileName to specify a different AWS CLI profile worked without any issues.
I am new to Visual Studio Team Services Release Management. My goal is to automate a deployment of an ASP.NET MVC application to the Azure App Service.
Trying different approaches, I created a Service Endpoint that is certificate based and one that uses a service principal (SPN). My build definition already builds a web deploy package, and the release definition is linked against that and can use this artifact.
Success 1:
A deployment of the app using the Azure Web App Deployment Task already succeeded - almost.
Shortcoming 1: I do not understand how I can specify the correct Resource Group using this task. This uses the certificate based endpoint, and for this task I cannot use the other (SPN) endpoint.
Success 2:
Using the Azure Resource Group Deployment task, I was able to use a JSON ARM template to create a new resource group with a web app in it. This way I can specify the resource group, addressing Shortcoming 1
Shortcoming 2: But now I don't understand how I can actually deploy the binaries of the build definition that has been linked against my release definition. The web application that gets created by the resource group deployment is empty, and a subsequent Web App Deployment Task seemingly cannot target this newly created web app, since it is probably not ARM based.
I get the feeling that I am missing something obvious here - any help is appreciated.
Update 1
Thanks to #bmoore-msft, I got a deployment working using the child resource extension example he linked to. Essentially, the corresponding snippet of my ARM template now looks like this:
"resources": [
{
"apiVersion": "2015-08-01",
"type": "Microsoft.Web/sites",
"name": "[variables('fullEnvName')]",
"location": "[parameters('siteLocation')]",
"properties": {
"name": "[variables('fullEnvName')]"
},
"resources": [
{
"apiVersion": "2014-06-01",
"name": "MSDeploy",
"type": "Extensions",
"dependsOn": [
"[concat('Microsoft.Web/Sites/', variables('fullEnvName'))]"
],
"properties": {
"packageUri": "https://dl.dropboxusercontent.com/u/<myId>/<WebDeploymentPackage>.zip",
"dbType": "None",
"connectionString": "",
"mode": "Complete"
}
}
]
}
]
But the problem is that this places a static link into my template - as you can see, I used Dropbox as temporary solution. But of course I don't want to upload my web deployment package to Dropbox, neither manually nor automatically. I want to link to the artifact created by my build definition, which unfortunately is dynamic and I can't find any information on how to construct this link. For example, build 1 is located at the following path
https://<tenant>.visualstudio.com/DefaultCollection/_apis/resources/Containers/800850?itemPath=<PathToWebDeploymentPackage>.zip
while build 2 is available here
https://<tenant>.visualstudio.com/DefaultCollection/_apis/resources/Containers/801968?itemPath=<PathToWebDeploymentPackage>.zip
So there is a number changing inside the link which means the link I refer to in my template must be dynamic which means I need to understand where to get that number from, which I don't.
Maybe there is another way of referencing artifact uploads?
Take a look at this sample:
https://github.com/Azure/azure-quickstart-templates/blob/75d0588fbd2702288bd35ed24cb00e43dcf980c2/wordpress-mysql-replication/website.json
The website in that template resource has a child resource extension named "MSDeploy". This will deploy a package to the web site during deployment. So in your task that does the deployment you can create the web app, and deploy the package all in the one deployment task in RM.
You will need to use user or SPN authn for anything using ARM (no certs).
Update: Staging the Package
Ok, usually what I do here is "stage" my artifacts in Azure Storage (secured with a sasToken). The uri you provide in the template must be accessible to AzureRM. You VSTS build output is likely secured, so even though you could access it interactively, AzureRM cannot.
Essentially what you need is a task in RM (or build) that will 1) copy the artifacts to Azure (securely) and then 2) tell the next task where those artifacts are... Here's one option:
https://azure.microsoft.com/en-us/documentation/articles/vs-azure-tools-resource-groups-ci-in-vsts/
This doc is using VSTS build, but RM works the same way. The other part that's different is the doc is using a PS script used by Visual Studio in the Azure Resource Group projects. There's nothing special about that script (it will work anywhere just like any other PS script) but that's the example. It doesn't use the Azure Resource Group Deployment Task because that task cannot do the staging of the artifacts.
Essentially what you need to do is:
parameterize that URI property (see example & repo below)
copy the webdeploy package to Azure (PowerShell in this case)
deploy the template and pass in the uri of the package
e.g.
"packageUri": "[concat(parameters('artifactsLocation'), webdeploy.zip, parameters('sasToken')]"
That doc shows you how VS does it, and you should be able to adapt that for your scenario. If you go this route, you would use the Azure PowerShell task and no longer need the Azure Resource Group Deployment Task.
Another way to do this is with the Azure File Copy task, but currently that task does not output the URI or sasToken, so you couldn't pass it in to the deployment task (there's a PR in the queue to make that work).
Another option if you don't have access to Visual Studio is this repo:
https://github.com/Azure/azure-xplat-arm-tooling/tree/master/PowerShell
It has the same PS script that VS uses, and the templates show an example of the parameterized URL (for a dsc.zip file in this example) but would work the same way for msdeploy.
You've actually hit on one of the more sophisticated scenarios and at the moment not doc'd real well, but it's pretty cool when it works. LMK if you need more help here.
I have set up continuous deployment from a Visual Studio Online Git repository to an Azure Web App.
What is the best way to run acceptance/smoke tests on the website after a build is triggered and deployment has completed?
I have already tried POST_DEPLOYMENT_ACTION (How to add a custom post deployment script to azure websites?), but this seems to get ignored.
I also had a look at the Kudu PostDeployment hook (https://github.com/projectkudu/kudu/wiki/Post-Deployment-Action-Hooks), which appears overly hacky.
I am deploying a standard ASP.NET 4 MVC site by the way. Any help appreciated.
What is hacky about the PostDeployment hook?
An alternative to that could be to subscribe to the PostDeployment hook from the Kudu/SCM site
POST /api/hooks
{
"url": "http://www.callback.com/callback",
"event": "PostDeployment",
"insecure_ssl": false (set to true to ignore https certificate check, for test purposes only)
}
That would give you a POST like below on the specified URL when deployment is done:
{
"id": "cd5bee7181e74ea38a3522e73253f6ebb8ed72fb",
"status": "success", (could be pending, building, deploying, failed, success)
"author_email": "someone#somewhere.com",
"author": "Some One",
"message": "My fix",
"deployer": "Some One",
"start_time": "2013-06-06T01:24:16.5873293Z",
"end_time": "2013-06-06T01:24:17.63342Z"
}
More info here on kudu github wiki
What I ended up doing was customizing the build process to add a RunScriptTask at the end, which invokes my tests.
You can pass build parameters to the RunScriptTask like so:
"-username user#example.org -password test123 -environment " + DeploymentSettings.GetValue(Of String)("ProviderHostedDeploymentEnvironmentName")
If you edit the build definition from Visual Studio -> Team Explorer -> Builds, there is a tab on the left called Process that breaks down the build steps. If you click Show details at the top, there is an option to download the XAML build process template. You can customize this as you wish and then create a new build process template from that file. (Note that XAML build process template file must be pushed to the remote repository beforehand)