·      Kubernetes and Microsoft Azure

·       Programmatic scripting of Kubernetes deployment

·       Provisioning the Azure Kubernetes infrastructure with a declarative template

·       Configuring the Azure Kubernetes infrastructure with Bash scripts and Ansible tasks

·       Automating the Kubernetes UI dashboard configuration

·       Using Kubernetes…

As we have seen previously, it’s possible to use ARM extension to execute commands on the provisioned machines. In order to automate the required setup on each machine, we may consider different options. We could manage the cluster configuration with a collection of scripts but the more efficient way is surely to keep a declarative logic instead of a pure programming approach. What we need is a consistent, reliable, and secure way to manage the Kubernetes cluster environment configuration without adding extra complexity due to an automation framework. That’s why we’ve chosen Ansible.

Ansible role in Kubernetes configuration

Ansible is a solution for configuration management based on a state-driven resource model that describes the desired state of the target, not the paths to get them to this state. Ansible role is to transform the environment to the desired state and to allow reliable and repeatable tasks without the failures risks related to scripting. So in order to handle the Kubernetes configuration, we have provisioned a dedicated Ansible controller which role is to enact configuration on the different type of nodes.

Ansible playbooks

Ansible automation jobs are declared with a simple description language (YAML), both human-readable and machine-parsable, in what is called an Ansible playbook.

Ansible playbook implementation

Playbooks are the entry point of an Ansible provisioning. They contain information about the systems where the provisioning should be executed, as well as the directives or steps that should be executed. They can orchestrate steps of any ordered process, even as different steps must bounce back and forth between sets of machines in particular orders.

Each playbook is composed of one or more “plays” in a list, which goal is to map a group of hosts to some well-defined roles (in our Kubernetes cluster: “master”, “node”, “etcd”) represented by tasks that call Ansible modules. By composing a playbook of multiple “plays”, it is possible to orchestrate multi-machine deployments. In our context, Ansible playbook enables to orchestrate multiple slices of the Kubernetes infrastructure topology, with very detailed control over how many machines to tackle at a time. So one of the critical task of our implementation was to create these playbooks.

