Docker, Nginx ve Let’s Encrypt ile Bir Django Uygulaması Nasıl Güvenli Hale Getirilir ve Ölçeklendirilir

Milyonlarca kullanıcı öğrenme, eğlence, haber ve hayatlarındaki’ gelişmeleri arkadaşlarıyla paylaşmak da dahil olmak üzere çeşitli amaçlarla bilgiye erişmek için internete giriyor. Bu nedenle, bir uygulama dağıtırken, uygulamanız için son derece güvenli ve ölçeklenebilir bir altyapı kurmak en iyi çıkarınızadır. Bulut, bir Django uygulamasını güvence altına almak ve ölçeklendirmek için çeşitli yollar sunar. Yatay ölçeklendirme, uygulamanızın birden fazla kopyasını çalıştırmanıza olanak tanıyan bir yöntemdir. Bu, uygulamanın hataya karşı daha dayanıklı ve yüksek oranda kullanılabilir olmasını sağlar. Ayrıca, aynı anda birden fazla isteği işlemek için performansını artırır.

Bir Django uygulamasını yatay olarak ölçeklendirme

Django uygulamasını ve WSGI HTTP sunucusunu (örneğin Gunicorn veya uWSGI) çalıştıran birkaç uygulama sunucusu hazırlayarak bir Django uygulamasını yatay olarak ölçeklendirebilirsiniz. Ardından, gelen istekleri bu uygulama sunucularına dağıtmak için bir altyapı kurmanız gerekecektir. Bir yük dengeleyici ve bir Nginx gibi ters proxy altyapınızın trafik dağıtımına yardımcı olabilir. Nginx, SSL sertifikaları dağıtarak HTTPS aracılığıyla uygulamanıza güvenli bağlantılar sağlayabilir. Son olarak Nginx, sunucunuzdaki yükü en aza indirmek için statik içeriğin önbelleğe alınmasını da sağlayabilir.

Bu çeşitli bileşenleri ayrı ayrı yapılandırmak ve iletişim kurmalarını sağlamak göz korkutucu bir görev olabilir. Neyseki, Docker kullanmak yapılandırma sürecini basitleştirir ve çeşitli bileşenlerin nerede dağıtıldıklarından bağımsız olarak aynı şekilde davranmasını sağlar.

Bu Kılavuzda Ne Yapacaksınız

Bu kılavuzda, bir Gunicorn WSGI HTTP sunucusu ile sunulan, konteynerleştirilmiş bir Django uygulamasını yatay olarak nasıl ölçeklendireceğinizi öğreneceksiniz. Her birinde Docker kurulu olan ve aynı Django ve Gunicorn uygulama konteyneri kopyasını çalıştıran iki uygulama sunucusu hazırlayacaksınız.

Ayrıca uygulamanızı bir Let’s Encrypt SSL sertifikası ile güvence altına alacaksınız; bunun için bir üçüncü proxy sunucusu hazırlayıp yapılandıracaksınız. Bu sunucu bir Nginx ters proxy konteyneri ve bir Certbot istemci konteyneri çalıştıracaktır. Certbot, Let’s Encrypt sertifika yetkilisinden alınan SSL sertifikalarını yönetmeye yardımcı olan bir pakettir. Sertifikayı alır, Nginx sunucu bloklarını sertifikanın konumuyla yapılandırır ve otomatik yenilemeleri yönetir. Bunu, sertifikanın süresinin dolmak üzere olup olmadığını ve yenilenmesi gerekip gerekmediğini periyodik olarak kontrol etmek için bir cron işi yapılandırarak yapar. SSL sertifikanızı güncel tutarak, web siteniz her zaman SSL Labs.

üzerinde yüksek bir güvenlik derecesine sahip olacaktır. üçüncü proxy sunucusu, dağıtık mimarinizin önünde yer alır ve gelen tüm harici trafiği alır. Ardından, trafiği uygulama sunucularınıza dağıtır. Uygulama sunucuları bir güvenlik duvarının arkasında yer alır ve yalnızca proxy sunucusunun kendilerine erişmesine izin verir.

Bu eğitim, Django, Docker ve Kubernetes ile çalışan üç bölümlük eğitim serisinin ikincisidir. Öncelikle şu eğitimde açıklanan adımları izlemelisiniz: Building a Django and Gunicorn Application with Docker on Ubuntu. Bu eğitimde, temel proje kodunu, bir Dockerfile dosyasını kurduk ve uygulamayı statik dosyalarımızı sunmak için MinIo Basit Depolama Servisi'ne (S3) bağladık.

Gereksinimler

Bu eğitimi takip etmek için aşağıdakilere ihtiyacınız olacak:

1. Dört adet Ubuntu 20.04 sunucusu:

Ön koşul eğitimindeki adımları izlediyseniz, Building a Django and Gunicorn Application with Docker on Ubuntu, dört sunucudan ikisine zaten sahipsiniz:

• İlk sunucu PostgreSQL veritabanı örneğini çalıştıracaktır. Veritabanını kurmak için Building a Django and Gunicorn Application with Docker on Ubuntu eğitiminin 1. ve 2. adımlarını izleyin. Postgres yapılandırmaları, yalnızca uygulama sunucusu IP'lerinizden gelen harici bağlantılara izin verecek şekilde değiştirilmelidir.

