Πώς να ασφαλίσετε και να κλιμακώσετε μια εφαρμογή Django με Docker, Nginx και Let’s Encrypt

Εκατομμύρια χρήστες συνδέονται στο Διαδίκτυο για να αποκτήσουν πρόσβαση σε πληροφορίες για διάφορους σκοπούς, όπως η μάθηση, η ψυχαγωγία, οι ειδήσεις και η κοινή χρήση της εξέλιξης της ζωής τους’ με φίλους. Επομένως, κατά την ανάπτυξη μιας εφαρμογής, είναι προς το συμφέρον σας να υλοποιήσετε μια εξαιρετικά ασφαλή και επεκτάσιμη υποδομή για την εφαρμογή σας. Το cloud προσφέρει διάφορους τρόπους για την ασφάλεια και την κλιμάκωση μιας εφαρμογής Django εφαρμογής. Η οριζόντια κλιμάκωση είναι μια μέθοδος που μπορεί να σας επιτρέψει να εκτελέσετε πολλά αντίγραφα της εφαρμογής σας. Αυτό διασφαλίζει ότι είναι πιο ανθεκτική στα σφάλματα και εξαιρετικά διαθέσιμη. Αυξάνει επίσης την απόδοσή της για την ταυτόχρονη επεξεργασία πολλαπλών αιτημάτων.

Οριζόντια κλιμάκωση μιας εφαρμογής Django

Μπορείτε να κλιμακώσετε οριζόντια μια εφαρμογή Django δημιουργώντας αρκετούς διακομιστές εφαρμογών που εκτελούν την εφαρμογή Django και τον WSGI HTTP διακομιστή της (όπως Gunicorn ή uWSGI). Στη συνέχεια, θα πρέπει να δημιουργήσετε μια υποδομή για τη διανομή των εισερχόμενων αιτημάτων σε αυτούς τους διακομιστές εφαρμογών. Ένας εξισορροπητής φορτίου και ένας reverse proxy like Nginx μπορούν να βοηθήσουν την υποδομή σας με τη διανομή της κίνησης. Ο Nginx μπορεί να αναπτύξει SSL certificates διασφαλίζοντας ασφαλείς συνδέσεις με την εφαρμογή σας μέσω HTTPS. Τέλος, ο Nginx μπορεί επίσης να παρέχει προσωρινή αποθήκευση στατικού περιεχομένου για την ελαχιστοποίηση του φορτίου στον διακομιστή σας.

Η διαμόρφωση αυτών των διαφόρων στοιχείων ξεχωριστά και η διασφάλιση της επικοινωνίας τους μπορεί να είναι μια δύσκολη εργασία. Ευτυχώς, η χρήση του Docker απλοποιεί τη διαδικασία διαμόρφωσης και διασφαλίζει ότι τα διάφορα στοιχεία συμπεριφέρονται με τον ίδιο τρόπο ανεξάρτητα από το πού αναπτύσσονται.

Τι θα κάνετε σε αυτόν τον οδηγό

Σε αυτόν τον οδηγό, you will learn how to horizontally scale a containerized Django application, served with a Gunicorn WSGI HTTP server. Θα δημιουργήσετε δύο διακομιστές εφαρμογών, ο καθένας με εγκατεστημένο το Docker, οι οποίοι θα εκτελούν το ίδιο αντίγραφο ενός container εφαρμογής Django και Gunicorn.

Θα ασφαλίσετε επίσης την εφαρμογή σας με ένα Let’s Encrypt πιστοποιητικό SSL, δημιουργώντας και διαμορφώνοντας έναν third proxy server που θα εκτελεί έναν container Nginx reverse proxy και έναν container πελάτη Certbot. Το Certbot είναι ένα πακέτο που βοηθά στη διαχείριση πιστοποιητικών SSL από την αρχή πιστοποίησης Let’s Encrypt. Ανακτά το πιστοποιητικό, διαμορφώνει τα server blocks του Nginx με την τοποθεσία του πιστοποιητικού και διαχειρίζεται τις αυτόματες ανανεώσεις. Αυτό το κάνει ρυθμίζοντας μια εργασία cron για να ελέγχει περιοδικά εάν το πιστοποιητικό πρόκειται να λήξει και πρέπει να ανανεωθεί. Διατηρώντας το πιστοποιητικό SSL ενημερωμένο, ο ιστότοπός σας θα έχει πάντα υψηλή βαθμολογία ασφάλειας στο SSL Labs.

Ο third proxy server βρίσκεται μπροστά από την κατανεμημένη αρχιτεκτονική σας και λαμβάνει όλη την εισερχόμενη εξωτερική κίνηση. Στη συνέχεια, διανέμει την κίνηση στους διακομιστές εφαρμογών σας. Οι διακομιστές εφαρμογών βρίσκονται πίσω από ένα τείχος προστασίας, επιτρέποντας μόνο στον διακομιστή μεσολάβησης να έχει πρόσβαση σε αυτούς.

Αυτό το σεμινάριο είναι το second in a series of three tutorials working with Django, Docker, and Kubernetes. Θα πρέπει πρώτα να ακολουθήσετε τα βήματα που περιγράφονται στο σεμινάριο σχετικά με τη Building a Django and Gunicorn Application with Docker on Ubuntu. Σε αυτό το σεμινάριο, ρυθμίσαμε τον βασικό κώδικα του έργου, ένα Dockerfile, και συνδέσαμε την εφαρμογή στο MinIo Simple Storage Service (S3) για την εξυπηρέτηση των στατικών μας αρχείων.

Prerequisites

Για να παρακολουθήσετε αυτό το σεμινάριο, θα χρειαστείτε τα εξής:

1. Τέσσερις διακομιστές Ubuntu 20.04:

Εάν έχετε ακολουθήσει τα βήματα στο προαπαιτούμενο σεμινάριο, Building a Django and Gunicorn Application with Docker on Ubuntu, έχετε ήδη δύο από τους τέσσερις διακομιστές:

• Ο πρώτος διακομιστής θα εκτελεί το PostgreSQL database instance. Ακολουθήστε τα Βήματα 1 και 2 του σεμιναρίου: Building a Django and Gunicorn Application with Docker on Ubuntu για να ρυθμίσετε τη βάση δεδομένων. Οι ρυθμίσεις του Postgres θα πρέπει να τροποποιηθούν ώστε να επιτρέπουν εξωτερικές συνδέσεις μόνο από τις IP των διακομιστών της εφαρμογής σας.

• Ο second και ο third διακομιστές θα φιλοξενούν τους containers για τον κώδικα της εφαρμογής σας. Θα πρέπει ήδη να έχετε τον δεύτερο διακομιστή σε λειτουργία από το prerequisite tutorial. Θα τροποποιήσουμε το τείχος προστασίας του ώστε να επιτρέπει εξωτερικές συνδέσεις μόνο από την IP του διακομιστή μεσολάβησης. Μπορείτε να ακολουθήσετε τα βήματα 1 έως 4 αυτού του step-by-step tutorial to help you set up your Ubuntu server στο CloudSigma.

