FreeBSD'nin bağlantı noktalarını geniş bir ortamda nasıl yönetir ve dağıtırsınız?

19

İnsanların FreeBSD'nin bağlantı noktalarını çevrelerinde nasıl kullandıklarını merak ediyorum. FreeBSD kullanan çoğu insanın gerçekten de Ports (ve ikili dosyalar için yükseltme yapmak için portupgrade) kullandığını varsayıyorum. Bununla birlikte, son sürümlerde işlerin nasıl çalıştığından memnun olmadığım için bu kurulumun nasıl yapıldığıyla ilgileniyorum. Şimdi FreeBSD 9.0 kullanıyorum ve sorun yaşıyorum.

İşleri şu şekilde ayarladım:

/ usr / portları bir düğümden NFS aracılığıyla paylaşılır (her gece 'portnap getirme güncellemesi' ile).
Her düğüm okuma / yazma özelliğine sahiptir.
Tüm düğümlerde /etc/make.conf içinde "WRKDIRPREFIX = / usr / tmp" ayarladım
Portsnap'ı, /usr/local/etc/pkgtools.conf dosyasına aşağıdakileri ekleyerek yerel bir dizin kullanacak şekilde yapılandırdım:

ENV['LOCALINDICES'] ||= '/var/db'

ENV['PORTS_INDEX'] ||= ENV['LOCALINDICES'] + '/INDEX.local'

Başarılı portupgrade -p packagebir paket oluşturmak ve daha sonra portupgrade -P packageikili diğer düğümlere yüklemek için çalıştırabilirsiniz .

Yine de, bazen aşağıdaki sorunu alıyorum: /var/db/INDEX.local:23265:dbm_store failed

Dizin şimdi yerel olarak bulunduğu için sistemde yapabileceğim diğer optimizasyonları düşünemiyorum ve gerçekten ihraç edilen tek şey portlar ağacı ve hiçbir şey düğümlerden oraya yazılmıyor.

freebsd

— vpetersson
kaynak

Bir seçenek, her düğümde tam bir yerel bağlantı noktası ağacına sahip olmak (ve belki de sadece 'distfiles' ve 'paketleri' monte etmek) olacaktır, ancak bu büyük bir alan israfı gibi hissettirir (ve birçok gereksiz güncellemeden bahsetmez).

— vpetersson

vpeterson: Bu sorulması gereken bir soru (şu anda bu konuda engellendim. +5 oy ve 3 yıldız yalnız olmadığımızı gösteriyor). Belki de bu soruyu temizleyin ve çözmeye çalıştığınız bazı sorunları belirtin. (FWIW, birisi sorunuzu kapatmak için oy kullandı. Şahsen ben bunu görmek istiyorum, ya da benzer bir soru kaydedildi).

— Stefan Lasiewski

Soruyu nasıl daha net hale getireceğimden emin değilim. Ayrıca @ voretaq7'nin soruları gerçekten cevapladığını düşünmüyorum, aksine alternatif bir yöntem önerdi. Soru gerçekten konunun ne önerdiği ile ilgilidir - insanlar FreeBSD'nin portlarını çok düğümlü bir ortamda nasıl dağıtırlar.

— vpetersson

13

Geniş bir ortamda liman sisteminden hiç tam olarak memnun kalmadım - İyi çalışması için her zaman dış yönetim uygulamanız gerekiyor gibi görünüyor.

Benim en iyi ipuçları (artan sırayla, "en iyi" çözüm için "en kötü" çözüm):

Her ev sahibini inşa ediyorsanız, yapmayın .
Gerekirse, açıkladığınız gibi okuma-yazma bağları ile NFS üzerinde yapmayın: Bağlantı noktalarına genellikle Doğru Şey Yapmak için güvenebilirsiniz ve alternatif çalışma dizinleri sağlarsanız bağlantı noktaları ağacında durmazsınız, ancak her zaman daha iyidir üzgün olmaktan emin olun: Yerel bir CVS / csup aynası çalıştırın ve tüm ana bilgisayarlarınızı bu kutudan csup edin, ardından tek tek makineler gibi yerel olarak oluşturun.
Evet, bunun ana bilgisayarlarda daha fazla disk alanı ve fazladan bir adım olması anlamına geldiğini biliyorum. Ayrıca neredeyse sorunsuz olduğu garanti edilmektedir.
Uyarı: Her makinede tutarlılık sağlamak için muhtemelen paket yapılandırma dosyalarını (rsync veya benzeri) belirlenmiş bir "yapılandırma ana bilgisayarından" senkronize etmek istersiniz (her düğümde csup kullanmak yerine tüm bağlantı noktaları ağacını yeniden senkronize edebilirsiniz).

Bir Yapı Ana Bilgisayarı kullanın, paketler oluşturun ve bunları kurun.
Her bir makineye inşa etmekten çok daha iyi bir çözüm: Paket oluşturmak için bir yapı ana bilgisayarı kullanın ve araçlarınızı bu paketlere yönlendirin.
Bu, çalıştırdığınız (veya çapraz derleme) her mimari için bir yapı ana bilgisayarı bulundurmak anlamına gelir, ancak sonuçta hedef makineleriniz için daha iyidir (büyük derleme işleri yok, tutarlılık garantisi)

Bir yapılandırma / sistem yönetim aracı kullanın.
Bu, çözdüğüm çözüm - Standart bir sunucu görüntüsü oluşturuyorum ve bunu kullanarak ortamımın etrafına dağıtıyorum radmind. Kukla veya Şef ile benzer şeyler yapabilirsiniz . Bu, bir yapı ana bilgisayarını kullanmanın tüm avantajlarına sahiptir (tutarlılık, bağımsız sunucularda daha az yük) ve yapılandırma yönetiminin avantajını ekler.

Uyarı: Bu, yalnızca makineleriniz "özdeş" ise gerçekten iyi çalışır - Yani hepsine aynı bağlantı noktası setini kurabilirsiniz. Bu olabilir Eğer port setleri değişen varsa çalışır, ancak o ölçüde idari yükü artırır.

Feragatname: Ben liman sorumlusuyum sysutils/radmind. Evet, kabul ettiğim kadar çok beğendim.

Tüm bunlar, çeşitli boyutlu FreeBSD ortamlarını (1-2 makineden 100'ün üzerinde) yönetme deneyimime dayanıyor. Standartlaştırılmış bir görüntüyü zorlayan ve koruyan Konfigürasyon / Sistem Yönetimi araçları, bunu deneyimlerime göre ele almanın en iyi yoludur.

— voretaq7
kaynak

İyi işaretçiler. Geçmişte biraz Kukla ile oynadım ve Ubuntu'da çok sevdim. Ancak, FreeBSD ile ne kadar iyi oynadığından emin değilim. Henüz denemedim. Ne olursa olsun, Kukla ile bile, sanırım bizi kare birliğe geri götüren Portupgrade'i çağırıyor. Daha sonra iyi bir fikir olmazdı pkg_delete / pkg_add veya 'pkg_add -f' yapması gerektiği için çalışabilir başka bir yol görmüyorum. Donanım gittikçe, herkese açık bir bulutta (KVM / Qemu) çalıştıkları için hepsi aynı.

— vpetersson

Donanım ve temel yazılım yapılandırmalarınız aynı ise, tüm sistem görüntüsünü yöneten radmind gibi bir şey öneririm. Kukla ve Şef harika araçlardır, ancak işaret ettiğiniz gibi temel OS ikili dosyalarını çağırırlar, bu da sizi bir yapı ana bilgisayarı ve dağıtım paketleri kullanmada bırakır. radmind, vekil sysadmin olmaya çalışmak yerine dosya sistemi düzeyinde ("Burada olması gerekenler değilse, değiştirin veya kaldırın") yönetimi üstlenerek bunu önler ("Bu komutları çalıştır / bu dosyaları değiştir Kutu").

— voretaq7

Sistemler aynı donanıma sahiptir, ancak aynı konfigürasyonlara sahip değildir. Radmind'e bakmam gerekecek ama bunun en iyi yaklaşım olup olmadığından emin değilim. Kullanılması yerleşik araçlar gerektiğini ben belirgin bir şey kaçırdığınızı görmek için topluma iletmek için yazıyorum neden IMHO, çalışırlar. Bunu yapmaya çalışan tek kişi ben olamam.

— vpetersson

Yerleşik araçlar kesinlikle işe yarıyor, sadece çok fazla yardıma ihtiyaç duyuyorlar (sunucular oluştur, paketlerin yerel dağıtımı, vb.) - Gerçekten bir makineyi yönetmeye yönelikler ve mümkün olduğunca ölçeklendirmiyorlar. Kendi freebsd güncelleme sunucunuzu haddeleme seçeneğini bıraktığımı unutmayın - bunu sadece temel sistemden daha fazlası için denemedim, ancak teorik olarak mümkün.

— Çalıştığını

Evet, aslında ilginç bir fikir. Çok fazla değişiklik yapmadan bağlantı noktaları-paketleri dağıtmakla çalışıp çalışmadığından emin değilim. Büyük sistem sistem yöneticilerinin bunu nasıl yönettiğini merak ediyorum, çünkü FreeBSD'nin çok sayıda büyük kurulumu var. Hepsi kendi çözümlerini yapıyor mu? Eğer öyleyse, bu oldukça garip ve Açık Kaynak-ish değil.

— vpetersson

6

Kimsenin port-mgmt / tinderbox'tan bahsetmemesi garip :

Tinderbox, FreeBSD portları için, sivri yapı kümesinde kullanılan resmi Portbuild betiklerine dayanan bir paket oluşturma sistemidir. Tinderbox, Joe Marcus Clarke tarafından yazılmıştır.

Birden çok hapishane (temel sistem sürümleri) ve birden fazla port tanımlayabilirsiniz. Hapis ve portstree kombinasyonuna yapı denir. Bir Tinderbox hapishanesi FreeBSD'de hapishane olarak algılanan şey değildir, aslında bir chroot'ta verilen bir dünyadır. Tinderbox, bağımlılıkların otomatik olarak izlenmesini destekler ve yalnızca son çalıştırmadan bu yana değişen paketleri yeniden oluşturur. Tinderbox, başarısız derlemeler için e-posta bildirimi desteğine sahiptir. Tinderbox ayrıca ccache ile iyi entegre olur.

Tinderbox, ihtiyacınız olan platformlar ve mimariler için ihtiyacınız olan bağlantı noktası paket setlerini kolayca sağlamak üzere tasarlanmıştır. Tinderbox ayrıca yeni bağlantı noktalarını ve bağlantı noktası yükseltmelerini test etmek için, özellikle de bağımlılıkları ve paket listelerini test etmek için mükemmel bir araçtır. FreeBSD 6.X dünyasını FreeBSD 7.X / 8.X ana bilgisayarında bir hapishane olarak çalıştırabildiğiniz için, çeşitli FreeBSD sürümlerindeki bağlantı noktalarını test etmek için de yararlıdır.

Ayrıca pkgng'a geçmek, paket dağıtımlarını büyük ölçüde basitleştirir.
Github'da göz atın: https://github.com/pkgng/pkgng

— SaveTheRbtz
kaynak

1

Bu, gerçek paketleri farklı bir ortamda (çoklu sürümler, mimariler vb.) Oluşturmak için kesinlikle kullanışlı olsa da, paketleri dağıtma sorununu gerçekten çözmez.

— vpetersson

Tinderbox paketleri HTTP üzerinden kullanılabilir hale getirir, böylece bunu dağıtım çözümünüzü almak için voretaq7'nin cevabındaki yorumlarla birleştirebilirsiniz (örneğin set PACKAGEROOT/ PACKAGESITEve radmind veya Kukla / Şef kullanın).

— James O'Gorman

Evet, ancak paket oluşturmak ve dağıtmak sorun değil. Paketi oluşturmak ve NFS (bir bağlantı noktası ağacı olan veya olmayan) aracılığıyla dağıtmak için portupgrade (-p) kullanabilirim. Sorun şu ki, bu model hala ya a) yerel olarak tam bir bağlantı noktası ağacı ya da b) NFS yoluyla dışa aktarılan ve bizi eldeki soruna geri getiren bir bağlantı noktası ağacı gerektirmektedir.

— vpetersson

2

Portupgrade, kaynaktan inşa ediyorsanız veya ikili paketler kullanıyorsanız yapmanız gerekenleri yapacak - pkg_deleteönce çalıştırılmalı ve ardından yeni sürümü yüklemelisiniz. OpenBSD, yükseltme seçeneği ekleyerek bunu daha iyi halletti pkg_add. Portupgrade'den emin değilsiniz, ancak portmaster tam bir port ağacı değil, sadece INDEX kullanarak çalışabilir.

— James O'Gorman

1

Doğru, ama pkg_delete pek de makul bir yaklaşım değil. Diyelim ki Ruby, Python veya çok sayıda başka paket için önkoşul olan herhangi bir paketi yükseltmek istiyorsunuz. pkg_delete daha sonra bir üretim sistemi için pek bir seçenek olmayan tüm bağımlılıkları silmenizi gerektirir. Portupgrade bununla çok daha iyi bir iş çıkarıyor, ancak yine de ölçeksiz görünüyor.

— vpetersson

3

Sadece iyi ayarlanmış NFS üzerinden / usr salt okunur paylaşarak, / / için usr paket veritabanları taşıyarak ve onlara onlara symlinking 100 + FreeBSD sunucuları yönettik (kesinlikle gerekli değil ama pkg_info ve benzeri sağlar). Bir yönde veya diğerinde hareket ettirilmesi ve işaretlenmesi gereken bir veya iki dosya daha olabilirdi, ancak tüm kurulum bana bir saat sürdü. Çok, çok iyi çalıştı. Ölçekleme sorunları içine koşmak olsaydı ben ek NFS sunucuları eklemek ve iş yükünü bölmek olurdu ama asla gelmedi. Performans benim için hiçbir zaman bir sorun değildi (aslında harikaydı) ama bir md NFS sunucusunun / usr (veya bir kopyasını) koyabilirsiniz sanırım.

— hav
kaynak

Yapılmış paket dosyalarını NFS üzerinden paylaşmak (bahsettiğiniz şey budur?) Kesinlikle başka bir makul yaklaşımdır - daha sonra paketleri yüklemek / yükseltmek için kukla (hatta ev yapımı SSH ve kabuk komut dosyaları) gibi bir şey kullanabilirsiniz. NFS paylaşımından.

— voretaq7

1

Kimsenin maalesef buna iyi bir çözümü olmadığı için görünüyor. Büyük olasılıkla bu, altlık araçlarındaki sınırlamalardan kaynaklanmaktadır.

İşte ortaya koyduğum şey: Tüm liman ağacını ihraç etme fikrini çıkardım. Bunun yerine, her bir düğüme tam bir bağlantı noktası ağacı koydum. Daha sonra NFS üzerine 'paketler' taktım (paketlerin dağıtımını sağlamak için).

Ben de portnap sürecini hızlandırmak için bir önbellek proxy (muhtemelen Squid) kullanmak niyetinde. Bunu blogumda nasıl kuracağımla ilgili kısa bir yazı yazdım .

Referanslar:

— vpetersson
kaynak