How-to : Grafana 6 sur AWS avec Docker

3 juin 2019 corexpert

Le maintien d’une infrastructure et l’optimisation des ressources sont des tâches qui nécessitent une vigilance quotidienne et des plateformes comme Grafana, Kibana ou Chronograf sont une pierre angulaire dans la surveillance des systèmes d’information.

Cette supervision est très importante dans un contexte DevOps : une meilleure vision des ressources facilite les prises de décisions, facilite le suivi de performance et permet de réfléchir plus durablement sur l’intérêt d’automatiser les tâches. La bonne mise en place et configuration de ces outils de supervision facilite une notion importante du DevOps : le dialogue entre le Dev et les Ops renforcé par des métriques fiables et partagées.

Nous allons nous pencher sur Grafana et plus spécifiquement la version 6 (une des dernières versions disponibles au moment où nous écrivons cet article). Dans un premier temps, nous aborderons l’intérêt de se baser sur AWS pour établir son outil de monitoring puis nous suivrons pas à pas la mise en place de l’infrastructure proposée.

Grafana est une plateforme open source de visualisation de métriques et de surveillance permettant de réaliser des tableaux de bord et des graphiques. La visualisation des métriques est remontée dès que les données sont disponibles et la plateforme supporte des data sources comme Cloudwatch, Influxdb, Elastichsearch ou Prometheus… Un des avantages de Grafana est aussi sa comptabilité avec plusieurs types d’authentification et ne nécessite donc pas d’utilisateurs IAM à gérer.

Voici quelques avantages à déployer Grafana sur AWS :

• Scalabilité de la base de données
Par défaut Grafana utilise SQLite3 en local mais supporte également MySQL et PostgreSQL. En utilisant Aurora MySql serverless, plus de problème d’évolutivité et le coût est indexé sur l’activité (pay as you go).

• Services managés
Avec des services comme Amazon Aurora ou l’utilisation de Docker avec Amazon ECS et AWS Fargate, plus besoin de gérer la maintenance de base de données ou de cluster ce qui se traduit par un gain de temps considérable.

Notre architecture de test

L’architecture est la suivante : un Application Load Balancer redistribue la charge sur le cluster ECS Fargate qui interroge la base de données Aurora MySQL Serverless.
D’autres services sont appelés afin de superviser (CloudWatch) ou de sécuriser (IAM, Certificate Manager et Route 53).

Place à la pratique

Pour ce tutoriel, on part du principe que le compte AWS est opérationnel et que la couche réseau (VPC, Subnets …) a été créée au préalable.

Création de la base de données Aurora MySQL

Création du cluster ECS

+ Configuration du cluster : création de Task definition Grafana (utilisation du Docker hub pour récupérer l’image Docker)

+ Configuration du cluster : inclure les variables d’environnement qui commence par GRAFANA_DATABASE_*

Task Definition ECS Fargate

+ Configuration de ECS Fargate : création du Service ECS

+ Configuration de ECS Fargate : Configuration du réseau

Permettre l’accessibilité de Cloud Watch <> Grafana avec les policies IAM

Ajouter l’IAM Policy (JSON) disponible sur le site de Grafana.

Configuration des data sources pour Grafana

Cas d’usage : monitoring le coût de run efficacement
IAM Policy pour avoir l’accès à la facturation :

 {
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": [
 "aws-portal:*Billing",
 "awsbillingconsole:*Billing",
 "aws-portal:*Usage",
 "awsbillingconsole:*Usage",
 "aws-portal:*PaymentMethods",
 "awsbillingconsole:*PaymentMethods",
 "budgets:ViewBudget",
 "budgets:ModifyBudget",
 "cur:*"
 ],
 "Resource": "*"
 }
 ]
 }

