Deno ve pnpm Workspace ile Optimize Edilmiş Docker İmajları Oluşturma

Modern yazılım geliştirme, hız, verimlilik ve tutarlılık gerektirir. Deno’nun güvenli ve performanslı çalışma zamanı ortamı, pnpm’in verimli bağımlılık yönetimi ve Docker’ın taşınabilir konteyner mimarisi, bu gereksinimleri karşılamak için bir araya geldiğinde güçlü bir sinerji oluşturur. Peki, bu üç teknolojiyi bir Docker imajında birleştirerek geliştirme süreçlerinizi nasıl devrimleştirebilirsiniz? Bu makale, Deno ve pnpm workspace yapısını bir Docker imajına entegre etmenin inceliklerini, en iyi uygulamalarını ve gerçek dünya senaryolarındaki faydalarını detaylıca ele alacaktır. Amacımız, hem yeni başlayanların hem de deneyimli geliştiricilerin bu karmaşık süreci adım adım anlamasını sağlamak ve optimize edilmiş, güvenli ve ölçeklenebilir uygulamalar oluşturmalarına yardımcı olmaktır.

Günümüzün hızlı tempolu geliştirme dünyasında, uygulamaların tutarlı bir şekilde farklı ortamlarda çalışması hayati öneme sahiptir. Geliştiricilerin yerel makinelerinde çalışan bir uygulamanın, test, hazırlık (staging) ve üretim ortamlarında da sorunsuz bir şekilde çalışması beklenir. İşte tam da bu noktada konteynerleşme teknolojisi ve özellikle Docker devreye girer. Docker, uygulamaları ve bağımlılıklarını izole edilmiş, taşınabilir bir konteyner içinde paketleyerek bu tutarlılığı sağlar. Ancak, bir uygulamanın bağımlılıklarını verimli bir şekilde yönetmek ve çalışma zamanı ortamını optimize etmek de aynı derecede önemlidir. Bu bağlamda, Deno gibi modern bir JavaScript/TypeScript çalışma zamanı ve pnpm gibi akıllı bir paket yöneticisi, geliştiricilere önemli avantajlar sunar. Bir monorepo (monolithic repository) yaklaşımıyla birden fazla Deno projesini tek bir pnpm workspace içinde yönetmek, kod paylaşımını kolaylaştırır ve bağımlılıkların tekrarlanmasını önler. Bu güçlü kombinasyonu Docker ile birleştirmek, geliştirme ve dağıtım süreçlerinde eşi benzeri görülmemiş bir verimlilik ve kontrol düzeyi sunar.

Bu makale boyunca, Deno, pnpm ve Docker’ın temel prensiplerini anlamaktan başlayarak, adım adım nasıl bir Dockerfile oluşturacağınızı, performans ve güvenlik optimizasyonlarını nasıl uygulayacağınızı ve bu entegrasyonun gerçek dünya senaryolarında nasıl kullanılabileceğini keşfedeceğiz. Örneğin, bir mikroservis mimarisinde her bir Deno servisini ayrı bir Docker konteyneri olarak nasıl çalıştıracağınızı veya CI/CD boru hatlarında bu yapıyı nasıl kullanacağınızı ele alacağız. Amacımız, sadece teknik bilgiyi aktarmakla kalmayıp, aynı zamanda okuyuculara bu teknolojilerin bir araya geldiğinde sunduğu potansiyeli göstererek, kendi projelerinde yenilikçi çözümler üretmeleri için ilham vermektir. Bu entegrasyon, özellikle büyük ve karmaşık projelerde bağımlılık yönetimini basitleştirir, imaj boyutlarını küçültür ve dağıtım süreçlerini hızlandırır, böylece geliştiricilere daha fazla zaman ve enerji kazandırır.

Deno, pnpm ve Docker: Temelleri Anlamak Neden Önemli?

Herhangi bir karmaşık sistemi kurmadan önce, o sistemin temel bileşenlerini iyi anlamak kritik öneme sahiptir. Bu bölümde, Deno’nun modern çalışma zamanı özellikleri, pnpm’in bağımlılık yönetimindeki devrimci yaklaşımı ve Docker’ın konteynerleştirme gücü hakkında özet bilgiler sunacağız. Ayrıca, bu üç teknolojinin bir araya geldiğinde monorepo yapılarında nasıl bir değer yarattığını da inceleyeceğiz.

Deno Nedir ve Modern Web Geliştirmede Yeri Nasıldır?

Deno, Ryan Dahl tarafından geliştirilen, JavaScript ve TypeScript için güvenli, hızlı ve modern bir çalışma zamanı ortamıdır. NodeJS’in yaratıcısı olan Dahl, NodeJS’teki bazı temel tasarım kararlarından duyduğu pişmanlıkları gidermek amacıyla Deno’yu tasarladı. Deno’nun öne çıkan özellikleri arasında varsayılan olarak güvenli olması (dosya sistemi, ağ ve ortam değişkenlerine erişim için açıkça izin verilmesi gerekir), TypeScript’i yerel olarak desteklemesi (derleyiciye ihtiyaç duymaz), tek bir yürütülebilir dosya olması (bağımlılıkları birleştirir) ve standart web API’lerini (Fetch API, Web Workers vb.) benimsemesi yer alır. Bu özellikler, Deno’yu hem backend hem de CLI araçları geliştirmek için cazip bir seçenek haline getirir. Örneğin, bir Deno uygulaması varsayılan olarak ağ erişimi veya dosya yazma iznine sahip değildir; bu izinler uygulama çalıştırılırken deno run --allow-net --allow-write main.ts gibi komutlarla açıkça verilmelidir. Bu güvenlik modeli, özellikle konteynerize edilmiş uygulamalarda ekstra bir koruma katmanı sağlar, çünkü yetkisiz erişim riski önemli ölçüde azalır. Ayrıca, Deno’nun tek bir ikili dosya olarak dağıtılması, Docker imajlarının boyutunu küçültme potansiyeli sunar, zira NodeJS’in karmaşık node_modules yapısına ihtiyaç duymaz. Bu sayede, daha hızlı indirme ve dağıtım süreleri elde edilebilir.

pnpm Nedir ve Monorepo Yapılarında Bağımlılıkları Nasıl Yönetir?

pnpm (performant npm), modern JavaScript projeleri için hızlı ve disk alanından tasarruf sağlayan bir paket yöneticisidir. Geleneksel paket yöneticileri (npm, yarn) her projenin node_modules dizinine bağımlılıkların kopyalarını yüklerken, pnpm bu bağımlılıkları sisteminizdeki paylaşılan, içerik adreslenebilir bir depo (content-addressable store) içinde saklar. Bu depo, aynı bağımlılık farklı projelerde kullanıldığında tek bir kopyasının tutulmasını sağlar. Her projenin node_modules dizini ise sembolik linkler (symlinks) aracılığıyla bu paylaşılan depoya bağlanır. Bu yaklaşımın başlıca avantajları şunlardır:

