Kako osigurati i skalirati Django aplikaciju uz Docker, Nginx i Let’s Encrypt

Milijuni korisnika pristupaju internetu kako bi došli do informacija u različite svrhe, uključujući učenje, zabavu, vijesti i dijeljenje napretka u svojim životima’ s prijateljima. Stoga je prilikom postavljanja aplikacije u vašem najboljem interesu implementirati visoko sigurnu i skalabilnu infrastrukturu za svoju aplikaciju. Oblak nudi različite načine za osiguranje i skaliranje Django aplikacije. Horizontalno skaliranje je jedna od metoda koja vam omogućuje pokretanje nekoliko kopija vaše aplikacije. To osigurava da je ona otpornija na pogreške i visoko dostupna. Također povećava njezine performanse za istovremenu obradu više zahtjeva.

Horizontalno skaliranje Django aplikacije

Django aplikaciju možete horizontalno skalirati pripremanjem nekoliko aplikacijskih poslužitelja koji pokreću Django aplikaciju i njezin WSGI HTTP poslužitelj (poput Gunicorn ili uWSGI). Zatim ćete morati postaviti infrastrukturu za distribuciju dolaznih zahtjeva na ove aplikacijske poslužitelje. Balanser opterećenja i obrnuti proxy poput Nginxa mogu pomoći vašoj infrastrukturi u distribuciji prometa. Nginx može implementirati SSL certifikate osiguravajući sigurne veze s vašom aplikacijom putem HTTPS-a. Na kraju, Nginx također može pružiti predmemoriranje statičkog sadržaja kako bi se smanjilo opterećenje vašeg poslužitelja.

Konfiguriranje ovih različitih komponenti zasebno i osiguravanje njihove komunikacije može biti zastrašujući zadatak. Srećom, korištenje Dockera pojednostavljuje proces konfiguracije i osigurava da se različite komponente ponašaju na isti način bez obzira na to gdje su postavljene.

Što ćete raditi u ovom vodiču

U ovom vodiču, naučit ćete kako horizontalno skalirati kontejneriziranu Django aplikaciju, posluženu s Gunicorn WSGI HTTP poslužiteljem. Pripremit ćete dva aplikacijska poslužitelja, od kojih svaki ima instaliran Docker, koji pokreću istu kopiju Django i Gunicorn aplikacijskog kontejnera.

Također ćete osigurati svoju aplikaciju s Let’s Encrypt SSL certifikatom pripremanjem i konfiguriranjem trećeg proxy poslužitelja koji će pokretati Nginx obrnuti proxy kontejner i Certbot klijentski kontejner. Certbot je paket koji pomaže u upravljanju SSL certifikatima izdavatelja certifikata Let’s Encrypt. On dohvaća certifikat, konfigurira Nginx blokove poslužitelja s lokacijom certifikata i upravlja automatskim obnavljanjem. To čini konfiguriranjem cron posla koji povremeno provjerava istječe li certifikat uskoro i treba li ga obnoviti. Održavanjem vašeg SSL certifikata ažurnim, vaša će web stranica uvijek imati visoku ocjenu sigurnosti na SSL Labs.

Taj treći proxy poslužitelj nalazi se ispred vaše distribuirane arhitekture i prima sav dolazni vanjski promet. Zatim distribuira promet vašim aplikacijskim poslužiteljima. Aplikacijski poslužitelji nalaze se iza vatrozida, dopuštajući samo proxy poslužitelju da im pristupi.

Ovaj je vodič drugi u nizu od tri vodiča koji se bave Django, Docker i Kubernetes tehnologijama. Najprije biste trebali slijediti korake opisane u vodiču o Izgradnji Django i Gunicorn aplikacije s Dockerom na Ubuntuu. U tom smo vodiču postavili osnovni kod projekta, Dockerfile i povezali aplikaciju s MinIo Simple Storage Service (S3) za posluživanje naših statičkih datoteka.

Preduvjeti

Kako biste pratili ovaj vodič, trebat će vam sljedeće:

1. Četiri Ubuntu 20.04 poslužitelja:

Ako ste slijedili korake u preduvjetnom vodiču, Izgradnja Django i Gunicorn aplikacije s Dockerom na Ubuntuu, već imate dva od četiri poslužitelja:

• Prvi poslužitelj pokretat će instancu PostgreSQL baze podataka. Slijedite korake 1 i 2 vodiča: Izgradnja Django i Gunicorn aplikacije s Dockerom na Ubuntuu kako biste postavili bazu podataka. Konfiguracije Postgresa trebale bi se modificirati kako bi se omogućile vanjske veze samo s IP adresa vaših aplikacijskih poslužitelja.