• The İkinci ve üçüncü sunucular, uygulama kodunuz için konteynerleri barındıracaktır. İkinci sunucunun ön koşul eğitiminden zaten çalışıyor olması gerekir. Güvenlik duvarını, yalnızca proxy sunucu IP'sinden gelen harici bağlantılara izin verecek şekilde değiştireceğiz. Ubuntu sunucunuzu kurmanıza yardımcı olması için bu adım adım kılavuzun 1 ila 4. adımlarını takip edebilirsiniz CloudSigma üzerinde.

• The Dördüncü sunucu, proxy sunucusu olacaktır ve iki uygulama sunucusu konteynerine yük dengeleme ile trafik dağıtımını yönetecektir.

2. Docker, iki uygulama sunucusuna ve proxy sunucusuna kurulmalıdır.

   Şu belgedeki adımları takip ettikten sonra: önkoşul eğitimi, sunuculardan birinde Docker'ın zaten kurulu olması gerekir. Şu belgemizin 1, 2 ve 3. adımlarını takip edebilirsiniz: Docker kurulumu ve çalıştırılması eğitimi. Yukarıda oluşturulan sudo kullanıcısını Docker grubuna eklemeyi unutmayın.

3. Kayıtlı bir alan adı edinin ve DNS kayıtlarını proxy sunucusunun genel IP adresini gösterecek şekilde ayarlayın. Gösterim amacıyla, example_domain.com.

4. Bir S3 nesne depolama servisi kurun. Önkoşul eğitiminde depolama servisi olarak MinIO kullandık. Bu nedenle, Adım 5 içindeki açıklamaları takip ederek önkoşul eğitimi depolama alanınızı kurun: MinIO depolama klasörü (bucket).

Adım 1: İlk Django Uygulama Sunucusunun Çalıştığının Doğrulanması

Şurada açıklandığı gibi: Önkoşullar, bu kılavuz şu eğitimden sonra gelmektedir: Ubuntu üzerinde Docker ile Django ve Gunicorn Uygulaması Oluşturma. O eğitimden geliyorsanız ve adımları zaten uyguladıysanız, ilk sunucunun çalışıyor olması gerekir. Uygulamanın kodu, Django belgelerindeki Anket (Polls) uygulaması eğitimine dayanmaktadır. İlk kurulum hakkında bilgi sahibi olmak için bu adımları okumanız önemlidir. Eğitimdeki adımları uyguladıysanız, bu ilk adımı atlayabilirsiniz.

Aksi takdirde, Dockerize edilmiş dalı (branch) sunucunuza kopyalayabilirsiniz (clone). İlk uygulama sunucunuza giriş yaparak başlayın ve git komutunu çalıştırarak django-polls-docker dalını kopyalayın: django-polls deposu:

Ardından, şu dizine gidin: django-polls dizini:

cd django-polls

Bu dizinde, Dockerfile (Docker tarafından uygulama imajını oluşturmak için kullanılır), Python uygulama kodunu içeren django-polls dizini ve başlangıçta davranışını değiştirmek için konteynere aktarılacak ortam değişkenlerinin bir listesini içeren bir env dosyası bulacaksınız. Dockerfile içinde, Django paket bağımlılıklarını requirements.txt dosyası. Ek olarak, gelen trafiği kabul etmek için kullanılacak bir port 8000 bildirmemiz ve bunu 3 worker'a sahip bir gunicorn sunucusu çalıştıracak şekilde ayarlamamız gerekir. Dockerfile talimatları hakkında daha fazla bilgi edinmek için lütfen Adım 7 bölümüne bakın: Ubuntu üzerinde Docker ile Django ve Gunicorn Uygulaması Oluşturma.

Docker imajını şu komutu kullanarak oluşturabilirsiniz:

docker build -t django-polls:v1 .

Docker imajı oluşturduktan sonra, aşağıdaki komutla sunucudaki mevcut imajları listeleyebilirsiniz:

docker images

Komutu çalıştırdığımızda aldığımız çıktı şöyledir:

Ardından, çalışma zamanı ortamını yapılandırmada kullanılan env dosyasını değiştirmemiz gerekiyor. Bu dosya, konteyner başlatılırken Docker run konteynerine aktarılır. env dosyasını nano düzenleyici ile açın:

The env dosyasında, değiştirmeniz ve doğru değerlerinizle doldurmanız gereken bazı yer tutucu metinler bulunmaktadır:

• DJANGO_SECRET_KEY: Şurada açıklandığı gibi benzersiz, tahmin edilemeyen bir değer oluşturun: Django docs. Rastgele bir dize oluşturmak ve bunu değişkene atamak için bu komutu kullanabilirsiniz:  python -c 'from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())'.

• DJANGO_ALLOWED_HOSTS: bu değer, uygulamanızı HTTP Host Header saldırılarına karşı korumak için kullanılır. Bunu, geliştirme modundaysanız tüm ana bilgisayarlarla eşleşen joker karakter olan * değerine ayarlayabilirsiniz. Uygulamanızı canlı ortama dağıttığınızda, bunu kayıtlı alan adınız olarak ayarlayın. Bizim gösterimimiz için bu example_domain.com.

• DB_DATABASE: bunu, Prerequisites bölümünde oluşturduğunuz PostgreSQL veritabanının adına ayarlayın, bizim durumumuzda bu polls_db.

