Bagaimana cara si kecil belajar dan menggunakan Wayang secara efektif? [Tutup]


109

Enam bulan lalu, dalam proyek nirlaba kami, kami memutuskan untuk mulai memigrasikan manajemen sistem kami ke lingkungan yang dikendalikan Wayang karena kami mengharapkan jumlah server kami tumbuh secara substansial antara sekarang dan satu tahun dari sekarang.

Karena keputusan telah dibuat, orang-orang IT kita menjadi agak terlalu jengkel, terlalu sering. Keberatan terbesar mereka adalah:

  • "Kami bukan programmer, kami sysadmin";
  • Modul tersedia online tetapi banyak yang berbeda satu sama lain; roda sedang diciptakan kembali terlalu sering, bagaimana Anda memutuskan mana yang sesuai dengan tagihan;
  • Kode dalam repo kami tidak cukup transparan, untuk menemukan bagaimana sesuatu bekerja mereka harus berulang melalui manifes dan modul mereka bahkan mungkin telah menulis sendiri beberapa waktu lalu;
  • Satu daemon baru membutuhkan penulisan modul baru, konvensi harus serupa dengan modul lain, proses yang sulit;
  • "Ayo jalankan saja dan lihat cara kerjanya"
  • Banyak 'ekstensi' yang hampir tidak dikenal dalam modul komunitas: 'trocla', 'augeas', 'hiera' ... bagaimana sysadmin kami dapat melacak?

Saya bisa melihat mengapa sebuah organisasi besar akan mengirim sysadmin mereka ke kursus wayang untuk menjadi master wayang. Tetapi bagaimana pemain yang lebih kecil bisa belajar Wayang ke tingkat profesional jika mereka tidak pergi ke kursus dan pada dasarnya mempelajarinya melalui browser dan editor mereka?

Jawaban:


101

Saya mulai menggunakan Wayang sebelum menggunakan infrastruktur baru dan hanya membeli buku (yang dianggap baik ) tentang topik itu. Saya tidak berpikir kebanyakan orang benar-benar mendapatkan pelatihan Wayang profesional. Saya mengerjakan contoh sampai saya bisa mencetak proses ke lingkungan saya. Ini adalah Desember 2011, jadi dalam beberapa minggu, saya dapat memahami dasar-dasarnya dan mendapatkan kerangka kerja produksi. Saya bukan orang baru dalam manajemen konfigurasi, memiliki latar belakang CFEngine , tetapi banyak masalah sysadmin Anda beresonansi. Saya membuat kesalahan dan harus melakukan refactor beberapa kali, tetapi saya berhasil menyelesaikan pekerjaan dengan memuaskan.

Beberapa catatan tentang poin Anda ...

  • Peran administrasi sistem tradisional berubah. Beradaptasi atau tertinggal. Saya telah menjadi insinyur sistem yang sukses, tetapi saya juga harus memperlengkapi kembali (belajar Python, misalnya). Fokus pada masing-masing server berkurang karena abstraksi perangkat keras melalui virtualisasi dan layanan cloud publik dan swasta mendapatkan traksi. Ini berarti otomatisasi tugas-tugas sistem dan penggunaan manajemen konfigurasi untuk merebut kendali dari sejumlah besar server. Tambahkan konsep DevOps ke dalam campuran, dan Anda akan melihat bahwa harapan dan persyaratan pelanggan / pengguna akhir berubah.

  • Modul boneka yang tersedia online berbeda dalam gaya dan struktur dan ya, saya melihat banyak upaya yang tumpang tindih, redundansi, dan duplikat. Salah satu pengembang tempat saya bekerja berkata, "Anda bisa mengembangkan alat sendiri ketika Anda menghabiskan waktu mencari daring untuk sesuatu yang berfungsi!" Itu membuat saya terdiam ketika saya menyadari bahwa Wayang tampaknya lebih menarik bagi tipe pengembang daripada admin yang mencari praktik terbaik atau pendekatan cara yang benar .

  • Dokumentasikan banyak untuk merasakan bagaimana hal-hal terhubung. Dengan definisi yang lemah dan kurangnya cara standar untuk melakukan sesuatu, struktur manajemen konfigurasi Anda benar-benar unik untuk lingkungan Anda. Transparansi itu harus dikembangkan di dalam.

  • Saya berpendapat bahwa cukup mudah untuk menduplikasi modul untuk mengakomodasi daemon baru atau menambahkan layanan ke manifes yang ada, tergantung pada bagaimana Anda mengatur server dan peran Anda.

  • Saya menghabiskan banyak waktu menguji pada satu target sebelum mendorong perubahan ke grup server yang lebih besar. Menjalankan puppetd secara langsung di server perwakilan memungkinkan saya untuk men-debug perubahan dan menilai dampaknya. Mungkin itu agak konservatif, tapi itu perlu.

  • Saya tidak yakin seberapa besar saya akan bergantung pada modul komunitas. Saya memang harus mulai menggunakan Augeas untuk beberapa pekerjaan , dan menyesalkan fakta bahwa itu adalah fungsi yang saya terima begitu saja di CFEngine.

Secara keseluruhan, saya merasa seperti tidak ada standar yang jelas dalam hal Wayang. Saya mengalami kesulitan mencari tahu bagaimana mengatur struktur direktori pada Puppetmaster saya, memahami cara mengelola penandatanganan sertifikat, mendapatkan DNS terbalik yang tepat di mana-mana, membuat Wayang untuk skala secara tepat untuk lingkungan dan memahami kapan harus meningkatkan modul komunitas dibandingkan membangun saya sendiri. Ini adalah pergeseran dalam pemikiran dan saya melihat bagaimana itu akan membuat panik sysadmin. Namun, ini juga solusi yang dibangun dari awal, jadi saya memiliki kemewahan untuk mengevaluasi alat. Keputusan untuk bertindak seperti ini didasarkan pada mindshare dan momentum di balik Wayang. Itu sepadan dengan usaha untuk mempelajari sesuatu yang baru.

Ingat, situs ini juga sumber yang bagus.


20
Saya beralih dari tidak memiliki pengalaman tentang Wayang ke lingkungan lengkap saya dikelola dalam dua minggu datar. Saya bertanggung jawab untuk ~ 40 mesin virtual, walaupun semuanya menjalankan Ubuntu. Hal-hal yang disederhanakan cukup sedikit. Saya seorang pengembang berdasarkan profesi. "Adaptasi atau ditinggalkan" - Saya sekarang devops + sysadmin + arsitek. Jawaban yang sangat bagus!
François Beausoleil

Saya akan merekomendasikan mereka untuk mulai menggunakan layanan kecil, pertama di standalone kemudian mulai bermain-main dengan lebih banyak server. Saya tidak harus bekerja dengan Puppet, tapi saya punya VPS kecil dan saya baru-baru ini membuat modul Puppet saya sendiri. Jika mereka ingin mengikuti perkembangan para sysadmin di abad ini, mereka sebaiknya berpikiran terbuka. Saya melakukannya karena saya suka, dan saya kira tidak semua orang suka mempelajari hal-hal baru, tetapi satu hal yang pasti, saat ini sysadmin lebih dekat dengan pengembang daripada sebelumnya.
Sergio Galvan

2
Saya bekerja di sebuah perusahaan kecil dan saya juga menjalankan puppetd -tpengujian beberapa kotak sebelum mendorong ke semua server. Tidak pernah gagal bahwa pasangan memiliki sesuatu yang unik yang menyebabkan pembaruan saya gagal. Wayang jauh lebih mudah ketika Anda memiliki lingkungan yang terkendali dan konsisten untuk permulaan.
jordanm

1
@ewwhite, saya telah mengerjakan tutorial Puppet dalam dokumen mereka tetapi bertanya-tanya buku apa yang Anda gunakan saat belajar? Saya merasa tutorial yang disediakan dalam dokumen tidak ada yang menjaga semuanya agar tidak mengklik dengan saya karena saya bekerja dengan Wayang pada host pengujian untuk mempelajari apa yang saya lakukan. EDIT: Atau sumber daya tambahan apa pun yang dapat Anda rekomendasikan. Terima kasih.
Mike Keller

1
@MikeKeller Saya suka di posting saya ... Tapi ini tersedia di sini .
ewwhite

29

Pada pekerjaan sebelumnya, saya diberi tugas melakukan uji coba implementasi Wayang. Sekarang, saya memiliki latar belakang pemrograman, meskipun bukan Ruby, jadi saya tidak memiliki banyak masalah seperti yang lainnya.

Namun, menarik untuk dicatat bahwa programmer tanpa pengalaman dengan paradigma non-tradisional memiliki masalah dengan Wayang juga, karena Wayang adalah deklaratif , bukan keharusan. Dalam hal ini, Wayang bekerja seperti halnya file konfigurasi: Anda mengatakan bagaimana keadaannya, dan Wayang mengurus sisanya.

Setelah pilot saya mendapat kesempatan untuk melatih selusin admin lainnya dengan Wayang, ditambah memberikan presentasi tentang hal itu di dua acara. Menurut saya dari pengalaman itu adalah bahwa beberapa admin mengambilnya, dan beberapa tidak. Ini semua adalah admin tradisional, tanpa keterampilan pemrograman, dan berbagai tingkat keahlian.

Satu hal khusus yang saya perhatikan adalah bahwa Wayang membutuhkan latihan terus - menerus . Orang-orang yang dilatih, menulis modul, dan kemudian menghabiskan satu atau dua bulan melakukan sesuatu yang lain kembali ke Wayang dengan sedikit keterampilan yang berguna. Orang yang terus melakukan hal-hal kecil di dalamnya setiap minggu tidak pernah kehilangan kemampuannya.

Berdasarkan dua pengamatan ini, saya sarankan Anda memastikan semua orang terus menambahkan beberapa kelas Wayang, definisi atau modul setiap minggu (lebih disukai setidaknya dua atau tiga kali). Mereka yang masih belum terbiasa dengan itu mungkin benar-benar tidak memiliki keterampilan untuk melakukannya.

Kemudian lagi, jika Wayang dikenakan pada mereka dari tingkat yang lebih tinggi, mereka mungkin hanya bereaksi terhadap apa yang mereka anggap sebagai manajemen yang mengganggu dalam cara mereka melakukan pekerjaan mereka - yang sebenarnya cukup benar. Mungkin saja mereka membiarkan mereka memilih sistem manajemen konfigurasi mana yang akan digunakan untuk memperbaiki keadaan. Berikut ini beberapa alternatif:

  • ANSIBLE : Ini baru, tetapi didasarkan pada perintah shell dan ssh, yang mungkin membujuknya untuk sysadmin tradisional.
  • Chef : Mungkin masalah mereka adalah gaya deklaratif, dalam hal ini Chef akan lebih baik jika mereka memiliki pengalaman Ruby.
  • SaltStack : Berbasis Python, dan open-source
  • CFEngine : tua, cepat, tradisional - mungkin memenangkan mereka dengan alasan itu.

12
Hal yang menyenangkan tentang ANSIBLE adalah ia bekerja melintasi jarak galaksi tanpa penundaan dalam pengiriman data!
Kalamane

1
Terima kasih telah menyebutkan ANSIBLE. Saya tidak menyadarinya sampai sekarang.
ewwhite

@ewwhite Sama-sama. Saya sendiri baru saja menemukannya, tetapi banyak hal yang menarik perhatian saya. Jika kita belum begitu banyak di Wayang, saya pasti akan mencobanya.
Daniel C. Sobral

11