• Ο τέταρτος διακομιστής θα είναι ο διακομιστής μεσολάβησης (proxy server) που θα χειρίζεται την εξισορρόπηση φορτίου και τη διανομή της κίνησης στα δύο containers του διακομιστή εφαρμογών.

2. Το Docker θα πρέπει να είναι εγκατεστημένο στους δύο διακομιστές εφαρμογών και στον διακομιστή μεσολάβησης.

   Αφού ακολουθήσετε τα βήματα στον προαπαιτούμενο οδηγό, θα πρέπει να έχετε ήδη εγκατεστημένο το Docker σε έναν από τους διακομιστές. Μπορείτε να ακολουθήσετε τα βήματα 1, 2 και 3 του οδηγού μας για την εγκατάσταση και λειτουργία του Docker. Θυμηθείτε να προσθέσετε τον χρήστη sudo που δημιουργήθηκε παραπάνω στην ομάδα Docker.

3. Αποκτήστε ένα κατοχυρωμένο όνομα τομέα (domain name) και ρυθμίστε τις εγγραφές DNS του ώστε να δείχνουν στη δημόσια διεύθυνση IP του διακομιστή μεσολάβησης. Για σκοπούς επίδειξης, θα χρησιμοποιήσουμε example_domain.com.

4. Ρυθμίστε μια υπηρεσία αποθήκευσης αντικειμένων S3. Χρησιμοποιήσαμε το MinIO ως υπηρεσία αποθήκευσης στον προαπαιτούμενο οδηγό. Επομένως, ακολουθήστε τις επεξηγήσεις στο Βήμα 5 του προαπαιτούμενου οδηγού για να ρυθμίσετε το MinIO storage bucket σας.

Βήμα 1: Επιβεβαίωση ότι ο πρώτος διακομιστής εφαρμογής Django λειτουργεί

Όπως εξηγείται στα Προαπαιτούμενα, αυτός ο οδηγός ακολουθεί τον οδηγό για τη Δημιουργία μιας εφαρμογής Django και Gunicorn με Docker σε Ubuntu. Εάν προέρχεστε από αυτόν τον οδηγό και έχετε ήδη εφαρμόσει τα βήματα, θα πρέπει να έχετε τον πρώτο διακομιστή σε λειτουργία. Ο κώδικας της εφαρμογής βασίζεται στο οδηγό εφαρμογής Polls της τεκμηρίωσης του Django. Είναι σημαντικό να διαβάσετε αυτά τα βήματα για να κατανοήσετε την αρχική ρύθμιση. Εάν έχετε εφαρμόσει τα βήματα στον οδηγό, μπορείτε να παραλείψετε αυτό το πρώτο βήμα.

Διαφορετικά, μπορείτε απλώς να κλωνοποιήσετε το Dockerized branch στον διακομιστή σας. Ξεκινήστε συνδεόμενοι στον πρώτο διακομιστή εφαρμογών σας και εκτελέστε την ακόλουθη εντολή git για να κλωνοποιήσετε το django-polls-docker branch του αποθετηρίου django-polls:

Στη συνέχεια, μεταβείτε στον κατάλογο django-polls:

cd django-polls

Σε αυτόν τον κατάλογο, θα βρείτε ένα Dockerfile που χρησιμοποιείται από το Docker για τη δημιουργία του image της εφαρμογής, τον κατάλογο django-polls που περιέχει τον κώδικα της εφαρμογής Python, και ένα αρχείο env που περιέχει μια λίστα με μεταβλητές περιβάλλοντος οι οποίες θα μεταβιβαστούν στο container κατά την εκκίνηση για να τροποποιήσουν τη συμπεριφορά του. Στο Dockerfile, ορίζουμε τις εξαρτήσεις πακέτων του Django μέσω του αρχείου requirements.txt. Επιπλέον, πρέπει να δηλώσουμε μια θύρα 8000 που θα χρησιμοποιηθεί για την αποδοχή της εισερχόμενης κίνησης, και να την ρυθμίσουμε να εκτελεί έναν gunicorn server με 3 workers. Για να μάθετε περισσότερα σχετικά με τις οδηγίες του Dockerfile, ρίξτε μια ματιά στο Βήμα 7 του οδηγού Δημιουργία μιας εφαρμογής Django και Gunicorn με Docker σε Ubuntu.

Μπορείτε να δημιουργήσετε το Docker image χρησιμοποιώντας την εντολή:

docker build -t django-polls:v1 .

Αφού το Docker δημιουργήσει το image, μπορείτε να δείτε τη λίστα με τα διαθέσιμα images στον διακομιστή με την ακόλουθη εντολή:

docker images

Εδώ είναι το αποτέλεσμα όταν εκτελέσαμε την εντολή:

Στη συνέχεια, πρέπει να τροποποιήσουμε το αρχείο env που χρησιμοποιείται για τη διαμόρφωση του περιβάλλοντος εκτέλεσης. Αυτό το αρχείο μεταβιβάζεται στο Docker run container κατά την εκκίνηση του container. Ανοίξτε το αρχείο env με τον επεξεργαστή nano:

Το env αρχείο περιέχει κάποιο κείμενο placeholder που πρέπει να τροποποιήσετε και να συμπληρώσετε με τις σωστές σας τιμές:

• DJANGO_SECRET_KEY: Δημιουργήστε μια μοναδική, απρόβλεπτη τιμή όπως εξηγείται στα έγγραφα του Django. Μπορείτε να χρησιμοποιήσετε αυτήν την εντολή για να δημιουργήσετε μια τυχαία συμβολοσειρά και να την ορίσετε στη μεταβλητή:  python -c 'from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())'.

• DJANGO_ALLOWED_HOSTS: αυτή η τιμή χρησιμοποιείται για την προστασία της εφαρμογής σας από επιθέσεις HTTP Host Header. Μπορείτε να την ορίσετε σε *, χαρακτήρα μπαλαντέρ (wildcard) που ταιριάζει με όλους τους κεντρικούς υπολογιστές εάν βρίσκεστε σε λειτουργία ανάπτυξης. Όταν αναπτύξετε την εφαρμογή σας σε περιβάλλον παραγωγής, ορίστε το στο καταχωρημένο όνομα τομέα σας. Για την παρουσίασή μας είναι example_domain.com.

• DB_DATABASE: ορίστε το στο όνομα της βάσης δεδομένων PostgreSQL που δημιουργήσατε στην ενότητα Προαπαιτούμενα, για την περίπτωσή μας είναι polls_db.

• DB_USERNAME: ορίστε το στο όνομα χρήστη που επιλέξατε για τη βάση δεδομένων σας.

• DB_PASSWORD: ορίστε το στον κωδικό πρόσβασης που επιλέξατε για τη βάση δεδομένων σας.

• DB_HOST: ορίστε το στον κεντρικό υπολογιστή (host) που εκτελεί το στιγμιότυπο της βάσης δεδομένων σας, όπως είχατε ρυθμίσει στην ενότητα Προαπαιτούμενα. Αυτό εξηγείται στα Βήματα 1 και 2 του οδηγού Δημιουργία μιας εφαρμογής Django και Gunicorn με Docker σε Ubuntu για τη ρύθμιση της βάσης δεδομένων.