• The Drugi i treći poslužitelji udomit će kontejnere za kod vaše aplikacije. Već biste trebali imati pokrenut drugi poslužitelj iz preduvjetnog vodiča. Modificirat ćemo njegov vatrozid kako bismo omogućili vanjske veze samo s IP adrese proxy poslužitelja. Možete slijediti korake od 1 do 4 ovog vodiča korak-po-korak koji će vam pomoći postaviti vaš Ubuntu poslužitelj na CloudSigma.

• The Četvrti poslužitelj bit će proxy poslužitelj koji upravlja uravnoteženjem opterećenja i distribucijom prometa na dva spremnika aplikacijskog poslužitelja.

2. Docker bi trebao biti instaliran na dva aplikacijska poslužitelja i proxy poslužitelj.

   Nakon što slijedite korake u vodiču s preduvjetima, trebali biste već imati instaliran Docker na jednom od poslužitelja. Možete slijediti korake 1, 2 i 3 našeg vodiča o instalaciji i upravljanju Dockerom. Ne zaboravite dodati gore stvorenog sudo korisnika u Docker grupu.

3. Nabavite registrirani naziv domene i postavite njegove DNS zapise da pokazuju na proxy poslužiteljevu javnu IP adresu. U svrhu demonstracije koristit ćemo example_domain.com.

4. Postavite uslugu S3 pohrane objekata. Koristili smo MinIO kao uslugu pohrane u vodiču s preduvjetima. Stoga slijedite objašnjenja u Koraku 5 iz vodiča s preduvjetima kako biste postavili svoj MinIO spremnik za pohranu.

Korak 1: Provjera radi li prvi Django aplikacijski poslužitelj

Kao što je objašnjeno u Preduvjetima, ovaj vodič dolazi nakon vodiča o Izgradnji Django i Gunicorn aplikacije s Dockerom na Ubuntuu. Ako dolazite iz tog vodiča i već ste primijenili korake, trebali biste imati pokrenut prvi poslužitelj. Kod aplikacije temelji se na dokumentaciji za Django Vodič za aplikaciju Polls. Važno je da pročitate te korake kako biste razumjeli početno postavljanje. Ako ste primijenili korake iz vodiča, možete preskočiti ovaj prvi korak.

U suprotnom, možete jednostavno klonirati Dockeriziranu granu na svoj poslužitelj. Započnite prijavom na svoj prvi aplikacijski poslužitelj i izvršite sljedeću git naredbu za kloniranje django-polls-docker grane django-polls repozitorija:

Zatim idite u django-polls direktorij:

cd django-polls

U ovom direktoriju naći ćete Dockerfile koji Docker koristi za izgradnju slike aplikacije, django-polls direktorij koji sadrži kod Python aplikacije i env datoteku koja sadrži popis varijabli okruženja koje će se proslijediti u spremnik pri pokretanju radi izmjene njegovog ponašanja. U Dockerfile, definiramo ovisnosti Django paketa kroz requirements.txt datoteku. Osim toga, moramo deklarirati priključak 8000 koji će se koristiti za prihvaćanje dolaznog prometa i postaviti ga da pokreće gunicorn poslužitelj s 3 radnika. Da biste saznali više o Dockerfile uputama, pogledajte Korak 7 vodiča Izgradnja Django i Gunicorn aplikacije s Dockerom na Ubuntuu.

Možete izgraditi Docker sliku pomoću naredbe:

docker build -t django-polls:v1 .

Nakon što Docker izgradi sliku, možete izlistati dostupne slike na poslužitelju pomoću sljedeće naredbe:

docker images

Evo izlaza kada smo pokrenuli naredbu:

Zatim moramo izmijeniti env datoteku koja se koristi za konfiguriranje izvršnog okruženja. Ova se datoteka prosljeđuje u Docker spremnik prilikom pokretanja spremnika. Otvorite env datoteku pomoću nano uređivača teksta:

Datoteka env sadrži privremeni tekst koji trebate izmijeniti i popuniti svojim točnim vrijednostima:

• DJANGO_SECRET_KEY: Generirajte jedinstvenu, nepredvidivu vrijednost kako je objašnjeno u Django dokumentaciji. Možete koristiti ovu naredbu za generiranje nasumičnog niza i njegovo postavljanje u varirablu:  python -c 'from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())'.

• DJANGO_ALLOWED_HOSTS: ova se vrijednost koristi za zaštitu vaše aplikacije od napada zaglavljem HTTP Host. Možete je postaviti na *, zamjenski znak koji odgovara svim poslužiteljima ako ste u razvojnom načinu rada. Kada implementirate aplikaciju u produkciju, postavite ovo na naziv svoje registrirane domene. Za našu demonstraciju to je example_domain.com.

• DB_DATABASE: postavite ovo na naziv PostgreSQL baze podataka koju ste izradili u odjeljku Preduvjeti , u našem slučaju to je polls_db.