Saya telah menggunakan Wayang lebih dari dua tahun di toko-toko kecil di mana saya adalah satu-satunya sysadmin. Rintangan terbesar yang saya miliki adalah belajar bagaimana mengembangkan perangkat lunak dengan benar. Tidak ada satu minggu pun yang berlalu dimana saya tidak mengacaukan sesuatu yang saya katakan kepada pengembang untuk tidak melakukan selusin kali. Saya memeriksa terlalu banyak kode, saya tidak memecah checkin, saya tidak menandai, saya tidak bercabang, tidak menjalankan pemeriksa sintaksis, tidak menggunakan standar, dll. Jika Anda baru memulai Saya akan merekomendasikan beberapa hal berikut.

  1. Sadarilah bahwa Anda sedang mengembangkan perangkat lunak yang Anda sendiri tidak tahu bagaimana melakukannya atau melakukannya dengan buruk. Ini diharapkan karena ini baru.
  2. Infrastruktur sebagai kode adalah kenyataan dan sekali Anda mengatasi punuk itu cukup kuat. Saya akan mengundang beberapa pengembang, menunjukkan kepada mereka proses pengembangan Anda saat ini (atau kurang dari itu), jangan tersinggung ketika mereka mengangkat alis, dan menanggapi saran mereka dengan serius. Saya akan merekomendasikan menggunakan sistem dan proses apa pun yang digunakan pengembang Anda kecuali itu sepenuhnya tidak pantas.
  3. Modul boneka pihak ketiga menyedot 90% dari waktu. Saya akan membacanya. Saya akan mencuri ide dari mereka. Saya tidak akan menarik mereka ke sistem saya tanpa suntingan besar. Namun saya akan menarik stdlib boneka yang menambahkan beberapa fungsi yang bagus.
  4. augeas dan hiera. Pelajari keduanya. Yang pertama memungkinkan pengeditan kompleks file yang ada di tempat. Yang kedua adalah penyimpanan data eksternal.
  5. Pisahkan kode dari data. Ini adalah salah satu konsep yang lebih sulit untuk dipelajari. Nilai-nilai hardcoding seperti Host Pemantauan ke dalam kode modul Anda buruk. Menempatkan mereka di penyimpanan data (db, yaml (Hiera menggunakan ini sebagai default), csv, apa pun) yang dapat dikonsumsi modul Anda baik. Contohnya adalah webapp yang menggunakan Mysql. Apa ini memungkinkan adalah kemampuan untuk mendorong kode dan data secara terpisah. Ini membuat proses pengembangan Anda lebih sederhana.
  6. parser puppy memvalidasi dan puppet-lint sebagai bagian dari proses checkin kode pra atau posting. Juga tes rspec mungkin merupakan ide bagus setelah Anda siap.
  7. tulis panduan gaya / kode standar dan gunakan itu. "di mana kode yang menginstal Apache" adalah masalah umum. Jika modul Anda sebagian besar sama, itu harus mudah.

Singkatnya saya telah menemukan semua masalah ini dan begitu juga sebagian besar teman sysadmin saya. Butuh beberapa waktu untuk menjadi ahli dalam menggunakan sistem manajemen konfigurasi. Setelah Anda melakukannya, Anda akan bertanya-tanya bagaimana Anda pernah hidup tanpa itu. "Masuk ke server dan buat perubahan secara manual? Ya."


Terima kasih atas saran Anda, terutama augeas dan hiera adalah dua komponen yang telah kami mulai laksanakan dan ini membuat kami jauh lebih sadar, bahkan percaya diri dengan kemampuan Wayang. Jadi terima kasih :-)
drumfire

7

Enam bulan lalu, dalam proyek nirlaba kami, kami memutuskan untuk mulai memigrasikan manajemen sistem kami ke lingkungan yang dikendalikan Wayang karena kami mengharapkan jumlah server kami tumbuh secara substansial antara sekarang dan satu tahun dari sekarang.

Kedengarannya seperti ide yang sangat bagus untuk memulai lebih awal - Wayang lebih dari sekedar manajemen konfigurasi, ini adalah bentuk dokumentasi.

Karena keputusan telah dibuat, orang-orang IT kita menjadi agak terlalu jengkel, terlalu sering.

Mereka membutuhkan penyesuaian sikap.

"We're not programmers, we're sysadmins";

Sekali lagi, sikap. Anda -dapat- membuat file conf untuk server kan? Anda dapat mempermudah ke dalam templating / 'programmer' stuff saat kebutuhan dan kompleksitas Anda berkembang .

Modul tersedia online tetapi banyak yang berbeda satu sama lain; roda sedang diciptakan kembali terlalu sering, bagaimana Anda memutuskan mana yang sesuai dengan tagihan;

