397 liens privés
Faire de l'infra immutable sans docker.
On se force en plus à ne pas avoir ssh sur les instances pour se forcer à fonctionner avec des images (et réduire la surface d'attaque) : si on a besoin de faire une modif on trash l'instance et on switch sur une nouvelle qui est basée sur une autre version d'une image.
C'est bien joli mais pour fonctionner avec ces principes cela implique d'avoir un process bien bien carré pour faire ces images, comme la solution de l'auteur du billet en question.
Enfin pour débugguer, sans ssh c'est compliqué. Docker n'encourage pas non plus à mettre ssh dans les containers mais on peut l'avoir sur les machines qui les hébergent.
A creuser, concept néanmoins intéressant. Reste à trouver comment l'implémenter.
"""
“Infrastructure as a code” changes the administrator mindset. It makes them developers and requires from them programmatic skills. It perfectly matches the DevOps concept. Looking at it from the other side – taking care of infrastructure becomes interesting for developers and starts to no longer be considered as a necessary evil.
In the current tools and technology state implementing this approach takes quite a lot of time. Using it for small scale solutions and systems might (let me emphasise: might) not pay off. However, if you are managing several dozen configurations and machines you will notice the benefits quite fast. While implementing new changes might still take more time than in the old approach, full tracking, automation and gained stability will leverage the additional effort.
There will be less and less classical admins in the future. We have see this trend since many years ago. I also expect that “Infrastructure as a code” tools will go into direction when setup and usage will be so simple and user friendly that almost no one will consider configuring infrastructure without them.
"""
j'avais eu l'idée de ce site que j'aurais appelé 'watstack', afin de savoir quelle stack utilise telle société
bon bah... trop tard ^^
ce mec a une tête à claque, mais ce qu'il raconte est très intéressant,
particulièrement si vous faites de l'infrastructure as code
oui!
une code review engage à la discussion.
de l'"infrastructure as code" ne peut fonctionner que si il y a un minimum d'échange.
si chacun release dans son coin, on peut vite se retrouver à passer son temps à debugger des trucs et mettre en danger la production.
en particulier si le niveau d'automatisation et élevé (et que le code est complexe)
tout est lié, et la moindre bourde peut avoir des implications qu'on ne verra pas forcément dans l'immédiat.
les tests et surtout la communication permettent d'éviter ces bombes, de les désamorcer, voire de diminuer leur impact.