{

"Version": "2012-10-17",

"Statement": [

{

"Effect": "Allow",

"Action": [

"aws-portal:*Billing",

"awsbillingconsole:*Billing",

"aws-portal:*Usage",

"awsbillingconsole:*Usage",

"aws-portal:*PaymentMethods",

"awsbillingconsole:*PaymentMethods",

"budgets:ViewBudget",

"budgets:ModifyBudget",

"cur:*"

"Resource": "*"

}

]

}

Un exemple d’un tableau de bord concernant la facturation de services AWS.

Conclusion

Comme vu précédemment, la mise en place d’une plateforme de supervision est une pierre angulaire dans un environnement. Une supervision centralisée, résiliente et capable de croitre selon les besoins peut ne pas être un besoin critique au départ mais s’avère rapidement indispensable. Grâce à AWS, la notion d’agilité est possible grâce au scalling in / out et au paiement à la ressource consommée.

Vous êtes intéressés par le sujet du DevOps ? Notre prochain article à paraitre courant juin, reprends quelques bases sur ce sujet complexe !

Bien débuter avec Amazon EC2 Container Service (101) – Cluster & task

17 janvier 2018 corexpert Commentaires 0 Commentaire

Nous continuons dans la série “Bien débuter avec Amazon EC2 Container Service” en se concentrant sur les tasks et les clusters qui vont les héberger.

1 – Qu’est ce qu’un Cluster

Un cluster ECS est un regroupement d’instances EC2 qui vont héberger vos containers.

Exemple d'un cluster ECS — Exemple d’un cluster ECS

Un cluster peut contenir une ou plusieurs instances, de différents types et taille. Dans notre exemple, nous utiliserons une t2.micro.

2 – Création d’un cluster ECS

Nous allons nous connecter à la console web aws pour ecs. Nous allons cliquer sur “Cluster” dans le menu de gauche. Dans l’écran suivant (liste des clusters), nous allons cliquer sur “Create Cluster” pour créer notre premier cluster.

Dans l’écran de création de cluster nous avons un formulaire très complet avec de nombreuses options. Nous allons utiliser les champs suivants :

Cluster Name : helloworldCluster
Provisioning Model : On-Demand Instance
EC2 instance type : t2.micro
VPC : choisir la VPC où vous désirez créer vos instances
Security group : Choisir/Créer un security group qui ouvre le port 80

Cliquez sur le bouton bleu “Create” pour créer le cluster. Il devrait maintenant apparaître dans la liste des clusters

3 – Task Definition ou comment définir le lancement des containers

Une task definition est une liste des paramètres qui vont permettre le lancement de nos containers.

Pour la créer, nous allons cliquer sur “Task definitions” dans le menu de gauche, puis sur le bouton bleu “Create new Task Definition”.

Cette première task definition va nous permettre de lancer un container, qui aura son port HTTP (80) lié au port 8080 sur l’instance hôte.

Pour notre exemple nous allons remplir les champs suivants :

Task Definition Name : Helloworld-1
Container Definitions : cliquez sur “add container”
- Container name : Helloworld
- Image : 123456789012.dkr.ecr.eu-west-1.amazonaws.com/helloworld:latest
- Memory Limits (MB) : 128
- Port mappings :
  - Host : 8080
  - Container : 80
  - protocol : tcp
- Cliquez sur le bouton “Add”

Vous pouvez ensuite cliquer sur le bouton bleu “Create”

De nombreuses autres options sont disponibles dans le Container Definitions, pour permettre une définition fine des besoins des containers (Mapping de volumes, lien entre containers …)

4 – Exécution d’une task

Maintenant que nous avons créé notre Cluster de machine hôte et que nous avons décrit la manière de lancer le container, nous pouvons enfin l’exécuter.
Pour cela, nous allons cliquer sur le menu “Cluster” puis choisir dans la liste notre cluster helloworldCluster. Nous arrivons donc ici :

Cliquez sur l’onglet “Task” puis sur le bouton bleu “Run new Task”
Dans l’écran suivant nous allons choisir tous les éléments que nous avons créé précédemment

La task est créée et est prête à recevoir des messages.

5 – Connexion au container

Il ne reste plus qu’à valider que le container répond bien à nos requêtes HTTP.
Nous allons nous connecter directement à l’instance hôte sur le port 8080.
Pour trouver son IP, il suffit de cliquer sur le nom de la task (dans notre cas 67f6a5b4-4…) pour afficher les détails.
Dans la partie container il faut cliquer sur le triangle à côté du nom du container (helloworld) pour afficher les détails, l’IP sera dans la section “Network Bindings”

Vous pouvez ensuite aller dans votre navigateur préféré, et entrez l’url du container pour afficher la page

Félicitations, vous avez fait fonctionner votre premier container sur Amazon EC2 Container Service.

Dans le prochain article nous verrons comment aller plus loin en créant un service se basant sur l’image de container existante. Ainsi plusieurs containers seront lancés et pourront répondre à vos requêtes

Bien débuter avec Amazon EC2 Container Service (101) – ECR

30 août 2017 corexpert Commentaires 0 Commentaire

Docker est une technologie qui fait grand bruit depuis plusieurs années maintenant dans le domaine de l’IT.

docker-vs-aws — AWS vs docker in google search

Tous les grands cloud publics (Amazon Web Service, Google Cloud, Microsoft Azure) proposent une solution plus ou moins intégrée pour la gestion des containers. Dans ces articles nous allons vous expliquer comment débuter avec succès sur le service managé Amazon EC2 Container Service.

Cette série d’articles suppose que vous avez créé un VPC où seront créé les instances hôtes pour les containers docker, que la CLI AWS est installée sur votre poste et nous utiliserons une image “Hello-world” (dockercloud/hello-world) disponible sur le docker hub.

1 – Création du dépôt Docker Privé (ECR)

Pour être déployé, une image de container doit être mis à disposition dans un dépôt docker.
Plusieurs solutions sont disponibles, Amazon Web services (AWS) nous propose un dépôt privé managé (ECR) à un tarif intéressant (0,1$/Go/mois au 01/08/2017).

Pour déployer notre image sur ECR ( Amazon EC2 Container Registry ) nous allons tout d’abord récupérer cette image sur le docker hub.

docker pull dockercloud/hello-world

1	docker pull dockercloud/hello-world

Maintenant que nous avons notre image, nous allons la déposer sur ECR
Nous allons nous connecter à la console web aws pour ecs.

1a – Si vous n’avez pas encore utilisé le service

vous allez tomber sur la page “get Started”, il vous suffira alors de cliquer sur le bouton bleu “getStarted” au milieu de la page.
Sur l’écran suivant (Getting Started with Amazon EC2 Container Service), décocher la case pour ne pas déployer la demo ECS (sample)

1b – Si vous avez déjà utilisé ECS

Il suffit de cliquer sur “Repositories” puis sur “Create Repository”

2 – Sur la page suivante

vous allez pouvoir donner un nom à votre dépôt, helloworld dans notre cas. Puis l’on passe à l’étape suivante (Next step)

3 – La dernière page

elle nous donne toutes les indications pour utiliser le dépôt qui vient d’être créé.

2 – Ajout d’une image sur ECR

Nous allons déposer notre image HelloWorld sur le dépôt. Pour cela nous allons nous connecter sur ECR à partir de notre machine (notre dépôt est en ireland)

aws ecr get-login --no-include-email --region eu-west-1
 docker login -u AWS -p eyJwRXl…...iMSIsZnR5cGUKOiJEQWRBX0tFWSJ8 https://123456789012.dkr.ecr.eu-west-1.amazonaws.com

1 2	aws ecr get-login --no-include-email --region eu-west-1 docker login -u AWS -p eyJwRXl…...iMSIsZnR5cGUKOiJEQWRBX0tFWSJ8 https://123456789012.dkr.ecr.eu-west-1.amazonaws.com

Nous obtenons une ligne de commande qui va nous permettre de nous connecter à ECR

docker login -u AWS -p eyJwRXl…...iMSIsZnR5cGUKOiJEQWRBX0tFWSJ8 https://123456789012.dkr.ecr.eu-west-1.amazonaws.com
 Login Succeeded

1 2	docker login -u AWS -p eyJwRXl…...iMSIsZnR5cGUKOiJEQWRBX0tFWSJ8 https://123456789012.dkr.ecr.eu-west-1.amazonaws.com Login Succeeded

Nous sommes maintenant connectés, nous pouvons pousser l’image locale

docker tag dockercloud/hello-world:latest 123456789012.dkr.ecr.eu-west-1.amazonaws.com/helloworld:latest
docker push 123456789012.dkr.ecr.eu-west-1.amazonaws.com/helloworld:latest

1 2	docker tag dockercloud/hello-world:latest 123456789012.dkr.ecr.eu-west-1.amazonaws.com/helloworld:latest docker push 123456789012.dkr.ecr.eu-west-1.amazonaws.com/helloworld:latest

Si vous vous connectez sur la console web AWS, vous pourrez voir votre image dans le dépôt

Dans le prochain article nous allons utiliser cette image pour lancer un container docker sur ECS.

@ Très bientôt

Le SLA chez Amazon Web Services #AWS

2 janvier 2017 corexpert

Cet article a été mis à jour en janvier 2019 avec les modifications du SLA fourni par AWS. Les compléments d’information ont été intégrés directement dans l’article d’origine.

Chez Corexpert, nos clients nous posent souvent cette question :

« On nous parle toujours de Haute Disponibilité et Très Haute Disponibilité chez AWS, mais s’engagent-ils vraiment ? Existe-t-il un SLA ? »

Qu’est ce que le SLA ?

Le SLA, ou Service Level Agreement, est le niveau de qualité et de performance contractuel d’un service ou d’une infrastructure technique. Dans le cas de AWS, fournisseur Cloud, on parlera donc bien d’un service, vue qu’on évolue dans le monde IaaS – Infrastructure as a Service !

Le SLA doit cadrer en premier lieu de quelle fourniture nous parlons, et les critères de performances sur lesquels le fournisseur va s’engager. On pourra donc parler de temps de réponse, de fonctionnalité assurée, de disponibilité complète du service etc.

SLA chez AWS

Nous allons parcourir ci-dessous les principaux services, ou services majeurs de l’offre AWS, qui possèdent un SLA à la date de rédaction de cet article. Bien évidemment la liste est non exhaustive.

Amazon Route 53 : SLA du DNS AWS

Le service DNS de AWS, Amazon Route 53, possède un SLA de disponibilité du service du niveau le plus haut possible. En effet on a ici un engagement de disponibilité de 100% sur le service, ce qui est explicité par « Amazon Route 53 n’échouera pas pour répondre à vos requêtes DNS dans le cycle de facturation d’un mois ». Pourquoi parler d’un mois ? Car AWS, s’engage, en cas d’éventuelle défaillance avérée, de vous rembourser sous forme de crédits sur ce cycle de facturation.

Extrait de la page SLA – Amazon Route 53 au 29 décembre 2016

Amazon EC2 ou Elastic Cloud Compute : SLA des VM AWS

Service principal de AWS, Amazon EC2 et Amazon EBS fournissent respectivement l’hyperviseur managé pour executer vos Machines Virtuelles, aka instances EC2 et le stockage virtualisé Amazon Elastic Block Store. [Le SLA a été étendu à Amazon Elastic Container Service (ECS) et AWS Fargate (deux services ayant traits aux conteneurs Docker) depuis 2018].

Le SLA des services, avec l’engagement de Amazon Web Services, est d’au moins 99.95% mensuel. Soient moins de 22 minutes.

Si une indisponibilité était avérée entre 99.95 et 99.0%, AWS s’engage à effectuer une remise de 10% en crédits AWS sur le service EC2, en deça de 99.0% de disponibilité AWS proposera une remise de 30% en crédits. [La période d’indisponibilité est maintenant de 90.0% à 99.99% depuis 2018 pour la remise de 10% de crédit AWS.]

Il est important de noter que le SLA est lié à l’état « Region Unavailable« . Si vous ne le savez pas déjà, une région est l’ensemble de plusieurs zones (2+) de disponibilités, mais dans le cadre du SLA, AWS précise que l’état « Région indisponible » vous concerne si plus d’une zone de disponibilité où vous exécutez des instances EC2 est indisponible, comprendre les instances n’ont plus accès à Internet.

L’indisponibilité de EBS est avérée lorsque les volumes de stockage ne génèrent plus d’I/O avec une file d’attente non vide.

Amazon RDS, SLA des bases de données managées AWS

Amazon RDS est le service de Base de données managée par AWS, il supporte à ce jour MySQL, Oracle, PostgreSQL, MariaDB, Microsoft SQL Server, AuroraDB. Mais le SLA proposé par AWS, concerne uniquement les instances Multi-AZ (c’est à dire avec un serveur en Stand-By mode dans une autre zone de disponibilité) des moteurs SQL : Oracle, MariaDB, MySQL & PostgreSQL. Ce SLA est de 99.95% de disponibilité du service. L’indisponibilité est avérée quand toutes les requêtes de connection échouent pendant une minute sur l’instance RDS multi-AZ.

Engagement de AWS pour RDS et remboursement en crédits au 10 janvier 2019

Amazon S3, SLA du stockage AWS

Amazon S3 est le service de stockage d’objets, il est l’un des plus anciens services de AWS, et possède une durabilité des données de 99.999999999% en mode de stockage standard. Toutefois le SLA, concerne la disponibilité d’accès à la données stockée via l’API AWS. Le SLA de Amazon S3 est donc calculé sur le comptage d’erreurs ou d’indisponibilité de l’API sur 5 minutes.

L’engagement de AWS est de conserver une disponibilité au-delà de 99.9% mensuel, ce qui représente moins de 43 minutes 36 secondes.

Si AWS ne peut assurer cette disponibilité sur la région où est stocké votre bucket S3, alors 10% de remise sur le coût de stockage S3 seront reversés en crédits, et en deça de 99.0%, alors la remise en crédit s’élèvera à 25% du coût du service Amazon S3.

[Depuis janvier 2019, ces règles ont été étendues à Amazon Elastic File System (EFS) avec les mêmes engagements que pour S3. Amazon EFS est un système de stockage de fichiers simple managé (AWS gère l’infrastructure pour vous).]

Amazon CloudFront, SLA du CDN AWS

Amazon Cloudfront est le service CDN de AWS, avec plusieurs dizaines de « Edge Locations », ce service met en cache les requêtes web selon vos comportements et pattern d’URLs choisis. Il permet des diffusions et donc des chargements de données accélérés sur les sites web et applications mobile, notamment lorsque du contenu media transite.

AWS s’engage à maintenir une disponibilité globale du service au-dessus de 99.9% mensuel (identique à Amazon S3). Les remises effectuées sur le service, en cas de défaillance avérée, également basé sur la fréquence des erreurs d’accès aux données sont identiques à celles de Amazon S3.

AWS Shield, SLA du service de protection anti-DDoS

Lancé lors du re:Invent 2016, AWS Shield est l’officialisation de la protection anti DDoS de AWS. Le service utilise et protège les autres services Amazon CloudFront et Amazon Route 53, et son SLA, ramené sur des périodes de 24 heures, est lié directement aux SLA des produits cités précédemment. On pourra donc traduire ce SLA, par un simple rappel que l’utilisation du service AWS Shield devant Amazon CloudFront ou Amazon Route 53 ne modifie pas leur SLA.

Amazon API Gateway, SLA sur la gestion des API

Depuis janvier 2019, AWS s’engage à assurer une disponibilité de 99.95% mensuel du service Amazon API Gateway. Ce service entièrement managé facilite la gestion, la surveillance et la sécurité des API de n’importe quelle taille. En cas de rupture du service, le crédit alloué est identique à ceux de RDS : 10% de remise entre 99.0% et 99.95% et 25% de remise pour une disponibilité mensuelle moindre à 99.0%.

Amazon EMR, SLA sur les frameworks Big Data

En janvier 2019, Amazon EMR bénéfice d’un engagement en terme de disponibilité de la part d’AWS. Les frameworks Big Data gérés par le service possède un SLA de 99.9% mensuel.

Engagement de AWS pour EMR et remboursement en crédits au 10 janvier 2019

Amazon Kinesis, SLA sur la gestion des données en streaming

Amazon Kinesis traite de la collecte, du traitement et de l’analse de données en streaming en temps réel. Le SLA sur lequel s’engage AWS depuis janvier 2019 touche trois composants principaux de Kinesis : Videos Streams, Data Streams et Data Firehose. L’engagement de disponibilité des services est de 99.9% mensuel avec une remise de 10% à 25% en cas d’indisponibilité.

Synthèse des SLA chez AWS

Service AWS	SLA mensuel	SLA minutes/mois
Amazon Route 53	100.00 %	0 seconde
Amazon EC2	99.99 %	4 minutes 30 secondes
Amazon RDS	99.95 %	21 minutes et 36 secondes
Amazon S3	99.90 %	43 minutes et 12 secondes
Amazon CloudFront	99.90 %	43 minutes et 12 secondes
AWS Shield	Cf. CloudFront ou Route 53	Cf. CloudFront ou Route 53
AWS API Gateway	99.95 %	21 minutes et 36 secondes
Amazon EMR	99.90 %	43 minutes et 12 secondes
Amazon Kinesis (Data / Videos Stream / Data Firehose	99.90 %	43 minutes et 12 secondes

Calcul du SLA d’une infrastructure AWS

Partons d’une infrastructure Web App, relativement classique. Elle est composée de plusieurs serveurs applicatifs frontaux, ici EC2 C4.Large, le code exécuté est le même sur chaque instance, et nous avons une redondance multi-zone de disponibilités. La base de données est un MySQL sur RDS en Multi-AZ (Stand-By Instance). Les éléments statiques du sites sont stockés sur S3. CloudFront, est placé devant le Load Balancer, il met en cache les éléments statiques de S3 et reroute les autres requêtes sur le LoadBalancer. Route53 gère le nom de domaine du site.

Infrastructure Web : Amazon Route 53, CloudFront, S3, EC2 et RDS

Voici comment nous pouvons calculer le SLA de cette infrastructure, bien entendu celui-ci est dans le cas d’une défaillance de tous les services AWS utilisés sur une région, et dans le cadre du SLA de chacun de ses services. Dans ce cas l’infrastructure ne peut prétendre à un SLA supérieur sans redondance supplémentaire.

RDS Multi-AZ MySQL : SLA de 99,95 %
EC2 : SLA de 99.95 %
CloudFront : SLA de 99.9 %
S3 : SLA de 99.9%
Route 53 : 100.0 %

Le SLA de l’infrastructure brute sera de :

99.95% x 99.95% x 99.9% x 99.9% x 100% = 99,70 %

Si l’on considère que l’indisponibilité S3 n’est pas critique pour la conservation de la disponibilité de l’infrastructure web (par exemple une API) et qu’on gère via Route 53 l’éventuel downtime de CloudFront en pointant vers le Load Balancer en secours, nous gagnerons 0,2% de SLA juste par modification et optimisation du Design de l’infrastructure :

99.95% x 99.95% x 100% = 99,90 %

N’hésitez pas à poser vos questions ou nous contacter pour plus d’informations.

Corexpert & TeamWork Blog

Ressources pour les architectes et développeurs cloud AWS

Archives de
Étiquette : ECS