Salah satu yang sulit dijawab - saya selalu lebih suka modul puppetlab daripada kebanyakan - dan bahkan pada saat itu, saya tidak menggunakan banyak. Panggilan penghakiman pasti. Menurut pendapat saya, beberapa modul 'terlalu berenda'.

Kode dalam repo kami tidak cukup transparan, untuk menemukan bagaimana sesuatu bekerja mereka harus berulang melalui manifes dan modul mereka bahkan mungkin telah menulis sendiri beberapa waktu lalu;

Ini tidak terdengar seperti masalah boneka, tetapi lebih merupakan masalah organisasi atau dokumentasi?

Satu daemon baru membutuhkan penulisan modul baru, konvensi harus serupa dengan modul lain, proses yang sulit;

Daemon itu bisa menjadi kelas jika cukup sederhana untuk dikelola. Saya tidak yakin apa yang Anda maksud dengan konvensi, boneka memberlakukan konvensi pada Anda dengan cukup baik bukan? Atau apakah kita berbicara sepanjang garis pemformatan kode?

"Let's just run it and see how it works"

Bukan ide yang buruk jika Anda menganggapnya lambat dan aman. Saya masih mulai dengan VM untuk mendapatkan intinya.

Banyak 'ekstensi' yang hampir tidak dikenal dalam modul komunitas: 'trocla', 'augeas', 'hiera' ... bagaimana sysadmin kami dapat melacak?

postfix, exim, sendmail, mysql, postgresql, iftop, iptraf, perl, perl modul .. Pilih yang Anda inginkan dan gunakan? Saya kira ini terdengar seperti sikap lagi ...

Saya bisa melihat mengapa sebuah organisasi besar akan mengirim sysadmin mereka ke kursus wayang untuk menjadi master wayang. Tetapi bagaimana pemain yang lebih kecil bisa belajar Wayang ke tingkat profesional jika mereka tidak pergi ke kursus dan pada dasarnya mempelajarinya melalui browser dan editor mereka?

Saya tidak menghadiri kursus setiap - sementara saya saya seorang programmer lebih dari sysadmin, saya menemukan itu tidak membutuhkan keahlian pemrograman banyak untuk mendapatkan sesuatu dicapai.

Dokumentasi Wayang, bila diikuti cukup teliti. Perhatikan tipe bawaan dan luangkan waktu untuk melihat bagaimana modul lain disatukan. Saya tidak akan mengatakan itu -super- mudah, tetapi juga bukan -ardih. Butuh sedikit waktu untuk menyiapkan infrastruktur Anda untuk boneka, tetapi waktu yang diinvestasikan dijamin akan dihabiskan dengan baik ketika Anda melakukan ekspansi.


FYI ini datang dari seseorang yang baru saja selesai menyiapkan infrastruktur mereka. Jadi saya punya pengalaman baru dan tidak bisa mengatakan itu adalah waktu yang terbuang.
thinice

Sebagai pemula baru-baru ini, saya mengenali diri saya sepenuhnya dalam komentar Anda.
Martijn Heemels

1
Dalam kasus saya, perubahan sikap memang perlu. Ops menyukai otomatisasi dan sering membuat skrip, jadi sebagian besar masalah menggunakan alat yang berbeda. Rasanya keren melihat manifes Wayang Anda mengonfigurasi seluruh mesin atau layanan baru dari awal. Fakta bahwa kesalahan dapat berdampak pada banyak mesin sekaligus mengharuskan untuk terbiasa dengan pengujian yang lebih ketat, yang dapat mengganggu tetapi jelas merupakan hal yang baik. Bereksperimenlah dengan Vagrant, rspec-puppet, puppet-lint, Geppetto, cabang Git dan alat gratis lainnya dan Anda akan segera menemukan alur kerja favorit Anda.
Martijn Heemels

1
Bekerja dengan Puppet juga membantu saya mempelajari Ruby, yang telah menggantikan Bash sebagai bahasa alat sistem default saya.
Martijn Heemels

5

KISS (Keep it simple stupid) - Jangan menggunakan teknologi baru hanya karena mereka ada di sana karena Anda memiliki persyaratan untuk itu, gunakan minimum yang diperlukan penyebaran Anda, perbarui sebagaimana diperlukan jangan mencoba untuk mengikuti pendarahan tepi. Jika Anda mulai dengan pengaturan dasar dan membangunnya agar lebih mudah untuk diambil saat Anda pergi, dan mereka seharusnya tidak memerlukan kursus (apakah ini bahkan tersedia?).

