Kubernetes, Nomad veya herhangi bir bulutta barındırılan hizmet olarak platform (Paas) gibi platformlar çeşitli güçlü yetenekler sunar. İş yüklerinin ölçeklendirilmesinden gizli dizi yönetimine ve dağıtım stratejilerine kadar bu iş yükü düzenleyicileri, altyapının farklı şekillerde ölçeklendirilmesine yardımcı olmak için optimize edilmiştir.  Ancak operatörlerin her zaman maksimum ölçeklenebilirlik için maliyet ödemesi gerekiyor mu? Bazen karmaşıklığın ve soyutluğun maliyeti, yararlarının önüne geçer. Bunun yerine birçok inşaatçı, yönetim kolaylığı için son derece basit dağıtım mimarilerine güvenmeye başladı. Bir yük dengeleyicinin arkasındaki iki sanal özel sunucu, bir konteyner ana bilgisayar filosu boyunca yayılan bir mikro sunucu kümesiyle karşılaştırıldığında yönetimi çok daha basit bir yığındır. Sorunlar ortaya çıktığında hata ayıklamak veya bakım zamanı geldiğinde yükseltme yapmak için daha az hareketli parça olduğunda bu, temettü ödemeye başlayabilir.  Birçok modern Linux dağıtımının temeli   ve genellikle konteyner orkestratörleri veya PaaS sistemleriyle karşılaştırılabilecek güçlü özelliklerle birlikte gelir. Bu makalede, yönetim sorunu yaşamadan diğer büyük sistemlerin yeteneklerini kazanmak için en son systemd özelliklerinden nasıl yararlanabileceğinizi ve herhangi bir sıradan   sunucusunu çok yetenekli bir uygulama platformu haline getirecek şekilde nasıl güçlendirebileceğinizi keşfedeceğiz. systemd'dir Linux  Bir sistem Astarı  Tek bir ana bilgisayarda systemd   dosyası yazmak, yönetilen bir işlemi çalıştırmanın ideal bir yoludur. Çoğu zaman uygulamayı değiştirmenize bile gerek kalmaz: systemd çeşitli farklı türdeki hizmetleri destekler ve buna göre uyum sağlayabilir. .service  Örneğin, basit bir web hizmetinin nasıl çalıştırılacağını tanımlayan bu basit   düşünün: .service   [Unit] Description=a simple web service [Service] ExecStart=/usr/bin/python3 -m http.server 8080  Systemd hizmetleri için varsayılanları unutmayın:   mutlak bir yol olmalı, işlemler arka plana çatallanmamalı ve gerekli ortam değişkenlerini   seçeneğiyle ayarlamanız gerekebilir. ExecStart= Environment=    gibi bir dosyaya yerleştirildiğinde,   ile kontrol edebileceğiniz bir hizmet oluşturulur: /etc/systemd/system/webapp.service systemctl    işlemi başlatacaktır. systemctl start webapp    hizmetin çalışıp çalışmadığını, çalışma süresini ve   ve   çıktısının yanı sıra işlemin kimliğini ve diğer bilgileri görüntüler. systemctl status webapp stderr stdout    hizmeti sonlandıracak. systemctl stop webapp  Ek olarak,   ve   yazdırılan tüm çıktılar, Journald tarafından toplanacak ve sistem günlüğü aracılığıyla (   ile) erişilebilecek veya özellikle   bayrağı kullanılarak hedeflenecektir: stderr stdout journalctl --unit   journalctl --unit webapp  Journald varsayılan olarak depolama alanını dönüşümlü olarak yönettiğinden ve günlükleri günlük aracılığıyla toplamak, günlük depolamasını yönetmek için iyi bir stratejidir.  Bu makalenin geri kalanında bunun gibi bir hizmeti geliştirmeye yönelik seçenekler incelenecektir.  Sırlar      güvenli bir şekilde ekleme yeteneğini destekler: güvenli veri depolarından alınan ve çalışan iş yüklerine sunulan değerler. API anahtarları veya şifreler gibi hassas veriler, kasıtsız olarak açığa çıkmayı önlemek için ortam değişkenlerinden veya yapılandırma dosyalarından farklı bir işlem gerektirir. Kubernetes gibi konteyner orkestratörleri, Secrets'ı    diskteki dosyalardan hassas değerlerin yüklenmesini ve bunların güvenli bir şekilde çalışan hizmetlere sunulmasını destekler. Sırları uzaktan yöneten barındırılan platformlar gibi, systemd de   güvende tutulduklarından emin olmak için ortam değişkenleri gibi değerlerden farklı şekilde ele alacaktır. LoadCredential= systemd seçeneği, Kimlik Bilgilerini,  Bir systemd hizmetine bir sır enjekte etmek için, gizli değeri içeren bir dosyayı dosya sistemindeki bir yola yerleştirerek başlayın. Örneğin, bir API anahtarını bir   birimine göstermek için, yeniden başlatmalarda dosyayı kalıcı kılmak için   konumunda veya dosyanın kalıcı olarak kalıcı olmasını önlemek için   konumunda bir dosya oluşturun ( path isteğe bağlı olabilir, ancak systemd bu   yollarını varsayılan olarak değerlendirecektir). Her iki durumda da, dosyanın   gibi bir komut kullanılarak sınırlı izinlere sahip olması gerekir. .service /etc/credstore/api-key /run/credstore/api-key credstore chmod 400 /etc/credstore/api-key    dosyasının   bölümü altında,   seçeneğini tanımlayın ve iki nokta üst üste (   ) ile ayrılmış iki değeri iletin: kimlik bilgisinin adı ve yolu. Örneğin,   dosyamızı "token" olarak adlandırmak için aşağıdaki systemd hizmet seçeneğini tanımlayın: .service [Service] LoadCredential= : /etc/credstore/api-key   LoadCredential=token:/etc/credstore/api-key  Systemd hizmetinizi başlattığında, sır   biçiminde bir yol altında çalışan hizmete sunulur; burada   , systemd tarafından doldurulan bir ortam değişkenidir. Uygulama kodunuz, API belirteçleri veya parolalar gibi güvenli değerler gerektiren kitaplıklarda veya kodlarda kullanılmak üzere bu şekilde tanımlanan her gizli diziyi okumalıdır. Örneğin Python'da bu sırrı aşağıdaki gibi kodla okuyabilirsiniz: ${CREDENTIALS_DIRECTORY}/token ${CREDENTIALS_DIRECTORY}   from os import environ from pathlib import Path credentials_dir = Path(environ["CREDENTIALS_DIRECTORY"]) with Path(credentials_dir / "token").open() as f: secret = f.read().strip()  Daha sonra   değişkeni, API belirteci veya parola gerektirebilecek tüm kitaplıklar için sırrınızın içeriğiyle birlikte kullanabilirsiniz. secret  Yeniden başlatır    gibi orkestratörlerin bir başka yeteneği de çöken bir iş yükünü otomatik olarak   yeteneğidir. İşlenmeyen bir uygulama hatasından veya başka bir nedenden dolayı, başarısız uygulamaların yeniden başlatılması, bir uygulamayı dayanıklı olacak şekilde tasarlarken genellikle ilk savunma hattı olan çok kullanışlı bir özelliktir. Nomad yeniden başlatabilme    systemd   systemd'nin çalışan bir işlemi otomatik olarak yeniden başlatıp başlatmayacağını kontrol eder. Bu seçeneğin çeşitli potansiyel değerleri vardır, ancak temel hizmetler için   ayar çoğu kullanım durumunu karşılamak için çok uygundur. Restart= seçeneği, on-failure  Otomatik yeniden başlatmayı yapılandırırken göz önünde bulundurulması gereken diğer bir ayar da, hizmeti yeniden başlatmadan önce sistemin ne kadar bekleyeceğini belirleyen       . Tipik olarak, bu değerin, başarısız hizmetlerin sıkı bir döngüde yeniden başlatılmasını ve potansiyel olarak süreçleri yeniden başlatmak için harcanan çok fazla CPU zamanını tüketmesini önlemek için özelleştirilmesi gerekir.   gibi   uzun süre beklemeyen kısa bir değer genellikle yeterlidir. RestartSec RestartSec= seçeneğidir 5s çok  Süre aralıklarını veya zamana dayalı değerleri kabul eden   gibi seçenekler, ihtiyaçlarınıza bağlı olarak   veya   gibi çeşitli biçimleri ayrıştırabilir. Ek bilgi için   bakın. RestartSec= 5min 10s 1hour systemd.time kılavuzuna  Son olarak, diğer iki seçenek, sistemin sonunda pes etmeden önce başarısız üniteleri ne kadar agresif bir şekilde yeniden başlatmaya çalışacağını belirler.   ve   belirli bir süre içinde bir ünitenin ne sıklıkla başlatılmasına izin verildiğini kontrol eder. Örneğin aşağıdaki ayarlar: StartLimitIntervalSec= StartLimitBurst=   StartLimitBurst=5 StartLimitIntervalSec=10  Bir ünitenin 10 saniyelik bir süre içinde yalnızca en fazla 5 kez başlatmayı denemesine izin verir. Yapılandırılmış hizmet 10 saniye içinde altıncı kez başlatmayı denerse, systemd üniteyi yeniden başlatma girişimini durduracak ve bunun yerine   olarak işaretleyecektir. failed  Tüm bu ayarları birleştirerek,   biriminize otomatik yeniden başlatmaları yapılandırmak için aşağıdaki seçenekleri dahil edebilirsiniz: .service   [Unit] StartLimitBurst=5 StartLimitIntervalSec=10 [Service] Restart=on-failure RestartSec=1  Bu yapılandırma, bir hizmeti başarısız olursa (yani sıfırdan farklı bir çıkış koduyla beklenmedik bir şekilde çıkarsa) bir saniye bekledikten sonra yeniden başlatır ve süreç boyunca beş defadan fazla başlatmayı denerse hizmeti yeniden başlatma girişimini durdurur. 10 saniye.  Hizmet Sertleştirme  Bir konteyner içinde çalışmanın başlıca faydalarından biri güvenlik korumalı alan oluşturmadır. Bir uygulama sürecini temeldeki işletim sisteminden bölümlere ayırarak, hizmette mevcut olabilecek herhangi bir güvenlik açığının tam gelişmiş bir tehlikeye dönüşmesi çok daha zordur. Docker gibi çalışma zamanları bunu, grupların ve diğer güvenlik temellerinin bir kombinasyonu aracılığıyla başarır.  Temeldeki ana bilgisayarı öngörülemeyen iş yükü davranışına karşı korumaya yardımcı olabilecek benzer kısıtlamaları uygulamak için çeşitli sistemd seçeneklerini etkinleştirebilirsiniz:      ve   gibi hassas sistem yollarına yazma erişimini kısıtlayabilir.   mevcut tüm seçenekleri sıralamaktadır, ancak genel olarak konuşursak, bu seçeneği   olarak ayarlamak, bu dosya sistemi yollarını korumak için makul bir varsayılandır. ProtectSystem= /boot /usr Bu seçeneğe ilişkin belgeler full      ,   ve   dizinlerini   ayarıyla salt okunur olarak ayarlayabilir veya   olarak ayarlandığında bunları hizmetin dosya sistemine boş dizinler olarak bağlayabilir. Uygulamanızın bu dizinlere erişmeye özel bir ihtiyacı olmadığı sürece, bunu   olarak ayarlamak, sistemi bu dizinlere yasadışı erişime karşı güvenli bir şekilde güçlendirebilir. ProtectHome= /home /root /run/user read-only true true    yapılandırılan hizmet için ayrı bir   ve   dosyası tutar, böylece bu hizmete ve diğer işlemlere ilişkin geçici dosyalar özel kalır. İşlemlerin geçici dosyalar aracılığıyla bilgi paylaşması için zorlayıcı bir neden olmadığı sürece, bu, etkinleştirilmesi yararlı bir seçenektir. PrivateTmp= /tmp /var/tmp    yürütülen işlemin ayrıcalıklarını yükseltememesini sağlayarak bir hizmeti güçlendirmenin   . Diğer sağlamlaştırma seçeneklerini kullanma yeteneğinden emin değilseniz, bu genellikle etkinleştirilmesi en az sorunlu olanlardan biridir. NoNewPrivileges= başka bir güvenli ve basit yoludur    hizmetler gibi yürütülebilir iş yükleri için geçerli olan farklı seçenekleri keşfetmeye yönelik yararlı bir kaynaktır. systemd.exec kılavuz sayfası,  Daha fazla okuma    kapsamlıdır ve kendi uygulamalarınızı çalıştırmak için mevcut tüm seçenekler hakkında bilgi edinmek için kullanışlıdır. İster bir web sunucusu gibi kalıcı bir hizmet çalıştırıyor olun, ister bir cron işini değiştirmek için periyodik bir   ünitesi çalıştırıyor olun, systemd dokümantasyonu faydalı rehberlik sağlayabilir. Systemd projesinin kılavuz sayfaları .timer

This story contains new, firsthand information uncovered by the writer.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Systemd ile Micro-DevOps: Herhangi Bir Sıradan Linux Sunucusunu Güçlendirin

About Author

YORUMLAR

ETİKETLERİ ASIN

BU YAZI

Related Stories

Kazanmak için Dokun: Telegram, Solana'dan Önce Sonraki 10 Milyar Kripto Kullanıcısına Katılabilir

Yapay Zekanın Gücünü Ortaya Çıkarıyoruz. En Son Tekniklerin Sistematik Bir İncelemesi: Özet ve Giriş

İş Akışınızı 10 Kat Nasıl İyileştirirsiniz: 17 Temel Uygulama

Kripto Büyümesi: Etkili Kullanıcı Kişilikleri Oluşturma

Kazanmak için Dokun: Telegram, Solana'dan Önce Sonraki 10 Milyar Kripto Kullanıcısına Katılabilir

Yapay Zekanın Gücünü Ortaya Çıkarıyoruz. En Son Tekniklerin Sistematik Bir İncelemesi: Özet ve Giriş

İş Akışınızı 10 Kat Nasıl İyileştirirsiniz: 17 Temel Uygulama

Kripto Büyümesi: Etkili Kullanıcı Kişilikleri Oluşturma

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps