Archives de
Catégorie : Automatisation

DevOps : concepts et base

DevOps : concepts et base

Le DevOps est un mot à la mode en ce moment dans le monde de l’IT mais il est toujours difficile de cerner exactement ce qu’apporte ce concept protéiforme. Nous allons nous pencher un peu plus sur ce (vaste) sujet et aborder les bases de ce qui constitue le DevOps.

Qu’est-ce que le DevOps ?

Vous l’aurez peut-être deviné, DevOps provient de la contraction des mots développement et opérations. Il s’agit d’une approche culturelle et technique reposant sur des principes agiles et visant à renforcer la collaboration entre les équipes métiers, développement, opérations et assurances qualité dans le but de délivrer des logiciels de manière continue. Cette organisation permet à une entreprise de profiter plus rapidement de certaines opportunités de marché et d’avoir un retour client accéléré.

Dans une approche DevOps, les équipes de développement et d’opérations collaborent pleinement et peuvent même fusionner. Ces équipes travaillent ainsi sur tout le cycle de vie des applications comme l’illustre le schéma au dessus.

Il est important de garder à l’esprit qu’une approche DevOps n’est pas uniquement technique : elle est aussi culturelle et relationnelle. Elle repose sur la communication entre tous les services d’une entreprise au-delà des équipes purement techniques (développement et opérations). L’approche DevOps doit ainsi englober les parties prenantes d’un projet tels que : le marketing, la direction et même les clients…

Les bénéfices d’une approche DevOps

La mise en application de l’approche DevOps au sein des équipes et des environnements garantit de nombreux avantages comme la facilité de la maintenance, l’automatisation des tâches ou l’amélioration de la communication inter-équipes.

  • Publications plus rapides et plus légères.
    La publication fréquente de nouvelles versions d’un logiciel va permettre de mettre à disposition les nouvelles fonctionnalités plus rapidement aux client (gain de compétitivité à la clé). Avec des déploiements plus fréquents, ces derniers sont moins importants et posent potentiellement moins de problèmes. La remontée de bugs est également accélérée.
  • L’automatisation, gage de fiabilité
    Une approche DevOps permet un gain non négligeable en termes de sécurité et de fiabilité. Grâce aux processus automatisés, on ne risque plus d’erreurs humaines liées aux tâches manuelles. De nombreux tests et vérifications automatiques sont effectués avant d’arriver à une phase de déploiement qui devient un non-événement.
  • Automatisation & productivité
    Du fait de cette forte automatisation, on bénéficie aussi d’un gain en termes de productivité. On peut profiter de plus de temps pour travailler sur de nouvelles fonctionnalités au lieu d’effectuer des tâches manuelles et lentes de tests, gestion d’infrastructures ou encore de déploiement.
  • Facilitation de la communication interne
    Le DevOps vise aussi à améliorer la collaboration entre les équipes, qu’elles soient techniques ou non. L’objectif de la philosophie DevOps est d’aligner tout le monde sur le même objectif pour éviter les conflits. Par exemple, de nombreux outils de supervisions retranscrivent sous forme de tableau (dashboard) les données et facilitent la compréhension et le suivi par tous.

DevOpsBenefits.

Quelques pratiques de l’approche DevOps

L’automatisation étant au cœur de la philosophie DevOps et de nombreuses pratiques y participent mais ces changements techniques impliquent aussi une organisation différente. Voici quelques grandes pratiques DevOps.

  • Intégration continue
    Méthode de développement logiciel permettant d’intégrer régulièrement chaque changement du code au niveau d’un dépôt de code source (GitLab, Bitbucket). A la suite de cette intégration, des opérations automatisées de build et de tests sont lancés avec le nouveau code source.
  • Livraison et déploiement continue
    Il s’agit de l’extension même de l’intégration continue. En effet, si le processus d’intégration continue permet de tester l’application à chaque changement de manière optimale, on peut se permettre par la suite de préparer un livrable ou bien de carrément déployer l’application quand tous les tests sont au vert et ce de manière automatisée.
  • Infrastructure as Code
    Le concept d’Infrastructure as Code se réfère au fait de décrire son infrastructure sous forme d’un fichier texte (JSON/YAML). L’infrastructure peut alors être gérée comme du code source normal en étant versionnée ou encore passée dans un processus d’intégration ou de déploiement continu.
    Grâce aux API proposés par les différents Cloud providers, l’IaC est désormais accessible grâce à des outils comme Terraform ou AWS Cloudformation (pour ne citer qu’eux) qui prennent en entrée ce fichier respectant une certaine norme puis déploient et configurent l’infrastructure décrite de manière automatisée. Cela permet une forte standardisation, une limitation des risques d’erreurs de configuration mais aussi une reproductibilité grandement simplifiée.
  • Monitoring et feedback
    Dans une démarche DevOps le monitoring aussi bien au niveau de l’application que de l’infrastructure est important pour détecter les problèmes de performances, de sécurité ou encore d’expérience utilisateur.
    Cela constitue la boucle de feedback de la démarche DevOps qui permet de mettre en lumière les problèmes posés par les mises à jour et les potentielles améliorations à apporter. (On peut citer par exemple Grafana, qui a été l’objet d’un article précédemment.)
  • Communication et collaboration renforcées
    Au-delà de la partie technique, comme nous l’avons évoqué en début d’article, une démarche DevOps passe aussi par l’amélioration de la collaboration au sein et entre les équipes techniques (développement, opérationnel) et non techniques (marketing, direction …).
    Le DevOps casse les frontières et implique un partage de l’information entre toutes les parties prenantes à un projet dans le but de garder un objectif commun.