Area lain yang bisa Anda lihat adalah sysadmin Anda. Jika mereka tidak dapat memprogram juga, apakah mereka cukup maju untuk penyebaran besar, di mana sebagian besar pekerjaan perlu dituliskan alat apa pun yang Anda gunakan?


4
... karena kami mengharapkan jumlah server kami tumbuh secara substansial antara sekarang dan satu tahun dari sekarang. Kebutuhan?
Jeff Ferland

1
Sangat tergantung pada seberapa yakin harapan itu dan apakah apa yang Anda tempatkan masih akan sesuai pada saat kebutuhan benar-benar muncul.
JamesRyan

Memberi +1 untuk "gunakan seminimal mungkin yang diperlukan penyebaran Anda" - Banyak masalah boneka yang saya hadapi karena mencoba membuat boneka mengendalikan segalanya di sistem.
Sirex

5

Saya bekerja untuk nirlaba juga dan bertanggung jawab untuk awalnya membawa kotak Linux di rumah dan tak lama kemudian Wayang untuk mengelola mereka. Ada beberapa hal spesifik yang telah kami lakukan yang benar - benar membantu menyelesaikan berbagai hal.

Pertama dan terutama saya sudah mencoba untuk menjauh dari modul pihak ketiga. Alat bawaan menangani 90% dari manajemen kami. Utilitas pihak ketiga terbesar yang saya gunakan adalah modul firewall. Setiap fakta khusus, dll dikembangkan dengan seluruh tim yang terlibat. Kami mengembangkan modul template dan menjaga manajemen file, paket, layanan, dll semua standar dari template ini.

Kedua, setelah melakukan standarisasi penggunaan modul inbuilt, kami mulai menggunakan Git dan Atlassian's Crucible - omong-omong, gratis untuk nirlaba - untuk melakukan review semua perubahan konfigurasi. Ini memberikan transparansi yang diinginkan.

Ketiga, saya mengotomatiskan pengaturan untuk Wayang sehingga host baru dapat ditambahkan secara otomatis dengan serangkaian opsi default. Ada beberapa cara untuk mengatasi ini. Karena saya sudah memiliki lingkungan Kickstart yang lengkap, saya memilih untuk menambahkan skrip di sana.


4

"Kami bukan programmer, kami sysadmin"

Bagaimana waktu saya telah berubah, menjadi lebih buruk: seorang greybeard seperti saya diharapkan menjadi programmer yang lebih baik daripada programmer profesional, jika tidak, tidak akan pernah bisa lulus untuk administrator sistem .

Sekarang, kami memiliki "administrator sistem", yang pada dasarnya adalah pengguna desktop Windows yang pada suatu saat dikonversi ke Linux dan tidak dapat memprogram, dan tidak menemukan kesalahan apa pun dengan itu.

Gajah di ruangan itu adalah mengapa manajemen mentolerir sikap destruktif seperti itu. Merusak siapa atau apa? Untuk bisnis dan infrastruktur.

Kembali ke Puppet [, CFEngine, Chef] subjek: begitu seseorang menentukan solusi seperti itu, ia akan kalah. Semua orang kalah. Mengapa? Karena siapa pun yang datang dengan ide tersebut tidak mampu merancang manajemen konfigurasi enkapsulasi dalam bentuk paket sistem operasi yang bagus, bersih, Kickstart [, JumpStart, Pemasang Otomatis, AutoYaST, Ignite-UX, NIM]. Ketika Anda harus menggunakan alat peretasan otomatis seperti Puppet (atau Chef, atau CFEngine), itu berarti Anda tidak memiliki sarana untuk mendesain dan mengimplementasikan proses yang, dengan desain yang sama, menegakkan sepenuhnya murni dan menyalakan sistem yang dikelola, sepenuhnya otomatis dan sepenuhnya non-interaktif.