• DB_PORT: ορίστε το στη θύρα της βάσης δεδομένων σας.

Αποθηκεύστε και κλείστε το αρχείο μόλις ολοκληρώσετε την επεξεργασία. Με τα διαπιστευτήρια της βάσης δεδομένων μας στη θέση τους, μπορούμε να δημιουργήσουμε το σχήμα της βάσης δεδομένων εκτελώντας το container και παρακάμπτοντας την εντολή CMD που έχει οριστεί στο Dockerfile. Μπορείτε να βρείτε περισσότερες πληροφορίες σχετικά με το σημείο εισόδου του Dockerfile από τα επίσημα έγγραφα (Docs). Στη συνέχεια, εκτελέστε την ακόλουθη εντολή:

In this command, we are running the django-polls:v1 image and passing in the env file modified earlier. The part: sh -c "python manage.py makemigrations && python manage.py migrate” δημιουργεί το σχήμα της βάσης δεδομένων που ορίζεται από τον κώδικα της εφαρμογής. Εάν εκτελείτε την εντολή για πρώτη φορά, θα πρέπει να δείτε ένα παρόμοιο αποτέλεσμα που υποδεικνύει τη δημιουργία του σχήματος της βάσης δεδομένων:

Μόλις δημιουργηθεί το σχήμα, μπορούμε να δημιουργήσουμε τον υπερχρήστη (superuser) του Django. Εκτελέστε την ακόλουθη εντολή για να ξεκινήσετε το container με ένα διαδραστικό κέλυφος (interactive shell):

Η εντολή εκκινεί το container με μια προτροπή κελύφους (shell prompt) που μπορείτε να χρησιμοποιήσετε για να αλληλεπιδράσετε με το κέλυφος της Python. Ας δημιουργήσουμε έναν χρήστη με την ακόλουθη εντολή:

Ακολουθήστε τις οδηγίες για να εισαγάγετε όνομα χρήστη, διεύθυνση email και κωδικό πρόσβασης. Πληκτρολογήστε ξανά τον κωδικό πρόσβασης και πατήστε enter για να δημιουργήσετε τον χρήστη. Βγείτε από το κέλυφος και τερματίστε το container πατώντας CTRL+D.

Στη συνέχεια, πρέπει να εκτελέσουμε ξανά το container, παρακάμπτοντας την προεπιλεγμένη εντολή με την εντολή Django collectstatic. Η εντολή θα δημιουργήσει τα στατικά αρχεία για την εφαρμογή και θα τα μεταφορτώσει στο MinIO Cloud Storage:

Η εντολή δημιουργεί και μεταφορτώνει το αρχείο στην ρυθμισμένη υπηρεσία αποθήκευσης αντικειμένων (object storage). Δείτε το αποτέλεσμα:

Μπορείτε τώρα να εκτελέσετε την εφαρμογή χωρίς να καθορίσετε κάποια πρόσθετη εντολή για να παρακάμψετε την προεπιλεγμένη εντολή CMD που ορίζεται στο Dockerfile:

Το Docker εκτελεί την προεπιλεγμένη εντολή που ορίζεται στο Dockerfile, εκκινεί το container με τον διακομιστή gunicorn, εκθέτει τη θύρα του container 8000, και την αντιστοιχίζει στη θύρα του Ubuntu 80. Μπορείτε τώρα να δείτε τη διεπαφή της εφαρμογής στο πρόγραμμα περιήγησής σας, αποκτώντας πρόσβαση στη διεύθυνση IP του πρώτου διακομιστή στη γραμμή διευθύνσεών σας: http://FIRST_SERVER_IP.

Θα λάβετε ένα σφάλμα 404 Page Not Found επειδή δεν έχουμε ορίσει τίποτα για το / διαδρομή. Μεταβείτε στο http://FIRST_SERVER_IP/polls για να δείτε τη διεπαφή των Polls:

Επισκεφθείτε τη διεπαφή διαχειριστή για να δημιουργήσετε μερικές δημοσκοπήσεις: http://FIRST_SERVER_IP/admin:

Παρέχετε τα διαπιστευτήρια που ορίσατε με την εντολή createsuperuser παραπάνω για να αποκτήσετε πρόσβαση στη διεπαφή διαχειριστή:

Αν δείτε τον πηγαίο κώδικα της σελίδας, θα παρατηρήσετε ότι τα στατικά αρχεία ανακτώνται από τον κάδο αποθήκευσης (storage bucket) όπως έχει οριστεί. Αφού επιβεβαιώσετε ότι το κοντέινερ εξυπηρετεί την εφαρμογή όπως αναμένεται, μπορείτε να τερματίσετε το κοντέινερ πατώντας CTRL+C στο τερματικό.

Στη συνέχεια, πρέπει να διατηρήσουμε το κοντέινερ σε λειτουργία σε detached λειτουργία, ώστε να μπορέσουμε να εξέλθουμε από τη συνεδρία SSH του πρώτου διακομιστή. Αυτό θα αφήσει το κοντέινερ να εκτελείται στο παρασκήνιο. Εκτελέστε την ακόλουθη εντολή:

Η σημαία -d εκκινεί το κοντέινερ σε detached λειτουργία, ώστε να μπορεί να παραμείνει σε λειτουργία στο παρασκήνιο. Η σημαία --rm καθαρίζει το σύστημα αρχείων του κοντέινερ μετά την έξοδο του κοντέινερ. Δίνουμε στο κοντέινερ ένα όνομα, polls, ώστε να μπορούμε να το δούμε όταν κάνουμε λίστα των κοντέινερ.

Εξέλθετε από τη συνεδρία SSH του πρώτου σας διακομιστή και μεταβείτε στο http://FIRST_SERVER_IP/polls στο πρόγραμμα περιήγησής σας για να επιβεβαιώσετε ότι λειτουργεί όπως αναμένεται. Εάν μπορείτε να δείτε τη διεπαφή των δημοσκοπήσεων, τότε ο πρώτος διακομιστής εφαρμογών σας έχει ρυθμιστεί με επιτυχία. Ας ρυθμίσουμε τον δεύτερο διακομιστή εφαρμογών στο επόμενο βήμα.

Βήμα 2: Ρύθμιση του δεύτερου διακομιστή εφαρμογών

Θα κλωνοποιήσουμε τον Dockerized κλάδο της εφαρμογής που δημιουργήσαμε στον οδηγό Building a Django and Gunicorn Application with Docker on Ubuntu . Μπορείτε να βρείτε περισσότερες λεπτομέρειες για τις εντολές που θα χρησιμοποιήσουμε εδώ από αυτόν τον οδηγό, ή τη συνοπτική έκδοση στο Βήμα 1.

Θα πρέπει να έχετε τον δεύτερο διακομιστή σε λειτουργία, να έχετε προσθέσει έναν non-root sudo χρήστη και να έχετε εγκαταστήσει το Docker όπως εξηγείται στην ενότητα Προαπαιτούμενα .