• Disk Alanı Tasarrufu: Aynı bağımlılığın birden fazla kopyasını depolamak yerine tek bir kopyasını tutar. Bu, özellikle çok sayıda proje veya monorepo içeren büyük geliştirme ortamlarında önemli ölçüde yer kazandırır.
• Daha Hızlı Kurulum: Bağımlılıklar zaten depoda mevcutsa, pnpm bunları yeniden indirmez; doğrudan linkleme yapar. Bu, kurulum sürelerini ciddi şekilde kısaltır.
• Daha Sıkı Güvenlik: Bağımlılıklar, node_modules içinde sadece uygulamanın doğrudan ihtiyaç duyduğu paketlerin görünür olduğu bir yapı oluşturur. Bu, “phantom dependencies” (gölge bağımlılıklar) sorununu azaltır ve uygulamanızın yanlışlıkla beklenmedik paketlere erişmesini engeller.
• Monorepo Desteği: pnpm, workspace özelliği sayesinde monorepo’ları doğal ve verimli bir şekilde destekler. Aynı repodaki farklı projeler, birbirlerinin bağımlılıklarını kolayca paylaşabilir ve yönetebilir. Bu, özellikle mikroservisler veya birden fazla kütüphane/uygulama içeren büyük projeler için idealdir.

pnpm’in bu özellikleri, Docker imajlarında node_modules boyutunu minimize etmeye ve derleme sürelerini optimize etmeye yardımcı olur, zira daha az dosya kopyalanır ve daha az yer kaplar.

Docker Nedir ve Konteynerleştirmenin Avantajları Nelerdir?

Docker, uygulamaları ve tüm bağımlılıklarını, işletim sisteminden izole edilmiş, hafif, taşınabilir ve kendi kendine yeten “konteynerler” içinde paketlemeyi sağlayan bir platformdur. Bir Docker konteyneri, uygulamanızın ihtiyaç duyduğu her şeyi (kod, çalışma zamanı, sistem araçları, kütüphaneler ve ayarlar) içerir. Bu, “makinemde çalışıyor” sorununu ortadan kaldırır, çünkü uygulama her yerde aynı şekilde çalışır. Docker’ın başlıca avantajları:

• Tutarlılık: Geliştirme, test ve üretim ortamları arasında tutarlılığı garanti eder.
• İzolasyon: Uygulamalar ve bağımlılıkları birbirinden izole edilir, çakışmaları önler.
• Taşınabilirlik: Konteynerler herhangi bir Docker kurulu sunucuda çalışabilir.
• Kaynak Verimliliği: Sanal makinelere göre daha hafif ve hızlıdır, çünkü aynı işletim sistemi çekirdeğini paylaşırlar.
• Hızlı Dağıtım: Uygulamaların oluşturulması, dağıtılması ve ölçeklendirilmesi kolaylaşır.

Docker’ın bu özellikleri, Deno ve pnpm ile geliştirilen uygulamaların CI/CD süreçlerinde sorunsuz bir şekilde entegre edilmesini ve bulut ortamlarına kolayca dağıtılmasını sağlar. Konteynerler, uygulamanızın yaşam döngüsünün her aşamasında güvenilir ve öngörülebilir bir davranış sergilemesini mümkün kılar.

Monorepo Yaklaşımı Neden Tercih Edilmeli?

Monorepo, birden fazla projenin tek bir versiyon kontrol sisteminde (git deposunda) tutulduğu bir yazılım geliştirme stratejisidir. Bu yaklaşım, mikroservisler, UI bileşen kütüphaneleri ve farklı uygulama katmanları gibi çeşitli bağımsız projelerin aynı depo içinde birlikte geliştirilmesine olanak tanır. Monorepo’nun başlıca faydaları şunlardır:

• Kod Paylaşımı ve Yeniden Kullanım: Ortak kütüphaneler, bileşenler veya yardımcı işlevler kolayca oluşturulup tüm projeler arasında paylaşılabilir. Bu, kod tekrarını azaltır ve geliştirme hızını artırır.
• Atomik Değişiklikler: Birden fazla proje veya servis üzerinde yapılan bir değişiklik, tek bir taahhüt (commit) ile yapılabilir. Bu, farklı repolarda ayrı ayrı taahhütler yapma ve senkronizasyon sorunlarını ortadan kaldırır.
• Basitleştirilmiş Bağımlılık Yönetimi: pnpm gibi araçlar sayesinde, tüm projelerin bağımlılıkları merkezi bir şekilde yönetilebilir. Bu, bağımlılık çakışmalarını azaltır ve güncelleme süreçlerini basitleştirir.
• Geliştirme Ortamı Kolaylığı: Geliştiricilerin tek bir depoyu klonlaması ve tüm projelere erişmesi yeterlidir. Bu, projeler arasında gezinmeyi ve yerel geliştirme ortamını kurmayı kolaylaştırır.
• Tutarlılık: Tüm projelerde aynı kodlama standartları, linting kuralları ve test çerçeveleri daha kolay uygulanabilir.

Deno ve pnpm ile birlikte kullanılan bir monorepo, özellikle ölçeklenen ekipler ve karmaşık uygulama ekosistemleri için güçlü bir çözüm sunar. Bu yapı, hem geliştirici verimliliğini artırır hem de dağıtım süreçlerini daha yönetilebilir hale getirir.

Deno ve pnpm Workspace’i Docker’a Taşımanın Avantajları Nelerdir?

Deno, pnpm ve Docker’ı bir araya getirmek, geliştirme ve dağıtım süreçlerinde önemli avantajlar sağlar. Bu sinerjinin getirdiği başlıca faydaları detaylıca inceleyelim. Bu bölüm, özellikle performans, güvenlik ve tutarlılık konularına odaklanarak, bu entegrasyonun neden modern bir uygulama mimarisi için vazgeçilmez olduğunu ortaya koyacaktır.

Performans ve İmaj Boyutu Optimizasyonu: pnpm’in Rolü

Deno, minimalist bir çalışma zamanı olmasının yanı sıra, pnpm’in bağımlılık yönetimindeki verimliliği ile birleştiğinde Docker imaj boyutlarında önemli optimizasyonlar sağlar. pnpm, bağımlılıkları paylaşılan bir depoda tuttuğu ve sembolik linkler kullandığı için, node_modules dizininin şişkinliğini engeller. Bu durum, özellikle bir monorepo içinde birden fazla projenin benzer bağımlılıklara sahip olduğu senaryolarda çok büyük fayda sağlar. Dockerfile içerisinde pnpm install komutu çalıştığında, eğer bağımlılıklar Docker’ın önbelleğinde (cache) varsa veya paylaşılan depoda mevcutsa, kurulum süresi kısalır ve Docker katmanlarının boyutu küçülür. Sonuç olarak, daha küçük Docker imajları elde edilir. Daha küçük imajlar, daha hızlı indirme, daha hızlı dağıtım ve daha az depolama alanı tüketimi anlamına gelir. Örneğin, bir CI/CD hattında her build işleminde imajın yeniden oluşturulması gerektiğinde, küçük imajlar derleme ve dağıtım sürelerini dramatik şekilde kısaltarak, geliştirici verimliliğini artırır. Bu durum, özellikle bulut ortamlarında maliyet avantajı da sağlar, zira daha az depolama ve bant genişliği kullanılır.

