Milióny používateľov sa pripájajú na internet, aby získali prístup k informáciám na rôzne účely vrátane vzdelávania, zábavy, správ a zdieľania pokroku vo svojich životoch’ s priateľmi. Preto je pri nasadzovaní aplikácie vo vašom najlepšom záujme implementovať vysoko bezpečnú a škálovateľnú infraštruktúru pre vašu aplikáciu. Cloud ponúka rôzne spôsoby zabezpečenia a škálovania Django aplikácie. Horizontálne škálovanie je jednou z metód, ktorá vám umožňuje spustiť niekoľko kópií vašej aplikácie. To zaisťuje, že je odolnejšia voči chybám a vysoko dostupná. Zvyšuje to tiež jej výkon pri spracovaní viacerých požiadaviek súčasne.
Horizontálne škálovanie aplikácie Django
Aplikáciu Django môžete horizontálne škálovať spustením niekoľkých aplikačných serverov, na ktorých beží aplikácia Django a jej WSGI HTTP server (napríklad Gunicorn alebo uWSGI). Potom budete musieť nastaviť infraštruktúru na distribúciu prichádzajúcich požiadaviek medzi tieto aplikačné servery. Load balancer a reverzný proxy server ako Nginx môžu vašej infraštruktúre pomôcť s distribúciou prevádzky. Nginx dokáže nasadiť SSL certifikáty zaisťujúce bezpečné pripojenie k vašej aplikácii prostredníctvom HTTPS. V neposlednom rade môže Nginx poskytovať aj ukladanie statického obsahu do vyrovnávacej pamäte, aby sa minimalizovalo zaťaženie vášho servera.
Konfigurácia týchto rôznych komponentov samostatne a zabezpečenie ich vzájomnej komunikácie môže byť náročná úloha. Našťastie, použitie Docker zjednodušuje proces konfigurácie a zaisťuje, že sa rôzne komponenty správajú rovnako bez ohľadu na to, kde sú nasadené.
Čo budete robiť v tejto príručke
V tejto príručke sa naučíte, ako horizontálne škálovať kontajnerizovanú aplikáciu Django, bežiacu s WSGI HTTP serverom Gunicorn. Spustíte dva aplikačné servery, pričom na každom bude nainštalovaný Docker a pobeží na nich rovnaká kópia kontajnera aplikácie Django a Gunicorn.
Svoju aplikáciu tiež zabezpečíte pomocou Let’s Encrypt SSL certifikátu spustením a konfiguráciou tretieho proxy servera , na ktorom pobeží kontajner reverzného proxy servera Nginx a kontajner klienta Certbot. Certbot je balík, ktorý pomáha so správou SSL certifikátov od certifikačnej autority Let’s Encrypt. Získava certifikát, konfiguruje bloky servera Nginx s umiestnením certifikátu a spravuje automatické obnovovanie. Robí to tak, že nakonfiguruje cron úlohu na periodickú kontrolu, či platnosť certifikátu čoskoro nevyprší a či ho netreba obnoviť. Udržiavaním vášho SSL certifikátu v aktualizovanom stave bude mať vaša webová stránka vždy vysoké hodnotenie bezpečnosti na SSL Labs.
Tento tretí proxy server stojí pred vašou distribuovanou architektúrou a prijíma všetku prichádzajúcu externú prevádzku. Potom distribuuje prevádzku na vaše aplikačné servery. Aplikačné servery sú umiestnené za firewallom, ktorý k nim povoľuje prístup iba proxy serveru.
Tento návod je druhým zo série troch návodov na prácu s Django, Docker a Kubernetes. Najprv by ste mali postupovať podľa krokov opísaných v návode na Vytvorenie aplikácie Django a Gunicorn pomocou Dockeru na Ubuntu. V tomto návode sme nastavili základný kód projektu, Dockerfile a pripojili aplikáciu k MinIo Simple Storage Service (S3) na poskytovanie našich statických súborov.
Požiadavky
Na sledovanie tohto návodu budete potrebovať nasledovné:
- Štyri servery Ubuntu 20.04:
Ak ste postupovali podľa krokov v predchádzajúcom návode, Vytvorenie aplikácie Django a Gunicorn pomocou Dockeru na Ubuntu, už máte dva zo štyroch serverov:
-
Na prvom serveri pobeží inštancia databázy PostgreSQL. Postupujte podľa krokov 1 a 2 v návode: Vytvorenie aplikácie Django a Gunicorn pomocou Dockeru na Ubuntu na nastavenie databázy. Konfigurácie Postgres by mali byť upravené tak, aby umožňovali externé pripojenia iba z IP adries vašich aplikačných serverov.
-
Na druhom a treťom serveri budú umiestnené kontajnery pre kód vašej aplikácie. Druhý server by vám už mal bežať z predchádzajúceho návodu. Budeme upravovať jeho firewall tak, aby povoľoval externé pripojenia iba z IP adresy proxy servera. Môžete postupovať podľa krokov 1 až 4 tohto podrobného návodu, ktorý vám pomôže nastaviť váš server Ubuntu na CloudSigma.
-
Ten štvrtý server bude proxy server zabezpečujúci vyvažovanie záťaže a distribúciu prevádzky do dvoch kontajnerov aplikačných serverov.
-
Docker by mal byť nainštalovaný na oboch aplikačných serveroch a na proxy serveri.
Po vykonaní krokov v predbežnom návode, by ste už mali mať Docker nainštalovaný na jednom zo serverov. Môžete postupovať podľa krokov 1, 2 a 3 nášho návodu na inštaláciu a prevádzku Dockeru. Nezabudnite pridať vyššie vytvoreného sudo používateľa do skupiny Docker.
- Získajte registrovaný názov domény a nastavte jeho DNS záznamy tak, aby smerovali na verejnú IP adresu proxy servera. Na demonštračné účely použijeme example_domain.com.
-
Nastavte službu objektového úložiska S3. Použili sme MinIO ako úložnú službu v predbežnom návode. Preto postupujte podľa vysvetlení v Kroku 5 v predbežnom návode na nastavenie vášho MinIO úložného bucketu.
Krok 1: Overenie, či prvý aplikačný server Django funguje
Ako je vysvetlené v časti Požiadavky, táto príručka nasleduje po návode na Vytvorenie aplikácie Django a Gunicorn pomocou Dockeru na Ubuntu. Ak prichádzate z tohto návodu a už ste kroky implementovali, mali by ste mať spustený prvý server. Kód aplikácie je založený na návode na aplikáciu Polls z dokumentácie Django. Je dôležité, aby ste si tieto kroky prečítali, aby ste porozumeli počiatočnému nastaveniu. Ak ste kroky v návode implementovali, môžete tento prvý krok preskočiť.
V opačnom prípade môžete do svojho servera jednoducho naklonovať dockerizovanú vetvu. Začnite prihlásením sa do svojho prvého aplikačného servera a vykonajte nasledujúci git príkaz na naklonovanie django-polls-docker vetvy repozitára django-polls:
|
1 |
git clone --single-branch --branch django-polls-docker --depth 1 https://github.com/jaymoh/django-polls.git |
Ďalej prejdite do adresára django-polls :
cd django-polls
V tomto adresári nájdete Dockerfile používaný Dockerom na zostavenie obrazu aplikácie, adresár django-polls , ktorý obsahuje kód aplikácie v jazyku Python, a súbor env obsahujúci zoznam premenných prostredia, ktoré sa odovzdajú kontajneru pri spustení na úpravu jeho správania. V súbore Dockerfile, definujeme závislosti balíkov Django prostredníctvom súboru requirements.txt file. In addition, we need to declare a port 8000 , ktorý sa použije na prijímanie prichádzajúcej prevádzky, a nastaviť ho na spustenie gunicorn servera s 3 workermi. Ak sa chcete dozvedieť viac o inštrukciách Dockerfile, pozrite si Krok 7 návodu Vytvorenie aplikácie Django a Gunicorn pomocou Dockeru na Ubuntu.
Obraz Docker môžete zostaviť pomocou príkazu:
docker build -t django-polls:v1 .
Po zostavení obrazu Dockerom môžete zobraziť zoznam dostupných obrazov na serveri pomocou nasledujúceho príkazu:
docker images
Tu je výstup po spustení príkazu:
Ďalej musíme upraviť súbor env používaný na konfiguráciu runtime prostredia. Tento súbor sa odovzdá kontajneru Docker pri jeho spúšťaní. Otvorte súbor env v editore nano:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
DJANGO_SECRET_KEY=vas_tajny_kluc DEBUG= DJANGO_LOGLEVEL=info DJANGO_ALLOWED_HOSTS=IP_adresa_vasho_servera DB_ENGINE=postgresql_psycopg2 DB_DATABASE=polls_db DB_USERNAME=hackins DB_PASSWORD=heslo_k_vasej_databaze DB_HOST=hostitel_vasej_databazy DB_PORT=port_vasej_databazy STATIC_DEFAULT_FILE_STORAGE=storages.backends.s3boto3.S3Boto3Storage STATIC_MINIO_BUCKET_NAME=test-bucket MINIO_ACCESS_KEY=your_minio_access_key MINIO_SECRET_KEY=your_minio_secret_key MINIO_URL=your_minio_url:your_minio_port |
Súbor env obsahuje nejaký zástupný text, ktorý musíte upraviť a vyplniť správnymi hodnotami:
-
DJANGO_SECRET_KEY: Vygenerujte jedinečnú, nepredvídateľnú hodnotu, ako je vysvetlené v dokumentácii Django. Na vygenerovanie náhodného reťazca a jeho nastavenie do premennej môžete použiť tento príkaz: python -c 'from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())'.
-
DJANGO_ALLOWED_HOSTS: táto hodnota sa používa na zabezpečenie vašej aplikácie pred útokmi typu HTTP Host Header. Môžete ju nastaviť na *, zástupný znak zodpovedajúci všetkým hostiteľom, ak ste vo vývojovom režime. Keď nasadíte aplikáciu do produkcie, nastavte túto hodnotu na váš registrovaný názov domény. Pre našu ukážku je to example_domain.com.
-
DB_DATABASE: nastavte túto hodnotu na názov databázy PostgreSQL, ktorú ste vytvorili v časti Požiadavky, v našom prípade je to polls_db.
-
DB_USERNAME: nastavte túto hodnotu na používateľské meno, ktoré ste si vybrali pre svoju databázu.
-
DB_PASSWORD: nastavte túto hodnotu na heslo, ktoré ste si vybrali pre svoju databázu.
-
DB_HOST: nastavte túto hodnotu na hostiteľa, na ktorom beží vaša databázová inštancia, ako ste ju nastavili v časti Požiadavky. Toto je vysvetlené v krokoch 1 a 2 návodu Vytvorenie aplikácie Django a Gunicorn pomocou Dockeru na Ubuntu na nastavenie databázy.
-
DB_PORT: nastavte túto hodnotu na port vašej databázy.
Po dokončení úprav súbor uložte a zatvorte. Keď máme prihlasovacie údaje k databáze na svojom mieste, môžeme vytvoriť databázovú schému spustením kontajnera a prepísaním príkazu CMD nastaveného v Dockerfile. Viac informácií nájdete v vstupnom bode Dockerfile z oficiálnej dokumentácie. Ďalej spustite nasledujúci príkaz:
|
1 |
docker run --env-file env django-polls:v1 sh -c "python manage.py makemigrations && python manage.py migrate" |
V tomto príkaze spúšťame obraz django-polls:v1 a odovzdávame mu súbor env upravený predtým. Časť: sh -c "python manage.py makemigrations && python manage.py migrate” vytvorí databázovú schému definovanú kódom aplikácie. Ak príkaz spúšťate prvýkrát, mali by ste vidieť podobný výstup indikujúci vytvorenie databázovej schémy:
Po vytvorení schémy môžeme vytvoriť superpoužívateľa Django. Spustením nasledujúceho príkazu spustite kontajner s interaktívnym shellom:
|
1 |
docker run -i -t --env-file env django-polls:v1 sh |
Príkaz spustí kontajner s príkazovým riadkom shellu, ktorý môžete použiť na interakciu s Python shellom. Vytvorme používateľa pomocou nasledujúceho príkazu:
|
1 |
python manage.py createsuperuser |
Podľa výziev zadajte používateľské meno, e-mailovú adresu a heslo. Znova zadajte heslo a stlačením klávesu Enter vytvorte používateľa. Ukončite shell a vypnite kontajner stlačením CTRL+D.
Ďalej musíme kontajner spustiť znova a prepísať predvolený príkaz príkazom Django collectstatic . Tento príkaz vygeneruje statické súbory pre aplikáciu a nahrá ich do úložiska MinIO Cloud Storage:
|
1 |
docker run --env-file env django-polls:v1 sh -c "python manage.py collectstatic --noinput" |
Príkaz vygeneruje a nahrá súbor do vašej nakonfigurovanej služby objektového úložiska. Tu je výstup:
Teraz môžete spustiť aplikáciu bez zadania akéhokoľvek ďalšieho príkazu na prepísanie predvoleného príkazu CMD definovaného v Dockerfile:
|
1 |
docker run --env-file env -p 80:8000 django-polls:v1 |
Docker spustí predvolený príkaz definovaný v Dockerfile, spustí kontajner so serverom gunicorn, sprístupní port kontajnera 8000 a namapuje ho na port Ubuntu 80. Rozhranie aplikácie si teraz môžete zobraziť v prehliadači zadaním IP adresy prvého servera do adresného riadka: http://FIRST_SERVER_IP.
Zobrazí sa vám 404 Stránka nenájdenápretože sme nedefinovali nič pre / cestu. Prejdite na http://FIRST_SERVER_IP/polls pre zobrazenie rozhrania ankiet:
Navštívte administrátorské rozhranie a vytvorte nejaké ankety: http://FIRST_SERVER_IP/admin:
Zadajte prihlasovacie údaje, ktoré ste nastavili pomocou príkazu createsuperuser vyššie, aby ste získali prístup k administrátorskému rozhraniu:
Ak si zobrazíte zdrojový kód stránky, všimnete si, že statické súbory sa načítavajú z úložiska (storage bucket) tak, ako je definované. Po overení, že kontajner poskytuje aplikáciu podľa očakávania, môžete kontajner ukončiť stlačením CTRL+C v termináli.
Ďalej musíme nechať kontajner bežať v detached režime, aby sme mohli ukončiť SSH reláciu prvého servera. Tým zostane kontajner bežať na pozadí. Spustite nasledujúci príkaz:
|
1 |
docker run -d --rm --name polls --env-file env -p 80:8000 django-polls:v1 |
Príznak -d spustí kontajner v detached režime, takže môže naďalej bežať na pozadí. Príznak --rm vymaže súborový systém kontajnera po jeho ukončení. Kontajneru dáme názov polls, aby sme ho videli, keď vypíšeme zoznam kontajnerov.
Ukončite SSH reláciu vášho prvého servera a prejdite na http://FIRST_SERVER_IP/polls vo vašom prehliadači, aby ste potvrdili, že beží podľa očakávania. Ak vidíte rozhranie ankiet, váš prvý aplikačný server bol úspešne nastavený. V ďalšom kroku nastavíme druhý aplikačný server.
Krok 2: Nastavenie druhého aplikačného servera
Budeme klonovať dockerizovanú vetvu aplikácie, ktorú sme vytvorili v návode Building a Django and Gunicorn Application with Docker on Ubuntu . Podrobnejšie informácie o príkazoch, ktoré tu použijeme, nájdete v tomto návode alebo v zhrnutej verzii v Kroku 1.
Mali by ste mať spustený druhý server, pridaného sudo používateľa, ktorý nie je root, a nainštalovaný Docker, ako je vysvetlené v časti Požiadavky.
Ďalším krokom je konfigurácia tohto servera na pripojenie k inštancii PostgreSQL servera. Ako je vysvetlené v Kroku 1 návodu Building a Django and Gunicorn Application with Docker on Ubuntu, musíte povoliť IP adresu druhého servera cez ufw a konfigurácie PostgreSQL.
Najprv sa prihláste do inštancie databázového servera PostgreSQL pomocou vášho sudo používateľa, ktorý nie je root. Ak chcete pridať pravidlo ufw, spustite nasledujúci príkaz:
|
1 |
sudo ufw allow from SECOND_SERVER_IP to any port 5432 |
Ďalej spustite tento príkaz a pridajte IP adresu druhého servera do súboru overovania klientov PostgreSQL:
|
1 |
sudo nano /etc/postgresql/12/main/pg_hba.conf |
Prečítajte si komentáre, aby ste lepšie porozumeli konfiguráciám. Ďalej pridajte tento riadok pod sekciu hosts a špecifikujte svoju IP adresu:
|
1 |
host all all SECOND_SERVER_IP/24 md5 |
Po dokončení úprav súbor uložte a zatvorte.
Potom reštartujte službu PostgreSQL, aby sa zmeny prejavili:
|
1 |
sudo service postgresql restart |
Odhláste sa z inštancie databázového servera PostgreSQL a pokračujte v konfigurácii druhej inštancie aplikačného servera.
Prihláste sa na druhý aplikačný server pomocou ssh. Potom naklonujte vetvu django-polls-vetvu repozitára django-polls pomocou nasledujúceho príkazu:
|
1 2 |
git clone --single-branch --branch django-polls-docker --depth 1 https://github.com/jaymoh/django-polls.git |
Prejdite do adresára django-polls:
|
1 |
cd django-polls |
Potom zostavte obraz pomocou nasledujúceho príkazu:
|
1 |
docker build -t django-polls:v1 . |
Po dokončení procesu zostavenia obrazu upravte súbor env s konfiguračnými hodnotami, ako je vysvetlené v Kroku 1. Otvorte súbor pomocou nano:
|
1 |
nano env |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
DJANGO_SECRET_KEY=vas_tajny_kluc DEBUG= DJANGO_LOGLEVEL=info DJANGO_ALLOWED_HOSTS=IP_adresa_vasho_servera DB_ENGINE=postgresql_psycopg2 DB_DATABASE=polls_db DB_USERNAME=hackins DB_PASSWORD=heslo_vasej_databazy DB_HOST=host_vasej_databazy DB_PORT=port_vasej_databazy STATIC_DEFAULT_FILE_STORAGE=storages.backends.s3boto3.S3Boto3Storage STATIC_MINIO_BUCKET_NAME=test-bucket MINIO_ACCESS_KEY=vas_minio_access_key MINIO_SECRET_KEY=vas_minio_secret_key MINIO_URL=vas_minio_url:vas_minio_port |
Nahraďte texty zástupných symbolov skutočnými hodnotami, ktoré ste pridali v Kroku 1. Nezabudnite upraviť premennú DJANGO_ALLOWED_HOSTS vhodným spôsobom. Po dokončení súbor uložte a zatvorte. Aktualizujte svoje prihlasovacie údaje pre MinIO v súbore env rovnako, ako ste to urobili v predchádzajúcom kroku.
Teraz môžete spustiť kontajner aplikácie v odpojenom režime (detached mode) pomocou nasledujúceho príkazu:
|
1 |
docker run -d --rm --name polls --env-file env -p 80:8000 django-polls:v1 |
Príkaz spustí kontajner a nechá ho bežať na pozadí. Ukončite reláciu ssh druhého aplikačného servera a prejdite na http://SECOND_SERVER_IP/polls vo vašom prehliadači, aby ste potvrdili, že beží podľa očakávania. Ak všetko prebehlo podľa očakávania, mali by ste vidieť rozhranie ankiet.
Teraz máte dva aplikačné servery, na ktorých beží rovnaká kópia vašej aplikácie. V ďalšom kroku nakonfigurujete kontajner Nginx tak, aby slúžil ako reverzný proxy server.
Krok 3: Nastavenie Docker kontajnera Nginx
Nginx je jedným z najpopulárnejších open-source webových serverov na svete. Je zodpovedný za zabezpečenie dostupnosti a škálovateľnosti webov s najvyššou návštevnosťou na internete. Zaručuje bezpečnosť a je veľmi všestranný. Môžete ho použiť na reverzné proxy, cachovanie a vyvažovanie záťaže. Našu aplikáciu sme nastavili tak, aby na správu statických a mediálnych súborov využívala samostatnú službu objektového úložiska. Preto nebudeme používať funkcie cachovania Nginx. Namiesto toho využijeme možnosti reverzného proxy a vyvažovania záťaže Nginx. Server Nginx otočený smerom von bude prijímať prichádzajúcu prevádzku a distribuovať ju na backendové aplikačné servery. Následne zabezpečí bezpečnú komunikáciu medzi klientom a serverom zabezpečením prevádzky pomocou SSL certifikátov získaných od Let’s Encrypt.
Existuje niekoľko spôsobov, ako implementovať reverzné proxy a vyvažovanie záťaže Nginx. Jedným zo spôsobov je nastavenie reverzného proxy Nginx oddelene od backendového aplikačného servera, ako sme to urobili v tomto návode. Toto nastavenie je flexibilné a umožňuje škálovať vrstvu proxy Nginx, ako aj aplikačnú vrstvu. Môžete pridať viacero proxy serverov Nginx alebo implementovať cloudový nástroj na vyvažovanie záťaže. Ďalším spôsobom implementácie reverzného proxy je použitie jedného z backendových aplikačných serverov ako proxy Nginx. Potom môžete prichádzajúce požiadavky smerovať lokálne aj na iné aplikačné servery. Voliteľne môžete nakonfigurovať kontajner Nginx na všetkých backendových aplikačných serveroch a nastaviť cloudový nástroj na vyvažovanie záťaže pred nimi, ktorý bude prijímať prichádzajúcu prevádzku a distribuovať ju na backendové aplikačné servery.
Začnime s konfiguráciou proxy servera. Prihláste sa na štvrtý server Ubuntu, ktorý ste určili na použitie ako proxy Nginx, a vytvorte konfiguračný adresár:
|
1 |
mkdir conf |
Otvorte konfiguráciu pomocou nano vo vnútri adresára:
|
1 |
nano conf/nginx.conf |
Ďalej do súboru pridajte nasledujúcu konfiguráciu:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
upstream django { server FIRST_SERVER_IP; server SECOND_SERVER_IP; } server { listen 80 default_server; return 444; } server { listen 80; listen [::]:80; server_name example_domain.com; return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name example_domain.com; # SSL ssl_certificate /etc/letsencrypt/live/example_domain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example_domain.com/privkey.pem; ssl_session_cache shared:le_nginx_SSL:10m; ssl_session_timeout 1440m; ssl_session_tickets off; ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers off; ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384"; client_max_body_size 4G; keepalive_timeout 5; location / { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Host $http_host; proxy_redirect off; proxy_pass http://django; } location ^~ /.well-known/acme-challenge/ { root /var/www/html; } } |
V tomto konfiguračnom súbore špecifikujeme server, upstream, a location bloky, ktoré inštruujú Nginx, aby presmeroval HTTP požiadavky na HTTPS a distribuoval požiadavky medzi dva aplikačné servery, ktoré sme nastavili v Kroku 1 a Kroku 2. Všeobecné informácie o štruktúre konfiguračného súboru Nginx nájdete v ich oficiálnej dokumentácii.
Preštudovali sme si konfiguračné súbory poskytované Docker Hub dokumentáciou k obrazu Nginx, Certbot, a Gunicorn na vytvorenie tohto minimálneho konfiguračného súboru Nginx. Aj keď je to len na demonštračné účely a na spustenie nášho nastavenia, môžete slobodne skúmať a experimentovať s inými konfiguráciami podľa príručiek pre Nginx.
Blok upstream sa používa na definovanie skupiny serverov, ktoré budú spracovávať prichádzajúce požiadavky. Skupine sa priradí názov a volá ju direktíva proxy_pass. Blok sme pomenovali ako django a špecifikovali sme IP adresy dvoch backendových aplikačných serverov:
|
1 2 3 4 |
upstream django { server FIRST_SERVER_IP; server SECOND_SERVER_IP; } |
Definovali sme tiež 3 bloky servera. Prvý blok servera zachytáva všetky požiadavky, ktoré nezodpovedajú vašej doméne, a vracia 444 kód (zatvorí spojenie bez odoslania odpovede klientovi, čím odmietne škodlivé alebo nesprávne naformátované požiadavky). Priama požiadavka HTTP na IP adresu vášho servera je spracovaná týmto blokom, keďže je definovaný ako default_server:
|
1 2 3 4 |
server { listen 80 default_server; return 444; } |
The Druhý blok servera spracováva prichádzajúce požiadavky HTTP (port 80) a presmerováva ich na HTTPS (port 443) pomocou presmerovania HTTP 301:
|
1 2 3 4 5 6 |
server { listen 80; listen [::]:80; server_name example_domain.com; return 301 https://$server_name$request_uri; } |
Tretí blok servera teraz spracováva požiadavky. Má niekoľko direktív a ich dôležitosť si definujeme nižšie.
Máme dve direktívy definujúce cesty k certifikátu TLS a kľúču, ako ich poskytol Certbot. Certifikáty sa namontujú do kontajnera Nginx pri jeho spustení:
|
1 2 3 |
# SSL ssl_certificate /etc/letsencrypt/live/example_domain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example_domain.com/privkey.pem; |
Ďalej tu máme predvolené nastavenia zabezpečenia SSL odporúčané nástrojom Certbot. Viac sa môžete dozvedieť v oficiálnej dokumentácii Nginx o module ngx_http_ssl_module. Mozilla tiež ponúka viac informácií o zabezpečení na strane servera. Hodnota ssl_ciphers v súbore conf je prevzatá zo stránky spoločnosti Mozilla:
|
1 2 3 4 5 6 |
ssl_session_cache shared:le_nginx_SSL:10m; ssl_session_timeout 1440m; ssl_session_tickets off; ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers off; ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384"; |
V nasledujúcich dvoch direktívach definujeme maximálnu povolenú veľkosť tela požiadavky klienta a nastavíme časový limit pre keep-alive spojenia s klientom. Nginx ukončí spojenie s klientom po uplynutí sekúnd, ktoré nastavíte v direktíve keepalive_timeout. Viac informácií o konfiguráciách Nginx pre nasadenie Gunicorn nájdete v oficiálnej dokumentácii:
|
1 2 |
client_max_body_size 4G; keepalive_timeout 5; |
V konfiguračnom súbore máme tiež definované dva bloky location. Prvý blok spracováva proxy požiadaviek, ako je definované pomocou proxy direktív. Prichádzajúce požiadavky sú smerované cez proxy na upstream django servery definované skôr:
|
1 2 3 4 5 6 7 |
location / { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Host $http_host; proxy_redirect off; proxy_pass http://django; } |
Viac informácií o proxy direktívach nájdete v Nginx Module ngx_http_proxy_module a v dokumentácii k nasadeniu servera Gunicorn.
V druhom bloku location definujeme cestu: /well-known/acme-challenge/. Zvyčajne ho používa Certbot na overenie vášho doménového mena v službe Let’s Encrypt pred vygenerovaním alebo obnovením SSL certifikátu:
|
1 2 3 |
location ^~ /.well-known/acme-challenge/ { root /var/www/html; } |
To je pre konfiguračný súbor Nginx všetko. Po dokončení úprav môžete súbor uložiť a zatvoriť.
Práve definovaný konfiguračný súbor možno použiť na spustenie kontajnera Nginx. To však zlyhá, pretože sme ešte nevygenerovali SSL certifikáty od Let’s Encrypt. V tomto návode použijeme nginx:1.20.2 verziu Docker obrazu 1.20.2 z oficiálneho úložiska obrazov Nginx na Docker Hub.
Spustením príkazu nižšie môžete stiahnuť obraz a overiť, či všetko funguje správne:
|
1 2 3 4 |
docker run --rm --name nginx -p 80:80 -p 443:443 \ -v ~/conf/nginx.conf:/etc/nginx/conf.d/nginx.conf:ro \ -v /var/www/html:/var/www/html \ nginx:1.20.2 |
Tento príkaz vytvorí kontajner s názvom nginx a mapuje porty 80 a 443 medzi hostiteľským systémom a kontajnerom. Príznak --rm odstráni všetky dočasné kontajnery po úspešnom zostavení. Používame príznak -v na pripojenie konfiguračného súboru do kontajnera v /etc/nginx/conf.d/nginx.conf, čo je predvolený adresár pre konfigurácie Nginx. Je pripojený v režime len na čítanie pomocou príznaku ro, aby sa zabránilo kontajneru Nginx v jeho úprave. Nastavíme predvolený adresár webroot a pripojíme ho ako /var/www/html. Na záver inštruujeme Docker, aby pre toto zostavenie použil obraz nginx:1.20.2 . V ďalšom kroku získame TLS/SSL certifikát a kľúč od Let’s Encrypt.
Krok 4: Vygenerovanie SSL/TLS certifikátu od Let’s Encrypt a konfigurácia automatického obnovovania Certbot
Certbot pomáha generovať bezplatné TLS certifikáty od Let’s Encrypt a tiež spravovať ich automatické obnovovanie pred vypršaním ich platnosti. To zvyšuje bezpečnosť vašich webových stránok a zabezpečuje, že sú poskytované cez HTTPS. V súlade s udržiavaním našej architektúry v kontajneroch budeme na získanie SSL/TLS certifikátov a konfiguráciu automatického obnovovania používať Docker obraz Certbot. Uistite sa, že máte Docker nainštalovaný na vašom proxy serveri podľa pokynov v časti Požiadavky.
Mali by ste mať tiež DNS záznam typu A pre váš registrovaný doménový názov smerujúci na IP adresu vášho proxy servera. Overiť to môžete spustením Docker obrazu certbot a odovzdaním príznaku --staging:
|
1 2 3 4 |
docker run -it --rm -p 80:80 --name certbot \ -v "/etc/letsencrypt:/etc/letsencrypt" \ -v "/var/lib/letsencrypt:/var/lib/letsencrypt" \ certbot/certbot certonly --standalone --staging -d example_domain.com |
Tento príkaz stiahne obraz Certbot a spustí ho v interaktívnom režime. To znamená, že bude spustený so shellom, čo vám umožní zadať niektoré údaje. Mapuje port 80 hostiteľa na port 80 vo vnútri kontajnera. Používame príznak -v na pripojenie dvoch adresárov hostiteľa do kontajnera: /etc/letsencrypt/ a /var/lib/letsencrypt/. Príznak --standalone príznak špecifikuje, že chceme, aby obraz Certbot bežal bez použitia Nginx. Nakoniec tu máme --staging príznak, ktorý spustí Certbot na staging serveroch a overí váš názov domény.
Zadajte svoju e-mailovú adresu a prijmite Zmluvné podmienky po výzve. Nasleduje výstup úspešného overenia:
|
1 2 3 4 5 6 7 |
Účet zaregistrovaný. Žiada sa o certifikát pre example_domain.com Úspešne prijatý certifikát. Certifikát je uložený v: /etc/letsencrypt/live/example_domain.com/fullchain.pem Kľúč je uložený v: /etc/letsencrypt/live/example_domain.com/privkey.pem Tento certifikát expiruje dňa 2022-04-29. Tieto súbory budú byť aktualizované keď sa certifikát obnoví. |
ĎALŠIE KROKY:
Certifikát bude potrebné obnoviť pred uplynutím jeho platnosti. Certbot môže automaticky obnovovať certifikát na pozadí, ale možno budete musieť vykonať kroky na povolenie tejto funkcie. Pozrite si tento odkaz pre inštrukcie.
Certifikát si môžete zobraziť pomocou príkazu cat:
|
1 |
sudo cat /etc/letsencrypt/live/example_domain.com/fullchain.pem |
Vyššie uvedený príkaz by mal zobraziť váš certifikát v termináli. Po potvrdení, že Certbot úspešne vygeneroval váš certifikát, môžete teraz otestovať konfiguráciu Nginx, ktorú ste vytvorili v Kroku 3. Spustením nižšie uvedeného príkazu Docker spustite kontajner Nginx:
|
1 2 3 4 5 6 |
docker run --rm --name nginx -p 80:80 -p 443:443 \ -v ~/conf/nginx.conf:/etc/nginx/conf.d/nginx.conf:ro \ -v /etc/letsencrypt:/etc/letsencrypt \ -v /var/lib/letsencrypt:/var/lib/letsencrypt \ -v /var/www/html:/var/www/html \ nginx:1.20.2 |
V tomto príkaze sme použili príznak -v na pripojenie umiestnenia adresárov s certifikátmi SSL/TLS od Let’s Encrypt.
Keď je kontajner spustený a beží, otvorte webovú stránku vo svojom prehliadači: http://example_domain.com. Pravdepodobne uvidíte upozornenie, že webová stránka nie je zabezpečená:
Je to preto, že sme vygenerovali iba staging/testovacie certifikáty a nie produkčné certifikáty od Let’s Encrypt. Získajme produkčné certifikáty spustením nasledujúceho príkazu Certbot bez príznaku --staging príznaku:
|
1 2 3 4 |
docker run -it --rm -p 80:80 --name certbot \ -v "/etc/letsencrypt:/etc/letsencrypt" \ -v "/var/lib/letsencrypt:/var/lib/letsencrypt" \ certbot/certbot certonly --standalone -d example_domain.com |
Vo výzve potvrďte, že chcete obnoviť a nahradiť existujúci certifikát zadaním 2 a stlačením ENTER. To by malo vygenerovať certifikát pripravený na produkciu. Teraz môžete spustiť kontajner Nginx a všetko by malo fungovať správne:
|
1 2 3 4 5 6 |
docker run --rm --name nginx -p 80:80 -p 443:443 \ -v ~/conf/nginx.conf:/etc/nginx/conf.d/nginx.conf:ro \ -v /etc/letsencrypt:/etc/letsencrypt \ -v /var/lib/letsencrypt:/var/lib/letsencrypt \ -v /var/www/html:/var/www/html \ nginx:1.20.2 |
Keď je kontajner spustený a beží, znova otvorte webovú stránku vo svojom prehliadači: http://example_domain.com znova. Všimnite si, že váš prehliadač je presmerovaný na HTTPS, aj keď zadáte HTTP. To znamená, že náš server v konfigurácii Nginx, ako aj vygenerované SSL/TLS certifikáty fungujú správne. Prejdite na trasu polls route http://example_domain.com/polls, keďže nemáme definovanú trasu pre domovskú cestu /. Mali by ste vidieť rozhranie ankiet:
Doteraz ste úspešne nakonfigurovali architektúru pripravenú na produkciu. Implementovali ste dva backendové servery, ktoré budú spracovávať prichádzajúce požiadavky smerované cez proxy server. Proxy server sa postará o vyrovnávanie záťaže a zabezpečenie prevádzky pomocou poskytnutých TLS certifikátov.
Mali by ste však mať na pamäti, že platnosť certifikátov Let’s Encrypt vyprší po 90 dňoch. Preto by ste ich mali obnoviť pred uplynutím tejto 90-dňovej lehoty. Keďže kontajner Nginx bude spustený, mali by ste použiť režim webroot namiesto režimu standalone pri spustení príkazu certbot na obnovenie certifikátu. Nezabudnite, že ste v konfiguračnom súbore Nginx v /var/www/html/.well-known/acme-challenge/ špecifikovali adresár Step 3. Certbot použije túto cestu na uloženie overovacích súborov. Klient Let’s Encrypt bude tiež volať túto cestu s overovacími požiadavkami, keď sa pokúsite obnoviť certifikáty. Po dokončení vykonávania príkazu na obnovenie môžete znova načítať Nginx, aby sa zmeny prejavili.
Ukončite kontajner stlačením CTRL+C vo vašom termináli a poďme ho znova spustiť v odpojenom režime s príznakom -d :
|
1 2 3 4 5 6 |
docker run --rm --name nginx -d -p 80:80 -p 443:443 \ -v ~/conf/nginx.conf:/etc/nginx/conf.d/nginx.conf:ro \ -v /etc/letsencrypt:/etc/letsencrypt \ -v /var/lib/letsencrypt:/var/lib/letsencrypt \ -v /var/www/html:/var/www/html \ nginx:1.20.2 |
Týmto zostane kontajner Nginx spustený na pozadí. Otestujme postup obnovenia certifikátu s príznakom --dry-run spustením príkazu nižšie:
|
1 2 3 4 5 |
docker run -it --rm --name certbot \ -v "/etc/letsencrypt:/etc/letsencrypt" \ -v "/var/lib/letsencrypt:/var/lib/letsencrypt" \ -v "/var/www/html:/var/www/html" \ certbot/certbot renew --webroot -w /var/www/html --dry-run |
V tomto príkaze sme špecifikovali plugin --webroot ako aj cestu, ktorá sa má použiť pre overovacie požiadavky pomocou príznaku -w. Tiež špecifikujeme príznak --dry-run na overenie postupu automatického obnovenia bez skutočného vystavenia certifikátu.
Pri úspešnej simulácii by ste mali vidieť podobný výstup:
|
1 2 3 4 5 6 7 8 |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Spracováva sa /etc/letsencrypt/renewal/example_domain.com.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Simuluje sa obnovenie of an existujúceho certifikátu pre example_domain.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gratulujeme, všetky simulované obnovenia uspeli: /etc/letsencrypt/live/hackinroms.com/fullchain.pem (úspech) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
Vždy, keď obnovíte certifikát pre vašu spustenú aplikáciu, musíte znova načítať Nginx, aby kontajner začal používať nový certifikát. Nasledujúci príkaz Docker znova načíta kontajner nginx (nezabudnite, že sme kontajner pomenovali ako nginx):
|
1 |
docker kill -s HUP nginx |
Príkaz odošle Unix signál HUP procesu Nginx bežiacemu vo vnútri Docker kontajnera nginx. To spôsobí, že Nginx znova načíta svoje konfigurácie a začne používať obnovené certifikáty.
Keďže máme na našom proxy serveri nainštalovaný TLS/SSL a naša webová stránka je poskytovaná prostredníctvom HTTPS, teraz musíme zabezpečiť naše backendové aplikačné servery tak, aby povoľovali iba požiadavky z proxy servera.
Krok 5: Zabezpečenie backendových serverov Django pred externým prístupom
Proxy server, ktorý ste implementovali v tomto návode, spracováva ukončenie SSL (SSL termination), kde dešifruje SSL spojenie a preposiela nešifrované pakety na aplikačné servery v pozadí (backend). Keďže servery v pozadí zabezpečíme proti akémukoľvek externému prístupu, táto úroveň zabezpečenia by mala vo väčšine prípadov postačovať. Ak však nasadzujete aplikácie, ktoré prenášajú citlivé údaje, ako sú bankové informácie alebo zdravotné údaje, mali by ste implementovať end-to-end šifrovanie.
V tomto návode sú servery Gunicorn v pozadí chránené serverom Nginx, keďže nie sú určené na priamy kontakt s verejnosťou. Proxy server Nginx funguje ako brána k serverom v pozadí a zabraňuje externým klientom v priamom prístupe k aplikačným serverom v pozadí. Mali by ste sa uistiť, že všetky požiadavky prechádzajú cez proxy server. Vzhľadom na to má Docker problém, pri ktorom obchádza ufw pravidlá firewallu a otvára porty navonok, čo môže ponechať vašu infraštruktúru nezabezpečenú. To je zrejmé aj z toho, že sme naše aplikačné servery nastavili v Kroku 1 a Kroku 2 bez povolenia portu 80 v ufw pravidlách. Napriek tomu však môžete pristupovať k webovým stránkam, keď v prehliadači navštívite ktorúkoľvek z verejných IP adries servera. Jedným zo spôsobov, ako tento problém vyriešiť, je použiť iptables priamo bez toho, aby ste prechádzali cez ufw. Viac informácií nájdete v Docker a iptables oficiálnej dokumentácii. Ďalším odporúčaným spôsobom je použitie cloudových firewallov.
Upravme konfiguráciu UFW tak, aby sme zablokovali externý prístup ku všetkým portom, ktoré mohol Docker otvoriť. Keď sme namapovali port hostiteľa 80 na port kontajnera Docker 8000 s príznakom -p 80:8000 v príkaze Docker, neúmyselne sme tým otvorili aj port 80 na hostiteľskom stroji. Tento prístup môžete zakázať úpravou konfigurácie UFW, ako je popísané v README pre repozitár ufw-docker.
Urobme túto zmenu pre prvý aplikačný server Django. Prihláste sa na server a otvorte súbor v /etc/ufw/after.rules pomocou nano ako sudo používateľ:
|
1 |
sudo nano /etc/ufw/after.rules |
Súbor obsahuje nasledujúce pravidlá ufw:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
# # rules.input-after # # Pravidlá, ktoré by sa mali spustiť po pravidlách pridaných cez príkazový riadok ufw. Vlastné # pravidlá by mali byť pridané do jedného z týchto reťazcov: # ufw-after-input # ufw-after-output # ufw-after-forward # # Nemažte tieto požadované riadky, inak dôjde k chybám *filter :ufw-after-input - [0:0] :ufw-after-output - [0:0] :ufw-after-forward - [0:0] # Koniec požadovaných riadkov # predvolene nezaznamenávať hlučné služby -A ufw-after-input -p udp --dport 137 -j ufw-skip-to-policy-input -A ufw-after-input -p udp --dport 138 -j ufw-skip-to-policy-input -A ufw-after-input -p tcp --dport 139 -j ufw-skip-to-policy-input -A ufw-after-input -p tcp --dport 445 -j ufw-skip-to-policy-input -A ufw-after-input -p udp --dport 67 -j ufw-skip-to-policy-input -A ufw-after-input -p udp --dport 68 -j ufw-skip-to-policy-input # nezaznamenávať hlučné všesmerové vysielanie (broadcast) -A ufw-after-input -m addrtype --dst-type BROADCAST -j ufw-skip-to-policy-input # nemažte riadok 'COMMIT', inak sa tieto pravidlá nespracujú COMMIT |
Na koniec súboru pridajte nasledujúci blok konfiguračných riadkov UFW:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
# BEGIN UFW AND DOCKER *filter :ufw-user-forward - [0:0] :DOCKER-USER - [0:0] -A DOCKER-USER -j RETURN -s 10.0.0.0/8 -A DOCKER-USER -j RETURN -s 172.16.0.0/12 -A DOCKER-USER -j RETURN -s 192.168.0.0/16 -A DOCKER-USER -p udp -m udp --sport 53 --dport 1024:65535 -j RETURN -A DOCKER-USER -j ufw-user-forward -A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16 -A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8 -A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12 -A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 192.168.0.0/16 -A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 10.0.0.0/8 -A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 172.16.0.0/12 -A DOCKER-USER -j RETURN COMMIT # END UFW AND DOCKER |
Pravidlá, ktoré ste pridali, zabraňujú verejnému prístupu k portom, ktoré Docker otvára. Okrem toho umožňujú prístup z 10.0.0.0/8, 172.16.0.0/12, a 192.168.0.0/16 súkromných rozsahov IP adries. Viac podrobností o pravidlách si môžete prečítať v ufw-docker README. Po dokončení úprav súbory uložte a zatvorte. Toto nastavenie by malo fungovať, ak by ste mali nastavenú virtuálnu privátnu cloudovú sieť (VPC) so všetkými tromi servermi vo VPC a potom by ste špecifikovali súkromné IP adresy Django serverov v direktíve upstream pre Nginx konfiguračnom súbore.
Použili sme však verejné IP adresy a VPC nemusíme mať k dispozícii. Preto musíte pridať pravidlo do ufw na povolenie prevádzky z proxy servera Nginx cez port 80 oboch aplikačných serverov Django. Môžete pridať povoľovacie pravidlo do ufw špecifikujúce zdrojovú IP adresu servera pre port 80 pomocou nasledujúceho príkazu:
|
1 |
sudo ufw allow from NGINX_PROXY_IP to any port 80 |
Po dokončení zmien reštartujte aplikačný server Django, aby sa zmeny prejavili, keďže spustenie sudo ufw reload sa zdá, že neaplikuje zmeny:
|
1 |
sudo reboot |
Po reštartovaní servera spustite kontajner tak, ako ste to urobili v Kroku 1 alebo Kroku 2:
|
1 |
docker run -d --rm --name polls --env-file env -p 80:8000 django-polls:v1 |
Potom skúste v prehliadači navštíviť IP adresu prvého Django servera a overte, či sa zobrazí rozhranie Polls: http://FIRST_SERVER_IP/polls. To zlyhá. Teraz sa odhláste z prvého servera a zopakujte kroky, ktoré ste tu vykonali, pre druhý server. Otvorte /etc/ufw/after.rules pomocou nano ako sudo používateľ:
|
1 |
sudo nano /etc/ufw/after.rules |
Tak ako predtým, prejdite na koniec a pridajte konfiguračný blok UFW:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
# BEGIN UFW AND DOCKER *filter :ufw-user-forward - [0:0] :DOCKER-USER - [0:0] -A DOCKER-USER -j RETURN -s 10.0.0.0/8 -A DOCKER-USER -j RETURN -s 172.16.0.0/12 -A DOCKER-USER -j RETURN -s 192.168.0.0/16 -A DOCKER-USER -p udp -m udp --sport 53 --dport 1024:65535 -j RETURN -A DOCKER-USER -j ufw-user-forward -A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16 -A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8 -A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12 -A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 192.168.0.0/16 -A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 10.0.0.0/8 -A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 172.16.0.0/12 -A DOCKER-USER -j RETURN COMMIT # END UFW AND DOCKER |
Po pridaní vyššie uvedeného bloku súbor uložte a zatvorte.
Ďalej pridajte povoľovacie pravidlo do ufw špecifikujúce zdrojovú IP adresu servera na port 80 pomocou nasledujúceho príkazu:
|
1 |
sudo ufw allow from NGINX_PROXY_IP to any port 80 |
Reštartujte server, aby sa zmeny prejavili:
|
1 |
sudo reboot |
Keď sa server znova spustí, znova spustite kontajner pomocou príkazu:
|
1 |
docker run -d --rm --name polls --env-file env -p 80:8000 django-polls:v1 |
Otestujte, či môžete zobraziť rozhranie ankiet prechodom priamo na IP adresu druhého servera: http://SECOND_SERVER_IP/polls. Tiež by to malo zlyhať.
Táto architektúra je teraz pripravená na testovanie. Môžete navštíviť https://example_domain_here/polls na zobrazenie predvoleného rozhrania ankiet (Polls) z vášho prehliadača. To znamená, že proxy server Nginx má stále prístup k backendovým serverom Django.
Záver
V tejto príručke sme vám ukázali, ako implementovať škálovateľnú infraštruktúru pomocou kontajnerov Docker. Infraštruktúra zahŕňa samostatný databázový server PostgreSQL, dva backendové aplikačné servery a proxy server Nginx na vyrovnávanie záťaže a distribúciu prevádzky medzi týmito dvoma servermi. Hoci sme našu aplikáciu založili na aplikácii Django Polls, túto architektúru môžete prispôsobiť pre rôzne aplikácie pomocou rôznych frameworkov, ako napríklad Node.js, Laravel, atď.
Toto je základná príručka, ktorá vám pomôže začať. Medzi vylepšenia, ktoré môžete pridať, patrí hosťovanie vášho obrazu v repozitári obrazov, ako je Docker Hub, čo umožňuje jednoduchú distribúciu obrazu na viacero serverov. Môžete tiež pridať pipeline pre kontinuálnu integráciu a nasadenie na automatické zostavenie, testovanie a nasadenie obrazov na aplikačné servery, kedykoľvek nastane nejaká udalosť. Udalosťou môže byť napríklad odoslanie nového kódu do špecifikovanej vetvy v git repozitári. Možno budete chcieť automatizovať aj to, čo sa stane, keď kontajner narazí na chybu. Oficiálna dokumentácia Docker poskytuje dobrý návod na Automatické spúšťanie kontajnerov v prípade chýb alebo reštartu systému.
Príjemnú prácu!








Komentáre
Zatiaľ žiadne komentáre. Buďte prvý.