013 — DevOps

[r3trofitted]

Il y a un monde au-delà de Heroku et des tutos DigitalOcean.

[jlecour]

Je suis partant pour cet épisode.

[celine-m-s]

Je ne sais pas beaucoup en devops mais le sujet m'intéresse beaucoup. Je pourrai faire des recherches en amont :)

[abelards]

Et de Scalingo, Clever Cloud et OVH #cocorico

Je pense qu'on part sur un épisode à préciser, car il va mélanger (ou se coller sur un seul sujet)

faire tourner une appli

• hébergement
• monitoring
• sécurité

déployer une appli

• déploiement
• tests / CI / CD / méthodos pour ça
• docker, instrumentation

coder une appli et travailler en équipe

• gestion d'équipe
• formation
• responsabilités

Pour moi "le devops" c'est

• assure-toi que tes développeurs connaissent un peu des 6 premiers
• assure-toi que tes ops/infra/sysadmin connaissent un peu des 3 derniers
• assure-toi que ces gens travaillent ensemble

Je propose de faire 1 à 3 épisodes selon les intervenants qu'on aura et les sujets qui vous tentent <3

[jlecour]

Wow, effectivement c'est vaste et passionnant.

Je ne suis pas bon en CI/CD, ni en Docker, mais pour le reste j'ai un peu ou beaucoup d'expérience selon.

[clairezed]

J'arrive sur cette issue après m'être questionnée sur twitter sur des problématiques d'hébergement ; j'en profite donc pour partager ici mes interrogations (ça donnera peut-être du grain à moudre pour cet épisode ?).

Je suis toute jeune freelance après avoir bossé 3 ans en agence, où j'avais intégré certaines procédures qui étaient bien cadrées. Deux options dans l'agence : soit heroku, soit hébergement maison (passenger + nginx) sur serveur dédié (vraiment dédié, ou gros serveurs contenants plusieurs projets, tous en rails). Si j'ai déjà fait la config et/ou l'install avec ces deux options, ce n'est jamais moi qui choisissais le serveur ni qui gérais tout ce qui était nom de domaine, dns, certificats...

En me retrouvant à mon compte, je suis confrontée à plein de questions que j'avais jamais eu à me poser jusqu'ici. Ces questions sont pas forcément hyper poussées, mais j'ai du mal à trouver des réponses ou des échanges clairs sur ces sujets :

• Comment bien choisir son hébergement ? Pourquoi plutôt partir sur un VPS ou un dédié ? Quels sont les critères déterminants ?
• Comment estimer la puissance / l'espace nécessaire ? Non seulement pour une appli, mais aussi pour une batterie d'appli sur un même serveur ?
• Comment gérer la demande d'un client qui te demande de reprendre l'hébergement d'un de ces sites historiques codé avec un framework fait main en php, et qui aimerait avoir une solution pour héberger aussi ses futurs projets (dont un site en rails que tu es en train de développer) ?
• Quelles solutions quand ton client prévoit pas mal d'uploads (fichiers pdf, images, .doc... tout sauf video, en gros), mais dit ne pas vouloir entendre parler d'Amazon pour des raisons éthiques ?
• Plus largement, avez-vous été confronté à des clients qui veulent à tout prix des solutions éthiques et / ou françaises ? Quelles solutions leur proposez-vous ? (j'ai l'impression que 75% au moins des ressources pour l'upload de fichiers propose S3, 10% parlent de google, et après ça devient compliqué, par exemple)
• Comment estimer un tarif de maintenance, et quoi prendre en compte là-dedans ?
• maintenant que je n'ai plus le gitlab + CI de l'agence, quelle solution pas trop complexe ni onéreuse ai-je à disposition pour le CI ?
• quelles sont les bonnes ressources, fr ou en, pour apprendre petit à petit dans ce domaine, sans se retrouver direct à faire de la tachychardie devant des tutos hyper techniques auxquels on ne comprend rien ?

Le tout, en intégrant des problématiques financières (quand tu es plutôt développeur-se, c'est peut-être plus simple pour toi de passer par heroku, mais tes petits clients avec des petits moyens vont grincer des dents) et de compétences (c'est sur ma liste de me pencher sur docker, mais là je n'ai clairement pas encore le niveau). Quelles sont les meilleures solutions, du coup, en croisant comme critères coût / complexité / bonne pratique (solidiaté, scalabilité / sécurité), et en poussant le curseur vers un pôle ou l'autre ?

Et pouf, un pavé :) (désolée) En tout cas, oui, la question m'intéresse sacrément !

[r3trofitted]

Ce sont d'excellentes questions, mais là, on élargit vraiment beaucoup le sujet. J'ai l'impression qu'on a de quoi faire au moins trois épisodes disincts : l'hébergement, le CI et les pratiques associées, et le dev ops (automatisation de l'infrastructure) proprement dit.

