Create a new Git repo in your project
https://docs.microsoft.com/en-us/vsts/git/create-new-repo?view=vsts

Get started with Git from the command line
https://docs.microsoft.com/en-us/vsts/git/share-your-code-in-git-cmdline?view=vsts

To add a new Visual Studio solution to an existing repository of Visual Studio Team Services (VSTS, aka Visual Studio Online), you can use the Git add-on to Visual Studio.

Or, you can run the command lines as shown below. Note that I tested the command lines on my Windows 10 PC and Visual Studio 2017. Also, there is only one team project in the repository.

Step 1 – Create and complete a new Visual Studio project

For this blog post, I created a sample project called Ninja Care Twilio in Visual Studio 2017.

Step 2 – Locate your VSTS repository and team  project and download/create a local repo

Navigate to the location where you’d like to add the local repo for the team project, e.g. c:\users\zxue\source\repos

git clone https://<reponame>.visualstudio.com/_git/<projectname>

Step 3 – Add the new VS solution to the new local repo and make git aware of the changes to the local repo.

Copy the new VS solution to the local repo with Windows Explorer or command line.

In Git CMD, navigate to the local repo and check git status. You will notice the VS solution listed as “Untracked files.” The add the VS solution to the local repo and commit the changes. Note that you don’t need to run “git init .” because you have already initialized the local repo through the “git clone” command.

git status

git add --all
git commit -m "add a new VS solution"

git status

Step 4 – Sync up the changes to the team project in VSTS

git push origin master

You should be all set. You can browse the VSTS portal to see that the new VS solution has been added to the team project.

if you are not sure if you have set up the remote origin, you can run the command below.

git remote –v

If necessary, you can add a remote origin by running the command below. Replace the repository and team project name with yours.

git remote add origin https://fabrikops2.visualstudio.com/DefaultCollection/Fabrikam/_git/FabrikamApp

For .NET developers using Visual Studio, you can develop a Bot app by following instructions outlined in “Create a bot with the Bot Builder SDK for .NET” and  “Develop bots with Bot Builder”. With “Bot Builder SDK v4”, which is being actively developed, developers can create bots in other popular programming languages like JavaScript, Python, and Java.

Once you’ve done testing the app with the botframework-Emulator running locally, you will need to publish the Bot app to Azure, create a Web App Bot or Bot Channels Registration, and then Connect to Cortana or other channels.

Publish your Bot to Azure

With Visual Studio 2017, you can publish your Bot directly to your Azure portal. You can either create a new Azure App Service or deploy over an existing one.

Create Bot Channels Registration

On the Azure portal, search on “Bot” and select Bot Channels Registration. Make sure that you enter the Messaging endpoint. Note: If you haven’t published the app to the portal yet, you can leave it blank and complete it later on.

Update your Visual Studio Bot project with Microsoft App ID and Password

Select the Bot Channel Registration (listed under Type in the resource group of your Azure portal), and select Settings as shown below. If you create the web app bot directly from the Azure portal, the service is listed under “Web App Bot” type.

From the Setting page, you can update the Messaging endpoint. Also, you can see the Microsoft App ID here.

To find the Microsoft App Password for the Bot, click on Manage. This opens the application registration portal, which is a separate portal but works seamlessly with the Azure portal now.

Because the password is partially hidden, you will need to create a new one, make a note of it, and delete the old one.

Now, go back to your Visual Studio, update the App ID and Password values in the web.config file. Then re-publish the app to the Azure portal.

Connect your Bot app to Cortana

Test your bot app with web chat, and fix any issue you find.

Then, select Channels, and select Cortana, and click on register it with the organization you previously created in the knowledge store.

If this is the first time you are using the knowledge store portal, you can create an organization there. Also, you can review the Cortana channels you have created.

Test your Bot with Cortana on your PC or Harmon Kardon Invoke device

You can either speak to Cortana or type in something like “Ask BenjaminChat” to initiate your Bot app. From there, you can speak or type in your questions and commands that your Bot app knows how to process.

That’s all. It’s fun!

Initially I tried to stop the Edge app or Office app like Outlook or Word using Task Manager. But that didn’t help. Every time when I re-started Edge, it kept trying to refresh a web page at the below url but never could finish it.

ms-appx-web://microsoft.microsoftedge/assets/errorpages/startfresh.html