Poin penting lainnya adalah, jika Anda harus memiliki Wayang atau solusi semacam itu untuk memperbaiki sistem peretasan seseorang atau konfigurasi aplikasi dengan tangan, itu juga akan kembali ke tidak memiliki pengalaman untuk merancang suatu proses, dan dalam proses itu kerangka kerja di mana konfigurasi dikemas menjadi komponen diskrit. Akibatnya, siapa pun yang mengimplementasikan Puppet dan sejenisnya, tidak memiliki konsep pemilik komponen, rilis, manajemen konfigurasi, Model Kematangan Kemampuan. Ini berkembang pesat menjadi masalah yang sangat serius di industri ini.

Bekerja dengan Puppet juga membantu saya mempelajari Ruby, yang telah menggantikan Bash sebagai bahasa alat sistem default saya. "

Mengapa Ruby diperlukan, ketika manajemen konfigurasi komprehensif, ujung-ke-ujung dapat dienkapsulasi dalam pra-instal, pasca-instal, sebelum dan sesudah menghapus bagian dari paket sistem operasi, hanya dengan menggunakan program shell Bourne, AWK, dan sed? Bahwa seseorang akan belajar bahasa esoterik Ruby, dan dialeknya dalam konteks Wayang, sama sekali tidak diperlukan. Masalah manajemen konfigurasi mudah dipecahkan (dan juga, telah dipecahkan) dengan program shell dan AWK, dan sedikit sed (1) di sana-sini sebagai lem.

Rasanya keren melihat manifes Wayang Anda mengonfigurasi seluruh mesin atau layanan baru dari awal.

Ini adalah hal yang lebih keren melihatnya dilakukan oleh Kickstart, AutoYaST, atau JumpStart, tanpa satu baris kode , dan dapat melakukan query sistem operasi dengan menggunakan alat bawaan , tanpa memerlukan perangkat lunak esoterik atau tambahan , tanpa klien-server diperlukan arsitektur (SSH lebih dari baik, jauh lebih baik), dan melihat sistem operasi Anda mengetahui setiap perubahan yang dilakukan.

5. Memisahkan kode dari data. Ini adalah salah satu konsep yang lebih sulit untuk dipelajari. Nilai-nilai hardcoding seperti Host Pemantauan ke dalam kode modul Anda buruk. Menempatkan mereka di penyimpanan data (db, yaml (Hiera menggunakan ini sebagai default), csv, apa pun) yang dapat dikonsumsi modul Anda baik. Contohnya adalah webapp yang menggunakan Mysql. Apa ini memungkinkan adalah kemampuan untuk mendorong kode dan data secara terpisah. Ini membuat proses pengembangan Anda lebih sederhana.

... Atau Anda bisa template file konfigurasi Anda dengan variabel shell, bahkan backquotes (misalnya ls -1 ...) dan menulis sebuah shell script yang menggunakan AWK untuk memanggil eval (1) dan memperluas semua variabel dalam template, sehingga memanfaatkan yang sama persis kuat parser yang memiliki cangkang built-in. Mengapa membuatnya rumit, padahal sebenarnya bisa sangat, sangat sederhana? Di mana Anda akan menyimpan nilai konfigurasi? Mengapa, di mana saja Anda mau, seperti misalnya file pkginfo (4), atau database seperti Oracle, atau cukup banyak di mana saja . Tidak perlu solusi ultrakompleks. Pustaka yang saya sebutkan di atas hanya dapat bersumber dari bagian pra-instal atau pasca-instal dalam paket sistem operasi, dengan demikian menghapus duplikasi dan meningkatkan sepotong kode pusat ...

Tetapi di atas semua, saya menemukan bahwa kutipan di atas adalah contoh dari generasi berikutnya dari administrator sistem yang perlu bimbingan bukan oleh administrator sistem, tetapi oleh insinyur sistem . Temukan diri Anda seorang greybeard dan masuk sebagai murid.


1
Anda sepertinya lupa jawaban atas pertanyaan penulis.
M. Glatki

Jawaban ini tampaknya terutama diskusi tentang pendapat, sikap dan alat, dan tidak benar-benar menjawab pertanyaan yang diajukan.
JonathanDavidArndt
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.