cloudappsdevops

En conclusion

L’approche DevOps apporte de nombreux avantages en termes de productivité, de fiabilité et de maintenance. En facilitant la communication entre les pôles d’une équipe, l’approche DevOps est aussi un facteur de cohésion : grâce à des métriques fiables et communes, un environnement peut être analysé et optimisé par l’ensemble de l’équipe. L’automatisation des processus est important aussi bien en termes d’efficacité que de fiabilité. L’approche DevOps reposant sur les concepts d’agilité, les retours utilisateurs peuvent être intégrés rapidement au sein des solutions déployées.

L’approche DevOps serait donc le saint Graal du monde de l’IT ? Sans doute mais la mise en place des principes DevOps est toujours une gageure quelle que soit la structure. La bonne application des pratiques nécessite des équipes volontaires aussi bien dans la technique (CI/CD et utilisations d’outils IaC) que dans le relationnel (partage de l’information renforcée, amélioration de la communication). Comme souvent, une bonne synchronisation des équipes et l’application de bonnes pratiques sont la base d’un travail efficace.

Réseau mondial, où centraliser ses données ?

Réseau mondial, où centraliser ses données ?

Introduction

Grâce à ses multiples régions à travers le monde, AWS offre la capacité de créer une infrastructure réseau couvrant la totalité du globe. Dans ce cadre la question de l’emplacement des données se pose : doivent-elles être centralisées dans une région, ou réparties selon les besoins ?
Pour apporter un élément de réponse à cette problématique, nous nous sommes penchés sur les vitesses de transfert de données inter-région. Pour cas d’usage, nous avons pris un environnement Windows avec des utilisateurs travaillant sur des machines pour traiter/manipuler des données de projets hébergées sur un serveur de fichiers.

Un peu de théorie

Lorsque qu’un message est envoyé d’une machine à une autre, il va mettre un certain temps pour parcourir le chemin à travers le réseau. Ce temps est appelé la latence. On peut consulter un tableau des latences entre les régions AWS sur le site www.cloudping.co :

graphique-1

On vous déconseille de transférer des fichiers de São Paulo à Mumbai.

Lors du transfert d’un fichier, plusieurs messages sont échangés entre les machines, notamment à l’initialisation de la connexion puis durant le transfert car le fichier va être découpé en plusieurs messages. Le nombre d’échanges est dépendant du protocole de communication utilisé. Plus il y a d’échanges, plus la latence va impacter le temps total de transfert.

En pratique

Durant nos tests, en plus de comparer les temps de transfert entre les régions, nous avons également voulu voir l’impact de la version de Windows Server du côté de l’hébergeur et de la consommation des données.

Notre protocole de test :

  • Infrastructure réseau répartie sur les régions Oregon, Ireland et Singapore (liaison avec VPC peering)
  • 4 serveurs Windows Server 2008 R2, 2012 R2, 2016 et 2019 par région
  • Fichiers de test : un dossier de 400Mo contenant 210 fichiers allant de 52k à 100Mo
  • Outils de transfert : robocopy

La mise en place de l’infrastructure et les tests ont été automatisés à l’aide des services AWS CloudFormation et AWS System Manager.

Infrastructure réseau :

Infra Reseaux TestQuatre type de Windows Server (2008 / 2012 / 2016 / 2019) dans trois régions AWS distinctes (Oregon / Ireland / Singapore)

Les latences observées entre les régions :

  • Oregon – Ireland : 160 ms
  • Oregon – Singapore : 170 ms
  • Ireland – Singapore : 190 ms

Résultats des transferts :

graphique-2

graphique-3

graphique-4

