#administrer

La gestion des services publics n’est pas uniquement une affaire de compétence permettant de planifier, d’organiser, de réaliser et de contrôler. Le gestionnaire et l’administrateur de services publics doivent savoir conjuguer avec sa capacité de raisonner, sa faculté d’écouter son intuition, la prise en compte de ce qu’il ressent afin de prendre des décisions en phase qui nécessite du…

Le Cloud c’est simple comme un clic de souris et une page web. Effectivement, la plupart des fournisseurs de Cloud mettent en avant la facilité d’administration. Le portail web cache toute la complexité. Cette approche est parfaite pour un service SaaS ou quand mon équipe IT est très limitée ou que les besoins en administration sont minimes.

Mais on s’aperçoit assez rapidement que les portails d’administration Cloud sont aussi leurs propres ennemis : parfois complexe, belle ergonomie, mais trop lent, perte de temps à trouver la bonne option, etc. Pour une administration fine, rapide et efficace, finalement, rien ne vaut la ligne de commande (CLI, command line interface). La CLI est idéale pour gérer au quotidien son Cloud.

Cette semaine j’ai eu l’occasion de montrer Azure et les fondamentaux du Cloud à des étudiants. Oui j’ai utilisé le portail Azure mais j’ai passé plus de temps à manipuler Azure en CLI : plus rapide, plus efficace. Et surtout, nous avons accès à toutes les fonctions immédiatement, avec les bonnes commandes. La productivité est indéniable même si la maîtrise de la CLI est indispensable et que cela prend un peu de temps. Créer un site web, basic, en CLI, prend à peine 40 à 50s. 

L’avantage de la CLI est la rapidité d’action, si le réseau est bon. On gère son compte, les VM, les services PaaS sans aucun souci. Travaillant avec un Mac, il suffit d’installer Azure-CLI et en quelques minutes, mon Terminal se transforme en console d’administration Azure et je peux ouvrir x fenêtres de mon Terminal pour encore plus de souplesse. Je travaille donc à la fois sur Docker, sur Azure et dans ma VM Ubuntu Server, déployée dans Azure. Oui on perd toute l’interface du portail, mais honnêtement, pour un sysadmin cloud ce n’est pas grave, car en principe, il connaît.

En Azure-CLI, nous avons deux modes d’administration : arm et asm. Chaque mode ne fonctionne pas exactement de la même manière et les commandes ne sont pas identiques. Pareillement, il y a des différences avec Azure-CLI 1.x et 2.x.

Ce constat interface vs CLI est valable pour tous les IaaS et PaaS finalement. 

Go to Source

Ceux qui ont l’habitude de gérer des services Windows connaissent bien Windows PowerShell. Cette expertise peut désormais être portée vers le monde AWS. AWS Tools for Windows PowerShell comporte des milliers de commandes (cmdlet) qui fonctionnent avec les outils AWS. Dans cet article, nous allons apprendre à comment utiliser ces outils en configurant des instances EC2.

Jusqu’à présent, le module PowerShell était une simple option des systèmes Windows. Toutefois, Microsoft a placé son outil en Open Source et l’a rendu donc accessible et exploitable pour d’autres plateformes, comme Linux et MacOS.

Installation et configuration

AWS Tools for Windows PowerShell est installé sur les dernières instances Windows d’EC2. Toutefois, dans le cas de dévéloppeurs préférant travailler depuis sa machine en local, il existe plusieurs méthodes :

Utiliser l’installeur MSI avec AWS .NET SDK ainsi que le module AWS PowerShell.

AWS propose un support pour PowerShell Gallery, qui est le repository central de Microsoft pour tout ce qui porte sur PowerShell. Si un développeur utilise Windows Management Framework 5.0, qui inclut PowerShell 5.0, il peut alors installer le module avec une seule ligne de commandes :

 Install-Module AWSPowerShell

 Indiquer les identifiants pour les outils AWS PowerShell

Avant d’exécuter les précieux cmdlets, le développeur doit fournir ses identifiants. Pour les instances EC2 où les outils sont déjà installés, il suffit d’attacher un rôle AWS Identity and Access Management à l’instance pour avoir les bonnes permissions et exécuter les cmdlets. Si le développeur travaille sur sa propre machine, il doit entrer ses identifiants soit de façon explicite soit en créant un profil.

Chaque cmdlet AWS dispose des paramètres AccessKey et SecretKey, mais il est plus sécurisé et facile de créer un profil. Avec ce dernier, on peut oublier ces paramètres et ne pas avoir à embarquer les clés dans le source des scripts.

Pour stocker des identifiants dans un profil, la méthode la plus courante consiste à utiliser le SDK Store, qui chiffre les identifiants et les stocke dans le dossier par défaut. La commande suivante ajoute un nouveau profil au SDK Store :

Set-AWSCredentials -AccessKey -SecretKey -StoreAs Development

 Dans cet exemple, les identifiants sont stockés dans un profil appelé Development. Le développeur peut créer autant de profils qu’il le souhaite. Il se peut aussi que les entreprises préfèrent avoir des profils séparés en fonction des environnements (test, production). Pour utiliser un profil spécifique dans une unique ligne de commande, appuyez-vous sur le paramètre ProfileName :

Get-EC2Instance -ProfileName Development –Region us-west-2

