Bagaimana Anda mengelola dan menggunakan port FreeBSD di lingkungan yang besar?

19

Saya ingin tahu bagaimana orang-orang menyebarkan porta FreeBSD di lingkungan mereka. Saya berasumsi bahwa kebanyakan orang yang menggunakan FreeBSD memang menggunakan Ports (dan seringkali portupgrade untuk melakukan upgrade dengan binari). Namun saya tertarik pada bagaimana Anda memiliki pengaturan ini, karena saya tidak puas dengan cara kerjanya di versi terbaru. Saya sekarang menjalankan FreeBSD 9.0 dan mengalami masalah.

Saya telah mengatur beberapa hal sebagai berikut:

/ usr / ports dibagi melalui NFS dari satu node (dengan 'portsnap fetch update' setiap malam).
Setiap node me-mount / usr / ports dengan read-write
Saya telah menetapkan "WRKDIRPREFIX = / usr / tmp" di /etc/make.conf di semua node
Saya telah mengkonfigurasi Portsnap untuk menggunakan indeks lokal dengan menambahkan berikut ini ke /usr/local/etc/pkgtools.conf:

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

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

Saya dapat berhasil menjalankan portupgrade -p packageuntuk membangun sebuah paket dan kemudian portupgrade -P packagemenginstal biner pada node lain.

Namun, kadang-kadang saya menerima masalah berikut: /var/db/INDEX.local:23265:dbm_store failed

Saya tidak dapat memikirkan optimasi lain yang dapat saya lakukan untuk sistem, karena indeks sekarang berada secara lokal, dan satu-satunya hal yang benar-benar diekspor adalah port-tree dan tidak ada yang pernah ditulis di sana dari node.

freebsd

— vpetersson
sumber

Salah satu opsi adalah memiliki port-tree lokal penuh pada setiap node (dan mungkin hanya me-mount 'distfiles' dan 'paket'), tetapi ini terasa seperti pemborosan ruang yang sangat besar (dan belum lagi banyak pembaruan yang tidak perlu).

— vpetersson

vpeterson: Ini adalah pertanyaan yang perlu ditanyakan (Saya diblokir pada ini sekarang. Dan +5 suara dan 3 bintang menunjukkan kita tidak sendirian). Mungkin bersihkan pertanyaan ini dan nyatakan beberapa masalah spesifik yang Anda coba selesaikan. (FWIW, seseorang memilih untuk menutup pertanyaan Anda. Secara pribadi saya sangat ingin melihat ini, atau pertanyaan serupa, disimpan).

— Stefan Lasiewski

Saya tidak yakin bagaimana membuat pertanyaan lebih jelas. Saya juga tidak berpikir bahwa @ voretaq7 benar-benar menjawab pertanyaan, tetapi menyarankan metode alternatif. Pertanyaannya adalah benar-benar tentang apa yang disarankan topik - bagaimana orang menyebarkan port FreeBSD di lingkungan multi-node.

— vpetersson

13

Saya tidak pernah puas sepenuhnya dengan sistem port di lingkungan yang besar - Sepertinya Anda perlu menerapkan manajemen eksternal untuk membuatnya berfungsi dengan baik.

Kiat terbaik saya (dalam urutan preferensi naik, solusi "terburuk" ke solusi "terbaik"):

Jika Anda membangun di setiap host, jangan .
Jika Anda harus, jangan lakukan lebih dari NFS dengan mount baca-tulis seperti yang Anda jelaskan: Anda biasanya dapat mempercayai port untuk Melakukan Hal yang Benar dan tidak menginjak pohon port jika Anda memberikan direktori kerja alternatif, tetapi selalu lebih baik untuk aman daripada menyesal: Jalankan mirror CVS / csup lokal dan csup semua host Anda dari kotak itu, lalu buat secara lokal seperti yang Anda lakukan jika mereka adalah mesin individual.
Ya, saya tahu ini berarti memiliki lebih banyak ruang disk pada host dan langkah tambahan. Ini juga hampir dijamin bebas masalah.
Peringatan: Anda mungkin ingin menyinkronkan file konfigurasi paket (rsync atau serupa) dari "host konfigurasi" yang ditunjuk untuk memastikan konsistensi pada setiap mesin (Anda bahkan dapat rsync seluruh port tree jika Anda mau, daripada menggunakan csup pada setiap node).

Gunakan Build Host, buat paket, dan instal itu.
Solusi yang jauh lebih baik daripada membangun di masing-masing mesin: Gunakan host build untuk membuat paket, dan arahkan alat Anda ke paket tersebut.
Ini berarti menjaga build host tetap ada untuk setiap arsitektur yang Anda jalankan (atau kompilasi silang), tetapi pada akhirnya lebih baik untuk mesin target Anda (tidak ada pekerjaan kompilasi besar, jaminan konsistensi)