• DB_USERNAME: postavite ovo na korisničko ime koje ste odabrali za svoju bazu podataka.

• DB_PASSWORD: postavite ovo na lozinku koju ste odabrali za svoju bazu podataka.

• DB_HOST: postavite ovo na poslužitelj na kojem se izvodi vaša instanca baze podataka, kako ste postavili u odjeljku Preduvjeti. To je objašnjeno u koracima 1 i 2 vodiča Izgradnja Django i Gunicorn aplikacije s Dockerom na Ubuntuu za postavljanje baze podataka.

• DB_PORT: postavite ovo na port svoje baze podataka.

Spremite i zatvorite datoteku nakon što završite s uređivanjem. S postavljenim vjerodajnicama baze podataka, možemo izraditi shemu baze podataka pokretanjem spremnika i nadjačavanjem naredbe CMD postavljene u Dockerfileu. Više informacija možete pronaći na ulaznoj točki Dockerfilea u službenoj dokumentaciji. Zatim izvedite sljedeću naredbu:

U ovoj naredbi pokrećemo sliku django-polls:v1 i prosljeđujemo datoteku env koja je prethodno izmijenjena. Dio: sh -c "python manage.py makemigrations && python manage.py migrate” stvara shemu baze podataka definiranu kodom aplikacije. Ako naredbu izvršavate prvi put, trebali biste vidjeti sličan izlaz koji ukazuje na stvaranje sheme baze podataka:

Nakon što izradimo shemu, možemo stvoriti Django superkorisnika. Izvršite sljedeću naredbu za pokretanje spremnika s interaktivnom ljuskom:

Naredba pokreće spremnik s upitom ljuske koji možete koristiti za interakciju s Python ljuskom. Stvorimo korisnika sljedećom naredbom:

Slijedite upite kako biste unijeli korisničko ime, e-adresu i lozinku. Ponovno upišite lozinku i pritisnite Enter za stvaranje korisnika. Izađite iz ljuske i zaustavite spremnik pritiskom na CTRL+D.

Zatim moramo ponovno pokrenuti spremnik, nadjačavajući zadanu naredbu s Django naredbom collectstatic. Naredba će generirati statičke datoteke za aplikaciju i prenijeti ih na MinIO Cloud Storage:

Naredba generira i prenosi datoteku na vašu konfiguriranu uslugu pohrane objekata. Evo izlaza:

Sada možete pokrenuti aplikaciju bez navođenja dodatnih naredbi za nadjačavanje zadane naredbe CMD definirane u Dockerfileu:

Docker pokreće zadanu naredbu definiranu u Dockerfileu, pokreće spremnik s poslužiteljem gunicorn, izlaže port spremnika 8000 i mapira ga na port Ubuntua 80. Sada možete vidjeti sučelje aplikacije u svom pregledniku tako da u adresnu traku unesete IP adresu prvog poslužitelja: http://FIRST_SERVER_IP.

Dobit ćete 404 Stranica nije pronađena jer nismo definirali ništa za / putanju. Idite na http://FIRST_SERVER_IP/polls kako biste vidjeli sučelje anketa:

Posjetite administratorsko sučelje kako biste kreirali neke ankete: http://FIRST_SERVER_IP/admin:

Unesite vjerodajnice koje ste postavili pomoću naredbe createsuperuser iznad kako biste pristupili administratorskom sučelju:

Ako pogledate izvorni kod stranice, primijetit ćete da se statičke datoteke dohvaćaju iz spremnika za pohranu kako je definirano. Nakon što potvrdite da spremnik poslužuje aplikaciju prema očekivanjima, možete zaustaviti spremnik pritiskom na CTRL+C u terminalu.

Zatim moramo ostaviti spremnik da radi u detached načinu rada, kako bismo mogli izaći iz SSH sesije prvog poslužitelja. To će ostaviti spremnik da radi u pozadini. Izvršite sljedeću naredbu:

Zastavica -d pokreće spremnik u detached načinu rada kako bi mogao nastaviti raditi u pozadini. Zastavica --rm čisti datotečni sustav spremnika nakon što se spremnik ugasi. Spremniku dajemo naziv, polls, kako bismo ga mogli vidjeti kada izlistamo spremnike.

Izađite iz SSH sesije vašeg prvog poslužitelja i idite na http://FIRST_SERVER_IP/polls u vašem pregledniku kako biste potvrdili da radi prema očekivanjima. Ako možete vidjeti sučelje anketa, tada je vaš prvi aplikacijski poslužitelj uspješno postavljen. Postavimo drugi aplikacijski poslužitelj u sljedećem koraku.

Korak 2: Postavljanje drugog aplikacijskog poslužitelja