• DB_USERNAME: bunu veritabanınız için seçtiğiniz kullanıcı adına ayarlayın.

• DB_PASSWORD: bunu veritabanınız için seçtiğiniz şifreye ayarlayın.

• DB_HOST: bunu, Prerequisites bölümünde kurduğunuz gibi veritabanı örneğinizi çalıştıran ana bilgisayara ayarlayın. Bu, veritabanını kurmak için Building a Django and Gunicorn Application with Docker on Ubuntu kılavuzunun 1. ve 2. Adımlarında açıklanmıştır.

• DB_PORT: bunu veritabanınızın portuna ayarlayın.

Düzenlemeyi bitirdikten sonra dosyayı kaydedip kapatın. Veritabanı kimlik bilgilerimiz hazır olduğunda, konteyneri çalıştırarak ve Dockerfile içinde ayarlanan CMD komutunu geçersiz kılarak veritabanı şemasını oluşturabiliriz. Şunun hakkında daha fazla bilgi bulabilirsiniz: Dockerfile entry point from official Docs. Ardından, aşağıdaki komutu çalıştırın:

Bu komutta, django-polls:v1 imajını çalıştırıyoruz ve daha önce düzenlediğimiz env dosyasını içeri aktarıyoruz. Şu kısım: sh -c "python manage.py makemigrations && python manage.py migrate” uygulama kodu tarafından tanımlanan veritabanı şemasını oluşturur. Komutu ilk kez çalıştırıyorsanız, veritabanı şemasının oluşturulduğunu gösteren benzer bir çıktı görmelisiniz:

Şema oluşturulduktan sonra Django süper kullanıcısını (superuser) oluşturabiliriz. Konteyneri etkileşimli bir kabuk (shell) ile başlatmak için aşağıdaki komutu çalıştırın:

Komut, Python kabuğu ile etkileşime girmek için kullanabileceğiniz bir kabuk istemiyle konteyneri başlatır. Aşağıdaki komutla bir kullanıcı oluşturalım:

Kullanıcı adı, e-posta adresi ve şifre girmek için istemleri takip edin. Şifreyi tekrar yazın ve kullanıcıyı oluşturmak için enter tuşuna basın. Kabuktan çıkın ve şu tuşlara basarak konteyneri sonlandırın: CTRL+D.

Ardından, varsayılan komutu collectstatic Django komutuyla geçersiz kılarak konteyneri tekrar çalıştırmamız gerekiyor. Bu komut, uygulama için statik dosyaları oluşturacak ve bunları MinIO Bulut Depolama alanına yükleyecektir:

Komut, dosyayı oluşturur ve yapılandırılmış nesne depolama servisinize yükler. İşte çıktı:

Artık Dockerfile içinde tanımlanan varsayılan CMD komutunu geçersiz kılmak için ek bir komut belirtmeden uygulamayı çalıştırabilirsiniz:

Docker, Dockerfile içinde tanımlanan varsayılan komutu çalıştırır, konteyneri gunicorn sunucusuyla başlatır, konteyner portu olan 8000 portunu dışa açar ve bunu Ubuntu'nun 80 portuna eşler. Artık adres çubuğunuzda ilk sunucunun IP adresine erişerek uygulamanın arayüzünü tarayıcınızda görüntüleyebilirsiniz: http://FIRST_SERVER_IP.

Bir 404 Page Not Found hatası alacaksınız çünkü şunun için herhangi bir şey tanımlamadık: / yolu. Şuraya gidin: http://FIRST_SERVER_IP/polls Polls arayüzünü görmek için:

Bazı anketler oluşturmak için yönetici arayüzünü ziyaret edin: http://FIRST_SERVER_IP/admin:

Yönetici arayüzüne erişmek için yukarıdaki createsuperuser komutuyla belirlediğiniz kimlik bilgilerini sağlayın:

Sayfa kaynağını görüntülerseniz, statik dosyaların tanımlandığı gibi depolama klasöründen (bucket) çekildiğini fark edeceksiniz. Konteynerin uygulamayı beklendiği gibi sunduğunu onayladıktan sonra, terminalde CTRL+C tuşlarına basarak konteyneri sonlandırabilirsiniz.

Ardından, ilk sunucunun SSH oturumundan çıkabilmemiz için konteynerin detached modda çalışmaya devam etmesini sağlamamız gerekir. Bu, konteynerin arka planda çalışmaya devam etmesini sağlayacaktır. Aşağıdaki komutu çalıştırın:

The -d bayrağı, konteyneri arka planda çalışmaya devam edebilmesi için detached modda başlatır. --rm bayrağı, konteyner kapandıktan sonra konteynerin dosya sistemini temizler. Konteynere, konteynerleri listelediğimizde görebilmemiz için polls adını veriyoruz.

İlk sunucunuzun SSH oturumundan çıkın ve beklendiği gibi çalıştığını onaylamak için tarayıcınızda http://FIRST_SERVER_IP/polls adresine gidin. Anket arayüzünü görüntüleyebiliyorsanız, ilk uygulama sunucunuz başarıyla kurulmuş demektir. Bir sonraki adımda ikinci uygulama sunucusunu kuralım.

Adım 2: İkinci Uygulama Sunucusunun Kurulması

