When working locally, how can one direct azure-core-tools to download "Microsoft.Azure.Functions.ExtensionBundle" from a self hosted endpoint instead of "https://functionscdn.azureedge.net/public/ExtensionBundles/Microsoft.Azure.Functions.ExtensionBundle/index.json"?
In a enterprise environment, internet proxy often bock access to the internet and artefact have to instead of hosted on the intranet.
Thanks to #DeepDave-MT comment I was able to figure it out.
Upload the extension bundles and index.json somewhere following strict paths:
/Microsoft.Azure.Functions.ExtensionBundle/<version>/Microsoft.Azure.Functions.ExtensionBundle.<version>.zip (can be downloaded from https://functionscdn.azureedge.net/public/ExtensionBundles/Microsoft.Azure.Functions.ExtensionBundle/2.13.0/Microsoft.Azure.Functions.ExtensionBundle.2.13.0.zip)
/Microsoft.Azure.Functions.ExtensionBundle/index.json (you use that file https://functionscdn.azureedge.net/public/ExtensionBundles/Microsoft.Azure.Functions.ExtensionBundle/index.json)
Set the an environment variable before starting az function core tools FUNCTIONS_EXTENSIONBUNDLE_SOURCE_URI=https://example.net/some/path/
Az core tools will first fetch the index.json, checking the versions listed there and then downloading the zip.
Related
I have made a task for Azure Devops Server pipeline.
On the local Azure Dev-Ops server, I can upload extensions from the local machine wrapped in VSIX file and examine the agent on the machine itself. The agent has the deployed DLL's from the extension and I always change specific DLL that has Logger inside and it prints to console on the pipeline itself.
How can I check if my task is compatible with the cloud version?
And off course if it is, how can I debug it?
The only possible way I found to insert my task in VSO is through the Microsoft DevOps marketplace, but I cannot upload the whole extension once per each change in code.
Also, didn't find a way to upload personal tasks to the marketplace. The private version is not helping because I can see it from within the server just like my clients.
Any advice or debug experience on that platform is appreciated.
Please follow this devblogs, it described how you can work and debug extension directly inside your IDE without publishing it to the marketplace.
Since this blog is very detailed, just mention the key steps.
Based on debugging purposes, you need create a special manifest, for sample I specify it as vss-extension-debug.json:
{
...
"id": "dev-extension",
"name": "Dev-Extension",
"baseUri": "https://localhost:44362",
...
}
You can customized the id and name by yourself. The most important and magic is baseUri, this will tell the VSTS server to load the extension from localhost where we can run and debug it in IISExpress from Visual Studio.
Note: Since our server need extension served from a secure source, please ensure enable SSL mode to run IISExpress
I have scripts to install the extension, add the app settings but actually requesting and installing a cert is still a manual process through the kudu website. I'm not even sure exactly what to search for, or if it's possible. But what I'd like to do is create a script that requests and installs the certificate for each hostname on an app, just as if I were clicking through the screens in kudu.
I believe I wrote just the tool for you:
https://github.com/ohadschn/letsencrypt-webapp-renewer.
EDIT - Specifically for PowerShell, I found this (never tested it though): https://www.powershellgallery.com/packages/Register-LetsEncryptCertificate/1.0/DisplayScript.
According to the above documentation, to create the initial configuration I need to open a web browser. This is sound really weird to me. I would like to script the deploy of OpenAM and it seems impossible.
https://wikis.forgerock.org/confluence/display/openam/Deploy+OpenAM
My actual script do the following
Download openam
extract openam
copy .war in tomcat webapp
extract administration tools
extract configuration tool
extract diagnostic tool
download opendj
lauch the setup of opendj with all args
Now I would like to launch the configuration tool of openam with the configuration file I would like to use but it seems OpenAM must be already configured;
The configuration tool require $HOME/openam/boostrap file where $HOME/openam is the configuration folder that should exists once you have already configure it.
Is this true ? To use configuration tool you must already have configured your service ?
Of course not ... 'configurator tool' is meant to initially configure OpenAM.
For the sake of simplicity, you should not use an external data store.
If you really want to use an external configuration store (OpenDJ or Oracle DSEE are the only supported ones currently), the external config store must be up and running before launching 'configurator tool'.
OpenDJ can be configurated in an automated way as well.
If you do not need an external configuration store, just deploy the OpenAM web-app and use 'configurator tool'
Some helpful links:
Using the CLI
configurator.jar documentation
Automated installation and configuration of OpenAM
A couple of days ago, Microsoft released the engine they're using to do git deployments to Azure. I've had a task on my TODO list for a while to get that kind of functionality set up on my DEV IIS server, so I'm interested in trying out Kudu for that purpose.
The "Getting Started" document shows how to run the web front-end, but everything in there uses "http://localhost:PORTNUMBER" type URL's for git repositories, site URL's, etc.
I realize this is probably getting too far ahead of them, but I'm wondering if anyone has pointers for how to set it up using real domains on "regular" IIS instead of all of the localhost bits?
This is an old question, so I'm giving an updated answer with more current info since I just worked through setting up Kudu on an internal deployment server. The currently selected answer only deals with if you are directly running Kudu from within a development environment.
If you are deploying to a "production" type environment and don't want to install Visual Studio on the target server, there is a good guide on the project website on github.
https://github.com/projectkudu/kudu/wiki/Deploying-to-a-server
On the target server, you will need to install:
MSBuild ( http://go.microsoft.com/fwlink/?LinkId=309745 ) - comes with Visual Studio
NodeJS ( http://nodejs.org )
Git ( http://git-scm.com/downloads )
Back on your development machine, clone the git repo and build using the "build.cmd" file, following instructions in the above link.
In running build.cmd I got several test failures which blocked the build from producing artifacts. These were all related to Mercurial, which we don't use. Installing a Mercurial client didn't make them magically go away, so I disabled the tests rather than sink a bunch of time into debugging my environment.
Your build output will indicate the failures. I disabled by commenting out the [Fact] attribute.
These are the tests I disabled:
tests/Kudu.Core.Test/HgRepositoryFacts.cs (all tests)
Once you have a successful build that has created all the items in the artifacts you can move to deploying the Kudu website and web service code. The below instructions are for setting up a distinct web application instance, rather than dumping everything in c:\inetpub\wwwroot, which is how the instructions read.
Copy "artifacts\Release\KuduWeb" to the target area on the server where your website will run from. I run my kudu install with a separate host header, but you could as easily use a separate port or run as the root website. This directory will be the root for your web application.
Create an empty "App_Data" folder immediately under the KuduWeb folder.
Copy "artifacts\Release\SiteExtensions\Kudu" to the same level as the folder in step 1 and rename to "Kudu.Services.Web". This location is set as a relative path in the KuduWeb web.config file - setting serviceSitePath.
Open IIS Admin and create a website pointing to the "KuduWeb" folder from step 1.
Configure the app pool from step 4 to run as "LocalSystem". This is required to manage IIS Sites.
Create a new folder "apps" at the same level as KuduWeb. This is where deployments will be sent. Note: this location is controlled in the KuduWeb web.config file - setting "sitesPath"
Change filesystem permissions to grant "Users" full access to the "apps" folder created in the above step.
On starting my Kudu website, I got the following error.
Parser Error Message: Could not load file or assembly 'System.Web.Mvc, Version=5.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
For some reason it didn't copy the appropriate MVC version into the deployment artifacts.
If you hit this error, the MVC 5 file can be obtained via NuGet. I found that my source code was built against 5.1.0, so this is the appropriate link:
https://www.nuget.org/packages/Microsoft.AspNet.Mvc/5.1.0
In order to extract the dll, I set up a new dummy project and used NuGet to pull down the dll via the package manager console.
Install-Package Microsoft.AspNet.Mvc -Version 5.1.0
Once you get the binary, copy it from package directory ( .\packages\Microsoft.AspNet.Mvc.5.1.0\lib\net45\System.Web.Mvc.dll ) to the website bin directory on the target machine.
At this point you are up and running. Use the web interface to create your application. It will create a subfolder under the "apps" directory with a tree that should be self explanatory. It will also have created two new websites for your application:
kudu_{your-app-name}
kudu_service_{your-app-name}
In a production situation, you should create an additional website running on appropriate port/host header that points to: .\apps\\site\wwwroot
Now you can add a git remote for your deployment. Go to your source location in a git console (ex: Git Bash) and add the remote as identified by Kudu. Note: you may need to change localhost in the url to be the appropriate server name.
git remote add deploy http://:52711/your-app-name.git
Push your code to the new "deploy" remote and see what happens. You should see all the normal push messages, plus the build output.
git push deploy master
My initial push failed to build and deploy due to "node" not being recognized. It was in the path, so a server reset convinced the path environment variable to be refreshed. You may find additional errors to work through. For instance, I had an issue with MSBuild being imported and causing a hiccup.
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\Visual Studio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found.
YMMV, but these are all solvable problems now. Good continuous deploying!
The project automatically sets up two websites on IIS for each application you add using the web front end. Kudu doesn't automatically map the bindings for them but it's relatively easy to open IIS and find the two sites named "kudu_appname" and "kudu_appname_service". The service website is the one that you point GIT too and the other one is the site itself. Just add public bindings to them by right-clicking and "edit bindings". You can then add public hostnames to them.
This is the easy part. The hard part that I'm still working on is getting authentication working so any random Joe isn't able to push to my kudu repository!
Does MS Deploy support the following scenario?
Create a package from a Team Build drop
Install the web application into IIS6/7 including app pools, settings, etc.
It doesn't seem to want to let me configure IIS on the destination server if my package wasn't created from IIS originally.
If you pass the parameter DeployOnBuild set to true, then your build will produce not only your normal web site files under _PublishedWebSites, but also one whose name ends with _Package. That will contain your package, the parameters file and the manifest, plus a .cmd file for deploying the package.
What it will not contain is anything you didn't tell MSBUILD to place into the package. In particular, no, it won't contain IIS settings unless you told MSBUILD to place IIS settings there. It won't get the settings from out of the air - it will only get them from your local IIS, and only if that's where you have your project set up.
The current feature set does not support this scenario - Microsoft