Le développeur peut aussi utiliser une méthode qui d’ailleurs est recommandée : initialiser les paramètres par défaut pour qu’il n’ait pas à entrer le nom du profil dans chaque commande. Cela peut être fait avec le cmdlet Initialize-AWSDefaults :

Initialize-AWSDefaults -ProfileName Development -Region us-west-2

Dans cet exemple, le paramètre Region est fixé sur us-west. Ce paramètre, comme AccessKey et SecretKey, peut être modifié à la commande.

Rechercher les AMIs

Lorsque l’on parle d’automatisation, la tâche la plus courante est le provisioning d’instances EC2. Avant de lancer une instance avec AWS PowerShell, on doit savoir quelle Amazon Machine Image (AMI) utiliser.  L’ID de l’image est ici important.

Avec le cmdlet Get-EC2ImageByName, il est facile de trouver une image Windows. Ce cmdlet retourne simplement une liste d’images aux noms évocateurs, comme par exemple WINDOWS_2012R2_BASE ou WINDOWS_2008R2_BASE. Utilisez cela pour identifier l’ID de l’image.

L’ID de l’image change régulièrement car AWS met à jour les AMIs Windows une fois par mois. Ces ID diffèrent d’une région AWS à une autre. Par conséquent, le moyen le plus facile d’avoir la bonne ID pour la bonne plateforme est la suivante :

$ami = Get-EC2ImageByName windows_2012r2_base | Select-Object -ExpandProperty imageid

Dans cet exemple, Get-EC2ImageByName retrouve l’ID de l’image  Windows Server 2012 R2. Nous modifions également la propriété ImageId pour que la variable puisse contenir une chaîne de caractère équivalent à l’ID de l’image. Cette commande peut s’exécuter dans toutes les régions et doit toujours contenir la dernière ID.

Après avoir choisi la bonne image, il est assez simple de créer une instance EC2. Nous avons besoin d’utiliser le cmdlet New-EC2Instance. Cela fournit d’ailleurs un grand nombre de paramètres pour la création de l’instance. Les développeurs créent une instance sur le Amazon Virtual Private Cloud par défaut via la commande ci-dessous :

New-EC2Instance -ImageId $ami -KeyName Oregon -InstanceType m4.xlarge

Cela suppose que les clés ont été créées dans la région us-west-2 appelée Oregon.

 Créer des groupes de sécurité et des règles de gestion

Si aucun groupe de sécurité n’est créé au lancement d’une instance, celle-ci s’appuiera sur le groupe par défaut. Pour lancer une instance dans un groupe spécifique, il convient d’en connaître son ID. Dans l’exemple ci-dessous, un groupe de sécurité est créé et l’ID qui en ressort est capturé dans une variable.

$sg = New-EC2SecurityGroup -GroupName MyRDPGroup -Description ‘Enable RDP from Internet’

Pour utiliser Remote Desktop Protocol et se connecter à une instance dans un groupe dès sa création, ajoutez une seule règle au groupe qui autorise le port TCP 3389 :

$ip = New-Object Amazon.EC2.Model.IpPermission $ip.IpProtocol = ‘tcp’ $ip.FromPort = ‘3389’ $ip.ToPort = ‘3389’ $ip.IpRange.add(‘0.0.0.0/0’)

Nous avons créé un nouvel objet IpPermission avec le cmdlet New-Object. Utilisez la notation par points pour définir la valeur des propriétés requises par défaut pour la règle. La dernière ligne indique l’adresse de la source. Il est une bonne pratique : utilisez votre propre adresse IP pour sécuriser les instances. Pour cela, remplacer 0.0.0.0/0 par votre propre adresse IP.

Pour créer plusieurs règles, produisez plusieurs objets IpPermission puis ajoutez-les à la règle avec le cmdlet Grant-EC2SecurityGroupIngress.

Grant-EC2SecurityGroupIngress -GroupId $sg -IpPermissions $ip

Pour assigner plusieurs règles, entrez une liste (dont les éléments sont séparés par un point-virgule) d’objets IpPermission dans les paramètres d’IpPermissions. Puis lancez une instance EC2 dans le groupe de sécurité avec les commandes suivantes :

New-EC2Instance -ImageId $ami -KeyName Oregon -InstanceType m4.xlarge -SecurityGroupId $sg

Tagguer les instances EC2

Tagguer les instances permet aux développeurs de mieux les suivre. Il est recommandé d’utiliser le tag Name pour que le nom de l’instance corresponde au nom de l’hôte à la console. Voici les commandes :

$i = New-EC2Instance -ImageId $ami -KeyName Oregon -InstanceType m4.xlarge New-EC2Tag -Resources $i.instances.instanceid -Tags @{key=’Name’;value=’SRV01′}

 Dans cet exemple, nous avons créé une instance et stocké l’objet qui en résulte dans la variable $1. Pour les administrateurs, cela est un moyen assez simple pour passer les ID dans la commande suivante, qui utilise le cmdlet New-EC2Tag pour assigner un tag Name avec la valeur SRV01 à l’instance.

Si l’instance a déjà été créée, il se peut que vous ayez besoin de référencer l’ID de l’instance. Cela est possible via le cmdlet Get-EC2Instance.

Traduit et adapté par la rédaction

Go to Source