Monday, July 22, 2013

Using Azure Websites Diagnostic Console


This feature allows you to do something along the line of remote command shell on your Azure Websites file system.  For instance, you can perform simple shell commands like "cd", "dir", "mkdir" etc.   Internally, these commands are executed remotely on Azure WebSites and against its file system.   If you were to "del" pr "rmdir" a file or folder, it will behave the same way as you were to FTP and delete the file manually.

To access this feature, follow the below steps.

1.  Connect to the SCM endpoint of your Websites.

This feature is exposed via the SCM (Source Control Manager) endpoint as part of your WebSites.   To connect to SCM endpoint, simply add "scm" between your site name and subdomain.   For instance, if your site url is "", the scm endpoint is "".  You can browse to "".  

This SCM endpoint requires username and password.   This information is available in your site publishing profile which you can download from Azure Portal Websites QUICKSTART or DASHBOARD (the username is usually your site name prefixed with "$" and the password is a long cryptic one).    By the way, if you happen to setup git publishing for your site, you can also find this credential and URL on your site CONFIGURE tab under "deployments" sections.

Browse to SCM endpoint should land you on this page.

2. Launch the Diagnostic Console

Click the "Launch" shown in picture above should open the console.

Now, you can experiment by typing "dir" or "cd" commands.  The Azure Website file structure is described here.  Enjoy!

Wednesday, July 17, 2013

Enable Git for existing Azure WebSites


Azure Git deployment provides source control and versioning deployment.  The benefit is the ability to get the history of deployments and to rollback to any point in history.

If you have existing WebSites which is deployed by other means such as WebDeploy (Gallery) or FTP and want to enable Git publishing over those deployed files.   You can achieve it by the following.

Step 1 Enable Git Publishing on your site.

Logon to Azure Portal, select your site and navigate to the Dashboard.

Click "Setup up deployment from source control" and double click "Local Git repository"

Step 2 Download (Clone) deployed files to your local machine

Your site is now Git enabled.  You can now download (clone) the content of your site to your local machine.  This is done by simply using git clone command.  The Git URL for your site can be found on the Deployments page.

That's it.  After the clone is done, you can modify local files, git commit and deploy (git push) to your site.

Saturday, July 6, 2013

Deploy to Windows Azure using git with private submodules


Windows Azure supports continuous deployment from GitHubBitbucket and CodePlex.  This includes both public and private repositories.   For private repository, Windows Azure generates an SSH key pair.  The public SSH part is added to the repository's deployment key while the private one is used to fetch the repository content during deployment.  If the repository contains submodules, their contents will also be fetched automatically.

It becomes interesting when submodules happen to be private repositories.   Since Windows Azure, by default, uses the same SSH private key to fetch the main repository as well as its submodules, one can workaround by manually propagating the SSH deployment key across all related submodules.  Note that you have to make sure all submodules are fetched using SSH (not https) by looking at .gitmodules file (see url property).  This works well with Bitbucket but fails in GitHub.   The reason is GitHub uses SSH key as an identifier; hence, it can only be defined once for either a user key or repository deployment key across GitHub site.

Below describes a few workarounds for the GitHub issue.

Dedicated user with pull permission

This is the simplest workaround by introducing a new dedicated user with pull permission to all related private repositories (main and submodules) required for deploying to Windows Azure and set an appropriate SSH key pair to this user and Windows Azure.  There are two ways to achieve this depending on whether your main repository is public or private.

If the main repository is private, the private SSH key is already set to Windows Azure and you will only need to deal with public key part.  Simply copy the deployment key (d:\home\.ssh\ from your webapp (using FTP or Kudu Console) and paste to this user as user SSH key.  Because GitHub only allows one unique key, you may have to delete the deployment key from repo before add as a user key.

If the main repository is public, Windows Azure will not generate nor set any SSH key pair.   In this case, you will have to generate the key pair manually (ssh-keygen).  The public part ( should be set as user key of the dedicated user above.  Upload the private key (id_rsa) part to Windows Azure (you may follow Giving the private key to the Kudu service instruction).

This is simplest and recommended way.

Use different SSH keys for each repositories

This solution is to take advantage of SSH alias support in SSH configuration.  This allows us to speficy different private key files (id_rsa) to be used to access different repositories.

Let's assume, we are dealing with 2 private submodules (say repo1 and repo2).  First, generate two set of key pairs (one for each repositories) and add the public part as deployment key for appropriate repositories.

Configure the ssh configuration file (~/.ssh/config) to use different private key files for different repositories as follow.

Host github-repo1
    User git
    IdentityFile ~/.ssh/id_isa.repo1
    StrictHostKeyChecking no

Host github-repo2
    User git
    IdentityFile ~/.ssh/id_isa.repo1
    StrictHostKeyChecking no

You can test if it is properly configured by doing a git clone/pull from each repositories.

$ git clone git@github-repo1:account/repo1.git
$ git clone git@github-repo2:account/repo2.git

Use FTP to upload ~/.ssh/config, ~/.ssh/id_rsa.repo1 and ~/.ssh/id_rsa.repo2 to Windows Azure's /site/.ssh folder.    Modify and commit the .gitmodules file along with you rmain repository.

[submodule "repo1"]
  path = repo1path
  url = git@github-repo1:account/repo1.git

[submodule "repo2"]
  path = repo2path
  url = git@github-repo1:account/repo2.git

Windows Azure should be able to fetch the main and its submodules successfully.   By the way, this solution only works well if you are the only one using these repositories and your have propagated the ssh's configuration as well as id_rsa key files to all your git client machines.

Hope it helps.