Gelişmiş Güvenlik: Deno’nun İzin Modeli ve Konteyner İzolasyonu

Deno’nun varsayılan olarak güvenli olması, konteynerize edilmiş uygulamalar için ek bir koruma katmanı sağlar. Deno uygulamaları, dosya sistemi, ağ, ortam değişkenleri ve alt süreçlere erişim için açıkça izin istemelidir. Bu, Docker’ın sunduğu konteyner izolasyonuyla birleştiğinde, güvenlik duruşunu önemli ölçüde güçlendirir. Docker konteynerleri zaten uygulamanızı ana sistemden izole ederken, Deno’nun ince taneli izin modeli, uygulamanın konteyner içindeki olası kötü niyetli eylemlerini sınırlar. Örneğin, bir web sunucusu uygulaması sadece ağ erişimine ihtiyaç duyarken, dosya sistemine yazma veya rastgele programlar çalıştırma iznine sahip olmamalıdır. Bu prensip, olası güvenlik açıklarının neden olabileceği zararı minimuma indirmeye yardımcı olur. Ayrıca, pnpm’in node_modules yapısındaki sıkı güvenlik modeli, uygulamanın yalnızca doğrudan bağımlılıklarına erişmesini sağlayarak, kötü niyetli “phantom dependencies” riskini de azaltır. Bu çok katmanlı güvenlik yaklaşımı, kritik uygulamalar için ideal bir ortam sunar.

Tutarlılık ve Taşınabilirlik: Docker’ın Temel Vaadi

Docker’ın en büyük avantajı, “çalışıyor benim makinemde” sorununu ortadan kaldırmasıdır. Deno ve pnpm ile geliştirilen bir uygulama, Docker imajına paketlendiğinde, bu imajın her ortamda (yerel geliştirme, test, hazırlık, üretim) aynı şekilde davranması garanti edilir. Bu tutarlılık, hata ayıklama süreçlerini basitleştirir, dağıtım risklerini azaltır ve tüm geliştirme ekibinin aynı ortamda çalışmasını sağlar. Bir geliştirici, Deno ve pnpm workspace’ini içeren Docker imajını kullanarak, uygulama davranışının kendi yerel makinesinde test edildiği gibi üretimde de olacağından emin olabilir. Bu taşınabilirlik, özellikle farklı bulut sağlayıcıları veya sunucu altyapıları arasında geçiş yaparken hayati öneme sahiptir. Konteynerler, altyapıdan bağımsız bir uygulama katmanı sağlayarak, uygulamaların çok daha esnek ve adapte olabilir olmasını sağlar.

Geliştirici Deneyimi ve CI/CD Süreçlerinde Hızlanma

Monorepo yapısında Deno ve pnpm kullanmak, geliştiricilerin farklı servisler veya kütüphaneler arasında kolayca geçiş yapmasını sağlar. Tüm kod tabanı tek bir yerde olduğundan, kod paylaşımı ve bağımlılık güncellemeleri çok daha sorunsuz hale gelir. Docker’ın bu yapıya entegrasyonu, geliştirme ortamının hızlı bir şekilde kurulmasını sağlar; yeni bir geliştirici sadece depoyu klonlayıp Docker komutlarını çalıştırarak eksiksiz bir geliştirme ortamına sahip olabilir. Ayrıca, CI/CD süreçleri (Sürekli Entegrasyon/Sürekli Dağıtım) bu entegrasyondan büyük ölçüde faydalanır. Küçük ve optimize edilmiş Docker imajları, daha hızlı build ve push süreleri anlamına gelir. Multi-stage build yaklaşımları kullanılarak, yalnızca gerekli runtime bileşenlerini içeren nihai imajlar oluşturulabilir, bu da dağıtım boru hatlarını daha verimli hale getirir. Tek bir monorepo değişikliği, ilgili tüm servislerin otomatik olarak test edilmesini ve dağıtılmasını tetikleyebilir, bu da teslimat sürelerini kısaltır ve yazılımın pazara daha hızlı ulaşmasını sağlar.

Adım Adım Uygulama: Deno ve pnpm Workspace İçin Dockerfile Nasıl Oluşturulur?

Bu bölümde, Deno ve pnpm workspace yapınızı bir Docker imajına dönüştürmek için pratik adımları ele alacağız. Bir Dockerfile’ın nasıl oluşturulacağını, multi-stage build prensiplerini ve docker-compose.yml ile çoklu servisleri nasıl yöneteceğinizi örneklerle göstereceğiz. Bu adımlar, projenizin güvenli, performanslı ve tutarlı bir şekilde konteynerize edilmesini sağlayacaktır.

Örnek Bir pnpm Workspace Yapısı Oluşturma

Başlamadan önce, bir Deno ve pnpm monorepo yapısına sahip olduğunuzu varsayalım. Tipik bir pnpm workspace, kök dizinde bir package.json ve bir pnpm-workspace.yaml dosyası içerir. packages/ dizini altında ise bağımsız Deno uygulamalarınız veya kütüphaneleriniz bulunur.

Örnek bir proje yapısı şöyle görünebilir:

    my-deno-monorepo/
    ├── package.json
    ├── pnpm-workspace.yaml
    ├── Dockerfile
    ├── packages/
    │   ├── backend/
    │   │   ├── package.json
    │   │   └── src/
    │   │       └── main.ts
    │   └── common-lib/
    │       ├── package.json
    │       └── src/
    │           └── utils.ts
    └── .dockerignore
  

pnpm-workspace.yaml dosyasının içeriği, pnpm'e hangi dizinlerin workspace üyeleri olduğunu bildirir:

    packages:
      - 'packages/*'
  

Kök package.json dosyası, genellikle workspace genelindeki komutları veya bağımlılıkları barındırır. Örneğin:

    {
      "name": "deno-monorepo-root",
      "version": "1.0.0",
      "private": true,
      "scripts": {
        "start:backend": "pnpm --filter backend start"
      }
    }
  

Her bir alt proje (örneğin packages/backend), kendi package.json dosyasına sahip olabilir ve Deno komutlarını scripts bölümünde tanımlayabilir. Örneğin, packages/backend/package.json içinde:

    {
      "name": "backend",
      "version": "1.0.0",
      "type": "module",
      "scripts": {
        "start": "deno run --allow-net --allow-env src/main.ts",
        "dev": "deno run --watch --allow-net --allow-env src/main.ts"
      },
      "dependencies": {
        "oak": "^12.0.0"
      },
      "devDependencies": {
        "@deno/types": "^0.160.0"
      }
    }
  

Dockerfile Hazırlığı: Multi-Stage Build Yaklaşımı

Optimize edilmiş bir Docker imajı oluşturmak için multi-stage build (çok aşamalı derleme) yaklaşımını kullanmak en iyi yöntemdir. Bu, imaj boyutunu küçültür ve gereksiz araçların üretim imajına dahil edilmesini engeller. Temel olarak, bir aşamada tüm bağımlılıklar yüklenir ve uygulama derlenir (varsa), ikinci aşamada ise sadece uygulamanın çalışması için gerekli olan minimum bileşenler kopyalanır.