On peut constater plusieurs points :

  1. Les temps de transfert sont sans commune mesure à l’intérieur d’une même région.
  2. La liaison Oregon-Ireland est plus rapide qu’Oregon-Singapore
  3. Selon la version de Windows Server, on peut avoir près de 50% de temps de chargement en plus.

Conclusion

Malgré la qualité des connexions réseaux, la distance entre les données et les utilisateurs est un facteur primordial pour une expérience de travail optimale. Il faut donc privilégier les courtes distances.

Pour pallier ce problème, nous pouvons nous appuyer sur l’offre End User Computing d’AWS qui fournit des machines de travail au plus près des données : Amazon WorkSpaces et Amazon AppStream 2.0. L’un est un service de desktop streaming et l’autre d’application streaming.

Tous deux sont accessibles par internet depuis le monde entier et utilisent des protocoles sécurisés et optimisés. En les intégrant dans un domaine Active Directory, ils offrent une porte d’entrée sécurisée vers votre système d’information, sans contraintes de mise en place de configuration réseau entre vos utilisateurs ou prestataires externes.

Vous voulez en savoir plus sur les possibilités de déploiement de Amazon WorkSpaces et Amazon AppStream 2.0 ? N’hésitez pas à nous contacter !

Corexpert déploie SAP GUI avec Amazon AppStream

Corexpert déploie SAP GUI avec Amazon AppStream

En seulement deux jours Corexpert déploie le client SAP Gui pour l’ensemble de ses collaborateurs.

Après avoir rejoint le groupe TeamWork en septembre 2017, Corexpert a réintégré sa comptabilité en quelques semaines dans SAP. A partir de janvier 2018, l’intégralité de la gestion de Corexpert est opérationnelle dans SAP : Commandes, Facturation, saisie des temps à facturer, suivi des absences, notes de frais, workflow…

Afin de permettre à nos collègues d’utiliser le client de connexion SAP (SAP GUI, prononcez « gooey » ou G-U-I pour Graphic User Interface) il leur fallait donc un client à installer sur leur poste local ainsi qu’un compte VPN individuel afin d’accéder aux infrastructures SAP du groupe. Le client Mac n’étant pas natif, une version JAVA est disponible…

Corexpert est « born in cloud » et dans la mesure du possible nous utilisons des ressources dans Amazon Web Services pour nos applicatifs, ou des applications SaaS. Nous ne sommes pas vraiment coutumiers du déploiement sur postes utilisateurs et ne voyant pas comment faire cela avec Jenkins 🙂 nous avons décidé de mettre en oeuvre Amazon AppStream afin d’accélérer ce déploiement et s’assurer que celui-ci soit réalisé sans impact pour nos utilisateurs (disponibilité du PC/MAC etc…).

Amazon AppStream est actuellement dans sa seconde version, basé sur la technologie NICE DCV, celle-ci sécurise les pixels et les entrées d’utilisateur final à l’aide d’un chiffrement AES-256 de bout en bout. Le service ne nécessite pas de client à installer, mais un simple navigateur HTML5, authentification par email et mot de passe ou ADFS par exemple. Les applications préalablement installées sur une image Windows Server 2012, sont « streamées » vers le navigateur de l’utilisateur final.

L’architecture déployée est celle décrite ci-dessous, les utilisateurs Corexpert accèdent au portail AppStream 2 de n’importe où en SSL et la « fleet » de serveurs AppStream se trouve dans un VPC interconnecté avec le VPN & Firewall de TeamWork, Data-Centre où est hébergé l’infrastructure SAP groupe.

sapgui-corexpert

Le déploiement Amazon AppStream est réalisé sur « fleet on-Demand » c’est à dire que le nombre de serveur est déclenché au fur et à mesure de la connexion et demande des utilisateurs. Vous trouverez dans la petite vidéo ci-dessous un « cold-start » avec une attente constaté d’une minute.

A retenir

Un déploiement unifié et sécurisé, l’accès aux données est chiffré de bout en bout.

Une gestion centralisé du porte-feuille des application, la mise à jour du SAP GUI est appliquée et disponible pour tous les collaborateurs simultanément.

Amazon Appstream est programmatique et pilotable en ligne de commande, on planifie par exemple plus de serveurs dans la flotte Amazon Appstream lors de la saisie des temps en fin de semaine et fin de mois !

Un coût minimal de l’infrastructure, paiement à l’heure d’utilisation.

Employee Advocacy : déléguez la publication de news AWS sur Twitter avec Slack

Employee Advocacy : déléguez la publication de news AWS sur Twitter avec Slack

