Prévoyez-vous (ou envisagez-vous) d'exécuter Red Hat Enterprise Linux (RHEL) sur Microsoft Azure ? Vous vous demandez à quoi vous devez penser avant de le faire ?
Exécuter RHEL sur Azure semble assez simple, et je serais partiellement d'accord pour dire que c'est vrai. Cependant, les exigences typiques de l'entreprise lors de l'utilisation d'Azure peuvent être légèrement différentes des images BYOS (apportez votre propre abonnement) consommable et du paiement à l'utilisation (PAYG) par défaut. Je n'entrerai pas dans les détails, mais je vais vous donner quelques conseils sur la configuration du réseau (en particulier DNS) qui devraient vous aider à commencer à adapter les images Azure à vos besoins.
Configuration de l'environnement
Dans mon exemple, je m'attends à ce que vous ayez un VPN entre vos machines virtuelles Azure et votre centre de données principal (qu'il s'agisse d'une autre forme de service cloud ou de votre service sur site). Vous avez besoin d'un serveur DNS (interne) responsable de vos hôtes et éventuellement des services que vous souhaitez utiliser.
Par défaut, si vous démarrez une image Red Hat Enterprise Linux dans Azure, vous vous retrouverez probablement avec un /etc/resolv.conf similaire à celui-ci :
$ cat /etc/resolv.conf
# Generated by NetworkManager
search iftv0wntyplulh4lbl2jpq0ppg.fx.internal.cloudapp.net
nameserver 168.63.129.16
Bien qu'il s'agisse d'une configuration de travail qui est probablement suffisante pour une variété de scénarios, elle ne répond pas à nos exigences :
- Interroge notre propre serveur de noms afin de pouvoir résoudre les noms d'hôtes internes.
- Ne nous permet pas d'interroger des noms d'hôte non FQDN dans notre propre domaine.
- Fuite éventuellement des informations sur nos noms d'hôte vers le serveur de noms Microsoft (sans infraction).
Adaptation de la configuration générée
Les administrateurs système expérimentés qui ont travaillé avec DHCP pour attribuer une configuration IP/DNS à leurs clients dans le passé finiront par connaître les astuces nécessaires. La clé ici est dhclient.conf , le fichier de configuration du client DHCP. À l'aide de ce fichier, on peut remplacer/adapter les valeurs de configuration fournies par le serveur DHCP (Microsoft Azure).
Afin de rendre cet exemple facile à reproduire et également une configuration de travail, nous utiliserons l'un des serveurs DNS publics de Google comme serveur DNS principal (et unique), 8.8.8.8. Et, nous voulons que notre domaine soit redhat.com .
Nous créons donc le fichier de configuration /etc/dhcp/dhclient.conf avec le contenu suivant :
$ cat /etc/dhcp/dhclient.conf
supersede domain-name-servers 8.8.8.8;
supersede domain-search "redhat.com";
Cette configuration conduit au /etc/resolv.conf généré suivant :
$ cat /etc/resolv.conf
# Generated by NetworkManager
search redhat.com
nameserver 8.8.8.8
Notez que nous divulguerons toujours les noms d'hôte internes au serveur DNS de Google dans cet exemple. Mais, comme indiqué ci-dessus, par souci de reproductibilité, j'ai choisi un serveur DNS accessible au public pour tout le monde.
Tester la configuration
Vous allez probablement essayer cette configuration avec des noms d'hôte internes, mais nous allons la tester en essayant de résoudre uniquement mx1 (non FQDN) :
$ host mx1
mx1.redhat.com has address 209.132.183.28
Voilà, exactement ce que nous attendons.
Configuration supplémentaire
Il existe plusieurs autres valeurs de configuration que vous pouvez remplacer, ajouter et adapter à vos besoins. La meilleure façon d'en savoir plus sur ces valeurs est, comme tous les administrateurs système devraient le savoir, de consulter les pages de manuel. Dans ce cas précis, je vous recommande de lire ce qui suit :
$ man 5 dhclient.conf
Personnellement, je recommanderais de s'en tenir aux valeurs par défaut s'il n'y a pas de besoin absolu de les modifier, mais si vous devez remplacer ou ajouter des valeurs, vous devriez pouvoir les trouver dans la page de manuel.
Vous voulez essayer Red Hat Enterprise Linux ? Téléchargez-le maintenant gratuitement.