397 liens privés
L'auteur, Gruntwork, fournit par ailleurs un bon outil (wrapper) pour utiliser terraform: https://github.com/gruntwork-io/terragrunt
I gave that talk at the 2016 Sysadmin Days to explain how I work when taking over a new infrastructure.
Citation tirée du bouquin:
A "cowboy culture" where seemingly "nimble" behavior has promoted destructive side effects. The sense of agility is all too often a delusion.
en relation avec: https://jeekajoo.eu/links/?SB0_uQ
Résumé complet du livre: http://www.wikisummaries.org/Visible_Ops
"""
“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.
"""
twitch for devops
Une présentation culte qui parle des postes de "DevOp" en entreprise.
Même si je pense qu'un poste de "DevOp" ça n'a pas de sens (https://jeekajoo.eu/links/?hD9S7Q) du point de vue de mon xp actuelle, l'auteur pense le contraire et explique le rôle que doit avoir ce DevOp.
"""
Slide 73: ownership over the TOOLS to improve DevOps efforts.
"""
On ne parle pas de l'infra ici dont la responsabilité est laissée aux sysadmins.
Bonne approche.
Haha, j'aurais été tenté de répondre comme toi, Kevin (http://www.mypersonnaldata.eu/shaarli/?oBPM7A), mais en fait non. Je vais argumenter.
Le sysadmin code aussi, mais il ne fait pas que ça.
Il code car il doit créer l'infrastructure qu'il souhaite la plus jetable possible. Le but c'est d'être capable de recréer toute l'infrastructure from scratch depuis son code. C'est ce qu'on appele l'infrastructure as code. TOUT est code, de la taille des machines à leur nombre de disque en passant par les règles firewall et les membres d'un loadbalancer. Cette infra est le plus souvent écrite dans un DSL propre au logiciel de gestion de configuration utilisé.
Pour Saltstack, c'est majoritairement du yaml qui décrit l'état des services (states). On retrouve du jinja pour la partie templating et pour ajouter un peu de logique dans les states. On peut également avoir besoin de faire du python pour développer des modules spécifiques.
Enfin de manière générale, on utilise beaucoup python et bash pour l'administration, le monitoring ou pour des tâches lancées via cron sur les serveurs.
Le problème c'est que peu de monde comprend le métier de sysadmin (ou Ops comme ils disent aux states). Mêmes certains devs ignorent ce qu'on fait au jour le jour. Est-ce qu'on peut dire que ce sont de mauvais dev? Peut-être mais la direction d'une entreprise a d'abord un vrai rôle à jouer pour que tout ce petit monde coopère et puisse bosser ensemble.
La réalité c'est que le métier de sysadmin n'est pas mis en valeur car leur produit, l'infrastructure, n'est pas directement "visible". On ne pense aux sysadmins que quand le service tombe ou quand celui-ci est lent. Et c'est justement tout l'enjeu de notre métier que cela ne se produise jamais.
On parle de "DevOps"[1] pour justement améliorer la communication entre les équipes, qu'on arrête de considérer les sysadmins comme des larbins et pour que la communication se fasse dans les 2 sens. Car les sysadmins sont avant tout des architectes. Des architectes ayant l'expérience de la montée en charge, de savoir quel RDBMS il est préférable d'utiliser plutôt qu'un autre, de connaître le comportement d'un redis en production, de savoir sur quels axes on pourrait améliorer les performances d'une application, etc.. Bref, au même titre que les developpeurs, les sysadmins doivent être impliqués le plus tôt possible dans les choix techniques.
[1] Le problème de ce mot "DevOps", c'est qu'il est galvaudé. Certains chasseurs de tête l'utilisent pour désigner des titres de poste alors qu'il ne s'agit que d'un état d'esprit. Un état d'esprit visant à dire que moi developpeur je ne connais pas tout ; alors je vais aller poser des questions aux sysadmins. Et inversement.
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
Gov.uk : “L’important n’est pas d’innover, mais de faire que les choses marchent” « InternetActu.net
en complément, voir aussi cette vidéo https://vimeo.com/album/2384821/video/66622266 prise lors des devopsdays paris 2013 qui montre comment ils releasent.
présentation basée sur le bouquin 'The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps'
cette méthodologie tente de permettre aux ops de travailler sur ce qu'ils voudraient travailler (conception, architecture, écriture de code infra) plutôt que de passer leur temps à fixer des trucs.
"""
4 visible ops phases
- stabilize the patient
- catch & release and find fragile artifacts
- establish repeatable build library
- enable continuous improvement
"""
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.
On y parlera de saltstack, mais pas que. Par ex, Nicolas Ledez parlera de Chef, entres autres présentations. Même si vous n'avez touché à salt vous apprendrez plein de trucs et vous pourrez apporter votre pierre à l'édifice de discussions ouvertes sur les différents outils pour "faire du devops". Ça aura lieu dans les locaux de Mozilla ou ceux de l'IRILL.
PS: moi je viens surtout pour les pizzas gratuites mais ça, ça reste entre nous. je déconne ;)
je cite mon collègue binôme:
"""
Je vous laisse découvrir cet article intéressant sur le devops, et dans quels cas ça ne fonctionne pas correctement.
En particulier, une interrogation légitime, je cite : "How does the ops team, historically the one responsible for uptime in the production environment, permit or expand access to environments they support? How can they avoid being the bottleneck at the tail end of every application team’s project cycle? How does the business remove the friction but not invite chaos, outages and lack of compliance?"
Et des tentatives de réponse dans l'article, qui soulève, à mon sens, les bons problèmes.
"""
Podcast devops.
Cet épisode est sur la livraison continue.