Uygulamanın, Building a Django and Gunicorn Application with Docker on Ubuntu eğitiminde oluşturduğumuz Dockerize edilmiş dalını (branch) klonlayacağız. Burada kullanacağımız komutların daha fazla detayını o eğitimde veya Adım 1.

altındaki özetlenmiş sürümde bulabilirsiniz. İkinci sunucunun çalışıyor olması, root olmayan bir sudo kullanıcısı eklemiş olmanız ve Prerequisites bölümünde açıklandığı gibi Docker'ı kurmuş olmanız gerekir.

Bir sonraki adım, bu sunucuyu PostgreSQL sunucu örneğine bağlanacak şekilde yapılandırmaktır. Building a Django and Gunicorn Application with Docker on Ubuntu eğitiminin 1. Adımında açıklandığı gibi, ikinci sunucunun IP adresine ufw ve PostgreSQL yapılandırmaları üzerinden izin vermeniz gerekir.

İlk olarak, root olmayan sudo kullanıcınızla PostgreSQL veritabanı sunucusu örneğinde oturum açın. ufw kuralını eklemek için aşağıdaki komutu çalıştırın:

Ardından, bu komutu çalıştırın ve ikinci sunucunun IP adresini PostgreSQL istemci kimlik doğrulama dosyasına ekleyin:

Yapılandırmalar hakkında daha fazla bilgi edinmek için yorumları okuyun. Ardından, IP adresinizi belirterek hosts bölümünün altına şu satırı ekleyin:

Düzenlemeyi bitirdiğinizde dosyayı kaydedip kapatın.

Ardından, değişikliklerin geçerli olması için PostgreSQL hizmetini yeniden başlatın:

PostgreSQL veritabanı sunucusu örneğinden çıkış yapın ve ikinci uygulama sunucusu örneğini yapılandırmaya devam edin.

Şu adresten second app server oturum açın: ssh ile oturum açın. Ardından, django-polls- deposunun of the django-polls dalını aşağıdaki komutla klonlayın:

Şu dizine geçin: django-polls dizini:

Bundan sonra, aşağıdaki komutla imajı oluşturun:

İmaj oluşturma işlemi tamamlandıktan sonra, env dosyasını şu bölümde açıklandığı gibi yapılandırma değerleriyle düzenleyin: Step 1. Dosyayı nano ile açın:

Yer tutucu metinleri, Adım 1'de eklediğiniz gerçek değerlerle değiştirin. DJANGO_ALLOWED_HOSTS değişkenini uygun şekilde değiştirmeyi unutmayın. İşiniz bittiğinde dosyayı kaydedip kapatın. Önceki adımda yaptığınız gibi env  dosyasındaki MinIO kimlik bilgilerinizi güncelleyin.

Artık aşağıdaki komutla uygulama konteynerini arka planda (detached) modda çalıştırabilirsiniz:

Bu komut konteyneri başlatır ve arka planda çalışmaya devam etmesini sağlar. İkinci uygulama sunucusunun ssh oturumundan çıkın ve tarayıcınızda http://SECOND_SERVER_IP/polls adresine giderek beklendiği gibi çalıştığını doğrulayın. Her şey beklendiği gibi gittiyse anket arayüzünü görebilmeniz gerekir.

Artık uygulamanızın aynı kopyasını çalıştıran iki uygulama sunucunuz var. Bir sonraki adımda, Nginx konteynerini ters proxy (reverse proxy) olarak hizmet verecek şekilde yapılandıracaksınız.

Adım 3: Nginx Docker Konteynerini Kurma

Nginx dünyadaki en popüler açık kaynaklı web sunucusu yazılımlarından biridir. İnternetteki en yüksek trafiğe sahip sitelerin erişilebilirliğini ve ölçeklenebilirliğini sağlamaktan sorumludur. güvenlik sağlar ve oldukça çok yönlüdür. Bunu ters proxy oluşturma, önbelleğe alma ve yük dengeleme için kullanabilirsiniz. Uygulamamızı, statik ve medya dosyalarını işlemek için ayrı bir nesne depolama hizmeti kullanacak şekilde yapılandırdık. Bu nedenle Nginx önbelleğe alma özelliklerini kullanmayacağız. Bunun yerine Nginx ters proxy ve yük dengeleme yeteneklerini kullanacağız. Nginx ön yüz sunucusu gelen trafiği alacak ve bunu arka uç uygulama sunucularına dağıtacaktır. Ardından, Let’s Encrypt.

'ten alınan SSL sertifikalarını kullanarak trafiği güvence altına alacak ve istemci ile sunucu arasında güvenli iletişim sağlayacaktır. Nginx ters proxy ve yük dengelemeyi uygulamanın birkaç yolu vardır. Bu yollardan biri, bu eğitimde yaptığımız gibi Nginx ters proxy'sini arka uç uygulama sunucusundan ayrı olarak ayarlamaktır. Bu kurulum esnektir ve hem Nginx proxy katmanını hem de uygulama katmanını ölçeklendirmenize olanak tanır. Birden fazla Nginx proxy'si ekleyebilir veya bir bulut yük dengeleyici uygulayabilirsiniz. Ters proxy uygulamanın başka bir yolu da arka uç uygulama sunucularından birini Nginx proxy'si olarak kullanmaktır. Ardından, gelen istekleri yerel olarak ve diğer uygulama sunucularına proxy edebilirsiniz. İsteğe bağlı olarak, tüm arka uç uygulama sunucularında bir Nginx konteyneri yapılandırabilir ve gelen trafiği alıp arka uç uygulama sunucularına dağıtmak için ön tarafta duran bir bulut yük dengeleyici ayarlayabilirsiniz.