Το επόμενο βήμα είναι να διαμορφώσετε αυτόν τον διακομιστή ώστε να συνδέεται στο στιγμιότυπο του διακομιστή PostgreSQL. Όπως εξηγείται στο Βήμα 1 του οδηγού Building a Django and Gunicorn Application with Docker on Ubuntu, πρέπει να επιτρέψετε τη διεύθυνση IP του δεύτερου διακομιστή μέσω του ufw και των ρυθμίσεων της PostgreSQL.

Αρχικά, συνδεθείτε στο στιγμιότυπο του διακομιστή βάσης δεδομένων PostgreSQL με τον non-root sudo χρήστη σας. Για να προσθέσετε τον κανόνα ufw, εκτελέστε την ακόλουθη εντολή:

Στη συνέχεια, εκτελέστε αυτήν την εντολή και προσθέστε τη διεύθυνση IP του δεύτερου διακομιστή στο αρχείο ελέγχου ταυτότητας πελάτη της PostgreSQL:

Διαβάστε τα σχόλια για να κατανοήσετε περισσότερα σχετικά με τις ρυθμίσεις. Στη συνέχεια, προσθέστε αυτή τη γραμμή κάτω από την ενότητα hosts, καθορίζοντας τη διεύθυνση IP σας:

Αποθηκεύστε και κλείστε το αρχείο όταν ολοκληρώσετε την επεξεργασία.

Στη συνέχεια, επανεκκινήστε την υπηρεσία PostgreSQL για να εφαρμοστούν οι αλλαγές:

Αποσυνδεθείτε από το στιγμιότυπο του διακομιστή βάσης δεδομένων PostgreSQL και προχωρήστε στη διαμόρφωση του δεύτερου στιγμιότυπου διακομιστή εφαρμογών.

Συνδεθείτε στον δεύτερο διακομιστή εφαρμογών με ssh. Στη συνέχεια, κλωνοποιήστε τον κλάδο django-polls-κλάδο του αποθετηρίου django-polls με την ακόλουθη εντολή:

Μεταβείτε στον κατάλογο django-polls:

Μετά από αυτό, δημιουργήστε την εικόνα (build) με την ακόλουθη εντολή:

Μόλις ολοκληρωθεί η διαδικασία δημιουργίας της εικόνας, τροποποιήστε το αρχείο env με τις τιμές διαμόρφωσης όπως εξηγείται στο Βήμα 1. Ανοίξτε το αρχείο με το nano:

Αντικαταστήστε τα κείμενα των placeholders με τις πραγματικές τιμές που προσθέσατε στο Βήμα 1. Θυμηθείτε να τροποποιήσετε τη DJANGO_ALLOWED_HOSTS μεταβλητή κατάλληλα. Αποθηκεύστε και κλείστε το αρχείο όταν τελειώσετε. Ενημερώστε τα διαπιστευτήριά σας MinIO στο env  αρχείο όπως κάνατε στο προηγούμενο βήμα.

Τώρα μπορείτε να εκτελέσετε το container της εφαρμογής σε detached mode με την ακόλουθη εντολή:

Η εντολή εκκινεί το container και το διατηρεί σε εκτέλεση στο παρασκήνιο. Εξέλθετε από τη συνεδρία ssh του δεύτερου διακομιστή εφαρμογών και μεταβείτε στο http://SECOND_SERVER_IP/polls στο πρόγραμμα περιήγησής σας για να επιβεβαιώσετε ότι εκτελείται όπως αναμένεται. Θα πρέπει να μπορείτε να δείτε τη διεπαφή των δημοσκοπήσεων (polls) εάν όλα πήγαν όπως αναμενόταν.

Έχετε πλέον δύο διακομιστές εφαρμογών που εκτελούν το ίδιο αντίγραφο της εφαρμογής σας. Στο επόμενο βήμα, θα ρυθμίσετε το Nginx container για να λειτουργεί ως reverse proxy.

Βήμα 3: Ρύθμιση του Nginx Docker Container

Nginx είναι ένα από τα πιο δημοφιλή λογισμικά διακομιστή ιστού ανοιχτού κώδικα στον κόσμο. Είναι υπεύθυνο για τη διασφάλιση της διαθεσιμότητας και της επεκτασιμότητας των ιστότοπων με την υψηλότερη επισκεψιμότητα στο διαδίκτυο. Εγγυάται ασφάλεια και είναι πολύ ευέλικτο. Μπορείτε να το χρησιμοποιήσετε για reverse proxying, caching και load balancing. Έχουμε ρυθμίσει την εφαρμογή μας να χρησιμοποιεί μια ξεχωριστή υπηρεσία αποθήκευσης αντικειμένων (object storage) για τη διαχείριση των στατικών αρχείων και των αρχείων πολυμέσων της. Επομένως, δεν θα χρησιμοποιήσουμε τις λειτουργίες προσωρινής αποθήκευσης (caching) του Nginx. Αντίθετα, θα χρησιμοποιήσουμε τις δυνατότητες reverse proxy και load balancing του Nginx. Ο εξωτερικός διακομιστής Nginx θα λαμβάνει την εισερχόμενη κίνηση και θα τη διανέμει στους διακομιστές εφαρμογών backend. Στη συνέχεια, θα διασφαλίζει την ασφαλή επικοινωνία μεταξύ πελάτη και διακομιστή, ασφαλίζοντας την κίνηση με χρήση πιστοποιητικών SSL που λαμβάνονται από το Let’s Encrypt.

Υπάρχουν διάφοροι τρόποι για την υλοποίηση του Nginx reverse proxying και load balancing. Ένας από τους τρόπους είναι η ρύθμιση του Nginx reverse proxy ξεχωριστά από τον διακομιστή εφαρμογών backend, όπως κάναμε σε αυτόν τον οδηγό. Αυτή η ρύθμιση είναι ευέλικτη και σας επιτρέπει να κλιμακώσετε τόσο το επίπεδο proxy του Nginx όσο και το επίπεδο της εφαρμογής. Μπορείτε να προσθέσετε πολλαπλούς Nginx proxies ή να εφαρμόσετε έναν cloud load balancer. Ένας άλλος τρόπος υλοποίησης reverse proxying είναι η χρήση ενός από τους backend διακομιστές εφαρμογών ως Nginx proxy. Στη συνέχεια, μπορείτε να προωθήσετε τα εισερχόμενα αιτήματα τοπικά και σε άλλους διακομιστές εφαρμογών. Προαιρετικά, μπορείτε να ρυθμίσετε ένα Nginx container σε όλους τους backend διακομιστές εφαρμογών και να ορίσετε έναν cloud load balancer στην πρόσοψη για να λαμβάνει την εισερχόμενη κίνηση και να τη διανέμει στους backend διακομιστές εφαρμογών.