Klonirat ćemo dockeriziranu granu aplikacije koju smo izradili u vodiču Building a Django and Gunicorn Application with Docker on Ubuntu . Više pojedinosti o naredbama koje ćemo ovdje koristiti možete pronaći u tom vodiču ili u sažetoj verziji u Koraku 1.

Trebali biste imati pokrenut drugi poslužitelj, dodanog ne-root sudo korisnika i instaliran Docker kao što je objašnjeno u odjeljku Preduvjeti.

Sljedeći korak je konfiguracija ovog poslužitelja za povezivanje s instancom PostgreSQL poslužitelja. Kao što je objašnjeno u Koraku 1 vodiča Building a Django and Gunicorn Application with Docker on Ubuntu, morate dopustiti IP adresu drugog poslužitelja kroz ufw i PostgreSQL konfiguracije.

Prvo se prijavite na instancu PostgreSQL poslužitelja baze podataka sa svojim ne-root sudo korisnikom. Za dodavanje pravila ufw izvršite sljedeću naredbu:

Zatim izvršite ovu naredbu i dodajte IP adresu drugog poslužitelja u datoteku za autentifikaciju PostgreSQL klijenta:

Pročitajte komentare kako biste bolje razumjeli konfiguracije. Zatim dodajte ovaj redak pod odjeljak hosts, navodeći svoju IP adresu:

Spremite i zatvorite datoteku kada završite s uređivanjem.

Zatim ponovno pokrenite PostgreSQL uslugu kako bi promjene stupile na snagu:

Odjavite se iz instance PostgreSQL poslužitelja baze podataka i nastavite s konfiguracijom druge instance aplikacijskog poslužitelja.

Prijavite se na drugi aplikacijski poslužitelj pomoću ssh. Zatim klonirajte granu django-polls-granu repozitorija django-polls sa sljedećom naredbom:

Prijeđite u direktorij django-polls:

Nakon toga, izgradite sliku pomoću sljedeće naredbe:

Nakon što proces izgradnje slike završi, izmijenite datoteku env s konfiguracijskim vrijednostima kako je objašnjeno u Koraku 1. Otvorite datoteku pomoću nano:

Zamijenite tekstove rezerviranih mjesta sa stvarnim vrijednostima koje ste dodali u Korak 1. Ne zaboravite izmijeniti DJANGO_ALLOWED_HOSTS varijablu na odgovarajući način. Spremite i zatvorite datoteku kada završite. Ažurirajte svoje MinIO vjerodajnice u env  datoteci kao što ste to učinili u prethodnom koraku.

Sada možete pokrenuti spremnik aplikacije u pozadinskom načinu rada (detached mode) sa sljedećom naredbom:

Naredba pokreće spremnik i drži ga pokrenutim u pozadini. Izađite iz ssh sesije drugog poslužitelja aplikacije i idite na http://SECOND_SERVER_IP/polls u svom pregledniku kako biste potvrdili da radi kako se očekuje. Trebali biste moći vidjeti sučelje anketa ako je sve prošlo prema očekivanjima.

Sada imate dva poslužitelja aplikacija koji pokreću istu kopiju vaše aplikacije. U sljedećem koraku konfigurirat ćete Nginx spremnik da služi kao reverzni proxy.

Korak 3: Postavljanje Nginx Docker spremnika

Nginx je jedan od najpopularnijih softvera za web poslužitelje otvorenog koda na svijetu. Odgovoran je za osiguravanje dostupnosti i skalabilnosti web stranica s najvećim prometom na internetu. Jamči sigurnost i vrlo je svestran. Možete ga koristiti za reverzno proksiranje, predmemoriranje i uravnoteženje opterećenja. Postavili smo našu aplikaciju da koristi zasebnu uslugu pohrane objekata za rukovanje svojim statičkim i medijskim datotekama. Stoga nećemo koristiti Nginx funkcije predmemoriranja. Umjesto toga, koristit ćemo Nginx mogućnosti reverznog proksiranja i uravnoteženja opterećenja. Nginx poslužitelj okrenut prema van primat će dolazni promet i distribuirati ga pozadinskim poslužiteljima aplikacija. Zatim će osigurati sigurnu komunikaciju između klijenta i poslužitelja osiguravanjem prometa pomoću SSL certifikata dobivenih od Let’s Encrypt.

Postoji nekoliko načina za implementaciju Nginx reverznog proksiranja i uravnoteženja opterećenja. Jedan od načina je postavljanje Nginx reverznog proxyja odvojeno od pozadinskog poslužitelja aplikacije, kao što smo učinili u ovom vodiču. Ova postavka je fleksibilna i omogućuje vam skaliranje kako Nginx proxy sloja, tako i sloja aplikacije. Možete dodati više Nginx proxyja ili implementirati oblačni usmjerivač opterećenja (cloud load balancer). Drugi način implementacije reverznog proksiranja je korištenje jednog od pozadinskih poslužitelja aplikacija kao Nginx proxyja. Zatim možete proksirati dolazne zahtjeve lokalno i na druge poslužitelje aplikacija. Opcionalno, možete konfigurirati Nginx spremnik na svim pozadinskim poslužiteljima aplikacija i postaviti prednji oblačni usmjerivač opterećenja koji će primati dolazni promet i distribuirati ga pozadinskim poslužiteljima aplikacija.

