Où dois-je commencer à apprendre DevOps?

Rechercher «comment commencer avec les devops» n'a pas vraiment aidé car, beaucoup d'entre eux aiment ça et cela ainsi que beaucoup d'autres ne me pointent pas vraiment dans le bon sens. Chaque vidéo youtube que j'ai vue jusqu'à présent n'a pas aidé non plus (car je n'ai pas besoin de vidéos m'expliquant ce que IS développe), cette vidéo étant la seule vraie exception jusqu'à présent (qui montre comment les choses s'intègrent les unes aux autres).

Je suis un CCNA et également très compétent avec les SGBD (j'apprends actuellement l'exécution du parallélisme ainsi que d'autres choses).

Mais je n'ai aucune idée de ce que je suis censé apprendre en premier (ou où trouver les bonnes ressources d'ailleurs).

Je suis sur le point d'obtenir mon diplôme, je n'ai donc pas accès à une expérience du monde réel.

Des conseils ou de l'aide?

Les devops concernent l'exécution de logiciels. Il s'agit de savoir comment exécuter une application ou un service. Les outils de configuration du serveur, les machines virtuelles et les conteneurs sont donc les prochaines étapes. Je suggère de regarder la documentation de ces outils et d'apprendre d'eux des choses comme la découverte, l'observabilité, l'évolutivité et la redondance. Pour ne citer que quelques exemples:

Configuration du serveur:

• PXE
• Ansible
• Fantoche

VM:

• Vagabond
• QEMU

Récipient:

• Docker
• Kubernetes

EDIT: Présentation des technologies cloud:

• Paysage CNCF

Lorsque votre architecture logicielle concerne les microservices, les conteneurs sont un bon choix. Lorsque vous utilisez d'anciennes applications monolithiques, les machines virtuelles ne sont pas une mauvaise option. Cela dépend donc toujours du contexte de ce que vous devez apprendre spécifiquement. Le sujet est assez large pour le résumer. Un livre pourrait aider à cela, mais malheureusement, je ne peux pas suggérer un bon large. "Kubernetes in Action" vous donne cependant un bon début dans Kubernetes.

Tout d'abord, je voudrais souligner que DevOps est une culture et non un rôle. À mon avis, on pourrait le comparer avec une équipe de commandos qui ont leur propre expertise, par exemple sniper, marine, sapeur (pensez à la série des commandos). La combinaison de ces expertises, travaillant essentiellement ensemble, permet d'accomplir des missions ou de créer de la valeur commerciale dans les meilleurs délais.

LowOps et NoOps

Depuis quelques semaines, j'ai trouvé qu'après beaucoup de conversations avec des gens, c'était plutôt parler de LowOps de nos jours. Si j'implémente une solution, cela signifie qu'elle est complètement automatisée et qu'un collègue peut déployer des machines lui-même plutôt que de me le demander. Parfois, il n'est pas immédiatement possible de l'automatiser complètement, mais ensuite je m'assure qu'il est automatisé pour moi-même pour m'assurer que je n'ai qu'à exécuter une seule commande afin de faire le travail (LowOps), au lieu de perdre quelques heures. Si j'ai créé une telle solution, je m'assure qu'un ticket a été créé pour un collègue afin d'automatiser ma solution personnelle pour tout le monde. Exemple: un de mes collègues a transformé l'un de mes scripts bash en un robot qu'il exécute désormais tous les soirs.

Figure 1: https://www.gslab.com/blog-post/what-is-noops/

"comment commencer avec les devops"

Assurez-vous que vous faites partie d'une équipe aux compétences mixtes et que l'équipe doit déployer le logiciel elle-même. Parlez avec tous les membres de l'équipe et commencez avec des tâches que personne ne veut faire car il y a un manque de connaissances ou de volonté. Si vous commencez par une tâche, vous tomberez sur des choses que vous ne savez pas. Commencez à regarder des vidéos, assistez à des rencontres , achetez et lisez des livres, lisez des blogs et de la documentation officielle sur l'outillage, demandez à vos collègues d'examiner vos demandes de tirage et de communiquer et d'écouter bien les gens, de bien documenter les choses et de préparer et de démontrer des solutions aux collègues (partage des connaissances) . La dernière suggestion est de garder un œil sur l' équilibre travail-vie .

D'autres réponses ici se sont concentrées sur les outils. À mon avis, acquérir des compétences dans une boîte à outils est bien sûr une bonne chose, mais ne vous fera pas un bon ajustement dans une culture DevOps. DevOps est d'abord un ensemble de pratiques ou de méthodes .

Comprendre pourquoi ces pratiques et méthodes sont utiles vient avec l'expérience, mais vous n'avez pas ce luxe. Je vous signale donc

• la boîte à main DevOps
• Accélérer

comme un texte fondateur.

Le site Web de livraison continue dispose également d'un ensemble de principes et de bases qui vous fournissent les bases pertinentes lors du démarrage.

À partir de ceux-ci, vous apprendrez des pratiques et des méthodes qui vous informeront sur la façon dont vous collaborez et utilisez les outils.

Tout ce que vous devez apprendre est Linux, Docker, Networking, Git, Jenkins etc. Vous pouvez les apprendre de manière interactive ici

Si vous recherchez des didacticiels vidéo, pluralsight a quelque chose de bon pour vous.

C'est le genre de question que je me pose plusieurs fois, et qui a tendance à me suivre (maintenant que je suis à peine sorti du "débutant", je me demande où apprendre des sujets plus avancés). Malheureusement, comme vous l'avez souligné, poser ces questions sur les moteurs de recherche a tendance à affluer avec des sites Web ciblant les cadres et essayant d'expliquer Qu'est-ce que les devops? et pourquoi devrions-nous industrialiser le cycle logiciel avec des devops?

Cela dit, pour essayer de répondre à votre question, je ne peux parler que par expérience personnelle: j'ai commencé mon parcours d'apprentissage avec l'excellent guide de démarrage Docker .

"Apprendre DevOps" me semble être une requête trop large, comme vous l'avez également découvert, mais je me souviens avoir dû google la même chose.

Pour ajouter à la réponse de @ jhamfler: demandez-vous pourquoi voulez-vous en savoir plus? De quel contexte venez-vous? DevOps a généralement à voir avec la suppression des obstacles manuels, ou également des structures de silo dans les équipes (chacun fait juste sa propre tâche et s'appuie sur quelqu'un d'autre pour penser à intégrer les résultats). Y a-t-il de telles «lacunes» dans votre projet (je suppose que vous en avez une)? Quelles parties de celui-ci pourraient bénéficier de l'automatisation?

Les problèmes typiques que je pourrais suggérer sont:

• maintenance manuelle du serveur VS solutions scriptées
• fiabilité et sauvegardes
• automatiser les tests d'intégration
• automatiser le déploiement continu (par exemple d'un service Web)
• ...

Peut-être qu'une recherche de «déploiement continu» et «intégration continue» (CI / CD) pourrait également vous aider.

Les toutes premières choses que vous devez apprendre et vous familiariser avec:

• unix (système de fichiers, permissions, processus, services, logs, mise en réseau, etc…)
• tunneling ssh & reverse
• nano / vim
• python
• git

Ensuite, vous pouvez passer à des sujets plus spécifiques:

• conteneurisation (par exemple docker)
• gestion de la configuration (par exemple ansible)
• déploiement continu (par exemple jenkins)
• surveillance (p. ex. prometheus / grafana)