Container'larda FastAPI - Docker¶

FastAPI uygulamalarını deploy ederken yaygın bir yaklaşım, birLinux container image oluşturmaktır. Bu genellikleDocker kullanılarak yapılır. Ardından bu container image'ı birkaç farklı yöntemden biriyle deploy edebilirsiniz.

Linux container'ları kullanmanıngüvenlik,tekrarlanabilirlik,basitlik gibi birçok avantajı vardır.

FROMpython:3.14WORKDIR/codeCOPY./requirements.txt/code/requirements.txtRUNpipinstall--no-cache-dir--upgrade-r/code/requirements.txtCOPY./app/code/appCMD["fastapi","run","app/main.py","--port","80"]# If running behind a proxy like Nginx or Traefik add --proxy-headers# CMD ["fastapi", "run", "app/main.py", "--port", "80", "--proxy-headers"]

Container Nedir¶

Container'lar (özellikle Linux container'ları), bir uygulamayı tüm bağımlılıkları ve gerekli dosyalarıyla birlikte paketlemenin, aynı sistemdeki diğer container'lardan (diğer uygulama ya da bileşenlerden) izole tutarken yapılan, çokhafif bir yoludur.

Linux container'ları, host'un (makine, sanal makine, cloud server vb.) aynı Linux kernel'ini kullanarak çalışır. Bu da, tüm bir işletim sistemini emüle eden tam sanal makinelere kıyasla çok daha hafif oldukları anlamına gelir.

Bu sayede container'laraz kaynak tüketir; süreçleri doğrudan çalıştırmaya benzer bir seviyede (bir sanal makine çok daha fazla tüketirdi).

Container'ların ayrıca kendiizole çalışan process'leri (çoğunlukla tek bir process), dosya sistemi ve ağı vardır. Bu da deployment, güvenlik, geliştirme vb. süreçleri kolaylaştırır.

Container Image Nedir¶

Bircontainer, bircontainer image'dan çalıştırılır.

Container image; bir container içinde bulunması gereken tüm dosyaların, environment variable'ların ve varsayılan komut/programınstatik bir sürümüdür. Buradakistatik, containerimage'ının çalışmadığı, execute edilmediği; sadece paketlenmiş dosyalar ve metadata olduğu anlamına gelir.

Depolanmış statik içerik olan "container image"ın aksine, "container" normalde çalışan instance'ı, yaniexecute edilen şeyi ifade eder.

Container başlatılıp çalıştığında (bircontainer image'dan başlatılır), dosyalar oluşturabilir/değiştirebilir, environment variable'ları değiştirebilir vb. Bu değişiklikler sadece o container içinde kalır; alttaki container image'da kalıcı olmaz (diske kaydedilmez).

Bir container image,program dosyası ve içeriklerine benzetilebilir; örn.python vemain.py gibi bir dosya.

Vecontainer'ın kendisi (container image'a karşıt olarak) image'ın gerçek çalışan instance'ıdır; birprocess'e benzer. Hatta bir container, yalnızca içindeçalışan bir process varken çalışır (ve genelde tek process olur). İçinde çalışan process kalmayınca container durur.

Container Image'lar¶

Docker,container image vecontainer oluşturup yönetmek için kullanılan başlıca araçlardan biri olmuştur.

Ayrıca birçok araç, ortam, veritabanı ve uygulama için önceden hazırlanmışresmi container image'ların bulunduğu herkese açık birDocker Hub vardır.

Örneğin, resmi birPython Image bulunur.

Ve veritabanları gibi farklı şeyler için de birçok image vardır; örneğin:

• PostgreSQL
• MySQL
• MongoDB
• Redis, vb.

Hazır bir container image kullanarak farklı araçlarıbirleştirmek ve birlikte kullanmak çok kolaydır. Örneğin yeni bir veritabanını denemek için. Çoğu durumdaresmi image'ları kullanıp sadece environment variable'lar ile yapılandırmanız yeterlidir.

Bu şekilde, çoğu zaman container'lar ve Docker hakkında öğrendiklerinizi farklı araç ve bileşenlerde tekrar kullanabilirsiniz.

Dolayısıyla; veritabanı, Python uygulaması, React frontend uygulaması olan bir web server gibi farklı şeyler içinbirden fazla container çalıştırır ve bunları internal network üzerinden birbirine bağlarsınız.

Docker veya Kubernetes gibi tüm container yönetim sistemlerinde bu ağ özellikleri entegre olarak bulunur.

Container'lar ve Process'ler¶

Bircontainer image normalde metadata içinde,container başlatıldığında çalıştırılacak varsayılan program/komutu ve o programa geçirilecek parametreleri içerir. Bu, komut satırında yazacağınız şeye çok benzer.

Bircontainer başlatıldığında bu komutu/programı çalıştırır (ancak isterseniz bunu override edip başka bir komut/program çalıştırabilirsiniz).

Bir container,ana process (komut/program) çalıştığı sürece çalışır.

Container'larda normaldetek bir process olur. Ancak ana process içinden subprocess'ler başlatmak da mümkündür; böylece aynı container içindebirden fazla process olur.

Amaen az bir çalışan process olmadan çalışan bir container olamaz. Ana process durursa container da durur.

FastAPI için Docker Image Oluşturalım¶

Tamam, şimdi bir şeyler inşa edelim! 🚀

ResmiPython image'ını temel alarak, FastAPI içinsıfırdan birDocker image nasıl oluşturulur göstereceğim.

Bu, örneğin şu durumlardaçoğu zaman yapmak isteyeceğiniz şeydir:

• Kubernetes veya benzeri araçlar kullanırken
• Raspberry Pi üzerinde çalıştırırken
• Container image'ınızı sizin için çalıştıran bir cloud servisi kullanırken, vb.

Paket Gereksinimleri¶

Uygulamanızınpaket gereksinimleri genelde bir dosyada yer alır.

Bu, gereksinimleriyüklemek için kullandığınız araca göre değişir.

En yaygın yöntem, paket adları ve versiyonlarının satır satır yazıldığı birrequirements.txt dosyasına sahip olmaktır.

Versiyon aralıklarını belirlemek için elbetteFastAPI sürümleri hakkında bölümünde okuduğunuz fikirleri kullanırsınız.

Örneğinrequirements.txt şöyle görünebilir:

fastapi[standard]>=0.113.0,<0.114.0pydantic>=2.7.0,<3.0.0

Ve bu bağımlılıkları normaldepip ile yüklersiniz, örneğin:

$pipinstall-rrequirements.txt---> 100%Successfully installed fastapi pydantic

FastAPI Kodunu Oluşturun¶

• Birapp dizini oluşturun ve içine girin.
• Boş bir__init__.py dosyası oluşturun.
• Aşağıdakilerle birmain.py dosyası oluşturun:

fromfastapiimportFastAPIapp=FastAPI()@app.get("/")defread_root():return{"Hello":"World"}@app.get("/items/{item_id}")defread_item(item_id:int,q:str|None=None):return{"item_id":item_id,"q":q}

Dockerfile¶

Şimdi aynı proje dizinindeDockerfile adlı bir dosya oluşturun ve içine şunları yazın:

# (1)!FROMpython:3.14# (2)!WORKDIR/code# (3)!COPY./requirements.txt/code/requirements.txt# (4)!RUNpipinstall--no-cache-dir--upgrade-r/code/requirements.txt# (5)!COPY./app/code/app# (6)!CMD["fastapi","run","app/main.py","--port","80"]

1. Resmi Python base image'ından başlayın.

2. Geçerli çalışma dizinini/code olarak ayarlayın.

   requirements.txt dosyasını veapp dizinini buraya koyacağız.

3. Gereksinimleri içeren dosyayı/code dizinine kopyalayın.

   Önce kodun tamamını değil,sadece gereksinim dosyasını kopyalayın.

   Bu dosyaçok sık değişmediği için Docker bunu tespit eder ve bu adımdacache kullanır; böylece bir sonraki adım için de cache devreye girer.

4. Gereksinim dosyasındaki paket bağımlılıklarını yükleyin.

   --no-cache-dir seçeneği, indirilen paketlerin yerel olarak kaydedilmemesinipip'e söyler. Bu kayıt,pip aynı paketleri tekrar yüklemek için yeniden çalıştırılacaksa işe yarar; ancak container'larla çalışırken genelde bu durum geçerli değildir.

   Not

   --no-cache-dir yalnızcapip ile ilgilidir; Docker veya container'larla ilgili değildir.

   --upgrade seçeneği, paketler zaten yüklüysepip'e onları yükseltmesini söyler.

   Bir önceki adım (dosyayı kopyalama)Docker cache tarafından tespit edilebildiği için, bu adım da uygun olduğundaDocker cache'i kullanır.

   Bu adımda cache kullanmak, geliştirme sırasında image'ı tekrar tekrar build ederken size çokzaman kazandırır; her seferinde bağımlılıklarıindirip yüklemek zorunda kalmazsınız.

5. ./app dizinini/code dizininin içine kopyalayın.

   Burada en sık değişen şey olan kodun tamamı bulunduğundan, bu adım (ve genelde bundan sonraki adımlar) için Dockercache'i kolay kolay kullanılamaz.

   Bu yüzden, container image build sürelerini optimize etmek için bunuDockerfile'ınsonlarına yakın koymak önemlidir.

6. Altta Uvicorn kullananfastapi run komutunucommand olarak ayarlayın.

   CMD bir string listesi alır; bu string'lerin her biri komut satırında boşlukla ayrılmış şekilde yazacağınız parçaları temsil eder.

   Bu komut, yukarıdaWORKDIR /code ile ayarladığınız/code dizininden çalıştırılır.

CMD Kullanımı - Exec Form¶

CMD Docker talimatı iki formda yazılabilir:

✅Exec form:

# ✅ Do thisCMD["fastapi","run","app/main.py","--port","80"]

⛔️Shell form:

# ⛔️ Don't do thisCMDfastapirunapp/main.py--port80

FastAPI'nin düzgün şekilde kapanabilmesi velifespan event'lerinin tetiklenmesi için her zamanexec formunu kullanın.

Detaylar içinshell ve exec form için Docker dokümanlarına bakabilirsiniz.

Bu durumdocker compose kullanırken oldukça belirgin olabilir. Daha teknik detaylar için şu Docker Compose FAQ bölümüne bakın:Hizmetlerimin yeniden oluşturulması veya durması neden 10 saniye sürüyor?.

Dizin Yapısı¶

Artık dizin yapınız şöyle olmalı:

.├── app│   ├── __init__.py│   └── main.py├── Dockerfile└── requirements.txt

TLS Termination Proxy Arkasında¶

Container'ınızı Nginx veya Traefik gibi bir TLS Termination Proxy (load balancer) arkasında çalıştırıyorsanız--proxy-headers seçeneğini ekleyin. Bu, Uvicorn'a (FastAPI CLI üzerinden) uygulamanın HTTPS arkasında çalıştığını söyleyen proxy header'larına güvenmesini söyler.

CMD["fastapi","run","app/main.py","--proxy-headers","--port","80"]

Docker Cache¶

BuDockerfile içinde önemli bir numara var: önce kodun geri kalanını değil,sadece bağımlılık dosyasını kopyalıyoruz. Nedenini anlatayım.

COPY./requirements.txt/code/requirements.txt

Docker ve benzeri araçlar bu container image'larınıartımlı (incremental) olarakbuild eder;Dockerfile'ın en üstünden başlayıp her talimatın oluşturduğu dosyaları ekleyerekkatman katman (layer) ilerler.

Docker ve benzeri araçlar image build ederken ayrıca birinternal cache kullanır. Son build'den beri bir dosya değişmediyse, dosyayı tekrar kopyalayıp sıfırdan yeni bir layer oluşturmak yerine, daha önce oluşturulanaynı layer'ı yeniden kullanır.

Sadece dosya kopyalamayı azaltmak her zaman büyük fark yaratmaz. Ancak o adımda cache kullanıldığı için,bir sonraki adımda da cache kullanılabilir. Örneğin bağımlılıkları yükleyen şu talimat için:

RUNpipinstall--no-cache-dir--upgrade-r/code/requirements.txt

Paket gereksinimleri dosyasısık sık değişmez. Bu yüzden sadece bu dosyayı kopyalayınca, Docker bu adımdacache kullanabilir.

Sonra Docker, bağımlılıkları indirip yükleyenbir sonraki adımda da cache kullanabilir. Asılçok zaman kazandığımız yer de burasıdır. ✨ ...ve beklerken sıkılmayı engeller. 😪😆

Bağımlılıkları indirip yüklemekdakikalar sürebilir, fakatcache kullanmak en fazlasaniyeler alır.

Geliştirme sırasında kod değişikliklerinizin çalıştığını kontrol etmek için container image'ı tekrar tekrar build edeceğinizden, bu ciddi birikimli zaman kazancı sağlar.

SonraDockerfile'ın sonlarına doğru tüm kodu kopyalarız. En sık değişen kısım bu olduğu için sona koyarız; çünkü neredeyse her zaman bu adımdan sonra gelen adımlar cache kullanamaz.

COPY./app/code/app

Docker Image'ını Build Edin¶

Tüm dosyalar hazır olduğuna göre container image'ı build edelim.

• Proje dizinine gidin (Dockerfile'ınızın olduğu veapp dizininizi içeren dizin).
• FastAPI image'ınızı build edin:

$dockerbuild-tmyimage.---> 100%

Docker Container'ını Başlatın¶

• Image'ınızdan bir container çalıştırın:

$dockerrun-d--namemycontainer-p80:80myimage

Kontrol Edin¶

Docker container'ınızın URL'inden kontrol edebilmelisiniz. Örneğin:http://192.168.99.100/items/5?q=somequery veyahttp://127.0.0.1/items/5?q=somequery (ya da Docker host'unuzu kullanarak eşdeğeri).

Şuna benzer bir şey görürsünüz:

{"item_id":5,"q":"somequery"}

Etkileşimli API Dokümanları¶

Şimdihttp://192.168.99.100/docs veyahttp://127.0.0.1/docs adresine gidebilirsiniz (ya da Docker host'unuzla eşdeğeri).

Otomatik etkileşimli API dokümantasyonunu görürsünüz (Swagger UI tarafından sağlanır):

Alternatif API Dokümanları¶

Ayrıcahttp://192.168.99.100/redoc veyahttp://127.0.0.1/redoc adresine de gidebilirsiniz (ya da Docker host'unuzla eşdeğeri).

Alternatif otomatik dokümantasyonu görürsünüz (ReDoc tarafından sağlanır):

Tek Dosyalık FastAPI ile Docker Image Oluşturma¶

FastAPI uygulamanız tek bir dosyaysa; örneğin./app dizini olmadan sadecemain.py varsa, dosya yapınız şöyle olabilir:

.├── Dockerfile├── main.py└── requirements.txt

Bu durumdaDockerfile içinde dosyayı kopyaladığınız path'leri buna göre değiştirmeniz yeterlidir:

FROMpython:3.14WORKDIR/codeCOPY./requirements.txt/code/requirements.txtRUNpipinstall--no-cache-dir--upgrade-r/code/requirements.txt# (1)!COPY./main.py/code/# (2)!CMD["fastapi","run","main.py","--port","80"]

1. main.py dosyasını doğrudan/code dizinine kopyalayın (herhangi bir./app dizini olmadan).

2. Tek dosya olanmain.py içindeki uygulamanızı sunmak içinfastapi run kullanın.

Dosyayıfastapi run'a verdiğinizde, bunun bir package'ın parçası değil tek bir dosya olduğunu otomatik olarak algılar; nasıl import edip FastAPI uygulamanızı nasıl serve edeceğini bilir. 😎

Deployment Kavramları¶

AynıDeployment Kavramlarını bu kez container'lar açısından tekrar konuşalım.

Container'lar, bir uygulamayıbuild etme ve deploy etme sürecini basitleştiren bir araçtır. Ancak budeployment kavramlarını ele almak için belirli bir yaklaşımı zorunlu kılmazlar; birkaç farklı strateji mümkündür.

İyi haber şu: Hangi stratejiyi seçerseniz seçin, deployment kavramlarının tamamını kapsayacak bir yol vardır. 🎉

Budeployment kavramlarını container'lar açısından gözden geçirelim:

• HTTPS
• Startup'ta çalıştırma
• Restart'lar
• Replication (çalışan process sayısı)
• Memory
• Başlatmadan önceki adımlar

HTTPS¶

Bir FastAPI uygulamasının sadececontainer image'ına (ve sonra çalışancontainer'a) odaklanırsak, HTTPS genellikleharicen başka bir araçla ele alınır.

ÖrneğinTraefik kullanan başka bir container olabilir;HTTPS vesertifikalarınotomatik alınmasını o yönetebilir.

Alternatif olarak HTTPS, bir cloud provider'ın sunduğu servislerden biri tarafından da yönetilebilir (uygulama yine container içinde çalışırken).

Startup'ta Çalıştırma ve Restart'lar¶

Container'ınızıbaşlatıp çalıştırmaktan sorumlu genellikle başka bir araç olur.

Bu; doğrudanDocker,Docker Compose,Kubernetes, bircloud service vb. olabilir.

Çoğu (veya tüm) durumda, container'ı startup'ta çalıştırmayı ve hata durumlarında restart'ları etkinleştirmeyi sağlayan basit bir seçenek vardır. Örneğin Docker'da bu,--restart komut satırı seçeneğidir.

Container kullanmadan, uygulamaları startup'ta çalıştırmak ve restart mekanizması eklemek zahmetli ve zor olabilir. Ancakcontainer'larla çalışırken çoğu zaman bu işlevler varsayılan olarak hazır gelir. ✨

Replication - Process Sayısı¶

Eğer birküme (cluster) olarak yapılandırılmış makineler grubunuz varsa ve bunlarıKubernetes, Docker Swarm Mode, Nomad veya benzeri, birden çok makinede dağıtık container'ları yöneten karmaşık bir sistemle yönetiyorsanız, replication'ı her container içinde birprocess manager (ör. worker'lı Uvicorn) kullanarak yönetmek yerine, muhtemelenküme seviyesinde (cluster level) ele almak istersiniz.

Kubernetes gibi dağıtık container yönetim sistemleri, gelen request'ler içinload balancing desteği sunarken aynı zamandacontainer replication'ını yönetmek için entegre mekanizmalara sahiptir. Hepsicluster seviyesinde.

Bu tür durumlarda, yukarıdaanlatıldığı gibi bağımlılıkları yükleyipsıfırdan bir Docker image build etmek ve birden fazla Uvicorn worker kullanmak yerinetek bir Uvicorn process çalıştırmak istersiniz.

Load Balancer¶

Container'lar kullanırken, genellikle ana port'ta dinleyen bir bileşen olur. Bu,HTTPS'i ele almak için birTLS Termination Proxy olan başka bir container da olabilir ya da benzeri bir araç olabilir.

Bu bileşen request'lerinyükünü alıp worker'lar arasında (umarım)dengeli şekilde dağıttığı için yaygın olarakLoad Balancer diye de adlandırılır.

Container'larla çalışırken, onları başlatıp yönettiğiniz sistem; buload balancer'dan (aynı zamandaTLS Termination Proxy de olabilir) uygulamanızın bulunduğu container(lar)anetwork communication'ı (ör. HTTP request'leri) iletmek için zaten dahili araçlar sunar.

Tek Load Balancer - Çoklu Worker Container¶

Kubernetes veya benzeri dağıtık container yönetim sistemleriyle çalışırken, dahili ağ mekanizmaları sayesinde anaport'u dinleyen tek birload balancer, uygulamanızı çalıştıran muhtemelenbirden fazla container'a request'leri iletebilir.

Uygulamanızı çalıştıran bu container'ların her birinde normaldetek bir process olur (ör. FastAPI uygulamanızı çalıştıran bir Uvicorn process). Hepsi aynı şeyi çalıştıranözdeş container'lardır; ancak her birinin kendi process'i, memory'si vb. vardır. Böylece CPU'nunfarklı core'larında, hattafarklı makinelerde paralelleştirmeden yararlanırsınız.

Load balancer'lı dağıtık sistem, request'leri uygulamanızın bulunduğu container'ların her birine sırayladağıtır. Böylece her request, uygulamanızın birden fazlareplicated container'ından biri tarafından işlenebilir.

Ve buload balancer normalde cluster'ınızdakidiğer uygulamalara giden request'leri de (ör. farklı bir domain ya da farklı bir URL path prefix altında) yönetebilir ve iletişimi odiğer uygulamanın doğru container'larına iletir.

Container Başına Tek Process¶

Bu senaryoda, replication'ı zaten cluster seviyesinde yaptığınız için, muhtemelencontainer başına tek bir (Uvicorn) process istersiniz.

Dolayısıyla bu durumda container içinde--workers gibi bir komut satırı seçeneğiyle çoklu worker istemezsiniz. Container başına sadecetek bir Uvicorn process istersiniz (ama muhtemelen birden fazla container).

Container içine ekstra bir process manager koymak (çoklu worker gibi) çoğu zaman zaten cluster sisteminizle çözdüğünüz şeye ekgereksiz karmaşıklık katar.

Birden Fazla Process'li Container'lar ve Özel Durumlar¶

Elbette bazıözel durumlarda bir container içinde birden fazlaUvicorn worker process çalıştırmak isteyebilirsiniz.

Bu durumlarda çalıştırmak istediğiniz worker sayısını--workers komut satırı seçeneğiyle ayarlayabilirsiniz:

FROMpython:3.14WORKDIR/codeCOPY./requirements.txt/code/requirements.txtRUNpipinstall--no-cache-dir--upgrade-r/code/requirements.txtCOPY./app/code/app# (1)!CMD["fastapi","run","app/main.py","--port","80","--workers","4"]

1. Burada worker sayısını 4 yapmak için--workers komut satırı seçeneğini kullanıyoruz.

Bunun mantıklı olabileceği birkaç örnek:

Basit Bir Uygulama¶

Uygulamanız tek bir server üzerinde (cluster değil) çalışacak kadarbasitse, container içinde bir process manager isteyebilirsiniz.

Docker Compose¶

Docker Compose iletek bir server'a (cluster değil) deploy ediyor olabilirsiniz. Bu durumda, paylaşılan ağı veload balancing'i koruyarak container replication'ını (Docker Compose ile) yönetmenin kolay bir yolu olmayabilir.

Bu durumda, tek bir container içindebir process manager ilebirden fazla worker process başlatmak isteyebilirsiniz.

Ana fikir şu: Bunlarınhiçbiri körü körüne uymanız gerekendeğişmez kurallar değildir. Bu fikirleri, kendi kullanım senaryonuzudeğerlendirmek ve sisteminiz için en iyi yaklaşımı seçmek için kullanabilirsiniz. Şu kavramları nasıl yöneteceğinize bakarak karar verin:

• Güvenlik - HTTPS
• Startup'ta çalıştırma
• Restart'lar
• Replication (çalışan process sayısı)
• Memory
• Başlatmadan önceki adımlar

Memory¶

Container başına tek process çalıştırırsanız, her container'ın tüketeceği memory miktarı aşağı yukarı tanımlı, stabil ve sınırlı olur (replication varsa birden fazla container için).

Sonra aynı memory limit ve gereksinimlerini container yönetim sisteminizin (ör.Kubernetes) konfigürasyonlarında belirleyebilirsiniz. Böylece sistem; ihtiyaç duyulan memory miktarını ve cluster'daki makinelerde mevcut memory'yi dikkate alarakuygun makinelerde container'ları replicate edebilir.

Uygulamanızbasitse, muhtemelen bubir sorun olmaz ve katı memory limitleri belirlemeniz gerekmeyebilir. Ancakçok memory kullanıyorsanız (ör.machine learning modelleriyle), ne kadar memory tükettiğinizi kontrol edipher makinede çalışacakcontainer sayısını ayarlamalısınız (ve gerekirse cluster'a daha fazla makine eklemelisiniz).

Container başına birden fazla process çalıştırırsanız, başlatılan process sayısının mevcut olandanfazla memory tüketmediğinden emin olmanız gerekir.

Başlatmadan Önceki Adımlar ve Container'lar¶

Container kullanıyorsanız (örn. Docker, Kubernetes), temelde iki yaklaşım vardır.

Birden Fazla Container¶

Birden fazla container'ınız varsa ve muhtemelen her biritek process çalıştırıyorsa (ör. birKubernetes cluster'ında), replication yapılan worker container'lar çalışmadanönce,başlatmadan önceki adımların işini yapanayrı bir container kullanmak isteyebilirsiniz (tek container, tek process).

Kullanım senaryonuzda bu adımlarıparalel olarak birden fazla kez çalıştırmak sorun değilse (örneğin veritabanı migration çalıştırmıyor, sadece veritabanı hazır mı diye kontrol ediyorsanız), o zaman her container'da ana process başlamadan hemen önce de çalıştırabilirsiniz.

Tek Container¶

Basit bir kurulumda;tek bir container olup onun içinde birden fazlaworker process (ya da sadece bir process) başlatıyorsanız, bu adımları aynı container içinde, uygulama process'ini başlatmadan hemen önce çalıştırabilirsiniz.

Base Docker Image¶

Eskiden resmi bir FastAPI Docker image'ı vardı:tiangolo/uvicorn-gunicorn-fastapi. Ancak artık kullanımdan kaldırıldı (deprecated). ⛔️

Muhtemelen bu base Docker image'ını (veya benzeri başka bir image'ı) kullanmamalısınız.

Kubernetes (veya diğerleri) kullanıyor ve cluster seviyesinde birden fazlacontainer ilereplication ayarlıyorsanız, bu durumda yukarıda anlatıldığı gibisıfırdan bir image build etmek daha iyi olur:FastAPI için Docker Image Oluşturalım.

Ve birden fazla worker gerekiyorsa, sadece--workers komut satırı seçeneğini kullanabilirsiniz.

Container Image'ı Deploy Etme¶

Bir Container (Docker) Image'ınız olduktan sonra bunu deploy etmenin birkaç yolu vardır.

Örneğin:

• Tek bir server'daDocker Compose ile
• BirKubernetes cluster'ı ile
• Docker Swarm Mode cluster'ı ile
• Nomad gibi başka bir araçla
• Container image'ınızı alıp deploy eden bir cloud servisiyle

uv ile Docker Image¶

Projenizi yüklemek ve yönetmek içinuv kullanıyorsanız, onlarınuv Docker rehberini takip edebilirsiniz.

Özet¶

Container sistemleri (örn.Docker veKubernetes ile) kullanınca tümdeployment kavramlarını ele almak oldukça kolaylaşır:

• HTTPS
• Startup'ta çalıştırma
• Restart'lar
• Replication (çalışan process sayısı)
• Memory
• Başlatmadan önceki adımlar

Çoğu durumda bir base image kullanmak istemezsiniz; bunun yerine resmi Python Docker image'ını temel alaraksıfırdan bir container image build edersiniz.

Dockerfile içindeki talimatlarınsırasına veDocker cache'ine dikkat ederekbuild sürelerini minimize edebilir, üretkenliğinizi artırabilirsiniz (ve beklerken sıkılmayı önlersiniz). 😎