Ένα ιδιωτικό cloud μέσα σε ένα VM του Google Cloud

Η εργασία ζητούσε να στηθεί OpenStack και να διαχειριστώ έναν tenant από την αρχή ως το τέλος: project και χρήστη, quotas, δίκτυο και instances, και στο τέλος μια εφαρμογή πάνω τους. Έτρεξα το DevStack σε ένα μόνο VM στο Google Cloud.

Έτσι, στην ίδια στοίβα υπάρχουν δύο hypervisors. Το VM είναι το πρώτο επίπεδο και τα instances που ξεκινά το Nova είναι εικονικές μηχανές μέσα σε αυτό. Το δημιούργησα με ενεργό nested virtualisation.

Το DevStack εγκατέστησε το OpenStack σε αυτόν τον έναν host, με τις υπηρεσίες του να τρέχουν ως 24 systemd units. Μέσα του έστησα έναν tenant:

Keystone

ένα project, έναν χρήστη με τον ρόλο member και ένα αρχείο openrc για αυτόν τον χρήστη

Glance

ένα image Ubuntu 22.04 Minimal και για τα δύο instances

Nova

δικά μου flavors και quotas για το project

Neutron

ιδιωτικό δίκτυο και subnet, router προς το δημόσιο δίκτυο, ένα security group και floating IPs

Ο διαχωρισμός του tenant από τον admin έφερε τα περισσότερα προβλήματα. Από τα 18 που κατέγραψα, τα 8 προήλθαν από πόρους που δημιουργήθηκαν ή αναζητήθηκαν με τα credentials του admin: ένα security group που «δεν βρέθηκε», ένα key pair «μη έγκυρο», ένα instance χωρίς ιδιωτική διεύθυνση. Κάθε πόρος ανήκει στο project που τον δημιούργησε, άρα τα credentials που χρησιμοποιούνται καθορίζουν τι υπάρχει.

Η κίνηση ενός instance περνά από δύο δίκτυα. Μέσα στο OpenStack, ο router του Neutron της δίνει μια διεύθυνση από το floating range και τη στέλνει έξω από το br-ex, το Open vSwitch bridge του host για το εξωτερικό δίκτυο. Έξω, το Google Cloud γνωρίζει μία μόνο διεύθυνση για όλο το μηχάνημα: την εσωτερική διεύθυνση του VM στο ens4, τη μοναδική του κάρτα δικτύου.

Σύμπτωμα

Στο πρώτο instance, το ping δεν έπαιρνε απάντηση και το apt update κολλούσε στο «Connecting to archive.ubuntu.com». Κανένα μήνυμα λάθους, πουθενά.

Εντοπισμός

tcpdump σε κάθε interface κατά μήκος της διαδρομής: τα πακέτα εμφανίζονταν στο tap interface του instance και στο br-ex, ποτέ στο ens4.

Αιτία

Ο host δεν προωθούσε πακέτα μεταξύ br-ex και ens4, και ό,τι προωθούσε θα έφευγε με διεύθυνση πηγής από το floating range, την οποία το Google Cloud απορρίπτει χωρίς απάντηση.

Λύση

Ενεργό IP forwarding, κανόνες FORWARD από το br-ex προς τα έξω και πίσω μόνο για εγκατεστημένες συνδέσεις, MASQUERADE στο ens4, όλα αποθηκευμένα με iptables-persistent.

Αυτό άντεξε ώσπου το VM σταμάτησε και ξεκίνησε ξανά. Οι κανόνες iptables επανήλθαν, αλλά το br-ex ξεκίνησε χωρίς τη διεύθυνση και το route του, και τα floating IPs έγιναν ξανά απρόσιτα. Στην αρχή κρατούσα μια λίστα εντολών για να τις ξανατρέχω. Μετά την αντικατέστησα με το brex-setup.service, ένα oneshot systemd unit που τρέχει μετά το δίκτυο και το DevStack και επαναφέρει το bridge σε κάθε εκκίνηση.

Τι κράτησα: το πρόβλημα βρίσκεται ένα βήμα μετά το τελευταίο interface όπου το πακέτο φαίνεται ακόμα, και μια διόρθωση που χάνεται με μια επανεκκίνηση δεν έχει τελειώσει μέχρι να γίνει μέρος της εκκίνησης.

Για να ελέγξω τον tenant από άκρη σε άκρη, έστησα μια μικρή εφαρμογή δύο επιπέδων. Τα εργαστήρια έβαζαν PostgreSQL και Flask στο ίδιο VM. Εγώ τα χώρισα σε δύο instances, ώστε το API να φτάνει στη βάση του μέσα από το ιδιωτικό δίκτυο του OpenStack.

Το vm-db τρέχει PostgreSQL 14, ρυθμισμένη να δέχεται απομακρυσμένες συνδέσεις. Το vm-app τρέχει ένα Flask API με Gunicorn ως systemd service, πίσω από NGINX στη θύρα 80, και συνδέεται στο vm-db με την ιδιωτική του διεύθυνση. Ο τελικός έλεγχος έγινε μέσω SSH tunnel από τον host: το /api/products επέστρεψε τέσσερα προϊόντα σε JSON, διαβασμένα από το άλλο instance.

Λειτούργησε, αλλά ήταν στημένο για εργαστήριο. Τα δύο instances μοιράζονται ένα security group, οπότε η θύρα της PostgreSQL είναι ανοιχτή και στο VM της εφαρμογής και η θύρα 80 στη βάση. Θα έδινα σε κάθε επίπεδο δικό του group, με τη 5432 ανοιχτή μόνο για το vm-app. Ο κωδικός της βάσης βρίσκεται μέσα στον κώδικα της εφαρμογής και η PostgreSQL ακούει σε όλα τα interfaces. Και η δικτύωση του host ανήκει στον τρόπο που στήνεται το VM, όχι σε διορθώσεις που προστέθηκαν στην πορεία.