Počnimo s konfiguracijom proxy poslužitelja. Prijavite se na četvrti Ubuntu poslužitelj koji ste odredili za korištenje kao Nginx proxy i stvorite konfiguracijski direktorij:

Otvorite konfiguraciju s nano unutar direktorija:

Zatim dodajte sljedeću konfiguraciju u datoteku:

U ovoj konfiguracijskoj datoteci specificiramo server, upstream, i location blokove kako bismo uputili Nginx da preusmjeri HTTP zahtjeve na HTTPS i raspodijeli zahtjeve između dva aplikacijska poslužitelja koja smo postavili u Koraku 1 i Koraku 2. Općenite informacije o strukturi Nginx konfiguracijske datoteke možete pronaći u njihovoj službenoj dokumentaciji.

Proučili smo konfiguracijske datoteke koje pruža Docker Hub dokumentacija Nginx slike, Certbot, i Gunicorn kako bismo došli do ove minimalne Nginx konfiguracijske datoteke. Iako je ovo samo u svrhu demonstracije i pokretanja našeg sustava, slobodno istražujte i eksperimentirajte s drugim konfiguracijama prateći Nginx vodiče.

Upstream blok se koristi za definiranje grupe poslužitelja koji će obrađivati dolazne zahtjeve. Grupi se dodjeljuje naziv i poziva ga direktiva proxy_pass. Blok smo nazvali django i naveli IP adrese dvaju pozadinskih aplikacijskih poslužitelja:

Također smo definirali 3 server bloka. prvi server blok hvata sve zahtjeve koji ne odgovaraju vašoj domeni i vraća 444 kod (zatvara vezu bez slanja odgovora klijentu, čime se odbijaju zlonamjerni ili neispravni zahtjevi). Izravni HTTP zahtjev prema IP adresi vašeg poslužitelja obrađuje ovaj blok jer je definiran kao default_server:

Drugi drugi server blok obrađuje dolazne HTTP (port 80) zahtjeve i preusmjerava ih na HTTPS (port 443) pomoću HTTP 301 preusmjeravanja:

Treći server blok sada obrađuje zahtjeve. Sadrži nekoliko direktiva, a njihovu važnost definirat ćemo u nastavku.

Imamo dvije direktive koje definiraju putanje do TLS certifikata i ključa koje je osigurao Certbot. Certifikati se montiraju u Nginx spremnik prilikom njegova pokretanja:

Zatim imamo zadane sigurnosne postavke za SSL koje preporučuje Certbot. Više možete saznati u službenoj Nginx dokumentaciji o modulu ngx_http_ssl_module. Mozilla također nudi više informacija o sigurnosti na strani poslužitelja. Vrijednost ssl_ciphers u conf datoteci preuzeta je s Mozilline stranice:

U sljedeće dvije direktive definirat ćemo maksimalnu dopuštenu veličinu tijela klijentskog zahtjeva i postaviti vremensko ograničenje za keep-alive veze s klijentom. Nginx će zatvoriti veze s klijentom nakon broja sekundi koji postavite u direktivi keepalive_timeout. Više informacija o Nginx konfiguracijama za implementaciju Gunicorna možete pronaći u službenoj dokumentaciji:

U konfiguracijskoj datoteci također smo definirali dva lokacijska bloka. Prvi blok upravlja proksiranjem zahtjeva kako je definirano proxy direktivama. Dolazni zahtjevi se proksiraju na upstream django poslužitelje koji su prethodno definirani:

Više informacija o proxy direktivama možete pronaći u Nginx Module ngx_http_proxy_module i dokumentaciji o postavljanju Gunicorn poslužitelja.

U drugom lokacijskom bloku definiramo putanju: /well-known/acme-challenge/. Obično ga koristi Certbot za provjeru vašeg naziva domene s Let’s Encrypt prije izdavanja ili obnove SSL certifikata:

To je sve za Nginx konfiguracijsku datoteku. Sada možete spremiti i zatvoriti datoteku nakon što završite s uređivanjem.

Konfiguracijska datoteka koju ste upravo definirali može se koristiti za pokretanje Nginx spremnika. Međutim, to neće uspjeti jer nismo osigurali SSL certifikate od Let’s Encrypt. U ovom vodiču koristit ćemo nginx:1.20.2 Docker sliku verzije 1.20.2 iz službenog Nginx repozitorija slika na Docker Hubu.

