Author Archive

Kubernetes Nedir, Nasıl Çalışır, Nerede Kullanılır?

Kubernetes’in kelimesi Yunancadan geliyor ve anlamı dümenci (helmsman) veya pilot olarak karşımıza çıkıyor. Çoğu kaynaklarda kubernetesi k8s olarak yazıldığını görebilirsiniz. Bunun sebebi k ve s harflerinin arasında 8 tane harf olmasıdır.

Kubernetes (K8s), konteyner uygulamaların dağıtımını, ölçeklendirilmesini ve yönetimini otomatikleştirmek için açık kaynaklı bir sistemdir.

Sektörün ihtiyaçları neticesinde container yapılarının yoğun olarak kullanılmaya başlanmasıyla, yönetim ve operasyon yükünü kısıtlı personel ile kaldırabilmek adına bu sistemleri otonom haline getirmek kaçınılmaz bir hal aldı. Kubernetes’in öne çıktığı nokta tam olarak burası diyebilirim. Gerçek hayattan birkaç örnek verecek olursak;

  • Bizim makine bütünümüz var yani 1000 core luk bir makine halinde değil 8/10/12 vb gibi parçalar halinde, biz uygulamaları bunların üzerinde çalıştırırken uygulamaların nerede çalışacağına da karar vermek istemiyoruz. Bu durumlardan dolayı bütün container orchestratorlar birer cluster manager rolünde. Bunların üzerine bir agent kuruyoruz ve bize uygulamayı yönetme imkanı veriyor. Bizim 20 tane 10 core luk makinemiz varsa ben onları 200 core şeklinde bir bütün olarak görüyorum.
  • Containerları kurduk, 5 tane container çalıştıracağım, bunları aynı VM ler üzerinde değil de farklı VM lerde çalıştrımak istiyorum (best practice) gibi mantıksal tercihlerin yapılması ve aynı zamanda bir önceki maddede belirttiğim makine bütününde kullanılan/kalan core hesaplarının yapılması gibi işlemler içinde pencerenin bütününü gören bir mekanizmaya ihtiyacımız var bu noktada bir container orchestrator ihtiyacımız doğuyor.

Bu bilgiler ışığında kubernetes’in çözdüğü ve çözmeye aday olduğu noktalar ;

  • Tüm alt yapıyı tek bir bütün olarak görmemize/yönetmemize olanak sağlıyor.
  • Alt yapımızı daha iyi kullanmamıza olanak veriyor.
  • Containerlarda health check yaparak kontrollü çalışmasını sağlıyor.
  • Bir container herhangi bir sebepten fail duruma geçerse, yenisinin ayağa kaldırılmasını sağlıyor.
  • Maintenance yada failing durumlarında HA şeklinde bir node üzerindeki uygulamaları bir diğerine kesintisiz şekilde taşınmasını sağlıyor.
  • Conteinerların belirlenen kriterlerde auto-scale edilmesini sağlıyor ve aynı zamanda scale olan containerlere yük dağılımını da sağlıyor.
  • Yeni versiyonların herhangi bir kesinti olmadan deploy edilmesini sağlıyor.
  • Service discover gibi bir özellik ile ne-nerde bilmemize olanak sağlıyor.
  • Key/Value Store yani konfigürasyonları containerler dışında store edilmesini sağlıyor.
  • Containerlerin izole bir networkte haberleşmesini sağlıyor.

Google’ın GO dili kullanılarak geliştirdiği Kubernetes’i 2014 yılında açık kaynak hale getirildi ve Cloud Native Computing Foundation tarafından desteklenmektedir. Google tarafından 2004 yılından beri kullanılmakta ve hali hazırda milyarlarca konteyner için kullanılıyor.

Kubernetes konteyner içerisindeki uygulama veya servislerinizin en iyi şekilde çalışmasını sağlar.

Servisleri izler, yük dengelemesi yapar, depolama alanlarınızı yönetir, (Yerel depolama birimlerinizden, Amazon servislerine, NFS ve iSCSI protokollerinden verilmiş depolama birimlerine kadar), secret ve konfigürasyon yönetiminizi yapar, konteynerlarınız hataya düştüğünde otomatik olarak onarmaya çalışır, çok basit şekilde yatayda genişlemenizi sağlar. (CPU kullanımına göre otomatik olarak yapılabilir.)

Konteyner yönetim aracı olarak birden fazla alternatif vardır bunlardan başlıcaları docker swarm ve mesos’dur. Bu arada Kubenetes’de konteyner teknolojisi(Container runtime) olarak sadece docker’ı değil başka konteynerlarıda desteklemektedir, bunlar containerd, cri-o, rktlet konteynırlarıdır.
(continue reading…)

 1,797 total views,  39 views today


Docker Nedir

Merhabalar bu yazıda gün geçtikçe popülerliği artan docker ile ilgili bir şeyler yazmak istedim fakat araştırdıkça o kadar güzel yazılar gördüm ki yazmak yerine, benim docker’ı anlama yardım eden yazılardan kısa,net ve anlaşılır bir özet çıkarmak istedim. Kullandığım referansların bir kısımını yazının sonuna ekliyor olacağım.

Konteyner yapısının ve getirdiği farklılıkların daha iyi anlaşılabilmesi için öncelikle eskiden ne yapıyorduk, şimdi ne yapıyoruz bir hatırlayalım.

Sanallaştırma teknolojilerinden önce bir fiziksel sunucu üzerine birden fazla işletim sistemi kurmak mümkün olmuyordu. Farklı her bir işletim sistemi için mutlaka yeni fiziksel kaynak gerekiyordu. Bu durumda her yeni sunucu ihtiyacında temin süresi bekleniyor, alınacak sunucular için rack alanı ayarlanıyor, sistem odasinin soğutma tasarımı ve enerji tüketimi gözden geçiriliyor vs. vs. bir çok olumsuz ve iş yükü getiren detay ortaya çıkıyordu.

Sanallaştırma teknolojileri ile beraber bu durum değişti. Sanallaştırma ile yazılımsal olarak elde bulunan fiziksel donanımların mantıksal olarak ayrılarak birden fazla sanal makine şekline sokulup, kaynakları daha verimli kullanmak başta olmak üzere daha bir çok avantajı beraberinde getirdi diyebiliriz. Sanalaştırma ile onlarca fiziksel makine yerine yüksek kapasiteli tek bir makine içerisine sanal olarak aynı sistemleri kurabilirsiniz. Böylece enerji, kablolama, soğutma, ve sunucuların kapladığı alandan büyük ölçüde tasarruf ve mobilite sağlar. Bakım, onarım, upgrade süreleri kısalır, high availability çözümleri kolaylaşır, olası bir afet veya bir arıza durumlarında downtime sürenizi saniyelere kadar indirir. Bu yapı halen çok yaygın kullanılmakta olup, aşağıdaki resim sanallaştırılmış bir ortamı anlatmaktadır.


(continue reading…)

 216 total views,  9 views today


Linux Rsync ile Yerel veya Uzak Sunucular Arasında Senkronizasyon işlemleri

rsync, uzak ya da lokal olarak dosya transferi işlemlerini gerçekleştiren ve bu işlemlerde kullandığı algoritma sayesinde daha hızlı sonuç sağlayan bir senkronizasyon aracı olarak ifade edilebilir. Açık kaynak kodlu ve GNU Genel Kamu Lisans’ı altında dağıtılan rsync, bir çok Linux dağıtımında öntanımlı olarak yüklü gelmektedir. Ayrıca, bir çok dağıtımın paket yöneticisinden de kolayca kurulabilmektedir. Kaynak ve hedef arasında kopyalama yapmadan önce, bir algoritma üzerinden dosyalar arasındaki farkları tespit eden rsync, hedef’e sadece değişikliğe uğramış ya da tamamen yeni olan dosyaları aktarır. Bu sayede kopyalama süreci hızlandırılmış olur.

  • Tüm bir dizinin ya da dosya sisteminin yedeklenebilmesi
  • Sembolik ve Hard linklerin, dosya ve dizin izinlerinin, sahip ve grup bilgilerinin hedefte muhafaza edilebilmesi
  • Root yetkisine gereksinim duyulmaması
  • Lokal sistem üzerinde yedekleme/senkronizasyon
  • Lokal sistemden, uzaktaki sisteme yedekleme/senkronizasyon
  • Uzaktaki sistemden, lokal sisteme yedekleme/senkronizasyon
  • Network üzerinden transfer için ssh kullanabilme
  • Rsync daemon modu ile sunucu desteği
  • Exclude anahtarı ile spesifik dosya/dizinlerin, dosya tiplerinin hariç tutulabilmesi.

Redhat tabanlı sistemlerde öntanımlı olarak bulunmaktadır. Bu sebeple ayrıca kuruluma ihtiyaç duyulmamaktadır.

Debian ve Ubuntu gibi dağıtımların paket depolarında bulunmaktadır. Dolayısı ile “apt-get” ile kolayca kurulabilmektedir.
(continue reading…)

 8,106 total views


Mysql/Mariadb Master-Slave Replikasyon

Replication kelime anlamı olarak Veri Kopyalama anlamına gelir. Database tarafında ise; bir database’in başka bir sunucu üzerinde eşleniğinin ‘yani hem yapısal hem de datasal olarak’ tutulmasıdır. Master database da yapılan herhagi bir değişiklik anında eşlenik database ‘Slave’ yansır. Replication bir backuplama yöntemi değildir. Çünkü Master database de yapılan bir delete işlemi slave database de de yapılacağı için her iki database de de veri silinmiş olacaktır. Replication nun faydası yüksek erişilebilirlilik sağlaması(Hight Availability) ve uygulamanın performansında artışa sebeb olmaktır. Bu performans artışını da uygulama tarafında insert-update-delete işlemlerini master database’e select işlemlerini de slave database’e yönlendirilerek yapılabilir. Tabi bu yapıyı Çoğaltma şansınız var.Master -Slave -Slave şeklinde Slave sunucau sayısını arttırabilirsiniz. Burada dikkat etmeniz gereken bir nokta var.Master ve Slave sunucuların aynı network farmında bulunması gerekmektedir. Aksi takdirde perforans ta ciddi azalmalar meydana gelir.

Replikasyon Çeşitleri

Replikasyon işlemini senkron ve asenkron olarak ve yarı senkron olacak şekilde 3 şekilde yapabilir. Default olarak asenkron replikasyon yapılır.

Asenkron replikasyon

Master veritabanında transactionlar binary dosyalara yazılır ve slave requestler hazır olduklarında talep ederler. Yalnız bu yöntemde transactionın slave veritabanına ulaşabileceğinin garantisi yoktur. . (row-based replikasyon ve statement-based replikasyon yapma seçeneklerimiz var burada) Asenkron replikasyon avantajı slave veritabanına herhangi bir nedenden dolayı ulaşılamasa bile kullanıcılar veritabanında işlemi yapmaya devam edebilir dezavantajı ise replikasyonun sıfır veri kaybı garantisini verememesidir.

 

Mysql Master-Slave Replication 1

Yarı Senkron replikasyon

Transactionın doğru aktarılmasını sağlamak için slave ve master ünitenin birbirleriyle iletişim kurması anlamına gelir. Master yalnızca binlog dosyasını doldurur ve slavelerden biri transactionın slave’in relay loglarından birine düzgün bir şekilde yerleştirildiğinin doğrulanmasını sağlarsa transaction devam eder. Yarı eşzamanlı replikasyon, bir transactionın doğru şekilde kopyalandığını garanti eder, ancak slave üzerine olan taahhüdün gerçekten gerçekleşeceğini garanti etmez.

Mysql Master-Slave Replication 2

 

Senkron replikasyon

Master veritabanında bir transaction gerçekleştirildiğinde, tüm slave’lerde bu transaction işlenene kadar master transaction sonlanmaz.Bunun dezavantajı ise bir transactionı tamamlamak için çok fazla gecikme olabileceğidir.

Row-Based Replikasyon ve Statement-Based Replikasyon

