Docker tr TR
ASF, bir docker konteyneri olarak mevcuttur. Docker paketlerimiz şu anda hem ghcr.io hem de Docker Hub üzerinde mevcuttur.
ASF'yi bir Docker konteynerinde çalıştırmanın gelişmiş bir kurulum olarak kabul edildiğini, kullanıcıların büyük çoğunluğu için gerekli olmadığını ve genellikle konteynersiz kuruluma göre hiçbir avantaj sağlamadığını belirtmek önemlidir. Eğer ASF'yi bir servis olarak çalıştırmak için (örneğin işletim sisteminizle otomatik olarak başlatmak) Docker'ı bir çözüm olarak düşünüyorsanız, bunun yerine yönetim bölümünü okumayı ve uygun bir systemd servisi kurmayı düşünmelisiniz. Bu, ASF'yi bir Docker konteynerinde çalıştırmaktan neredeyse her zaman daha iyi bir fikirdir.
ASF'yi bir Docker konteynerinde çalıştırmak genellikle yüzleşmeniz ve kendi başınıza çözmeniz gereken birkaç yeni problem ve sorun içerir. Bu yüzden, zaten Docker bilginiz yoksa ve iç işleyişini anlama konusunda yardıma ihtiyacınız yoksa (ki bu konuyu burada ASF vikisinde detaylandırmayacağız), bundan kaçınmanızı şiddetle tavsiye ederiz. Bu bölüm, çoğunlukla çok karmaşık kurulumların geçerli kullanım durumları içindir; örneğin, ileri düzey ağ yapılandırması veya ASF'nin systemd servisiyle birlikte gelen (ve zaten çok gelişmiş güvenlik mekanizmalarıyla üstün süreç izolasyonu sağlayan) standart sanal alan (sandbox) korumasının ötesindeki güvenlik durumları gibi. Bu bir avuç insan için, burada ASF'nin Docker uyumluluğuna ilişkin kavramlarını daha iyi açıklıyoruz, sadece bu kadar. Eğer ASF ile birlikte kullanmaya karar verirseniz, yeterli Docker bilgisine sahip olduğunuz varsayılmaktadır.
ASF, 4 ana etiket türü aracılığıyla kullanılabilir:
Bu etiket her zaman main branch'indeki en son commit'ten derlenen ASF'yi işaret eder. Bu, en son derleme çıktısını doğrudan CI (Sürekli Entegrasyon) hattımızdan almakla aynı anlama gelir. Genellikle bu etiketten kaçınmalısınız, çünkü bu, geliştirme amaçları için geliştiricilere ve ileri düzey kullanıcılara adanmış, en yüksek seviyede hatalı olabilecek bir yazılımdır. Bu imaj, main GitHub branch'ine yapılan her commit ile güncellenir, bu nedenle çok sık güncelleme (ve bazı şeylerin bozulmasını) bekleyebilirsiniz. Bu etiket, sürüm döngümüzde de belirtildiği gibi, kararlı veya test edilmiş olması garanti edilmeyen ASF projesinin mevcut durumunu işaretlemek için buradadır. Bu etiket hiçbir üretim ortamında kullanılmamalıdır.
Yukarıdakine çok benzer şekilde, bu etiket her zaman en son yayınlanmış ASF sürümüne işaret eder (ön sürümler dahil). main etiketine kıyasla, bu imaj her yeni GitHub etiketi gönderildiğinde güncellenir. Hem kararlı hem de en güncel olmanın sınırlarında yaşamayı seven ileri düzey/güçlü kullanıcılara adanmıştır. latest etiketini kullanmak istemiyorsanız tavsiye edeceğimiz etiket budur. Pratikte bu, imajı çektiğiniz anda en son A.B.C.D sürümüne işaret eden değişken bir etiket gibi çalışır. Lütfen bu etiketi kullanmanın, bizim ön sürümlerimizi kullanmakla eşdeğer olduğunu unutmayın.
Diğerleriyle karşılaştırıldığında bu etiket, ASF'nin otomatik güncelleme özelliğini içeren ve en son kararlı (stable) ASF sürümüne işaret eden tek etikettir. Bu etiketin amacı, kendini güncelleyebilen, işletim sistemine özgü bir ASF sürümünü çalıştırabilen, mantıklı bir varsayılan Docker konteyneri sağlamaktır. Bu nedenle, içerdiği ASF sürümü gerektiğinde her zaman kendini güncelleyebileceği için imajın mümkün olduğunca sık güncellenmesi gerekmez. Elbette, UpdatePeriod güvenle kapatılabilir (0 olarak ayarlanabilir), ancak bu durumda muhtemelen bunun yerine dondurulmuş bir A.B.C.D sürümü kullanmalısınız. Benzer şekilde, otomatik güncellemeyi released etiketine yönlendirmek için varsayılan UpdateChannel ayarını değiştirebilirsiniz.
latest imajı otomatik güncelleme yeteneğiyle geldiğinden, diğer tüm etiketlerin aksine (ki onlar .NET çalışma zamanı ve generic ASF sürümü içerir), bu imaj yalnızca temel bir işletim sistemi ve ona özgü linux ASF sürümünü içerir. Bunun nedeni, daha yeni (güncellenmiş) bir ASF sürümünün, imajın oluşturulduğu çalışma zamanından daha yeni bir çalışma zamanı gerektirebilmesidir. Aksi takdirde, imajın sıfırdan yeniden oluşturulması gerekir ki bu da planlanan kullanım amacını boşa çıkarır.
Yukarıdaki etiketlerle karşılaştırıldığında, bu etiket tamamen dondurulmuştur, yani imaj yayınlandıktan sonra bir daha güncellenmez. Bu, ilk yayınlandıktan sonra asla dokunulmayan GitHub sürümlerimize benzer şekilde çalışır ve size kararlı ve değişmez bir ortam garanti eder. Genellikle bu etiketi, belirli bir ASF sürümünü kullanmak istediğinizde ve herhangi bir otomatik güncelleme istemediğinizde (örneğin latest etiketinde sunulanlar gibi) kullanmalısınız.
Bu, ne aradığınıza bağlıdır. Kullanıcıların çoğunluğu için latest etiketi en iyisi olmalıdır, çünkü masaüstü ASF'nin sunduğu özelliklerin aynısını, yalnızca özel bir Docker konteyneri içinde bir servis olarak sunar. İmajlarını sık sık yeniden oluşturan ve belirli bir sürüme bağlı bir ASF versiyonu ile tam kontrolü tercih eden kişiler released etiketini kullanabilirler. Eğer sizin açık bir niyetiniz olmadan asla değişmeyecek, dondurulmuş belirli bir ASF sürümünü kullanmak isterseniz, A.B.C.D sürümleri her zaman geri dönebileceğiniz sabit ASF kilometre taşları olarak mevcuttur.
Genel olarak main sürümlerini denemenizi önermiyoruz, çünkü bunlar ASF projesinin mevcut durumunu işaretlemek için buradadır. Böyle bir durumun düzgün çalışacağını hiçbir şey garanti etmez, ancak ASF geliştirmesiyle ilgileniyorsanız elbette denemekten çekinmeyin.
ASF docker imajı şu anda linux platformunda x64, arm ve arm64 olmak üzere 3 mimariyi hedef alarak oluşturulmaktadır. Bunlar hakkında daha fazla bilgiyi uyumluluk bölümünde okuyabilirsiniz.
Etiketlerimiz çoklu platform manifestosu kullanır, bu da makinenize kurulu Docker'ın imajı çekerken platformunuz için uygun imajı otomatik olarak seçeceği anlamına gelir. Eğer bir şekilde o an çalıştığınız platformla eşleşmeyen belirli bir platform imajını çekmek isterseniz, bunu docker run gibi uygun docker komutlarındaki --platform anahtarı aracılığıyla yapabilirsiniz. Daha fazla bilgi için imaj manifestosu hakkındaki Docker belgelerine bakın.
Tam bir referans için resmi Docker belgelerini kullanmalısınız. Bu kılavuzda yalnızca temel kullanımı ele alacağız, daha derine inmekten çekinmeyin.
Öncelikle Docker'ımızın düzgün çalışıp çalışmadığını doğrulamalıyız, bu bizim ASF "merhaba dünya" testimiz olacak:
docker run -it --name asf --pull always --rm justarchi/archisteamfarmdocker run, sizin için yeni bir ASF docker konteyneri oluşturur ve onu ön planda (-it) çalıştırır. --pull always, her zaman güncel imajın çekilmesini sağlar ve --rm, şimdilik her şeyin yolunda gidip gitmediğini test ettiğimiz için konteyner durdurulduğunda kaldırılmasını sağlar.
Eğer her şey başarılı bir şekilde bittiyse, tüm katmanları çektikten ve konteyneri başlattıktan sonra, ASF'nin düzgün bir şekilde başladığını ve tanımlanmış bot olmadığını bize bildirdiğini fark etmelisiniz. Bu iyi bir şey - Docker içindeki ASF'nin düzgün çalıştığını doğruladık. ASF sürecini ve dolayısıyla konteyneri de sonlandırmak için CTRL+C tuşlarına basın.
Komuta daha yakından bakarsanız, herhangi bir etiket belirtmediğimizi fark edersiniz, bu da otomatik olarak latest etiketinin varsayılan olarak kullanılmasına neden oldu. Eğer latest dışında bir etiket kullanmak isterseniz, örneğin released, bunu açıkça belirtmelisiniz:
docker run -it --name asf --pull always --rm justarchi/archisteamfarm:releasedEğer ASF'yi bir Docker konteynerinde kullanıyorsanız, programı yapılandırmanız gerekir. Bunu çeşitli yollarla yapabilirsiniz, ancak önerilen yöntem, yerel makinenizde bir ASF config dizini oluşturmak ve ardından bunu ASF Docker konteynerinde paylaşılan bir birim (volume) olarak bağlamaktır.
Örneğin, ASF yapılandırma klasörünüzün /home/archi/ASF/config dizininde olduğunu varsayalım. Bu dizin, çalıştırmak istediğimiz botların yanı sıra temel ASF.json dosyasını da içerir. Şimdi tek yapmamız gereken, bu dizini ASF'nin yapılandırma dizinini beklediği yere (/app/config) Docker konteynerimizde paylaşılan bir birim olarak bağlamaktır.
docker run -it -v /home/archi/ASF/config:/app/config --name asf --pull always justarchi/archisteamfarmVe işte bu kadar! Artık ASF Docker konteyneriniz, yerel makinenizle paylaşılan dizini okuma-yazma modunda kullanacak. Bu, ASF'yi yapılandırmak için ihtiyacınız olan her şeydir. Benzer şekilde, /app/logs veya /app/plugins gibi ASF ile paylaşmak istediğiniz diğer birimleri de bağlayabilirsiniz.
Elbette, bu istediğimizi başarmanın yalnızca belirli bir yoludur. Sizi, örneğin kendi Dockerfile dosyanızı oluşturarak yapılandırma dosyalarınızı ASF Docker konteyneri içindeki /app/config dizinine kopyalamaktan alıkoyan hiçbir şey yok. Bu kılavuzda yalnızca temel kullanımı ele alıyoruz.
ASF konteyneri varsayılan olarak root kullanıcısıyla başlatılır. Bu, dahili izin işlemlerini halletmesine ve ardından ana sürecin geri kalanı için asf (UID 1000) kullanıcısına geçmesine olanak tanır. Bu durum kullanıcıların büyük çoğunluğu için yeterli olsa da, paylaşılan birimi etkiler; çünkü yeni oluşturulan dosyaların sahibi normalde asf kullanıcısı olacaktır. Eğer paylaşılan biriminiz için başka bir kullanıcı atamak istiyorsanız, bu istenmeyen bir durum olabilir.
ASF'nin çalıştığı kullanıcıyı iki şekilde değiştirebilirsiniz. Önerilen ilk yöntem, çalıştırmak istediğiniz hedef UID (kullanıcı kimliği) ile bir ASF_USER ortam değişkeni bildirmektir. İkinci alternatif yöntem ise, doğrudan Docker tarafından desteklenen --user parametresini kullanmaktır.
uid'nizi örneğin id -u komutuyla kontrol edebilir ve ardından yukarıda belirtildiği gibi bildirebilirsiniz. Örneğin, hedef kullanıcınızın uid'si 1001 ise:
docker run -it -e ASF_USER=1001 -v /home/archi/ASF/config:/app/config --name asf --pull always justarchi/archisteamfarm
# Alternatif olarak, aşağıdaki sınırlamaları anlıyorsanız
docker run -it -u 1001 -v /home/archi/ASF/config:/app/config --name asf --pull always justarchi/archisteamfarmASF_USER ile --user parametresi arasındaki fark ince ama önemlidir. ASF_USER, ASF tarafından desteklenen özel bir mekanizmadır. Bu senaryoda Docker konteyneri yine root olarak başlar, ardından ASF başlangıç betiği ana programı ASF_USER ile başlatır. --user parametresini kullandığınızda ise, ASF başlangıç betiği de dahil olmak üzere tüm süreci belirttiğiniz kullanıcı olarak başlatırsınız. İlk seçenek, ASF başlangıç betiğinin izinleri ve diğer şeyleri sizin için otomatik olarak halletmesine olanak tanır ve neden olabileceğiniz bazı yaygın sorunları çözer. Örneğin, /app ve /asf dizinlerinizin gerçekten ASF_USER tarafından sahiplenildiğinden emin olur. İkinci senaryoda ise, root olarak çalışmadığımız için bunu yapamayız ve tüm bu işlemleri önceden kendinizin halletmesi beklenir.
Eğer --user parametresini kullanmaya karar verdiyseniz, tüm ASF dosyalarının sahipliğini varsayılan asf kullanıcısından yeni özel kullanıcınıza değiştirmeniz gerekir. Bunu aşağıdaki komutu çalıştırarak yapabilirsiniz:
# Sadece ASF_USER kullanmıyorsanız çalıştırın
docker exec -u root asf chown -hR 1001 /app /asfBu işlem, konteynerinizi docker run ile oluşturduktan sonra yalnızca bir kez ve yalnızca --user Docker parametresi aracılığıyla özel bir kullanıcı kullanmaya karar verdiyseniz yapılmalıdır. Ayrıca, yukarıdaki komutta yer alan 1001 argümanını, ASF'yi gerçekten altında çalıştırmak istediğiniz UID ile değiştirmeyi unutmayın.
Eğer işletim sisteminizde zorunlu modda SELinux kullanıyorsanız (örneğin RHEL tabanlı dağıtımlarda bu varsayılandır), o zaman birimi bağlarken sonuna :Z seçeneğini eklemelisiniz. Bu, birim için doğru SELinux bağlamını ayarlayacaktır.
docker run -it -v /home/archi/ASF/config:/app/config:Z --name asf --pull always justarchi/archisteamfarm
Bu, ASF'nin Docker konteyneri içindeyken birimi hedefleyen dosyalar oluşturmasına olanak tanır.
Yönetim bölümünde belirtildiği gibi, ASF birden fazla örneğin senkronizasyonunu destekler. ASF'yi birden fazla konteynerde çalıştırıyorsanız ve bunların birbirleriyle senkronize olmasını istiyorsanız, isteğe bağlı olarak bu sürece "katılabilirsiniz".
Varsayılan olarak, bir Docker konteyneri içinde çalışan her ASF bağımsızdır, bu da senkronizasyonun gerçekleşmediği anlamına gelir. Aralarında senkronizasyonu etkinleştirmek için, senkronize etmek istediğiniz her ASF konteynerindeki /tmp/ASF yolunu, Docker ana makinenizdeki tek bir paylaşılan yola, okuma-yazma modunda bağlamanız gerekir. Bu, yukarıda açıklanan bir birimi bağlamakla tamamen aynı şekilde, yalnızca farklı yollarla gerçekleştirilir:
mkdir -p /tmp/ASF-g1
docker run -v /tmp/ASF-g1:/tmp/ASF -v /home/archi/ASF/config:/app/config --name asf1 --pull always justarchi/archisteamfarm
docker run -v /tmp/ASF-g1:/tmp/ASF -v /home/john/ASF/config:/app/config --name asf2 --pull always justarchi/archisteamfarm
# Ve bu şekilde devam eder, tüm ASF konteynerleri artık birbiriyle senkronize edilirASF'nin /tmp/ASF dizinini makinenizdeki geçici bir /tmp dizinine de bağlamanızı öneririz, ancak elbette kullanımınıza uygun başka birini seçmekte özgürsünüz. Senkronize edilmesi beklenen her ASF konteynerinin /tmp/ASF dizini, aynı senkronizasyon sürecinde yer alan diğer konteynerlerle paylaşılmalıdır.
Yukarıdaki örnekten de tahmin edebileceğiniz gibi, farklı Docker ana makine yollarını ASF'nin /tmp/ASF yoluna bağlayarak iki veya daha fazla "senkronizasyon grubu" oluşturmak da mümkündür.
/tmp/ASF yolunu bağlamak tamamen isteğe bağlıdır ve açıkça iki veya daha fazla ASF konteynerini senkronize etmek istemiyorsanız aslında önerilmez. Tek konteyner kullanımı için /tmp/ASF bağlamanızı önermiyoruz, çünkü yalnızca bir ASF konteyneri çalıştırmayı bekliyorsanız kesinlikle hiçbir fayda sağlamaz ve hatta aksi takdirde kaçınılabilecek sorunlara neden olabilir.
ASF, bir Docker konteyneri içinde komut satırı argümanlarını ortam değişkenleri aracılığıyla geçirmenize olanak tanır. Desteklenen anahtarlar için belirli ortam değişkenlerini, geri kalanı için ise ASF_ARGS kullanmalısınız. Bu, docker run komutuna eklenen -e anahtarıyla gerçekleştirilebilir, örneğin:
docker run -it -e "ASF_CRYPTKEY=Parolam" -e "ASF_ARGS=--no-config-migrate" --name asf --pull always justarchi/archisteamfarmBu, --cryptkey argümanınızı ve diğer argümanları Docker konteyneri içinde çalışan ASF sürecine düzgün bir şekilde geçirecektir. Elbette, eğer ileri düzey bir kullanıcıysanız, ENTRYPOINT'i değiştirebilir veya CMD ekleyebilir ve kendi özel argümanlarınızı kendiniz geçirebilirsiniz.
Özel bir şifreleme anahtarı veya diğer gelişmiş seçenekleri sağlamak istemiyorsanız, genellikle herhangi bir özel ortam değişkeni eklemenize gerek yoktur. Çünkü Docker konteynerlerimiz zaten --no-restart ve --system-required gibi mantıklı varsayılan seçeneklerle çalışacak şekilde yapılandırılmıştır, bu nedenle bu parametrelerin ASF_ARGS içinde açıkça belirtilmesi gerekmez.
IPC genel yapılandırma özelliğinin varsayılan değerini değiştirmediğinizi varsayarsak, bu özellik zaten etkindir. Ancak, IPC'nin Docker konteynerinde çalışması için iki ek şey yapmanız gerekir. İlk olarak, dışarıdan parola kullanmadan bağlanmanıza izin vermek için ya IPCPassword kullanmalı ya da özel bir IPC.config dosyasında varsayılan KnownNetworks ayarını değiştirmelisiniz. Ne yaptığınızı gerçekten bilmiyorsanız, sadece IPCPassword kullanın. İkinci olarak, Docker dış trafiği geri döngü arayüzüne (loopback interface) yönlendiremediği için varsayılan dinleme adresi olan localhost'u değiştirmelisiniz. Tüm arayüzleri dinleyecek bir ayar örneği http://*:1242 olabilir. Elbette, yalnızca yerel LAN veya VPN ağı gibi daha kısıtlayıcı bağlamalar da kullanabilirsiniz, ancak rotanın dışarıdan erişilebilir olması gerekir - rota tamamen misafir makinenin içinde olduğundan localhost işe yaramayacaktır.
Yukarıdakileri yapmak için aşağıdaki gibi özel bir IPC yapılandırması kullanmalısınız:
{
"Kestrel": {
"Endpoints": {
"HTTP": {
"Url": "http://*:1242"
}
}
}
}IPC'yi geri döngü olmayan bir arayüzde kurduktan sonra, Docker'a ASF'nin 1242/tcp portunu -P veya -p anahtarıyla eşlemesini söylememiz gerekir.
Örneğin, bu komut ASF IPC arayüzünü (yalnızca) ana makineye açar:
docker run -it -p 127.0.0.1:1242:1242 -p [::1]:1242:1242 --name asf --pull always justarchi/archisteamfarmHer şeyi doğru ayarlarsanız, yukarıdaki docker run komutu, artık misafir makinenize doğru şekilde yönlendirilen standart localhost:1242 rotası üzerinden ana makinenizden IPC arayüzünü çalışır hale getirecektir. Ayrıca bu rotayı daha fazla açığa çıkarmadığımızı, bu sayede bağlantının yalnızca Docker ana makinesi içinde yapılabileceğini ve dolayısıyla güvenli kaldığını belirtmekte fayda var. Elbette, ne yaptığınızı biliyorsanız ve uygun güvenlik önlemlerini aldığınızdan eminseniz rotayı daha fazla açığa çıkarabilirsiniz.
Yukarıdaki tüm bilgileri birleştirerek, eksiksiz bir kurulum örneği şu şekilde görünecektir:
docker run -p 127.0.0.1:1242:1242 -p [::1]:1242:1242 -v /home/archi/ASF/config:/app/config -v /home/archi/ASF/plugins:/app/plugins --name asf --pull always justarchi/archisteamfarmBu, /home/archi/ASF/config içindeki tüm ASF yapılandırma dosyalarıyla tek bir ASF konteyneri kullanacağınızı varsayar. Yapılandırma yolunu makinenizle eşleşen yolla değiştirmelisiniz. Ayrıca ASF için /home/archi/ASF/plugins klasörüne koyabileceğiniz özel eklentiler sağlamak da mümkündür. Bu kurulum, eğer yapılandırma dizininize aşağıdaki gibi bir içerikle bir IPC.config dosyası eklemeye karar verdiyseniz, isteğe bağlı IPC kullanımı için de hazırdır:
{
"Kestrel": {
"Endpoints": {
"HTTP": {
"Url": "http://*:1242"
}
}
}
}ASF Docker konteyneriniz zaten hazır olduğunda, her seferinde docker run kullanmak zorunda değilsiniz. ASF Docker konteynerini docker stop asf ve docker start asf komutlarıyla kolayca durdurabilir/başlatabilirsiniz. Eğer latest etiketini kullanmıyorsanız, güncel bir ASF sürümü kullanmanın yine de sizden docker stop, docker rm ve tekrar docker run komutlarını çalıştırmanızı gerektireceğini unutmayın. Bunun nedeni, o imajda yer alan ASF sürümünü kullanmak istediğiniz her seferinde konteynerinizi yeni ASF Docker imajından yeniden oluşturmanız gerekmesidir. latest etiketinde, ASF kendi kendini otomatik güncelleme yeteneğine sahiptir, bu nedenle güncel bir ASF kullanmak için imajı yeniden oluşturmak gerekli değildir (ancak büyük ASF sürüm güncellemeleri arasında geçiş yaparken gerekebilecek olan yeni .NET çalışma zamanı bağımlılıklarını ve temel işletim sistemini kullanmak için zaman zaman bunu yapmak yine de iyi bir fikirdir).
Yukarıda ima edildiği gibi, latest dışındaki etiketlerde ASF kendini otomatik olarak güncellemez; bu da güncel justarchi/archisteamfarm deposunu kullanmaktan sizin sorumlu olduğunuz anlamına gelir. Uygulamanın çalışırken kendi koduna dokunmaması gerektiği için bunun birçok avantajı vardır, ancak Docker konteynerinizdeki ASF sürümü hakkında endişelenmenize gerek kalmamasının getirdiği kolaylığı da anlıyoruz. Eğer iyi uygulamalara ve doğru Docker kullanımına önem veriyorsanız, latest yerine released etiketini öneririz. Ancak bununla uğraşmak istemiyorsanız ve sadece ASF'nin hem çalışmasını hem de kendini otomatik güncellemesini istiyorsanız, o zaman latest işinizi görecektir.
ASF'yi genellikle Headless: true genel ayarıyla bir Docker konteynerinde çalıştırmalısınız. Bu, ASF'ye eksik ayrıntıları sağlamak için burada olmadığınızı ve bunları istememesi gerektiğini açıkça bildirecektir. Elbette, ilk kurulum için işleri kolayca ayarlayabilmek adına bu seçeneği false olarak bırakmayı düşünebilirsiniz. Ancak uzun vadede genellikle ASF konsoluna bağlı kalmayacağınız için, bu durumu ASF'ye bildirmek ve ihtiyaç doğduğunda input komutunu kullanmak mantıklı olacaktır. Bu şekilde ASF, gerçekleşmeyecek olan kullanıcı girdisi için sonsuza kadar beklemek (ve bu sırada kaynakları boşa harcamak) zorunda kalmaz. Bu aynı zamanda, ASF'nin konteyner içinde etkileşimli olmayan modda çalışmasına olanak tanır. Bu durum, örneğin sinyallerin yönlendirilmesi açısından kritik öneme sahiptir ve docker stop asf isteği üzerine ASF'nin düzgün bir şekilde kapanmasını mümkün kılar.
 |
 |
 |
 |
|---|---|---|---|
 |
 |
 |
 |
|---|---|---|---|
- 🏡 Ana Sayfa
- 💬 SSS
- ⚙️ Kurulum (buradan başlayın)
- 👥 Arkaplan oyun etkinleştirici
- 📢 Komutlar
- 🛠️ Uyumluluk
- 🔧 Yapılandırma
- 🧩 ItemsMatcher Eklentisi
- 📋 Yönetim
- ⏱️ Performans
- 📡 Uzaktan iletişim
- 👪 Steam Aile Paylaşımı
- 🔄 Takas