Marathon<\/a><\/noindex>\u00a0<\/li>\n<\/ul>\n<\/p>\n
7. Infrastructure comme code (IaC)<\/h2>\n
<\/p>\n
Br\u00e8ve description de la technologie<\/h3>\n
\n Et nous sommes arriv\u00e9s \u00e0 la derni\u00e8re section. Habituellement, cette technologie et les t\u00e2ches qui y sont li\u00e9es ne rel\u00e8vent pas de la responsabilit\u00e9 des ing\u00e9nieurs en automatisation. Et il y a de bonnes raisons pour cela. Tout d'abord, dans de nombreuses organisations, les questions d'infrastructure sont sous le contr\u00f4le du d\u00e9partement DevOps et l'\u00e9quipe de d\u00e9veloppement ne se soucie pas vraiment de la mani\u00e8re dont fonctionne le pipeline et de la fa\u00e7on dont il faut maintenir tout ce qui y est associ\u00e9. Deuxi\u00e8mement, soyons honn\u00eates, la pratique \u00ab Infrastructure comme code (IaC) \u00bb n'est pas encore appliqu\u00e9e dans de nombreuses entreprises. Mais cela reste d\u00e9finitivement une tendance populaire et il est important d'essayer d'\u00eatre impliqu\u00e9 dans les processus, approches et outils qui y sont li\u00e9s. Ou, au moins, de rester inform\u00e9 des \u00e9v\u00e9nements.<\/p>\n
Commen\u00e7ons par la motivation d'utiliser cette approche. Nous avons d\u00e9j\u00e0 discut\u00e9 qu'il nous fallait, pour ex\u00e9cuter des tests dans GitlabCI, au moins des ressources pour lancer Gitlab Runner. Et pour d\u00e9marrer des conteneurs avec des navigateurs\/\u00e9mulateurs, nous devons r\u00e9server une VM ou un cluster. En plus des ressources pour les tests, nous avons besoin d'une puissance significative pour maintenir les environnements de d\u00e9veloppement, de staging et de production, ce qui inclut \u00e9galement des bases de donn\u00e9es, des programmes automatiques, des configurations r\u00e9seau, un \u00e9quilibre de charge, des droits d'utilisateur, et ainsi de suite. Le principal probl\u00e8me r\u00e9side dans les efforts n\u00e9cessaires pour soutenir tout cela. Il existe plusieurs m\u00e9thodes par lesquelles nous pouvons apporter des modifications et d\u00e9ployer des mises \u00e0 jour. Par exemple, dans le contexte de GCP, nous pouvons utiliser la console UI dans le navigateur et effectuer toutes les actions en cliquant sur des boutons. Un autre moyen pourrait \u00eatre d'utiliser des appels API pour interagir avec des entit\u00e9s cloud ou d'utiliser l'outil en ligne de commande gcloud pour effectuer les manipulations n\u00e9cessaires. Mais avec un grand nombre d'entit\u00e9s et d'\u00e9l\u00e9ments d'infrastructure, il devient difficile, voire impossible, d'effectuer toutes les op\u00e9rations manuellement. De plus, toutes ces actions manuelles ne sont pas contr\u00f4l\u00e9es. Nous ne pouvons pas les soumettre \u00e0 une revue avant l'ex\u00e9cution, utiliser un syst\u00e8me de contr\u00f4le de version et revenir rapidement sur des modifications qui ont conduit \u00e0 un incident. Pour r\u00e9soudre ces probl\u00e8mes, les ing\u00e9nieurs ont cr\u00e9\u00e9 et continuent de cr\u00e9er des scripts bash\/shell automatiques, ce qui n'est gu\u00e8re mieux que les m\u00e9thodes pr\u00e9c\u00e9dentes, car il est assez difficile de les lire rapidement, de les comprendre, de les maintenir et de les modifier dans un style proc\u00e9dural.<\/p>\n
Dans cet article et ce guide pratique, j'utilise deux outils li\u00e9s \u00e0 la pratique de l'IaC. Ce sont Terraform et Ansible. Certains estiment qu'il n'est pas utile de les utiliser simultan\u00e9ment, car leurs fonctionnalit\u00e9s sont similaires et elles sont interchangeables. Cependant, la r\u00e9alit\u00e9 est qu'ils sont con\u00e7us pour r\u00e9pondre \u00e0 des t\u00e2ches totalement diff\u00e9rentes. Le fait que ces outils doivent se compl\u00e9ter a \u00e9t\u00e9 confirm\u00e9 lors d'une pr\u00e9sentation conjointe par des d\u00e9veloppeurs repr\u00e9sentant les entreprises HashiCorp et RedHat. La diff\u00e9rence conceptuelle r\u00e9side dans le fait que Terraform est un outil de provisioning pour g\u00e9rer les serveurs eux-m\u00eames. Pendant que Ansible est un outil de gestion de configurations, dont la t\u00e2che est d'installer, configurer et g\u00e9rer le logiciel sur ces serveurs.<\/p>\n
Une autre caract\u00e9ristique cl\u00e9 qui distingue ces outils est le style d\u2019\u00e9criture du code. Contrairement \u00e0 bash et Ansible, Terraform utilise un style d\u00e9claratif, bas\u00e9 sur la description de l'\u00e9tat final souhait\u00e9 qui doit \u00eatre atteint \u00e0 l\u2019issue de l'ex\u00e9cution. Par exemple, si l\u2019on souhaite cr\u00e9er 10 VMs et appliquer des modifications via Terraform, nous obtiendrons 10 VMs. Si le script est r\u00e9appliqu\u00e9, rien ne se produira, car nous avons d\u00e9j\u00e0 10 VMs, et Terraform en a connaissance, car il conserve l'\u00e9tat actuel de l'infrastructure dans un fichier d'\u00e9tat. En revanche, Ansible utilise une approche proc\u00e9durale et, si on lui demande de cr\u00e9er 10 VMs, lors de la premi\u00e8re ex\u00e9cution nous obtiendrons 10 VMs, tout comme avec Terraform. Mais apr\u00e8s une nouvelle ex\u00e9cution, nous aurons d\u00e9j\u00e0 20 VMs. C'est l\u00e0 qu'est la diff\u00e9rence importante. Dans le style proc\u00e9dural, nous ne conservons pas l'\u00e9tat actuel et d\u00e9crivons simplement la s\u00e9quence des \u00e9tapes \u00e0 r\u00e9aliser. Bien s\u00fbr, nous pouvons g\u00e9rer diff\u00e9rentes situations, ajouter plusieurs v\u00e9rifications sur l'existence des ressources et de l'\u00e9tat actuel, mais il est inutile de perdre notre temps et de faire des efforts pour contr\u00f4ler cette logique. De plus, cela augmente le risque d'erreurs.\u00a0<\/p>\n
Pour r\u00e9sumer tout ce qui pr\u00e9c\u00e8de, on peut conclure que pour le provisioning de serveurs, l'outil le mieux adapt\u00e9 est Terraform avec une notation d\u00e9clarative. Tandis que la gestion des configurations est mieux d\u00e9l\u00e9gu\u00e9e \u00e0 Ansible. Cela \u00e9tant clair, examinons des exemples d'utilisation dans le contexte de l'automatisation.<\/p>\n
Valeur pour l'infrastructure d'automatisation<\/h3>\n
\n Il est important de comprendre que l'infrastructure d'automatisation des tests doit \u00eatre consid\u00e9r\u00e9e comme une partie de l'ensemble de l'infrastructure de l'entreprise. Cela signifie que toutes les pratiques IaC doivent \u00eatre appliqu\u00e9es de mani\u00e8re globale aux ressources de l'ensemble de l'organisation. La responsabilit\u00e9 de cela d\u00e9pend de vos processus. L'\u00e9quipe DevOps a plus d'exp\u00e9rience sur ces questions, elle voit l'ensemble du tableau. Cependant, les ing\u00e9nieurs QA sont plus impliqu\u00e9s dans le processus de construction de l'automatisation et la structure du pipeline, ce qui leur permet de mieux voir tous les changements n\u00e9cessaires et les possibilit\u00e9s d'am\u00e9lioration. Le meilleur choix est de travailler ensemble, d'\u00e9changer des connaissances et des id\u00e9es pour atteindre le r\u00e9sultat attendu.\u00a0<\/p>\n
Voici quelques exemples d'utilisation de Terraform et d'Ansible dans le contexte de l'automatisation des tests et des outils que nous avons discut\u00e9s pr\u00e9c\u00e9demment :<\/p>\n
1. D\u00e9crire via Terraform les caract\u00e9ristiques et param\u00e8tres n\u00e9cessaires des VMs et des clusters.<\/p>\n
2. Installer avec Ansible les outils n\u00e9cessaires pour les tests : docker, Selenoid, Selenium Grid et charger les versions n\u00e9cessaires des navigateurs\/\u00e9mulateurs.<\/p>\n
3. D\u00e9crire via Terraform les caract\u00e9ristiques de la VM sur laquelle le GitLab Runner sera ex\u00e9cut\u00e9.<\/p>\n
4. Installer avec Ansible GitLab Runner et les outils associ\u00e9s n\u00e9cessaires, d\u00e9finir les param\u00e8tres et configurations.<\/p>\n
Illustration de l'\u00e9tat actuel de l'infrastructure<\/h3>\n
\n![\"Les](\"\/wp-content\/uploads\/2020\/04\/5d793a800a4ef62e181e6cb3a3f0544e.png\")
<\/p>\n
Liens pour \u00e9tude :<\/h3>\n
<\/p>\n