Geni\u015f Dil Modelleri (LLM’ler) hayat\u0131m\u0131za girdi\u011finden beri, bilgiye eri\u015fim ve i\u015fleme bi\u00e7imimiz k\u00f6kten de\u011fi\u015fti. Ancak LLM’lerin en b\u00fcy\u00fck zorluklar\u0131ndan biri, g\u00fcncel ve spesifik alan bilgisi eksiklikleriydi. \u0130\u015fte bu noktada Geri \u00c7a\u011f\u0131rma Art\u0131r\u0131lm\u0131\u015f \u00dcretim (Retrieval Augmented Generation – RAG) devreye giriyor. RAG, LLM’lere harici bir bilgi taban\u0131ndan relevant veriler sa\u011flayarak, onlar\u0131n daha do\u011fru ve ba\u011flama uygun yan\u0131tlar \u00fcretmesini sa\u011flayan g\u00fc\u00e7l\u00fc bir mimaridir. \u00d6nceki yaz\u0131lar\u0131m\u0131zda RAG sistemlerinin temelini ve vekt\u00f6r veritabanlar\u0131yla entegrasyonunu ele alm\u0131\u015ft\u0131k. Bu makale serisinin \u00fc\u00e7\u00fcnc\u00fc b\u00f6l\u00fcm\u00fcnde ise, RAG sistemlerinizi geli\u015ftirirken kar\u015f\u0131la\u015faca\u011f\u0131n\u0131z ba\u011f\u0131ml\u0131l\u0131k y\u00f6netimi ve da\u011f\u0131t\u0131m karma\u015f\u0131kl\u0131klar\u0131n\u0131 a\u015fman\u0131z\u0131 sa\u011flayacak kritik bir konuya odaklanaca\u011f\u0131z: Dockerizasyon ve Esnek Konfig\u00fcrasyon. Bu rehber, RAG uygulaman\u0131z\u0131 konteynerize ederek daha ta\u015f\u0131nabilir, \u00f6l\u00e7eklenebilir ve y\u00f6netilebilir hale getirmenize yard\u0131mc\u0131 olacak, b\u00f6ylece geli\u015ftirme s\u00fcrecinizi b\u00fcy\u00fck \u00f6l\u00e7\u00fcde h\u0131zland\u0131racaks\u0131n\u0131z.<\/p>\n
Bir RAG sistemi genellikle birden fazla bile\u015fenden olu\u015fur: temel uygulama mant\u0131\u011f\u0131, bir vekt\u00f6r veritaban\u0131 (Qdrant, Weaviate, Pinecone vb.), belki bir metin g\u00f6mme modeli ve hatta bir LLM’in kendisi. Bu bile\u015fenlerin her birinin farkl\u0131 ba\u011f\u0131ml\u0131l\u0131klar\u0131, \u00e7al\u0131\u015fma zaman\u0131 gereksinimleri ve yap\u0131land\u0131rma ayarlar\u0131 olabilir. Bu karma\u015f\u0131k yap\u0131y\u0131 y\u00f6netmek, genellikle geli\u015ftiriciler i\u00e7in kabusa d\u00f6n\u00fc\u015febilir. “Benim makinemde \u00e7al\u0131\u015f\u0131yordu!” sendromu, farkl\u0131 geli\u015ftirme ortamlar\u0131 veya \u00fcretim sunucular\u0131 aras\u0131nda uyumsuzluklar nedeniyle s\u0131k\u00e7a ya\u015fanan bir durumdur. Tam da bu noktada Docker, bize bir kurtar\u0131c\u0131 gibi uzan\u0131yor. Docker sayesinde, RAG uygulaman\u0131z\u0131n t\u00fcm bile\u015fenlerini ve ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131 izole edilmi\u015f, ta\u015f\u0131nabilir konteynerler i\u00e7inde paketleyebilirsiniz. Bu, geli\u015ftirme, test ve da\u011f\u0131t\u0131m s\u00fcre\u00e7lerinde tutarl\u0131l\u0131k sa\u011flayarak, “benim makinemde \u00e7al\u0131\u015f\u0131yordu” sorununu ortadan kald\u0131r\u0131r. \u00dcstelik, esnek yap\u0131land\u0131rma mekanizmalar\u0131 sayesinde, ayn\u0131 konteyner imaj\u0131n\u0131 farkl\u0131 ortamlar i\u00e7in kolayca \u00f6zelle\u015ftirebilir, hassas bilgileri g\u00fcvenli bir \u015fekilde y\u00f6netebilirsiniz. Bu sayede, RAG uygulaman\u0131z\u0131n da\u011f\u0131t\u0131m\u0131 ve bak\u0131m\u0131 \u00e7ok daha verimli hale gelirken, siz de ana i\u015finize, yani LLM’lerin potansiyelini maksimize etmeye odaklanabilirsiniz.<\/p>\n
Konteynerizasyon ve esnek yap\u0131land\u0131rma, modern yaz\u0131l\u0131m geli\u015ftirmenin temel ta\u015flar\u0131d\u0131r ve RAG gibi \u00e7ok bile\u015fenli, dinamik sistemler i\u00e7in vazge\u00e7ilmezdir. Bu b\u00f6l\u00fcmde, RAG projenizin temelini sa\u011flam bir \u015fekilde atman\u0131z i\u00e7in Docker’\u0131n neden bu kadar \u00f6nemli oldu\u011funu ve geli\u015ftirme d\u00f6ng\u00fcn\u00fcz\u00fc nas\u0131l basitle\u015ftirece\u011fini derinlemesine inceleyece\u011fiz. Ayr\u0131ca, ger\u00e7ek d\u00fcnya senaryolar\u0131nda kar\u015f\u0131la\u015fabilece\u011finiz zorluklara kar\u015f\u0131 nas\u0131l esnek \u00e7\u00f6z\u00fcmler \u00fcretebilece\u011finizi de g\u00f6sterece\u011fiz. Bu bilgiler \u0131\u015f\u0131\u011f\u0131nda, RAG uygulaman\u0131z\u0131 s\u0131f\u0131rdan olu\u015ftururken kar\u015f\u0131la\u015faca\u011f\u0131n\u0131z her ad\u0131mda daha bilin\u00e7li kararlar verebilecek ve sonu\u00e7 olarak daha sa\u011flam, daha s\u00fcrd\u00fcr\u00fclebilir bir sistem in\u015fa edebileceksiniz. K\u0131sacas\u0131, konteynerizasyon, RAG sistemlerinin karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 y\u00f6netmek, da\u011f\u0131t\u0131m s\u00fcre\u00e7lerini otomatize etmek ve \u00f6l\u00e7eklenebilirlik sa\u011flamak i\u00e7in vazge\u00e7ilmez bir ara\u00e7t\u0131r. Bu da geli\u015ftiricilerin daha verimli \u00e7al\u0131\u015fmas\u0131n\u0131 ve yenilik\u00e7i \u00e7\u00f6z\u00fcmler \u00fcretmesini kolayla\u015ft\u0131r\u0131r.<\/p>\n
RAG sistemlerinin karma\u015f\u0131kl\u0131\u011f\u0131ndan bahsettik. \u015eimdi bu karma\u015f\u0131kl\u0131\u011f\u0131 nas\u0131l y\u00f6netece\u011fimizin temeline inelim: Docker ve konteynerizasyon. Docker, uygulamalar\u0131 ve ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131 izole edilmi\u015f, hafif birimler olan “konteynerler” i\u00e7inde paketlemeyi sa\u011flayan a\u00e7\u0131k kaynakl\u0131 bir platformdur. Pek \u00e7ok ki\u015fi Docker’\u0131 bir sanal makine alternatifi san\u0131r, ancak aralar\u0131nda \u00f6nemli farklar vard\u0131r. Sanal makineler, her biri kendi i\u015fletim sistemiyle birlikte eksiksiz bir donan\u0131m sanalla\u015ft\u0131rmas\u0131 sa\u011flarken, konteynerler ana bilgisayar\u0131n i\u015fletim sisteminin \u00e7ekirde\u011fini payla\u015f\u0131r. Bu sayede konteynerler \u00e7ok daha hafif, h\u0131zl\u0131 ba\u015flar ve daha az kaynak t\u00fcketirler.<\/p>\n
Bir konteyner, uygulaman\u0131z\u0131n \u00e7al\u0131\u015fmas\u0131 i\u00e7in gereken her \u015feyi i\u00e7eren ta\u015f\u0131nabilir bir pakettir: kod, \u00e7al\u0131\u015fma zaman\u0131 (runtime), sistem ara\u00e7lar\u0131, sistem k\u00fct\u00fcphaneleri ve ayarlar. Bu paketler, “Docker \u0130majlar\u0131” olarak adland\u0131r\u0131l\u0131r. Bir imaj, bir konteyneri ba\u015flatmak i\u00e7in kullan\u0131lan pasif, \u015fablon benzeri bir yap\u0131d\u0131r. \u0130majlar bir kez olu\u015fturulduktan sonra herhangi bir Docker ortam\u0131nda tutarl\u0131 bir \u015fekilde \u00e7al\u0131\u015fabilir. Konteynerler ise bu imajlar\u0131n \u00e7al\u0131\u015fan \u00f6rnekleridir. Uygulaman\u0131z\u0131 bir konteyner i\u00e7inde \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131n\u0131zda, ana bilgisayar sistemindeki di\u011fer uygulamalardan izole edilmi\u015f olur. Bu izolasyon, ba\u011f\u0131ml\u0131l\u0131k \u00e7ak\u0131\u015fmalar\u0131n\u0131 ortadan kald\u0131r\u0131r ve uygulaman\u0131z\u0131n her yerde ayn\u0131 \u015fekilde davranmas\u0131n\u0131 garanti eder. \u00d6rne\u011fin, bir RAG uygulamas\u0131n\u0131n Python s\u00fcr\u00fcm\u00fc, bir vekt\u00f6r veritaban\u0131n\u0131n belirli bir C++ k\u00fct\u00fcphanesi veya bir LLM modelinin \u00f6zel bir CUDA s\u00fcr\u00fcc\u00fcs\u00fc gereksinimi olabilir. T\u00fcm bu farkl\u0131 gereksinimleri tek bir makine \u00fczerinde manuel olarak y\u00f6netmek b\u00fcy\u00fck bir eziyetken, her bir bile\u015feni kendi konteynerinde izole etmek bu sorunlar\u0131 k\u00f6kten \u00e7\u00f6zer.<\/p>\n
Docker’\u0131n RAG ba\u011flam\u0131ndaki faydalar\u0131 saymakla bitmez. \u00d6ncelikle, izolasyon<\/strong> sayesinde RAG uygulaman\u0131z\u0131n farkl\u0131 bile\u015fenleri (\u00f6rne\u011fin, uygulaman\u0131z ve vekt\u00f6r veritaban\u0131n\u0131z) birbirlerinin ortam\u0131n\u0131 kirletmeden veya ba\u011f\u0131ml\u0131l\u0131k \u00e7ak\u0131\u015fmas\u0131 yaratmadan ayr\u0131 ayr\u0131 \u00e7al\u0131\u015fabilir. \u0130kincisi, ta\u015f\u0131nabilirlik<\/strong>, geli\u015ftirme ortam\u0131n\u0131zda olu\u015fturdu\u011funuz ve test etti\u011finiz konteyner imaj\u0131n\u0131n, hi\u00e7bir de\u011fi\u015fiklik yapmadan test veya \u00fcretim sunucusunda da ayn\u0131 \u015fekilde \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flar. Bu, “benim makinemde \u00e7al\u0131\u015f\u0131yordu” sorununu ortadan kald\u0131r\u0131r ve geli\u015ftirme d\u00f6ng\u00fcs\u00fcn\u00fc h\u0131zland\u0131r\u0131r. \u00dc\u00e7\u00fcnc\u00fcs\u00fc, tutarl\u0131l\u0131k<\/strong>, RAG projenizdeki her geli\u015ftiricinin ayn\u0131 ortamda \u00e7al\u0131\u015fmas\u0131n\u0131 garanti eder, bu da hata ay\u0131klamay\u0131 ve i\u015fbirli\u011fini kolayla\u015ft\u0131r\u0131r. Son olarak, \u00f6l\u00e7eklenebilirlik<\/strong>, Docker Compose veya Kubernetes gibi orkestrasyon ara\u00e7lar\u0131 sayesinde RAG bile\u015fenlerinizin ihtiya\u00e7 duyuldu\u011funda kolayca \u00e7o\u011falt\u0131labilmesini ve kaynaklar\u0131n\u0131n y\u00f6netilebilmesini sa\u011flar. T\u00fcm bu avantajlar, RAG gibi \u00e7ok katmanl\u0131 ve teknoloji a\u00e7\u0131s\u0131ndan zengin projelerde Docker’\u0131 vazge\u00e7ilmez bir ara\u00e7 haline getirir. Gelin \u015fimdi, RAG uygulaman\u0131z\u0131 bir Docker imaj\u0131na d\u00f6n\u00fc\u015ft\u00fcrmenin ilk ad\u0131m\u0131 olan Dockerfile olu\u015fturma s\u00fcrecine yak\u0131ndan bakal\u0131m.<\/p>\n RAG uygulaman\u0131z\u0131 Docker ile paketlemenin ilk ad\u0131m\u0131, bir <\/code><\/p>\n Bu <\/code><\/p>\n Ba\u011f\u0131ml\u0131l\u0131klar y\u00fcklendikten sonra, Bu <\/code><\/p>\n Burada <\/code><\/p>\n Tek bir konteyneri \u00e7al\u0131\u015ft\u0131rmak basit olsa da, ger\u00e7ek bir RAG sistemi genellikle birden fazla ba\u011f\u0131ms\u0131z servisten olu\u015fur. \u00d6rne\u011fin, ana RAG uygulaman\u0131z (FastAPI veya Flask ile yaz\u0131lm\u0131\u015f), vekt\u00f6r veritaban\u0131 (Qdrant, Weaviate, Milvus vb.) ve belki de bir LLM API'si (e\u011fer yerel bir model kullan\u0131yorsan\u0131z) gibi bile\u015fenler i\u00e7erebilir. Bu servislerin her birini manuel olarak ayr\u0131 Docker komutlar\u0131yla ba\u015flatmak karma\u015f\u0131k ve hataya a\u00e7\u0131k bir s\u00fcre\u00e7tir. \u0130\u015fte bu noktada Docker Compose, birden fazla Docker konteynerini tan\u0131mlaman\u0131z\u0131 ve tek bir komutla \u00e7al\u0131\u015ft\u0131rman\u0131z\u0131 sa\u011flayan m\u00fckemmel bir ara\u00e7t\u0131r.<\/p>\n Docker Compose, \u00e7ok konteynerli Docker uygulamalar\u0131n\u0131 tan\u0131mlamak ve \u00e7al\u0131\u015ft\u0131rmak i\u00e7in bir YAML dosyas\u0131 kullan\u0131r. Bu dosya, uygulaman\u0131z\u0131n t\u00fcm servislerini, a\u011flar\u0131n\u0131 ve birimlerini yap\u0131land\u0131r\u0131r. RAG ba\u011flam\u0131nda, bu, ana uygulaman\u0131z\u0131n konteyneri ile vekt\u00f6r veritaban\u0131 konteynerini ayn\u0131 anda ve do\u011fru s\u0131rayla ba\u015flatabilece\u011finiz anlam\u0131na gelir. Ayr\u0131ca, bu servislerin birbirleriyle nas\u0131l ileti\u015fim kuraca\u011f\u0131n\u0131 da tan\u0131mlayabilirsiniz. Docker Compose sayesinde, geli\u015ftirme ve da\u011f\u0131t\u0131m s\u00fcre\u00e7leri b\u00fcy\u00fck \u00f6l\u00e7\u00fcde basitle\u015fir ve h\u0131zlan\u0131r.<\/p>\n Haydi, bir RAG sistemi i\u00e7in \u00f6rnek bir <\/code><\/p>\n Bu Bu <\/code><\/p>\n Bir RAG uygulamas\u0131n\u0131 farkl\u0131 ortamlarda (geli\u015ftirme, test, \u00fcretim) \u00e7al\u0131\u015ft\u0131r\u0131rken, baz\u0131 ayarlar\u0131n ortama g\u00f6re de\u011fi\u015fmesi gerekir. \u00d6rne\u011fin, geli\u015ftirme ortam\u0131nda yerel bir Qdrant \u00f6rne\u011fine ba\u011flan\u0131rken, \u00fcretimde bulut tabanl\u0131 bir Qdrant servisine veya farkl\u0131 bir LLM API anahtar\u0131na ihtiyac\u0131n\u0131z olabilir. Kodunuzun i\u00e7ine bu t\u00fcr de\u011ferleri \"sabit kodlamak\" (hardcoding) kesinlikle k\u00f6t\u00fc bir uygulamad\u0131r, \u00e7\u00fcnk\u00fc her ortam de\u011fi\u015fikli\u011finde kodu de\u011fi\u015ftirmek ve yeniden derlemek zorunda kal\u0131rs\u0131n\u0131z. Ayr\u0131ca, hassas bilgiler (API anahtarlar\u0131, veritaban\u0131 \u015fifreleri) kaynak kontrol sistemlerinde (Git gibi) saklanmamal\u0131d\u0131r.<\/p>\n Esnek yap\u0131land\u0131rma stratejileri, bu sorunlar\u0131 \u00e7\u00f6zmek i\u00e7in devreye girer. En yayg\u0131n ve etkili y\u00f6ntemlerden biri, ortam de\u011fi\u015fkenlerini kullanmakt\u0131r. Ortam de\u011fi\u015fkenleri, bir uygulaman\u0131n \u00e7al\u0131\u015ft\u0131\u011f\u0131 ortam taraf\u0131ndan sa\u011flanan dinamik anahtar-de\u011fer \u00e7iftleridir. Docker ve Docker Compose, ortam de\u011fi\u015fkenlerini y\u00f6netmek i\u00e7in yerle\u015fik destek sunar. \u00d6rne\u011fin, Hassas bilgileri y\u00f6netmenin daha temiz bir yolu ise <\/code><\/p>\n Daha sonra <\/code><\/p>\n Bu yakla\u015f\u0131m, RAG uygulaman\u0131z\u0131n yap\u0131land\u0131rmas\u0131n\u0131 koddan ay\u0131r\u0131r ve uygulaman\u0131n farkl\u0131 ortamlarda sorunsuz bir \u015fekilde \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flar. Ayr\u0131ca, Docker'\u0131n <\/code><\/p>\n Bu y\u00f6ntem, RAG sisteminizin esnekli\u011fini art\u0131r\u0131rken ayn\u0131 zamanda g\u00fcvenlik ve s\u00fcrd\u00fcr\u00fclebilirlik a\u00e7\u0131s\u0131ndan da \u00f6nemli avantajlar sa\u011flar. B\u00f6ylece, uygulaman\u0131z\u0131n \u00e7ekirdek mant\u0131\u011f\u0131n\u0131 de\u011fi\u015ftirmeden, sadece yap\u0131land\u0131rma dosyalar\u0131n\u0131 g\u00fcncelleyerek farkl\u0131 da\u011f\u0131t\u0131m senaryolar\u0131na uyum sa\u011flayabilirsiniz. Bu, \u00f6zellikle b\u00fcy\u00fck \u00f6l\u00e7ekli ve dinamik RAG projelerinde, birden fazla ekip \u00fcyesinin ayn\u0131 kodu farkl\u0131 ayarlarla kullanmas\u0131 gerekti\u011finde hayati bir rol oynar. Ortam de\u011fi\u015fkenlerinin do\u011fru kullan\u0131m\u0131, RAG uygulaman\u0131z\u0131n gelece\u011fe y\u00f6nelik olarak daha sa\u011flam ve uyarlanabilir olmas\u0131n\u0131 garantiler.<\/p>\n \u015eimdiye kadar temel RAG uygulamas\u0131n\u0131 Docker ile nas\u0131l paketleyece\u011fimizi ve Docker Compose ile nas\u0131l birden fazla servisi y\u00f6netece\u011fimizi g\u00f6rd\u00fck. Peki ya ger\u00e7ek d\u00fcnyada, y\u00fcksek trafikli bir web sitesi veya kurumsal bir arama motoru i\u00e7in \u00f6l\u00e7eklenebilir bir RAG sistemi kurmam\u0131z gerekirse ne yapaca\u011f\u0131z? Bir e-ticaret platformunun \u00fcr\u00fcn a\u00e7\u0131klamalar\u0131, s\u0131k\u00e7a sorulan sorular veya m\u00fc\u015fteri yorumlar\u0131 \u00fczerinden an\u0131nda do\u011fru bilgi sa\u011flayan bir RAG botu olu\u015fturmak istedi\u011fini varsayal\u0131m. Bu senaryo, tek bir basit konteynerin \u00f6tesine ge\u00e7er ve daha sofistike bir mimari gerektirir.<\/p>\n \u00d6ncelikle, e-ticaret sitesindeki \u00fcr\u00fcn say\u0131s\u0131 \u00e7ok fazla olaca\u011f\u0131ndan, tek bir vekt\u00f6r veritaban\u0131 veya tek bir RAG servisi yeterli olmayabilir. Bu durumda, vekt\u00f6r veritaban\u0131n\u0131 ve RAG uygulamas\u0131n\u0131 yatay olarak \u00f6l\u00e7eklendirmemiz gerekir. Yani, birden fazla Qdrant veya Weaviate \u00f6rne\u011fi ve birden fazla Senaryomuzda, RAG botumuzun hem \u00fcr\u00fcn a\u00e7\u0131klamalar\u0131ndan hem de m\u00fc\u015fteri yorumlar\u0131ndan bilgi \u00e7ekmesi gerekti\u011fini d\u00fc\u015f\u00fcnelim. Bu, farkl\u0131 veri kaynaklar\u0131 i\u00e7in ayr\u0131 vekt\u00f6r koleksiyonlar\u0131 veya hatta ayr\u0131 vekt\u00f6r veritabanlar\u0131 anlam\u0131na gelebilir. Mimarimizi basitle\u015ftirmek ad\u0131na, bir ana <\/code><\/p>\n Bu senaryoda, Ek olarak, RAG uygulaman\u0131z\u0131n kullan\u0131c\u0131 aray\u00fcz\u00fc mobil cihazlardan da eri\u015filebilir olmal\u0131. Konteynerizasyon do\u011frudan UI ile ilgili olmasa da, da\u011f\u0131tt\u0131\u011f\u0131n\u0131z backend servislerinin herhangi bir istemci (mobil, web) taraf\u0131ndan kullan\u0131labilir olmas\u0131 \u00f6nemlidir. Modern web aray\u00fczleri, CSS Media Query'leri kullanarak farkl\u0131 ekran boyutlar\u0131na uyum sa\u011flar. \u00d6rne\u011fin, bir RAG botu sohbet aray\u00fcz\u00fcn\u00fcz i\u00e7in:<\/p>\n <\/code><\/p>\n Bu RAG sistemlerinizi Docker ile konteynerize etmek ve Docker Compose ile \u00e7ok servisli mimarileri y\u00f6netmek, geli\u015ftirme ve da\u011f\u0131t\u0131m s\u00fcre\u00e7lerinizi b\u00fcy\u00fck \u00f6l\u00e7\u00fcde iyile\u015ftirir. Ancak sa\u011flam, g\u00fcvenli ve performansl\u0131 bir RAG sistemi olu\u015fturmak i\u00e7in baz\u0131 ileri d\u00fczey ipu\u00e7lar\u0131 ve en iyi uygulamalar\u0131 g\u00f6z \u00f6n\u00fcnde bulundurmak \u00f6nemlidir. Bu k\u0131s\u0131m, projenizin olgunlu\u011funu art\u0131racak ve sizi olas\u0131 tuzaklardan koruyacakt\u0131r.<\/p>\n Daha \u00f6nce ortam de\u011fi\u015fkenleri ve <\/code><\/p>\n Ard\u0131ndan, Docker imajlar\u0131n\u0131z\u0131n boyutu ve olu\u015fturulma s\u00fcresi, CI\/CD s\u00fcre\u00e7lerinizi ve da\u011f\u0131t\u0131m h\u0131z\u0131n\u0131z\u0131 do\u011frudan etkiler. \u0130majlar\u0131 optimize etmek i\u00e7in \u015fu y\u00f6ntemleri kullanabilirsiniz:<\/p>\n RAG sisteminiz \u00e7al\u0131\u015f\u0131r durumdayken, performans\u0131n\u0131 izlemek ve sorunlar\u0131 gidermek i\u00e7in loglara ve metrik verilere ihtiyac\u0131n\u0131z olacakt\u0131r. Docker, konteyner loglar\u0131n\u0131 stdout\/stderr'e yazmay\u0131 te\u015fvik eder. Docker Compose veya Kubernetes ile bu loglar\u0131 merkezi bir loglama sistemine (Elastic Stack (ELK), Grafana Loki) y\u00f6nlendirebilirsiniz. Metrikler i\u00e7in Prometheus ve Grafana ikilisi harika bir \u00e7\u00f6z\u00fcmd\u00fcr. RAG uygulaman\u0131zdaki her bir bile\u015fenin (vekt\u00f6r veritaban\u0131 sorgu s\u00fcreleri, LLM \u00e7a\u011fr\u0131 s\u00fcreleri, token kullan\u0131m\u0131) metriklerini toplamak, darbo\u011fazlar\u0131 tespit etmenize ve performans\u0131 optimize etmenize yard\u0131mc\u0131 olur.<\/p>\n S\u00fcrekli Entegrasyon\/S\u00fcrekli Da\u011f\u0131t\u0131m (CI\/CD) hatt\u0131 kurmak, RAG uygulaman\u0131z\u0131n konteynerizasyonunun tam potansiyelini a\u00e7\u0131\u011fa \u00e7\u0131kar\u0131r. Kod de\u011fi\u015fiklikleri yap\u0131ld\u0131\u011f\u0131nda otomatik testleri \u00e7al\u0131\u015ft\u0131ran, Docker imajlar\u0131n\u0131 olu\u015fturan ve bunlar\u0131 bir konteyner kay\u0131t defterine (Docker Hub, Google Container Registry) iten bir CI\/CD hatt\u0131 kurun. Ard\u0131ndan, yeni imajlar haz\u0131r oldu\u011funda uygulamay\u0131 otomatik olarak da\u011f\u0131tan bir CD s\u00fcreci ekleyin. Bu, RAG sisteminizin daha h\u0131zl\u0131, daha g\u00fcvenilir ve daha s\u0131k g\u00fcncellenmesini sa\u011flar. GitHub Actions, GitLab CI\/CD veya Jenkins gibi ara\u00e7lar bu s\u00fcre\u00e7leri otomatikle\u015ftirmek i\u00e7in kullan\u0131labilir.<\/p>\n Bu ileri d\u00fczey ipu\u00e7lar\u0131 ve en iyi uygulamalar, RAG projenizin sadece \u00e7al\u0131\u015f\u0131r durumda olmas\u0131n\u0131 de\u011fil, ayn\u0131 zamanda \u00fcretim ortam\u0131nda da g\u00fcvenilir, \u00f6l\u00e7eklenebilir ve y\u00f6netilebilir olmas\u0131n\u0131 sa\u011flar. G\u00fcvenlikten performansa, izlenebilirlikten otomasyona kadar her alanda ataca\u011f\u0131n\u0131z ad\u0131mlar, RAG sisteminizin uzun vadeli ba\u015far\u0131s\u0131 i\u00e7in kritik \u00f6neme sahiptir.<\/p>\n Bu makale serisinin \u00fc\u00e7\u00fcnc\u00fc b\u00f6l\u00fcm\u00fcnde, RAG sistemlerinin konteynerizasyonu ve esnek yap\u0131land\u0131rmas\u0131n\u0131n neden bu kadar \u00f6nemli oldu\u011funu detayl\u0131 bir \u015fekilde inceledik. Dockerfile ile tek bir uygulaman\u0131n nas\u0131l konteynerize edilece\u011fini, ard\u0131ndan Docker Compose ile birden fazla servisi (uygulama ve vekt\u00f6r veritaban\u0131 gibi) i\u00e7eren karma\u015f\u0131k RAG mimarilerinin nas\u0131l kolayca y\u00f6netilece\u011fini \u00f6\u011frendik. Ayr\u0131ca, ortam de\u011fi\u015fkenleri ve Hay\u0131r, genellikle Docker kullanmak RAG performans\u0131n\u0131 kayda de\u011fer \u00f6l\u00e7\u00fcde d\u00fc\u015f\u00fcrmez. Konteynerler, sanal makinelere g\u00f6re \u00e7ok daha hafif ve ana bilgisayar\u0131n \u00e7ekirde\u011fini payla\u015ft\u0131\u011f\u0131 i\u00e7in performans overhead'i minimaldir. Hatta, ba\u011f\u0131ml\u0131l\u0131k \u00e7ak\u0131\u015fmalar\u0131n\u0131 \u00f6nleyerek ve tutarl\u0131 bir ortam sa\u011flayarak geli\u015ftirme ve \u00fcretim ortamlar\u0131ndaki performans tutarl\u0131l\u0131\u011f\u0131n\u0131 art\u0131rabilir. Ancak, yanl\u0131\u015f yap\u0131land\u0131r\u0131lm\u0131\u015f bir Dockerfile veya konteyner ayarlar\u0131 (\u00f6rne\u011fin yetersiz kaynak atamas\u0131) performans\u0131 etkileyebilir. Do\u011fru optimizasyonlarla performans kayg\u0131s\u0131 ya\u015fanmaz.<\/p>\n<\/li>\n Piyasada bulunan pop\u00fcler vekt\u00f6r veritabanlar\u0131n\u0131n \u00e7o\u011fu Docker imaj\u0131 olarak mevcuttur ve Docker ile kolayca kullan\u0131labilir. \u00d6rne\u011fin, Qdrant, Weaviate, Milvus, ChromaDB gibi veritabanlar\u0131n\u0131n hepsi Docker Hub'da resmi imajlara sahiptir. Bu sayede, Evet, genellikle ayn\u0131 Docker Compose, tek bir ana bilgisayar \u00fczerinde birden fazla konteyneri y\u00f6netmek i\u00e7in harikad\u0131r. Geli\u015ftirme, test ve k\u00fc\u00e7\u00fck \u00f6l\u00e7ekli \u00fcretim da\u011f\u0131t\u0131mlar\u0131 i\u00e7in yeterli olabilir. Ancak, uygulaman\u0131z y\u00fcksek kullan\u0131labilirlik, otomatik \u00f6l\u00e7eklenebilirlik, geli\u015fmi\u015f a\u011f yetenekleri, karma\u015f\u0131k da\u011f\u0131t\u0131m stratejileri (rolling updates, blue\/green deployment) veya birden fazla sunucu (k\u00fcme) \u00fczerinde da\u011f\u0131t\u0131m gerektiriyorsa, Kubernetes gibi daha geli\u015fmi\u015f bir konteyner orkestrasyon platformuna ge\u00e7melisiniz. Kubernetes, \u00f6zellikle mikroservis tabanl\u0131 RAG mimarileri ve b\u00fcy\u00fck \u00f6l\u00e7ekli, dinamik i\u015f y\u00fckleri i\u00e7in tasarlanm\u0131\u015ft\u0131r.<\/p>\n<\/li>\n<\/ol>\n <\/body><\/p>\n","protected":false},"excerpt":{"rendered":"Geni\u015f Dil Modelleri (LLM’ler) hayat\u0131m\u0131za girdi\u011finden beri, bilgiye eri\u015fim ve i\u015fleme bi\u00e7imimiz k\u00f6kten de\u011fi\u015fti. Ancak LLM’lerin en b\u00fcy\u00fck…","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1407],"tags":[],"class_list":{"0":"post-31430","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-docker","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\nDockerfile Olu\u015fturma: RAG Uygulaman\u0131z\u0131 Konteynerize Etmenin \u0130lk Ad\u0131m\u0131<\/h3>\n
Dockerfile<\/code> olu\u015fturmakt\u0131r. Dockerfile<\/code>, Docker’\u0131n bir imaj\u0131 nas\u0131l olu\u015fturaca\u011f\u0131n\u0131 ad\u0131m ad\u0131m anlatan metin tabanl\u0131 bir betiktir. Her talimat, imajda yeni bir katman olu\u015fturur ve bu katmanlar, imaj\u0131n boyutunu ve olu\u015fturulma h\u0131z\u0131n\u0131 etkileyebilir. \u0130\u015fte basit bir RAG uygulamas\u0131 i\u00e7in \u00f6rnek bir Dockerfile<\/code>:<\/p>\n# RAG uygulaman\u0131z i\u00e7in temel Python imaj\u0131n\u0131 kullan\u0131n\nFROM python:3.9-slim-buster\n\n# \u00c7al\u0131\u015fma dizini olu\u015ftur ve i\u00e7ine gir\nWORKDIR \/app\n\n# Python ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131 kopyala ve y\u00fckle\n# Bu ad\u0131m, s\u0131k de\u011fi\u015fmeyen ba\u011f\u0131ml\u0131l\u0131klar\u0131n \u00f6nbelle\u011fe al\u0131nmas\u0131n\u0131 sa\u011flar\nCOPY requirements.txt .\nRUN pip install --no-cache-dir -r requirements.txt\n\n# Uygulama kodunu kopyala\nCOPY . .\n\n# Uygulaman\u0131n \u00e7al\u0131\u015ft\u0131\u011f\u0131 portu belirt (iste\u011fe ba\u011fl\u0131, sadece bilgilendirme ama\u00e7l\u0131)\nEXPOSE 8000\n\n# Uygulamay\u0131 \u00e7al\u0131\u015ft\u0131racak komut\n# Gunicorn gibi bir WSGI sunucusu ile Flask\/FastAPI uygulamas\u0131n\u0131 ba\u015flatabiliriz\nCMD [\"python\", \"app.py\"]\n<\/pre>\nDockerfile<\/code>'\u0131 ad\u0131m ad\u0131m inceleyelim: FROM python:3.9-slim-buster<\/code> komutu, imaj\u0131m\u0131z i\u00e7in temel bir Python ortam\u0131 sa\u011flar. WORKDIR \/app<\/code> ile konteyner i\u00e7inde \u00e7al\u0131\u015faca\u011f\u0131m\u0131z dizini belirliyoruz. En kritik ad\u0131mlardan biri, requirements.txt<\/code> dosyas\u0131n\u0131 kopyalay\u0131p gerekli Python k\u00fct\u00fcphanelerini y\u00fcklemektir. Bu, uygulaman\u0131z\u0131n t\u00fcm ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131 tek bir komutla kurman\u0131z\u0131 sa\u011flar. \u00d6rne\u011fin, bir RAG uygulamas\u0131 i\u00e7in bu dosya a\u015fa\u011f\u0131daki gibi olabilir:<\/p>\n# requirements.txt\nfastapi\nuvicorn\nnumpy\nscipy\ntransformers\nsentence-transformers\nqdrant-client # Vekt\u00f6r veritaban\u0131 istemcisi\nopenai # LLM API eri\u015fimi i\u00e7in\npython-dotenv # Ortam de\u011fi\u015fkenleri i\u00e7in\n<\/pre>\nCOPY . .<\/code> komutu ile projenizin geri kalan kodunu konteynere kopyal\u0131yoruz. EXPOSE 8000<\/code>, uygulaman\u0131z\u0131n hangi portta dinledi\u011fini Docker'a bildirir (ancak bu, portu otomatik olarak yay\u0131mlamaz). Son olarak, CMD [\"python\", \"app.py\"]<\/code>, konteyner ba\u015flat\u0131ld\u0131\u011f\u0131nda \u00e7al\u0131\u015ft\u0131r\u0131lacak varsay\u0131lan komutu belirtir. Bu komut, uygulaman\u0131z\u0131 \u00e7al\u0131\u015f\u0131r duruma getirir.<\/p>\nDockerfile<\/code> ile imaj\u0131 olu\u015fturmak i\u00e7in, Dockerfile<\/code> ve uygulama kodunuzun bulundu\u011fu dizinde \u015fu komutu \u00e7al\u0131\u015ft\u0131r\u0131n:<\/p>\ndocker build -t my-rag-app:latest .\n<\/pre>\n-t my-rag-app:latest<\/code>, imaj\u0131m\u0131za bir etiket (tag) vermemizi sa\u011flar. .<\/code> ise Dockerfile<\/code>'\u0131n mevcut dizinde oldu\u011funu belirtir. \u0130maj ba\u015far\u0131yla olu\u015fturulduktan sonra, uygulaman\u0131z\u0131 bir konteyner i\u00e7inde \u00e7al\u0131\u015ft\u0131rmak i\u00e7in \u015fu komutu kullanabilirsiniz:<\/p>\ndocker run -p 8000:8000 my-rag-app:latest\n<\/pre>\n-p 8000:8000<\/code> komutu, ana bilgisayar\u0131n\u0131z\u0131n 8000 portunu konteynerin 8000 portuna e\u015fler, b\u00f6ylece uygulaman\u0131za d\u0131\u015far\u0131dan eri\u015filebilir. Art\u0131k RAG uygulaman\u0131z bir Docker konteynerinde izole ve ta\u015f\u0131nabilir bir \u015fekilde \u00e7al\u0131\u015f\u0131yor! Ancak bir RAG sistemi genellikle birden fazla servis i\u00e7erir. \u0130\u015fte bu noktada Docker Compose devreye giriyor.<\/p>\nDocker Compose ile \u00c7ok Servisli RAG Mimarisi: Orkestrasyonun G\u00fcc\u00fc<\/h2>\n
docker-compose.yml<\/code> dosyas\u0131 olu\u015ftural\u0131m. Bu \u00f6rnekte, bir Python RAG uygulamas\u0131n\u0131 ve Qdrant vekt\u00f6r veritaban\u0131n\u0131 kullanaca\u011f\u0131z:<\/p>\n# docker-compose.yml\nversion: '3.8'\n\nservices:\n rag_app:\n build: .\n ports:\n - \"8000:8000\"\n environment:\n QDRANT_HOST: qdrant\n QDRANT_PORT: 6333\n OPENAI_API_KEY: ${OPENAI_API_KEY} # Ortam de\u011fi\u015fkeni olarak \u00e7ekilecek\n depends_on:\n - qdrant\n volumes:\n - .\/app:\/app # Geli\u015ftirme s\u0131ras\u0131nda kod de\u011fi\u015fikliklerinin an\u0131nda yans\u0131mas\u0131 i\u00e7in\n\n qdrant:\n image: qdrant\/qdrant:latest\n ports:\n - \"6333:6333\" # Qdrant API portu\n - \"6334:6334\" # Qdrant gRPC portu\n volumes:\n - qdrant_data:\/qdrant\/data # Qdrant verilerini kal\u0131c\u0131 hale getirmek i\u00e7in\n\nvolumes:\n qdrant_data:\n<\/pre>\ndocker-compose.yml<\/code> dosyas\u0131n\u0131 inceleyelim:<\/p>\n\n
version: '3.8'<\/code>: Docker Compose dosyas\u0131n\u0131n versiyonunu belirtir.<\/li>\nservices<\/code>: Uygulaman\u0131z\u0131n farkl\u0131 bile\u015fenlerini tan\u0131mlad\u0131\u011f\u0131n\u0131z b\u00f6l\u00fcmd\u00fcr.<\/li>\nrag_app<\/code>: Bizim RAG uygulamas\u0131n\u0131 i\u00e7eren servisimiz.\n\n
build: .<\/code>: Bu servisin imaj\u0131n\u0131n mevcut dizindeki Dockerfile<\/code> kullan\u0131larak olu\u015fturulaca\u011f\u0131n\u0131 belirtir.<\/li>\nports: - \"8000:8000\"<\/code>: Ana bilgisayar\u0131n 8000 portunu rag_app<\/code> konteynerinin 8000 portuna y\u00f6nlendirir.<\/li>\nenvironment<\/code>: Konteyner i\u00e7inde kullan\u0131lacak ortam de\u011fi\u015fkenlerini tan\u0131mlar. Burada QDRANT_HOST<\/code> ve QDRANT_PORT<\/code> ile Qdrant servisine nas\u0131l eri\u015filece\u011fini belirtiyoruz. ${OPENAI_API_KEY}<\/code> ise ana bilgisayar\u0131n ortam de\u011fi\u015fkenlerinden al\u0131nacak bir de\u011feri g\u00f6sterir. Bu, esnek yap\u0131land\u0131rman\u0131n temelidir.<\/li>\ndepends_on: - qdrant<\/code>: rag_app<\/code> servisinin qdrant<\/code> servisi ba\u015flamadan \u00f6nce ba\u015flat\u0131lmamas\u0131 gerekti\u011fini belirtir. Bu, servisler aras\u0131 ba\u011f\u0131ml\u0131l\u0131klar\u0131 y\u00f6netmek i\u00e7in \u00f6nemlidir.<\/li>\nvolumes: - .\/app:\/app<\/code>: Ana bilgisayardaki .\/app<\/code> dizinini konteynerdeki \/app<\/code> dizinine ba\u011flar. Bu, geli\u015ftirme s\u0131ras\u0131nda kodunuzda yapt\u0131\u011f\u0131n\u0131z de\u011fi\u015fikliklerin konteyner i\u00e7inde an\u0131nda g\u00f6r\u00fcnmesini sa\u011flar (hot-reloading).<\/li>\n<\/ul>\n<\/li>\nqdrant<\/code>: Qdrant vekt\u00f6r veritaban\u0131n\u0131 \u00e7al\u0131\u015ft\u0131ran servisimiz.\n\n
image: qdrant\/qdrant:latest<\/code>: Docker Hub'dan qdrant\/qdrant<\/code> imaj\u0131n\u0131n en son s\u00fcr\u00fcm\u00fcn\u00fc \u00e7ekece\u011fini belirtir.<\/li>\nports: - \"6333:6333\" - \"6334:6334\"<\/code>: Qdrant'\u0131n API ve gRPC portlar\u0131n\u0131 ana bilgisayara a\u00e7ar.<\/li>\nvolumes: - qdrant_data:\/qdrant\/data<\/code>: Qdrant'\u0131n verilerini kal\u0131c\u0131 olarak saklamak i\u00e7in bir Docker volume kullan\u0131r. B\u00f6ylece konteyner silinse bile verileriniz kaybolmaz.<\/li>\n<\/ul>\n<\/li>\nvolumes<\/code>: Tan\u0131mlanm\u0131\u015f Docker volume'lerini i\u00e7erir.<\/li>\n<\/ul>\ndocker-compose.yml<\/code> dosyas\u0131n\u0131 kullanarak t\u00fcm RAG sisteminizi tek bir komutla ba\u015flatabilirsiniz:<\/p>\ndocker compose up -d\n<\/pre>\n-d<\/code> bayra\u011f\u0131, konteynerleri arka planda \u00e7al\u0131\u015ft\u0131rman\u0131z\u0131 sa\u011flar. Bu sayede terminalinizi serbest b\u0131rakabilirsiniz. Sisteminiz art\u0131k \u00e7al\u0131\u015f\u0131r durumda! Bu yakla\u015f\u0131m, sadece geli\u015ftirme s\u0131ras\u0131nda de\u011fil, test ve \u00fcretim ortamlar\u0131nda da RAG sisteminizi da\u011f\u0131tmak ve y\u00f6netmek i\u00e7in olduk\u00e7a etkilidir. Servislerin birbiriyle nas\u0131l konu\u015faca\u011f\u0131, portlar\u0131n nas\u0131l e\u015flenece\u011fi ve verilerin nas\u0131l saklanaca\u011f\u0131 gibi t\u00fcm karma\u015f\u0131k detaylar\u0131 tek bir dosyada merkezile\u015ftirmi\u015f olursunuz. Bu sayede, RAG projenizin her bir bile\u015fenini ayr\u0131 ayr\u0131 y\u00f6netme zahmetinden kurtulursunuz, bu da \u00f6zellikle b\u00fcy\u00fck ve da\u011f\u0131t\u0131k sistemlerde \u00f6nemli bir kolayl\u0131k sa\u011flar. Art\u0131k uygulaman\u0131z\u0131n hangi par\u00e7alar\u0131n\u0131n hangi ortamda \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 d\u00fc\u015f\u00fcnmenize gerek kalmaz, \u00e7\u00fcnk\u00fc Docker Compose her \u015feyi sizin i\u00e7in halleder.<\/p>\nEsnek Yap\u0131land\u0131rma Stratejileri: Ortam De\u011fi\u015fkenleri ve YAML Dosyalar\u0131<\/h3>\n
docker-compose.yml<\/code> dosyam\u0131zda OPENAI_API_KEY: ${OPENAI_API_KEY}<\/code> ifadesini kulland\u0131k. Bu, Docker Compose'un, bu de\u011feri kendisini \u00e7al\u0131\u015ft\u0131ran kabu\u011fun ortam\u0131ndan alaca\u011f\u0131 anlam\u0131na gelir. Yani, terminalinizde export OPENAI_API_KEY=\"sk-...\"<\/code> komutunu \u00e7al\u0131\u015ft\u0131r\u0131p sonra docker compose up<\/code> derseniz, bu anahtar rag_app<\/code> konteynerine iletilecektir.<\/p>\n.env<\/code> dosyalar\u0131 kullanmakt\u0131r. .env<\/code> dosyalar\u0131, ortam de\u011fi\u015fkenlerini anahtar-de\u011fer \u00e7iftleri halinde saklayan d\u00fcz metin dosyalar\u0131d\u0131r. Docker Compose, ayn\u0131 dizinde bulunan .env<\/code> dosyas\u0131n\u0131 otomatik olarak okur ve burada tan\u0131mlanan de\u011fi\u015fkenleri servislerinize iletir. Bu dosyay\u0131 .gitignore<\/code> dosyas\u0131na ekleyerek hassas bilgilerin yanl\u0131\u015fl\u0131kla kaynak kontrol\u00fcne g\u00f6nderilmesini engelleyebilirsiniz. \u00d6rnek bir .env<\/code> dosyas\u0131 \u015f\u00f6yle olabilir:<\/p>\n# .env\nOPENAI_API_KEY=\"sk-your-super-secret-key-here\"\nQDRANT_HOST_PROD=\"your.production.qdrant.cloud\"\nQDRANT_PORT_PROD=6333\n<\/pre>\ndocker-compose.yml<\/code> dosyan\u0131zda bu de\u011fi\u015fkenleri do\u011frudan kullanabilirsiniz:<\/p>\n# ...\nservices:\n rag_app:\n # ...\n environment:\n QDRANT_HOST: ${QDRANT_HOST_PROD}\n QDRANT_PORT: ${QDRANT_PORT_PROD}\n OPENAI_API_KEY: ${OPENAI_API_KEY}\n # ...\n<\/pre>\n--env-file<\/code> bayra\u011f\u0131n\u0131 kullanarak da belirli bir .env<\/code> dosyas\u0131n\u0131 g\u00f6sterebilirsiniz. Bu, farkl\u0131 ortamlar i\u00e7in (\u00f6rne\u011fin .env.dev<\/code>, .env.prod<\/code>) farkl\u0131 yap\u0131land\u0131rma dosyalar\u0131 tutman\u0131za olanak tan\u0131r. Uygulaman\u0131z\u0131n i\u00e7inde ise, Python'da os.getenv()<\/code> fonksiyonu veya python-dotenv<\/code> gibi k\u00fct\u00fcphanelerle bu ortam de\u011fi\u015fkenlerine kolayca eri\u015febilirsiniz.<\/p>\n# app.py veya config.py i\u00e7inde\nimport os\nfrom dotenv import load_dotenv\n\nload_dotenv() # .env dosyas\u0131n\u0131 y\u00fckler (sadece geli\u015ftirme ortam\u0131nda gerekli olabilir)\n\nQDRANT_HOST = os.getenv(\"QDRANT_HOST\", \"localhost\") # Varsay\u0131lan de\u011fer \"localhost\"\nQDRANT_PORT = int(os.getenv(\"QDRANT_PORT\", \"6333\"))\nOPENAI_API_KEY = os.getenv(\"OPENAI_API_KEY\")\n\nif not OPENAI_API_KEY:\n raise ValueError(\"OPENAI_API_KEY ortam de\u011fi\u015fkeni ayarlanmad\u0131.\")\n\nprint(f\"Qdrant'a ba\u011flan\u0131l\u0131yor: {QDRANT_HOST}:{QDRANT_PORT}\")\n<\/pre>\nGer\u00e7ek D\u00fcnya Senaryosu: \u00d6l\u00e7eklenebilir Bir RAG Sistemi Nas\u0131l Tasarlan\u0131r?<\/h2>\n
rag_app<\/code> servisi \u00e7al\u0131\u015ft\u0131rmal\u0131y\u0131z. Docker Compose, geli\u015ftirme ve k\u00fc\u00e7\u00fck \u00f6l\u00e7ekli da\u011f\u0131t\u0131mlar i\u00e7in harika olsa da, b\u00fcy\u00fck \u00f6l\u00e7ekli ve dinamik ortamlar i\u00e7in Kubernetes gibi daha geli\u015fmi\u015f bir konteyner orkestrasyon arac\u0131na ihtiya\u00e7 duyabiliriz. Kubernetes, konteynerle\u015ftirilmi\u015f uygulamalar\u0131 otomatik olarak da\u011f\u0131tmak, \u00f6l\u00e7eklendirmek ve y\u00f6netmek i\u00e7in tasarlanm\u0131\u015ft\u0131r. Ancak Docker Compose ile de temel bir \u00f6l\u00e7eklenebilir mimariyi sim\u00fcle edebiliriz.<\/p>\nrag_orchestrator<\/code> servisi ve birden fazla rag_worker<\/code> servisi ile bir qdrant_prod<\/code> cluster'\u0131 hayal edelim. Kullan\u0131c\u0131 istekleri bir y\u00fck dengeleyici (load balancer) arac\u0131l\u0131\u011f\u0131yla rag_orchestrator<\/code>'a gelir, o da iste\u011fi uygun rag_worker<\/code>'a y\u00f6nlendirir veya da\u011f\u0131t\u0131r.<\/p>\n# Ger\u00e7ek d\u00fcnya senaryosu i\u00e7in docker-compose.yml (Basitle\u015ftirilmi\u015f)\nversion: '3.8'\n\nservices:\n rag_orchestrator:\n build:\n context: .\/orchestrator_app\n dockerfile: Dockerfile\n ports:\n - \"80:80\" # Y\u00fck dengeleyici g\u00f6revi g\u00f6recek\n environment:\n WORKER_COUNT: 3\n QDRANT_HOST: qdrant-cluster\n depends_on:\n - qdrant-cluster\n - rag_worker_1 # \u00d6rnek workers\n - rag_worker_2\n - rag_worker_3\n\n rag_worker_1:\n build:\n context: .\/worker_app\n dockerfile: Dockerfile\n environment:\n QDRANT_HOST: qdrant-cluster\n volumes:\n - .\/worker_app:\/app # Geli\u015ftirme i\u00e7in\n\n rag_worker_2:\n extends:\n service: rag_worker_1\n file: docker-compose.yml # Ayn\u0131 worker imaj\u0131n\u0131 kullan\u0131yoruz\n\n rag_worker_3:\n extends:\n service: rag_worker_1\n file: docker-compose.yml # Ayn\u0131 worker imaj\u0131n\u0131 kullan\u0131yoruz\n\n qdrant-cluster:\n image: qdrant\/qdrant:latest\n ports:\n - \"6333:6333\"\n environment:\n QDRANT__STORAGE__LOCATION: \/qdrant\/data # Data path\n volumes:\n - qdrant_data:\/qdrant\/data # Kal\u0131c\u0131 veri saklama\n\nvolumes:\n qdrant_data:\n<\/pre>\nrag_orchestrator<\/code> gelen t\u00fcm istekleri y\u00f6netir ve rag_worker<\/code>'lardan birine y\u00f6nlendirir. rag_worker<\/code>'lar, ger\u00e7ek RAG i\u015f y\u00fck\u00fcn\u00fc (belge geri \u00e7a\u011f\u0131rma ve LLM ile cevap \u00fcretme) \u00fcstlenir. Qdrant cluster'\u0131 ise t\u00fcm vekt\u00f6r verilerini saklar. extends<\/code> anahtar kelimesi, ayn\u0131 servis yap\u0131land\u0131rmas\u0131n\u0131 tekrar tekrar yazmadan birden fazla \u00f6rnek olu\u015fturmam\u0131za olanak tan\u0131r. Bu sayede, RAG i\u015f y\u00fck\u00fcn\u00fc da\u011f\u0131tarak sistemin performans\u0131n\u0131 ve kullan\u0131labilirli\u011fini art\u0131r\u0131r\u0131z. Daha ileri seviye senaryolarda, bu orkestrasyonu bir mesaj kuyru\u011fu (\u00f6rne\u011fin RabbitMQ veya Kafka) kullanarak daha sa\u011flam hale getirebilir, istekleri asenkron olarak i\u015fleyebiliriz. Bu, sistemin yo\u011fun y\u00fck alt\u0131nda bile stabil kalmas\u0131n\u0131 sa\u011flar.<\/p>\n\/* styles.css *\/\n.chat-container {\n width: 80%;\n margin: 20px auto;\n max-width: 900px;\n background-color: #f9f9f9;\n padding: 20px;\n border-radius: 8px;\n box-shadow: 0 4px 8px rgba(0,0,0,0.1);\n}\n\n@media (max-width: 768px) {\n .chat-container {\n width: 95%; \/* K\u00fc\u00e7\u00fck ekranlarda daha geni\u015f *\/\n margin: 10px auto;\n padding: 15px;\n }\n .chat-input {\n flex-direction: column; \/* Mobil klavye i\u00e7in daha iyi *\/\n }\n}\n<\/pre>\n@media<\/code> sorgusu, 768px'den daha k\u00fc\u00e7\u00fck ekranlarda .chat-container<\/code> stilini otomatik olarak ayarlar. Bu, RAG sisteminizin backend'i ne kadar g\u00fc\u00e7l\u00fc olursa olsun, kullan\u0131c\u0131lar\u0131n ona nas\u0131l eri\u015fti\u011finin de \u00f6nemli oldu\u011funu g\u00f6sterir. \u00d6l\u00e7eklenebilirlik, sadece backend performans\u0131 de\u011fil, ayn\u0131 zamanda kullan\u0131c\u0131 deneyimi a\u00e7\u0131s\u0131ndan da d\u00fc\u015f\u00fcn\u00fclmelidir. B\u00f6yle bir mimari, RAG uygulaman\u0131z\u0131n sadece \u00e7al\u0131\u015fmas\u0131n\u0131 de\u011fil, ayn\u0131 zamanda b\u00fcy\u00fcyen talepleri kar\u015f\u0131layabilecek dayan\u0131kl\u0131l\u0131k ve esnekli\u011fe sahip olmas\u0131n\u0131 da sa\u011flar.<\/p>\n\u0130leri D\u00fczey \u0130pu\u00e7lar\u0131 ve En \u0130yi Uygulamalar: Daha Sa\u011flam RAG Sistemleri \u0130\u00e7in<\/h2>\n
G\u00fcvenlik: Hassas Bilgilerin G\u00fcvenli Y\u00f6netimi<\/h3>\n
.env<\/code> dosyalar\u0131 kullanarak yap\u0131land\u0131rma esnekli\u011fini tart\u0131\u015ft\u0131k. Ancak hassas bilgiler (API anahtarlar\u0131, veritaban\u0131 \u015fifreleri) s\u00f6z konusu oldu\u011funda, \u00f6zellikle \u00fcretim ortamlar\u0131nda daha g\u00fcvenli y\u00f6ntemlere ihtiya\u00e7 duyar\u0131z. Docker Swarm ve Kubernetes gibi orkestrasyon ara\u00e7lar\u0131, \"Secrets\" ad\u0131 verilen mekanizmalar sunar. Docker Secrets, hassas verileri \u015fifreli bir \u015fekilde saklar ve sadece yetkili konteynerler taraf\u0131ndan eri\u015filmesini sa\u011flar. Bu, verilerinizin depoda veya loglarda g\u00f6r\u00fcnmesini engeller. E\u011fer Docker Compose kullan\u0131yorsan\u0131z, secrets<\/code> b\u00f6l\u00fcm\u00fcn\u00fc kullanarak bunu taklit edebilirsiniz:<\/p>\n# docker-compose.yml i\u00e7inde secrets kullan\u0131m\u0131 (\u00d6rnek)\nversion: '3.8'\n\nservices:\n rag_app:\n # ...\n environment:\n OPENAI_API_KEY_FILE: \/run\/secrets\/openai_api_key\n secrets:\n - openai_api_key\n\nsecrets:\n openai_api_key:\n file: .\/openai_api_key.txt # Bu dosya .gitignore i\u00e7inde olmal\u0131!\n<\/pre>\nopenai_api_key.txt<\/code> adl\u0131 bir dosya olu\u015fturup i\u00e7ine API anahtar\u0131n\u0131z\u0131 yazmal\u0131s\u0131n\u0131z. Bu dosyan\u0131n asla Git'e eklenmedi\u011finden emin olun. Uygulaman\u0131zda bu dosyay\u0131 \/run\/secrets\/openai_api_key<\/code> yolundan okuyarak anahtara eri\u015febilirsiniz. Bu yakla\u015f\u0131m, g\u00fcvenlik duru\u015funuzu \u00f6nemli \u00f6l\u00e7\u00fcde g\u00fc\u00e7lendirir.<\/p>\nPerformans: \u0130maj Optimizasyonu ve Katman \u00d6nbellekleme<\/h3>\n
\n
node_modules<\/code>), derleme ortam\u0131n\u0131 nihai \u00e7al\u0131\u015ft\u0131rma ortam\u0131ndan ay\u0131rmak i\u00e7in \u00e7ok a\u015famal\u0131 derlemeler kullan\u0131n. Bu, nihai imaj\u0131n boyutunu \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131r.<\/li>\nDockerfile<\/code>'daki komutlar\u0131n s\u0131ras\u0131n\u0131 optimize edin. En az de\u011fi\u015fen katmanlar\u0131 (\u00f6rne\u011fin temel imaj, ba\u011f\u0131ml\u0131l\u0131klar) en \u00fcste koyun ve s\u0131k de\u011fi\u015fen katmanlar\u0131 (\u00f6rne\u011fin uygulama kodu) alta getirin. Docker, bir katmanda de\u011fi\u015fiklik alg\u0131lamad\u0131\u011f\u0131nda onu \u00f6nbellekten kullan\u0131r, bu da imaj olu\u015fturma s\u00fcresini h\u0131zland\u0131r\u0131r.<\/li>\n.dockerignore<\/code> dosyas\u0131 kullanarak node_modules<\/code>, .git<\/code>, log dosyalar\u0131 gibi imaj\u0131n\u0131za dahil edilmemesi gereken dosyalar\u0131 belirtin. Bu, imaj boyutunu k\u00fc\u00e7\u00fclt\u00fcr ve derleme ba\u011flam\u0131n\u0131 temiz tutar.<\/li>\n--no-cache-dir<\/code> ve --virtual-env<\/code>:<\/strong> Python pip install<\/code> komutlar\u0131nda --no-cache-dir<\/code> bayra\u011f\u0131n\u0131 kullanarak paket \u00f6nbelle\u011fini kald\u0131rmay\u0131 d\u00fc\u015f\u00fcnebilirsiniz. Bu, imaj boyutunu k\u00fc\u00e7\u00fclt\u00fcr ancak her derlemede t\u00fcm paketlerin yeniden indirilmesi anlam\u0131na gelir.<\/li>\n<\/ul>\nMonitoring ve Loglama<\/h3>\n
CI\/CD Entegrasyonu<\/h3>\n
Sonu\u00e7 ve S\u0131k\u00e7a Sorulan Sorular<\/h2>\n
.env<\/code> dosyalar\u0131 arac\u0131l\u0131\u011f\u0131yla esnek yap\u0131land\u0131rma stratejilerini ele alarak, farkl\u0131 ortamlarda sorunsuz \u00e7al\u0131\u015fan ve hassas bilgileri g\u00fcvenli bir \u015fekilde y\u00f6neten RAG uygulamalar\u0131 geli\u015ftirmenin yollar\u0131n\u0131 g\u00f6rd\u00fck. Ger\u00e7ek d\u00fcnya senaryolar\u0131 ve ileri d\u00fczey ipu\u00e7lar\u0131 ile, RAG sistemlerinizi sadece geli\u015ftirme a\u015famas\u0131nda de\u011fil, \u00fcretimde de \u00f6l\u00e7eklenebilir, g\u00fcvenli ve performansl\u0131 hale getirmek i\u00e7in gerekli ara\u00e7lar\u0131 ve bilgileri edindiniz. Konteynerizasyon ve do\u011fru yap\u0131land\u0131rma yakla\u015f\u0131mlar\u0131, modern yaz\u0131l\u0131m geli\u015ftirmenin temel ta\u015flar\u0131d\u0131r ve RAG gibi h\u0131zla geli\u015fen, \u00e7ok bile\u015fenli sistemler i\u00e7in vazge\u00e7ilmezdir. Bu sayede, RAG projeleriniz daha h\u0131zl\u0131 geli\u015fir, daha g\u00fcvenilir bir \u015fekilde da\u011f\u0131t\u0131l\u0131r ve daha kolay y\u00f6netilir, b\u00f6ylece yenilik\u00e7ili\u011fe odaklanabilirsiniz. RAG teknolojisi h\u0131zla evrilirken, bu sa\u011flam temeller \u00fczerine in\u015fa edilen sistemler gelecekteki de\u011fi\u015fikliklere daha kolay adapte olabilecektir.<\/p>\nS\u0131k\u00e7a Sorulan Sorular<\/h3>\n
\n
docker-compose.yml<\/code> dosyan\u0131zda sadece image: qdrant\/qdrant:latest<\/code> gibi bir sat\u0131r ekleyerek onlar\u0131 RAG sisteminize entegre edebilirsiniz. Bu, farkl\u0131 veritabanlar\u0131n\u0131 denemeyi ve ge\u00e7i\u015f yapmay\u0131 da olduk\u00e7a kolayla\u015ft\u0131r\u0131r.<\/p>\n<\/li>\ndocker-compose.yml<\/code> dosyas\u0131n\u0131n \u00e7ekirde\u011fini kullanabilirsiniz, ancak farkl\u0131 ortamlar i\u00e7in \u00f6zelle\u015ftirmeler yapman\u0131z \u00f6nerilir. Bu \u00f6zelle\u015ftirmeleri .env<\/code> dosyalar\u0131, ortam de\u011fi\u015fkenleri veya birden fazla Docker Compose dosyas\u0131 (docker-compose.dev.yml<\/code>, docker-compose.prod.yml<\/code> gibi) ile y\u00f6netebilirsiniz. \u00d6rne\u011fin, geli\u015ftirme ortam\u0131nda kodunuzu an\u0131nda yans\u0131tmak i\u00e7in volumes<\/code> kullan\u0131rken, \u00fcretimde bu \u00f6zellikten ka\u00e7\u0131nabilir ve daha optimize edilmi\u015f imajlar\u0131 tercih edebilirsiniz. \u00dcretimde ayr\u0131ca daha g\u00fc\u00e7l\u00fc sunucular, daha fazla replika ve g\u00fcvenlik \u00f6nlemleri gibi farkl\u0131 konfig\u00fcrasyonlara ihtiya\u00e7 duyulacakt\u0131r.<\/p>\n<\/li>\n