Nginx Reverse Proxy Server (Ters Vekil Sunucu) URL Rewrite Senaryo – Uygulama

Nginx Reverse Proxy Server (Ters Vekil Sunucu) URL Rewrite Senaryo – Uygulama

Nginx nedir : Rus yazılım mühendisi Igor Sysoev tarafından geliştirilen hafif, stabil, hızlı bir mail istemcisi olarak kodlanan daha sonraları geliştirilerek tüm sunucular için uygun hale getirilen bir web sunucusudur.

Nginx birçok amaç için kullanılabilir. Bunlar, ilk meydana çıkış sebebi olan Mail servisi, Web servisi, Reverse Proxy(bu özellik genelde web sayfalarını cache’lemek için kullanılır ve böylelikle sunucu yükünü azaltıp daha hızlı ve stabil çalışmasını sağlar) ve Load Balancer olarak sıralanabilir.

Daha fazla detay için https://nginx.org/en/ linkini ziyaret edebilirsiniz.

Proxy Server(Vekil Sunucu) mantığını açıklamak gerekirse, istemci tarafında bulunan ve web sunuculara çıkış için yani bağlanırken arada bir vekil görevini görmesidir. Reverse Proxy(Ters Vekil) ise sunucu tarafında bulunan ve istemcilerin isteklerine cevap verip web sunuculara bağlanıp istemcilere iletmesidir.

Biz şimdi uygulama senaryomuzda Nginx’i URL Rewrite yapması için kullanacağız. İleride uygulamayı yaptıkça kafanızda daha da oturacaktır. Url nedir aşağıda değinelim.

URL nedir : “Uniform Resource Locator” teriminin baş harflerinden oluşan kısaltmadır. Aslında “adres” dediğimiz şeydir.

URL Rewrite nedir : “Url Yeniden Yazma” yani website Url’lerinin uzun ve karmaşık yapısını daha anlaşılır hale getirme işlemine verilen isimdir.

URL Redirect(Yönlendirme) nedir : Bir URL’ye gelen istekleri başka bir URL’ye iletme yani geçici veya kalıcı olarak yönlendirme işlemidir. URL yönlendirme birçok sebep için kullanılabilir.

Şimdi uygulama senaryomuzu yazalım ve niye böyle bir senaryoya ihtiyaç duyarız bunu belirtelim. Herşeyden evvel ben tüm işlemler için 3 adet sanal makina(CentOS, Ubuntu, Fedora) hazırladım ve o sanallar üzerinden senaryoyu gerçekleştireceğiz. Test domain’imiz webmin.test olarak kullanacağız.

1. Adım : Web Servers olarak kullanacağımız CentOS Sunucu kurulumu gerçekleştirilecek. IP yapılandırması (192.168.1.100). Şimdi bu sunucu üzerinde Apache ile webden hizmet veren birden fazla servis çalışıyor olabilir ve bu servisler 80 değil de hepsi kendine özgü port’lardan erişiliyor olabilir. Ben test için bu sunucu üzerine 10000 portundan çalışan Webmin servisini kuracağım. Siz aynı sunucu üzerine farklı portlardan çalışan birden fazla servisi kurabilirsiniz. Jira, confluence vs gibi yada manuel yapılandırmış servisler gibi gibi.

2. Adım : Reverse Proxy Server için Ubuntu Server kurulumu gerçekleştirilecek. IP yapılandırması (192.168.1.101). Bu sunucu üzerine Nginx kurulumu gerçekleştirilip URL Rewrite için yapılandırılacak.

3. Adım : Tüm bu işlemleri test edeceğimiz Client kullanıcı olarak Fedora kurulumu gerçekleştirilecek.