Ας ξεκινήσουμε τη ρύθμιση του διακομιστή μεσολάβησης (proxy). Συνδεθείτε στον τέταρτο διακομιστή Ubuntu που είχατε ορίσει να χρησιμοποιηθεί ως Nginx proxy και δημιουργήστε έναν κατάλογο ρυθμίσεων:

Ανοίξτε ένα αρχείο ρυθμίσεων με το nano μέσα στον κατάλογο:

Στη συνέχεια, προσθέστε την ακόλουθη ρύθμιση στο αρχείο:

Σε αυτό το αρχείο ρυθμίσεων, καθορίζουμε τα server, upstream, και location blocks για να καθοδηγήσουμε το Nginx να ανακατευθύνει τα αιτήματα HTTP σε HTTPS και να κατανείμει τα αιτήματα μεταξύ των δύο διακομιστών εφαρμογών που ρυθμίσαμε στο Βήμα 1 και Βήμα 2. Μπορείτε να βρείτε γενικές πληροφορίες σχετικά με τη δομή του αρχείου ρυθμίσεων Nginx από την επίσημη τεκμηρίωσή του.

Μελετήσαμε τα αρχεία ρυθμίσεων που παρέχονται από το Docker Hub τεκμηρίωση της εικόνας Nginx, Certbot, και Gunicorn για να καταλήξουμε σε αυτό το ελάχιστο αρχείο ρυθμίσεων Nginx. Αν και αυτό προορίζεται μόνο για σκοπούς επίδειξης και για να θέσουμε σε λειτουργία την εγκατάστασή μας, είστε ελεύθεροι να εξερευνήσετε και να πειραματιστείτε με άλλες ρυθμίσεις ακολουθώντας τους οδηγούς του Nginx.

Το block upstream χρησιμοποιείται για τον ορισμό της ομάδας διακομιστών που θα επεξεργάζονται τα εισερχόμενα αιτήματα. Ένα όνομα δίνεται στην ομάδα και καλείται από την οδηγία proxy_pass . Έχουμε ονομάσει το block ως django και καθορίσαμε τις διευθύνσεις IP των δύο backend διακομιστών εφαρμογών:

Έχουμε επίσης ορίσει 3 server blocks. Το πρώτο server block καταγράφει όλα τα αιτήματα που δεν αντιστοιχούν στον τομέα σας και επιστρέφει ένα 444 κωδικό (κλείνει τη σύνδεση χωρίς να στείλει απάντηση στον πελάτη, απορρίπτοντας έτσι κακόβουλα ή κακοσχηματισμένα αιτήματα). Ένα απευθείας αίτημα HTTP στη διεύθυνση IP του διακομιστή σας αντιμετωπίζεται από αυτό το block, καθώς έχει οριστεί ως το default_server:

Το δεύτερο server block διαχειρίζεται τα εισερχόμενα αιτήματα HTTP (θύρα 80) requests και τα ανακατευθύνει σε HTTPS (θύρα 443) χρησιμοποιώντας ανακατεύθυνση HTTP 301:

Το τρίτο server block διαχειρίζεται τώρα τα αιτήματα. Έχει διάφορες οδηγίες και θα ορίσουμε τη σημασία τους παρακάτω.

Έχουμε δύο οδηγίες που ορίζουν τις διαδρομές προς το πιστοποιητικό TLS και το κλειδί, όπως παρέχονται από το Certbot. Τα πιστοποιητικά προσαρτώνται στο container του Nginx κατά την εκκίνησή του:

Στη συνέχεια, έχουμε τις προεπιλογές ασφαλείας SSL όπως συνιστώνται από το Certbot. Μπορείτε να μάθετε περισσότερα από τα επίσημα έγγραφα του Nginx για το ngx_http_ssl_module. Το Mozilla προσφέρει επίσης περισσότερες πληροφορίες σχετικά με την Ασφάλεια στην πλευρά του διακομιστή. Η τιμή ssl_ciphers στο αρχείο conf έχει ληφθεί από τη σελίδα του Mozilla:

Στις επόμενες δύο οδηγίες, θα ορίσουμε το μέγιστο επιτρεπόμενο μέγεθος του σώματος αιτήματος του πελάτη και θα ορίσουμε το χρονικό όριο για τις συνδέσεις keep-alive με τον πελάτη. Ο Nginx θα κλείνει τις συνδέσεις με τον πελάτη μετά τα δευτερόλεπτα που ορίζετε στην οδηγία keepalive_timeout. Μπορείτε να βρείτε περισσότερες πληροφορίες σχετικά με τις Ρυθμίσεις Nginx για την ανάπτυξη του Gunicorn από τα επίσημα έγγραφα:

Στο αρχείο ρυθμίσεων, έχουμε επίσης ορίσει δύο blocks τοποθεσίας. Το πρώτο block διαχειρίζεται τη διαμεσολάβηση των αιτημάτων, όπως ορίζεται με τις οδηγίες proxy. Τα εισερχόμενα αιτήματα προωθούνται μέσω proxy στους upstream django διακομιστές που ορίστηκαν νωρίτερα:

Μπορείτε να βρείτε περισσότερες πληροφορίες σχετικά με τις οδηγίες proxy από το Nginx Module ngx_http_proxy_module και τα έγγραφα τεκμηρίωσης για την ανάπτυξη ενός διακομιστή Gunicorn.

Στο δεύτερο block location, ορίζουμε μια διαδρομή: /well-known/acme-challenge/. Συνήθως χρησιμοποιείται από το Certbot για την επαλήθευση του ονόματος τομέα σας με το Let’s Encrypt πριν από την έκδοση ή την ανανέωση ενός πιστοποιητικού SSL:

Αυτά είναι όλα για το αρχείο ρυθμίσεων του Nginx. Μπορείτε τώρα να αποθηκεύσετε και να κλείσετε το αρχείο μόλις ολοκληρώσετε την επεξεργασία.

Το αρχείο ρυθμίσεων που μόλις ορίσατε μπορεί να χρησιμοποιηθεί για την εκτέλεση ενός container Nginx. Ωστόσο, θα αποτύχει καθώς δεν έχουμε εκδώσει τα πιστοποιητικά SSL από το Let’s Encrypt. Σε αυτόν τον οδηγό, θα χρησιμοποιήσουμε την nginx:1.20.2 έκδοση 1.20.2 της εικόνας Docker από το επίσημο Nginx image repository on Docker Hub.

Μπορείτε να εκτελέσετε την παρακάτω εντολή για να κατεβάσετε την εικόνα και να επαληθεύσετε ότι όλα λειτουργούν σωστά:

Αυτή η εντολή δημιουργεί έναν container με το όνομα nginx και αντιστοιχίζει τις θύρες 80 και 443 μεταξύ του συστήματος υποδοχής και του container. Η σημαία --rm αφαιρεί τυχόν ενδιάμεσους containers μετά από μια επιτυχημένη κατασκευή. Χρησιμοποιούμε τη σημαία -v για να προσαρτήσουμε το αρχείο ρυθμίσεων στον container στο /etc/nginx/conf.d/nginx.conf που είναι ο προεπιλεγμένος κατάλογος ρυθμίσεων του Nginx. Είναι προσαρτημένο σε λειτουργία μόνο για ανάγνωση χρησιμοποιώντας τη σημαία ro για να αποτρέψουμε τον container Nginx από το να το τροποποιήσει. Ορίζουμε τον προεπιλεγμένο κατάλογο webroot και τον προσαρτούμε ως /var/www/html. Ολοκληρώνουμε δίνοντας εντολή στο Docker να χρησιμοποιήσει την εικόνα nginx:1.20.2 για αυτήν την κατασκευή. Ας αποκτήσουμε το πιστοποιητικό TLS/SSL και το κλειδί από το Let’s Encrypt στο επόμενο βήμα.

Βήμα 4: Έκδοση Πιστοποιητικού SSL/TLS από το Let’s Encrypt και Ρύθμιση της Αυτόματης Ανανέωσης του Certbot

Certbot βοηθά στην έκδοση δωρεάν πιστοποιητικών TLS από το Let’s Encrypt καθώς και στη διαχείριση της αυτόματης ανανέωσής τους πριν λήξουν. Αυτό βελτιώνει την ασφάλεια των ιστοτόπων σας και διασφαλίζει ότι εξυπηρετούνται μέσω HTTPS. Στο πλαίσιο της διατήρησης της αρχιτεκτονικής μας σε containers, θα χρησιμοποιήσουμε την εικόνα Docker του Certbot για να λάβουμε τα πιστοποιητικά SSL/TLS και να ρυθμίσουμε την αυτόματη ανανέωση. Βεβαιωθείτε ότι έχετε εγκατεστημένο το Docker στον διακομιστή μεσολάβησης σύμφωνα με τις οδηγίες στις Προϋποθέσεις οδηγίες.

Θα πρέπει επίσης να έχετε μια εγγραφή DNS A του καταχωρημένου ονόματος τομέα σας που να δείχνει στη διεύθυνση IP του διακομιστή μεσολάβησης. Μπορείτε να το επαληθεύσετε εκτελώντας την εικόνα Docker του certbot και περνώντας τη σημαία --staging:

Η εντολή θα κατεβάσει την εικόνα Certbot και θα την εκτελέσει σε διαδραστική λειτουργία. Αυτό σημαίνει ότι θα συνοδεύεται από ένα κέλυφος, επιτρέποντάς σας να εισαγάγετε κάποιες λεπτομέρειες. Αντιστοιχίζει τη θύρα 80 του συστήματος υποδοχής στη θύρα 80 μέσα στον container. Χρησιμοποιούμε τη σημαία -v για να προσαρτήσουμε δύο καταλόγους του συστήματος υποδοχής στον container: /etc/letsencrypt/ και /var/lib/letsencrypt/. Η σημαία --standalone η σημαία καθορίζει ότι θέλουμε η εικόνα Certbot να εκτελείται χωρίς τη χρήση του Nginx. Τέλος, έχουμε τη --staging σημαία η οποία θα κάνει το Certbot να εκτελεστεί στους διακομιστές staging και να επικυρώσει το όνομα τομέα σας.

Εισαγάγετε τη διεύθυνση email σας και αποδεχτείτε τους Όρους Παροχής Υπηρεσιών όταν σας ζητηθεί. Το ακόλουθο είναι το αποτέλεσμα μιας επιτυχούς επικύρωσης:

ανανεώνεται

ΕΠΟΜΕΝΑ ΒΗΜΑΤΑ: Το πιστοποιητικό θα πρέπει να ανανεωθεί πριν λήξει. Το Certbot μπορεί να ανανεώνει αυτόματα το πιστοποιητικό στο παρασκήνιο, αλλά ίσως χρειαστεί να κάνετε κάποια βήματα για να ενεργοποιήσετε αυτήν τη λειτουργία. Ελέγξτε αυτόν τον σύνδεσμο για οδηγίες.

Μπορείτε να δείτε το πιστοποιητικό χρησιμοποιώντας την cat εντολή:

Η παραπάνω εντολή θα πρέπει να εμφανίσει το πιστοποιητικό σας στο τερματικό. Αφού επιβεβαιώσετε ότι το Certbot έχει εκδώσει το πιστοποιητικό σας, μπορείτε τώρα να δοκιμάσετε τις ρυθμίσεις παραμέτρων του Nginx που δημιουργήσατε στο Βήμα 3. Εκτελέστε την παρακάτω εντολή Docker για να εκκινήσετε το κοντέινερ Nginx:

Σε αυτήν την εντολή, χρησιμοποιήσαμε τη -v σημαία για να προσαρτήσουμε τη διαδρομή των καταλόγων πιστοποιητικών SSL/TLS του Let’s Encrypt.

Όταν το κοντέινερ είναι έτοιμο και εκτελείται, ανοίξτε την ιστοσελίδα στο πρόγραμμα περιήγησής σας: http://example_domain.com. Πιθανότατα θα δείτε μια προειδοποίηση ότι ο ιστότοπος δεν είναι ασφαλής:

Αυτό συμβαίνει επειδή είχαμε εκδώσει μόνο δοκιμαστικά πιστοποιητικά (staging) και όχι παραγωγής πιστοποιητικά από το Let’s Encrypt. Ας λάβουμε τα πιστοποιητικά παραγωγής εκτελώντας την ακόλουθη εντολή Certbot χωρίς τη --staging σημαία:

Στο μήνυμα προτροπής, επιβεβαιώστε ότι θέλετε να ανανεώσετε και να αντικαταστήσετε το υπάρχον πιστοποιητικό πληκτρολογώντας 2 και πατήστε ENTER. Αυτό θα πρέπει να εκδώσει ένα έτοιμο για παραγωγή πιστοποιητικό. Τώρα μπορείτε να εκτελέσετε το κοντέινερ Nginx και όλα θα πρέπει να λειτουργούν σωστά:

Μόλις το κοντέινερ τεθεί σε λειτουργία, ανοίξτε ξανά την ιστοσελίδα στο πρόγραμμα περιήγησής σας: http://example_domain.com ξανά. Παρατηρήστε ότι το πρόγραμμα περιήγησής σας ανακατευθύνεται στο HTTPS ακόμα κι αν πληκτρολογήσετε HTTP. Αυτό σημαίνει ότι ο διακομιστής μας στη διαμόρφωση του Nginx καθώς και τα εκδοθέντα πιστοποιητικά SSL/TLS λειτουργούν μια χαρά. Μεταβείτε στη polls  διαδρομή http://example_domain.com/polls καθώς δεν έχουμε ορίσει διαδρομή για την αρχική διαδρομή /. Θα πρέπει να δείτε τη διεπαφή των δημοσκοπήσεων:

Μέχρι στιγμής, έχετε ρυθμίσει με επιτυχία μια έτοιμη για παραγωγή αρχιτεκτονική. Έχετε υλοποιήσει δύο διακομιστές backend που θα επεξεργάζονται τα εισερχόμενα αιτήματα που προωθούνται από τον διακομιστή μεσολάβησης (proxy). Ο διακομιστής μεσολάβησης θα χειρίζεται την εξισορρόπηση φορτίου και την ασφάλεια της κίνησης χρησιμοποιώντας τα παρεχόμενα πιστοποιητικά TLS.

Ωστόσο, θα πρέπει να έχετε κατά νου ότι τα πιστοποιητικά Let’s Encrypt λήγουν σε 90 ημέρες. Επομένως, θα πρέπει να τα ανανεώσετε πριν από το όριο των 90 ημερών. Εφόσον το κοντέινερ Nginx θα εκτελείται, θα πρέπει να χρησιμοποιήσετε τη λειτουργία webroot αντί για τη λειτουργία standalone όταν εκτελείτε την εντολή certbot για την ανανέωση του πιστοποιητικού. Θυμηθείτε ότι είχατε καθορίσει τον κατάλογο /var/www/html/.well-known/acme-challenge/ στο αρχείο ρυθμίσεων του Nginx στο Βήμα 3. Το Certbot θα χρησιμοποιήσει αυτή τη διαδρομή για να αποθηκεύσει τα αρχεία επικύρωσης. Επίσης, ο πελάτης Let’s Encrypt θα καλέσει αυτή τη διαδρομή με αιτήματα επικύρωσης όταν προσπαθήσετε να ανανεώσετε τα πιστοποιητικά. Μόλις ολοκληρωθεί η εκτέλεση της εντολής ανανέωσης, μπορείτε να κάνετε επαναφόρτωση (reload) του Nginx για να εφαρμοστούν οι αλλαγές.

Τερματίστε το κοντέινερ πατώντας CTRL+C στο τερματικό σας, και ας το ξεκινήσουμε ξανά σε detached mode με τη σημαία -d :

Αυτό θα αφήσει το κοντέινερ Nginx να εκτελείται στο παρασκήνιο. Ας δοκιμάσουμε τη διαδικασία ανανέωσης πιστοποιητικού με τη σημαία --dry-run εκτελώντας την παρακάτω εντολή:

Σε αυτήν την εντολή, έχουμε καθορίσει το πρόσθετο --webroot καθώς και τη διαδρομή που θα χρησιμοποιηθεί για αιτήματα επικύρωσης με τη σημαία -w. Καθορίζουμε επίσης τη σημαία --dry-run για να επαληθεύσουμε τη διαδικασία αυτόματης ανανέωσης χωρίς να εκδοθεί πραγματικά πιστοποιητικό.

Θα πρέπει να δείτε ένα παρόμοιο αποτέλεσμα σε μια επιτυχημένη προσομοίωση:

Κάθε φορά που ανανεώνετε ένα πιστοποιητικό για την εφαρμογή σας που εκτελείται, πρέπει να κάνετε επαναφόρτωση του Nginx ώστε το κοντέινερ να αρχίσει να χρησιμοποιεί το νέο πιστοποιητικό. Η ακόλουθη εντολή Docker επαναφορτώνει το κοντέινερ nginx (θυμηθείτε ότι ονομάσαμε το κοντέινερ ως nginx):

Η εντολή στέλνει ένα σήμα Unix HUP στη διεργασία Nginx που εκτελείται μέσα στο κοντέινερ Docker nginx. Αυτό αναγκάζει τον Nginx να επαναφορτώσει τις ρυθμίσεις του και να αρχίσει να χρησιμοποιεί τα ανανεωμένα πιστοποιητικά.

Εφόσον έχουμε εγκαταστήσει TLS/SSL στον διακομιστή μεσολάβησης και ο ιστότοπός μας εξυπηρετείται με HTTPS, πρέπει τώρα να ασφαλίσουμε τους διακομιστές εφαρμογών backend ώστε να επιτρέπουν αιτήματα μόνο από τον διακομιστή μεσολάβησης.

Βήμα 5: Ασφάλιση των Backend Django Διακομιστών από Εξωτερική Πρόσβαση

Ο διακομιστής μεσολάβησης που υλοποιήσατε σε αυτόν τον οδηγό χειρίζεται τον τερματισμό SSL, όπου αποκρυπτογραφεί τη σύνδεση SSL και προωθεί μη κρυπτογραφημένα πακέτα στους διακομιστές εφαρμογών του backend. Εφόσον θα ασφαλίσουμε τους διακομιστές backend έναντι οποιασδήποτε εξωτερικής πρόσβασης, αυτό το επίπεδο ασφάλειας θα πρέπει να λειτουργεί για τις περισσότερες περιπτώσεις. Ωστόσο, εάν αναπτύσσετε εφαρμογές που μεταδίδουν ευαίσθητα δεδομένα, όπως τραπεζικές πληροφορίες ή δεδομένα υγείας, τότε θα πρέπει να εφαρμόσετε κρυπτογράφηση από άκρο σε άκρο.

Σε αυτόν τον οδηγό, οι διακομιστές Gunicorn στο backend προστατεύονται από το Nginx, καθώς δεν προορίζονται για άμεση έκθεση στο διαδίκτυο. Ο διακομιστής μεσολάβησης Nginx είναι σαν μια πύλη προς τους διακομιστές backend, εμποδίζοντας τους εξωτερικούς πελάτες να έχουν άμεση πρόσβαση στους διακομιστές εφαρμογών backend. Θα πρέπει να βεβαιωθείτε ότι όλα τα αιτήματα περνούν μέσα από τον διακομιστή μεσολάβησης. Σε αυτήν την περίπτωση, το Docker τυχαίνει να έχει ένα πρόβλημα όπου παρακάμπτει το ufw κανόνες τείχους προστασίας και ανοίγει θύρες εξωτερικά, κάτι που μπορεί να αφήσει την υποδομή σας μη ασφαλή. Αυτό είναι στην πραγματικότητα προφανές, καθώς ρυθμίσαμε τους διακομιστές εφαρμογών μας στο Βήμα 1 και Βήμα 2 χωρίς να επιτρέψουμε τη θύρα 80 στους ufw κανόνες. Ωστόσο, μπορείτε ακόμα να έχετε πρόσβαση στις ιστοσελίδες όταν επισκέπτεστε οποιαδήποτε από τις δημόσιες διευθύνσεις IP του διακομιστή στο πρόγραμμα περιήγησης. Ένας τρόπος με τον οποίο μπορείτε να διορθώσετε αυτό το πρόβλημα είναι χρησιμοποιώντας το iptables απευθείας χωρίς να περάσετε από το ufw. Μπορείτε να διαβάσετε τα Docker και iptables επίσημα έγγραφα για να μάθετε περισσότερα. Ένας άλλος συνιστώμενος τρόπος είναι η χρήση τειχών προστασίας cloud.

Ας τροποποιήσουμε τις ρυθμίσεις του UFW για να αποκλείσουμε την εξωτερική πρόσβαση σε όλες τις θύρες που ενδέχεται να έχουν ανοιχτεί από το Docker. Όταν αντιστοιχίσαμε τη θύρα του κεντρικού υπολογιστή 80 στη θύρα του κοντέινερ Docker 8000 με τη σημαία -p 80:8000 στην εντολή Docker, ανοίξαμε επίσης άθελά μας τη θύρα 80 στον κεντρικό υπολογιστή. Μπορείτε να απενεργοποιήσετε αυτήν την πρόσβαση τροποποιώντας τη διαμόρφωση του UFW όπως περιγράφεται στο αποθετήριο ufw-docker README.

