Azure Container Instance et SQL Server

 

Si l’on regarde la liste des services Azure, il peut parfois être compliqué de choisir la bonne option, le bon service, pour héberger SQL Server. D’un côté le classicisme au travers d’une VM (Windows ou Linux), d’un autre côté une architecture serverless avec SQL Azure (en single database ou bien en mode pool élastique), ou bien une instance managée. Ceux qui suivent ce blog ou qui ont assisté à une session lors d’un SQL Saturday savent que je m’intéresse de près à la version 2.0 de la virtualisation : les conteneurs.

Azure offre différents services de conteneurs, nous allons dans un premier temps aborder Azure Container Instance.

Il s’agit très certainement du moyen le plus simple pour déployer et exécuter des conteneurs Docker dans Azure. Pas de serveur à gérer. Pas de VM à déployer, pas d’orchestrateur type Kubernetes. Un nom réseau pleinement qualifié pour y accéder. Bref, simple, efficace.

Let’s go.

Lorsque l’on se connecte sur le portail, il suffit de sélectionner le bon service et de débuter l’assistant d’installation.

image

Il est possible de spécifier une image sur le Hub Docker ou bien sur le repository Microsoft.

image

On spécifie ensuite le ressources dont on souhaite disposer, le nom DNS, le port TCP et les variables d’environnement comme on le ferait dans un fichier DOCKERFILE ou en ligne de commande.

image

image

Après quelques secondes, le conteneur est créé et démarré.

image

On peut accéder à la configuration de celui-ci, sans toutefois pouvoir modifier quoi que ce soit. On note au passage l’effort qui a été fait pour présenter les métriques systèmes liées à ce conteneur.

image

 

image

image

Tout comme l’on pouvait voir la log du conteneur sous docker, un onglet spécifique nous fourni la même expérience utilisateur.

image

On dispose même d’un shell afin d’interagir avec le “système”, l’OS du conteneur. Notez au passage que le volume disponible dans le contenreur est relativement réduit : un peu plus de 40GB.

image

Au final, la connexion depuis SSMS (ou une application) se fait très simplement en utilisant le FQDN.

image

Simple, pragmatique, efficace.

MAIS

On est dans la vrai logique des conteneurs. A savoir que l’on est stateless. Dès que le conteneur est stoppé, ou redémarré depuis le portail Azure, tout ce qui a été fait dans le conteneur est perdu. Absolument tout. Donc … les bases. Ce qui va de fait limiter les scénarii possibles avec ACI et SQL Server.

  • En production : compliqué, à moins de conserver le conteneur Up And Running tout au long du cycle de vie de l’application. J’ai déjà au le cas de figure, il suffirait de définir sa propre image qui serait exécutée comme un environnement vierge à chaque démarrage. Une fois le job terminé, on jette. Les ressources sont elles aussi limitées. En mémoire et nombre de CPU, tout comme le volume total des bases.
  • En test : pourquoi pas. Le côté stateless devient cette fois un avantage, car on peut reprendre les tests depuis une configuration vierge. Et le mode de tarification n’y serait finalement pas trop mal adapté.
  • En dev : avis très partagé. J’ai encore du mal à me faire une idée définitive. Si le fait de stopper le conteneur fait “perdre” les bases de dev ne me parait pas très productif. Certes il y a un gestionnaire de code source qui peut l’héberger et on peut tout recréer, mais bon … Et quid des données de test …. A bien y réfléchir, je pense que je n’y mettrais pas mes bases de dev.
  • En démo : pourquoi pas. A voir si le tarif est plus intéressant sur du très court terme par rapport à une single database SQL Azure, ou une VM … mais le coté rapidement disponible, pourquoi pas. Même si une instance développeur sur ma machine gardera toute ma préférence.

Il est possible d’utiliser un stockage persistant en montant un partage réseau dans un conteneur. Mais cela complexifie un peu l’affaire. Même en passant par du script.

az container create \
    --resource-group conseilit-fr \
    --image mcr.microsoft.com/mssql/server:2017-latest \
    --name sqlserver2017 \
    --ports 1433 \
    --vnet-name aci_vnet1 \
    --vnet-address-prefix 10.0.0.0/16 \
    --subnet aci_subnet1 \
    --subnet-address-prefix 10.0.0.0/24 \
    --environment-variables ACCEPT_EULA=Y SA_PASSWORD=Password1
    --azure-file-volume-account-name $ACI_PERS_STORAGE_ACCOUNT_NAME \
    --azure-file-volume-account-key $STORAGE_KEY \
    --azure-file-volume-share-name $ACI_PERS_SHARE_NAME \
    --azure-file-volume-mount-path /mssql/

Il faudra ensuite donner les droits à SQL d’utiliser cet emplacement, … Quitte à créer une image basée sur l’image officielle. Bref, pas forcément très simple comme mise en oeuvre pour un service don’t la philosophie semble être “create – start – run – stop – delete” dans un laps de temps relativement faible.

Et si le conteneur doit avoir de la persistance et une durée de vie longue, autant le donner en gestion à un K8s, ce que l’on abordera dans un prochain billet.

Côté tarification, la facturation débute au moment où l’on commence le pull de l’image et se termine lorsque l’on stoppe le conteneur. Adapté donc à un workload qui durerait peu de temps, mais qui serait exécuté à intervalles réguliers.

Si l’on devait exécuter le conteneur toute une journée, cela reviendrait à 5.38$ soit un peu plus de 160$ par mois. Raisonnable donc.

 

image

A mon avis, l’intérêt indéniable de la solution consiste à démarrer des conteneurs, plutôt orientés traitements, à la demande, sachant également qu’il reste possible d’utiliser le co-scheduling qui va exécuter plusieurs conteneurs sur le même hote.

SQL Server ne semble pas être la cible prioritaire des container instances. Let’s play with K8s !

Happy ACI …

Publicités

A propos Christophe

Consultant SQL Server Formateur certifié Microsoft MVP SQL Server MCM SQL Server 2008
Cet article, publié dans Azure, Containers, SQL Server, est tagué , . Ajoutez ce permalien à vos favoris.

Un commentaire pour Azure Container Instance et SQL Server

  1. anththebarrel dit :

    Merci pour cet éclairage Christophe, article bien mené, on passe de la description à la pratique et au concret rapidement, et on imagine bien les use cases.

Répondre

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l'aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s