La réception des nouveautés AWS nous permettant déjà de nous informer quotidiennement des dernières annonces, nous avions besoin d’une solution de diffusion, ouverte à tous et à toutes, vers le compte Twitter de Corexpert. Pour cela, nous avons développé une application, nommée « NewsBot », basée sur plusieurs services AWS, et proposant de tweeter une actualité par l’intermédiaire de Slack.

 

1 – Architecture

L’application se compose de deux micro-services, le Notifier (Amazon Lambda) et le Publisher (Amazon API Gateway + Amazon Lambda), ainsi que d’une base de données (Amazon DynamoDB).

newsbot

2 – Base de données

Les informations reçues depuis le topic Amazon SNS sont stockées dans une table Amazon DynamoDB. En outre, un champ supplémentaire, que nous avons appelé « actions », contient la liste des réseaux sociaux pour lesquels l’article a déjà été publié.

Afin de restreindre la publication sur Twitter de certaines news en fonction de leur date de publication, nous avons également ajouté un champ TTL, indiquant à Amazon DynamoDB à partir de quelle date il est nécessaire de supprimer l’item de cette table.

dynamodb

 

3 – Le Notifier

Il est composé d’une unique fonction Amazon Lambda, déclenchée par le service Amazon SNS ; cette fonction va parser l’évènement reçu, pour ensuite l’insérer dans la table Amazon DynamoDB et envoyer un message dans un channel Slack.

Commençons par créer une application Slack ; pour notre Notifier, il est nécessaire d’activer les Incoming Webhooks, et d’en ajouter un à notre channel de notifications.

incoming-webhooks

Slack nous donne alors une URL, sur laquelle nous pouvons envoyer nos requêtes POST, contenant la nouvelle notification au format JSON.
Voici un exemple de notification générée par le NewsBot :

aws-newsbot-slack-1

 

4 – Le Publisher

 

a. Publication sur Twitter

Le Publisher est composé des services Amazon API Gateway et Amazon Lambda, permettant de publier un article sur Twitter.
Le fonctionnement du service est le suivant :

  • Une requête HTTP POST est envoyée depuis Slack à notre fonction Amazon Lambda.
  • On vérifie que le token reçu dans le body de la requête est le même que celui de notre application Slack. Ce token est renseigné dans l’onglet “Basic Information”.
  • On vérifie dans la table Amazon DynamoDB que l’article n’a pas déjà été publié sur Twitter.
  • On envoie une requête à Twitter pour créer l’article.
  • La table Amazon DynamoDB est mise à jour pour que la requête ne soit pas traitée deux fois.

Afin de :

  • rendre le bouton utilisable, il est nécessaire d’activer les Interactive Components, et ainsi indiquer à Slack l’URL à appeler (celle fournie par Amazon API Gateway) ;
  • publier sur Twitter, il faut d’abord créer une application, et générer les Consumer Keys et Access Token.

 

b. Modification du message original

Le corps de la requête POST envoyée par Slack est encodé, et contient un objet JSON  nous permettant de récupérer l’utilisateur ou l’utilisatrice ayant cliqué sur le bouton.

Cette information va donc nous servir à remplacer le bouton par un texte, informant toutes les personnes présentes sur le channel que l’article a déjà été publié sur Twitter, à quelle date, et par qui.

Bonus : à la publication de l’article, Twitter nous retourne l’identifiant du tweet qu’il vient de créer ; nous allons donc pouvoir utiliser les WebIntents et ainsi proposer à chacun et chacune de retweeter l’information sur son propre compte.

aws-newsbot-slack-2

 

5 – Conclusion

Le NewsBot va donc permettre de déléguer l’activité du compte Twitter d’une entreprise aux personnes présentes sur un channel Slack, d’une manière simple et rapide, depuis un (ou plusieurs) topic(s) Amazon SNS.

Planifiez vos tâches CRON avec AWS

Planifiez vos tâches CRON avec AWS

Utilisé en conjonction avec Amazon CloudWatch Events, Amazon SNS permet le déclenchement de tâches CRON appelant des web services. Nous allons voir dans ce post comment mettre cela en place facilement.

Dans un premier temps, il nous faut créer un topic SNS.
create_topic

Puis, créer une subscription vers la route du web service. Ainsi, à chaque publication dans le topic SNS par l’event Cloud Watch, une notification sera envoyée à la route HTTP définie.create-subscription

Avant de créer cette subscription, il faut savoir que toute subscription nécessite une confirmation dont la demande est envoyée à la cible. La demande de confirmation est envoyée lors de la création de la subscription mais celle-ci peut être faite manuellement via la console AWS.

Voici un exemple de code PHP qui vérifie la signature des messages envoyés par Amazon SNS et confirme automatiquement la subscription au topic :

