Ce qu'il faut savoir avant d'utiliser plusieurs interfaces réseau dans Google Cloud
Le Load Balancer de Google Cloud, avec une seule IP globale et une multitude de services backend (VM, pods Kubernetes, instances Cloud Functions, etc.), est aujourd'hui le moyen privilégié pour exposer une application sur le web. Surtout lorsqu'on n'a besoin que du bon vieux HTTP(S). Une seule adresse IP pour les gouverner toutes suffit en général.
Cela dit, on rencontre parfois une configuration particulière, voire traditionnelle, où l'on souhaite qu'une VM accepte du trafic sur plusieurs IP. Le plus souvent, ce sera via le protocole TCP, même si l'exemple classique de l'hébergement virtuel HTTP basé sur l'IP vient immédiatement à l'esprit.
Tout cela revient finalement à une question : comment obtenir une VM GCP avec plusieurs IP ? Une recherche sur le web vous orientera très probablement vers la piste " VM GCP avec plusieurs interfaces réseau ". Cette approche fonctionne comme décrit ici : on attache une IP externe à chaque carte d'interface réseau (NIC) de la VM. Plusieurs limites sont toutefois à connaître :
- Chaque carte d'interface réseau (NIC) nécessite un réseau VPC distinct. Ce n'est pas un problème en soi, mais cela exige une vraie configuration DevOps : il ne s'agit pas seulement de créer un VPC et de définir ses plages d'IP sans chevauchement, mais aussi de mettre en place des règles de pare-feu pour chaque VPC.
- Vous pouvez avoir jusqu'à 8 NIC par VM. Cela peut suffire, ou pas, selon vos besoins.
- Il est IMPOSSIBLE de modifier le nombre de NIC d'une VM après sa création. Si vous démarrez avec 5 IP et souhaitez en ajouter une plus tard, il faudra recréer la VM.
- Le nombre de vCPU de la VM doit être au moins égal au nombre de NIC. C'est là que la facture peut vite grimper. 1 ou 2 vCPU peuvent suffire à servir l'ensemble de votre trafic, mais il faudra payer une machine à 8 vCPU si vous voulez 8 IP.
Voici une astuce à partager : créez une VM 8 vCPU avec 8 NIC, arrêtez-la, réduisez le type de machine, puis redémarrez-la. À utiliser avec prudence : GCP peut combler cette faille à tout moment.
Les forwarding rules
L'approche la moins coûteuse et la plus simple repose sur les forwarding rules. Le réseau GCP étant entièrement défini par logiciel, votre VM ne peut pas s'approprier des IP et les annoncer via des réponses ARP : il n'y a en réalité que très peu d'ARP en jeu. C'est soit localhost, soit la passerelle par défaut pour tout le reste. Même le trafic vers la VM " voisine " du même VPC transite par la passerelle par défaut.
me@my-vm:~$ ip route showdefault via 10.128.0.1 dev ens410.128.0.1 dev ens4 scope linkIl faut donc " expliquer " à GCP que l'on souhaite ouvrir d'autres IP au trafic, et cette explication passe par les forwarding rules.
Une forwarding rule dans GCP est très souple. Elle peut écouter n'importe quelle combinaison d'IP, de ports, de protocoles, d'hôtes et de chemins HTTP, puis rediriger le trafic correspondant vers une cible : une VM, un pool de VM, un bucket Cloud Storage, une Cloud Function, un service Kubernetes, etc.
Les forwarding rules sont payantes. Nous y reviendrons.
Dans notre cas, nous n'avons besoin que de la forme la plus simple : écouter sur tcp:adresse:port et rediriger tout le trafic vers une seule instance cible.
Les forwarding rules dans leur forme la plus simple
La documentation GCP propose un article très bien fait, et très long, sur la marche à suivre. Cette approche y est appelée Protocol Forwarding. Elle n'est pratiquement pas prise en charge dans la console GCP. Pour la configurer dans une région autre que celle par défaut, vous devez veiller à indiquer précisément les bonnes régions et zones pour chacune des commandes (dites-le moi en commentaire si vous souhaitez plus de détails à ce sujet).
Heureusement, l'interface graphique offre un moyen plus simple.
Commençons par allouer plusieurs IP :
NOTE : assurez-vous que vos IP sont régionales et qu'elles se trouvent dans la même région que votre VM cible.
L'interface vous avertit que les IP externes statiques inutilisées sont facturées plus cher (tarifs ici) que celles qui sont utilisées, mais nous allons rectifier cela dans un instant.
Créez ensuite une VM, que nous appellerons " au-vm " dans la région australia-southeast1. Pensez à cocher " Allow HTTP traffic " ou à configurer les règles de pare-feu pour autoriser le port concerné en TCP.
Passons maintenant aux forwarding rules. Dans le menu Network Services, sélectionnez Load Balancing puis lancez la configuration d'un nouveau load balancer TCP. Les valeurs par défaut " From Internet to my VMs ", " Single region only " et " Target Pool or Target Instance " correspondent exactement à nos besoins.
Donnez un nom à votre load balancer puis, dans la section Backend configuration, sélectionnez votre instance au-vm existante.
Voilà pour la partie cible. Cliquez maintenant sur " Frontend configuration " pour gérer la partie " écoute " et ajoutez toutes les IP que vous avez réservées.
Ici, j'ai ajouté toutes mes IP précédemment allouées pour qu'elles soient écoutées sur le port 80
Cliquez sur " Create " et le tour est joué ! Comptez quelques minutes le temps que tout se mette en place, et à partir de là votre VM accepte le trafic sur les trois IP ci-dessus. Si cela ne fonctionne pas, vérifiez que vos règles de pare-feu autorisent bien les ports requis.
Vous pouvez modifier votre load balancer à tout moment pour ajouter ou retirer des IP.
Les processus de votre VM peuvent même se lier à l'adresse IP cible souhaitée, alors même qu'aucune interface réseau Linux ne semble la porter (selon ip address show). Dans cet exemple, la commande suivante fonctionnera :
nc -s 34.87.204.138 -l -p 80Le secret derrière cette magie réside dans les daemons GCP qui tournent sur votre machine et configurent les routes Linux pour accepter les paquets destinés aux adresses concernées :
me@au-vm:~$ ip route show table all...local 34.87.204.138 dev ens4 table local proto 66 scope hostlocal 34.87.228.28 dev ens4 table local proto 66 scope hostlocal 34.116.108.163 dev ens4 table local proto 66 scope host...Parlons argent
Les forwarding rules fonctionnent très bien et constituent une réponse plus naturelle au besoin. Mais elles ne sont pas gratuites.
Google facture un tarif fixe de 0,025 $/heure pour les 5 premières règles, autrement dit vous payez le même total de 0,025 $/heure que vous en ayez 1 ou 5. Au-delà, chaque forwarding rule supplémentaire coûte 0,01 $/heure. Ainsi, disposer de 10 IP pour une VM pendant un mois entier reviendrait à 55 $/mois, rien que pour les forwarding rules.
Malheureusement, ce n'est pas tout. Il n'y a pas si longtemps, GCP s'est mis à facturer les IP externes, y compris celles qui sont utilisées (peu importe qu'elles soient associées à des VM ou à des forwarding rules). Leur tarif de 0,004 $/h par IP peut sembler négligeable, mais cela représente 0,004 $ * 730 h = 2,92 $/mois et, multiplié par 10 IP dans notre cas, le coût total de 10 IP routées vers notre VM atteint :
55 $ + 29,2 $ ≈ 85 $/mois, uniquement pour les IP, avant même de payer la VM
Cher ou pas ? Je vous laisse en juger :-)
Merci de votre lecture ! Pour rester en contact, suivez-nous sur le DoiT Engineering Blog , la page LinkedIn de DoiT et le compte Twitter de DoiT . Pour découvrir nos opportunités de carrière, rendez-vous sur https://careers.doit.com .