Statement-based replikasyon ile SQL sorgusunun kendisi binary log dosyasına kaydedilir ve slave tarafından bu sql ler çalıştırılır.Bu sistemin birçok avantajı ve dezavantajı vardır:

  • Gerçek sorgular binary log dosyasına kaydedildiği için veritabanını denetlemek çok daha kolaydır
  • Network üzerinden daha az veri aktarılır

Row-based replikasyon defauly yöntemdir. Satır değişiklikleri binary log dosyalarına kaydedilir ve içerik bilgisi gerektirmez. Avantajları;

  • Birkaç satır değişikliği içeren yüksek eşzamanlılık sorgularıyla performans iyileştirmeleri
  • veri tutarlılığı geliştirme

Master –Slave Replikasyon Örneği

Şimdi biz bu yazıdaki örneğimizde asenkron master-slave replikasyon yapacağız. Öncelikle kullanacağımız ipler aşağıdaki gibidir;

Master Database : 192.168.10.130
Slave Database : 192.168.10.130

  • Eğer veritabanı bulunmuyorsa aşağıdaki gibi kurmamız gerekmektedir.

apt-get install mariadb-server -y


NOT :
MariaDB, GNU Genel Kamu Lisansı altında serbest olarak kullanılabilen, MySQL’in yaratıcısı olan Monty Widenius‘un MySQL’in kodunu çatallayıp (fork) “çoğunlukla” MySQL ile aynı komutları, arayüzleri ve API’leri destekleyecek şekilde geliştirmeye başlanan (MariaDB 5.2 >= MySQL 5.2), toplulukla iç içe hızlı ve verimli şekilde geliştirilmeye devam edilen MySQL ilişkisel veritabanı yönetim sistemidir. Tabi geliştirmelerle birlikte farklı yaklaşımlar da sürümlerle birlikte sunulmaya başlandı. Detaylı bir değerlendirme için MariaDB versus MySQL – Features sayfasını inceleyebilirsiniz.

  • Yükleme tamamlandıktan sonra, MariaDB servisini başlatmak ve aşağıdaki komutla önyükleme zamanında başlatmak için etkinleştirin;
systemctl start mysql
systemctl enable mysql
  • Aşağıda kodu verilen mysql_secure_installation scripti çalıştırarak güvenlik ayarlarını yapabiliriz.Scripti çalıştırdıktan sonra MySQL root şifresini değiştirmeyi, anonim hesabını kaldırmayı ve localhostun dışında root girişi yapılmamasını ve test veritabanını silmek isteyip istemediğinizi sorabilir.

 

mysql_secure_installation

Aşağıda gösterildiği gibi tüm soruları cevaplayın;

Set root password? [Y/n] n
Remove anonymous users? [Y/n] y
Disallow root login remotely? [Y/n] y
Remove test database and access to it? [Y/n] y
Reload privilege tables now? [Y/n] y
    • Şimdi master sunucumuzda mysql yapılandırma dosyasını açıp /etc/mysql/my.cnf aşağıdaki satırları düzenleyelim;
    • bind-address : Belirli interfacelerin dinlenmesini sağlar. Birden fazla interface ekleyebiliriz. 192.168.1.1,10.0.0.1
    • server_id : Bu değişken sunucu kimliğini belirtir. server_id varsayılan olarak 1’e ayarlanmıştır. Replikasyon  topolojisinde kullanılan sunucular için, her replikasyon sunucusu için 1 – 232  aralığında benzersiz bir sunucu kimliği belirtmeniz gerekir.
    • log-basename : binary logun yerini belirtiriz
    • binlog-format : binary log formatını seçmemizi sağlayan parametre. STATEMENT, ROW ve MIXED değerlerini alabilir.
    • binlog-do-db : Replike edilecek veritabanını belirtir bunun yerine istersek binlog-ignore-db parametresi ile replike edilmeyecek veritabanlarınıda ayarlayabiliriz.
[mysqld]
bind-address = 192.168.10.130
server_id=1
log-basename=master
log-bin=/var/log/mysql/mariadb-bin
binlog-format=row
binlog-do-db=masterdb

