Pourquoi automatiser l’infrastructure informatique ? En fait, l’automatisation n’est pas la meilleure solution uniquement pour l’infrastructure informatique, mais pour de nombreuses choses dans le développement de logiciels. Et pourquoi?
Les processus manuels sont lents, très vulnérables aux défaillances humaines, non évolutifs, difficiles à créer, à mettre à jour et à maintenir une norme, etc. Je pourrais citer de nombreuses autres raisons pour lesquelles quiconque s’éloigne de tout processus manuel. C’est le contraire qui est proposé dans les méthodologies agiles ou la culture DevOps. En ce qui concerne maintenant spécifiquement l’infrastructure, nous pouvons affirmer que sans automatisation, il est impossible d’obtenir le meilleur des ressources de n’importe quel service Cloud. Nous pouvons voir le pourquoi dans les lignes suivantes.
Peu importe à quel point les sociétés de cloud et d’hébergement tentent d’améliorer la convivialité de leurs consoles Web, il sera toujours très difficile de se souvenir de chaque action effectuée pour créer une infrastructure complexe, puis de la répliquer ou de la modifier. N’attendez pas un jour catastrophique pour commencer à faire ce qui est juste.
La fusion des outils, des techniques et des pratiques peut permettre aux entreprises d’avoir une culture technologique mature qui les rend plus compétitives. L’infrastructure fournit une optimisation des coûts à la demande, analyse la sécurité, les meilleures pratiques, les tests fonctionnels, le code source versionné et tout ce qui est nécessaire. Il n’y a plus d’excuses pour maintenir les processus lents et susceptibles d’erreurs.
Il n’est pas plus difficile d’écrire du code déclaratif que de naviguer entre de nombreuses pages et de devoir se souvenir de chaque étape lorsqu’il est nécessaire de le refaire. C’est le chaos. J’ai préparé quelques exemples d’automatisation à l’aide de Terraform, Docker, Ansible et Jenkins pour créer des ressources dans AWS. Ce n’est qu’un exemple. J’ai laissé tout le code source dans Github et vous pouvez vous en inspirer pour faire des choses avec d’autres outils et dans d’autres clouds de plate-forme comme GCP, Azure et autres. Au lieu de Jenkins, il pourrait s’agir de sa propre application, spécifique à ce travail et avec une meilleure convivialité. Vous pouvez évoluer vers des solutions beaucoup plus robustes en utilisant l’intelligence artificielle, la surveillance et d’autres choses.
Pour cette démonstration, j’ai commencé à créer des scripts à l’aide de Terraform pour le provisionnement de ressources sur AWS : EC2, S3, EKL et autres, mais je ne voudrais pas avoir à l’exécuter manuellement à chaque fois que j’ai besoin de provisionner une nouvelle ressource, J’ai donc créé des emplois sur Jenkins. Mon objectif est de n’avoir qu’à appuyer sur un bouton pour provisionner une nouvelle infrastructure.
Téléchargez l’exemple de code ici.
Pour exécuter cette démo, les exigences sont les suivantes : Docker installé, un compartiment S3 pour enregistrer les états de Terraform, une paire de clés pour se connecter à l’instance EC2 et créer un utilisateur avec une clé d’accès et une clé d’accès secrète. Dans cet autre article, j’enseigne comment créer ces clés.
Dans tous les scripts Terraform, j’ai cet extrait de code indiquant où enregistrer les états.
backend "s3" {
bucket = "tutorial-automation-with-jenkins"
key = "ec2/ec2"
region = "us-east-1"
}Avec les scripts prêts, j’exécute la commande Docker suivante pour créer le volume qui conservera les données du Jenkins.
docker volume create jenkins-volExécutons maintenant la commande pour démarrer le Jenkins.
docker container run -d -p 8080:8080 -v jenkins-vol:/var/jenkins_home --name jenkins-lab jenkins/jenkins:lts
Dans ce Jenkins, j’ai créé cinq emplois pour automatiser la création de certaines ressources d’infrastructure sur AWS. Les ressources étaient ec2, s3, un cluster EKS, une installation WordPress et un cmd pour que je puisse voir les dossiers Jenkins au cas où j’en aurais besoin. Vous pouvez vous sentir à l’aise pour collaborer en ajoutant de nouvelles ressources.
La figure suivante résume tout ce qui a été fait dans cet exemple.
Évidemment, ce n’est qu’un point de départ. Nous pouvons faire évoluer ce modèle en ajoutant d’autres outils, en séparant les responsabilités et en rendant le projet plus mature.
Chaque travail que j’ai créé n’a qu’un seul paramètre : créer ou détruire, mais ils pourraient être complètement paramétrables. Uniquement dans le job demo-web-app que j’installe WordPress à l’aide d’Ansible, je passe l’IP publique générée par le job aws-ec2 en paramètre. Ces deux métiers pourraient-ils n’en faire qu’un ? Oui. Vous pouvez le faire évoluer !
Toutes les informations d’identification ont été enregistrées dans les informations d’identification Jenkins. Rien dans les dépôts. Le fichier tutorial.pem est généré dynamiquement et la valeur est obtenue lors de la construction. Lorsque nous exécutons l’une de ces tâches, nous avons en quelques minutes une infrastructure complexe entièrement prête grâce à une action simple. Si nous devons répéter cela dix fois de plus, la simplicité sera la même.
PLAY RECAP *********************************************************************
54.167.124.23 : ok=16 changed=14 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
[Pipeline] }
[Pipeline] // withCredentials
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
Finished: SUCCESSCela peut sembler un vieil argument, mais il existe encore de nombreuses entreprises et administrateurs système qui, tout en se rendant au cloud, essaient toujours de l’utiliser comme un ancien système d’infrastructure. Sans connaître ses principaux avantages et sans en profiter pleinement.
Si quelqu’un a des connaissances sur AWS ou d’autres serveurs Cloud, a consulté l’exemple de code dans cet article et n’a toujours pas travaillé avec l’infra as code, vous avez réalisé à quel point cela facilite la vie. Je vous invite à dupliquer cet exemple de code ou à collaborer avec celui-ci, y compris d’autres plateformes et d’autres ressources.