Proxy sunucusunu yapılandırmaya başlayalım. Nginx proxy olarak kullanılmak üzere ayarladığınız dördüncü Ubuntu sunucusunda oturum açın ve bir yapılandırma dizini oluşturun:

Dizinin içinde nano ile bir yapılandırma dosyası açın:

Ardından, dosyaya aşağıdaki yapılandırmayı ekleyin:

Bu yapılandırma dosyasında, server, upstream, ve location bloklarını, Nginx'e HTTP isteklerini HTTPS'e yönlendirmesini ve istekleri Adım 1 ve Adım 2 içinde kurduğumuz iki uygulama sunucusu arasında dağıtmasını söylemek için belirtiyoruz. Nginx'in resmi belgelerindeki yapılandırma dosyası yapısı hakkında genel bilgileri bulabilirsiniz..

Docker Hub Nginx imajı dokümantasyonu, , Certbot ve Gunicorn tarafından sağlanan yapılandırma dosyalarını inceledik. bu minimal Nginx yapılandırma dosyasını oluşturmak için. Bu yalnızca gösterim amaçlı ve kurulumumuzu çalışır hale getirmek için olsa da, şununla keşif ve denemeler yapmakta özgürsünüz: Nginx kılavuzlarını takip eden diğer yapılandırmalar.

Upstream bloğu, gelen istekleri işleyecek sunucu grubunu tanımlamak için kullanılır. Gruba bir ad verilir ve bu ad proxy_pass yönergesi tarafından çağrılır. Bloğu django olarak adlandırdık ve iki arka uç uygulama sunucusunun IP adreslerini belirttik:

Ayrıca 3 sunucu bloğu tanımladık. İlk sunucu bloğu, alan adınızla eşleşmeyen tüm istekleri yakalar ve bir 444 kodu döndürür (istemciye bir yanıt göndermeden bağlantıyı kapatır, böylece kötü niyetli veya hatalı biçimlendirilmiş istekleri reddeder). Sunucunuzun IP adresine yapılan doğrudan bir HTTP isteği, şu şekilde tanımlandığı için bu blok tarafından işlenir: default_server:

The İkinci sunucu bloğu, gelen HTTP (port 80) isteklerini işler ve bunları 443 kullanarak HTTPS (port ) protokolüne yönlendirir: HTTP 301 yönlendirmesi:

Üçüncü sunucu bloğu artık istekleri işler. Birkaç yönergeye sahiptir ve bunların önemini aşağıda tanımlayacağız.

Certbot tarafından sağlanan TLS sertifikası ve anahtarının yollarını tanımlayan iki yönergemiz var. Sertifikalar, başlattığımızda Nginx konteynerine bağlanır:

Sırada, Certbot tarafından önerilen SSL güvenlik varsayılanları var. Şuradan daha fazla bilgi edinebilirsiniz: ngx_http_ssl_module hakkındaki resmi Nginx belgeleri. Mozilla ayrıca şu konuda daha fazla bilgi sunmaktadır: Sunucu Tarafı güvenliği. ssl_ciphers değeri, conf dosyasında kullanılmak üzere Mozilla'nın sayfasından alınmıştır:

Sonraki iki yönergede, istemci istek gövdesinin izin verilen maksimum boyutunu tanımlayacağız ve istemciyle olan keep-alive bağlantıları için zaman aşımını ayarlayacağız. Nginx, keepalive_timeout yönergesinde ayarladığınız saniyeden sonra istemciyle olan bağlantıları kapatacaktır. Resmi belgelerden Gunicorn Dağıtımı için Nginx yapılandırmaları hakkında daha fazla bilgi bulabilirsiniz:

Yapılandırma dosyasında ayrıca iki konum bloğu tanımladık. İlk blok, proxy yönergeleriyle tanımlandığı gibi isteklerin proxy'lenmesini işler. Gelen istekler, daha önce tanımlanan upstream django sunucularına proxy'lenir:

Proxy yönergeleri hakkında daha fazla bilgiyi şurada bulabilirsiniz: Nginx Module ngx_http_proxy_module ve şu belgelere göz atabilirsiniz: bir Gunicorn sunucusu dağıtma.

İkinci location bloğunda bir yol tanımlıyoruz: /well-known/acme-challenge/. Genellikle bir SSL sertifikası sağlanmadan veya yenilenmeden önce Certbot tarafından alan adınızı Let’s Encrypt ile doğrulamak için kullanılır:

Nginx yapılandırma dosyası için bu kadar. Düzenlemeyi bitirdikten sonra dosyayı kaydedip kapatabilirsiniz.

Az önce tanımladığınız yapılandırma dosyası bir Nginx konteynerini çalıştırmak için kullanılabilir. Ancak, Let’s Encrypt'ten SSL sertifikalarını henüz sağlamadığımız için başarısız olacaktır. Bu eğitimde, resmi nginx:1.20.2 Docker imajı sürüm 1.20.2'yi kullanacağız. İmaj kaynağı: resmi Nginx image repository on Docker Hub.

İmajı indirmek ve her şeyin doğru çalıştığını doğrulamak için aşağıdaki komutu çalıştırabilirsiniz:

Bu komut, nginx adında bir konteyner oluşturur ve ana sistem ile konteyner arasındaki 80 ve 443 portlarını eşler. --rm bayrağı, başarılı bir derlemeden sonra tüm ara konteynerleri kaldırır. Yapılandırma dosyasını konteyner içindeki -v bayrağını kullanarak /etc/nginx/conf.d/nginx.conf (varsayılan Nginx yapılandırma dizini) konumuna bağlarız. Nginx konteynerinin dosyayı değiştirmesini önlemek için ro bayrağı kullanılarak salt okunur modda bağlanır. Varsayılan webroot dizinini ayarlayıp /var/www/html olarak bağlıyoruz. Son olarak Docker'a bu derleme için nginx:1.20.2 imajını kullanmasını söylyoruz. Bir sonraki adımda Let’s Encrypt'ten TLS/SSL sertifikasını ve anahtarını alalım.

Adım 4: Let’s Encrypt'ten SSL/TLS Sertifikası Sağlama ve Certbot Otomatik Yenilemeyi Yapılandırma

Certbot şuradan ücretsiz TLS sertifikaları sağlamaya yardımcı olur: Let’s Encrypt ve bunların süresi dolmadan önce otomatik yenilenmesini yönetir. Bu, web sitelerinizin güvenliğini artırır ve HTTPS üzerinden sunulmasını sağlar. Mimarimizi konteynerleştirilmiş olarak tutmaya uygun olarak, SSL/TLS sertifikalarını çekmek ve otomatik yenilemeyi yapılandırmak için Certbot Docker imajını kullanacağız. Proxy sunucunuzda Docker'ın kurulu olduğundan emin olun, bunun için Gereksinimler yönergelerini takip edebilirsiniz.

Ayrıca, kayıtlı alan adınızın proxy sunucunuzun IP adresini gösteren bir DNS A kaydına sahip olmalısınız. Certbot Docker imajını çalıştırıp --staging bayrağını ileterek bunu doğrulayabilirsiniz:

Bu komut Certbot imajını indirecek ve etkileşimli modda çalıştıracaktır. Bu, bazı ayrıntıları girmenize olanak tanıyan bir kabukla geleceği anlamına gelir. Ana sistemin 80 portunu, konteyner içindeki 80 portuna eşler. İki ana sistem dizinini konteynere bağlamak için -v bayrağını kullanırız: /etc/letsencrypt/ ve /var/lib/letsencrypt/. --standalone bayrağı, Certbot imajının Nginx kullanmadan çalışmasını istediğimizi belirtir. Son olarak, elimizde --staging bayrağı vardır; bu bayrak Certbot'un staging sunucularında çalışmasını ve alan adınızı doğrulamasını sağlayacaktır.

E-posta adresinizi girin ve Hizmet Şartları metnini istendiğinde kabul edin. Aşağıdaki çıktı, başarılı bir doğrulamanın sonucudur:

SONRAKİ ADIMLAR:

Sertifikanın süresi dolmadan önce yenilenmesi gerekecektir. Certbot, sertifikayı arka planda otomatik olarak yenileyebilir, ancak bu özelliği etkinleştirmek için bazı adımlar atmanız gerekebilir. Talimatlar için bu bağlantıyı kontrol edin.

Sertifikayı şu komutu kullanarak görüntüleyebilirsiniz: cat komutu:

Yukarıdaki komut sertifikanızı terminalde görüntülemelidir. Certbot'un sertifikanızı sağladığını onayladıktan sonra, artık Adım 3 bünyesinde oluşturduğunuz Nginx yapılandırmasını test edebilirsiniz. Nginx konteynerini başlatmak için aşağıdaki Docker komutunu çalıştırın:

Bu komutta, Let's Encrypt SSL/TLS sertifika dizinlerinin konumunu bağlamak (mount etmek) için -v bayrağını kullandık.

Konteyner çalışmaya başladığında, tarayıcınızda şu web sayfasını açın: http://example_domain.com. Muhtemelen web sitesinin güvenli olmadığına dair bir uyarı göreceksiniz:

Bunun nedeni, Let's Encrypt'ten yalnızca hazırlık/test sertifikaları sağlamış olmamız ve üretim sertifikaları almamış olmamızdır. Üretim sertifikalarını, aşağıdaki Certbot komutunu --staging bayrağı olmadan çalıştırarak alalım:

Komut satırında, mevcut sertifikayı yenilemek ve değiştirmek istediğinizi onaylamak için 2 yazıp ENTER tuşuna basın. Bu işlem, üretime hazır bir sertifika sağlayacaktır. Artık Nginx konteynerini çalıştırabilirsiniz ve her şey düzgün çalışacaktır:

Konteyner çalışmaya başladığında, tarayıcınızda web sayfasını tekrar açın: http://example_domain.com. HTTP yazsanız bile tarayıcınızın HTTPS protokolüne yönlendirildiğini fark edeceksiniz. Bu, Nginx yapılandırmasındaki sunucumuzun yanı sıra sağlanan SSL/TLS sertifikalarının da sorunsuz çalıştığı anlamına gelir. Ana dizin yolu için tanımlanmış bir rotamız olmadığından polls rotasına ( http://example_domain.com/polls ) gidin. /. Anket arayüzünü görmelisiniz:

Şimdiye kadar, üretime hazır bir mimariyi başarıyla yapılandırdınız. Proxy sunucusundan yönlendirilen gelen istekleri işleyecek iki arka uç sunucusu uyguladınız. Proxy sunucusu, yük dengelemeyi ve sağlanan TLS sertifikalarını kullanarak trafiğin güvenliğini sağlamayı üstlenecektir.

Ancak, Let’s Encrypt sertifikalarının 90 gün içinde geçerliliğini yitireceğini unutmamalısınız. Bu nedenle, 90 günlük süre dolmadan önce bunları yenilemelisiniz. Nginx konteyneri çalışıyor olacağından, sertifika yenileme için certbot komutunu çalıştırırken webroot modunu kullanmalısınız, standalone modu yerine. Nginx yapılandırma dosyasında /var/www/html/.well-known/acme-challenge/ dizinini belirttiğinizi unutmayın: Adım 3. Certbot, doğrulama dosyalarını depolamak için bu yolu kullanacaktır. Ayrıca, sertifikaları yenilemeye çalıştığınızda Let’s Encrypt istemcisi bu yolu doğrulama istekleriyle çağıracaktır. Yenileme komutunun yürütülmesi tamamlandığında, değişiklikleri uygulamak için Nginx'i yeniden yükleyebilirsiniz.

Terminalinizde CTRL+C tuşlarına basarak konteyneri sonlandırın ve -d bayrağıyla arka planda (detached) modda tekrar başlatalım:

Bu, Nginx konteynerinin arka planda çalışmaya devam etmesini sağlayacaktır. Sertifika yenileme prosedürünü --dry-run bayrağıyla aşağıdaki komutu çalıştırarak test edelim:

Bu komutta, --webroot eklentisinin yanı sıra doğrulama istekleri için kullanılacak yolu -w bayrağıyla belirttik. Ayrıca, gerçekten bir sertifika sağlamadan otomatik yenileme prosedürünü doğrulamak için --dry-run bayrağını da belirtiyoruz.

Başarılı bir simülasyonda benzer bir çıktı görmelisiniz:

Çalışan uygulamanız için bir sertifikayı her yenilediğinizde, konteynerin yeni sertifikayı kullanmaya başlaması için Nginx'i yeniden yüklemelisiniz. Aşağıdaki Docker komutu nginx (konteyneri nginx olarak adlandırdığımızı unutmayın) konteynerini yeniden yükler:

Komut, HUP Unix sinyalini nginx Docker konteyneri içinde çalışan Nginx işlemine gönderir. Bu, Nginx'in yapılandırmalarını yeniden yüklemesini ve yenilenen sertifikaları kullanmaya başlamasını sağlar.

Proxy sunucumuzda TLS/SSL kurulu olduğundan ve web sitemiz HTTPS ile sunulduğundan, artık arka uç uygulama sunucularımızı yalnızca proxy sunucusundan gelen isteklere izin verecek şekilde güvenli hale getirmemiz gerekiyor.

Adım 5: Arka Uç Django Sunucularını Harici Erişime Karşı Güvenli Hale Getirme

Bu öğreticide uyguladığınız proxy sunucusu, SSL bağlantısını çözdüğü ve şifrelenmemiş paketleri arka uç uygulama sunucularına ilettiği SSL sonlandırma işlemini gerçekleştirir. Arka uç sunucularını her türlü harici erişime karşı koruyacağımız için, bu güvenlik düzeyi çoğu durum için yeterli olacaktır. Ancak, banka bilgileri veya sağlık verileri gibi hassas verileri ileten uygulamalar dağıtıyorsanız, o zaman şunu uygulamalısınız: uçtan uca şifreleme.

Bu öğreticide, arka uçtaki Gunicorn sunucuları doğrudan dışarıya açık olmaları amaçlanmadığı için Nginx tarafından korunmaktadır. Nginx proxy sunucusu, arka uç sunucularına giden bir geçit gibidir ve harici istemcilerin arka uç uygulama sunucularına doğrudan erişmesini engeller. Tüm isteklerin proxy sunucusundan geçtiğinden emin olmalısınız. Durum böyleyken, Docker'ın ufw güvenlik duvarı kurallarını baypas ettiği ve bağlantı noktalarını harici olarak açtığı bir sorunu vardır; bu da altyapınızı güvensiz bırakabilir. Bu durum aslında uygulama sunucularımızı Adım 1 ve Adım 2 without allowing port 80 bağlantı noktasına ufw kurallarında izin vermeden kurduğumuzda açıkça görülmektedir. Ancak, tarayıcıda sunuculardan birinin genel IP adresini ziyaret ettiğinizde web sayfalarına hala erişebilirsiniz. Bu sorunu çözmenin bir yolu, doğrudan iptables'ı doğrudan ufw üzerinden geçmeden kullanmaktır. Daha fazla bilgi edinmek için Docker ve iptables resmi belgelerini okuyabilirsiniz. Önerilen bir diğer yol ise bulut güvenlik duvarlarını kullanmaktır.

Docker tarafından açılmış olabilecek tüm bağlantı noktalarına harici erişimi engellemek için UFW yapılandırmalarını değiştirelim. Ana makinenin 80 bağlantı noktasını, Docker konteynerinin 8000 bağlantı noktasına, Docker komutundaki -p 80:8000 bayrağıyla eşlediğimizde, yanlışlıkla ana makinedeki 80 bağlantı noktasını da dışarıya açmış olduk. Bu erişimi, ufw-docker deposu README dosyasında açıklandığı gibi UFW yapılandırmasını değiştirerek devre dışı bırakabilirsiniz.

İlk Django uygulama sunucusu için değişiklik yapalım. Sunucuda oturum açın ve /etc/ufw/after.rules konumundaki dosyayı sudo kullanıcısı olarak nano ile açın:

Dosya aşağıdaki ufw kurallarını içerir:

Dosyanın en altına aşağıdaki UFW yapılandırma satırları bloğunu ekleyin:

Eklediğiniz kurallar, Docker'ın açtığı portlara genel erişimi engeller. Ayrıca, 10.0.0.0/8, 172.16.0.0/12, ve 192.168.0.0/16 özel IP aralıklarından erişime izin verir. Kurallar hakkında daha fazla ayrıntıyı şuradan okuyabilirsiniz: ufw-docker README. Düzenlemeyi bitirdiğinizde dosyaları kaydedip kapatın. Bu kurulum, tüm üç sunucunuzun da içinde yer aldığı bir sanal özel bulut ağı (VPC) kurduysanız ve ardından Nginx'in upstream yönergesinde Django sunucularının özel IP'lerini belirttiyseniz çalışacaktır yapılandırma dosyası.

Ancak, genel IP'ler kullandık ve bir VPC'miz olmayabilir. Bu nedenle, ufw aracına, Nginx proxy sunucusundan gelen trafiğe her iki Django uygulama sunucusunun 80 portu üzerinden izin vermek için bir kural eklemelisiniz. ufw aracına, kaynak sunucu IP'sini belirterek portuna izin veren bir kuralı80 aşağıdaki komutu kullanarak ekleyebilirsiniz:

Değişiklikleri tamamladıktan sonra, sudo ufw reload komutunu çalıştırmak değişiklikleri uygulamada yetersiz kaldığı için, değişikliklerin geçerli olması için Django uygulama sunucunuzu yeniden başlatın:

Sunucu yeniden başlatıldığında, konteyneri Adım 1 veya Adım 2:

Ardından, Polls arayüzünü gösterip göstermediğini görmek için tarayıcıda ilk Django sunucusunun IP'sini ziyaret etmeyi deneyin: http://FIRST_SERVER_IP/polls. Bu başarısız olacaktır. Şimdi, ilk sunucudan çıkış yapın ve burada yaptığınız adımları ikinci sunucu için tekrarlayın. /etc/ufw/after.rules dosyasını bir sudo kullanıcısı olarak nano ile açın:

Daha önce yaptığınız gibi, en alta kaydırın ve UFW yapılandırma bloğunu ekleyin:

Yukarıdaki bloğu ekledikten sonra dosyayı kaydedip kapatın.

Ardından, şuraya bir izin verme kuralı ekleyin: ufw kaynak sunucu IP'sini şu porta belirterek: 80 aşağıdaki komutu kullanarak:

Değişikliklerin geçerli olması için sunucunuzu yeniden başlatın:

Sunucu tekrar açıldığında, aşağıdaki komutla konteyneri yeniden ayağa kaldırın:

Doğrudan ikinci sunucunun IP adresine giderek anket arayüzünü görüntüleyip görüntüleyemediğinizi test edin: http://SECOND_SERVER_IP/polls. Bu da başarısız olmalıdır.

Bu mimari artık test edilmeye hazır. Tarayıcınızdan varsayılan Anketler arayüzünü görüntülemek için https://example_domain_here/polls adresini ziyaret edebilirsiniz. Bu, Nginx proxy sunucusunun Django arka uç sunucularına hâlâ erişimi olduğu anlamına gelir.

Sonuç

Bu kılavuzda, Docker konteynerlerini kullanarak ölçeklenebilir bir altyapıyı nasıl uygulayacağınızı gösterdik. Altyapı; ayrı bir PostgreSQL veritabanı sunucusu, iki arka uç uygulama sunucusu ve trafiği bu iki sunucu arasında dengelemek ve dağıtmak için bir Nginx proxy sunucusu içerir. Uygulamamızı Django Anket uygulaması üzerine kurmuş olsak da, bu mimariyi Node.js, Laravel vb. farklı çerçeveler kullanan çeşitli uygulamalar için özelleştirebilirsiniz.

Bu, başlamanız için temel bir kılavuzdur. Ekleyebileceğiniz birkaç iyileştirme, imajınızı Docker Hub gibi bir imaj deposunda barındırarak imajın birden çok sunucuya kolayca dağıtılmasını sağlamaktır. Ayrıca, bir olay gerçekleştiğinde imajları otomatik olarak derlemek, test etmek ve uygulama sunucularına dağıtmak için sürekli entegrasyon ve dağıtım hatları ekleyebilirsiniz. Örneğin, bir git deposundaki belirli bir dala yeni kod gönderilmesi bir olay olabilir. Konteyner bir hatayla karşılaştığında ne olacağını da otomatikleştirmek isteyebilirsiniz. Docker resmi belgeleri, hata veya sistemin yeniden başlatılması durumunda Konteynerleri otomatik olarak başlatma konusunda iyi bir kılavuz sunmaktadır.

Keyifli Çalışmalar!