Gunakan alat manajemen konfigurasi / sistem.
Ini adalah solusi yang saya gunakan - saya membangun image server standar dan menggunakannya di lingkungan saya radmind. Anda dapat melakukan hal serupa dengan Wayang atau Koki . Ini memiliki semua keuntungan menggunakan build host (konsistensi, lebih sedikit memuat pada masing-masing server), dan menambahkan manfaat manajemen konfigurasi.

Peringatan: Ini hanya berfungsi dengan sangat baik jika mesin Anda "identik" - Artinya Anda dapat menginstal set port yang sama pada semuanya. Ini dapat berfungsi jika Anda memiliki beragam set port, tetapi hal itu secara substansial meningkatkan overhead administrasi.

Penafian: Saya pengelola pelabuhan sysutils/radmind. Ya, saya sangat menyukainya sehingga saya mengadopsinya.

Semua ini didasarkan pada pengalaman saya mengelola berbagai lingkungan FreeBSD ukuran (mulai dari 1-2 mesin hingga lebih dari 100). Alat Konfigurasi / Sistem Manajemen yang mendorong dan memelihara gambar standar adalah cara terbaik untuk menangani hal ini dalam pengalaman saya.

— voretaq7
sumber

Petunjuk bagus. Saya telah bermain dengan Wayang sedikit di masa lalu, dan menyukainya di Ubuntu. Namun, saya tidak yakin seberapa bagus kinerjanya dengan FreeBSD. Saya belum mencobanya. Apapun, bahkan dengan Wayang, saya pikir itu memanggil Portupgrade, yang membawa kita kembali ke titik awal. Saya tidak melihat cara lain itu bisa bekerja, karena kemudian perlu melakukan pkg_delete / pkg_add atau 'pkg_add -f' yang tidak akan menjadi ide yang baik. Sejauh peranti kerasnya - semuanya identik sejak dijalankan di cloud publik (KVM / Qemu).

— vpetersson

Jika konfigurasi perangkat keras dan perangkat lunak dasar Anda identik, saya akan menyarankan sesuatu seperti radmind, mengelola seluruh gambar sistem. Puppet dan Chef adalah alat yang hebat, namun seperti yang Anda tunjukkan, mereka memanggil binari OS yang mendasarinya, yang membuat Anda kembali menggunakan build host dan mendistribusikan paket. radmind menghindari ini dengan mengambil alih manajemen di tingkat filesystem ("Jika bukan apa yang seharusnya ada di sini, ganti atau hapus") daripada mencoba menjadi sysadmin pengganti ("Jalankan perintah ini / ubah file-file ini agar saya dapat mengkonfigurasi kotak").

— voretaq7

Ya, sistem memiliki perangkat keras yang identik, tetapi tidak dengan konfigurasi yang identik. Saya harus melihat ke Radmind tetapi saya tidak yakin apakah itu pendekatan terbaik. Menggunakan alat bawaan harus bekerja IMHO, itulah sebabnya saya menjangkau komunitas untuk melihat apakah saya melewatkan sesuatu yang jelas. Saya hampir tidak bisa menjadi satu-satunya yang mencoba melakukan ini.

— vpetersson

Alat bawaan pasti berfungsi, mereka hanya membutuhkan banyak bantuan (membangun server, distribusi paket lokal, dll.) - Mereka benar-benar diarahkan untuk mengelola satu mesin, dan tidak menskalakan sebaik yang mereka bisa. Perhatikan bahwa saya mengabaikan opsi untuk menggulirkan server pembaruan freebsd Anda sendiri - Saya belum pernah mencoba ini lebih dari sekadar sistem basis, tetapi secara teori memungkinkan. Saya hanya terjebak pada hal-hal yang saya tahu bekerja :)

— voretaq7

Ya, itu ide yang menarik sebenarnya. Saya hanya tidak yakin apakah itu akan berfungsi dengan mendistribusikan paket-paket tanpa banyak modifikasi. Saya benar-benar ingin tahu bagaimana sysadmin sistem besar mengelola ini, karena ada banyak penyebaran FreeBSD. Apakah mereka semua memberikan solusi mereka sendiri? Jika demikian, itu terasa sangat aneh dan tidak terlalu Open Source-ish.

— vpetersson

6

Aneh bahwa tidak ada yang menyebutkan ports-mgmt / tinderbox :

Tinderbox adalah sistem pengembangan paket untuk port FreeBSD, berdasarkan skrip Portbuild resmi yang digunakan pada cluster building pointyhat. Tinderbox ditulis oleh Joe Marcus Clarke.

Anda dapat mendefinisikan banyak penjara (versi sistem dasar) dan beberapa portstrees. Kombinasi jail dan portstree disebut build. Penjara Tinderbox bukanlah apa yang dipahami sebagai penjara di FreeBSD, itu sebenarnya adalah dunia tertentu dalam chroot. Tinderbox mendukung pelacakan dependensi secara otomatis dan hanya membangun kembali paket yang berubah sejak dijalankan terakhir. Tinderbox memiliki dukungan untuk pemberitahuan email tentang bangunan yang gagal. Tinderbox juga terintegrasi dengan baik dengan ccache.