Ας κάνουμε την αλλαγή για τον πρώτο διακομιστή εφαρμογής Django. Συνδεθείτε στον διακομιστή και ανοίξτε το αρχείο στο /etc/ufw/after.rules με το nano ως χρήστης sudo:

Το αρχείο περιέχει τους ακόλουθους κανόνες ufw :

Προσθέστε το ακόλουθο μπλοκ γραμμών διαμόρφωσης UFW στο κάτω μέρος του αρχείου:

Οι κανόνες που προσθέσατε αποτρέπουν τη δημόσια πρόσβαση στις θύρες που ανοίγει το Docker. Επιπλέον, επιτρέπουν την πρόσβαση από τα 10.0.0.0/8, 172.16.0.0/12, και 192.168.0.0/16 ιδιωτικά εύρη IP. Μπορείτε να διαβάσετε περισσότερες λεπτομέρειες σχετικά με τους κανόνες από το ufw-docker README. Αποθηκεύστε και κλείστε τα αρχεία όταν τελειώσετε την επεξεργασία. Αυτή η εγκατάσταση θα πρέπει να λειτουργεί εάν είχατε δημιουργήσει ένα εικονικό ιδιωτικό δίκτυο νέφους (VPC), με και τους τρεις διακομιστές σας στο VPC, και στη συνέχεια είχατε καθορίσει τις ιδιωτικές IP των διακομιστών Django στην οδηγία upstream του Nginx config αρχείου.

Ωστόσο, χρησιμοποιήσαμε δημόσιες IP και ενδέχεται να μην έχουμε VPC. Επομένως, πρέπει να προσθέσετε έναν κανόνα στο ufw για να επιτρέψετε την κίνηση από τον διακομιστή μεσολάβησης Nginx μέσω της θύρας 80 και των δύο διακομιστών εφαρμογής Django. Μπορείτε να προσθέσετε έναν κανόνα allow στο ufw καθορίζοντας την IP του διακομιστή προέλευσης στη θύρα 80 χρησιμοποιώντας την ακόλουθη εντολή:

Μόλις τελειώσετε με τις τροποποιήσεις, επανεκκινήστε τον διακομιστή εφαρμογής Django για να εφαρμοστούν οι αλλαγές, καθώς η εκτέλεση του sudo ufw reload φαίνεται να αποτυγχάνει να εφαρμόσει τις αλλαγές:

Όταν ο διακομιστής επανεκκινηθεί, ξεκινήστε το container όπως κάνατε στο Βήμα 1 ή Βήμα 2:

Στη συνέχεια, δοκιμάστε να επισκεφθείτε την IP του πρώτου διακομιστή Django στο πρόγραμμα περιήγησης για να δείτε αν εμφανίζει τη διεπαφή Polls: http://FIRST_SERVER_IP/polls. Θα αποτύχει. Τώρα, αποσυνδεθείτε από τον πρώτο διακομιστή και επαναλάβετε τα βήματα που κάνατε εδώ για τον δεύτερο διακομιστή. Ανοίξτε το /etc/ufw/after.rules με το nano ως χρήστης sudo:

Όπως κάνατε προηγουμένως, μετακινηθείτε προς τα κάτω και προσθέστε το μπλοκ ρυθμίσεων UFW:

Αποθηκεύστε και κλείστε το αρχείο αφού προσθέσετε το παραπάνω μπλοκ.

Στη συνέχεια, προσθέστε έναν κανόνα allow στο ufw καθορίζοντας την IP του διακομιστή προέλευσης στη θύρα 80 χρησιμοποιώντας την ακόλουθη εντολή:

Κάντε επανεκκίνηση του διακομιστή σας για να εφαρμοστούν οι αλλαγές:

Όταν ο διακομιστής επανέλθει, εκκινήστε ξανά το container με την εντολή:

Δοκιμάστε αν μπορείτε να δείτε τη διεπαφή των δημοσκοπήσεων (polls) μεταβαίνοντας απευθείας στη διεύθυνση IP του δεύτερου διακομιστή: http://SECOND_SERVER_IP/polls. Θα πρέπει επίσης να αποτύχει.

Αυτή η αρχιτεκτονική είναι τώρα έτοιμη για δοκιμή. Μπορείτε να επισκεφθείτε το https://example_domain_here/polls για να δείτε την προεπιλεγμένη διεπαφή Polls από το πρόγραμμα περιήγησής σας. Αυτό σημαίνει ότι ο διακομιστής μεσολάβησης Nginx εξακολουθεί να έχει πρόσβαση στους διακομιστές backend του Django.

Συμπέρασμα

Σε αυτόν τον οδηγό, σας δείξαμε πώς να υλοποιήσετε μια επεκτάσιμη υποδομή χρησιμοποιώντας Docker containers. Η υποδομή περιλαμβάνει έναν ξεχωριστό διακομιστή βάσης δεδομένων PostgreSQL, δύο διακομιστές εφαρμογών backend και έναν διακομιστή μεσολάβησης Nginx για εξισορρόπηση φορτίου και διανομή της κίνησης στους δύο διακομιστές. Παρόλο που βασίσαμε την εφαρμογή μας στην εφαρμογή Django Polls, μπορείτε να προσαρμόσετε αυτήν την αρχιτεκτονική για διάφορες εφαρμογές χρησιμοποιώντας διαφορετικά frameworks, όπως Node.js, Laravel, κ.λπ.

Αυτή είναι μια βασική κατευθυντήρια γραμμή για να ξεκινήσετε. Μερικές βελτιώσεις που μπορείτε να προσθέσετε είναι να φιλοξενήσετε το image σας σε ένα αποθετήριο εικόνων (image repository) όπως το Docker Hub επιτρέποντας την εύκολη διανομή του image σε πολλαπλούς διακομιστές. Μπορείτε επίσης να προσθέσετε ροές συνεχούς ενοποίησης και ανάπτυξης (continuous integration and deployment pipelines) για αυτόματη κατασκευή, δοκιμή και ανάπτυξη images στους διακομιστές εφαρμογών όποτε συμβαίνει ένα συμβάν. Για παράδειγμα, ένα συμβάν θα μπορούσε να είναι η ώθηση (push) νέου κώδικα σε έναν καθορισμένο κλάδο (branch) σε ένα αποθετήριο git. Ίσως επίσης να θέλετε να αυτοματοποιήσετε τι συμβαίνει όταν το container αντιμετωπίζει σφάλμα. Τα επίσημα έγγραφα του Docker παρέχουν έναν καλό οδηγό σχετικά με την Αυτόματη εκκίνηση containers σε περίπτωση σφαλμάτων ή επανεκκίνησης του συστήματος.

Καλή συνέχεια!