When Hervé and I began to work on this automated Ansible CentOS Kubernetes deployment, we checked if there weren’t any existing asset we should build the solution upon. And we found exactly what we were looking for with the repository “Deployment automation of Kubernetes on CentOS 7” on GitHub (https://github.com/xuant/ansible-kubernetes-centos)

Note: Hervé did a fork from this git repository in order to enable further modification (https://github.com/herveleclerc/ansible-kubernetes-centos.git) and I made a submodule ["ansible-kubernetes-centos"] from this fork in order to clone this Git repository and keep it as a subdirectory of our main Git repository (to keep commits separate).

Here's what the main playbook (https://github.com/herveleclerc/ansible-kubernetes-centos/blob/master/integrated-wait-deploy.yml) currently looks like:

---

- hosts: cluster

  become: yes

  gather_facts: false

  tasks:

  - name: "Wait for port 3333 to be ready"

    local_action: wait_for port=3333 host="{{ inventory_hostname }}" state=started connect_timeout=2 timeout=600

- hosts: cluster

  become: yes

  roles:

    - common

    - kubernetes

- hosts: etcd

  become: yes

  roles:

    - etcd

- hosts: masters

  become: yes

  roles:

    - master

- hosts: minions

  become: yes

  roles:

    - minion

- hosts: masters

  become: yes

  roles:

    - flannel-master

- hosts: minions

  become: yes

  roles:

    - flannel-minion

Ansible playbook deployment

Ansible allows you to act as another user (through the “become: yes” declaration), different from the user that is logged into the machine (remote user). This is done using existing privilege escalation tools like sudo. As the playbook is launched through the ARM custom extension, the default requirement for a “tty” has to be disabled for the sudo users (and after playbook execution, to be re-enabled). The corresponding code that triggers the “integrated-wait-deploy.yml” playbook deployment is given with the following function:

function deploy()

{

  sed -i 's/Defaults    requiretty/Defaults    !requiretty/g' /etc/sudoers

  ansible-playbook -i "${ANSIBLE_HOST_FILE}" integrated-wait-deploy.yml | tee -a /tmp/deploy-"${LOG_DATE}".log

  sed -i 's/Defaults    !requiretty/Defaults    requiretty/g' /etc/sudoers

}

Solution environment setup

This Kubernetes nodes and the Ansible controller should have the same level of OS packages.

Ansible controller and nodes software environment

The software environment of the virtual machines involved in this Kubernetes cluster is setup through the usage of the Open Source EPEL (Extra Packages for Enterprise Linux) Linux repository (a repository of add-on packages that complements the Fedora-based Red Hat Enterprise Linux (RHEL) and its compatible spinoffs, such as CentOS and Scientific Linux).

Current EPEL version is the following:

EPEL_REPO=https://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-8.noarch.rpm

Please note that sometimes a new EPEL release is published without any guaranty for the previous one retention. So a current limitation with our current template is the requirement to update this EPEL url when there’s a new version for software packages hosted on EPEL repository.

The version of the EPEL repository is specified in “ansible-config.sh” and “node-config.sh” scripts with the following function:

function install_epel_repo()

{

   rpm -iUvh "${EPEL_REPO}"

}

Ansible controller setup

Ansible setup is achieved through a simple clone from GitHub and a compilation of the corresponding code.

Here is the code of the corresponding function:

function install_ansible()

{

  rm -rf ansible

  git clone https://github.com/ansible/ansible.git --depth 1

  cd ansible || error_log "Unable to cd to ansible directory"

  git submodule update --init --recursive

  make install

}

The “make install” that does the compilation first requires “Development Tools groups” to be installed.

function install_required_groups()

{

  until yum -y group install "Development Tools"

  do

    log "Lock detected on VM init Try again..." "N"

    sleep 2

  done

}

Ansible configuration

Ansible configuration is defined in two files, the “hosts” inventory file and the “ansible.cfg” file. The Ansible control path has to be shorten to avoid errors with long host names, long user names or deeply nested home directories. The corresponding code for the “ansible.cfg” creation is the following:

function configure_ansible()

{

  rm -rf /etc/ansible

  mkdir -p /etc/ansible

  cp examples/hosts /etc/ansible/.

  printf "[defaults]\ndeprecation_warnings=False\n\n" >> "${ANSIBLE_CONFIG_FILE}"

  printf "[defaults]\nhost_key_checking = False\n\n" >> "${ANSIBLE_CONFIG_FILE}"

  echo $'[ssh_connection]\ncontrol_path = ~/.ssh/ansible-%%h-%%r' >>                

                                                           "${ANSIBLE_CONFIG_FILE}"  

  printf "\npipelining = True\n" >> "${ANSIBLE_CONFIG_FILE}"  

}

Ansible connection management

Ansible represents the machines it manages using a simple INI file that organizes the Kubernetes nodes in groups corresponding to their role. In our solution we created “etcd”,”master”,”minion” groups completed by a “cluster” role that gathers all the nodes.

Here's what the plain text inventory file (“/etc/ansible/hosts”) looks like:

This inventory has to be dynamically created depending on the cluster size requested in the ARM template.

Inventory based on Kubernetes nodes dynamically generated private IP

In our first ARM template implementation, each Kubernetes node launches a short “first-boot.sh” custom script in order to specify its dynamically generated private IP and its role in the cluster.

privateIP=$1

role=$2

FACTS=/etc/ansible/facts

mkdir -p $FACTS

echo "${privateIP},${role}" > $FACTS/private-ip-role.fact

chmod 755 /etc/ansible

chmod 755 /etc/ansible/facts

chmod a+r $FACTS/private-ip.fact

exit 0

In this version, the “deploy.sh” script makes ssh requests to nodes to get their private IP in order to create the inventory file. Here is an extract of the code of the corresponding function:

function get_private_ip()

{

  let numberOfMasters=$numberOfMasters-1

  for i in $(seq 0 $numberOfMasters)

  do

    let j=4+$i

       su - "${sshu}" -c "ssh -l ${sshu} ${subnetMasters3}.${j} cat $FACTS/private-ip-role.fact" >> /tmp/hosts.inv

  done

#...and so on for etcd, and minions nodes

}

Inventory based on Kubernetes nodes static ARM computed IP

In our second ARM implementation (the “linked” template composed from several ones), private IPs are computed directly in the ARM script. The following code is extracted from “KubeMasterNodes.json”:

  "resources": [

    {

      "apiVersion": "[parameters('apiVersion')]",

      "type": "Microsoft.Network/networkInterfaces",

      "name": "[concat(parameters('kubeMastersNicName'), copyindex())]",

      "location": "[resourceGroup().location]",

      "copy": {

        "name": "[variables('kubeMastersNetworkInterfacesCopy')]",

        "count": "[parameters('numberOfMasters')]"

      },

      "properties": {

        "ipConfigurations": [

          {

            "name": "MastersIpConfig",

            "properties": {

              "privateIPAllocationMethod": "Static",

              "privateIPAddress": "[concat(parameters('kubeMastersSubnetRoot'), '.',add(copyindex(),4) )]",

              "subnet": {

                "id": "[parameters('kubeMastersSubnetRef')]"

              },

              "loadBalancerBackendAddressPools": [

                {

                  "id": "[parameters('kubeMastersLbBackendPoolID')]"

                }

              ],

              "loadBalancerInboundNatRules": [

                {

                  "id": "[concat(parameters('kubeMastersLbID'),'/inboundNatRules/SSH-', copyindex())]"

                }

              ]

            }

          }

        ]

      }

    },

 In the “ansible-config.sh” custom script file, there is the function that creates this inventory:

function create_inventory()

{

  masters=""

  etcd=""

  minions=""

  for i in $(cat /tmp/hosts.inv)

  do

    ip=$(echo "$i"|cut -f1 -d,)

    role=$(echo "$i"|cut -f2 -d,)

    if [ "$role" = "masters" ]; then

      masters=$(printf "%s\n%s" "${masters}" "${ip} ansible_user=${ANSIBLE_USER} ansible_ssh_private_key_file=/home/${ANSIBLE_USER}/.ssh/idgen_rsa")

    elif [ "$role" = "minions" ]; then

      minions=$(printf "%s\n%s" "${minions}" "${ip} ansible_user=${ANSIBLE_USER} ansible_ssh_private_key_file=/home/${ANSIBLE_USER}/.ssh/idgen_rsa")

    elif [ "$role" = "etcd" ]; then

      etcd=$(printf "%s\n%s" "${etcd}" "${ip} ansible_user=${ANSIBLE_USER} ansible_ssh_private_key_file=/home/${ANSIBLE_USER}/.ssh/idgen_rsa")

    fi

  done

  printf "[cluster]%s\n" "${masters}${minions}${etcd}" >> "${ANSIBLE_HOST_FILE}"

  printf "[masters]%s\n" "${masters}" >> "${ANSIBLE_HOST_FILE}"

  printf "[minions]%s\n" "${minions}" >> "${ANSIBLE_HOST_FILE}"

  printf "[etcd]%s\n" "${etcd}"       >> "${ANSIBLE_HOST_FILE}"

}

As you may have noticed, this file completes the IP addresses with a path for the SSH private key.

Ansible security model

Ansible does not require any remote agents to deliver modules to remote systems and to execute tasks. It respects the security model of the system under management by running user-supplied credentials and as we’ve seen includes support for “sudo”. To secure the remote configuration management system, Ansible may also rely on the default transport layer through the usage of OpenSSH, which is more secure than password authentication. This is the way we decided to secure our deployment.

In our second ARM implementation SSH key generation is done through a simple call to “ssh-keygen” (In the first one, we use existing keys).

function generate_sshkeys()

{

  echo -e 'y\n'|ssh-keygen -b 4096 -f idgen_rsa -t rsa -q -N ''

}

Then the configuration is done by copying the generated key file in the .ssh folder for “root” and “Ansible” users and by changing their permissions.

function ssh_config()

{

  printf "Host *\n  user %s\n  StrictHostKeyChecking no\n" "${ANSIBLE_USER}"  >> "/home/${ANSIBLE_USER}/.ssh/config"

  cp idgen_rsa "/home/${ANSIBLE_USER}/.ssh/idgen_rsa"

  cp idgen_rsa.pub "/home/${ANSIBLE_USER}/.ssh/idgen_rsa.pub"

  chmod 700 "/home/${ANSIBLE_USER}/.ssh"

  chown -R "${ANSIBLE_USER}:" "/home/${ANSIBLE_USER}/.ssh"

  chmod 400 "/home/${ANSIBLE_USER}/.ssh/idgen_rsa"

  chmod 644 "/home/${ANSIBLE_USER}/.ssh/idgen_rsa.pub"

}

We also have to define a way to propagate SSH keys between Ansible controller and Kubernetes nodes. At least the SSH public key is stored in the .ssh/authorized_keys file on all the computers Ansible has to log in to while the private key is kept on the computer the Ansible user log in from (in fact we have automated the copy of both public and private keys, because having the ability to SSH from any machine to the other was sometimes quite useful during development phase…). In order to do this, we use Azure Storage.

SSH Key files sharing

The “ansible-config.sh” file launched in Ansible controller generates the SSH keys and stores them in a blob in an Azure storage container with the “WriteSSHToPrivateStorage.py” Python script.

function put_sshkeys()

 {

  log "Push ssh keys to Azure Storage" "N"

  python WriteSSHToPrivateStorage.py "${STORAGE_ACCOUNT_NAME}" "${STORAGE_ACCOUNT_KEY}" idgen_rsa

  error_log "Unable to write idgen_rsa to storage account ${STORAGE_ACCOUNT_NAME}"

  python WriteSSHToPrivateStorage.py "${STORAGE_ACCOUNT_NAME}" "${STORAGE_ACCOUNT_KEY}" idgen_rsa.pub

  error_log "Unable to write idgen_rsa.pub to storage account ${STORAGE_ACCOUNT_NAME}"

}

Here is the corresponding “WriteSSHToPrivateStorage.py” Python function:

import sys,os

from azure.storage.blob import BlockBlobService

from azure.storage.blob import ContentSettings

block_blob_service = BlockBlobService(account_name=str(sys.argv[1]), account_key=str(sys.argv[2]))

block_blob_service.create_container('keys')

block_blob_service.create_blob_from_path(

    'keys',

    str(sys.argv[3]),

    os.path.join(os.getcwd(),str(sys.argv[3])),

    content_settings=ContentSettings(content_type='text')

)

The “node-config.sh” file launched in Ansible controller gets the SSH key files in Azure storage with the “ReadSSHToPrivateStorage.py” Python script which code is the following:

import sys,os

from  azure.storage.blob import BlockBlobService

blob_service = BlockBlobService(account_name=str(sys.argv[1]), account_key=str(sys.argv[2]))

blob = blob_service.get_blob_to_path(

    'keys',

    str(sys.argv[3]),

    os.path.join(os.getcwd(),str(sys.argv[3])),

    max_connections=8

)

These two Python functions require the corresponding Python module to be installed on the Ansible controller and Kubernetes nodes. One easy way to do it is first to install “pip”. Pip is a package management system used to install and manage software packages written in Python. Here is the code corresponding to this setup.

function install_required_packages()

{

  until yum install -y git python2-devel python-pip libffi-devel libssl-dev openssl-devel

  do

    sleep 2

  done

}

function install_python_modules()

{

  pip install PyYAML jinja2 paramiko

  pip install --upgrade pip

  pip install azure-storage

}

But providing the technical mechanism to share SSH keys files between Kubernetes nodes and Ansible controller is not sufficient. We have to define how they both interact with each other.

Synchronization between Ansible controller and nodes

One of the complex requirements of the solution we propose is the way we handle the synchronization of the different configuration tasks.

ARM “depensOn” and SSH key files pre-upload solution

In our first ARM template implementation, this is easily handled through the usage of “dependsOn” attribute in the ARM template. This solution requires all the nodes to be deployed before launching the Ansible playbook with a custom “deploy.sh” script extension. This script is deployed on the Ansible controller with the “fileUris” settings (“scriptBlobUrl”). The others filesUris correspond to the SSH key files used for Ansible secure connection management (and another token file used for monitoring through Slack).

In this solution, synchronization between Ansible controllers and node is quite easy but requires the publication of SSH key files in an Azure storage account (or an Azure Key vault) before launching the template deployment, so Ansible controller may download them before running the playbooks. If these files are not deployed before launching the deployment, it will fail. Here are the corresponding files displayed with the Azure Management Studio tool.

The following code is extracted from the “azuredeploy.json” and corresponds to the Ansible extension provisioning.

Netcat synchronization and automated Python SSH key files sharing through Azure Storage

The second ARM implementation (the “linked” template composed from several ones) enables to avoid to pre-publish keys in a vault by directly generating these keys during deployment. As this solution may appear more elegant and more secure, by specializing a generated SSH key for Ansible configuration management instead of sharing existing keys for other purpose, it adds a significant level of complexity, because it requires now to handle in parallel both Ansible controller and Kubernetes nodes configuration.

The bash script on the Ansible controller generates SSH keys but have to wait for the nodes to get theses keys and declared them as authorized for logon before launching the Ansible playbook. A solution to this kind of scenario may be implemented thanks to the usage of Netcat, a networking utility using the TCP/IP protocol, which reads and writes data across network connections, and that can be used directly or easily driven by other programs and scripts. The way we synchronized both scripts “config-ansible.sh” and “config-node.sh” is described with the following schema.

So the first machines which have to wait are the nodes. As they are waiting for getting a file, it’s quite simple to have them making this request periodically in pull mode until the file is there (with a limit on attempts number). The code extracted from “config-node.sh” is the following.

function get_sshkeys()

 {

    c=0;

   sleep 80

    until python GetSSHFromPrivateStorage.py "${STORAGE_ACCOUNT_NAME}" "${STORAGE_ACCOUNT_KEY}" idgen_rsa

    do

        log "Fails to Get idgen_rsa key trying again ..." "N"

        sleep 80

        let c=${c}+1

        if [ "${c}" -gt 5 ]; then

           log "Timeout to get idgen_rsa key exiting ..." "1"

           exit 1

        fi

    done

    python GetSSHFromPrivateStorage.py "${STORAGE_ACCOUNT_NAME}" "${STORAGE_ACCOUNT_KEY}" idgen_rsa.pub

}

In order to launch the Netcat server in the background (using the & command at the end of the line), and logout from the “config-node.sh” extension script session without the process being killed, the job is executed with “nohup” command (which stands for “no hang up”).

To make sure that the Netcat server launching will not interfere with foreground commands and will continue to run after the extension script logouts, it’s also required to define the way input and output are handled. The standard output will be redirected to “/tmp/nohup.log” file (with a “> /tmp/nohup.log” and the standard error will be redirected to stdout (with the “2>&1” file descriptor), thus it will also go to this file which will contain both standard output and error messages from the Netcat server launching. Closing input avoids the process to read anything from standard input (waiting to be brought in the foreground to get this data). On Linux, running a job with “nohup” automatically closes its input, so we may consider not to handle this part, but finally the command I decided to use was this one.

function start_nc()

{

  log "Pause script for Control VM..." "N"

  nohup nc -l 3333 </dev/null >/tmp/nohup.log 2>&1 &

}

The “start_nc()” function is the last one called in the “config-node.sh” file, which is executed on each cluster node. On the other side, the “ansible-config.sh” file launched in Ansible controller executes without any pause and launches the Ansible playbook. This is the role of this playbook to wait for the availability of the Netcat Server (that shows that the “config-node.sh” script is terminated with success). This is easily done with the simple task we’ve already seen. This task is executed for any host belonging to the Ansible “cluster” group, i.e all the Kubernetes cluster nodes.

- hosts: cluster

  become: yes

  gather_facts: false

  tasks:

  - name: "Wait for port 3333 to be ready"

    local_action: wait_for port=3333 host="{{ inventory_hostname }}" state=started connect_timeout=2 timeout=600

One last important point is how we handle the monitoring of the automated tasks.

Monitoring the automated configuration

Monitoring this deployment part supposes to be able to monitor both custom script extension and Ansible playbook execution.

Custom script logs

One way to monitor both script extension and Ansible automated configuration is to connect to the provisioned VM and check the “stdout” and the “errout” files in the waagent (Azure Microsoft Azure Linux Agent that manages Linux VM interaction with the Azure Fabric Controller) directory :  “/var/lib/waagent/Microsoft.OSTCExtensions.CustomScriptForLinux-1.4.1.0/download/0”

A more pleasant way is to monitor the custom script execution directly from Slack.

In order to get in realtime the output from the “ansible-config.sh” and “node-config.sh” deployment custom script, you just have to define “Incoming WebHooks” in your Slack team project.

This gives you a WebHook extension URL which can directly be called from those bash scripts in order to send your JSON payloads to this URL.

LOG_URL=https://hooks.slack.com/services/xxxxxxxx/yyyyyyy/zzzzzzzzzzzzzzzzzzzzzz

Then it’s quite easy to integrate this in a log function such as this one:

function log()

{

  #...

  mess="$(date) - $(hostname): $1 $x"

  payload="payload={\"icon_emoji\":\":cloud:\",\"text\":\"$mess\"}"

  curl -s -X POST --data-urlencode "$payload" "$LOG_URL" > /dev/null 2>&1

  echo "$(date) : $1"

}

Ansible logs

Ansible logs may also be read from playbook execution output which is piped to a tee command in order to write it to the terminal, and to the /tmp/deploy-"${LOG_DATE}".log file.

Once again it’s possible to use Slack to get Ansible logs in realtime. In order to do that we have used an existing Slack Ansible plugin (https://github.com/traveloka/slack-ansible-plugin) which I added as submodule of our GitHub solution (https://github.com/stephgou/slack-ansible-plugin). Once it’s done, we just have to get the Slack incoming WebHook token in order to set the SLACK_TOKEN and SLACK_CHANNEL.

Please note that for practical reasons, I used base64 encoding in order to avoid to handle vm extension “fileuris” parameters outside of Github, because Github forbids token archiving. This current implement choice is definitely not a best practice. An alternative could be to put a file in a vault or a storage account and copy this file from the config-ansible.sh.

The corresponding code is extracted from the following function:

function ansible_slack_notification()

{

  encoded=$ENCODED_SLACK

  token=$(base64 -d -i <<<"$encoded")

  export SLACK_TOKEN="$token"

  export SLACK_CHANNEL="ansible"

  mkdir -p "/usr/share/ansible_plugins/callback_plugins"

  cd "$CWD" || error_log "unable to back with cd .."

  cd "$local_kub8/$slack_repo"

  pip install -r requirements.txt

  cp slack-logger.py /usr/share/ansible_plugins/callback_plugins/slack-logger.py

}

Thanks to this plugin it’s now possible to directly get Ansible logs in Slack.

Conclusion

The combination of ARM templates, custom script extension files and Ansible playbooks enabled us to install the required system packages to setup and configure Ansible, to deploy required Python modules (for example in order to share SSH key files through Azure Storage), to synchronize our nodes configuration and execute Ansible playbooks to finalize the Kubernetes deployment configuration.

Next time we’ll see how to automate the Kubernetes UI dashboard configuration… Stay tuned !

So first let’s explain the way we have automated Kubernetes Azure provisioning through ARM Templates.

Overview of the solution

Kubernetes infrastructure is made up of several components – virtual machine, storage account, and virtual network which are the related and interdependent parts of a single entity.

The targeted topology (generated with https://armviz.io) should be the following one:

Azure Resource Manager enables to deploy, manage these resources in a single, coordinated operation and monitor them as a group rather than handling them individually. With Azure Resource Manager, it’s possible to define dependencies between these resources so they are deployed in the correct order. Moreover, Azure Resource Manager provides tagging features to help manage these resources after deployment, auditing and security: Role-Based Access Control (RBAC) is natively integrated into the management platform.

Azure Resource Manager Template

Azure Resource Manager offers the ability to build templates and easily leverage them to deploy and manage resources on Azure. It’s a very efficient way to deploy a cluster of several virtual machines.

An Azure Resource Manager Template enables to deploy and manage these resources together by using a JSON description of the resources and associated deployment parameters. The template consists of JSON and expressions which you can use to construct values for your deployment. The template is organized in three sections:

·       In the parameters section of the template, you specify which values you can input when deploying the resources. These parameter values enable you to customize the deployment by providing values that are tailored for your particular environment.

·       In the variables section, you construct values that can be used throughout your template. Typically, these variables will be based on values provided from the parameters. The objective is to simplify your template by reducing complex expressions.

·       In the resources section, you define the resources to deploy or update using types defined in resource providers. When you deploy a template, you must specify an API version to use for creating each resource. The API version corresponds to a version of REST API operations that are released by the resource provider. As a resource provider enables new features, it will release a new version of the REST API. Therefore, the version of the API you specify in your template affects which properties you can specify in the template. In general, you will want to select the most recent API version when creating new templates. For existing templates, you can decide whether you want to continue using an earlier API version, or update your template for the latest version to take advantage of new features.

For example, the following extract corresponds to the provisioning of the network resource.

Linked ARM template

From within one Azure Resource Manager template, you can link to another template which enables you to decompose your deployment into a set of targeted, purpose-specific templates. This facilitates the reading and maintenance of the template.  

In our solution, provisioning of a Kubernetes cluster built upon a configurable number of etcd nodes and Kubernetes nodes (master and minions) is implemented with a linked Azure Resource Manager Template “azuredeploy.json” combined with its parameters file “azuredeploy.parameters.json”.

Note : In the current armviz.io version, the previously displayed diagram is the one related to the global “azuredeploy.json” template [https://github.com/DXFrance/AzureKubernetes/blob/master/Kubernetes-Ansible-Centos-Azure/azuredeploy.json], not the linked one, which will be the one presented in this article [https://github.com/DXFrance/AzureKubernetes/blob/master/AzureKubernetes/Templates/VM-Cluster/azuredeploy.json].

The declaration for the usage of a linked template is similar to the declaration of a native Azure resource:

You may also provision the infrastructure by directly editing the template from the portal.

And of course, independently of the way you deploy the template you may monitor the deployment directly from the portal. And that’s it. The following screen capture displays the result of the deployment of Kubernetes cluster resources through the linked template. It takes about 30 minutes to have the solution fully deployed.

Next…

Provisioning of the whole topology is not so difficult when you get used to it. What’s may be more complex is how to automate the configuration through extension, especially when there are dependencies between them and that’s what I will explain in my next article.

Stay tuned!

So let’s explain different ways of automating Kubernetes deployment through scripting technologies (Azure CLI and PowerShell).

Overview of the solution

Provisioning of a Kubernetes cluster built upon a configurable number of etcd nodes and Kubernetes nodes (master and minions) is implemented with Azure CLI (init-static/init-script.sh) and PowerShell (AzureKubernetes/Scripts/Deploy-VM-Cluster-PowerShell.ps1).

Configuration of cluster CoreOS nodes is achieved through declaration in cloud-config file of various OS-level items (network configuration, user accounts, systemd units) that will be used by coreos-cloudinit program to configures the OS after startup or during runtime (https://coreos.com/os/docs/latest/cloud-config.html).

The whole deployment is achieved within about 20 minutes.

Cloud-config file

The implemented Azure CLI generates a cloud-config files depending on the configuration. The PowerShell script implementation goes a bit less far. It simply reuses yml files generated by Azure CLI (“init-static\custom-data\kubernetes-cluster-etcd-nodes.yml” for etc nodes and “init-static\custom-data\kubernetes-cluster-main-nodes-template.yml" for master and minion nodes) in order to apply the targeted nodes configuration.

For both cloud-config files (“kubernetes-cluster-etcd-nodes.yml” and “kubernetes-cluster-main-nodes-template.yml”), the file uses the YAML file format, which uses whitespace and new-lines to delimit lists, associative arrays, and values. It contains a “#cloud-config” header followed by an associative array “coreos” and “write_files” keys:

·       The coreos.update.* parameters manipulate settings related to how CoreOS instances are updated. These fields will be written out to and replace “/etc/coreos/update.conf”. The “coreos.units.*” parameters define a list of arbitrary systemd units to start after booting. This feature is intended to start essential services required to mount storage and configure networking. Each item is an object with the following fields: name (unit’s name), content (unit file), command (command to execute on unit: start, stop, reload, restart,...).

·       The write_files directive defines a set of files to create on the local filesystem. Each item in the list may have the following keys: path (absolute location on disk where contents should be written, content (data to write at the provided path), permissions, owner….

The following “kubernetes-cluster-etcd-nodes.yml” file is the cloud-config file for the etcd node. It’s a very short one, because the etcd role is quite simple to configure.

The “kubernetes-cluster-main-nodes-template.yml” file is quite bigger. It declares for each role, the different required services. For example, in the master node, the unit name “kubernetes-master” requires “weave network” and will be configured with “kube-apiserver”, “kube-scheduler”, “kube-controller-manager” and “kube-proxy” services, as described on Kubernetes cluster deployment topology.

The launch of the corresponding service will be done by bash script inside “ExecStartPre” or “ExecStart” commands. For example, the installation of the “kube-scheduler” service is the following:

These services may themselves be dependent on other ones. For example, all Kubernetes services require first the installation of Kubernetes, which is done in the following way:

Once the cloud-config files are ready, you just have to inject them with the “CustomData” option which is available for both Azure CLI and PowerShell.

In PowerShell, the corresponding parameter is “-CustomData”:

     $vm = Set-AzureRmVMOperatingSystem -VM $vm -Linux -ComputerName $vmName `

-Credential $credential -CustomData $customData   

In Azure CLI, the corresponding parameter is “--custom-data”:

And that’s it for the programmatic deployment of a Kubernetes cluster.

Stay tune for the next article. We will speak about a declarative way to reach the same objective.

These are the articles I have planned to write:

Let’s start first by presenting Kubernetes and why and how to deploy it in Azure.

Kubernetes

Kubernetes is an open-source orchestration platform for automating deployment, operations, and scaling of applications across multiple hosts. It targets applications composed of multiple Docker containers, such as distributed micro-services and provides ways for containers to find and communicate with each other. It enables users to ask a cluster to run a set of containers with an automatic scheduling and choice of the hosts to run those containers on. It regroups containers that make up an application into logical units for easy management with self-healing mechanisms (auto-restarting, re-scheduling, and replicating containers) and discovery.

Kubernetes has been created by Google but contributors to this project now include IBM, Microsoft, Red Hat, CoreOS, Mesosphere, and others…

Kubernetes concepts

A Kubernetes cluster is made up of several nodes with different roles such as master, minions, and etcd (https://github.com/kubernetes/kubernetes#concepts). The master is responsible for managing the cluster and issuing requests to be performed by the minions. The minions are the Kubernetes nodes that actually run Docker workloads. Pods represent a co-located group of application containers with shared volumes. They are scheduled to run and are balanced across the minions by the master. Replication controllers manage the lifecycle of pods and ensure that a specified number of pods are running at any given time, while services provide a single, stable name and address for a set of pods. Etcd is a distributed, highly-available, consistent key-value store for shared configuration and service discovery which Kubernetes uses for persistent storage of all of its REST API objects.

Kubernetes networking model

For communicating over a network, containers are tied to the IP addresses of the host machines and must rely on port-mapping to reach the desired container. This makes it difficult for applications running inside containers to advertise their external IP and port as that information is not available to them. Kubernetes allocates an IP address to each pod. It is required to allocate a different block of IPs to each node in the cluster as the node is added, so any process in one pod could communicate with another one running in a second pod through IP connectivity.

This can be achieved by configuring a network to route Pod IPs or by creating an overlay network with weave or flannel:

·       A weave network consists of a number of “peers” - weave routers residing on different hosts. Weave routers establish TCP connections to each other, over which they perform a protocol handshake and subsequently exchange topology information.

·       A flannel network gives each container an IP that can be used for container-to-container communication. It uses packet encapsulation to create a virtual overlay network that spans the cluster. It gives each host an IP subnet from which the Docker daemon is able to allocate IPs to the individual containers. flannel uses etcd to store mappings between the virtual IP and host addresses.

Kubernetes cluster deployment topology

Depending on networking model (weave or flannel), Kubernetes cluster deployment topology should correspond to the following representation.

Why Kubernetes on Microsoft Azure?

Docker brings a more flexible deployment model using containers as its runtime. Kubernetes offers a way to manage those containers that imposes less overhead on servers when multiple workloads are shared on a single machine. Moreover, containers can be fired up and removed at a much faster pace than with machine virtualization. Kubernetes is intended to run on physical hosts as well as cloud providers such as Microsoft Azure. That’s why Scott Guthrie, Executive Vice President of the Cloud and Enterprise group at Microsoft has stated: “Microsoft will help contribute code to Kubernetes to enable customers to easily manage containers that can run anywhere. This will make it easier to build multi-cloud solutions including targeting Microsoft Azure.”

Running Kubernetes on Azure

Kubernetes documentation offers detailed guidance on the way to deploy a Kubernetes cluster to Azure (https://kubernetes.io/docs/getting-started-guides/coreos/azure). The proposed implementation relies on the usage of CoreOs virtual machines, with Weave Network for communication. Provisioning of Kubernetes master, minions and etcd nodes is done through Azure CLI and call to a node.js script “./create-kubernetes-cluster.js”, which is published on https://github.com/kubernetes/kubernetes. This script provisions a cluster with a ring of three dedicated etcd nodes, one kubernetes master and two kubernetes minions for the containers workloads deployment.

Automating a Kubernetes cluster deployment in Azure

Automating a Kubernetes cluster deployment in Azure requires first cluster provisioning, and then each cluster node configuration. Scripted cluster provisioning in Azure can be done in many ways, that’s why we propose three different solutions: PowerShell ARM cmdlets, Azure CLI and json ARM Templates. Configuration requires the ability to extend the configuration of the different nodes. This can be done through cloud-config file CoreOs mechanism. It can also be achieved through the usage of Ansible tasks. We have also explored and implemented both ways.

So first solution is to provision a Kubernetes through PowerShell or Azure CLI using cloud-config file. Second solution is an ARM json template built upon linked templates, that relies on Ansible tasks for Kubernetes roles setup.

All the following code is published online on https://github.com/DXFrance/AzureKubernetes.

Stay tuned for the next article…

But today, I will not blog about DevOps. This article is the extension of my previous Microsoft Cloud Data Platform post. I would like to share a comparison matrix built with my friend Benjamin Guinebertière on the multiple ways of envisioning a Storage and Analysis Platform with Microsoft Azure Services, depending on several criteria : programming model, batch vs realtime, provisioning duration, pricing, reversibility, scaling, stop/start option, proprietary vs Open Source…

I hope you will find this matrix useful. Please do not hesitate to comment this attempt of comparison so I could update and enhance this table.

• Solution et choix d’implémentation
• Mise en œuvre d’un service de recherche
• Consommation du service de recherche par une application Web
• Exposition du service de recherche
• Consommation du service de recherche par une application Universelle
• Gestion d’identité
• Code et configuration de l’application

Nous voici donc au terme de notre exploration de l’implémentation d’une solution fondée sur les Azure App Services. L’objectif est maintenant de vous permettre de récupérer le code et de déployer la solution correspondante dans le Cloud.

L’environnement de développement

Il vous faudra installer un Visual Studio dans sa version 2015. La « Version communautaire » devrait théoriquement suffire, mais si vous disposez d’une version « Professional » ou « Entreprise », c’est encore mieux…
Le Microsoft Azure SDK for .NET - 2.7 Azure est disponible ici. Je vous invite à plutôt utiliser Microsoft Web Platform Installer (Web PI 5.0), l’outil de référence pour mettre à jour les derniers composants de la plateforme Microsoft.
Un simple Build devrait vous permettre de récupérer les packages NuGet requis (à condition d’activer l’option « Enable NuGet Package Restore » par un simple clic droit sur la solution Visual Studio).

Code de l’application

Le code de l’application est ici. Vous pouvez le récupérer en le téléchargeant depuis le portail GitHub ou  avec la ligne de commande : https://github.com/stephgou/Thot.git

Initialisation des services Backend

La première étape consiste à ouvrir une souscription Azure pour ceux qui n’en disposeraient pas encore. Pour ce faire, je vous invite à lire l’article « Testez Azure gratuitement pendant un mois » de mon collègue et ami Benjamin Guinebertière.
Une fois votre souscription activée, il faut créer un compte et un conteneur Microsoft Azure Storage. La procédure à suivre est décrite dans l’article du MSDN « Leçon 1 : Créer un compte et un conteneur Microsoft Azure Storage » .
Il faut ensuite créer une instance de service « Azure Search ». Le début du tutorial « Prise en main de votre première application Azure Search dans .NET » devrait vous permettre de rapidement réaliser cette tâche…
La création du tenant Azure Active Directory se fait depuis le portail actuel.

Enfin, il faut y déclarer au moins un utilisateur de l’application. L’article « Création ou modification d’utilisateurs dans Azure AD » devrait vous éclairer sur ce point.

Configuration des paramètres liés aux services Backend

Une fois ces premiers éléments configurés, il faut ensuite renseigner dans le code les différentes clés Azure (« Azure Storage », « Azure Search ») requises pour faire fonctionner cette solution. Les fichiers à modifier dans la solution Visual Studio (« Doc.Search ») sont, en premier lieu, les fichiers de configuration :

• Le fichier « App.Config » du projet « BuildIndex.Search.App » correspondant à l’application console qui permet de créer et d’initialiser l’index du service de recherche à partir du contenu d’un compte de stockage.
• Le fichier « Web.Config » du projet « Doc.Search.Portal » correspondant à la « Web App » permettant de télécharger des documents sur le stockage Azure et d’effectuer des recherches sur ce contenu.
• Le fichier « Web.Config » du projet « Doc.Search.API » correspondant à l’« API App » exposant de façon sécurisée le service de recherche pour l’application Universelle.

  <appSettings>

    <add key="SearchServiceApiKey" value="…" />

    <add key="SearchServiceName" value="…" />

    <add key="ApiKey" value="…" />

    <add key="ApiVersion" value="2014-07-31-Preview" />

    <add key="Endpoint" value="nom-endpoint-search-service.search.windows.net" />

    <add key="QueryKey" value="…" />

    <add key="IndexName" value="…" />

    <add key="SearchCriteria" value="docx" />

    <add key="AzureStorage.ConnectionString" value="DefaultEndpointsProtocol=https;AccountName=searchdoc;AccountKey=…" />

    <add key="AzureStorage.ContainerReference" value="public" />

  </appSettings>

Les paramètres SearchServiceApiKey (« PRIMARY ADMIN KEY ») et QueryKey (« docs ») sont disponibles dans le portail (partie masquée en rouge sur la copie d’écran).

Enfin, avant de pouvoir utiliser l’application, il faut définir l’index. Pour ce faire, il suffit de lancer l’application console « BuildIndex.Search.App » qui automatise la création de cette index selon la définition décrite dans l’article Implémentation d’une solution fondée sur les Azure App Services : Mise en œuvre du service de recherche.

Publication des services Backend

La publication des Azure App Service est réalisée directement depuis Visual Studio.
La première étape consiste à déployer la « Web App ».

Le site devrait être opérationnel, il est indépendant de l’« API App ». Je vous invite à vérifier son bon fonctionnement pour vous assurer que les paramètres ont été bien renseignés.
Puis il faut déployer l’« API App ». L’« API Gateway » sera créée par Visual Studio lors de la publication de l’API.

Enfin, il faut configurer cette « API App » et l’« API Gateway » en suivant les indications fournies dans mon précédent article « Implémentation d’une solution fondée sur les Azure App Services : Gestion d’identité ».
Je vous invite à vérifier que l’API App fonctionne avant sécurisation de l’« API Gateway », puis une fois la configuration achevée, en appliquant la démarche décrite dans ce même article.

Configuration de l’application universelle

Il ne reste plus qu’à renseigner les paramètres définis au sein de la classe « ThotSettings » dans le projet « Doc.Search.App » correspondant à l’application Universelle.

Ces paramètres API_APP (« URL ») et GATEWAY (« Gateway ») sont lisibles directement sur le nouveau portail Azure, au niveau de l’« API App ».

Conclusion

En principe, vous devriez maintenant pouvoir lancer cette application sans difficulté particulière.
Je n’ai pas eu le temps de m’assurer que la mise en œuvre des différentes étapes que je viens d’énoncer sur un environnement « vierge » permettait de parvenir à remonter la solution sans encombre. Je vous invite donc à me remonter tout élément permettant d’améliorer cette procédure.

D’avance, merci pour votre contribution…

• Solution et choix d’implémentation
• Mise en œuvre d’un service de recherche
• Consommation du service de recherche par une application Web
• Exposition du service de recherche
• Consommation du service de recherche par une application Universelle
• Gestion d’identité
• Code et configuration de l’application

L’objectif est maintenant de filtrer les accès sur l’« API App », exposée au-dessus du service backend « Azure Search » et d’adapter l’application Windows Universelle pour qu’elle puisse utiliser cette « API App », en donnant la possibilité à l’utilisateur de s’identifier depuis cette application…

Services d’authentification « Azure App Service »

« Azure App Service » propose des services d'authentification intégrés qui implémentent nativement OAuth 2.0 et OpenID et peuvent s’intégrer avec plusieurs fournisseurs d'identité (interne comme « Azure Active Directory » ou externes comme Microsoft Account, Google, Twitter ou Facebook).
Dans l’implémentation proposée, l’accès à l’« API App » sera donc maintenant restreint aux utilisateurs authentifiés sur « Azure Active Directory » (AAD).

« Azure Active Directory »

« Azure Active Directory » est un service Cloud de gestion d'identité destiné à offrir un accès par authentification unique à des milliers d’Applications SaaS, comme par exemple « Office 365 » ou Salesforce.com, .... « Azure Active Directory » propose de nombreuses fonctions comme l’authentification multi-facteurs ou l'intégration avec « Windows Server Active Directory ». Dans le contexte de l’implémentation de cette solution, si le choix s'est porté sur ce service, c'est surtout parce qu'il permet de rapidement intégrer un mécanisme d'authentification fondé sur l'utilisation d'un annuaire facile à administrer (tout en offrant une interface de gestion de mot de passe, en libre-service pour les utilisateurs qui y sont déclarés).

Configuration de l’« API App »

L’ « API App » propose trois paramètres d’authentification (« Access Level » dans les « Application Settings ») :

• Public (anonyme) - n'importe qui peut appeler l’« API App ».
• Public (authentifié) - seuls les utilisateurs authentifiés sont autorisés à appeler l’« API App » en dehors du groupe de ressources dans lequel est déployée l’« API App ».
• Interne - l’« API App » peut uniquement être appelée par d'autres « API App » déployées dans le même groupe de ressources.

Lorsque l’on souhaite configurer l’« API App » pour accepter uniquement les requêtes authentifiées, la première étape consiste donc à paramétrer son niveau d’accès sur Public (authentifié). Et pour exiger une authentification auprès d'un fournisseur d’identité comme « Active Directory Azure », il faut maintenant configurer une passerelle : l’« API Gateway ».

Configuration de l’« API Gateway »

L’« API Gateway » est créée par Visual Studio lors de la publication de l’API. Il s’agit d’une application web dont le rôle est de filtrer toutes les requêtes HTTP entrantes destinées aux « API Apps » du même groupe de ressources pour y inclure diverses tâches administratives, dont l'authentification.
La passerelle gère les procédures de connexion, les jetons et empêche les appels non authentifiés d'atteindre l’« API App » configurée pour exiger ce type d’accès. 

Le fournisseur d’identité de notre solution est « Azure Active Directory ». Pour bénéficier de ces services, il est nécessaire d’enregistrer l’« API App » « Doc.Search.API » en tant qu’application AAD.
Pour ce faire, on peut utiliser le portail Azure actuel et renseigner les paramètres « Sign-on URL », « App ID URI », et « Reply URL » obtenus par simple copie depuis le nouveau portail Azure, dans la configuration AAD de la passerelle.

On obtient alors un « Client ID » pour l’« API App » que l’on peut ensuite reporter, avec le « Allowed tenant » dans la configuration de la passerelle sur le nouveau portail.

Evolution du code de l’« API App »

La première évolution de l’« API App » consiste à modifier le fichier « apiapp.json » pour déclarer le fournisseur d’identité que l’on souhaite utiliser.

Il est également possible d’étendre l’« API App » pour ajouter une opération permettant d’obtenir le nom et l’email de la personne connectée. Ainsi, il sera possible depuis l’application universelle de faire un appel à cette méthode et d’afficher l’email de la personne identifiée. 
Pour tester l’accès restreint sur l’« API App », on peut utiliser un browser, en déclenchant d’abord une authentification sur l’« API Gateway », via son URL suffixée par « /login/aad » et en utilisant un compte défini sur le « tenant » AAD cible.
https://nom-de-la-gateway.azurewebsites.net/login/aad
Une fois l’utilisateur identifié sur l’« API Gateway », il devient alors possible de faire usage de l’API.Il ne reste plus maintenant qu’à modifier le code de l’application cliente de l’API pour qu’elle puisse passer les paramètres d’authentification requis.

Evolution du code de l’application Universelle

L’application mobile peut donner la possibilité de s’authentifier vis-à-vis d’AAD en intégrant la page de Logon comme l’illustre la copie d’écran suivante. 

Le SDK d’« App Service » offre une syntaxe simplifiée pour la gestion du code liée à l’identification de l’utilisateur et au contrôle d’accès qui en découle.
Les URLs de l’« API Gateway » et de l’« API App » doivent être connues de l’application cliente, ainsi que le type de fournisseur d’identité cible, dans notre contexte, la chaîne identifiant l’AAD.

        public const string GATEWAY = "https://nom-de-la-gateway.azurewebsites.net";
        public const string API_APP = "https://nom-de-la-api-app.azurewebsites.net";
        public const string AUTH_PROVIDER = "WindowsAzureActiveDirectory";

C’est dans le constructeur du « MainViewModel » qu’est réalisée l’authentification, par appel au constructeur « AppServiceClient » qui intègre nativement un mécanisme de connexion sur l’« API Gateway ». 

L’authentification est réalisée par l’appel à la méthode asynchrone « LoginAsync(…) », dans laquelle on spécifie le fournisseur d’identité cible. 
Il est important de bien choisir les conditions permettant de déclencher cette authentification. Il est parfois délicat de se mettre en attente d'un retour d'appel asynchrone à l’intérieur d’un gestionnaire d’évènement associé à la logique de chargement des fenêtres Windows.

J’avais initialement prévu de lancer cet appel sur l’évènement « OnNavigatedTo(…) ». Mais il semble que le modèle de navigation (utilisation d’une page « Shell » permettant d’afficher la page cible en utilisant un contrôle « SplitView ») de l’application rende ce choix inapproprié [la fenêtre de saisie des « credentials » ne s'affichait que si l’appel de la méthode de « LoginAsync(…) » était précédé d’un « Task.Delay » de 50 ms]. Pour contourner cette problématique, l’appel à la méthode est donc déclenché sur la première occurrence de l’évènement « GotFocus(…) » de la page « Shell ». 

Une fois authentifié sur l’« API Gateway », on peut alors faire usage de l’« API App » en lui communiquant le jeton délivré par AAD.
La première étape consiste à appeler la méthode « GetUserName() » pour afficher l’email de l’utilisateur dans la page « Welcome ». 

La méthode « GetUserName() » [de même que la méthode « LaunchSearch() » d’invocation du service de recherche] s’appuie sur un proxy que l’on peut obtenir par la méthode « CreateDocSearchAPI() ». Cette dernière est automatiquement générée par la fonction d’ajout « Azure API App Client » de Visual Studio. Son appel est réalisé depuis l’objet « _appServiceClient() » [lui-même à l’origine de l’appel de la méthode « LoginAsnc() »].
Elle offre la possibilité de mettre en cache des jetons d'authentification, afin que l'application n’ait pas besoin d'authentifier l'utilisateur à chaque appel grâce à l’utilisation de la classe « TokenExpiredHandler() ». Le code utilisé pour cette classe est issu de l’exemple Azure Cards. Il s’agit d’une évolution d’une classe fournie initialement pour l’authentification sur « Azure Mobile Services » (nom de code « Zumo », que l’on retrouve d’ailleurs dans l’implémentation…).

Pour gérer le cas où ce jeton expire, la classe « TokenExpireHandler() » dérive de la classe « DelegatingHandler() », une sous-classe de « HttpMessageHandler() ». 
Lorsque sa méthode « SendAsync » est appelée, elle envoie d'abord le message vers le reste du pipeline HTTP, et si elle obtient une réponse non autorisée (« HttpStatusCode.Unauthorized »), elle tente d'abord de se connecter au service, puis envoie à nouveau la requête avec le jeu d'en-têtes d'authentification approprié.

Comme la demande est susceptible d’être envoyée plusieurs fois, elle et clonée…
 
Nous venons donc d’intégrer un mécanisme d’authentification vis-à-vis d’« Azure Active Directory » sur un service « API App » avec mise en cache des jetons d’authentification depuis une application universelle.
Le prochain et dernier article devrait être plutôt court, je vous indiquerai les éléments permettant de récupérer le code et de déployer rapidement cette application….

L’objectif est de développer une application pouvant s’exécuter sur Windows 10 ou Windows 10 Mobile, en utilisant l’« API App » décrite dans mon précédent article pour accéder aux services Backend.

Description fonctionnelle de l’application

Sur le plan fonctionnel, l’application doit permettre de naviguer entre une page de recherche et une page pour le stockage. Nous nous limiterons à l’implémentation de la partie recherche, la page liée au stockage pouvant être développée de façon similaire.
La page « Recherche » offre la possibilité de saisir une chaîne de caractères pour lancer une requête sur l’ensemble des attributs marqués comme étant « searchable » de l’index d’« Azure Search ». Elle doit permettre d’afficher le résultat de cette requête de telle sorte que l’on puisse downloader par un simple clic le document souhaité (avec là encore, incrément du compteur de téléchargement).

La plateforme UWP
Une plateforme universelle

Avec Windows 10 et la plateforme UWP (Universal Windows Platform), il est maintenant possible de créer des applications qui s’exécutent, avec le même package, dans un store unique, sur de multiples types de device (Windows 10 mobile, Windows 10, Xbox, Hololens, device IoT,…).

Précédemment, avec les versions Windows 8 et Windows Phone 8, même s’il était possible de partager du code, ce code contenait des directives de compilation permettant de prendre en compte les spécificités de telle ou telle plateforme. En outre, le package était spécifique à chaque plateforme.
L’exécution d’un même code sur PC et sur appareils mobiles est maintenant rendue possible grâce à la convergence des APIs mises à disposition dans une librairie baptisée « Universal Windows ».  

Cette librairie « Universal Windows » apparaît dans la liste des références du projet Visual Studio.

Les spécificités de l’application universelle « Doc.Search.App »

L’application « Doc.Search.App » doit fonctionner aussi bien sur un device mobile que sur un PC Windows. Ce choix se traduit par deux pré-requis.

En premier lieu, l’application doit être en mesure de détecter le type de device et de s’adapter en conséquence. Par exemple, l’application offrira la possibilité de faire des retours arrière sur la navigation avec une option de menu « Back » qui n’apparait que sur l’application Windows 10. Cette option offrira le même type de comportement que la touche « Back » sur Windows 10 mobile.

Le second pré-requis est de permettre à l’application d’adapter automatiquement son affichage aux différentes tailles d'écran. La copie d’écran suivante illustre les deux affichages possibles de la même application en fonction du device qui l’exécute. 

Nous allons maintenant étudier les différentes techniques permettant de satisfaire à ces deux pré-requis.

Adaptation au device

L’environnement de développement d’application universelle permet, si on le souhaite, d’écrire du code qui qui ne s’exécute que sous certaines conditions (type de device, version d’API d’extension de la plateforme). Pour ce faire, il suffit d’ouvrir la boîte de dialogue « Gestionnaire de références » et de choisir l'extension du SDK pour la plateforme « Universal Windows » en fonction des familles de devices que le code doit cibler. Bien entendu, l’utilisation de ces extensions de plateforme n'invalide pas les binaires sur les devices qui n’en sont pas la cible.Ainsi, pour pouvoir utiliser le bouton « Back » sur un device de type Windows 10 Mobile, dans l’application « Doc.Search.App », il faut gérer un évènement de type « BackPressed », ce qui d’après le MSDN, requiert le contrat « Windows.Phone.PhoneContract ».

Pour utiliser cette API, le projet « Doc.Search.App » doit donc référencer les extensions Windows Mobile pour la plateforme UWP.

Adaptation de l’interface utilisateur

Comme nous l’avons vu, l’application « Doc.Search.App » doit également proposer une interface adaptée à la taille et à la disposition du device sur lequel elle s’exécute. Pour faciliter ce type d’implémentation, la plateforme UWP offre de multiples évolutions.
De nouveaux contrôles sont venus enrichir la plateforme, comme le « RelativePanel » (un container qui permet de définir une zone dans laquelle on peut positionner et aligner les éléments d'interface les uns par rapport aux autres) ou le « SplitView » un contrôle visuel de navigation. Le « ViewStateManager » a également été amélioré pour permettre de changer facilement la mise en page en fonction des dimensions de l’écran et éviter d’avoir à gérer séparément de multiples projets et définitions d’interface utilisateur.

« ViewStateManager » - « AdaptiveTrigger »

En utilisant la classe « AdaptiveTrigger », lorsque la fenêtre est suffisamment réduite, on peut  basculer sur une interface correspondant à celle d’un téléphone mobile et à l’inverse changer d’interface pour s’adapter à un écran plus grand.
Pour ce faire, la classe « AdaptiveTrigger » permet de créer des règles qui déclenchent automatiquement un changement d’état (le « VisualState ») lorsque la hauteur ou la largeur d’une fenêtre dépasse une valeur spécifique.
Lorsque l’on utilise « AdaptiveTrigger » dans le balisage XAML, il n’est plus maintenant plus nécessaire de gérer par code l'évènement « Window.SizeChanged » afin de pouvoir appeler la méthode « VisualStateManager.GoToState ». De plus les effets de ces changements adaptatifs sont directement visibles dans le designer Visual Studio 2015.
Par exemple, pour changer l’affichage d’un mode grille « Paysage » à un mode liste « Portrait », il suffit de déclarer les deux états correspondant à ces « VisualState ».  

Ce mécanisme peut être étendu pour permettre d’adapter l’interface de l’application en fonction d’autres critères, comme par exemple la présence d’un bouton « Back » sur le device. C’est ce que propose Morten Nielsen avec ses « WindowsStateTriggers » dont le code source est disponible sur GitHub. 
Pour utiliser cette extension, il suffit alors de la référencer dans l’entête de la page. 

Il devient alors possible de l’employer dans la déclaration des éléments participant au déclenchement du changement d’état...

Le contrôle « SplitView »

« SplitView » est un contrôle visuel qui permet d’offrir une gestion de la navigation des applications Windows similaire à celle des applications web et autres plates-formes mobiles. Ce contrôle permet d’afficher un menu que l’on peut modifier pour créer un menu « hamburger » comme le propose Jerry Nilson dans son blog.
Le contrôle « SplitView » expose deux propriétés. Les boutons de menu et de navigation de l’application sont déclarés dans la propriété « Pane ». La propriété « Content » est, comme son nom l’indique, un « ContentPresenter » pour le « Frame » de l’application. Le contenu de la page est donc directement injecté dans le contrôle lui-même, via la propriété « ContentControl » que l’on définit via un mécanisme de binding.
Ce binding est configuré au niveau de la déclaration XAML du contrôle. 
Il est implémenté dans le code la page « Shell.xaml ». 
Il est préférable d’utiliser le contrôle « Splitview » dans une Page dédiée (c’est le rôle de la page « Shell.xaml ») plutôt qu’à la racine (« app.xaml ») : on bénéficie ainsi d’une  meilleure expérience de conception dans Visual Studio. Pour la page « SearchPage.xaml », l’arbre XAML sera donc :
Window.Current.Content > Shell > SplitView > Frame > SearchPage

Le contrôle « SplitView » offre plusieurs niveaux d'affichage correspondant à la propriété « DisplayMode ». Dans l’application, en fonction de la taille de l’écran deux modes ont été utilisés : le mode « Compact Overlay « (lorsque le volet de menu est ouvert, il se superpose sur la page contenue dans le contrôle) et le mode « Compact Inline » (lorsque le volet de menu est ouvert, la page contenu se décale et revient à sa position d’origine à la fermeture du volet). Dans les deux cas, le volet reste visible en mode « Compact » lorsqu’il est fermé.
Les changements d’état d’affichage du « SplitView » sont également gérés via le « VisualStateManager ».

Déploiement dans le Store

Avant de distribuer une application depuis le Store, il faut s’assurer de son bon fonctionnement en mode « .NET Native ». « .NET Native » est une technologie de pré-compilation incluse dans Visual Studio 2015 pour les applications universelles. Le principe est de compiler le code « IL » pour obtenir une librairie native avant la mise à disposition de l’application sur le device cible. Cette innovation apporte plusieurs avantages : optimisation des performances, réduction de l’occupation mémoire, indépendance vis-à-vis du runtime .NET… La contrepartie est une durée de compilation qui est plus élevée. Le fonctionnement par défaut (que l’on peut modifier) est donc de réserver l’option de compilation mode « .NET Native » aux configurations de type « Release ». 

Une fois validé le bon fonctionnement de l’application générée en mode « .NET Native », on peut alors créer un package « .appxupload », en précisant les différentes configurations cibles (x86, x64, ARM).
 
Ce package est généré directement depuis Visual Studio, depuis l’option « Store » accessible par un clic droit sur le projet cible « Universal Windows ». Il contient les fichiers binaires MSIL, mais aussi une référence explicite à la version de la configuration « .NET Native » que l’application utilise et qui est déclarée dans le fichier « AppxManifest.xml ».
Il ne reste plus alors qu’à publier le package sur le portail développeur (https://dev.windows.com). Il sera alors compilé sur le store avec la même version de l’environnement de compilation « .NET Native » que la version référencée dans Visual Studio.

Implémentation de l’Application Universelle Windows

Pour implémenter l’application « Doc.Search.App », nous pouvons capitaliser sur les acquis des plateformes précédentes (WPF, Silverlight…). L’application est implémentée selon le respect de modèles éprouvés comme le « pattern M-V-VM » ou le « pattern Command ». Elle est développée en C# et la description de l'interface graphique (fenêtres, bouton, champs de texte, contrôle d’affichage de type liste ou grille) est réalisée en XAML (« Extensible Application Markup Language »), comme nous avons déjà pu voir dans la déclaration du contrôle « SplitView » ou du « VisualStateManager ».

« Le pattern M-V-VM »

Le « pattern M-V-VM » (« Model-View-ViewModel ») est dérivé du « pattern MVC ». Dans la logique de décomposition proposée par le « pattern M-V-VM », le « Model » (ou « DataModel ») est responsable des données, la « View » représente la partie visuelle de l'application tandis que le « ViewModel » expose les données et les comportements (notamment les commandes) pour la « View ».
 

Ainsi la « View » peut utiliser le « ViewModel » dans son « DataContext » pour le binding afin de transformer les données en éléments visuels avec les « DataTemplates ». Le « ViewModel » quant à lui ne fait aucune supposition sur la façon dont va s'opérer le binding. C’est sur ce principe que sont alimentés les contrôles « ListView » et « GridView » que nous verrons par la suite.
Pour afficher la « View » avec les informations souhaitées, il suffit d’alimenter le « ViewModel ». Ce dernier est spécifique pour chaque vue. D’un point de vue technique, il s’agit d’une classe qui implémente le pattern « Observable ».Plus concrètement, il s’agit d’implémenter l’interface « INotifyPropertyChanged » et il est préférable de définir une classe abstraite « BaseViewModel » dont hériteront l’ensemble des « ViewModels » pour y gérer le « PropertyChangedEventHandler ».

De même, les propriétés de la classe « ViewModel » implémentent également « INotifyPropertyChanged » (ou « DependencyObject ») ou « ObservableCollection » suivant qu’il s’agit d’objets ou de collections, afin de prévenir la vue lors de tout changement des données, comme par exemple la collection de « DocumentProperties » correspondant aux éléments issus de la requête sur le service de recherche.
Lorsque ce « pattern » est mis en œuvre, la « View » ne contient quasiment pas de « code-behind ». Le code réside dans le « ViewModel » et est facile à tester de façon unitaire, ce qui présente un intérêt supplémentaire pour cette approche.

« Le pattern Command »

Le « pattern Command » permet de séparer complètement le code initiateur de l'action, du code de l'action elle-même. Très utilisé dans le développement d'interface utilisateur, il permet d'associer plusieurs éléments visuels à la même commande, et de les rendre activables ou non, selon des règles spécifiques (par exemple, le bouton « Rechercher » ne sera actif que si la zone de saisie inclue un critère permettant de filtrer la recherche...).

Plus concrètement, l’implémentation de ce « pattern » se traduit par la déclaration d’une « Command » qui, généralement est réalisée dans le « ViewModel », comme c’est le cas pour la commande « SearchCommand ». 

Il ne reste plus alors qu’à faire le binding de cette commande dans la « View » sur le contrôle avec lequel on souhaite l’associer.
 
Les commandes sont une implémentation de l'interface « ICommand ». Cette interface expose trois membres :

• La méthode « Execute(object) » est appelée lorsque la commande est actionnée. Elle comporte un paramètre, qui peut être utilisé pour passer des informations supplémentaires de l'appelant à la commande..
• La méthode « CanExecute(object) » retourne une valeur booléenne. Si la valeur de retour est « true », cela signifie que la commande peut être exécutée. Le paramètre est le même que pour la méthode « Execute ». Le contrôle sera automatiquement désactivé si la méthode « CanExecute » retourne la valeur false.
• Le gestionnaire d'événements « CanExecuteChanged » doit être déclenché par l'implémentation de la commande lorsque la méthode « CanExecute » est réévaluée. En XAML, lorsqu'une instance de « ICommand » est liée à une propriété du contrôle commande via une liaison de données, déclencher l'événement « CanExecuteChanged » appelle automatiquement la méthode « CanExecute », et le contrôle va être activé ou désactivé en conséquence.

L’application « Doc.Search.App » utilise une implémentation « classique » de l’interface « ICommand » avec la classe « RelayCommand ». Cette classe permet d’injecter et de relayer la logique des commandes dans le constructeur de « RelayCommand » via un « delegate », ce qui permet de vérifier si elle peut être exécutée et de la déclencher.

La déclaration d’une « Command » peut se faire à un autre niveau que celui du « ViewModel ». Par exemple, la commande « UploadCommand », qui permet d’incrémenter le compteur de téléchargement d’un document, doit pouvoir être déclenchée pour chaque « Document » de la collection « DocumentProperties ». Elle doit donc être associée à un contrôle, ici un « HyperlinkButton », lui-même déclaré dans un « DataTemplate ». 

Dans le « ViewModel », lors de l’initialisation de la collection « DocumentProperties », il suffit donc de passer en paramètre une lambda expression permettant de décrire l’action souhaitée lors du déclenchement de la commande.
Dans notre contexte, il s’agit d’appeler l’API de mise à jour du compteur et de relancer la recherche pour que l’affichage soit cohérent avec les nouvelles valeurs (celles du compteur de téléchargement incrémenté mais également les mises à jour pouvant avoir eu lieu en parallèle, l’application n’étant pas mono-utilisateur).

La classe « DocumentProperties » étant comme nous allons le voir un peu plus loin, une classe automatiquement générée à partir de la description Swagger de l’« API App », le passage de ce paramètre « Action » sur la classe « DocumentProperties » suppose donc le développement d’une extension sur cette classe incluant la définition de la commande « UploadCommand ».

L’organisation du code de l’application « Doc.Search.App »

L’organisation est des plus classiques, un dossier pour les « Views », un pour les « ViewModels », et un pour les extensions.

Les contrôles d’affichage des données

En fonction des dimensions de l’écran, la page « SearchPage » utilise deux contrôles d’affichage, en mode liste ou en mode grille.

Le contrôle « ListView »

Le contrôle « ListView » est nativement conçu pour afficher une énumération d’objets. Par conséquent, il est tout à fait adapté pour restituer la liste des « DocumentProperties ».

Il suffit donc de le déclarer en XAML, d’établir le binding avec la propriété « Documents », et de définir le modèle d’affichage de chacun de ses éléments (l’ « ItemTemplate »). 
L’ « ItemTemplate » est déclaré dans les ressources de la même page. 

Il utilise deux objets de type « Converter », l’un pour afficher la tailler du document en unités octales, l’autre pour afficher le nombre de téléchargement (avec ou sans « s », suivant la valeur du compteur…)
 
Le contrôle « ListeView » utilise également un « ItemContainerStyleSelector » pour permettre d’alterner le style des lignes affichées dans la liste (pour l’instant sur UWP, il n’y a pas de « Triggers » sur le « DataTemplate » pour alterner les styles comme on pouvait le faire en WPF…). 

Pour utiliser cette classe ou les classes de type « Converter », il suffit de les déclarer dans les ressources de la page.

Le contrôle « GridView »

Lorsque l’écran le permet, il est plus approprié de pouvoir étendre l’affichage sur une grille, d’où l’intérêt d’utiliser le contrôle « GridView ». 

De même que pour le contrôle « ListView », il suffit de déclarer une instance de la « GridView » en XAML, d’établir le binding avec la propriété « Documents », de définir le modèle d’affichage de chacun de ses éléments (l’« ItemTemplate ») et définir un « ItemContainerStyleSelector » pour alterner le style des lignes (on utilisera d’ailleurs la même classe que pour la « ListView »).

L’ « ItemTemplate » est déclaré dans les ressources de la même page. A la différence de l’ « ItemTemplate » défini pour la « ListView », il utilise un « StackPanel » horizontal pour positionner les différents « TextBlock » ainsi que le « HyperlinkButton ».

Interaction avec l’« API App »

L’application universelle « Doc.Search.Api » doit pouvoir appeler l’ « API App » exposée sur Azure avec une URL similaire à https://microsoft-apiapp###############.azurewebsites.net. Il s’agit d’une API REST, on pourrait donc naturellement utiliser la classe « HttpClient » incluse dans l’espace de nommage « System.Net.Http ». Mais l’utilisation combinée d’« API App » et Visual Studio propose un modèle de développement nettement plus productif.

En effet, après installation du SDK Azure, Visual Studio offre une fonction d’ajout « Azure API App Client », qui permet de générer un proxy d’invocation de cette API App, avec les modèles associés (dont la classe « DocumentProperties » que nous avons dû étendre pour les raisons précédemment expliquées). Cette fonction est accessible à travers un assistant permettant de choisir l’ « API app » en ligne ou à partir d’un fichier Swagger local.

Cet assistant télécharge les métadonnées de l’API App et génère une interface typée pour pouvoir gérer les appels à l’API. Une fois la génération de code achevée, un nouveau dossier du nom de l’API App est ajouté à la solution. Il contient le code correspondant à l’implémentation des classes « client » et des modèles de données.

 
L’appel à l’« API App » depuis le code de l’application Universelle est alors grandement simplifié grâce à la mise à disposition de l’objet « DocSearchAPI », qui permet d’accéder à un objet de type « SearchOperations » offrant des méthodes comme « SearchbyNameAsync » permettant de lancer une recherche sur un champ texte ou « Update » assurant la mise à jour du compteur de téléchargement. 
Dans le cas de la méthode « Update », il a été nécessaire de reprendre le code généré dans la classe « SearchOperationsExtensions » pour permettre une invocation asynchrone.
Le code d’origine était le suivant. 
Le nouveau code est celui-ci :

Nous disposons maintenant d’une application universelle capable d’échanger avec une « API App » déployée dans Azure, cette API App permettant d’exposer l’accès au service de recherche « Azure Search ». Dans le prochain article, nous étudierons comment intégrer des mécanismes permettant d’assurer la gestion d’identité de l’ensemble de la solution.

Introduction

La donnée élément clé du cycle de décision

Piloter plus efficacement un système d’information grâce à une meilleure utilisation des données suppose :

• Un changement de culture qui permette à chacun dans l'organisation de prendre des décisions fondées sur ces données
• La mise en place de processus et d’outils liés au cycle de vie des données et qui accélèrent leur flux dans toute l'organisation

L’objectif est donc de pouvoir répondre à différents types de question avec les solutions d’affichage ou de manipulation des données les plus adaptées :

• Que s’est-il passé ? (Rapports statiques)
• Pourquoi est-ce arrivé ? (Rapports interactifs)
• Qu’est-il en train de se passer ? (Tableaux de bord temps réel)
• Que va-t-il se passer ? (Prédictions)

Le cycle de vie des données

Le cycle de vie des données peut être décomposé selon trois axes :

• Tout d'abord, comment collecter et ensuite gérer toutes les données entrant dans l'entreprise ? Au volume de données existant dans l’entreprise s’ajoutent aujourd’hui de nouveaux types de données telles que les données non structurées et les flux de données en continu (« streaming »). Il devient donc nécessaire de faciliter la capture et la gestion de ces données pour les préparer aux étapes suivantes de ce cycle.
• Une fois ces données recueillies et gérées, il faut être en mesure de les transformer et les analyser et ce, quel que soit leur type, afin de s’assurer qu’elles soient prêtes à être exploitées.
• Enfin, il faut pouvoir manipuler ces données en utilisant des outils permettant d’obtenir des réponses visuelles pour chaque question que l’on souhaiterait se poser afin de pouvoir prendre des décisions.
  

La plateforme de données Microsoft

Microsoft fournit une plateforme de données cohérente offrant la capacité à gérer le cycle de vie des données de bout à bout afin d’en obtenir la meilleure exploitation. Cette proposition de valeur est rehaussée par la flexibilité du choix des éléments constitutifs de la solution à déployer (Cloud ou OnPremise).
Plus concrètement, si l’on considère l’exemple suivant de flux de donnée au sein d’un système d’information, on se rend rapidement compte de la nécessité de proposer un découpage plus fin que la grille d’analyse sur trois axes précédemment évoquée.

Sur chacun des axes se distinguent de multiples sous-rubriques en fonction, par exemple, du type de données ou de la nature des transformations opérées. S’y ajoute également la notion de services applicatifs orientés données.
Voici donc la grille d’analyse que je propose afin de passer en revue l’ensemble des composantes de la plateforme de données de Microsoft, en la restreignant volontairement à ses composantes Cloud et aux solutions de Business Intelligence à destination des utilisateurs.

L’objectif de la suite de cet article est donc d’établir une correspondance entre chacun des blocs de ce schéma et une ou plusieurs briques de l’offre Microsoft.

Collecter et gérer l’information

Dans un premier temps, il s'agit donc de faire l’inventaire des solutions permettant de capturer et de gérer les données, qu’elles soient structurées ou non, statiques ou propagées en continu, à demeure ou dans le Cloud.

Base de données relationnelles

Azure SQL Database

Azure SQL Database est un service Cloud de mise à disposition de base de données SQL hautement disponible. Toutes les opérations d’administration et d’optimisation correspondantes sont entièrement prises en charge par Microsoft. Le « provisioning » d’un nouveau serveur ou d’une nouvelle base d’une taille maximale de 500 GB est réalisé en l’espace de quelques secondes. Le service est disponible sur l’ensemble des DCs Azure avec un SLA  de 99.99%. Il est facturé en fonction de la consommation (à l’heure) et propose 6 niveaux de performances pour 3 niveaux de service : Basic, Standard, et Premium. Il offre différentes options (« Self-service restore », « Active geo-replication », « Auto failover »). Azure SQL Database est compatible à 100% avec les outils (Management Studio), les frameworks de développement et les bases de données SQL Server 2014.

 
Azure SQL Database offre des fonctions avancées de backup et de réplication inter-datacenters. Les services déjà disponibles comme les Elastic Database Tools, mais surtout les nouveautés comme les Elastic Database Pools, complétés par les Elastic Database Query et les Elastic Database Jobs étendent les possibilités en permettant d’offrir un environnement Database-as-a-Service capable de gérer des charges non prédictibles pour des applications SaaS d’échelle très significative, sans remise en cause des outils de management ou de développement existants.

SQL Server en IaaS

Dans l’environnement IaaS (Infrastructure as a Service) proposé avec Azure, il est également possible d’installer et configurer un serveur SQL et ses services associés, de même que l’on peut déployer des bases de données relationnelles propriétaires Oracle, IBM DB2 ou issues du monde de l’Open Source comme MySQL.
En complément des bonnes pratiques habituelles (indexes, plans de maintenances, optimisation du schéma, des requêtes, de tempdb), il faut veiller à prendre en compte certaines spécificités liées au Cloud et notamment optimiser les entrées/sorties sur le stockage, qui, rappelons-le, est un stockage sur un système de fichiers accessible par le réseau. Il est notamment recommandé d’utiliser :

• un maximum de disques via Disk Stripping (Windows Server Storage Spaces, jusqu’à 64 disques, séparer fichiers de données et fichiers de logs sur des pools distincts)
• des achines G ou D (tempdb sur le disque temporaire SSD, Buffer Pool Extension si lecture intensive, sur machines G : In-Memory)
• Azure Premium Storage et des machines DS (5000 IOPS par disque, max 50 000 IOPS par machine)

Des images pré-optimisées sont d’ailleurs fournies nativement dans la Galerie Azure (« SQL Server 2014 Enterprise Optimized for DataWarehousing on Windows Server 2012 R2 » et « SQL Server 2014 Enterprise Optimized for Transactional Workloads on Windows Server 2012 R2 »).

No SQL

Document DB

Document DB est un service de mise à disposition de base de données NoSQL entièrement géré par Microsoft Azure, à destination des applications Cloud, facilitant le développement itératif et l’évolution du modèle de données. Document DB offre un support natif pour JavaScript, les requêtes SQL, ainsi qu’un traitement transactionnel intégré de JavaScript associé à un modèle fondé sur des documents JSON sans schéma (« Self-describing », « self-contained ») et une indexation automatique.

Table Storage

La plateforme Microsoft Azure offre des services de stockage reposant sur un mécanisme scalable et hautement  disponible (avec une géo-réplication en option) permettant de gérer des volumétries de données très conséquentes, de les exposer via API REST pour un usage intra-Datacenter ou extérieur et de les sécuriser. Au sein de ces services, Azure Table Storage offre des fonctions NoSQL de type « clé/valeur » pour les applications devant stocker de grandes quantités de données non structurées. Les tables constituent un service géré certifié ISO 27001, capable d'évoluer automatiquement pour prendre en charge un débit et un volume conséquents jusqu'à 500 téraoctets, accessible de n'importe où, via des API REST ou des API managées.

Données non structurées

Azure Blob Storage

Autre composante des services de stockage Azure, les Blobs constituent la manière la plus simple de stocker d'importants volumes de données binaires ou de textes non structurés tels que des fichiers vidéo, audio et des images. Il s’agit également d’un service géré certifié ISO 27001, ouvert à des API REST ou managées.

Azure Premium Storage

Avec l'introduction de Premium Storage, Microsoft Azure offre maintenant deux types de stockage durable : Premium et Standard. Le stockage Premium se distingue en permettant de conserver les données sur des disques SSD (« Solid State Drive »). Il est particulièrement adapté aux scénarios OLTP, Big Data et Data Warehousing  (pour des plateformes telles que SQL Server, MongoDB, Cassandra,…) exigeants en termes de performances sur les entrées-sortie et de faible latence (moins de 1ms de latence en lecture). Premium Storage est actuellement disponible pour les Page Blobs et les disques de données utilisés par les Machines virtuelles (Jusqu’à 32 To par machine virtuelle et 50 000 IO/s par machine virtuelle).

WASB

WASB est une implémentation de HDFS (Hadoop Distributed File Store) sur Azure Blob Storage pour le service HDInsight (que nous verrons un peu plus loin dans la suite de cet article). Il constitue une alternative au système de fichiers distribués attachés localement sur les nœuds de calcul d’un cluster Hadoop, avec un accès proposé en utilisant l'URI complet : HDFS: / / <namenodehost>/<path>. Avec WASB, les mêmes données peuvent être stockées dans les Blob Azure. Pour leur usage HDInsight, la syntaxe est : wasb [s]:// <containername>@<accountname>.blob.core.windows.net/ <path>.

Azure HDInsight HBase

Azure HDInsight HBase est le service qui permet de configurer dans Azure des clusters HBase pour stocker de gros volumes de données directement dans le stockage Blob Azure avec une faible latence et les analyser avec des jobs Hadoop. HBase est une base de données Apache Open Source NoSQL « orientée colonne » construite sur Hadoop. Elle fournit un accès aléatoire et une forte cohérence pour grandes quantités de données non structurées et semi-structurées. Les données sont stockées dans les lignes d’une table et regroupées au sein d’une ligne par « famille de colonne ». La scalabilité de HBase (fondé sur le modèle « BigTable » de Google) lui permet de gérer plusieurs pétaoctets de données sur des milliers de nœuds. L’implémentation HDInsight HBase se fonde sur l’architecture de scale-out de HBase pour offrir un sharding automatique des tables, une forte cohérence pour les lectures et écritures et un basculement automatique. La performance est renforcée par la mise en cache en mémoire sur la lecture et un débit élevé en écriture.

Data Lake

Azure Data Lake est un référentiel construit comme un magasin de fichiers distribués à très grande échelle, sans limite de taille, pour le traitement analytique de  données volumineuses. Cela permet de stocker au même endroit de multiples types de données (relationnelles, non relationnelles,…) avant toute définition formelle de schéma ou contrainte de transformation et de les analyser dans leur format natif. Azure Data Lake est compatible avec HDFS (Hadoop Distributed File Store - WebHDFS 2.7), ce qui favorise son intégration avec des solutions Hadoop comme Azure HDInsight, Hortonworks, and Cloudera et le rend accessible par l’ensemble des projets Open Source compatibles HDFS (Spark, Storm, Flume, Sqoop, Kafka, R,...). Il fournit un stockage illimité, la possibilité de stocker des fichiers uniques de taille de l’ordre du pétaoctet avec des accès en lecture/écriture bénéficiant d’une haute fréquence et d’une faible latence, qui sont adaptées aux flux volumineux du Big Data.
 

Collecte de données en streaming

L’ingestion de données peut être gérée de multiples façons dans Azure.

Azure Service Bus

Azure Service Bus est un service middleware Azure fondé sur la mise en œuvre d’un pattern de « publication/souscription ». Il permet de séparer le trafic de messagerie entre de multiples rubriques (les Service Bus Topics) afin de maximiser le débit.

Azure Event Hub

Event Hub est un service de collecte de données en streaming qui se distingue par sa capacité à proposer un service de réception évolutif, capable de prendre en charge des profils de charge variables, ainsi que des pics causés par une connectivité intermittente. Event Hub offre en effet un mécanisme de type publication-souscription pouvant recevoir des millions d’événements par seconde, tout en conservant l’ordre des évènements. La prise en charge de protocoles standards comme AMQP ou HTTPS permet à de nombreuses solutions de pouvoir interagir avec Event Hub. Des bibliothèques clientes natives existent également pour les plateformes les plus courantes.

Transformer et analyser les données

Le monde connecté d’aujourd’hui est défini par le Big Data. En effet, une fois les données collectées, il est nécessaire de les stocker et de les transformer, sachant que les devices et applications connectés peuvent produire des volumes de données très importants.

Intégration et orchestration

Azure Data Factory

Azure Data Factory est un service Cloud entièrement géré qui le facilite l’intégration des étapes de stockage, de traitement, et de mouvement de données au sein de pipelines de production, évolutifs et fiables. Azure Data Factory facilite la coordination et la gestion des sources de données relationnelles et non-relationnelles à demeure ou dans le Cloud (SQL Server, Azure Blob, Tables, HDInsight, SQL Databases,…). L’accès aux données locales est pris en charge via une passerelle de gestion des données qui permet une configuration et une sécurisation des connexions aux serveurs SQL locaux. Les mécanismes natifs de supervision d’Azure Data Factory permettent de considérablement réduire les coûts opérationnels.

Power Query

Power Query est un addin Office qui permet de facilement découvrir des données provenant de sources de données publiques ou d'entreprises. Il inclut des fonctions de recherche, ainsi que des capacités de transformation et fusion de données provenant de plusieurs sources. 

Data Warehouse et analyse historique des données

Azure Data Warehouse (Preview)

Azure SQL Data Warehouse est une solution Cloud de DataWarehouse-as-a-service bâtie sur l'architecture de traitement massivement parallèle de SQL Server. Ce service peut dynamiquement se redimensionner en fonction des requêtes (avec une facturation à l’usage). Il permet aux utilisateurs d'utiliser leurs compétences T-SQL existantes pour exécuter des requêtes sur un ensemble de données structurées et non structurées, sur des volumes de l’ordre du pétaoctet. Il supporte les requêtes Polybase qui permettent de requêter simultanément des données Hadoop et des données relationnelles et s'intègre avec les outils existants et des solutions comme Azure HDInsight, Azure Machine Learning, Azure Data Factory ou PowerBI.

Power Pivot

Power Pivot est un addin Excel qui permet de modéliser et transformer très rapidement de gros volumes de données (des millions de lignes) grâce au moteur analytique en mémoire x-velocity (algorithmes Vertipaq). Il permet d’importer ces données de multiples sources (bases de données relationnelles, multidimensionnelles, services Cloud, fichiers Excel, fichiers texte et données sur le Web) dans un seul classeur Excel. Il permet de créer des modèles mettant en œuvre des relations entre des données hétérogènes, de créer des colonnes calculées à l'aide de formules et des mesures personnalisées associées à des indicateurs de performance clé, construire des tableaux et des graphiques croisés dynamiques, afin de pouvoir analyser les données.

Big Data

Azure HDInsight  Hadoop

Azure HDInsight Hadoop est une distribution Apache Hadoop proposée sur le Cloud Microsoft Azure. Hadoop est un framework Open Source Apache qui cible les applications distribuées qui consomment des gros volumes de données. Il est composé de multiples projets. HDFS (Hadoop Distributed File System) est le système de fichiers de Hadoop. Il permet un stockage distribué de fichiers très volumineux (du gigaoctet à plusieurs téraoctets) sur plusieurs ordinateurs. MapReduce est le modèle de programmation qui effectue les opérations de filtrage, de tri et d'autres commandes liées à l'obtention et à la transformation de données en appliquant des algorithmes parallèles et distribués. A ces briques Hadoop s'ajoutent des projets Open Source comme HBase, R, cochon, ruche, Flume, cornac, Avro, Zookeeper, .... Le service HDInsight est architecturé pour gérer et analyser une quantité quelconque de données non structurées ou semi-structurées en proposant des extensions de programmation pour de nombreux langages tels que C#, Java et .NET.

Azure HDInsight Spark (Preview)

Azure HDInsight Spark est le service Azure permettant de provisionner, en une dizaine de minutes, un cluster de serveurs pré-configurés avec le framework Open Source Apache Spark afin d’offrir un traitement parallèle de données pour les applications analytiques du Big Data. Les capacités de calcul du moteur Spark sont optimisées pour travailler en mémoire, privilégier la vitesse et la facilité d'utilisation. HDInsight Spark est compatible avec stockage Blob Azure (WASB). Il permet également l’analyse de données en temps réel, grâce aux connecteurs natifs de Spark, qui permettent d'ingérer des données provenant de nombreuses sources (Kafka, Flume, Twitter, ZeroMQ, sockets TCP) et grâce au support d’Azure Event Hub. 
 

Analyse temps réel

Azure Stream Analytics

Le service Azure Stream Analytics est issu des travaux de Microsoft Research. Ce moteur de traitement d’événements permet de traiter des informations issues de multiples sources, notamment les données en provenance d’Event Hub, afin d’analyser en « temps réel » des millions d’événements par seconde.  Stream Analytics permet de comparer plusieurs flux en temps réel, et d’intégrer dans l’analyse des valeurs et des modèles historiques en bénéficiant d’un débit élevé, d’une faible latence et d’une résilience garantie. Stream Analytics permet ainsi la détection des anomalies, la transformation des données entrantes, l’alimentation de tableaux de bord en temps réel et offre la possibilité de déclencher une alerte lorsqu’une erreur ou condition spécifique apparaît dans le flux. Stream Analytics propose un langage SQL pour décrire les transformations souhaitées en fournissant une gamme d’opérations sur une fenêtre d’observation temporelle permettant d’appliquer de simples filtres ou des agrégats plus complexes.
 

Event Processor Host

Il est possible de développer un service d’analyse en temps réel des données issues de l’Event Hub en implémentant l’interface IEventProcessor et en enregistrant l’objet correspondant dans un EventProcessorHost, qui est thread safe. Au final, une seule interface à connaître et la beauté de cette interface, c'est qu‘elle masque complètement la complexité de ce type de traitement. En effet, du point de vue du développeur, il suffit de parcourir et filtrer une boucle de messages.

Azure HDInsight Storm (Preview)

Azure HDInsight Storm est le service qui permet de configurer dans Azure un cluster Apache Storm managé. Apache Storm est un système de calcul Open Source distribué et résilient, pour le traitement de données, en temps réel, avec Hadoop. Ces données peuvent être issues de files d’attente Service Bus ou Hub Event. Les clusters HDInsight Storm peuvent également être configurés sur un réseau virtuel Azure (VNET) extensible avec un VPN, afin d’offrir une communication sécurisée vis-à-vis de ressources localisées au sein d’un DataCenter privé.

Analyse prédictive

Azure Machine Learning est un service intégralement géré par Microsoft Azure. Il permet de prévoir les futurs comportements ou tendances, en fondant ces analyses prédictives sur des données précédemment collectées. Azure Machine Learning offre une expérimentation rapide pour créer un meilleur modèle avec l’aide de bibliothèques de modèles réutilisables. Il permet une composition visuelle de bout en bout sur le flux de données et supporte l’environnement de programmation Open Source « R » pour les statistiques et l’exploration de données. Enfin, il est possible de déployer le modèle comme un Service Web hébergé dans Azure.

Manipuler l’information et prendre des décisions

Les données ne commencent à avoir de la valeur qu’à partir du moment où l’on est en mesure de les manipuler pour en retirer de nouvelles connaissances. Les solutions à mettre en place doivent proposer une vue de bout à bout de tous les types de données (structurées, non structurées, précédemment archivées ou mis au rebut).
Même si ces données ont été intégrées ou transformées, elles ne sont pas nécessairement localisées au même endroit : il faut donc pouvoir offrir un accès sécurisé à de multiples sources (données internes ou résidant dans les solutions SaaS et autres emplacements externes). Chacun doit avoir la possibilité de pouvoir prendre des décisions sur la base de ces données. Il faut donc rendre ces données disponibles en fonction de l’utilisateur, de ses niveaux d’accès, de ses besoins, et du moment. Enfin, ces données doivent être accessibles en situation de mobilité quel que soit le lieu, l’instant, ou le device utilisé…

Power View

Power View est un addin Excel qui permet de facilement créer des rapports visuels interactifs et qui offre une vue analytique par le biais de cartes interactives ou graphiques pour faciliter l’exploration des données et la collaboration autour de la visualisation de ces données.

Power Map

Power Map est un addin Excel qui s’inspire des travaux de Microsoft Research sur le projet « WorldWide Telescope ». Il ajoute une nouvelle dimension en offrant la possibilité de tracer visuellement des données géographiques et temporelles sur Bing Maps, d'analyser ces données en 3D et de créer des visites interactives que l’on peut partager.

Power BI

Power BI est service Cloud d'exploration de données visuelles qui permet d'analyser les données et créer des rapports. Il intègre des fonctions d’acquisition et de préparation des données similaires à celles de Power Query. Il permet la consolidation de plusieurs sources de données, à demeure ou dans le Cloud, pour définir leur structure, leur transformation, leur analyse, leur exploration, puis leur partage sécurisé au sein de l’organisation. Les rapports interactifs sont construits en ligne ou avec Power BI Desktop par simple drag-and-drop d’une large gamme de contrôles de visualisation de données. Ils sont accessibles en ligne (HTML5), via Power BI Desktop ou depuis une application mobile.

Datazen

Datazen est une solution récemment acquise par Microsoft, qui offre des fonctions très avancées de visualisation interactive de données et d’indicateurs de performance sur des scénarios connectés ou déconnectés pour tout type de device.

Services de données d’application

Lorsque l’on souhaite bâtir une application dans le Cloud, il y a de multiples points à considérer pour implémenter certaines fonctions comme la recherche, ou pour améliorer la réactivité et les performances par des mécanismes de cache. Il devient alors pertinent de s’intéresser à la mise en œuvre de services applicatifs orientés données (cache, service de recherche, …).

Cache Applicatif

In-Role Cache

Azure Redis Cache

Azure Redis Cache est un service construit sur la solution Open Source Redis Cache. Ce service donne accès à un cache Redis sécurisé, dédié et géré par Microsoft. A la différence du In-Role Cache, un cache créé à l'aide d'Azure Redis Cache est accessible depuis n'importe quel type d’application Azure.

Service de recherche

Conclusion

Le service « Azure Search » offrant nativement une interface REST, on pourrait s’interroger sur l’intérêt de développer et exposer une API supplémentaire pour accéder à ce service. De multiples raisons peuvent justifier ce choix, comme par exemple la possibilité d’appliquer des transformations de format ou de sécuriser l’accès à cette API en se fondant sur un mécanisme d’authentification spécifique. Se pose alors la question de savoir comment nous allons développer et héberger cette API.

API Apps

Avec la prolifération des périphériques mobiles, les entreprises doivent proposer des API permettant aux développeurs d'applications internes ou non, d’offrir de nouvelles expériences spécifiquement conçues pour ce type de device. Cette évolution est facilitée par la généralisation de l’adoption du style d’architecture REST, des standards liés (HTML, JSON, ….) et des composantes technologiques associées en termes d’implémentation, de sécurité et d’infrastructure.
Pour accélérer cette transformation digitale, les « Azure API Apps » facilitent la création et la publication d’API. Elles permettent de les créer dans différents langages (ASP.NET, Java, PHP, Node.js, Python,…), de les déployer et de les héberger sur une infrastructure Microsoft Azure.
Elles offrent une gestion d’accès simplifiée vis-à-vis du service d’authentification intégré Azure Active Directory ou d’autres services tiers (comme les fournisseurs d’identité associés à Facebook ou Twitter) sans nécessité d’apporter de modification au code de l’API (via API Gateway : nous reviendrons sur ce sujet ultérieurement).
Elles permettent une connectivité hybride étendue grâce à plusieurs dizaines de connecteurs (SaaS & BizTalk) afin de simplifier le code à écrire pour assurer l’interaction avec SalesForce, Office 365, Twitter, Facebook, Dropbox… Dans le cadre de notre solution, nous n’aurons pas à utiliser cette capacité.
Enfin, elles augmentent la productivité en proposant un support natif des métadonnées Swagger  (documentation interactive et de détection d’API REST) pour la définition de l’API, ce qui permet d’offrir, grâce au SDK d’ « API Apps », des mécanismes de génération automatique de code client dans divers langages, par exemple C#, Java et JavaScript. Comme nous allons le voir, ce service est totalement intégré à Visual Studio, ce qui facilite grandement la publication et le debugging d'une API.

Développement d’une API App

Après installation du SDK Azure, Visual Studio (2013 ou 2015) propose un modèle pour le développement d’ « API App ». L’utilisation de ce modèle permet de créer un projet pré-configuré avec le code et les librairies requises. 

L’implémentation du service proprement dit est similaire à celle d’une Web API. Il s’agit dans un premier temps de décider des fonctions que l’on souhaite exposer. Dans notre contexte, nous nous limiterons dans un premier temps à des fonctions liées au contexte du service de recherche en les limitant à un usage de consultation. Il nous faut donc pouvoir remonter la liste des documents correspondant aux critères de recherche mais aussi pouvoir incrémenter le compteur correspondant aux nombres de demandes de téléchargement.
La méthode de recherche sur le nom du document (voire sur le content-type si l’on passe l’extension) renvoie une collection de DocumentProperties. De même que pour une Web API, il faut choisir le protocole d’exposition du service REST. Cette méthode sera exposée sur la base de l’utilisation d’un verbe http GET. On peut utiliser la déclaration d’attribut dans le Controller comme [HttpGet] ou respecter la convention qui consiste à préfixer la méthode par Get.Le paramètre « name » de la méthode « SearchByName » correspond au nom du paramètre « {name} » renseigné dans le fichier « WebApiConfig.cs ».

Par défaut le service API App refuse l’utilisation de du caractère « * »  et renvoie le message « A potentially dangerous Request.Path value was detected from the client (*) ». L’implémentation de la méthode « SearchByName » est donc aménagée pour permettre l’envoi de requête sur l’ensemble des fichiers, le « * » étant alors remplacé par un « #@! »…

On peut alors très simplement tester en local l’utilisation de cette méthode. Par exemple, l’appel REST correspondant à la recherche de l’ensemble des documents commençant par la lettre A sera : https://localhost:15244/api/Search/A
La méthode d’incrémentation du compteur, baptisée « Update » est exposée via le verbe http PUT puisqu’il s’agit de la mise à jour d’une ressource existante.L’implémentation de cette méthode est fondée sur le même principe que son équivalent dans l’application Web (Utilisation de l’objet « SearchIndexClient »,  et indexation par lot sur un batch composé d’une seule action de création).

Déploiement d’une API App

Le déploiement est réalisé directement depuis Visual Studio. L’ « API App » ainsi déployée s’inscrit dans un groupe de ressources. Un groupe de ressources est un conteneur logique destiné à faciliter la gestion du cycle de vie d’un regroupement de multiples ressources Azure : dans notre cas, une instance de service « Azure Search », une « Web App », et une « API App » ont été ajoutées au même groupe de ressources. Une fois l’ « API App » publiée, elle peut être configurée dans le nouveau portail. Il est également possible de downloader le fichier Swagger.

Swagger

L’« API App » peut être debuggée directement depuis Visual Studio (qu’elle s’exécute en local ou dans le Cloud). Il est également possible de la tester depuis l’interface Swager. Swagger est un framework offrant des mécanismes de génération de documentation et de code à partir d’une API REST. Il est possible d’étendre une « API App » avec Swagger. Le projet créé à partir du template « API App » dans Visual Studio intègre une référence à l’assembly  « Swashbuckle » (un « Swasjbuckler » est un héros de film de cape et d’épée…). 

Par défaut, le site Swagger n’est pas exposé.  Pour l’activer, il suffit de dé-commenter le code suivant dans le fichier « SwaggerConfig.cs ».
L’URL du site Swagger associée à l’API App est obtenue en suffixant l’URL du site correspondant par « /swagger ». On dispose alors de l’interface suivante :  
 
Pour tester une API, il suffit alors d’étendre l’opération que l’on souhaite cibler.  

On dispose ainsi d’une console permettant de renseigner les paramètres de la méthode et de l’exécuter, comme l’illustre la copie d’écran suivante pour le GET :  
Et cela offre naturellement la possibilité de tester très simplement le PUT.

Maintenant que le service de recherche est exposé via une API App déployée dans Azure, dans le prochain article, nous nous intéresserons à la façon dont nous allons pouvoir le consommer depuis une application Windows Universelle, une bonne occasion d’explorer ensemble les nouveautés de la plateforme UWP….