Aleksandr Surkov

Cet article est consacré à un problème courant rencontré lors de l'automatisation d'infrastructure avec Azure DevOps, connu sous le nom de "second hop". Nous verrons pourquoi ce problème survient et comment le résoudre efficacement pour garantir une intégration fluide et une automatisation complète.

Travailler avec des machines virtuelles Linux dans Azure via Azure DevOps peut s’avérer complexe lorsqu’un accès SSH est requis sans utiliser de connexions de service. Les tâches standard d’Azure DevOps supposent la présence d’une connexion de service préconfigurée, ce qui rend l’utilisation de machines virtuelles dynamiques ou temporaires peu pratique et inefficace. Dans cet article, nous examinons des solutions à ce problème.

Lorsqu'on parle d'accéder à une machine virtuelle Azure sous Windows, on pense immédiatement au protocole RDP. Pourtant, dans un contexte DevOps, CI/CD ou d'automatisation, une approche plus souple est souvent nécessaire. PowerShell Remoting propose une alternative efficace et sécurisée au RDP, permettant une gestion rapide et automatisée des VM. Cet article vous montre comment configurer et utiliser PowerShell Remote pour gérer vos VM Windows dans Azure.

La sécurité des machines virtuelles dans le cloud ne peut pas être remise à plus tard. L'accès Just-In-Time (JIT) dans Azure réduit considérablement les risques d'accès non autorisé, en accordant l'accès uniquement lorsque c'est nécessaire et pour une durée limitée. Cet article explique comment configurer et utiliser le JIT dans Azure, comment ouvrir des ports sur demande, et surtout, comment l'intégrer à vos pipelines Azure DevOps pour garantir un maximum de sécurité et d’automatisation.

Initialement, j'avais l'intention d'écrire un article sur la pratique de l'utilisation des modèles YAML dans Azure DevOps pour encapsuler des étapes répétables dans les pipelines. Mais pendant le processus d'écriture, j'ai réalisé que de simples références à la documentation et des exemples de fichiers YAML ne seraient pas aussi intéressants sans les relier à un scénario. Ainsi, un court article purement technique s'est transformé en un texte volumineux dédié à plusieurs sujets, chacun étant intéressant en soi. En fin de compte, j'ai décidé de transformer ce texte en une mini-série d'articles. Voici la deuxième partie, consacrée à l'utilisation des modèles YAML dans Azure DevOps, en mettant particulièrement l'accent sur le passage de paramètres vers et depuis les modèles.

Initialement, j'avais l'intention d'écrire un article sur la pratique de l'utilisation des modèles YAML dans Azure DevOps pour encapsuler des étapes répétables dans les pipelines. Mais pendant le processus d'écriture, j'ai réalisé que de simples références à la documentation et des exemples de fichiers YAML ne seraient pas aussi intéressants sans les relier à un scénario. Ainsi, un court article purement technique s'est transformé en un texte volumineux dédié à plusieurs sujets, chacun étant intéressant en soi. En fin de compte, j'ai décidé de transformer ce texte en une mini-série d'articles. Bienvenue dans la première partie, dédiée au test automatisé, où je donnerai un bref aperçu de l'approche du test logiciel et décrirai un scénario que nous automatiserons à l'aide de pipelines YAML avec des modèles dans le prochain article.

Aujourd'hui, tout le monde a entendu les mots intelligence artificielle, réseaux de neurones, ChatGPT. Le sujet est si pertinent et important qu’il est tout simplement impossible de l’ignorer. Dans cet article, je vais discuter un peu de ce qu'est l'intelligence artificielle moderne et vous parler des services que vous pouvez utiliser dans Azure pour travailler avec les réseaux de neurones.

Il n'y a pas si longtemps, j'ai été confronté à une situation où l'un de nos agents de déploiement Azure DevOps a disparu du réseau. Tout allait bien avec la machine, Internet fonctionnait dessus, les paramètres du pare-feu et le groupe de sécurité réseau étaient également bons, mais Azure DevOps a cessé de voir l'agent. Que s’est-il passé et comment avons-nous résolu le problème ? Bienvenue dans l'article.

La dernière fois, nous avons compris comment fonctionne le cloud au niveau le plus bas. Et maintenant, je vous suggère de regarder à l'intérieur du nuage de l'autre côté. Je pense que tout le monde sait ce que sont les fonctions serverless (ceux qui ne le savent pas, allez quand même à l'article - vous le découvrirez là-bas :). Un exemple de telles technologies serverless est Azure Functions, l'un des outils les plus puissants qui vous permet de résoudre facilement et avec élégance de nombreux problèmes de calcul. Voyons donc comment fonctionnent les fonctions serverless et il n'y a vraiment pas de serveurs là-bas...

Dans la continuité de mes réflexions sur la structure interne des cloud, je voudrais aujourd'hui réfléchir à la façon dont ils fonctionnent généralement à l'intérieur du point de vue de l'ingénierie informatique. Essayons de réfléchir à de quelles couches et blocs Microsoft Azure peut être constitué.

Après avoir expliqué le fonctionnement des centres de données, j'aimerais ajouter quelques mots sur la garantie de la fiabilité et de la sécurité au sein des équipes travaillant chez les fournisseurs de cloud. J'ai une certaine expérience de travail pour un fournisseur de cloud et j'énumérerai ci-dessous quelques points que les employés de tout fournisseur de cloud doivent obligatoirement suivre.

Les technologies cloud sont devenues une partie importante de notre vie et dans la plupart des cas, les ingénieurs informatiques modernes ne peuvent pas imaginer leur travail sans interagir avec les services cloud. Mais les nuages ne fonctionnent pas d’eux-mêmes quelque part dans le ciel. Quelque part sur notre planète, il existe des centres de données dotés de nombreux serveurs qui hébergent tous les services SaaS, PaaS et IaaS que nous utilisons. Dans cet article, je parlerai un peu des centres de données - des « baleines » sur lesquelles se dressent les nuages.