After a few rounds of troubleshooting without success, it occurred to me that the Edge browser might be the culprit for the app hanging issue. In other words, if I could fix the Edge issue, my Office apps might just work fine. It turned out to be true in my case.

The fix was rather simple: delete Edge cache and re-boot the machine.

You can find the Edge cache at the location below, as mentioned in the discussion here. Delete all subfolders in the folder. I had several of them.

C:\Users\username\AppData\Local\Packages\Microsoft.MicrosoftEdge_somerandomecodehere\AC\#!001\MicrosoftEdge\Cache

After rebooting my PC, the Edge browser and Office apps started normally, to my delight.

I won’t guarantee that this simple fix will resolve any similar issue but it’s certainly one option you have. Please note that you may lose browser history by deleting Edge cache but you should still have your favorites and download history.

Microsoft.WindowsAzure.Storage.StorageException occurred
  HResult=0x80131500
  Message=The remote server returned an error: (400) Bad Request.
  Source=Microsoft.WindowsAzure.Storage
  StackTrace:
   at Microsoft.WindowsAzure.Storage.Core.Executor.Executor.ExecuteSync[T](RESTCommand`1 cmd, IRetryPolicy policy, OperationContext operationContext)
   at Microsoft.WindowsAzure.Storage.Table.TableOperation.Execute(CloudTableClient client, CloudTable table, TableRequestOptions requestOptions, OperationContext operationContext)
   at Microsoft.WindowsAzure.Storage.Table.CloudTable.Create(TableRequestOptions requestOptions, OperationContext operationContext)
   at Microsoft.WindowsAzure.Storage.Table.CloudTable.CreateIfNotExists(TableRequestOptions requestOptions, OperationContext operationContext)
   at TableSBS.Program.Run(CloudTableClient tableClient, Int32 numIterations) in C:\Users\zxue\Downloads\azure-cosmosdb\PremiumTableGetStarted\Program.cs:line 70
   at TableSBS.Program.Main(String[] args) in C:\Users\zxue\Downloads\azure-cosmosdb\PremiumTableGetStarted\Program.cs:line 51

Inner Exception 1:
WebException: The remote server returned an error: (400) Bad Request.

1) Go to the Azure portal, create the “People” table and download the sample .NET app. It should just work because the app has the right connection string in the app.config file already.

2) Open “Manage NuGet Packages” window, remove WindowsAzure.Storage-PremiumTable and re-install it.

Creating the Bot App

Using Visual Studio, I created a bot app that lists a list of medications for a patient, and for a given medication different prices from pharmacies. To keep it simple, I have two medications, Lipitor and Crestor, in the bot app, and use prices publically available at GoodRx from HealthWharehouse, Membership warehouse, Target(CVS), Walmart, Sams Club, CVS Pharmacy, and Walgreens. All data including images is included in the VS solution. So there is no web service call. The source code, tested with Visual Studio 2017, Microsoft Bot Builder SDK, Microsoft Bot Connector, and Bot Framework Channel Emulator, is available at github. To learn how to get started with developing bot applications, check my previous blog.

The solution consists of several components as shown below.

Models – Medication and LUISModel. They define data properties. The images are kept in the data folder.

Services - LUISService, MedicationService, PricingService. MedicationService returns list of medications whereas PricingService returns list of prices for a given medication.

Dialogs – MainDialog, ListMedicationDialog, ListPricingDialog. They essentially provide the user interface with the bot app.

MessagesController – The default method (Post). It displays a greeting message, and provides an entry point to the MainDialog.

Wire up with Microsoft Cognitive Services – LUIS

To help the Bot app understand a user’s input, for example, list medications for a patient, I used LUIS, one of Microsoft Cognitive Services available at luis.ai. I created a LUIS app with two Entities - PatientName, MedicationName, two Intents - ListMedication and GetMedicationPricing, and added a few utterances for each of them.

And then train and publish the app. The endpoint url is added to the web.config file in Visual Studio solution.

In Visual Studio, I used the GetIntentFromLUIS method to find the matching Intent or action, and then use it to open medication or pricing dialogs from the MainDialog.

Publish the Bot app to Azure App Service and Register it

After testing the Bot app with the local emulator, I published it to Azure App Service and registered the app at dev.botframework.com. Make a note of the Bot app ID and password.

After the successful publication, I enabled Bot Authentication in the MessagesController file, bot app info in the web.config file, and the image urls in the MedicationService. And re-publish the bot app. You can now test the Bot app with the web chat channel.

MessageController file

Web.Config file

MedicationService file

Add the Bot app to Skype

Normally you’d add bot apps like this one to channels such Skype for Business (available in preview). For testing purposes I used Skype Desktop.

From my dev.botframework.com account, I clicked the Skype icon to add the app to my Skype desktop app.

The Bot app essentially became a new contact in my Skype desktop app, and I could talk to the Bot just like I would with a real person.

Connect the Bot app to Cortana

To use Cortana in the Bot app, I needed Cortana Skill, which is currently in private preview.

From my private preview account, I configured a skill for the bot app. The process was rather simple. All I had to do was to specify the endpoint, which was a combination of “bot” and the registered Bot app name. From there, you could download the Cortana app on supported devices, for example, Android, log in to the app using the same account where the bot app was registered, and talk to Cortana using the invocation phase you configured, something like “Ask Medication Pricing.” If all configurations were done properly, you’d hear the beautiful Cortana voice and your Bot would start on the mobile device.

You can follow the steps outlined in the document Get started with Relay Hybrid Connections.

You can find another example at Github, Azure Relay Hybrid Connections - Apache Thrift Listener. When you update or add the reference to “Microsoft.Azure.Relay”, make sure that you use the dll in the net45 folder, not the dll in the netstandard1.3 folder. You can download the branch version at Github.

If you download the Azure Relay .NET project from Github, without using the Microsoft.Azure.Relay package from NuGet Package Manager, make sure that you have the same or newer .Net sdk version in the global.json file. For example, change it from "version": "1.0.0-preview2-003121" to "version": "1.0.0-preview2-003131" if you have version “1.0.0-preview2-003131” installed, which you can find from the control panel, “Programs and Features.”

Also, if you create the namespace using the deployment template at the Github, you get two hybrid connections, “Authenticated” which requires authentication on Azure and “Unauthenticated”, which doesn’t require authentication. You will get the default policy, RootManageSharedAccessKey for both connections. But you can create one shared access policy for “Authenticated” connection from the portal and choose the right permissions, “Manage”, “Listen” and “Send”.

{
    "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "namespaceName": {
            "type": "string",
            "metadata": {
                "description": "Name of the Azure Relay namespace"
            }
        }
    },
    "variables": {
        "location": "[resourceGroup().location]",
        "apiVersion": "2016-07-01",
        "defaultSASKeyName": "RootManageSharedAccessKey",
        "defaultAuthRuleResourceId": "[resourceId('Microsoft.Relay/namespaces/authorizationRules', parameters('namespaceName'), variables('defaultSASKeyName'))]"
    },
    "resources": [
        {
            "apiVersion": "[variables('apiVersion')]",
            "name": "[parameters('namespaceName')]",
            "type": "Microsoft.Relay/Namespaces",
            "location": "[variables('location')]",
            "kind": "Relay",
            "resources": [
                {
                    "apiVersion": "[variables('apiVersion')]",
                    "name": "authenticated",
                    "type": "HybridConnections",
                    "dependsOn": [
                        "[concat('Microsoft.Relay/namespaces/', parameters('namespaceName'))]"
                    ],
                    "properties": {
                        "path": "authenticated"
                    }
                },
                {
                    "apiVersion": "[variables('apiVersion')]",
                    "name": "unauthenticated",
                    "type": "HybridConnections",
                    "dependsOn": [
                        "[concat('Microsoft.Relay/namespaces/', parameters('namespaceName'))]"
                    ],
                    "properties": {
                        "path": "unauthenticated",
                        "RequiresClientAuthorization": false
                    }
                }
            ],
            "properties": {}
        }
    ],
    "outputs": {
        "NamespaceConnectionString": {
            "type": "string",
            "value": "[listkeys(variables('defaultAuthRuleResourceId'), variables('apiVersion')).primaryConnectionString]"
        }
    }
}

Once that’s all done, you can build the client app (console app) and the server app (console app). Navigate to the folders where the apps, server.exe and client.exe, are located, and run the command lines below, each in its own console environment. The client app uses the calculator service to add, subtract, and divide two numbers, and the server app echo the results.

server zxuerelay1.servicebus.windows.net authenticated policy1 8nawZQXyR3Fx82r+k5iV0wjrdgW2iPVs8/4bTu3Jqbo=

client zxuerelay1.servicebus.windows.net authenticated policy1 8nawZQXyR3Fx82r+k5iV0wjrdgW2iPVs8/4bTu3Jqbo=

This post walks through the steps you take to integrate Cognitive Services – LUIS and RESTful services and web service APIs. The idea is to use LUIS to get the intent from user activity, and then call a RESTful service or web service API (e.g. Yahoo Finance API or OpenWeatherMap API) to get data for the user. You can find the source code at GitHub.

Step 1 – Create a Cognitive Service API Account

Go to http://portal.azure.com, and follow the steps at “Create a Cognitive Services APIs account in the Azure Portal”. Make a copy of Key 1 under Resource Management. You will need the key when you publish your LUIS app at next step.

Step 2 – Create your LUIS app and Publish it

Go to https://www.luis.ai/applications to create a Cognitive Service LUIS app. Add intents, entities, train and test the app, and publish the app. Use the key you obtained at Step 1 when publishing the app. You can find more detail here.

Step 3 – Create a Bot App using Visual Studio

Follow the steps here.

Before Publishing your Bot Application to Microsoft Azure, test the app in the local bot framework emulator, which I discussed in a previous post.

Modify your Visual Studio project to integrate LUIS, and web service APIs.

a) Update values in the web.config file

b) Add model.cs, stockprice.cs and weatherservice.cs files

c) Update MessageController.cs file by adding three methods – GetIntentFromLUIS, GetStock and GetWeather and modifying the Post method as follows.

Test the app in the local bot framework emulator again. Fix any error. You should be able to test it with “show me msft stock” and “show me weather in Seattle”.

You can now publish the app to Azure. See more detail at the section, “Publishing your Bot Application to Microsoft Azure”.

Also, you can finish the remaining steps.

• Testing the connection to your bot
• Registering your Bot with the Microsoft Bot Framework
• Configuring Channels

This simple app shows how a stateless service and a stateful service, two separate microservices, work together to accomplish the goal of tallying voting counts by candidate name. The stateless service provides a user interface (single page app) for data entry, and communicates with the stateful service through a remote client service proxy. The stateful service keeps track of voting counts by storing data in the Service Fabric built-in data collection, ReliableDictionary. Each stateful service comes with one Primary replica for read and write requests, and multiple active Secondary replicas for read only requests, to achieve high availability. No database or cache is used in the example.

The diagram below illustrates the high-level architecture of the Service Fabric Voting app. For more detail on Service Fabric, check out the online documentation or download the live pdf file (about 800 pages).

The lab documents provide detail on how to debug, test and upgrade the app and how to publish it to the local Service Fabric cluster in Visual Studio. In the post I will focus on deploying the app to Azure.

Step 1 – Create a Service Fabric cluster on Azure

You can use the Azure portal or PowerShell scripts. If you want to secure the Service Fabric, you’ll need to create Azure Key Vault. If you don’t have commercially available certificates, you can create and use self-signed certificates. See the detail here.

Step 2 – Publish the app to the Service Fabric cluster

You can use Visual Studio to publish the app directly to Azure. Alternatively, you can create a package for the app, and then use PowerShell scripts to publish it to Azure.

In Visual Studio, open Cloud.xml in PublishProfies in the app project. Replace <ClusterConnectionParameters ConnectionEndpoint="" /> with something similar to the following. Replace the ServerCertThumbprint value and FindValue with the thumbprint value you obtained at Step #1. Save the changes and go back to the Publish screen, you should be ready to publish the app to the cloud. If you have configured Azure AD for the cluster on Azure, use the ClusterConnectionParameters for Azure AD and make similar changes.

<ClusterConnectionParameters ConnectionEndpoint="mycluster.westus.cloudapp.azure.com:19000"
                             X509Credential="true"
                             ServerCertThumbprint="0123456789012345678901234567890123456789"
                             FindType="FindByThumbprint"
                             FindValue="9876543210987654321098765432109876543210"
                             StoreLocation="CurrentUser"
                             StoreName="My" />

In case you run into an error as shown here, ensure the value in Connection Endpoint is valid.

Step 3 – Launch Service Fabric Explorer

Open the browser and navigate to https://clustername.region.cloudapp.azure.com:19080/Explorer If you use a self-signed certificate, you can ignore the website security certificate warning. On the next screen, choose the same certificate that you uploaded to Azure Key Vault at Step 1.

If you don’t see it on the list, as it happened to me because the certificate disappeared after initial use, open Internet Options in IE and import the pfx file you used at Step 1. Restart the process.

You should now be able to see the Service Fabric Explorer, as you have seen the local version.

Step 4 – Configure the cluster load balancer

With the local cluster, you can access the user interface as shown above by accessing http://localhost:34001/api/index.html which you can find from the node of the stateless service. Now that the app is deployed on the Service Fabric cluster on Azure, the services including the single page app are running behind the load balancer. If you use the public IP address of the cluster and the port 20002, e.g. http://<publicipaddress>:20002/api/index.html, which is made up of VMs in VM Scale Set, or the cluster address, http://clustername.region.cloudapp.azure.com:20002/api/index.html, you will quickly find that the web app is not accessible. The reason is that either port 80 or port 20002, which you find from Service Fabric Explorer, is not set up for the load balancer.

To address the port issue, go back to your Azure account and create two rules, one under Health Probes and one under Load balancing rules. The Health Probes rule uses TCP protocol to check the heath status of the node every 5 seconds. The Load balancing rule forwards the request from port 80 to a backend port 20002 which the stateless service is listening on. Choose LoadBalancerBEAddressPool for Backend pool, the newly created Health Probes rule for Health probe, and keep all default values for other fields. If you choose to enable Floating IP, the front port and backend port much match.

With that, you should be able to see the single page app. It is available via http, not https. You can secure the app using Azure AD.

You can use the Bot Framework to build and connect bots to interact with your users in apps (or communication channels) such as your website, Skype, Facebook Messenger, and Office 365 mail. Before or after deploying and publishing bots, you can use the Bot Framework Emulator to test them. In the post I will share a few tips on how to use the emulator correctly.

Install and use the latest version of the emulator

You can download the latest version (currently 3.5.23) at github. (At the time of writing the post the other download link didn’t seem to be working.) If you have the older version, 1.0.0.73, on your Windows computer, you should replace it.

Test a Bot Connected to Azure Bot Service in the Emulator

With an Azure subscription, you can create a bot through the Azure portal by following the instructions here. You can test the bot directly through the portal chat channel as shown below.

To test the same bot in the emulator, you will need to find the end point, application ID and password for the bot service. The Settings tab only provides the partial message endpoint (ending with three dots). Therefore you will need to go to the developer site, https://dev.botframework.com/. Click on the Edit link. You will find the message endpoint there. Copy the entire URL and enter it in the emulator. Also, copy and paste the application ID and password from the bot developer portal.

You will also need to download free utility, ngrok, which creates a tunnel between the bot hosted remotely (in this case on Azure) and your computer behind the firewall. Click App Settings in the emulator. Browse to the location where ngrok.exe is located. Save the setting. The utility will be launched automatically from the emulator. At this point, the emulator is ready. Click “Connect” or the refresh icon. Type something in the input box. You’ll see a response.

Test a Bot Connected to localhost in the Emulator

You can use Visual Studio to create a bot using the Bot Framework Connector SDK .NET template. See detailed instructions here.

Note that the documentation is a bit outdated. It still shows the old emulator interface. It refers the portal to 3978. Your bot app actually uses port 3979. It says you can leave the application ID and application password blank, but the emulator (version 3.5.23) asks you for application ID and password.

If you just want to test the bot locally with the emulator, without registering the bot and publishing it to Azure, you can supply the application ID and password in your Visual Studio project code. Interestingly, you have to provide a valid application ID and password, not something random.

- If you leave the values of MicrosoftAppId and MicrosoftAppPassword blank, you will receive an error: “The bot's MSA appId or passsword is incorrect. Click here to edit your bot's MSA info.”

- If you set the value of MicrosoftAppId to “MyApp” and MicrosoftAppPassword to “12345”, you will received an errror: “Refresh access token failed with status code: 400”

I used the same application ID and password from the bot I created from the Azure portal. And it worked. Note that ngrok is not required for local message service.

Note: Docker Compose is supported on Windows Server 2016. You can download the tool at https://docs.docker.com/docker-for-windows/ or https://github.com/docker/compose/releases and rename it to docker-compose.exe. Also, you can install it by using Invoke-WebRequest. Detail at https://blog.docker.com/2016/09/build-your-first-docker-windows-server-container/

Option 1 – use docker run command

docker run -ti --entrypoint cmd -p 80:80 -p 443:443 -h myweb -v c:\demo\appfiles:c:\temp microsoft/aspnet

Note that a few options are used in the command line. “-it” option is for an interactive session, “-p” for ports mapping, and “-v” for volume mapping between the local folder on the vm named demo to the container folder named temp. Using ipconfig to find the local ip address of the container, you can access the app hosted at “Default Web Site” via http, but not https. The reason is that no security certificate has been assigned to the web site.

Use the following PowerShell script to create a new certificate, add it to the trusted root of the certificate store on the container, bind it to port 443. Note that the New-SelfSignedCertificate cmdlet creates a self-signed certificate for testing purposes. It is a successor to the makecert tool. You can find more info on the tool here.

import-module webadministration
#Get-Module -ListAvailable

cd cert:
$cert = New-SelfSignedCertificate -DnsName  myweb -Friendlyname MyCert -CertStoreLocation Cert:\LocalMachine\My
$rootStore = New-Object System.Security.Cryptography.X509Certificates.X509Store -ArgumentList Root, LocalMachine
$rootStore.Open("MaxAllowed")
$rootStore.Add($cert)
$rootStore.Close()

cd iis:
new-item -path IIS:\SslBindings\0.0.0.0!443 -value $cert
New-WebBinding -Name "Default Web Site" -IP "*" -Port 443 -Protocol https
iisreset

Refresh the https web page. It should be assessable now.  Note that you may get a security certificate warning even though the certificate has been added to the trusted root. (The same script worked on on my local IIS server and I didn’t get certificate warning or error.) The reason is that it is a self-issued certificate, which, unlike commercially available certificates, is not countersigned by a trusted authority.

Option 2 – Use dockerfile published at github

First, create a container using my own docker id named xuedocker.

docker build -t xuedocker/iishttps .\

docker images

docker run -it --entrypoint cmd -p 80:80 -p 443:443 -h myweb -v c:\demo\appfiles:c:\temp xuedocker/iishttps

Then, copy a sample htm file from the mapped temp folder to c”\iputnet\wwwroot on the container. The sample app is accessible through http or https.

Note the security certificate warning. This is because the certificate is not present in your container’s trusted root certificate authorities. Because containers do not provide your regular Windows user interface, you won’t be able to check if the certificate is in the root certificate folder through certificate manager as shown below.

However, you can run PowerShell commands to verify its existence or absence.

import-module webadministration

cd cert:

cd localmachine

cd my

dir

cd..

cd root

dir

To add the self-signed certificate to the trusted root, use the PowerShell commands by referencing the certificate’s thumbprint

$cert = cert:\localmachine\my\gci EB61F71C77E561B2148F9F207A3468BAF794DF07

$rootStore = New-Object System.Security.Cryptography.X509Certificates.X509Store -ArgumentList Root, LocalMachine

$rootStore.Open("MaxAllowed")

$rootStore.Add($cert)

$rootStore.Close()

The certificate is now added to the trusted root. Note that the certificate was bound to port 443 already, executing commands below returns errors.

cd iis:
new-item -path IIS:\SslBindings\0.0.0.0!443 -value $cert
New-WebBinding -Name "Default Web Site" -IP "*" -Port 443 -Protocol https
iisreset

Option 3 – Use import-certificate and import-pfxcertificate methods

If you work with commercially available certificates, you can import certificates to the containers using import-certificate and import-pfxcertificate methods. I will provide more detail once I have tested this option.

Lastly, my colleague Patrick Lang, senor program manager on the Windows Container team, mentioned a couple other approaches related to SSL and containers.

SSL Load balancer. With this option, an SSL load balancer handles decryption of requests and encryption of responses on behalf of the web server or the container.

More info at https://www.nginx.com/resources/glossary/ssl-load-balancer/ and https://dzone.com/articles/load-balancing-containers-with-docker-swarm-and-ng

Secure storage in Docker v1.13. With this feature, a possible workflow would be something like this.

1. Create certificates through whatever existing means you have
2. Export as PKCS#7 or any other format that can be represented as ascii text
3. Docker secret create … to store the certificate in the raft
4. Create a script or EXE to run inside the container that:
   1. Finds the certificate passed in
   2. Imports it to the Windows certificate store
5. Finishes configuring IIS or other services

More info at https://lostechies.com/gabrielschenker/2016/11/25/docker-and-swarmkit-part-6-new-features-of-v1-13/