(continue reading…)

 831 total views,  3 views today


WLSDM ile WebLogic ve Datasource Şifrelerinin Şifresini Çözme / Şifreleme (Decrypt/Encrypt)

WLSDM ile weblogic admin console kullanıcı adı ve şifresini veya data source ların şifrelerini encyrpt halden çözebiliriz.

Bu işleme admin console kullanıcı adını veya şifresinin unuttuğumuz durumlarda veya data source larımızı başka bir domaine taşıdığımız zaman ihtiyaç duyarız.

Şimdi bir örnekle hash li kullanıcı adımızı ve şifremizi çözecek olursak;

  • Öncelikle wlst’i çalıştırırız bunun için $WL_HOME/oracle_common/common/bin dizinine gidip wlst.sh dizinini çalıştırırız.

NOT : MiddlewareHome dizininin nasıl bulacağımıza geçmeden önce kısaca weblogic’deki directory yapısından bahsetmek istiyorum.

  • MW_HOME : Bu değişken ve ilgili dizin yolu, Oracle Fusion Middleware’in bulunduğu konumu belirtir. Bir MW_HOME’da bir WL_HOME, bir ORACLE_COMMON_HOME ve bir veya daha fazla ORACLE_HOME var.
  • WL_HOME: Bu değişken ve ilgili dizin yolu, bir WebLogic Sunucusunu barındırmak için gereken yüklü dosyaları içerir, örneğin .MW_HOME/wlserver_10.3
  • ORACLE_HOME: Bu değişken, Oracle HTTP Sunucusu, Oracle SOA Suite veya Oracle Internet Directory gibi bir Oracle Fusion Middleware ürününün kurulu olduğu ve o ürünün binary’lerinin güncel bir prosedürde kullanıldığı yere işaret eder. Örneğin: MW_HOME/iam
  • ORACLE_COMMON_HOME: Bu değişken ve ilgili dizin yolu, Oracle Fusion Middleware Ortak Java Required Files (JRF) Kütüphanelerinin ve Oracle Fusion Middleware Enterprise Manager kütüphanelerinin kurulu olduğu yere işaret eder. Örnek: MW_HOME/oracle_common

Bende MW_HOME dizinimi bulmak için WL_HOME değişkenini kullanacağım. WL_HOME’u bulmak için çalışan bir JVM’niz varsa aşağıdaki komutu kullanarak WLS_HOME’u buluruz buradan da WL_HOME ‘u buluruz ve daha sonrasında MW_HOME’u buluruz;

ps -eaf|grep -i AdminServer| fmt |grep -i "\-Dweblogic.home" --color
-Dweblogic.home=/oracle/product/Middleware12.1.3/wlserver/server

Yukarıdaki WLS_HOME’dan anlıyorum ki benim WL_HOME’um aşağıdaki gibi (WLS_HOME ile WL_HOME aynı şeyler değildir, WL_HOME dizini WLS_HOME dizininin bir altındaki dizindir);

-Dweblogic.home=/oracle/product/Middleware12.1.3/wlserver

WL_HOME danda MW_HOME dizinini buluyorum;

 -Dweblogic.home=/oracle/product/Middleware12.1.3 

Eğer çalışan bir JVM’niz yoksa ikinci bir yöntem ise weblogic.jar dosyasını aratarak MW_HOME dizinini bulabiliriz.

find /oracle -name "weblogic.jar"| sed 's/\/server\/lib\/weblogic.jar//g'
./product/Middleware12.1.3
  • Tamamdır artık $WL_HOME/oracle_common/common/bin dizinine gidip, wlst.sh dizinini çalıştırabiliriz.

(continue reading…)

 747 total views


Weblogic’de Client IP adresini Görme (X-Forwarded-For)

Internet erişimlerinde bir proxy sunucusu kullanıldığı durumlarda, hedef web sunucusu orjinal isteği yapan kullanıcıya ait gerçek IP adresini göremez. Bunun yerine proxy cihazının IP adresi hedef sisteme bağlanıyor olarak gözükecektir.

