--- id: e62d78ef5850c982dbddc9d3ff9134ae author: Lemon Mint title: 'gvx: Linux Containers, Docker ve Kubernetes''i Tek Bir Unprivileged Process İçinde Çalıştırma' description: gvx, Linux konteynerlerini, Docker-in-Docker ortamlarını ve çok düğümlü yüksek erişilebilirlikli (HA) Kubernetes kümelerini tek bir ayrıcalıksız süreç içinde güvenli biçimde çalıştıran, güvenlik açısından sertleştirilmiş, platformlar arası bir konteyner çalışma zamanı ve Go SDK'sı olup Windows, macOS ve Linux üzerinde gVisor kullanıcı alanı çekirdeği üzerine inşa edilmiştir; bu belgede gvx'in teknik bir genel bakışı sunulmaktadır. language: tr date: 2026-11-06T12:02:56.008516536Z path: /blog/posts/gvx-cross-platform-linux-containers-z48916d01 go_package: z.gfire.dev/gvx go_repourl: https://github.com/gfire-sigs/gvx.git category: lowlevel --- ## Giriş: Root veya Ana Makine Daemon'ı Gerektirmeden Güvenlik Sertleştirilmiş Konteynerler Bir geliştirme makinesinde, CI runner'ında veya çok kiracılı bir bulut düğümünde Linux konteynerlerini, `docker build` komutunu veya Kubernetes'i çalıştırmak genellikle rahatsız edici bir güvenlik ödünleşimine zorlar: - **Linux** üzerinde standart OCI çalışma zamanları (`runc`, `crun`, `runsc`), `root` ayrıcalıkları, ana makinedeki `/var/run/docker.sock` dosyasının açığa çıkarılması, `--privileged` (`CAP_SYS_ADMIN`) veya ana makine çekirdeğinin saldırı yüzeyini genişleten kullanıcı ad alanları (`unshare(CLONE_NEWUSER)`) gerektirir. - **Windows** ve **macOS** üzerinde konteyner motorları (`Docker Desktop`, `Podman Machine`, `Lima`, `OrbStack`), WSL2, Hyper-V veya `Virtualization.framework` içinde tam bir Linux sanal makine çekirdeği başlatır ve bu sanal makine içinde kalıcı bir arka plan daemon'ı çalıştırır. **[gvx](https://github.com/gfire-sigs/gvx)** (`rungv` CLI ve `z.gfire.dev/gvx/pkg/gvx` Go SDK), **güvenli, sıfır ayrıcalıklı bir alternatif** sunar. Google'ın **gVisor** kullanıcı alanı Linux çekirdeğinin (`Sentry`) ve kullanıcı alanı ağ yığınının (`netstack`) upstream ile izlenebilir bir çatalı olarak geliştirilen `gvx`, Windows, macOS ve Linux üzerinde değiştirilmemiş `linux/amd64` ve `linux/arm64` ELF64 ikililerini ve OCI konteynerlerini **tek bir ayrıcalıksız, kendini kilitleyen ana makine süreci** içinde doğrudan çalıştırır. > **Güvenlik Garantisi (Üç Halkalı Derinlemesine Savunma)**: `gvx` ana makine işletim sistemi güvenlik sınırlarını asla zayıflatmaz, çekirdek sürücüleri asla yüklemez ve ana makinede asla `root`, `sudo`, `--privileged` veya `CLONE_NEWUSER` gerektirmez. Tek bir konuk talimatını yürütmeden önce `gvx`, kendi ana makine sürecini Windows Restricted Tokens ve Job Objects, macOS Seatbelt (`deny default`) veya Linux `PR_SET_NO_NEW_PRIVS` ile BPF `seccomp` kullanarak kilitler. Tüm konuk sistem çağrıları, sanal `UID 0` ayrıcalıkları, bağlantılar (`VFS2`) ve ağ tabloları (`netstack`), bellek güvenli Go `Sentry` çekirdeği içinde sıkı biçimde sınırlandırılır. | Çalışma Zamanı | Ana Makine İşletim Sistemi | Soğuk Başlatma | Bellek Ayak İzi | Yönetici veya `sudo` Gerekli mi | Arka Plan VM Daemon'ı | Doğrudan OCI İmaj Çalıştırma | | :------------------------- | :---------------------------------------------------- | ---------------: | --------------: | :------------------------------ | :-------------------- | :--------------------------- | | **`gvx` (`whpx` / `hvf`)** | Windows (`amd64`, `arm64`) ve macOS (`arm64`) | `~20 ms` | `~30 MiB` | Hayır | Hayır | Evet | | **`gvx` (`systrap`)** | Windows (`amd64`, `arm64`) ve Linux (`amd64`, `arm64`) | `~25 ila 65 ms` | `~31 MiB` | Hayır | Hayır | Evet | | **WSL2 / Docker Desktop** | Windows ve macOS | `800 ila 2500 ms` | `> 512 MiB` | Evet (İlk Kurulum) | Evet | Daemon Gerektirir | | **QEMU (Tam Sistem)** | Windows ve macOS | `1500 ila 4000 ms` | `> 256 MiB` | Hayır | Hayır | Disk İmajı Gerektirir | Windows veya macOS üzerinde hiçbir Linux VM çekirdeği başlatılmaz. Ana makinede hiçbir arka plan daemon'ı çalışmaz. Ana makine işletim sistemi üzerinde `root`, `sudo`, kullanıcı ad alanları (`CLONE_NEWUSER`), `mount(2)`, `TUN`/`TAP` sürücüleri veya `CAP_NET_ADMIN` ayrıcalıkları gerekmez. Bu ayrıcalıksız süreç içinde `gvx`, **Docker-in-Docker (`docker:dind`)**, `docker build`, `docker compose` ve **çok düğümlü Yüksek Erişilebilirlikli Kubernetes (`k3s` ile gömülü `etcd` ve `Calico` CNI)** çalıştırır. --- ## Konteyner Yaşam Döngüsü ve Üç Halkalı Ana Makine Kilitlemesi Her `gvx` sandbox'ı tek bir ayrıcalıksız ana makine süreci içinde çalışır ve üç aşamalı bir yaşam döngüsü uygular: gerekli tüm ana makine dosya tanımlayıcılarını ve soketlerini önceden açmak, `pkg/hostlockdown` aracılığıyla ana makine işletim sistemi sürecini kilitlemek ve süreç içi `Sentry` yürütme döngüsüne girmek. ![gvx Konteyner Yaşam Döngüsü ve Ana Makine Öz Kilitlemesi](/assets/images/gvx/gvx-lifecycle-lockdown.png) Kontrolü ilk konuk talimatına devretmeden önce `gvx`, önbelleğe alınmış `.erofs` imaj katmanı tanımlayıcılarını, `.ext4` birim dosya tanımlayıcılarını, `/workspace` `*os.Root` tutamacını ve ana makine ağ soketlerini önceden açar, ardından `hostlockdown.Apply()` fonksiyonunu çağırır: 1. **Windows NT (`lockdown_windows.go`)**: Ayrıcalıkları yerinde kaldırmak için `SE_PRIVILEGE_REMOVED` ile `AdjustTokenPrivileges` çağırır, Low bütünlük seviyesinde (`S-1-16-4096`) bir `DISABLE_MAX_PRIVILEGE` kısıtlı taklit (impersonation) belirteci bağlar, süreci `JOB_OBJECT_LIMIT_ACTIVE_PROCESS = 1` ile anonim bir Job Object'e atar (herhangi bir alt süreç oluşturulmasını engeller) ve `SetProcessMitigationPolicy` ile `DisallowWin32kSystemCalls = 1` değerini etkinleştirir. 2. **macOS XNU (`lockdown_darwin.go`)**: `RLIMIT_NPROC = 0` değerini ayarlar ve `(version 1)(deny default)` ile başlayan, `process-fork`, `process-exec*` ve yeni tüm ana makine dosya açmalarını engelleyen bir Seatbelt profili (`sandbox_init_with_parameters`) uygular. 3. **Linux (`lockdown_linux.go` + `pkg/gvx/syscallfilter_linux.go`)**: `PR_SET_NO_NEW_PRIVS` değerini ayarlar ve `execve`, `execveat`, `clone`, `openat` ve `socket` için açık `EPERM` kuralları içeren Sentry BPF `seccomp` izin listesini tüm iş parçacıklarında (`SECCOMP_FILTER_FLAG_TSYNC`) kurar. --- ## Platformlar Arası Sistem Çağrısı Yakalama ve 4 KB Sayfalama (`pkg/sentry/platform`) Linux ELF64 ikilileri, `mmap(MAP_FIXED)` segment eşlemeleri için 4 KB (`0x1000`) bellek sayfa ayrıntı düzeyi varsayar. Ancak Windows `VirtualAlloc` ve `MapViewOfFile3` 64 KB (`0x10000`) hizalaması uygular, Apple Silicon macOS (`darwin/arm64`) ise 16 KB (`0x4000`) ana makine sayfaları kullanır. Ayrıca her işletim sistemi, bir Linux VM başlatmadan Linux `SYSCALL` (`amd64`) ve `SVC #0` (`arm64`) komutlarını yakalamak için farklı bir mekanizma gerektirir. `gvx`, `pkg/sentry/platform.Context` arayüzünü uygulayan dört yürütme arka ucunda bu iki sorunu çözer: ![gvx Platform Sistem Çağrısı Yakalama ve 4KB Sayfalama Mekanizmaları](/assets/images/gvx/gvx-platform-syscalls.png) ### 1. Windows Donanım Motoru: `platform/whpx` (`WinHvPlatform.dll`) `windows/amd64` ve `windows/arm64` üzerinde `platform/whpx`, bir konuk işletim sistemi çekirdeği başlatmadan `WHvCreatePartition` aracılığıyla hafif bir hipervizör bölümü oluşturur: - **64 KB'den 4 KB'ye Sayfalama Ayrıştırıcısı**: `whpx`, `pgalloc.MemoryFile` içindeki her 64 MiB arenayı `WHvMapGpaRange` aracılığıyla bölüme bir kez kaydeder. Sonraki `MapFile` ve `Unmap` çağrıları yalnızca bölüm içindeki konuk sayfa tablolarını değiştirir ve Windows'un 64 KB tahsis ayrıntı düzeyine rağmen tam 4 KB `R/W/X` izinlerini uygular. - **`CommPage` Üzerinden Sıfır API Kayıt Değişimi**: - `amd64` üzerinde, konuk Ring-3 `SYSCALL` komutu, bölüm içindeki bir Ring-0 `MSR_LSTAR` kesim noktasına (`stubgen_x86.go`) girer; bu kesim noktası hızlı yol sistem çağrısı GPR'lerini (`RAX, RDI, RSI, RDX, R10, R8, R9, RIP, RSP`) paylaşılan 4 KB `CommPage` alanına yazar ve `WHvRunVirtualProcessor` işleminden çıkmak için `HLT` komutunu yürütür. - `arm64` üzerinde, konuk EL0 `SVC #0` komutu EL1 vektörlerine (`stubgen_a64.go`) girer, `X0..X8, SP_EL0, ELR_EL1, PSTATE` değerlerini `CommPage` alanına yazar ve Sentry'ye bellek çıkışını tetiklemek için sıfır GPA'daki arka planı olmayan adresten yükleme yapar. ### 2. macOS Donanım Motoru: `platform/hvf` (`Hypervisor.framework`) Apple Silicon (`darwin/arm64`) üzerinde `platform/hvf`, konteyner iş parçacıklarını `Hypervisor.framework` vCPU'ları (`hv_vm_create`, `hv_vcpu_run`) içinde çalıştırır: - **Çift Aşamalı 16 KB Üzerinde 4 KB MMU Çevirisi**: Aşama 2 (`hv_vm_map`), 1 GiB bellek dosyası parçalarını Ara Fiziksel Adres (IPA) alanına bir kez, 16 KB ana makine sayfa ayrıntı düzeyinde `HV_MEMORY_READ | HV_MEMORY_WRITE | HV_MEMORY_EXEC` izinleriyle eşler. vCPU içinde EL1 `bluepill` kesim noktası (`bluepill_arm64.go`), `TTBR0_EL1` içinde `TCR_EL1.TG0 = 0b00` (4 KB granül) değerini yapılandırır ve tam `R-X` veya `RW-` (`UXN=1`) izinlerine sahip 4 KB Aşama 1 sayfa tablosu girişlerini doldurur. ARM64 MMU, Aşama 1 ve Aşama 2 izinlerinin kesişimini uyguladığından, donanım izin hatalarını tam 4 KB sınırlarında yakalar. - **Sistem Çağrısı Tuzağı**: Konuk EL0 `SVC #0` komutu EL1 `VBAR_EL1` değerine tuzaklanır, kayıtları paylaşılan 4 KB `CommPage` alanına yazar ve Go Sentry iş parçacığına dönmek için `hv_vcpu_run` içinden `HVC #0` komutunu yürütür. ### 3. Windows Kullanıcı Modu Yedeği: `platform/systrap` (`winsystrap`) Donanım sanallaştırması kullanılamadığında (iç içe bulut VM'lerinde olduğu gibi), `winsystrap` `windows/amd64` ve `windows/arm64` üzerinde konuk kodunu kullanıcı modunda çalıştırır: - **Donanım `CR3` / `TTBR0_EL1` İzolasyonu**: Konuk iş parçacıkları, Low bütünlük belirteci ve bir Job Object ile sınırlandırılmış, oluşturulmuş 1 KB çalıştırılabilir dosyadan (`stubimage_xplat.go`) başlatılan izole kesim alt süreçleri içinde çalışır. - **Yerinde İkili Yama ve `winSysmsg` IPC**: `amd64` üzerinde yama uygulayıcı (`patcher_amd64_xplat.go`), 2 baytlık `syscall` (`0f 05`) komutlarını 5 baytlık `jmp rel32` atlamalarıyla (5 baytlık pencere kullanılamadığında `CC 90` kesme noktası tuzakları ile) hızlı yol adasına değiştirir. `arm64` üzerinde `svc #0`, bir ada yuvasına `B` dallanmasıyla yamalanır. Ada, kayıtları paylaşılan `winSysmsg` sayfasına yazar ve `WaitOnAddress` ile `WakeByAddressSingle` aracılığıyla Sentry ile senkronize olur; yamalanmamış tuzaklar ve sayfa hataları ise bir Windows Debug Object (`WaitForDebugEventEx`) üzerinde durdurulur. ### 4. Linux Kullanıcı Modu Motoru: `platform/systrap` `linux/amd64` ve `linux/arm64` üzerinde `systrap`, konuk iş parçacıklarını (`sysmsg`) çalıştırır; bu iş parçacıkları konuk sistem çağrılarını `SECCOMP_RET_TRAP` (`SIGSYS`) ile yakalar ve `syscall` noktalarını `SYS_FUTEX` ile senkronize edilen paylaşılan bellekli bir sıçrama alanına (`sysmsg`) ikili yama ile yönlendirir. Bu sırada bir kesim `syscallThread` (`syscall_thread.go`) iş parçacığı, adres alanı işlemlerini (`mmap`, `munmap`, `clone`) `SECCOMP_RET_USER_NOTIF` (`_RUN_SECCOMP_LOOP`) aracılığıyla yürütür. `gvx`, tek `SECCOMP_FILTER_FLAG_NEW_LISTENER` yuvasının `EBUSY` döndürdüğü dış bir `gVisor` (`runsc`) sandbox'ı içinde çalıştığında, `syscallThread` iş parçacığını otomatik olarak paylaşılan bellekli futex döngüsüne (`_RUN_SYSCALL_LOOP`) geçirir; ayrıntılar [bu serinin 3. bölümünde](/blog/posts/docker-in-docker-inside-gvisor-with-gvx-z48916d03) anlatılmaktadır. --- ## `gvx`'in Konuk Linux Sistem Çağrılarını Sanal Alt Sistemlere ve Ana Makine Tutamaçlarına Eşlemesi Bir platform motoru konuk `SYSCALL` (`amd64`) veya `SVC #0` (`arm64`) komutunu yakaladıktan ve konuk kayıtlarını 4 KB paylaşılan sayfaya (`CommPage`, `sysmsg` veya `winSysmsg`) yazdıktan sonra kontrol, Go `Sentry` görev goroutine'ine (`pkg/sentry/kernel/task_syscall.go`) döner. Linux sistem çağrılarını altta yatan ana makine işletim sistemi çekirdeğine iletmek yerine `Task.doSyscall()`, özgün kayıt durumunu (`SyscallSaveOrig()`) kaydeder, konuk içi BPF `seccomp` filtrelerini ve `ptrace` duraklamalarını değerlendirir ve sistem çağrısı numarasını `linux.AMD64` veya `linux.ARM64` aracılığıyla (`pkg/sentry/syscalls/linux/linux64.go`, yaklaşık 370 Linux sistem çağrısını kapsar) dört iç alana yönlendirir: ![gvx'in Konuk Linux Sistem Çağrılarını Alt Sistemlere ve Ana Makine İşletim Sistemine Eşlemesi](/assets/images/gvx/gvx-syscall-mapping.png) | Sistem Çağrısı Alanı | Temsili Konuk Linux Sistem Çağrıları | Dahili `gvx` Alt Sistemi (`pkg/sentry`) | Ana Makine İşletim Sistemi Sınırı Etkileşimi (`hostlockdown` Sonrası) | | :--- | :--- | :--- | :--- | | **A. Süreç, Ad Alanı, Bağlama ve Senkronizasyon** | `clone`, `execve`, `unshare`, `setns`, `mount`, `umount2`, `pivot_root`, `setuid`, `capset`, `futex`, `epoll_wait`, `pipe2` | `kernel.Task`, sanal kimlik bilgileri, futex tablosu ve bellek içi `VFS2` (`procfs`, `sysfs`, `cgroupfs` v2, `tmpfs`, `overlayfs`) | **Sıfır ana makine sistem çağrısı** (%100 bellek içi Go durumu; ana makine işletim sistemi tarafından tamamen görünmez) | | **B. Sanal Bellek (`MM`)** | `mmap`, `munmap`, `mremap`, `mprotect`, `brk`, `madvise`, `memfd_create` | `mm.MemoryManager` (4 KB VMA ağacı) ve `pgalloc.MemoryFile` | `WHvMapGpaRange`, `hv_vm_map` + `TTBR0_EL1` veya kesim `mmap`/`mprotect` aracılığıyla çift yönlü 4 KB sayfa tablosu güncellemeleri | | **C. Dosya ve Depolama (`VFS2`)** | `openat`, `pread64`, `pwrite64`, `getdents64`, `statx`, `renameat2`, `setxattr`, `mknod`, `inotify_add_watch` | `vfs.VirtualFilesystem` bağlama tablosu yönlendiricisi (`fsimpl/erofs`, `fsimpl/ext4lite`, `fsimpl/hostfs` v2) | 1 sabitlenmiş `.erofs` FD veya 1 `.ext4` FD üzerinde çift yönlü `pread`/`pwrite` ya da `*os.Root` üzerinde kapsamlı göreli gezinmeler | | **D. Ağ Oluşturma ve Netfilter** | `socket`, `bind`, `listen`, `connect`, `sendmsg`, `recvmsg`, `netlink`, `setsockopt(IPT_SO_SET_REPLACE)` | Kullanıcı alanı `pkg/tcpip` (`lo`, `eth0`, `docker0`, `veth`, `vxlan`, `wireguard`, `ipset`, `iptables-legacy`) | Sandbox içi trafik **sıfır ana makine sistem çağrısı** kullanır; dış trafik `net.Dial`/`net.Listen` (`-net=nat`) veya 1 UDP soketi (`-net=wg`) ile eşlenir | Işleyici `(rval, ctrl, err)` döndürdüğünde `Task.doSyscallInvoke()`, herhangi bir hatayı negatif bir Linux `errno` değerine dönüştürür (`-ExtractErrno(err, sysno)`), dönüş değerini paylaşılan kayıt sayfasına yazar (`amd64` üzerinde `RAX`, `arm64` üzerinde `X0`) ve konuk yürütmeyi devam ettirir. --- ## Depolama (`VFS2`) ve İki İzli Kullanıcı Alanı Ağı (`netstack`) Tüm konuk dosya ve ağ işlemleri Go `Sentry` içinde üç `VFS2` dosya sistemi ve iki `pkg/netbackend` izi aracılığıyla yürütülür: ![gvx VFS2 Depolama Motorları ve İki İzli Netstack](/assets/images/gvx/gvx-storage-netstack.png) | Depolama Motoru | `gvx` İçindeki Bağlama Rolü | Destekleyen Ana Makine Kaynağı | Çalışma Zamanında Ana Makine `openat` / `NtCreateFile` Çağrıları | Windows Defender (`WdFilter.sys`) Dosya Başına Taramalar | | :--------------------- | :------------------------------------------------ | :--------------------------------------- | ---------------------------------------------------------------: | -------------------------------------------------------: | | **`fsimpl/erofs`** | Salt okunur OCI imajı alt katmanları | Katman başına tek bir `.erofs` dosyası | `0` | `0` | | **`fsimpl/ext4lite`** | Adlandırılmış birimler (`-v name:/path`) | Birim başına tek bir `.ext4` dosyası | `0` | `0` | | **`fsimpl/hostfs` v2** | Ana makine çalışma alanı (`-workspace`, `-v /host:/guest`) | Sabitlenmiş `*os.Root` ana makine dizini | Önbelleğe alınmamış açma başına `O(depth)` | Ana makine dosyası kapatma başına `1` | ### `ext4lite`'ın Docker, Veritabanları ve Paket Yöneticileri İçin Neden Önemli Olduğu On binlerce konteyner dosyasını doğrudan Windows NTFS veya macOS APFS üzerine çıkarmak veya yazmak; antivirüs minifilter taramalarını (`WdFilter.sys`), büyük-küçük harf duyarlılığı çakışmalarını ve eksik POSIX genişletilmiş öznitelikleri tetikler. `pkg/sentry/fsimpl/ext4lite`, önceden açılmış tek bir ana makine dosyasının (Windows'ta `%LOCALAPPDATA%\gvx\cache\volumes\.ext4`, macOS'ta `~/Library/Caches/gvx/volumes/.ext4` veya Linux'ta `~/.cache/gvx/volumes/.ext4`) içinde saf Go ile yazılmış bir `ext4` dosya sistemi uygular ve şunları içerir: - **4 KiB blok ve 16 MiB dinamik blok grupları (`meta_bg`)**: Seyrek dosya tahsisi duraklamaları olmadan dinamik olarak büyür (Linux'ta `fallocate`, macOS'ta `fcntl(F_PREALLOCATE)`, Windows'ta `FileAllocationInfo`) ve temiz ayırmada kullanılmayan sondaki grupları sıkıştırır. - **JBD2 sıralı mod günlüğü (inode 8)**: CRC-32 sağlama toplamları ve iptal blokları ile atomik işlem commit'leri, ayrıca `fsckLite` kurtarması. - **`overlayfs` üst katman desteği**: `trusted.overlay.*` ve `security.capability` genişletilmiş öznitelikleri, karakter aygıtı silme işaretleri (`0:0`), `d_type` dizin girdisi raporlaması ve `RENAME_EXCHANGE` uygular. --- ## Uygulamalı İş Yükleri: Docker Engine, Kubernetes (`k3s` + `Calico`) ve Go SDK ### `rungv`'nin Kurulumu: SLSA ile Doğrulanmış Hazır Sürümler veya `go install` `linux/amd64`, `linux/arm64`, `darwin/arm64`, `windows/amd64` veya `windows/arm64` için hazır bir `rungv` arşivini [GitHub Releases](https://github.com/gfire-sigs/gvx/releases) adresinden indirebilirsiniz (her biri Sigstore kaynak paketi ve `SHA256SUMS` ile SLSA sürüm hattı tarafından oluşturulmuştur) veya doğrudan kaynaktan `go install` ile kurabilirsiniz: ```sh # Seçenek A: Hazır bir sürümü indirin ve SLSA derleme kaynağını doğrulayın gh attestation verify rungv-v0.2.0-linux-amd64.tar.gz --repo gfire-sigs/gvx \ --signer-workflow gfire-sigs/gvx/.github/workflows/release.yml \ --source-ref refs/tags/v0.2.0 --deny-self-hosted-runners shasum -a 256 -c SHA256SUMS --ignore-missing tar -xzf rungv-v0.2.0-linux-amd64.tar.gz # Seçenek B: Go ile doğrudan kurun (Linux / Windows) CGO_ENABLED=0 go install z.gfire.dev/gvx/cmd/rungv@latest ``` > macOS (`darwin/arm64`) üzerinde hazır sürüm arşivi zaten `com.apple.security.hypervisor` yetkisiyle imzalanmıştır (`xattr -d com.apple.quarantine rungv` komutu tarayıcı karantina işaretini temizler). macOS üzerinde `go install` veya `go build` ile yerel olarak derlerseniz, ikiliyi `codesign --sign - --entitlements entitlements.plist --force $(which rungv)` komutuyla imzalayın. ### 1. Ayrıcalıksız Bir Docker Engine Çalıştırma (`docker:dind`) [`docs/docker-engine.md`](https://github.com/gfire-sigs/gvx/blob/main/docs/docker-engine.md) belgesini takip ederek, Windows, macOS veya Linux üzerinde `rungv` içinde değiştirilmemiş bir `docker:dind` konteyneri çalıştırabilir ve ana makinedeki `docker` CLI ile kontrol edebilirsiniz: ```sh # 1. İletilen Unix soketi için ana makine dizinini oluşturun mkdir -p ~/.gvx # 2. ext4lite birimiyle bir gvx sandbox içinde docker:dind'i başlatın rungv run \ -p unix:~/.gvx/docker.sock:2375 \ -p 127.0.0.1:9000-9019:9000-9019 \ -v gvx-docker:/var/lib/docker \ -e DOCKER_TLS_CERTDIR= \ docker:dind --tls=false ``` İkinci bir terminalde, ana makinedeki `docker` CLI'ı sandbox soketine yönlendirin: ```sh docker context create gvx --docker host=unix://$HOME/.gvx/docker.sock docker context use gvx docker info --format '{{.Driver}} {{.OperatingSystem}}' # Çıktı: overlayfs Alpine Linux ... (containerized) docker build -t myapp ./app docker compose up -d ``` ### 2. Ayrıcalıksız Sandbox'larda Kubernetes (`k3s` + `Calico`) Çalıştırma `gvx`, `/dev/kmsg`, `cgroup` v2 (`memory.max` OOM öldürücüsü ve `cpu.max` bant genişliği kısıtlaması), `/proc/diskstats`, `wireguard` ve `vxlan` netlink aygıtları, `ipset` ile `iptables-legacy` (`addrtype`, `conntrack`, `statistic`, `recent`) özelliklerini uyguladığı için, değiştirilmemiş bir `rancher/k3s` imajı tek bir `rungv` süreci içinde `Ready` durumuna ulaşır: ```sh mkdir -p ~/.gvx/k3s rungv run \ -e IPTABLES_MODE=legacy \ -p 127.0.0.1:6443:6443 \ -p 127.0.0.1:30000-30019:30000-30019 \ -v k3s:/var/lib/rancher \ --mount type=bind,src=$HOME/.gvx/k3s,dst=/output \ rancher/k3s:v1.31.4-k3s1 server \ --disable=traefik,servicelb \ --write-kubeconfig=/output/kubeconfig.yaml \ --write-kubeconfig-mode=644 ``` Ayrıca birden fazla `gvx` düğümünü WireGuard üzerinden (`flannel-backend=wireguard-native` veya bir `wg0` ağı) gömülü `etcd` yüksek erişilebilirliği ile birleştirebilir ya da Kubernetes `NetworkPolicy` kurallarını tamamen kullanıcı alanında uygulamak için **Calico** (`calico-vxlan.yaml` ile `FELIX_IPTABLESBACKEND=Legacy`) çalıştırabilirsiniz. ### 3. `z.gfire.dev/gvx/pkg/gvx` ile Go'da Linux Konteynerlerini Gömme Go uygulamaları, harici bir konteyner daemon'ı olmadan Linux konteynerlerini doğrudan gömebilir: ```go package main import ( "context" "fmt" "os" "z.gfire.dev/gvx/pkg/gvx" ) func main() { ctx := context.Background() sb, err := gvx.New(ctx, gvx.Config{ Platform: gvx.PlatformAuto, NetworkMode: gvx.NetModeNAT, OCIImage: "alpine:3.20", WorkspacePath: "./repo", Argv: []string{"/usr/bin/git", "status"}, Stdout: os.Stdout, Stderr: os.Stderr, }) if err != nil { fmt.Fprintf(os.Stderr, "init sandbox: %v\n", err) os.Exit(1) } defer sb.Close() exitCode, err := sb.Run(ctx) if err != nil { fmt.Fprintf(os.Stderr, "run sandbox: %v\n", err) os.Exit(1) } os.Exit(exitCode) } ``` --- ## Bu Serinin Devamı 1. **[gvx: Tek Bir Ayrıcalıksız Süreçte Linux Konteynerlerini, Docker'ı ve Kubernetes'i Çalıştırma](/blog/posts/gvx-cross-platform-linux-containers-z48916d01)** (bu yazı) 2. **[Root veya User Namespace Olmadan Docker, docker build ve docker compose Çalıştırma](/blog/posts/run-docker-without-root-or-userns-gvx-z48916d02)**: `sudo`, `unshare(CLONE_NEWUSER)`, `mount(2)` ve `/dev/fuse` erişiminin engellendiği kilitli sandbox'larda `docker:dind` nasıl başlatılır. 3. **[gvx ile gVisor ve İç İçe Sandbox'lar İçinde Docker-in-Docker Çalıştırma](/blog/posts/docker-in-docker-inside-gvisor-with-gvx-z48916d03)**: `apt-get install docker.io` komutu ve iç içe `runsc` neden `gVisor` içinde beş çekirdek engelinde başarısız olur ve `gvx`, paylaşılan bellekli futex döngüsünü kullanarak iç içe `docker:dind`i nasıl çalıştırır. 4. **[gvx ile AI Ajanı RL Rollout'ları için Hızlı İzole Docker Ortamları](/blog/posts/fast-docker-environments-for-agent-rl-rollouts-z48916d04)**: Yüzlerce paralel ayrıcalıksız `docker:dind` örneği ve 100 milisaniyelik kopyala-yazma `.ext4` birim sıfırlamaları ile `SWE-bench` ve ajan pekiştirmeli öğrenme rollout'larını ölçeklendirme.