Peki niye böyle bir şeye ihtiyaç var kısmını açıklamaya gelecek olursak. 1. Adımda farklı portlardan çalışıp webden hizmet sunan birden fazla servis olabilir. Tabi biz bu servislere erişimi Ip üzerinden değilde DNS’te kaydını oluşturacağımız domain üzerinden yapacağız FAKAT servis/servisler farklı portlardan hizmet verdiği için bilindiği gibi http://domain_name:port_numarası şeklinde erişmelidir ki yoksa web servisi default web sayfasını yansıtacaktır. Tabi kullanıcılara port ezberletip şöyle böyle erişin demek mümkün olmayacağı için 2. Adımdaki Reverse Proxy servisini kurup sonra yapılandırıp o işi arka planda Nginx’e yaptıracağız. Tabi böylelikle Web Server’ın yükünü de hafifletmiş olacağız.

Hemen senaryonu adım adım gerçekleştirelim.

1. Adım :

CentOS sunucu kurulumu gerçekleştirilecek. Aşağıdaki link yardımıyla bunu yapabilirsiniz.

http://www.fatlan.com/centos-7-minimal-kurulum/

Daha sonra Ip yapılandırmasını senaryodaki gibi yapılandırın. Aşağıdaki linkten yardım alabilirsiniz.

http://www.fatlan.com/centos-7-network-ayarlari/

Ardından ben test için 10000 portundan çalışan Webmin servisini kuracağım. Siz isterseniz kendi bildiğiniz farklı porttan çalışan webden hizmet veren bir yada birden fazla servisi kurup çalışır vaziyete getirebilirsiniz. Yada manuel olarak Apache kurup onun üzerine bina edebilirsiniz.

http://www.fatlan.com/webmin-nedir-nasil-kurulur-centos-7-ve-6/

2. Adım :

Ubuntu Server kurulumu gerçekleştirilecek. Aşağıdaki link yardımıyla bunu yapabilirsiniz.

http://www.fatlan.com/ubuntu-server-14-04-lts-kurulumu/

Daha sonra Ip yapılandırmasını senaryodaki gibi yapılandırın. Aşağıdaki linkten yardım alabilirsiniz.

http://www.fatlan.com/ubuntu-14-04-lts-network-ayarlari/

Şimdi Nginx kurulumu gerçekleştirin. Gene alttaki linkten yardım alabilirsiniz.

http://www.fatlan.com/linux-ubuntu-centos-server-uzerine-nginx-kurulumu-nginx-nedir/

Ve şimdi Nginx’i Reverse Proxy(Ters Vekil) olarak yapılandıralım.

Aşağıdaki komutla yapılandırma dosyasının dizin’ine gidelim.

> cd /etc/nginx/sites-available/

Yapılandırma dosyamızı oluşturalım.

> touch webmin.test

Şimdi listeleyelim.

> ls

Daha sonra ise dosyanın içine herhangi bir editör yardımıyla girip aşağıdaki şekilde yapılandıralım.

> sudo vi webmin.test

server {

             listen 80;

             server_name webmin.test;

             return 301 https://192.168.1.100:10000;                  —> Bu kısım webmin https(443) ten çalıştığı için webmin servisine özel eklenmiştir. Http(80) çalışan servislerde bu satırı eklemeyiniz.

location / {

                  proxy_pass https://192.168.1.100:10000/;

                  proxy_set_header X-Forwarded-Host $host;

                  proxy_set_header X-Forwarded-Server $host;

                  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

                  proxy_set_header X-Real-IP $remote_addr;

                    }

}

 

Ardından yapılandırmamızın etkin olabilmesi için sembolik link oluşturalım.

> sudo ln -s /etc/nginx/sites-available/webmin.test /etc/nginx/sites-enabled/webmin.test

İşlemin doğruluğunu teyit edelim.

>ls -l /etc/nginx/sites-enabled/webmin.test

En son Nginx servisini reboot edelim.

> systemctl restart nginx.service yada sudo /etc/init.d/nginx restart

3. Adım :

Herşey tamam, şimdi sıra test etme aşamasında. Bunun için webmin.test domaini için dns’te kaydını oluşturup, istekleri nginx’e göndereceğiz, her şey doğru yapılandırıldıysa zaten arka planda nginx request’i işleyip web sayfasını kullanıcıya gönderecektir. Tabi biz tüm bu işlemler için yerel dns olan hosts dosyasını kullanacağız.

İlk olarak aşağıdaki komutla kaydımızı oluşturuyoruz. Dosyayı kaydedip, çıkıyoruz.

> vi /etc/hosts

Şimdi ping atıp test edelim ve başarılı bir şekilde çözümlediğini görelim.

> ping webmin.test

 

Şimdi sıra geldi tarayıcı üzerinden hizmete erişim. Adres çubuğuna webmin.test/ yazıp enter’a basalım ve başarılı bir şekilde bağlandığımızı görelim.

Normalde işlem tamam ve istediğimiz senaryo gerçekleşti fakat burada bilgi amaçlı olarak şundan da bahsedelim Webmin https(443) üzerinden çalıştığı için kullanıcı adı ve şifreyi yazdığınız zaman login olamayacaksınız ve aşağıdaki uyarıyı alacaksınız.

Bu uyarıyı almamak ve login olabilmek için biz yukarıda “return 301 https://192.168.1.100:10000;” satırını ekledik. Yani bu satır eklenince Webmin’e login olunabiliniyor. Yani Http(80)’de çalışan bir servis olsaydı ne bu sorun olacaktı ne de bu satırı ekleyecektik. Aslında burada bir trik var Nginx’te virtualhost dosyasına 2. Adımda yukarıdaki kadar satır eklemek yerine Webmin servisi zaten 443’ten çalıştığı için “return 301 https://192.168.1.100:10000SADECE bu satırla bile işimizi çözüyor olacaktık fakat adres çubuğunda, bağlantı gerçekleştiğinde domain adı değil de ip bilgileri yer alıyor olurdu. Aşağıdaki gibi. Halbuki 101 makinesine istek attık.

Daha fazla bilgi için https://www.nginx.com/blog/creating-nginx-rewrite-rules/ linkini ziyaret edebilirsiniz.

3 Comments

  • suleyman yalçın

    21 Eylül 2017 at 23:20 Cevapla

    İyi günler. Ngnix ile ilgili bir sorum olacak cevaplayabilirseniz sevinirim.

    Bir süredir Mikroservisler üzerine araştırmalar yapıyorum şuan takıldığım tek nokta nginx ile ilgili.
    Yapmak istediğimi size kısaca anlatayım.

    Ben kullanıcıya sunacağım web arayüzünü servisler şeklinde programlamak istiyorum.
    Örneğin:
    http://www.domain.com anasayfasına istek gönderildiğinde 192.168.1.10 adresinde barınan web uygulaması cevap versin
    http://www.domain.com/customer ve http://www.domain.com/custumer/….. adreslerine istek gönderildiğinde 192.168.1.11 adresinde barınan web sunucusu cevap versin.
    ve bu uygulamaların başka örnekleri de loadbalancer ilişkisi kurmak için bulanacak.
    ilgili uygulamalar da mikroservis olarak host edilmiş apilere istek gönderecekler.

    şimdi buraya kadar anlaşılır olduğunu düşünüyorum.
    nginx in temel configuration işlemlerini yapıyorum loadbalancer da yapabiliyorum fakat yukarıda bahsettiğim senaryoda takıldım.
    Aşağıda yapmaya çalıştığım örnek config dosyasını paylaşıyorum göz atabilirseniz sevinirim iyi çalşmalar.

    worker_processes 1;
    events {
    worker_connections 1024;
    }
    http {
    include mime.types;
    default_type application/octet-stream;
    sendfile on;
    keepalive_timeout 65;

    –Docker üzerinde barınan customer servisi için upstream ayarı.
    upstream customerService {
    zone upstream-customerService 64k;
    server 66.249.66.6:80 max_fails=3 fail_timeout=60 weight=1;
    server 66.249.66.5:80 max_fails=3 fail_timeout=60 weight=1;
    server 66.249.66.4:80 max_fails=3 fail_timeout=60 weight=1;
    }
    –Kullanıcının kullanımına sunulan front-end uygulamasının anasayfası için upstream ayarı
    upstream homepage {
    zone upstream-customerListPage 64k;
    server 62.249.66.6:80 max_fails=3 fail_timeout=60 weight=1;
    server 62.249.66.5:80 max_fails=3 fail_timeout=60 weight=1;
    server 62.249.66.4:80 max_fails=3 fail_timeout=60 weight=1;
    }
    –Kullanıcının kullanımına sunulan front-end uygulamasının müşteri ekleme sayfası için upstream ayarı
    upstream customerAddPage {
    zone upstream-customerAddPage 64k;
    server 65.249.66.6:80 max_fails=3 fail_timeout=60 weight=1;
    server 65.249.66.5:80 max_fails=3 fail_timeout=60 weight=1;
    server 65.249.66.4:80 max_fails=3 fail_timeout=60 weight=1;
    }
    –Kullanıcının kullanımına sunulan front-end uygulamasının müşteri silme sayfası için upstream ayarı
    upstream customerRemovePage {
    zone upstream-customerRemovePage 64k;
    server 64.249.66.6:80 max_fails=3 fail_timeout=60 weight=1;
    server 64.249.66.5:80 max_fails=3 fail_timeout=60 weight=1;
    server 64.249.66.4:80 max_fails=3 fail_timeout=60 weight=1;
    }
    –Kullanıcının kullanımına sunulan front-end uygulamasının müşteri listeleme sayfası için upstream ayarı
    upstream customerListPage {
    zone upstream-customerListPage 64k;
    server 63.249.66.6:80 max_fails=3 fail_timeout=60 weight=1;
    server 63.249.66.5:80 max_fails=3 fail_timeout=60 weight=1;
    server 63.249.66.4:80 max_fails=3 fail_timeout=60 weight=1;
    }

    server {
    listen 80;
    server_name services.domain.com;
    –customer servisi asp.net core üzerinde host edilen api uygulaması ve /api/customer adresi üzerinden ilgili customer operasyonlarına erişiliyor
    location /api/customer {
    proxy_pass http://customerService;
    }

    location / {
    root html;
    index index.html index.htm;
    }
    }

    server{

    listen 80;

    server_name domain.com;
    –www.domain.com anasayfası için yönlendirme
    location /{
    proxy_pass http://homepage;
    }
    –www.domain.com/newcustomer sayfası için yönlendirme
    location /newCustomer {

    proxy_pass http://customerAddPage;
    }
    –www.domain.com/removecustomer sayfası için yönlendirme
    location /removeCustomer {

    proxy_pass http://customerRemovePage;
    }
    –www.domain.com/listcustomer sayfası için yönlendirme
    location /listCustomer {

    proxy_pass http://customerListPage;
    }

    }
    }

  • Fatih ASLAN

    24 Eylül 2017 at 18:54 Cevapla

    İyi günler.
    Sorunuzu tam anlamamakla beraber(hata mesajı nedir.? yada config çalışmadı mı.?), config microservis mimarisine uygun olmayabilir. Açıkcası nginx mikroservislerle ilgili bir pratiğim olmadı.
    Fakat bir kaç link paylaşayım, umarım size faydali olur.
    *https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/
    *https://www.nginx.com/blog/introduction-to-microservices/
    *https://www.infoq.com/microservices?utm_source=infoq&utm_medium=header_graybar&utm_campaign=topic_clk&utm_expid=14598459-44.OMT-JCDrQdyXdF2tFwk6yQ.0&utm_referrer=https%3A%2F%2Fwww.infoq.com%2F (burda bu işi ortaya çıkaran, kullanan kişiler neler yaptığını açıklıyor, faydalı olabilir.)
    *ebook:https://www.nginx.com/resources/library/designing-deploying-microservices/
    Kolay gelsin.

  • suleyman yalçın

    4 Ekim 2017 at 19:47 Cevapla

    Cevabınız için teşekkür ederim. İyi çalışmlar.

Post a Comment

13 + one =