Comment développer et héberger ses applications conteneurisées sur Azure Kubernetes Services ?
Entre IaaS et PaaS : le CaaS
Les services de cloud publics comme Microsoft Azure proposent aujourd’hui différentes façons d’héberger vos applications. Historiquement, on a connu d’abord le IaaS, « Infrastructure As A Service », qui permet de déployer en quelques clics depuis un portail web une machine virtuelle (entre autres) sous n’importe quel système d’exploitation et d’y installer notre application. Avec sa scalabilité verticale (on ne peut qu’augmenter/réduire les ressources d’une VM, en ajouter une est une opération complexe), le IaaS demeure aujourd’hui largement utilisé pour deux raisons principales :
- Historique : ce sont souvent des machines (physiques ou virtualisées) migrées depuis un datacenter précédemment hébergé en interne ou par un tiers hébergeur (dans les deux cas, on parle d’hébergement on-premises par opposition à un hébergement cloud)
- Confort/ROI : c’est un mode d’hébergement et d’administration technique connu et maitrisé par les entreprises, avec souvent des investissements à rentabiliser (formations, outils de gestion/monitoring…).
Est ensuite apparu le PaaS, « Platform As A Service », qui propose des services d’hébergement flexibles directement gérés par l’éditeur. Scalables verticalement, et parfois horizontalement (multiplication transparente des instances du service), le PaaS a de nombreuses qualités avec un coût qui n’est pas forcément plus important que le IaaS. Malheureusement, il ne répond pas à tous les besoins. Son autre inconvénient est l’adhérence qui se crée par rapport aux services implémentés. Il n’est pas trivial de déplacer une application conçue pour Amazon AWS vers Microsoft Azure (ou l’inverse) lorsque des services PaaS ont été utilisés : il faudra sans doute revoir certaines parties de l’application et s’attaquer à des travaux de réécriture (développement) potentiellement non négligeables.
Grâce aux conteneurs, une troisième solution est aujourd’hui disponible. Docker a su démocratiser l’utilisation de ses conteneurs avec des outils simples et pratiques, et surtout grâce à la construction d’une communauté active autour de ces technologies. Les avantages face aux machines virtuelles en IaaS et aux services en mode PaaS sont notables :
- Pas de maintien du système d’exploitation, on change simplement l’image de base de son conteneur.
- Une application qui tourne dans un conteneur est indépendante : elle embarque sa configuration et ses dépendances. Le conteneur fonctionnera donc partout de la même façon, indépendamment de son déploiement.
- Les conteneurs sont une excellente solution pour les architectures micro-services.
- La consommation de ressources d’un conteneur est bien plus faible que celle d’une machine virtuelle.
- Scalabilité verticale et horizontale avec un orchestrateur de conteneurs.
- Le temps d’instanciation rapide d’un conteneur (pas d’OS à démarrer) en fait un excellent candidat à la scalabilité horizontale.
Le conteneur Docker s’est rapidement imposé comme solution de conteneurisation, puis l’orchestrateur initié par Google qui fut offert à la Cloud Native Computing Foundation, Kubernetes (ou K8s), est en bonne position pour devenir le leader sur le marché des orchestrateurs de conteneurs Docker (et pas uniquement ceux-là, il sait en effet gérer d’autres technologies de conteneurs).
Le CaaS « Container As A Service » propose donc une alternative aux mondes du PaaS et du IaaS. Le principe est simple : proposer une plateforme de gestion de conteneurs gérée en mode PaaS sur votre fournisseur de cloud. Vous n’avez plus qu’à déployer vos images Docker dessus !
Se lancer dans le CaaS sur Azure
Microsoft Azure propose une solution CaaS sous Kubernetes nommée AKS (Azure Kubernetes Service). Entièrement managée, vous n’aurez qu’à choisir le nombre de nœuds (de machines virtuelles) qui composent le cluster et leur puissance (tout cela peut être modifié par la suite).
Mettre à jour votre instance AKS vers une version plus récente de Kubernetes se fait en un clic, et le service AKS propose une disponibilité de 99.5% (à ne pas confondre avec la disponibilité des nœuds, qui est de 99.9% sur un seul nœud).
Cas pratique 1 : le site e-commerce
Prenons le cas d’une enseigne de e-commerce qui héberge son infrastructure business sur des machines virtuelles en mode IaaS + PaaS sur Azure. Pour héberger son site de vente, elle dispose de cinq serveurs frontaux derrière un load-balancer, de deux serveurs applicatifs hébergeant l’import des flux produits et le back-office et d’une base de données sur Azure SQL (PaaS).
Premier problème rencontré : l’enseigne constate que l’utilisation du site entre 1h et 6h du matin est quasi nulle. Elle paye donc cinq serveurs frontaux alors qu’un seul suffirait (disons deux, pour assurer la haute disponibilité du site).
Second problème, lors des soldes : le site doit absorber quatre à cinq fois plus de visiteurs à la seconde. Les deux solutions qu’elle a trouvées pour tenter de répondre à ces pics d’utilisation sont l’ajout de ressources sur les cinq serveurs frontaux, et/ou l’ajout de frontaux supplémentaires le temps des soldes.
La première option montre vite ses limites : aligner des VM très puissantes coûte rapidement très cher et le gain en temps de réponse n’est pas proportionnel à la dépense supplémentaire.
La seconde possibilité est difficilement envisageable car relativement fastidieuse et risquée (c’est une opération manuelle qui mobilise des compétences et demande du temps, les gestes techniques ne sont pas anodins puisqu’il s’agit de modifier la topologie de l’environnement de production). Ceci sans compter que l’opération inverse doit être réalisée une fois la période de pics de fréquentation passée, soit finalement peu de temps après.
Une solution semble donc évidente : utiliser une architecture PaaS. La base de données y est déjà hébergée, il suffit de passer le site et le back-office chacun sur une Application Web Azure. A priori, pas ou peu de code à réécrire, la migration peut se faire rapidement et sans trop de problèmes. Un passage au CaaS est également envisageable, mais sera plus coûteux sur le moment : il faudra conteneuriser l’application et la découper en micro-services.
L’avantage d’une telle démarche est réel lorsque l’on considère les nouvelles possibilités de gestion du cycle de déploiement de chaque service et surtout si l’on souhaite absolument limiter l’adhérence par rapport à tel ou tel cloud provider. Avec une telle architecture il devient possible de changer de provider très facilement ou même de faire le choix d’un retour au mode on-premises avec un hébergement interne ou chez un tiers hébergeur « traditionnel ».
Cas pratique 2 : l’hébergement de conteneurs indépendants
Le Docker Hub fourmille d’applications packagées prêtes à être utilisées. Votre entreprise possède potentiellement elle aussi des applications conteneurisées. AKS peut être alors vue comme une solution d’hébergement « mutualisée » prête à l’emploi pour vos collaborateurs : au lieu d’avoir à demander la création d’une ressource PaaS ou IaaS Azure au service infrastructure de votre entreprise, qui devra être monitorée, facturée en interne, documentée (etc…), votre collaborateur aura la possibilité de demander très facilement l’hébergement de son application conteneurisée sur le cluster AKS existant.
Les cas d’usages sont multiples :
- Environnement de test / développement,
- Application déployée pour un événement particulier,
- Application nécessitant une très haute disponibilité,
- Hébergement d’un service non disponible en PaaS sur votre fournisseur de Cloud mais disponible sur le Docker Hub,
- Micro services, APIs…
Pour aller plus loin avec AKS … voici quelques ressources pour se lancer dans l’aventure AKS :
Ecrit par Alexis Deluze et Amaël Le Lan