Tinderbox dirancang untuk dengan mudah menyediakan paket set port yang Anda butuhkan, untuk platform dan arsitektur yang Anda butuhkan. Tinderbox juga merupakan alat yang sangat baik untuk menguji port baru dan peningkatan port, terutama untuk menguji dependensi dan daftar pengepakan. Ini juga berguna untuk menguji port pada berbagai rilis FreeBSD, karena Anda dapat menjalankan FreeBSD 6.X world sebagai jail pada host FreeBSD 7.X / 8.X.

Juga beralih ke pkgng sangat menyederhanakan penyebaran paket.
Lihat di github: https://github.com/pkgng/pkgng

— SaveTheRbtz
sumber

1

Walaupun itu mungkin berguna untuk membangun paket aktual dalam lingkungan yang beragam (beberapa versi, arsitektur dll), itu tidak benar-benar menyelesaikan masalah penggelaran paket.

— vpetersson

Tinderbox menyediakan paket melalui HTTP, sehingga Anda dapat menggabungkan ini dengan komentar pada jawaban voretaq7 untuk mendapatkan solusi penyebaran Anda (mis. Set PACKAGEROOT/ PACKAGESITEdan gunakan radmind atau Puppet / Chef).

— James O'Gorman

Ya, tetapi membangun dan mendistribusikan paket bukanlah masalah. Saya dapat menggunakan portupgrade (-p) untuk membangun paket dan mendistribusikannya melalui NFS (dengan atau tanpa port-tree). Masalahnya adalah bahwa model ini masih memerlukan a) pohon port lengkap secara lokal, atau b) pohon port yang diekspor melalui NFS, yang membawa kita kembali ke masalah.

— vpetersson

2

Portupgrade akan melakukan apa yang harus Anda lakukan jika Anda membangun dari sumber atau menggunakan paket biner - pkg_deleteharus dijalankan terlebih dahulu dan kemudian instal versi baru. OpenBSD telah menangani ini dengan lebih baik dengan memasukkan opsi pemutakhiran di pkg_add. Tidak yakin tentang Portupgrade tetapi portmaster dapat bekerja hanya dengan menggunakan INDEX dan bukan pohon port lengkap.

— James O'Gorman

1

Benar, tapi pkg_delete bukan pendekatan yang masuk akal. Katakanlah Anda ingin meningkatkan Ruby, Python atau paket lain yang merupakan prasyarat untuk sejumlah besar paket lainnya. pkg_delete akan mengharuskan Anda untuk menghapus semua dependensi, yang hampir tidak merupakan opsi untuk sistem produksi. Portupgrade melakukan pekerjaan yang jauh lebih baik dengan ini, tapi sekali lagi, sepertinya tidak skala.

— vpetersson

3

Saya telah mengelola 100+ server FreeBSD dengan hanya membagikan / usr read-only melalui NFS yang telah disetel dengan baik, memindahkan basis data paket dari / var ke / usr dan menghubungkannya dengan mereka (tidak terlalu diperlukan tetapi memungkinkan pkg_info dan semacamnya). Mungkin ada satu atau dua file lain yang perlu dipindahkan dalam satu arah atau yang lain dan disinkronkan, tetapi keseluruhan pengaturan membutuhkan waktu sekitar satu jam untuk mencari tahu. Itu bekerja dengan sangat baik. Seandainya saya mengalami masalah penskalaan saya akan menambahkan server NFS tambahan dan membagi beban kerja tetapi tidak pernah muncul. Kinerja tidak pernah menjadi masalah bagi saya (sebenarnya itu hebat) tapi saya kira Anda bisa menempatkan server NFS / usr (atau salinannya) pada md.

— bulu halus
sumber

Berbagi file paket yang dibangun melalui NFS (yang sepertinya Anda bicarakan?) Tentu saja merupakan pendekatan masuk akal lainnya - Anda kemudian dapat menggunakan sesuatu seperti boneka (atau bahkan skrip SSH-and-shell buatan sendiri) untuk menginstal / meningkatkan paket dari bagian NFS.

— voretaq7

1

Sayangnya tidak ada yang mendapat solusi yang baik untuk ini. Kemungkinan besar ini disebabkan oleh keterbatasan dalam alat yang mendasari.

Inilah yang saya pikirkan: Saya membatalkan ide untuk mengekspor seluruh port-tree. Sebaliknya, saya menyerah dan meletakkan pohon port penuh pada setiap node. Saya kemudian memasang 'paket' melalui NFS (untuk mengaktifkan distribusi paket).

Saya juga bermaksud untuk menggunakan proxy caching (mungkin Squid) untuk mempercepat proses portnap. Saya menulis posting singkat tentang cara mengatur ini di blog saya.

Referensi:

— vpetersson
sumber