Günümüz web uygulamaları birden fazla uygulama sunucusu ve veri tabanı sistemleri üzerinde çalışır. Temel anlamda tamamiyle aynı kaynak kodu paylaşan iki adet uygulama sunucusu düşünün. Kullanıcıdan gelen istekler, yük durumuna göre bu iki sunucudan herhangi birisi tarafından karşılanmak üzere hazırdır. Hangi talebin hangi uygulama sunucusuna aktarılacağının kararını, HTTP taleplerini uygulama sunucularının önünde karşılayan yük dengeleyici -load balancer- mekanizma yapar. Buda bizi, probleme sürükler. Kullanıcının gerçek IP adresi nedir ?

Proxy kelime olarak vekil sunucu anlamına gelir. Yani iki sistem arasındaki iletişimi taşımaktan sorumlu vekillerdir. Yukarıdaki resme bakıldığında da vekil(proxy) görevini load balancer’ın yüklendiği görülmektedir. Yani hem kullanıcı hemde uygulama sunucusu ile konuşan tek bir sistem mevcuttur. Ağ trafiği anlamında baktığımızda da web1 veya web2 sunucuları her zaman load balancer’ın IP adresi ile konuşmaktadır. Aynı durum kullanıcılar içinde geçerlidir pek tabi.

Proxy  sunucular  X-Forwarded-For HTTP başlığını, web isteğini yapan istemciye ait gerçek IP adresinin hedef sunucuya  iletmek için kullanmaktadırlar. Bu başlık RFC’lerde geçen bir standart olmamasına rağmen, genel kabul görmüş bir standarttır. İlk olarak Squid proxy geliştiricileri  tarafından  implemente  edilen  bu  başlık,  diğer  bir  çok  proxy  cihazında  da kullanılmaktadır. X-Forwarded-For HTTP başlığından kısaca XFF olarak da bahsedilmektedir.Bazı  cache  ve  proxy  cihazları  ise  X-Request-Client-IP,    X-Client-IP  HTTP  başlıklarını kullanmaktadırlar.

Yukarıdaki şekilde proxy sunucularının istemcilerin yaptığı web isteklerine “X-Forwarded-For: kullanıcının_ip_adresi” şeklinde bir satır eklemesinin detayı görülebilir. Bu sayede şekildeki proxy  sunucusu,  hedef  web  sunucusuna  bu  HTTP  isteğini  yapan  gerçek  istemciyi iletmektedir.X-Forwarded-For nerelerde kullanılır?X-Forwarded-For  (XFF)  HTTP  başlığı genelde log’lama amacıyla kullanılmaktadır. Bu şekilde siteyi ziyaret eden gerçek kullanıcının IP adresi log kayıtlarına aktarılmaya çalışılır. Bu kayıtlar, oluşan bir olay sonrası inceleme amaçlı kullanılabildiği gibi, web erişim log’larını analiz eden yazılımlar tarafından da kullanılabilir.

Weblogic Uygulama sunucularında X-Forwarded-For Enable Edilmesi

X-Forwarded-For ‘a değindikten sonra asıl amacımız olaran weblogic sunucularında gerçek client ip’yi nasıl görebiliriz ona odaklanalım;

Öncelikle bizim ortamda bulunan f5 tarafında yapmamız gereken bir takım değişiklikler var, yaptığımız bu değişiklik http header’ına X-Forwarded-For  diye yeni bir alan ekleyip bu alanın karşısınada gerçek kullanıcının ip’sini ekleyecektir. Bu konu f5’in konusu olduğu için bu konu ile ilgili detayları linkten görebilirsiniz.

Burada iki tane önemli gördüğüm konuda not düşmek istiyorum;

NOT 1 : Client X-Forwarded-For değeri manipule edebilir, mesela mozzilladaki bir plugin ile çok basit şekilde var olanın dışında bir ip’yi gönderebilir, bu tarz manipulasyonu önlemek için f5’e kural yazıp gelen X-Forwarded-For değerini en başta sildirip sonra source ip’sini X-Forwarded-For’a atayabiliriz. Kısaca aşağıdaki gibi bir kural;