Adım 1: Builder Aşaması (Bağımlılık Yükleme ve Derleme)

Bu aşamada, Deno çalışma zamanını ve pnpm'i kurup, workspace bağımlılıklarını yükleyeceğiz.

    # Stage 1: Bağımlılıkları yükle ve uygulamayı derle (build)
    FROM denoland/deno:1.x.x AS builder

    WORKDIR /app

    # pnpm'i global olarak kur
    # Deno imajlarında npm/node varsayılan olarak gelmeyebilir, bu nedenle önce npm'i kurmanız gerekebilir.
    # Alternatif olarak, Deno'nun entegre bağımlılık yönetimini kullanabilirsiniz.
    # Eğer Deno sadece bir çalışma zamanı olarak kullanılacaksa, pnpm adımı atlanabilir
    # ve sadece Deno bağımlılıkları (deps.ts) kullanılarak build yapılabilir.
    # Ancak burada pnpm workspace örneği için kurulumu gösterelim:
    RUN apt-get update && apt-get install -y curl && \
        curl -fsSL https://get.pnpm.io/install.sh | sh - && \
        pnpm setup && \
        # pnpm'in PATH'e eklenmesi için kabuk yeniden başlatma veya PATH'i elle ayarlama
        export PATH="$PATH:/root/.local/share/pnpm" # pnpm'in tipik kurulum yolu

    # pnpm-lock.yaml, package.json ve workspace dosyalarını kopyala
    COPY package.json pnpm-lock.yaml ./
    COPY pnpm-workspace.yaml ./
    COPY packages/ packages/ # Monorepo yapısındaki alt projeler

    # Bağımlılıkları yükle. --frozen-lockfile deterministik build'ler için önemlidir.
    # --prod sadece production bağımlılıklarını yükler, dev bağımlılıklarını atlar.
    RUN pnpm install --frozen-lockfile --prod

    # Derleme adımı (eğer Deno uygulamanızın bir derleme süreci varsa)
    # Deno uygulamaları genellikle derlenmez, doğrudan .ts veya .js dosyaları çalıştırılır.
    # Ancak bazı senaryolarda deno compile kullanılabilir:
    # RUN deno compile --allow-net --output my-app packages/backend/src/main.ts
  

Adım 2: Çalışma Zamanı Aşaması (Final İmaj)

Bu aşamada, önceki aşamadan gerekli dosyaları kopyalayarak minimal bir üretim imajı oluşturacağız.

    # Stage 2: Minimal bir runtime imajı oluştur
    FROM denoland/deno:1.x.x-slim

    WORKDIR /app

    # Builder aşamasından bağımlılıkları ve uygulama kodunu kopyala
    # Eğer deno compile kullandıysanız:
    # COPY --from=builder /app/my-app ./my-app
    # ENTRYPOINT ["./my-app"]

    # Eğer doğrudan Deno CLI ile çalıştıracaksanız (tipik Deno yaklaşımı):
    COPY --from=builder /app ./

    # Uygulamanın giriş noktasını belirtin
    # Örnek: packages/backend/src/main.ts
    # --allow-net gibi izinleri burada belirtmek önemlidir.
    CMD ["deno", "run", "--allow-net", "--allow-env", "packages/backend/src/main.ts"]

    # Uygulamanın dinleyeceği portu aç
    EXPOSE 8000
  

docker-compose.yml ile Orchestration ve Geliştirme Ortamı Yönetimi

Tek bir monorepo içinde birden fazla Deno servisini yönetiyorsanız veya veritabanı gibi ek servislerle çalışıyorsanız, docker-compose.yml dosyası kullanışlı olacaktır. Bu dosya, tüm servislerinizi tek bir komutla ayağa kaldırmanıza olanak tanır.

Örnek bir docker-compose.yml dosyası:

    version: '3.8'
    services:
      backend:
        build:
          context: .
          dockerfile: Dockerfile
        ports:
          - "8000:8000"
        # Geliştirme sırasında kod değişikliklerini otomatik yansıtmak için bind mount kullanabilirsiniz.
        # Üretim ortamında genellikle bu tercih edilmez.
        volumes:
          - .:/app
        environment:
          DENO_ENV: development
        command: deno run --allow-net --allow-env --watch packages/backend/src/main.ts # Geliştirme için --watch kullanın
        restart: always # Hata durumunda servisi yeniden başlat

      # Eğer başka bir servisiniz varsa (örneğin bir veritabanı):
      # postgres:
      #   image: postgres:13
      #   environment:
      #     POSTGRES_DB: mydatabase
      #     POSTGRES_USER: user
      #     POSTGRES_PASSWORD: password
      #   ports:
      #     - "5432:5432"
    

Bu docker-compose.yml dosyasını kullanarak, terminalinizde docker-compose up --build komutunu çalıştırarak tüm Deno uygulamanızı ve ilgili servislerinizi kolayca oluşturup başlatabilirsiniz. Geliştirme sırasında volumes kullanımı, yerel kodunuzda yaptığınız değişikliklerin konteyner içinde anında yansımasını sağlar, bu da geliştirme döngüsünü hızlandırır.

Performans ve Güvenlik Optimizasyonları: Docker İmajlarınızı Nasıl İyileştirirsiniz?

Sadece bir Dockerfile oluşturmak yeterli değildir; imajlarınızın mümkün olduğunca optimize edilmiş, küçük ve güvenli olduğundan emin olmak için ek adımlar atmanız gerekir. Bu bölümde, Deno ve pnpm ile oluşturduğunuz Docker imajlarının performansını ve güvenliğini artırmak için uygulayabileceğiniz stratejileri ve en iyi uygulamaları ele alacağız. Bu optimizasyonlar, daha hızlı dağıtım, daha az kaynak tüketimi ve daha sağlam uygulamalar anlamına gelir.

Multi-Stage Build'in Gücü: Neden Kullanmalıyız?

Daha önce de bahsettiğimiz gibi, multi-stage build (çok aşamalı derleme), Docker imajlarını optimize etmenin en etkili yollarından biridir. Bu teknik, bir Dockerfile içinde birden fazla FROM ifadesi kullanarak farklı aşamalar tanımlamanızı sağlar. İlk aşamalar (genellikle "builder" aşamaları), bağımlılıkları yüklemek, kodu derlemek veya testleri çalıştırmak gibi işlemleri gerçekleştirmek için gerekli tüm araçları ve kaynakları içerir. Daha sonraki aşamalar (genellikle "runtime" veya "final" aşamaları) ise, yalnızca uygulamanın çalışması için kesinlikle gerekli olan bileşenleri ve nihai çıktıyı önceki aşamalardan kopyalar.

Bu yaklaşımın temel avantajları şunlardır:

• Küçük İmaj Boyutları: Geliştirme veya derleme araçları (örneğin, tam bir Node.js paketi, pnpm'in kendisi, linterlar, test çerçeveleri) üretim imajına dahil edilmez. Bu, nihai imajın boyutunu önemli ölçüde küçültür. Daha küçük imajlar, depolama alanından tasarruf sağlar, ağ üzerinden daha hızlı aktarılır ve daha hızlı başlatılır.
• Gelişmiş Güvenlik: Üretim imajında gereksiz araçların ve bağımlılıkların bulunmaması, potansiyel güvenlik açıklarının yüzeyini azaltır. Daha az yazılım bileşeni, daha az güvenlik açığı anlamına gelir.
• Daha Hızlı Build Süreleri (Cache Kullanımıyla): Docker, her RUN komutunu ayrı bir katman olarak önbelleğe alır. Multi-stage build'lerde, bağımlılık yükleme ve derleme aşamaları ayrı katmanlarda tutulduğu için, kodunuz değiştiğinde sadece değişen katmanlar yeniden derlenir, bu da sonraki build'leri hızlandırır.

Deno ve pnpm ile multi-stage build, özellikle pnpm'in paylaşımlı deposunun avantajlarından yararlanarak, bağımlılık yükleme adımını daha verimli hale getirir.

Minimum Bağımlılık Prensibi ve Deno İzin Modeli

Üretim ortamındaki Docker imajlarında "minimum bağımlılık prensibi"ni uygulamak, performansı ve güvenliği artırmanın temelidir. Bu, imajınıza yalnızca uygulamanın çalışması için kesinlikle gerekli olan her şeyi dahil etmek anlamına gelir.

• Deno'nun İzin Modeli: Deno'nun güvenlik modeli, uygulamanın çalışması için gereken izinleri açıkça tanımlamanızı gerektirir (örneğin, --allow-net, --allow-read, --allow-env). Bu izinleri Dockerfile'ınızdaki CMD veya ENTRYPOINT komutlarında belirtmek, uygulamanızın konteyner içinde bile sadece belirli operasyonları gerçekleştirmesini sağlar. Bu, yetkisiz erişim veya kötü amaçlı kod çalıştırma riskini minimuma indirir. Örneğin, bir API servisi sadece ağ erişimine ihtiyaç duyuyorsa, dosya yazma izni vermemeniz güvenliği artırır.
• Sadece Üretim Bağımlılıkları: pnpm kullanırken, pnpm install --prod --frozen-lockfile gibi komutlar, sadece üretim bağımlılıklarının yüklenmesini sağlar. Geliştirme veya test bağımlılıkları (dev-dependencies) üretim imajına dahil edilmez, bu da imaj boyutunu daha da küçültür.

.dockerignore Dosyası ve Katman Önbellekleme Optimizasyonu

.dockerignore dosyası, Docker'ın bağlam (context) dizinini imaj oluştururken taramasını engelleyecek dosya ve dizinleri belirtmek için kullanılır. Bu dosya, gereksiz dosyaların (örneğin, .git dizini, node_modules (eğer bir builder aşamasında oluşturuluyorsa), geçici dosyalar, editör ayarları) Docker build bağlamına kopyalanmasını engeller. Bu sayede:

• Daha Hızlı Build Süreleri: Daha az dosya, Docker daemon'a daha hızlı gönderilir.
• Küçük İmaj Boyutları: Gereksiz dosyaların imaja dahil edilmesi engellenir.

Örnek bir .dockerignore dosyası:

    node_modules/
    .git/
    .vscode/
    tmp/
    *.log
    *.env
    dist/ # Eğer build çıktısı bu dizindeyse ve sadece final aşamasına kopyalayacaksanız
  

Katman Önbellekleme Optimizasyonu: Docker, Dockerfile'daki her komutu ayrı bir katman olarak önbelleğe alır. Bir komut veya onun bağımlılıkları değişmediği sürece, Docker önbelleğe alınmış katmanı kullanır. Bu özelliği etkin bir şekilde kullanmak için:

1. Değişme Olasılığı En Az Olanı Önce Kopyala: package.json, pnpm-lock.yaml ve pnpm-workspace.yaml gibi bağımlılık tanımlayıcı dosyalar, uygulama kodundan daha az sıklıkla değişir. Bu dosyaları Dockerfile'ın başlarında kopyalayıp bağımlılık yükleme komutunu (pnpm install) hemen ardından çalıştırmak, bağımlılıklar değişmediğinde bu katmanın önbellekten kullanılmasını sağlar.
2. Uygulama Kodunu En Son Kopyala: Uygulama kodunuz sık sık değiştiği için, onu mümkün olduğunca sona bırakmak, her kod değişikliğinde tüm katmanların yeniden derlenmesini engeller.

Bu stratejilerle, Deno ve pnpm tabanlı Docker imajlarınız daha hızlı oluşturulacak ve daha verimli çalışacaktır.

Gerçek Dünya Senaryoları: Monorepo Docker İmajları ile Ölçeklenebilirlik

Deno ve pnpm workspace'ini Docker ile birleştirmek, özellikle ölçeklenebilirlik ve yönetilebilirlik gerektiren gerçek dünya senaryolarında büyük faydalar sağlar. Bu bölümde, bu entegrasyonun mikroservis mimarilerinde ve CI/CD süreçlerinde nasıl kullanılabileceğini ve büyük bir e-ticaret platformunda nasıl başarıyla uygulandığına dair bir vaka analizini ele alacağız.

Mikroservis Mimarilerinde Deno ve pnpm Workspace Yönetimi

Mikroservis mimarileri, büyük ve karmaşık uygulamaları daha küçük, bağımsız ve yönetilebilir hizmetlere bölme prensibine dayanır. Her bir mikroservis kendi başına geliştirilebilir, dağıtılabilir ve ölçeklendirilebilir. Deno ve pnpm workspace'i bu mimari için doğal bir uyum sağlar:

• Her Servis Kendi Docker İmajı: Bir monorepo içindeki her Deno mikroservisi (örneğin, packages/auth-service, packages/product-service), kendi Dockerfile'ına sahip olabilir. Bu Dockerfile, yalnızca o servisin bağımlılıklarını ve kodunu içeren minimal bir imaj oluşturur. Bu, servislerin birbirinden bağımsız olarak güncellenmesine ve ölçeklenmesine olanak tanır. Örneğin, bir servis yoğun trafik alırken diğerleri daha az kaynak tüketebilir.
• Paylaşımlı Kütüphaneler: Monorepo'daki packages/common-lib gibi paylaşımlı kütüphaneler, farklı servisler arasında kod tekrarını önler. pnpm workspace, bu paylaşımlı bağımlılıkların tüm servisler tarafından verimli bir şekilde kullanılmasını sağlar. Docker imajları oluşturulurken, bu ortak bağımlılıklar da doğru bir şekilde resolver edilir.
• Docker Compose ile Geliştirme: Geliştirme ortamında, docker-compose.yml dosyası birden fazla Deno servisini ve diğer bağımlı servisleri (veritabanları, mesaj kuyrukları vb.) tek bir komutla ayağa kaldırmak için kullanılabilir. Bu, geliştiricilerin tüm ekosistemi yerel olarak kolayca test etmelerini sağlar.

Bu yapı sayesinde, geliştirme ekipleri daha bağımsız çalışabilir, servisler arasında daha net sınırlar oluşturulur ve uygulamanın genel hata toleransı artırılır. Bir servisteki sorun, diğer servisleri etkilemez.

CI/CD Süreçlerine Entegrasyon ve Otomatik Dağıtım

Sürekli Entegrasyon (CI) ve Sürekli Dağıtım (CD) boru hatları, modern yazılım geliştirmenin ayrılmaz bir parçasıdır. Deno, pnpm ve Docker entegrasyonu, bu süreçleri daha verimli ve güvenilir hale getirir:

• Otomatik Build ve Test: Bir kod değişikliği (commit), CI sistemini (örneğin GitHub Actions, GitLab CI, Jenkins) tetikler. CI, pnpm workspace'i içeren Docker imajını oluşturur, bağımlılıkları yükler ve Deno testlerini çalıştırır. Multi-stage build ve katman önbellekleme sayesinde bu süreç hızlıdır.
• Güvenli ve Hızlı İmaj Oluşturma: Başarılı testlerden sonra, CI boru hattı üretim için optimize edilmiş Docker imajını (multi-stage build'in son aşaması) oluşturur ve bir konteyner kayıt defterine (örneğin Docker Hub, AWS ECR) iter. Küçük imaj boyutları, bu push işlemini hızlandırır.
• Otomatik Dağıtım: CD aşaması, yeni oluşturulan imajı test, hazırlık veya üretim ortamlarına otomatik olarak dağıtır. Kubernetes gibi konteyner orkestrasyon araçları, yeni imajları çeker ve mevcut uygulamayı kesinti olmadan günceller. Deno'nun güvenlik modeli ve Docker'ın izolasyonu sayesinde dağıtım daha güvenlidir.
• Değişiklik Algılama: Akıllı CI/CD yapılandırmaları, monorepo içinde yalnızca değişen projelere ait Docker imajlarının yeniden oluşturulmasını ve dağıtılmasını sağlayabilir. Bu, gereksiz build ve deploy işlemlerini önleyerek kaynakları verimli kullanır.

Bu entegrasyon, yazılım teslimatını hızlandırır, insan hatasını azaltır ve geliştiricilerin daha çok değer yaratmaya odaklanmasını sağlar.

Vaka Analizi: Büyük Bir E-ticaret Platformunda Entegrasyon

Bir e-ticaret platformunun, hızla büyüyen müşteri tabanına hizmet verebilmek için mevcut Node.js tabanlı mikroservis mimarisini Deno ve pnpm workspace'ine taşıma kararı aldığını varsayalım. Platformun, ürün katalog yönetimi, kullanıcı kimlik doğrulama, sipariş işleme ve ödeme ağ geçitleri gibi birçok bağımsız servisi bulunuyordu.

Mevcut Durumun Zorlukları:

• Farklı Node.js versiyonları ve bağımlılık yönetimi sorunları her serviste ayrı ayrı yönetiliyordu.
• node_modules dizinlerinin şişkinliği, CI/CD süreçlerinde uzun build sürelerine ve büyük Docker imajlarına neden oluyordu.
• Güvenlik izinlerinin kontrolü zordu, çünkü Node.js varsayılan olarak tüm izinlere sahipti.

Deno, pnpm ve Docker ile Dönüşüm:

1. Monorepo'ya Geçiş: Tüm mikroservisler ve paylaşımlı kütüphaneler tek bir pnpm workspace monorepo'suna taşındı. packages/ altında her bir servis ve kütüphane kendi Deno projesi olarak konumlandırıldı.
2. Deno'ya Migrasyon: Her servis Deno'ya taşındı ve TypeScript'in yerel desteği kullanıldı. Deno'nun modül sistemi ve web standartlarına uygun API'leri sayesinde kod tabanı daha modern ve okunabilir hale geldi.
3. Docker Entegrasyonu: Her Deno servisi için optimize edilmiş, multi-stage Dockerfile'lar yazıldı. pnpm'in verimli bağımlılık yönetimi sayesinde, pnpm install --frozen-lockfile --prod komutları Docker build sürecinin önemli bir parçası oldu.
4. Güvenlik İyileştirmeleri: Her servisin Dockerfile'ında Deno'nun --allow-net, --allow-read gibi izinleri ince ayarlandı. Örneğin, ödeme servisi sadece ağ ve belirli ortam değişkenlerine erişim iznine sahipken, dosya sistemine yazma izni verilmedi.
5. CI/CD İyileştirmeleri: GitHub Actions, monorepo içindeki değişiklikleri akıllıca algılayacak şekilde yapılandırıldı. Sadece etkilenen servislerin testleri çalıştırıldı, Docker imajları yeniden oluşturuldu ve Kubernetes ortamına dağıtıldı.

Elde Edilen Faydalar:

• %40 Daha Küçük İmaj Boyutları: Gereksiz bağımlılıkların ve derleme araçlarının kaldırılmasıyla imaj boyutları önemli ölçüde küçüldü.
• %30 Daha Hızlı Build Süreleri: pnpm'in cache'leme yeteneği ve Docker katman önbellekleme optimizasyonları sayesinde build süreleri kısaldı.
• Gelişmiş Güvenlik: Deno'nun izin modeli ve minimalist runtime, platformun genel güvenlik duruşunu güçlendirdi.
• Artan Geliştirici Verimliliği: Monorepo ve Docker Compose sayesinde yeni geliştiricilerin sisteme katılımı hızlandı, kod paylaşımı kolaylaştı.
• Daha Hızlı Dağıtım: Otomatik CI/CD ve küçük imajlar, yeni özelliklerin ve hata düzeltmelerinin müşterilere daha hızlı ulaşmasını sağladı.

Bu vaka analizi, Deno, pnpm ve Docker entegrasyonunun, ölçeklenen ve kritik öneme sahip uygulamalar için nasıl güçlü, verimli ve güvenli bir çözüm sunduğunu açıkça göstermektedir.

İleri Düzey İpuçları ve Püf Noktaları: Docker ve Deno'dan Daha Fazlasını Nasıl Alırsınız?

Temel Dockerfile kurulumunun ötesine geçerek, Deno ve pnpm workspace'inizi içeren Docker imajlarınızdan en yüksek performansı ve esnekliği elde etmek için bazı ileri düzey ipuçları ve püf noktaları bulunmaktadır. Bu bölüm, deneyimli kullanıcılar için pratik öneriler sunarak, geliştirme ve üretim ortamlarınızı daha da optimize etmenize yardımcı olacaktır.

Deno Modül Önbellekleme ve Performans Optimizasyonları

Deno, modülleri ilk çalıştığında internetten indirir ve yerel bir önbellekte saklar. Bu önbellekleme mekanizmasını Docker bağlamında verimli kullanmak, build sürelerini önemli ölçüde hızlandırabilir:

• DENO_DIR Ortam Değişkeni: Deno'nun modül önbelleğini sakladığı dizini (~/.deno) değiştirmek için DENO_DIR ortam değişkenini kullanabilirsiniz. Dockerfile'da bu dizini ayarlayarak ve bu dizini ayrı bir katmanda önbelleğe alarak, bağımlılıklar değişmediği sürece modüllerin tekrar indirilmesini engelleyebilirsiniz.

    # Dockerfile'da builder aşamasında
    FROM denoland/deno:1.x.x AS builder

    WORKDIR /app

    ENV DENO_DIR=/deno-cache

    # Önbellek dizinini oluştur ve sahipliğini ayarla (Deno'nun çalışacağı kullanıcı)
    RUN mkdir -p ${DENO_DIR} && chown deno:deno ${DENO_DIR}

    # Bağımlılıkları içeren tüm .ts veya .js dosyalarını kopyala (sadece import'ları resolve etmek için yeterli olanları)
    # Örneğin, tüm projelerin deps.ts dosyaları veya ana giriş noktaları
    COPY packages/backend/src/deps.ts packages/backend/src/
    # Diğer servisler için de benzer şekilde
    COPY packages/common-lib/src/mod.ts packages/common-lib/src/

    # Deno'nun bağımlılıkları indirmesini ve önbelleğe almasını sağla
    # Bu adım, sadece modüllerin indirileceği ve cache'leneceği bir "deno check" veya "deno cache" komutu olabilir.
    # --quiet ve --reload sadece ilk build için veya zorunlu güncellemeler için kullanılabilir.
    RUN deno cache --quiet packages/backend/src/deps.ts && \
        deno cache --quiet packages/common-lib/src/mod.ts
    # ... daha sonra pnpm install ve diğer adımlar devam eder ...

    # Final aşamasında önbelleği kopyala
    FROM denoland/deno:1.x.x-slim
    WORKDIR /app
    ENV DENO_DIR=/deno-cache
    COPY --from=builder ${DENO_DIR} ${DENO_DIR}
    # ... diğer uygulama kodu kopyalama ve çalıştırma ...
  

Bu strateji, özellikle Deno'nun dış modüllerini yoğun olarak kullanan projelerde build süresini önemli ölçüde azaltır.

deno compile Kullanımı vs. deno run

Çoğu Deno uygulaması doğrudan deno run komutuyla çalıştırılır. Ancak, deno compile komutu, uygulamanızı tek bir bağımsız yürütülebilir dosyaya derlemenize olanak tanır. Bu, özellikle minimal Docker imajları oluşturmak ve Deno runtime'ını bile içermeyen "scratch" tabanlı imajlar elde etmek için faydalı olabilir.

• deno run: Esneklik ve hızlı geliştirme döngüsü sağlar. Kod değişiklikleri anında yansıtılabilir (--watch ile). Daha çok geliştirme ve bazı üretim senaryolarında tercih edilir. Final Docker imajı Deno runtime'ını içermelidir.
• deno compile: Üretim için daha küçük, tamamen bağımsız ikili dosyalar oluşturur. Deno runtime'ı gerektirmez, bu da imaj boyutunu daha da küçültür. Daha hızlı başlatma süresi sunabilir.

Eğer deno compile kullanıyorsanız, Dockerfile'ınızın son aşaması bir scratch imajına dayanabilir ve sadece derlenmiş ikili dosyayı kopyalayabilir:

    # Builder aşamasında (önceki örnekten devam)
    # ... pnpm install ve diğer bağımlılık adımları ...
    RUN deno compile --allow-net --allow-env --output my-backend-app packages/backend/src/main.ts

    # Stage 2: Minimal bir scratch imajı oluştur
    FROM scratch
    WORKDIR /app
    COPY --from=builder /app/my-backend-app ./my-backend-app
    # Eğer uygulamanızın bazı sertifikalara veya sistem kütüphanelerine ihtiyacı varsa
    # FROM alpine:latest gibi daha küçük bir base image kullanabilirsiniz.
    # Örneğin, eğer sertifika gereksinimi varsa:
    # FROM alpine:latest
    # RUN apk add --no-cache ca-certificates
    # COPY --from=builder /app/my-backend-app ./my-backend-app

    ENTRYPOINT ["./my-backend-app"]
    EXPOSE 8000
  

Docker Build Argümanları ve Ortam Değişkenleri

Docker build argümanları (ARG) ve ortam değişkenleri (ENV), Docker imajlarınızı daha esnek hale getirmenizi sağlar.

• ARG (Build-Time Variables): Dockerfile içinde tanımlanır ve docker build komutuyla değer atanır (--build-arg). Örneğin, Deno veya pnpm versiyonlarını dinamik olarak belirlemek için kullanılabilir.

  
          ARG DENO_VERSION=1.x.x
          FROM denoland/deno:${DENO_VERSION} AS builder
        

• ENV (Run-Time Variables): İmaj içinde tanımlanır ve konteyner çalışırken ortam değişkeni olarak mevcuttur. Hassas bilgiler (API anahtarları, veritabanı şifreleri) için docker run -e veya docker-compose.yml kullanmak daha güvenlidir, Dockerfile içine doğrudan yazmaktan kaçının.

Geliştirme Ortamı Optimizasyonları (Bind Mounts) ve Hata Ayıklama

Yerel geliştirme ortamında Docker kullanırken, kodunuzdaki değişiklikleri hızlıca görmek istersiniz. volumes özelliğini kullanarak (bind mounts), yerel dosya sisteminizdeki kodu doğrudan konteyner içine bağlayabilirsiniz:

    # docker-compose.yml içinde
    services:
      backend:
        # ...
        volumes:
          - .:/app # Yerel dizini /app konteyner dizinine bağla
        command: deno run --watch --allow-net --allow-env packages/backend/src/main.ts
  

Bu, yerel kodunuzu değiştirdiğinizde, Deno uygulamasının otomatik olarak yeniden yüklenmesini (--watch sayesinde) ve değişiklikleri görmenizi sağlar.

Deno Debugger ile Hata Ayıklama: Deno, yerleşik bir hata ayıklama protokolüne sahiptir (Chrome DevTools uyumlu). Docker konteyneri içinde çalışan bir Deno uygulamasında hata ayıklamak için, Deno uygulamasını --inspect-brk veya --inspect bayrağıyla çalıştırmanız ve ilgili hata ayıklama portunu Docker portlarını açarken yayımlamanız gerekir.

    # docker-compose.yml içinde hata ayıklama için
    services:
      backend:
        # ...
        ports:
          - "8000:8000"
          - "9229:9229" # Deno debug portunu yayımla
        command: deno run --inspect-brk=0.0.0.0:9229 --allow-net --allow-env packages/backend/src/main.ts
  

Daha sonra tarayıcınızdan chrome://inspect adresine giderek veya VS Code gibi bir IDE'nin Deno hata ayıklama uzantısını kullanarak konteynerdeki uygulamanıza bağlanıp hata ayıklama yapabilirsiniz.

Mobil Uyumlu HTML ve CSS İpuçları (Deno ile Frontend Geliştiriyorsanız)

Eğer Deno ile bir web servisi veya sunucu tarafında işlenen bir UI (SSR - Server Side Rendering) geliştiriyorsanız, çıktınızın mobil uyumlu olması önemlidir. Docker imajınız doğrudan bu HTML/CSS'i üretmese de, bu yapıların Docker imajına nasıl dahil edileceği ve çıktının mobil cihazlarda düzgün görünmesi için yapılabilecekler şunlardır:

• Meta Viewport Etiketi: HTML başlığınıza ekleyerek sayfanızın cihaz genişliğine uygun ölçeklenmesini sağlayın.
• Duyarlı Tasarım (Responsive Design) İçin CSS Media Queries: CSS'inizi farklı ekran boyutlarına göre uyarlamak için @media kurallarını kullanın.

  
          /* Varsayılan stil (mobil cihazlar için önce) */
          .container {
            width: 100%;
            padding: 10px;
          }
  
          /* Tabletler ve daha büyük cihazlar için (örneğin 768px üzeri) */
          @media (min-width: 768px) {
            .container {
              width: 70%;
              margin: 0 auto;
              padding: 20px;
            }
          }
  
          /* Masaüstü ve daha büyük cihazlar için (örneğin 1024px üzeri) */
          @media (min-width: 1024px) {
            .container {
              width: 50%;
              max-width: 1200px;
            }
          }
        

• Esnek Birimler (Flexible Units): px yerine em, rem, % veya vw/vh gibi göreceli birimler kullanmak, içeriğin farklı ekran boyutlarına daha iyi uyum sağlamasına yardımcı olur.
• Resim Optimizasyonu: Duyarlı resimler için etiketi veya srcset özniteliği kullanın. WebP gibi modern formatları tercih edin.

Bu ipuçları, Deno ile geliştirdiğiniz web uygulamalarının Docker konteynerleri içinde sorunsuz çalışmasının yanı sıra, kullanıcılara cihazdan bağımsız olarak iyi bir deneyim sunmasını sağlar.

Deno ve pnpm ile Geleceğin Konteynerize Uygulamalarını İnşa Etmek

Bu makale boyunca, Deno'nun modern çalışma zamanı yetenekleri, pnpm'in verimli bağımlılık yönetimi ve Docker'ın güçlü konteynerleştirme platformunun bir araya geldiğinde nasıl bir sinerji oluşturduğunu detaylıca inceledik. Monorepo yapılarını, multi-stage Dockerfile'ları ve çeşitli optimizasyon tekniklerini kullanarak, geliştirme süreçlerinizi hızlandırırken, dağıtılabilir uygulamalarınızın performansını, güvenliğini ve tutarlılığını nasıl artırabileceğinizi gördük. Bu entegrasyon, özellikle mikroservis mimarileri ve otomatik CI/CD boru hatları için vazgeçilmez bir yaklaşım sunmaktadır.

Artık Deno ve pnpm workspace'inizi Docker imajlarına taşıma konusunda kapsamlı bir bilgi birikimine sahipsiniz. Unutmayın ki yazılım geliştirme sürekli bir öğrenme ve adaptasyon sürecidir. Bu teknolojileri projelerinizde uygularken, kendi özel ihtiyaçlarınıza en uygun yapılandırmaları ve optimizasyonları keşfetmek için denemeler yapmaktan çekinmeyin. Daha küçük imajlar, daha hızlı dağıtımlar, artan güvenlik ve tutarlı geliştirme ortamları ile geleceğin bulut tabanlı uygulamalarını inşa etmeye hazırsınız. Bu güçlü kombinasyon, geliştiricilere daha az altyapı endişesiyle daha fazla değer yaratma özgürlüğü sunar.

Sıkça Sorulan Sorular

Neden pnpm yerine npm veya yarn kullanmamalıyım?

pnpm, disk alanından tasarruf, daha hızlı kurulum süreleri ve daha sıkı bir node_modules yapısı sunarak bağımlılık yönetiminde önemli avantajlar sağlar. Özellikle monorepo'larda, aynı bağımlılıkların birden fazla kopyasının indirilmesini ve depolanmasını engeller. npm ve yarn da iyi paket yöneticileri olsa da, pnpm'in bu benzersiz özellikleri onu büyük projeler ve konteynerize edilmiş ortamlar için daha cazip bir seçenek haline getirir.

Deno'nun Docker imaj boyutu NodeJS'ten daha mı küçük?

Evet, genellikle daha küçüktür. Deno'nun kendisi tek bir ikili dosya olarak geldiği ve karmaşık bir node_modules yapısına ihtiyaç duymadığı için, Deno tabanlı Docker imajları NodeJS tabanlı imajlara göre daha minimalist olma eğilimindedir. Özellikle denoland/deno:1.x.x-slim gibi minimal Deno base imajları kullanıldığında veya deno compile ile bağımsız bir ikili dosya oluşturulduğunda, boyut avantajı daha da belirginleşir.

Monorepo yapısında birden fazla Deno servisi nasıl yönetilir?

Monorepo'da her Deno servisi kendi alt dizininde (örneğin, packages/backend, packages/frontend-ssr) bulunur. Her servis için ayrı bir Dockerfile oluşturulur veya tek bir kök Dockerfile, build argümanları ile hangi servisin derleneceğini/çalıştırılacağını belirtecek şekilde yapılandırılabilir. docker-compose.yml dosyası, tüm servisleri (her biri kendi Docker imajından) tek bir komutla ayağa kaldırmak ve aralarındaki iletişimi yönetmek için idealdir. pnpm'in workspace özellikleri, servisler arası bağımlılık yönetimini basitleştirir.

Dockerize edilmiş Deno uygulamasında hata ayıklama nasıl yapılır?

Deno uygulamanızı Docker konteyneri içinde --inspect-brk=0.0.0.0:9229 (veya sadece --inspect üretim için) bayrağıyla çalıştırın. docker-compose.yml dosyanızda ports: - "9229:9229" satırını ekleyerek hata ayıklama portunu yayımlayın. Ardından, bir Chrome tarayıcısında chrome://inspect adresine giderek veya VS Code gibi bir IDE'nin Deno hata ayıklama uzantısını kullanarak çalışan konteynerdeki Deno sürecine bağlanabilirsiniz.

Üretim ortamı için nelere dikkat etmeliyim?

Üretim ortamı için Docker imajlarınızı oluştururken şu noktalara dikkat etmelisiniz:

1. Multi-stage build kullanın: Sadece uygulamanın çalışması için gerekli olanları içeren minimal imajlar oluşturun.
2. Deno izin modelini uygulayın: Uygulamanızın sadece ihtiyaç duyduğu izinleri (--allow-net, --allow-read vb.) verin.
3. pnpm install --prod --frozen-lockfile kullanın: Sadece üretim bağımlılıklarını yükleyin ve deterministik build'ler sağlayın.
4. Güvenli base imajlar kullanın: Resmi Deno slim imajlarını veya Alpine gibi minimal imajları tercih edin.
5. Hassas bilgileri ortam değişkenleriyle yönetin: API anahtarları gibi kritik verileri Dockerfile'da depolamayın, docker secrets veya Kubernetes secrets gibi çözümler kullanın.
6. Sağlık kontrolleri ekleyin: HEALTHCHECK talimatını Dockerfile'ınıza ekleyerek konteynerinizin düzgün çalışıp çalışmadığını izleyin.
7. Kaynak limitleri belirleyin: Konteynerler için CPU ve bellek limitleri belirleyerek kaynak tüketimini kontrol altında tutun.