Možete pokrenuti naredbu u nastavku kako biste preuzeli sliku i provjerili radi li sve ispravno:

Ova naredba stvara spremnik pod nazivom nginx i mapira portove 80 i 443 između host sustava i spremnika. Oznaka --rm uklanja sve međuspremnike nakon uspješne izgradnje. Koristimo oznaku -v za montiranje konfiguracijske datoteke u spremnik na /etc/nginx/conf.d/nginx.conf što je zadani direktorij za Nginx konfiguracije. Montiran je u načinu rada samo za čitanje pomoću oznake ro kako bismo spriječili Nginx spremnik da je mijenja. Postavljamo zadani webroot direktorij i montiramo ga kao /var/www/html. Završavamo tako što upućujemo Docker da koristi nginx:1.20.2 sliku za ovu izgradnju. Nabavimo TLS/SSL certifikat i ključ od Let’s Encrypt u sljedećem koraku.

Korak 4: Osiguravanje SSL/TLS certifikata od Let’s Encrypt i konfiguriranje automatske obnove Certbota

Certbot pomaže u osiguravanju besplatnih TLS certifikata od Let’s Encrypt kao i u upravljanju njihovom automatskom obnovom prije nego što isteknu. To poboljšava sigurnost vaših web stranica i osigurava da se poslužuju putem HTTPS-a. U skladu s održavanjem naše arhitekture kontejneriziranom, koristit ćemo Certbot Docker sliku za preuzimanje SSL/TLS certifikata i konfiguriranje automatske obnove. Provjerite imate li instaliran Docker na vašem proxy poslužitelju prema Preduvjetima uputama.

Također biste trebali imati DNS A zapis vašeg registriranog naziva domene koji upućuje na IP adresu vašeg proxy poslužitelja. To možete provjeriti pokretanjem certbot Docker slike i prosljeđivanjem oznake --staging oznake:

Naredba će preuzeti Certbot sliku i pokrenuti je u interaktivnom načinu rada. To znači da će doći s ljuskom, što vam omogućuje unos nekih pojedinosti. Mapira port 80 hosta na port 80 unutar spremnika. Koristimo oznaku -v za montiranje dvaju direktorija hosta u spremnik: /etc/letsencrypt/ i /var/lib/letsencrypt/. Oznaka --standalone zastavica specificira da želimo da se Certbot slika pokrene bez korištenja Nginxa. Na kraju, imamo --staging zastavicu koja će pokrenuti Certbot na staging poslužiteljima i potvrditi vašu domenu.

Unesite svoju e-adresu i prihvatite Uvjete pružanja usluge kada se to od vas zatraži. Slijedi izlaz uspješne provjere:

SLJEDEĆI KORACI:

Certifikat će trebati obnoviti prije nego što istekne. Certbot može automatski obnoviti certifikat u pozadini, ali možda ćete morati poduzeti korake kako biste omogućili tu funkcionalnost. Provjerite ovu poveznicu za upute.

Certifikat možete pregledati pomoću cat naredbe:

Gornja naredba trebala bi prikazati vaš certifikat u terminalu. Nakon što potvrdite da je Certbot osigurao vaš certifikat, sada možete testirati Nginx konfiguraciju koju ste izradili u Koraku 3. Izvršite Docker naredbu u nastavku kako biste pokrenuli Nginx spremnik:

U ovoj naredbi upotrijebili smo -v zastavicu za montiranje lokacije direktorija Let’s Encrypt SSL/TLS certifikata.

Kada se spremnik pokrene i proradi, otvorite web stranicu u svom pregledniku: http://example_domain.com. Vjerojatno ćete vidjeti upozorenje da web stranica nije sigurna:

To je zato što smo osigurali samo staging/testne certifikate, a ne produkcijske certifikate od Let’s Encrypt. Nabavimo produkcijske certifikate izvršavanjem sljedeće Certbot naredbe bez --staging zastavice:

U upitu potvrdite da želite obnoviti i zamijeniti postojeći certifikat upisivanjem 2 i pritisnite ENTER. To bi trebalo osigurati certifikat spreman za produkciju. Sada možete pokrenuti Nginx spremnik i sve bi trebalo raditi kako treba:

Nakon što se spremnik pokrene i proradi, ponovno otvorite web stranicu u svom pregledniku: http://example_domain.com opet. Primijetit ćete da je vaš preglednik preusmjeren na HTTPS čak i ako unesete HTTP. To znači da naš poslužitelj u Nginx konfiguraciji kao i osigurani SSL/TLS certifikati rade dobro. Idite na polls  rutu http://example_domain.com/polls jer nemamo definiranu rutu za početnu stazu /. Trebali biste vidjeti sučelje anketa:

Do sada ste uspješno konfigurirali arhitekturu spremnu za produkciju. Implementirali ste dva pozadinska poslužitelja koji će obrađivati dolazne zahtjeve proslijeđene s proxy poslužitelja. Proxy poslužitelj će upravljati balansiranjem opterećenja i osiguravanjem prometa pomoću osiguranih TLS certifikata.

Međutim, trebate imati na umu da Let’s Encrypt certifikati istječu za 90 dana. Stoga biste ih trebali obnoviti prije isteka tog roka od 90 dana. Budući da će Nginx spremnik biti pokrenut, trebali biste koristiti webroot način umjesto standalone načina kada izvršavate naredbu certbot za obnovu certifikata. Sjetite se da ste naveli /var/www/html/.well-known/acme-challenge/ direktorij u Nginx konfiguracijskoj datoteci u Koraku 3. Certbot će koristiti ovu putanju za pohranu datoteka za provjeru. Također, Let’s Encrypt klijent će pozvati ovu putanju sa zahtjevima za provjeru kada pokušate obnoviti certifikate. Nakon što se naredba za obnovu završi s izvršavanjem, možete ponovno učitati Nginx kako bi promjene stupile na snagu.

Zaustavite spremnik pritiskom na CTRL+C u svom terminalu i pokrenimo ga ponovno u pozadinskom načinu rada s oznakom -d:

To će ostaviti Nginx spremnik da radi u pozadini. Testirajmo postupak obnove certifikata s oznakom --dry-run izvršavanjem donje naredbe:

U ovoj naredbi naveli smo --webroot dodatak kao i putanju koja će se koristiti za zahtjeve za provjeru s oznakom -w. Također navodimo oznaku --dry-run kako bismo provjerili postupak automatske obnove bez stvarnog izdavanja certifikata.

Trebali biste vidjeti sličan izlaz u slučaju uspješne simulacije:

Kad god obnovite certifikat za svoju pokrenutu aplikaciju, morate ponovno učitati Nginx kako bi spremnik počeo koristiti novi certifikat. Sljedeća Docker naredba ponovno učitava nginx (sjetite se da smo spremnik nazvali nginx) spremnik:

Naredba šalje HUP Unix signal Nginx procesu koji se izvodi unutar nginx Docker spremnika. To uzrokuje da Nginx ponovno učita svoje konfiguracije i počne koristiti obnovljene certifikate.

Budući da imamo instaliran TLS/SSL na našem proxy poslužitelju i naša se web stranica poslužuje putem HTTPS-a, sada moramo osigurati naše pozadinske aplikacijske poslužitelje kako bismo dopustili samo zahtjeve s proxy poslužitelja.

Korak 5: Osiguravanje pozadinskih Django poslužitelja od vanjskog pristupa

Proxy poslužitelj koji ste implementirali u ovom vodiču upravlja SSL terminacijom gdje dešifrira SSL vezu i prosljeđuje nedešifrirane pakete pozadinskim poslužiteljima aplikacija. Budući da ćemo pozadinske poslužitelje osigurati od bilo kakvog vanjskog pristupa, ova bi razina sigurnosti trebala funkcionirati u većini slučajeva. Međutim, ako implementirate aplikacije koje prenose osjetljive podatke kao što su bankovni podaci ili zdravstveni podaci, trebali biste implementirati šifriranje s kraja na kraj.

U ovom vodiču, Gunicorn poslužitelji u pozadini zaštićeni su Nginxom jer nisu namijenjeni izravnom pristupu korisnika. Nginx proxy poslužitelj je poput mrežnog prolaza prema pozadinskim poslužiteljima, sprječavajući vanjske klijente da izravno pristupaju pozadinskim poslužiteljima aplikacija. Trebali biste se pobrinuti da svi zahtjevi idu kroz proxy poslužitelj. S obzirom na to, Docker ima problem u kojem zaobilazi ufw pravila vatrozida i otvara priključke prema van, što može ostaviti vašu infrastrukturu nesigurnom. To je zapravo očito jer smo postavili naše poslužitelje aplikacija u Koraku 1 i Koraku 2 bez dopuštanja priključka 80 u ufw pravilima. Međutim, i dalje možete pristupiti web stranicama kada u pregledniku posjetite bilo koju od javnih IP adresa poslužitelja. Jedan od načina na koji možete riješiti ovaj problem je korištenje iptables izravno bez prolaska kroz ufw. Možete pročitati Docker i iptables službene dokumente kako biste saznali više. Drugi preporučeni način je korištenje vatrozida u oblaku.

Izmijenimo konfiguracije UFW-a kako bismo blokirali vanjski pristup svim priključcima koje je Docker možda otvorio. Kada smo mapirali priključak domaćina 80 na priključak Docker spremnika 8000 sa zastavicom -p 80:8000 u Docker naredbi, također smo nenamjerno otvorili priključak 80 na računalu domaćinu. Ovaj pristup možete onemogućiti izmjenom konfiguracije UFW-a kako je opisano u ufw-docker repozitoriju README.