when HTTP_REQUEST {
HTTP::header remove X-Forwarded-For    
HTTP::header insert X-Forwarded-For [IP::remote_addr]
}

NOT 2 : Genelde X-Forwarded-For konusunda sistemciler ve orta katmancılar ortak çalışırlar, sistemciler f5 gibi load balancer/proxy konfigurasyonunu halleder, orta katmancılar weblogic gibi uygulama sunucu kısmını halleder, işte bu noktada şöyle sıkıntılar olabiliyor; sistemciler ben sana X-Forwarded-For gönderdim sen yanlış konfigurasyon yapmışsın yada tam tersi orta katmancılar sen X-Forwarded-For göndermiyorsun yanlış konfigure yapmışsın gibisine sistemcileri suçlayabiliyor işte bunun önüne geçmek için X-Forwarded-For değerinin gelip gelmediğini tcpdump veya wireshark gibi bir araçla kontrol etmek işlerimizi kolaylaştıracaktır. Mesela aşağıda örnek bir sorgulama ve sonucu görebilirsiniz.

tcpdump -i bond1 -A -s 10240 | grep -v IP | egrep --line-buffered "..(GET |\.HTTP\/|POST |HEAD )|^[A-Za-z0-9-]+: " |sed -r 's/..(GET |HTTP\/|POST |HEAD )/\n\n\1/g'
HTTP/1.1^M
Content-Type: application/x-www-form-urlencoded^M
Cache-Control: no-cache^M
Pragma: no-cache^M
User-Agent: Java/1.8.0_141^M
Host: sbbups.dtm.gov.tr^M
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2^M
Connection: keep-alive^M
Content-Length: 166^M
Cookie: JSESSIONID=xxxxxxxxxxxxxxxxxxxxxxxxxxx;
JSESSIONID=xxxxxxxxxxxxxxxxxxxxxxxxxxx;
X-Forwarded-For: 188.149.xxx.xxx^M

Gelelim ikinci adım olan weblogic kısmında yapacaklarımıza;

  • Admin Console’a giriş yapalım (http://server:port/console)
  • “Environment > Servers > My Server > Logging > HTTP” seçerek ilerleyelim,
  • Daha sonra “Lock & Edit” seçelim,
  • “HTTP access log file enabled” checkbox’ını seçelim,
  • “Advanced” diyerek seçenekleri genişletelim,
  • Formatı “Extended” olarak seçelim
  • Daha sonra “Extended Logging Format” kutusuna “cs(X-Forwarded-For)” parametresini ekleyelim
  • Daha sonra “Log File Buffer” seçeneğini 0 olarak ayarlayalım böylece loglar direk yazılır,
  • Sonra “Save” yapalım,
  • Sonrasında “Activate Changes” i seçeriz
  • Son olarak değişiklik yaptığmız manager serverı kapatıp açarız.

NOT : Burada “Extended Logging Format” kısmından access.log’umuza yazılacak logu istediğimiz gibi güncelleyebiliriz.Yandaki linkten bütün detayları linkten görebilirsiniz. Ben ayarı aşağıdaki yapıyorum bu arada.

 

date time cs-method cs-uri sc-status cs(user-agent) c-ip time-taken bytes cs(X-Forwarded-For)

Mustafa Bektaş Tepe
İyi Çalışmalar

Referanslar;

https://psadmin.io/2016/11/24/load-balancers-and-client-ip-addresses/
https://www.mehmetince.net/yuk-dengeleyiciler-ve-gercek-ip-adresi-karmasasi/
https://docs.oracle.com/middleware/1221/wls/CNFGD/web_server.htm#CNFGD207

 1,566 total views,  12 views today


  • Sertifikasyon



  • Etiketler

  • Topluluklar

                     
                     
  • Copyright © 1996-2010 Mustafa Bektaş Tepe. All rights reserved.
    Türkçeleştirme Blogizma | AltyapıWordPress
    Takip Et

    Her yeni yazı için posta kutunuza gönderim alın.

    Diğer takipçilere katılın: