In­fra­struc­ture as Code : L’IAC avec Ter­ra­form

In­fra­struc­ture as Code

L'Informaticien - - SOMMAIRE -

L’in­fra­struc­ture as Code, ou IAC, est en pleine ex­pan­sion. Rien d’éton­nant à ce­la au vu des avan­tages qu’elle peut ap­por­ter en termes d’ins­tal­la­tion et de dé­ploie­ment. Les Devops en savent quelque chose. Nous al­lons voir ce que pro­pose Ter­ra­form, l’un des prin­ci­paux ou­tils IAC du mo­ment.

L’In­fra­struc­ture As Code est une ap­proche d’au­to­ma­ti­sa­tion de l’in­fra­struc­ture ba­sée sur des – bonnes – pra­tiques de dé­ve­lop­pe­ment. Elle consiste no­tam­ment à dé­fi­nir l’in­fra­struc­ture – la confi­gu­ra­tion sys­tème – sous forme de code, à tes­ter le code en conti­nu, à ver­sion­ner le­dit code en uti­li­sant un con­trô­leur de code source ( Git ou autre), à éli­mi­ner toute in­ter­ven­tion manuelle et sur­tout à être ca­pable de dé­truire ou re­cons­truire ra­pi­de­ment l’in­fra­struc­ture, à la de­mande. Ce­la re­vient un peu – ce qui peut pa­raître sur­pre­nant de prime abord – à faire tra­vailler son équipe de pro­duc­tion comme des dé­ve­lop­peurs.

C’est la vague Devops qui a ame­né dans son sillage L’IAC, une ten­dance de fond qui amène à re­pen­ser la pro­duc­tion IT dans son en­semble. Celle- ci ap­porte son lot de nou­veaux ou­tils dé­diés à l’au­to­ma­ti­sa­tion et au pi­lo­tage des ser­veurs et autres com­po­sants via des API. L’in­fra­struc­ture

as Code consiste de fait à pro­gram­mer l’en­semble des opé­ra­tions liées au dé­ploie­ment, à l’évo­lu­tion ou à la main­te­nance des en­vi­ron­ne­ments dans les­quels les ap­pli­ca­tions se­ront exé­cu­tées. L’ob­jec­tif re­cher­ché consiste à dé­crire dans son en­semble l’in­fra­struc­ture ( sys­tèmes, ma­chines vir­tuelles, ser­vices dé­ployés) pour en­suite pi­lo­ter son fonc­tion­ne­ment et ses évo­lu­tions di­rec­te­ment via des scripts. Dans un en­vi­ron­ne­ment de pro­duc­tion IT tra­di­tion­nel, la pra­tique consiste à d’abord éva­luer les res­sources né­ces­saires, en­suite de choi­sir l’ar­chi­tec­ture, puis de pro­vi­sion­ner les res­sources, de pa­ra­mé­trer l’en­vi­ron­ne­ment d’exé­cu­tion, de créer ses ser­vices et, en­fin, de dé­ployer l’ap­pli­ca­tion. Lorsque cer­tains élé­ments posent pro­blème, un roll­back laisse le temps de cor­ri­ger le tir avant de re­dé­ployer. À l’heure de l’agile et du Devops, il est né­ces­saire de faire mieux que ce­la, et c’est jus­te­ment le cas grâce à L’IAC.

In­fra­struc­ture as Code avec Ter­ra­form

Plu­sieurs ou­tils sont dis­po­nibles avec, pour cha­cun, des avan­tages et des in­con­vé­nients. Ter­ra­form semble être un des plus in­té­res­sants à tous points de vue. C’est un ou­til open source écrit en Go par Ha­shi­corp en 2014, la so­cié­té édi­trice de Consul, At­las, Pa­cker, Va­grant, Vault et autres No­mad. L’ap­proche em­ployée par le lo­gi­ciel consiste à dé­fi­nir, mo­di­fier et ver­sion­ner une in­fra­struc­ture, de ma­nière hé­té­ro­gène et ce in­dé­pen­dam­ment des dif­fé­rents four­nis­seurs de sys­tèmes vir­tua­li­sés tels que Vm­ware, Mi­cro­soft Azure ou autres Ama­zon Web Ser­vice. Son ar­chi­tec­ture est com­po­sée d’un mo­teur cen­tral et de points d’ex­ten­sion. Le mo­teur cen­tral gère l’in­ter­face CLI et les points d’ex­ten­sions per­mettent l’im­plé­men­ta­tion de connec­teurs pour les dif­fé­rents four­nis­seurs. Il existe aus­si des connec­teurs tels que F5, Mon­godb ou Re­dis ain­si que des or­ches­tra­teurs tels que AKS ou GKE. Un simple fi­chier de confi­gu­ra­tion suf­fit à dé­fi­nir toutes les res­sources né­ces­saires à la créa­tion de l’in­fra­struc­ture. Ter­ra­form pro­pose éga­le­ment un mode plan – ap­pe­lé aus­si dry run ou what if – per­met­tant de lis­ter les mo­di­fi­ca­tions qui se­ront ef­fec­tuées mais sans les ap­pli­quer réel­le­ment. La com­mu­nau­té Ter­ra­form, très ac­tive, ras­semble plus de mille con­tri­bu­teurs. Ter­ra­form – ou TF pour les in­times – s’ap­puie sur une ar­chi­tec­ture ba­sée sur les plu­gins. Con­trai­re­ment à ce que vous au­riez pu lire sur In­ter­net, Ter­ra­form n’est pas une « plate- forme ag­nos­tic » , mais per­met au contraire d’uti­li­ser plu­sieurs pro­vi­ders dans un même tem­plate de confi­gu­ra­tion. Il existe des plu­gins

pour des pro­vi­ders de Cloud, de ser­vices d’hé­ber­ge­ment et tout ce qu’il est pos­sible d’em­ployer se­lon les be­soins.

Le lan­gage HCL

Les fi­chiers de confi­gu­ra­tion s’écrivent en HCL ( Ha­shi­corp Confi­gu­ra­tion Lan­guage). Le prin­cipe est d’écrire – de dé­crire plu­tôt – des res­sources. Ces res­sources peuvent aus­si être écrites en JSON, mais il est pré­fé­rable de le faire en HCL. Le HCL est un lan­gage « hu­man rea­dable » , donc a prio­ri as­sez simple à ap­pré­hen­der. Ter­ra­form scanne tous les fi­chiers se ter­mi­nant par . tf dans le ré­per­toire cou­rant, mais, at­ten­tion, il ne contrôle pas les ré­per­toires en­fants. Pla­cez donc bien ces fi­chiers de confi­gu­ra­tion di­rec­te­ment dans un seul ré­per­toire.

Pro­vi­der

Un pro­vi­der est res­pon­sable du cycle de vie ( ou CRUD) d’une res­source : sa créa­tion, sa lec­ture, sa mise à jour et sa sup­pres­sion. La liste des pro­vi­ders ac­tuel­le­ment sup­por­tés est plu­tôt longue : 1& 1, AWS, Azure, Bit­bu­cket, Consul, Chef, Cloud­flare, GCP, Do­cker, He­ro­ku, Ku­ber­netes, Git­lab, Gi­thub, Opens­tack, OVH, Post­gres­ql, Rab­bitmq, Dn­simple, Vault et j’en passe. Vous trou­ve­rez la liste ex­haus­tive de ces pro­vi­ders sur le site de TF : https:// www. ter­ra­form. io/ docs/ pro­vi­ders/ index. html. Rap­pe­lons que le terme CRUD, pour create, read, up­date, de­lete, par­fois ap­pe­lé SCRUD avec un S en plus pour search, dé­signe les quatre opé­ra­tions de base pour la per­sis­tance des don­nées, en par­ti­cu­lier le sto­ckage d’in­for­ma­tions dans une base de don­nées. Ce terme cor­res­pond aux quatre com­mandes : créer, lire, mo­di­fier et sup­pri­mer. Si par mal­heur vous ne trou­vez pas de pro­vi­der à votre goût, écri­vez votre propre plu­gin et par­ti­ci­per ain­si à l’éla­bo­ra­tion de nou­velles fonc­tion­na­li­tés pour Ter­ra­form. Il faut juste sa­voir co­der en Go.

Mo­dules

Les mo­dules sont uti­li­sés pour créer des com­po­sants réuti­li­sables, amé­lio­rer l’or­ga­ni­sa­tion et trai­ter les élé­ments de l’in­fra­struc­ture comme une boîte noire. Un mo­dule est un groupe de res­sources, les­quelles prennent en en­trée des pa­ra­mètres et re­tournent en sor­tie des out­puts, comme des fonc­tions en pro­gram­ma­tion.

Out­puts

Les out­puts servent à faire pas­ser des va­leurs d’un mo­dule à un autre. Ils sont éga­le­ment utiles pour af­fi­cher des in­for­ma­tions à la fin de l’ap­pli­ca­tion du ter­ra­form ap­ply.

Le site de TF ( https:// www. ter­ra­form. io/ docs/ pro­vi­ders/ index. html) donne la liste de tous les pro­vi­ders com­pa­tibles avec ter­ra­form.

Pour tout sa­voir sur cet ou­til et le té­lé­char­ger, ren­dez- vous sur le site de Ter­ra­form.

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.