Promijenimo to za prvi poslužitelj Django aplikacije. Prijavite se na poslužitelj i otvorite datoteku na /etc/ufw/after.rules pomoću nano-a kao sudo korisnik:

Datoteka sadrži sljedeća ufw pravila:

Dodajte sljedeći blok konfiguracijskih redaka za UFW na dno datoteke:

Pravila koja ste dodali sprječavaju javni pristup portovima koje Docker otvara. Nadalje, ona omogućuju pristup iz 10.0.0.0/8, 172.16.0.0/12, i 192.168.0.0/16 privatnih IP raspona. Više pojedinosti o pravilima možete pročitati u ufw-docker README. Spremite i zatvorite datoteke kada završite s uređivanjem. Ova bi konfiguracija trebala raditi ako ste postavili mrežu virtualnog privatnog oblaka (VPC), sa sva vaša tri poslužitelja u VPC-u, a zatim naveli privatne IP adrese Django poslužitelja u direktivi upstream za Nginx konfiguracijskoj datoteci.

Međutim, koristili smo javne IP adrese i možda nemamo VPC. Stoga morate dodati pravilo u ufw kako biste omogućili promet s Nginx proxy poslužitelja kroz port 80 oba poslužitelja Django aplikacije. Možete dodati pravilo dopuštenja u ufw navodeći izvorišni IP poslužitelja na port 80 pomoću sljedeće naredbe:

Nakon što završite s izmjenama, ponovno pokrenite poslužitelj Django aplikacije kako bi promjene stupile na snagu jer se čini da pokretanje sudo ufw reload samo ne uspijeva primijeniti promjene:

Kada se poslužitelj ponovno pokrene, pokrenite spremnik kao što ste to učinili u Koraku 1 ili Koraku 2:

Zatim pokušajte posjetiti IP adresu prvog Django poslužitelja u pregledniku kako biste vidjeli prikazuje li sučelje Polls: http://FIRST_SERVER_IP/polls. Neće uspjeti. Sada se odjavite s prvog poslužitelja i ponovite korake koje ste ovdje učinili za drugi poslužitelj. Otvorite /etc/ufw/after.rules pomoću nano-a kao sudo korisnik:

Kao što ste učinili ranije, pomaknite se do dna i dodajte blok UFW konfiguracija:

Spremite i zatvorite datoteku nakon što dodate gornji blok.

Zatim dodajte pravilo dopuštanja u ufw navodeći izvornu IP adresu poslužitelja na port 80 pomoću sljedeće naredbe:

Ponovno pokrenite poslužitelj kako bi promjene stupile na snagu:

Kada se poslužitelj ponovno pokrene, ponovno pokrenite spremnik naredbom:

Testirajte možete li vidjeti sučelje anketa tako da odete izravno na IP adresu drugog poslužitelja: http://SECOND_SERVER_IP/polls. To bi također trebalo biti neuspješno.

Ova je arhitektura sada spremna za testiranje. Možete posjetiti https://example_domain_here/polls kako biste vidjeli zadano sučelje anketa (Polls) iz svog preglednika. To znači da proxy poslužitelj Nginx i dalje ima pristup pozadinskim poslužiteljima Django.

Zaključak

U ovom smo vam vodiču pokazali kako implementirati skalabilnu infrastrukturu pomoću Docker spremnika. Infrastruktura uključuje zasebni PostgreSQL poslužitelj baze podataka, dva pozadinska aplikacijska poslužitelja i Nginx proxy poslužitelj za uravnoteženje opterećenja i distribuciju prometa na ta dva poslužitelja. Iako smo našu aplikaciju temeljili na aplikaciji Django Polls, ovu arhitekturu možete prilagoditi za razne aplikacije koristeći različite okvire, kao što su Node.js, Laravel, itd.

Ovo je osnovna smjernica za početak. Nekoliko poboljšanja koja možete dodati jest hostiranje vaše slike na repozitoriju slika kao što je Docker Hub što omogućuje jednostavnu distribuciju slike na više poslužitelja. Također možete dodati cjevovode za kontinuiranu integraciju i isporuku kako biste automatski izgradili, testirali i isporučili slike na aplikacijske poslužitelje kad god se dogodi neki događaj. Na primjer, događaj bi mogao biti slanje novog koda u određenu granu na git repozitoriju. Možda ćete također htjeti automatizirati što se događa kada spremnik naiđe na pogrešku. Službena Docker dokumentacija pruža dobre smjernice o Automatskom pokretanju spremnika u slučaju pogrešaka ili ponovnog pokretanja sustava.

Sretno s radom!