Enfin, il ne nous reste plus qu’a créer une rule pour déclencher un Event Amazon CloudWatch selon un Schedule qui publiera dans ce topic tous les x minutes/heures/jours . create_cw_rule

Et voilà ! notre web service est maintenant appelé toutes les 5 minutes.

Conjuguer les services Run Command et Auto Scaling Group

Conjuguer les services Run Command et Auto Scaling Group

Une commande à lancer sur la centaine de machines de votre Auto-Scaling Group ? Rien de plus facile avec le « Systems Manager Run Command » !

Configuration des droits

Les instances cibles doivent avoir un rôle contenant la policy AmazonEC2RoleforSSM.

iam-policy-ssm

L’utilisateur lançant les commandes doit avoir la policy AmazonSSMFullAccess.

 

Installation de l’agent sur les instances

L’agent est responsable de l’exécution de la commande. Sur les instances Windows, il est déjà installé. Pour Linux, il faut l’installer manuellement : soit en se connectant à l’instance et en lançant les commandes, soit via les user data (à utiliser pour l’Auto-Scaling Group).

Toutes les commandes d’installation de l’agent sont disponibles dans la page de documentation « Installing SSM Agent ».

Exemple de launch configuration avec une instance Amazon Linux AMI:

launch-configuration

 

Identification des instances

Les instances de l’Auto-Scaling Group doivent être identifiables par un tag dont la key/value est spécifique à celui-ci.

autoscalinggroup-tag

 

Lancement d’une commande depuis la console

Dans le menu de l’interface EC2, aller dans « Systems Manager Services » -> « Run command » et cliquer sur le bouton « Run command ».

goto-runcommand

Remplir le formulaire avec les informations suivantes :

  • Command document : sélectionner « AWS-RunShellScript »
  • Select targets by : sélectionner « Specifiying a Tag » et entrer le tag de l’auto scaling group

select-targets-by-tag

  • Commands : entrer « ps -aux »

Appuyer sur le bouton « Run » en bas à droite.

Vous pouvez alors suivre l’état d’avancement de la commande :

run-command-table

Le résultat de la commande est accessible via l’onglet « Output »:

run-command-output

 

Lancement d’une commande depuis AWS CLI

A la fin du formulaire précédent, un cadre donne la commande AWS CLI équivalente :

cli-from-form

 

Il est alors possible d’intégrer cette commande dans un scheduler afin de lancer des commandes de maintenance telles qu’un vidage de cache.

 


Sources :

Jenkins CI – Identifiants AWS

Jenkins CI – Identifiants AWS

Aujourd’hui, un petit article concernant l’automatisation et l’utilisation des services AWS depuis une instance Jenkins. AWS fournit de nombreux outils permettant l’automatisation de votre infrastructure, de vos déploiements, de vos backups, et j’en passe. On pense notamment au AWS CLI, AWS SDK et AWS CloudFormation. Cependant, il est nécessaire de contrôler la façon dont vous vous identifiez pour utiliser ces outils, par exemple vous pouvez avoir besoin de vous identifier sur plusieurs comptes AWS ou encore gérer différents droits en fonction du type d’environnement.

Tout d’abord, il faut vous munir d’identifiants AWS, liés à un utilisateur qu’il faudra créer :

add_user

Ensuite, rendez-vous sur votre instance Jenkins (si vous n’en avez pas encore, je vous conseille de suivre ce tutoriel). Jenkins permet de centraliser tous vos identifiants nécessaires pour les appels à tous les services externes dont vous avez besoin (Git, SSH, AWS, etc). Afin d’ajouter des identifiants AWS dans ce « Credentials Manager », il faut au préalable installer le CloudBees AWS Credentials Plugin. Il est maintenant possible d’ajouter les identifiants de notre utilisateur AWS :aws_credentials

Vous avez enfin vos identifiants AWS managés par Jenkins. Il ne reste plus qu’à les utiliser dans vos jobs. Pour cela, il faut se rendre dans la section « Build Environment » de votre job et sélectionner l’option « Use secret text(s) or file(s) ». Ajoutez un binding « AWS access key and secret » et choisissez les identifiants de votre choix :

job_aws_credentials

Par défaut, le plugin va ajouter les variables d’environnement AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY au runtime de votre job. Ces variables sont reconnues automatiquement par les outils AWS (CLI et SDK) et vous permettront de réaliser les actions de votre choix sur votre compte AWS (ex : aws s3api list-buckets).

Si cette article vous a été utile, n’hésitez pas à commenter, le partager ou nous contacter. Plus d’articles à venir sur l’automatisation…