[abelards]

Et la sécurité/monitoring, les outils d'infrastructure, les équipes... Qui est chaud pour proposer un découpage ? Ensuite les invité-e-s et habitué-e-s choisissent la priorisation et on est bons pour enregistrer :D

On 11 Mar 2017 15:41, "Ronan Limon Duparcmeur" notifications@github.com wrote:

Ce sont d'excellentes questions, mais là, on élargit vraiment beaucoup le sujet. J'ai l'impression qu'on a de quoi faire au moins trois épisodes disincts : l'hébergement, le CI et les pratiques associées, et le dev ops (automatisation de l'infrastructure) proprement dit.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LeRubyNouveau/liste-de-souhaits/issues/3#issuecomment-285870751, or mute the thread https://github.com/notifications/unsubscribe-auth/AAjrmENVknx_bKLzf4vmsT5LMIMl5E4Pks5rkrKkgaJpZM4MAdhW .

[jlecour]

Il y a aussi une approche plus "feeling" qui peut plaire ou pas.

On fait un épisode général sur "Mettre son projet en production" pour voir les sujets généraux qui remontent. On essaie de le diffuser assez rapidement pour avoir des retours de questions puis on organise et découpe des épisodes plus ciblés sur telle ou telle partie du sujet.

Mais je suis quand même partant si on veut découper d'emblée.

[jlecour]

J'essaie de voir les sous-parties qu'on pourrait avoir :

• comment anticiper la production dès le démarrage du projet + toutes les questions de @clairezed
• outils/processus/workflows facilitant la mise en prod régulière (voire la livraison continue)
• monitoring/debug/… d'une application en prod
• sécurité, backup, résilience, situations de crise, gestion de la croissance
• hébergement : cloud (Amazon, DigitalOcean…) vs. PAAS (Heroku…) vs. dédiés (presta spécialisé, interne…)
• DevOps/SRE (c'est quoi, en vrai ?) : outils/tech (Ansible, Docker…), découpage des équipes et responsabilités…

NB : j'ai volontairement pioché dans vos idées déjà citées, je ne m'attribue pas l'originalité de ce découpage 😉

[r3trofitted]

Mis à part qu'on a déjà abordé monitoring/debug, je dis : :shipit:

[jderrien]

:warning: J'ai un background de sysadmin donc plutôt côté Ops.

@clairezed Opérationnel, monitoring, backup, etc. ça peut être un job 24h/24 7j/7, selon le type de client que tu as. C'est peut-être bon de déléguer ça, et de ne pas avoir de serveur à gérer tout ça par toi même. Pour Docker, cette techno est une fausse bonne idée dans pas mal de cas (selon moi). Ça complexifie une grande partie de l'opérationnel. Plus d'inconvénients que de réels avantages, en particulier sur de petites infras/pour des petits projets.

---

Il pourrait être intéressant d'aborder la place de Ruby dans l'écosystème DevOps (ceci dit, je ne sais pas exactement de quelle manière).

Il y a pas mal d'outils qui gravitent autour du mouvement DevOps et qui sont écrits en Ruby. Je pense entre autre à Chef, Puppet, Vagrant, Capistrano. Ou des outils plutôt centrés sur le côté opérationnel comme Sensu, Riemann, The Foreman, Fluentd.

Ces projets sont assez anciens. J'ai l'impression que les gens autour du mouvement DevOps sont passés à d'autres langages que Ruby (notamment à Go, et pas mal de Python également).

À mon niveau, parmi tous ces outils, je n'en ai utilisé que très peu au final, donc pas de recul ou d'avis particulier.

Sinon d'un point de vue purement opérationnel, un autre ressenti, c'est qu'un sysadmin va plutôt privilégier Python pour des scripts. Ma principale hypothèse pour l'expliquer, c'est que Python est disponible par défaut sur la plupart des distributions Linux, et en plus, a la réputation d'être un langage facile à apprendre.

D'une manière générale, je trouve parfois que Rails occupe une trop grande place dans la communauté Ruby, au détriment du langage lui-même. C'est un peu dommage, car Ruby est très agréable à utiliser, que ce soit avec d'autres frameworks ou pour du scripting.

[r3trofitted]

👍👍👍

[alex-lairan]

Tu as aussi ManageIQ qui est sympa en Ruby, porté par RedHat.

Produit OpenSource 👍

Ruby est trop couplé avec Rails, c'est vrais, et bien dommage car pour avoir utilisé Thor, c'est vachement cool !

[begault]

Pour info http://nutanix-devops-tour.treeptik.fr/ Ca se tient le 20 avril à Paris (et à d'autres dates à Lille, Toulouse, Lyon et Nantes)