Cloud primer

Container solutions

Infrastructure as a Service

Aussi appelé: Lift and Shift

Cette stratégie consiste à utiliser les cloud provider en tant que pur infrastructure provider:

On utilise des VM cloud (voir tableau ci-dessous)
On réutilise les systèmes de provisioning traditionnels, en ajoutant Docker sur chaque serveur
La maintenance des versions Docker, l'elasticité/scaling des containers et leur orchestration sont à gérer manuellement

	Amazon	Google	Microsoft
Service	AWS EC2 Instance (Elastic Compute Cloud)	Google Compute Engine	Azure Virtual Machines

Container as a Service

Les services CaaS sont des abstractions propriétaires par-dessus un orchestrateur. On bénéficie donc des fonctionnalités d'un orchestrateur, via des API simplifiées mais propriétaires.

Solutions assez fermées et spécifiques à un provider:

Forte intégration avec l'outillage du provider
Necessité de se former aux API et process spécifiques à chaque provider (ex: Amazon ECS Agent vs kubelet, ECS CLI vs kubectl)

Quasiment toutes les fonctionnalités d'un orchestrateur, simplifiées:

Attention: En fonction du provider: toutes les features de l'orchestrateur ne sont pas forcément exposées
Auto-healing et recovery: les containers qui plantent sont relancés automatiquement
Groupements de container liés pour créer des applications (abstraction du paradigme Kubernetes Pod/Service) (exemple: ECS Task & Task Definition)
Intégration avec docker-compose, docker registry, load balancer, gestion d'accès (ex: AWS IAM), logging

	Amazon	Google	Microsoft
Service	AWS ECS (EC2 Container Service)	Google Container Engine	Azure Container Instance

Note: AWS ECS possède deux types de launcher, EC2 et Fargate. Fargate est basé sur une VM Firecracker, proche des unikernels, et possédant donc une meilleure sécurité et isolation niveau kernel

ECS Task Definition

voir ECS developer guide)

{
    "family": "webserver",
    "containerDefinitions": [
        {
            "name": "web",
            "image": "nginx",
            "memory": "100",
            "cpu": "99"
        },
    ],
    "requiresCompatibilities": [
        "FARGATE"
    ],
    "networkMode": "awsvpc",
    "memory": "512",
    "cpu": "256",
}

Kubernetes as a Service

Ces services ne comprenent que l'orchestrateur, il faut donc y adjoindre des VM pour créer un cluster complet.

On manipule directement l'API de Kubernetes (utilisation de kubectl, gestion des Pods / PodSpec)
Google est généralement leader sur le marché KaaS vu que Kubernetes est un produit Google (full-featured, SLA, cluster boot time le plus rapide etc).
En général, les KaaS sont moins intégrées aux solutions spécifiques d'un seul provider (ex: AWS IAM).

	Amazon	Google	Microsoft
Service	AWS EKS (Elastic Kubernetes Service)	GKE (Google Kubernetes Engine)	AKS (Azure Kubernetes Service)

Voir autres offres KaaS sur CNCF

comparaison GKE, EKS, AKS

Créer des applications cloud native

Un des prérequis DEV est de suivre les principes 12 Factor App

Ces principes garantissent que l'appli est packageable et exploitable en tant que container au sein d'un cluster.

Les applications Stateless sont bien plus simples à containeriser / exploiter en cluster que les applications Stateful

CNCF Trail Map

Processus recommandé par la CNCF pour aller vers du cloud:

Voir

1) Containerization: convertir ses applications et dépendances en containers

2) CI/CD: à chaque incrément applicatif, tester, générer et déployer un nouveau container. Automatiser le déploiement et le rollback.

3) Orchestration: sélectionner une distribution Kubernetes ou une plateforme Kubernetes hébergée ou un installateur Kubernetes

4) Observabilité: on monitore des noeuds physiques, on observe les services