Bir BT departmanı standart bir Linux dağıtımını nasıl seçmeli?

Hangi Linux dağıtımlarının üretim sunucusu ortamları için uygun olduğu ve bu duyguların pek çoğu dini olarak dayanan görünmediği ve nadiren destekleyici kanıtlarla sunulduğu konusunda pek çok topluluk hissi vardır.

Standardize etmek için bir Linux dağıtımı seçmeye çalıştığımızı varsayalım (çünkü çevremizi mümkün olduğunca homojen tutmaya ilgi duyuyoruz), hangi kriterler önemlidir ve farklı dağılımların bu kriterleri ne kadar iyi karşıladığı konusunda nasıl karar verirsiniz?

Şu anda on yıldan fazla bir süredir Linux kullanan bir ortamda çalışıyorum. Ofisteki herkes masaüstlerinde ve sunucularda farklı dağıtımlar kullanır. Bu nedenle, dağıtım seçimleri belirli bir düzende olmayan bir çok şey etrafında dönme eğilimindedir:

1. Tarihçe - Belli ki RedHat ve Debian gibi sistemler uzun süredir var. Bu nedenle, “kırılmadıysa düzeltmeyin” atasözü bunlar için kullanılabilir. Yazılım bir dağıtımda iyi destekleniyorsa, yükseltme daha kolay hale gelir.
2. Alışkanlık - Tarihe benzer, ancak hepimizin favorileri vardır. Debian'a dişlerimi kestim ve Ubuntu'ya göç ettim (o zamanlar zorlu bir karardı çünkü topluma bağlı olma eğilimindeydim). Tersine, bir düzine farklı dağıtımda işlerin nasıl yapıldığını hatırlamak zorunda kalmak bir acıdır (sıfırdan yapılanlardan bahsetmeden).
3. Destek - Ubuntu'ya göç ettim, çünkü ücretli destek önerdiği kadarıyla yaptıklarını takdir ettim. Bu, bir müşterinin uzun süreli bir sistemi yönetme konusunda endişesi varsa, bir satış noktasıydı. RedHat'ın yaklaşımına benzer (ancak RPM cehennemi devam ediyordu). Bunun için bir takım RedHat sunucularımız da var.
4. Bağımlılıklar - Bazı yazılımların bazı dağıtımlarda kullanımı kolaydır, çünkü bağımlı paketler daha kolay elde edilebilir veya üretilebilir. Bunun bir örneği RedHat'ta geçerli olabilir. Bazı dağıtımlarda bazı yazılımlar için paket yoktur. Ve onu derleyebilirsiniz, ama neden paket orada başka bir dağıtımda olsaydı, neden?
5. Grenliliği - Gentoo gibi dağıtımlar sürüm ve yazılım anahtarı ayrıntılar üzerinde daha iyi bir kontrol sunuyor. Diğer dağıtımlar çeşitli şekillerde "sabitlemeye" sahiptir, ancak bu hala kontrol edilebilir veya güvenilir değildir.
6. Ciltleme - Çoğu dağıtımdan kaynaktan derleme yapmak mümkün olsa da, bazı dağıtımlar diğerlerinden daha iyidir. Projeniz, genişletilmiş işlevsellik için mevcut kitaplıkları yamalarsa bunun bir etkisi olabilir.
7. Güzellik - Bazı dağıtımlar daha iyi görünür . Her inek sadece kabarık olduğunu bilir (ve muhtemelen bugünlerde bir web uygulaması olarak yapmaktan kurtulabilirsiniz), ancak bazı müşteriler bu şeyden şaşırıyor ve hepimiz bunu biliyoruz.
8. Kararlılık - Bazı dağıtımlar, "test etme", "deneysel" vb. Yerine yazılımın "kararlı" sürümlerini yayınlar. Projeniz bittiğinde, "kararlı" olacağına ve güveneceğinize emin olacağınızı bilerek "deneysel" geliştirmeye başlayabilirsiniz.
9. Paket yönetimi - Günlük olarak bir şey geliştiriyorsanız ve tek bir vuruşta 1000 makineye çıkacaksa, muhtemelen bu sistemler arasında paket oluşturmayı, bakımını yapmayı ve izlemeyi kolaylaştıran bir şey istersiniz.
10. Tutarlılık - Bu daha bir argümandır aynı dağıtıma. İnsanlar birçoğunun aksine bir dağıtıma odaklandıklarında daha az hata yapılır (ve güvenlik konusunda daha az hata).
11. Öngörülebilir sürüm takvimi - Yazılımınızın desteklendiğinden emin olmak istiyorsanız, planlanan yükseltmeler belirli bir stabilite sunar.
12. Güvenlik - Bazı dağıtımlar, görevi onaylanan herhangi bir paketteki orijinal güvenlik risklerine derhal yanıt vermek olan aktif güvenlik ekiplerine sahiptir.

Bunlar, her sistemin neden seçildiğinin sebepleriyle ilgili olarak kafamın tepesinden çıkan birkaç şey. Bu kararda hiç kimsenin bir başkasını tercih etmesinin yol gösterici ışığını veya tercihini göremiyorum. Çeşitlilik ve seçim harika olabilir ve bir projenin hızlı bir şekilde başlatılması için size gerçekten çok iyi seçenekler sunar, ancak aynı zamanda sizi asan ilmiktir. Neye ihtiyaç duyacağınızı önceden düşündüğünüzden emin olun. Sistemin ihtiyaç duyduğu şeyleri ve sistemin ne zaman yükseltileceğini veya emekli olacağını planlayın. Her zaman onu koruyacak kişi olacağınızı varsaymayın.

Bir teknoloji uzmanı olarak çalışan deneyimlerimi birkaç farklı alanda paylaşacağım ...

(Dikkat: bu Red Hat ve onunla nasıl profesyonel olarak büyüdüğüm hakkında bir hikaye)

2000-2002 yılları arasında Linux ile profesyonel olarak çalışmaya başladım. Bu, Red Hat ve Red Hat Profesyonel Yayınlarının geniş çapta benimsenmesiydi (6.x, 7.x, 8.0) . Bunlar, paketlenmiş paket setlerinin yanı sıra ücretsiz indirilebiliyordu. Bilgisayar perakende mağazalarında kolayca bulunabilirler.

Benim için bunun hobisi ve ev kullanıcılarını şirkette ortaya çıkmaya başlayan aynı ürünle meşgul etme avantajı vardı . Şu andaki çalışmam, müşteri sunucu sistemlerini ticari birimlerden (HP-UX, AIX ve SCO) Red Hat platformuna taşımaktı.

Maliyet tasarrufu önemliydi! 100k $ + HP9000 PA-RISC sunucularını 40k $ Compaq ProLiant ile değiştirme Intel sunucuları maliyet ve performansta mutlak bir kazanç elde etti.

Peki neden Kırmızı Şapka?

Red Hat bu pazarda ilk, kritik iş, satıcı ve donanım desteği kazandı. Büyük uygulama satıcılarını görmek, anlaşmayı imzalayan bir hedef platform olarak Red Hat kullanıyor. Benim gibi hobisi kullanıcıları, evde edindikleri becerileri kolaylıkla çalışma ortamlarına aktarabildiler. Topluluk büyüyordu. Slashdot , Freshmeat ve LAMP yığınları hüküm sürdü! Linux için iyi bir zamandı.

Bu noktada, özel bir ERP yazılımı çözümü için Linux dağıtımlarının geliştirilmesi ve değerlendirilmesinden sorumluydum. Red Hat ile kaldım. Sık sık, başka bir dağıtım denerdim ( Mandrake , SuSE , Debian , Gentoo ), ancak paketleme, donanım desteği (sunucular veya çevre birimleri), ( topluluğun büyüklüğü) topluluğunun veya başka bir anlaşma kesicisinin sorunlarını bulurdu.

Örnek: Digi Seri genişletme PCI-X kartları ve Esker VSIfax üretim faks yazılımı ile donatılmış Compaq / HP ProLiant donanımı kullanıyordum . Son ikisi sadece Red Hat işletim sistemleri için sürücü desteğine sahipti. Bazı durumlarda, yazılım yalnızca Linux sürümlerinde kolay kullanımın önüne geçmek için ikili veya RPM biçiminde teslim edildi.

Bilgi Teknolojisi Dünyası içinde Momentum hususlar
Kimse önerir biri olmak istiyor kaybeden sonunda yetim alır çözümü veya projeyi, bu nedenle güvenli seçenekleri ile sopa. Güvenilir çalışması ve birkaç katmanı desteklemesi gereken bir teknoloji yığınını yönetiyordum. Bu noktada farklı bir dağıtım seçmek sadece olurdu. olmuştur. sorumsuz.

Red Hat balayı 2003 yılında benim için yazılımın profesyonel baskılarının kesilmesiyle sona erdi . Red Hat Enterprise Linux'un yerini aldı ve bir miktar bagajla geldi ... Maliyet (pahalı abonelik tabanlı model), erişilebilirlik (kullanıcı tabanını ve topluluğunu küçülterek) ve geleceğe dair genel kafa karışıklığı ...

Gentoo, Debian ve SuSE'yi yeniden değerlendirerek alternatifler aramaya başladım. Teknoloji grubumuzun tüm bileşenleri için doğru desteği alamadım. Red Hat ekosistemine bağlı kalmaya zorlandım ... Red Hat Enterprise Linux ile ilgili vahşi maliyet kayması nedeniyle, ömrünün sonlarından yıllar boyunca oldukça değiştirilmiş bir Red Hat 8.0 kullanmaya başladım . RHEL klonları olgunlaşana kadar ( Whitebox Linux ve daha sonra CentOS ) standartlarımdan uzak bir hareket hazırladım.

Red Hat türevlerinin önemli avantajı ve bir ücretli RHEL sürümleri ile ikili-uyumluluğu. RHEL ve CentOS arasında yerinde dönüşüm gerçekleştirmek ve bunun tersi de mümkündür. Bir sonraki kariyerini gerçekleştirene kadar RHEL benzeri sistemler ile çalışmaya devam ettim.

Kendimi daha sonra yüksek frekanslı finansal ticaret endüstrisinde buldum; burada kritik otomasyon sistemleri Ar-Ge ve Linux mühendisliğinden sorumluydum. Bu dünyadaki vurgu , dikkatli bir test ve ayarlama yaparak hız oldu . Yine, donanım desteği önemliydi. Özel ağ kartlarım ve özel donanımım olurduyalnızca RHEL veya RHEL benzeri sistemler için onaylı sunucu donanımı veya uygulama kitaplıkları. Diğer Linux değişkenleri için işlerin derlenebileceği durumlarda bile, topluluk faktörü ortaya çıktı. Bir sorunu araştırmam gereken noktadayken, çoğu zaman Red Hat Bugzilla raporlarındaki notlara ya da yorumlara kadar izlenebilecek bir konu oldu, bazen de bir sonraki sürüm için bir yama ya da talepte bulunabilirdim. .

Düşük gecikmeli ağ ve çekirdek ayarlarına girmeye başladığımda, RHEL çekirdeklerini ve RHEL MRG Realtime çekirdeklerini parçalamaya başladım . Yayınlara ne kadar çalıştığını fark ettim ... vanilya kernel.org çekirdeğine 200'den fazla yama. Yorumları okuyun ve not alın. sysctlAçıkta kalan parametreler veya daha fazla aklı başında gelenler gibi küçük şeyler olabilir . Red Hat, insanlara bu sorunları yamaları, test etmelerini ve düzeltmelerini sağlıyor. Diğer Linux dağıtımlarında da aynı taahhüdü görmedim ... Kurumsal platformun yıllarca gerçek güvenlik, hata düzeltme ve destek desteği alacağının garantili olduğunu ekleyin .

Sonunda sunucu ve masaüstünde neredeyse tamamen Gentoo olan başka bir finans şirketine taşındım ... Bu benim için bir felaketti. Red Hat ve CentOS dünyasından geldiğimde, Gentoo kurulumunda sayısız istikrar ve yönetim sorunuyla karşılaştım. Sürüm kontrolü en büyük sorun oldu, ancak azalan topluluk desteği ve gerçek testlerin eksikliği de endişeliydi. RHEL'i çevreye tanıtmaya başladım çünkü üçüncü parti yazılımlarımızdan bazıları buna ihtiyaç duyuyordu ...

Ancak bir sorun vardı ... Geliştiricilerim Gentoo'ya alıştı ve çekirdek kütüphaneler ve uygulama sürümleri için nispeten kolay yükseltmeler yapıyordu. Red Hat Enterprise Linux'un standart hale getirdiği sabit ana sürümleri ayarlayamadılar. Geliştirme ve sürüm süreci, GLIBC 2.7'nin neden RHEL 5.x'e aşılamadığı veya neden belirli bir derleyici veya kütüphane sürümünün bulunmadığı ile ilgili sorulardan kaynaklandı . RHEL / CentOS’un ana sürümleri arasında yapılan yükseltmelerin esasen tam olarak yeniden yapılması gerektiğini söylediklerinde , çözüme büyük güven duydular.

Bu noktada, Red Hat'in kanamada / liderlikte olmak isteyen geliştiriciler için çok yavaş hareket ettiğini fark ettim. RHEL 6.x çok ihtiyaç duyulan ve hoşgeldin yükseltmesiydi, ancak DevOps ilkelerine abone olan firmalarla ve firmalarla görüşmeye başladığımda bu tema daha belirgin hale geldi .

Bugün ...
Giderek artan sayıda geliştirici ve Linux kullanıcısı Red Hat olmayan, SuSE olmayan, kurumsal olmayan Linux ortamlarından geliyor.

• Ubuntu veya Debian kullanıyorlar ...
• Eski okul donanımları veya büyük satıcı desteği ile uğraşmak zorunda kalmamışlardı.
• Kendi uygulamalarını sıfırdan yazıyorlar (kendi kendine destekli).
• Sanallaştırma ve bulut bilişim donanım katmanını soyutlar, bu nedenle korkak RAID denetleyici sürücüleri, PCI-X çevre birimleri veya ikili dağıtılmış yönetim aracıları hakkında endişelenmek radarda değil.
• Bu kullanıcılar alışkın oldukları araçları ve kullanıcı alanlarını ister.

Dolayısıyla bir çatışma var ... Bu kullanıcılar uygulama veya kütüphane sürümlerinde neden kısıtlandıklarını anlamıyor. Eski okul yöneticileri hala yeni paradigmaya uyum sağlıyorlar . Dinde kökleşmiş görünen argümanlar gerçekten insanların sadece kendi becerilerini nasıl geliştirdiklerini gösteren işlevlerdir.

Bugün okuduğum çok kıdemli DevOps Linux mühendisliği pozisyonu için bir iş ilanı gördüm:

(Tamam Ubuntu ve varyantları. Red Hat yetkin-to-uzman Debian tabanlı Linux dağıtımlarında olmalı fena ama değil tercih edilir)

Sanırım her iki yönde de işe yarıyor ... İş fırsatlarından uzak durdum çünkü yönettiğim 800 CentOS sunucu Ubuntu'ya dönüştürülüyordu. Tabii, Linux Linux ... ama olabileceğim kadar etkili olacağımı hissetmedim ... Debian kurulumlarını karıştırdım ve RPM tabanlı bir dağıtımın kullanılmasını diledim. Çeşitli platformların esası hakkında ateşli tartışmalar yaşadım (genellikle Gentoo'yu listenin altına yerleştiriyordum).

Peki çevreniz için doğru olan nedir? Değişir. Geliştiricilerin kral olduğu organizasyonların yanı sıra sistem mühendislerinin kararları aldığı firmalarda bulundum. En iyi düzenlemenin, geliştiriciler ve sistemleri destekleyen kişilerin platformda hemfikir oldukları durumlarda olduğunu düşünüyorum. Ancak bunun dışında, uzun vadeli destek, kullanılabilirlik, topluluk ve uygulama yığınınıza en uygun şekilde neyin uygun olduğunu düşünün.

Yetenekli bir geliştirici, RHEL veya Debian benzeri bir ortamda çalışabilmelidir. Üstelik, geliştirme platformları üretim ortamını yansıtmalıdır. Oradan git.