Infrastruktur sebagai kode dan TDD

11

Infrastruktur sebagai kode memberi tahu kami untuk menggunakan alat yang mengotomatiskan bangunan Anda. Bagus. Alat-alat seperti ansible , chef , boneka , tumpukan garam , dan lainnya mendorong kita untuk menulis bagaimana infrastruktur terlihat, sambil menyelesaikan perbedaan.

Dalam Salt Stack bit-bit itu disebut state . Jika negara tidak sesuai dengan kenyataan, alat itu akan menyelesaikannya untuk kita. Dengan kata lain - kami menulis tes untuk infrastruktur kami dan jika tes gagal, alat akan memperbaikinya sendiri. Setidaknya itulah idenya.

XP mengajarkan kita untuk menggunakan TDD dan pertanyaannya adalah apakah itu berlaku untuk infrastruktur? Tooling menyarankan itu.

Saya bisa membayangkan beberapa jenis tes yang bisa sangat berguna.

Kami menulis tes asap yang digabungkan dengan layanan yang digunakan untuk memastikan bahwa end-to-end layanan yang dikerahkan berfungsi dan berjalan seperti yang diharapkan. Ini akan menjadi panggilan API atau / dan pemeriksaan sistemctl untuk memastikan apa yang baru saja kami gunakan berfungsi. Banyak fungsi ini dapat dicakup dalam status yang sama karena alat seperti ansible memiliki status untuk memastikan layanan berjalan.

Ada Molekul proyek yang memungkinkan menjalankan peran individu (seperti yang dimungkinkan oleh statusnya) terhadap buruh pelabuhan atau mesin virtualisasi sementara lainnya. Hal ini memaksa untuk memisahkan peran dan memungkinkan untuk menjalankannya secara terpisah dari buku pedoman saat mengerjakannya. Tes sebagian besar memungkinkan mengejek variabel yang seharusnya berfungsi dengan peran. Contoh-contoh lain tampak seperti duplikasi dari mesin yang mungkin (menegaskan file milik pengguna ...).

ThoughtWorks radar berteknologi sekarang memuji alat-alat seperti inspeksi , serverspec atau goss untuk memvalidasi bahwa server memenuhi spec. Tapi kami sedang menulis spec, bukan?

Jadi apakah ada titik dalam pengujian infrastruktur lebih lanjut jika kita menggambarkan infrastruktur di negara bagian / peran? Saya dapat menduga ini menjadi lebih diperlukan dalam organisasi yang lebih besar di mana satu tim memberikan spek dan yang lainnya mengikuti, atau jika ada serangkaian peran yang besar, mungkin Anda ingin menjalankan subset dari mereka dan mendapatkan manfaat cepat dari tes? Saya berjuang untuk melihat mengapa Anda akan menulis ujian jika Anda dapat memiliki peran / negara untuk pertanyaan yang sama dalam pikiran.

— Jackeo
sumber

6

Singkatnya, saya melihat dua kategori tes untuk infrastruktur Anda: 1) apakah ia memiliki semua yang Anda butuhkan untuk menjalankan aplikasi Anda dan 2) tidak memiliki hal-hal yang berlebihan.

Pertama dan terpenting, Anda dapat memperlakukan suite uji perangkat lunak Anda yang sebenarnya sebagai semacam "uji meta" untuk infrastruktur Anda. Selama Anda membuat infrastruktur dari awal untuk setiap uji coba, dan test suite berjalan sepenuhnya pada infrastruktur itu (yaitu, tidak menggunakan layanan luar) fakta bahwa seluruh rangkaian berwarna hijau berarti infrastruktur infrastruktur Anda yang dikodifikasikan juga cukup memadai .

Kedua, terutama dari perspektif keamanan, Anda dapat menulis tes terhadap infrastruktur Anda. Yaitu, jika salah satu bagian dari infrastruktur Anda adalah VM yang menjalankan Linux, Anda dapat menulis tes yang melakukan pemindaian port terhadap VM itu, untuk memastikan bahwa tidak ada port yang tidak disengaja terbuka, yang mungkin telah diinstal oleh apt-get installefek samping yang tidak diinginkan. . Atau Anda dapat menulis tes yang memeriksa apakah ada file yang tidak terduga diubah setelah test suite Anda yang tepat selesai. Atau Anda dapat memeriksa psoutput dari VMs Anda atau wadah Docker untuk proses yang tidak terduga dan semacamnya, membuat daftar putih dll., Dan dengan demikian mendapatkan pemberitahuan otomatis jika beberapa paket pihak ketiga diubah dalam cara yang tidak terdokumentasi (atau tanpa disadari) dalam beberapa peningkatan.

Jenis tes kedua ini, dalam cara, mirip dengan apa yang akan Anda lakukan dalam pengaturan ops klasik, yaitu, pengerasan server Anda dan memeriksa intrusi, menghindari sumber daya penuh dan semacamnya.

— AnoE
sumber

Jadi setelah beberapa waktu, ini adalah sikap yang saya ambil. Bagian yang dieksekusi oleh ansible tidak diuji dengan sendirinya, tetapi efek samping dari tindakan tersebut diuji menggunakan goss. Jadi untuk misalnya, RPM diinstal (mungkin) dan kemudian diuji jika file default yang diharapkan diberlakukan, atau layanan berjalan dan mendengarkan port tertentu. Saya tidak ingin memperbaiki masalah seperti itu secara otomatis, tetapi diberitahu dan hentikan progresnya. Tentu Ansible dapat menguji sistem untuk Anda juga, Anda hanya perlu secara eksplisit tentang hal itu, tetapi dalam kasus kami, kami gunakan gossuntuk menguji perilaku layanan dalam sebuah wadah

— JackLeo

1

IMHO agak berlebihan untuk menulis tes TDD untuk item yang sepenuhnya dicakup oleh spesifikasi negara IaaC. Melakukannya menyiratkan bahwa efektivitas IaaC dipertanyakan - mengapa Anda menggunakannya jika demikian?

Melihatnya dari calon IaaC yang berbeda itu sendiri (jika / ketika dilakukan dengan benar) menggabungkan kemampuan yang sudah diuji dan dianggap berfungsi andal. Itulah yang membuatnya menarik dan yang membuat penulisan tes pencocokan TDD mubazir.

Sebagai contoh, konfigurasi IaaC yang menetapkan sistem dengan SSH yang diinstal sudah dilengkapi pengecekan yang andal untuk SSH yang dipasang dengan benar dan, jika tidak, mekanisme untuk menginstalnya dengan benar. Yang membuat tes TDD untuk memeriksa apakah SSH diinstal berlebihan. Jika konfigurasi IaaC Anda juga menentukan sshd untuk dimulai dan mendengarkan pada port tertentu maka tes TDD untuk sshd berjalan dan mendengarkan port masing-masing juga akan berlebihan.

Perhatikan bahwa jawaban saya tidak menargetkan TDD atau jenis pengujian lainnya yang memeriksa apakah konfigurasi IaaC Anda secara keseluruhan sesuai dengan tujuan tertentu. Itu tetap valid dan dapat digunakan dalam TDD, CI atau pemeriksaan serupa selama pengembangan spesifikasi IaaC - Saya percaya jawaban @ AnoE berlaku dalam kasus tersebut.

— Dan Cornilescu
sumber

Apakah Anda menerapkan pemikiran yang sama untuk memastikan SSH (atau apa pun) diaktifkan pada port khusus tertentu, yang diuraikan dari file konfigurasi eksternal? Itu tidak bertumpu pada unit yang diuji, itu logika novel.

— Jon Lauridsen

1

Itu harus menjadi bagian dari IaaC, jika mendukungnya. Jika tidak - maka diskusi ini tidak benar-benar berlaku. Ya, ini bisa meluncur ke berapa banyak hal yang bisa dicakup oleh IaaC, tapi itu diskusi yang berbeda.

— Dan Cornilescu

1

Saya juga berasumsi kita tidak berada dalam konteks di mana pemeriksaan berlebihan diperlukan - dalam beberapa kasus pemeriksaan berlebihan mengikuti jalur kode yang sama sekali berbeda atau bahkan infrastruktur mungkin diperlukan.

— Dan Cornilescu

1

Sepertinya semua orang di sini mengasumsikan alat IAC selalu berjalan seperti yang diharapkan, tetapi saya dapat mengatakan (dari pengalaman saya sendiri) ini tidak selalu terjadi, jika tidak, unit test sebenarnya tidak akan berguna.

Saya ingat gambar yang mengatakan "Playbook yang mungkin dijalankan, semuanya baik-baik saja" dengan sebuah bangunan terbakar di latar belakang ...

Menjalankan keadaan deklaratif dan memiliki server dalam keadaan yang dinyatakan sebenarnya adalah 2 hal yang berbeda dari sudut pandang dan pengalaman saya setidaknya.

Lingkungan yang luas dan heterogen, tersebar di beberapa DC, dapat dijangkau melalui jaringan publik, dll ... Ada beberapa alasan mengapa suatu negara tidak dapat diterapkan, baik secara penuh atau sebagian.

Untuk semua alasan ini, ada ruang untuk unit test yang memungkinkan seseorang untuk mendapatkan snapshot dari keadaan server aktual, yang, sekali lagi, mungkin berbeda dari keadaan yang dituju.

Jadi saya akan mengatakan ya, unit test berguna bahkan dalam lingkungan yang dikelola IAC.

EDIT

Bagaimana dengan sisi non-regresi dari cabang dev dari basis kode IaC? jadi Anda akan membuat perubahan pada kode Anda di cabang dev dan menggabungkannya ke cabang prod berharap tidak merusak segalanya? unit test sangat berharga, dan biasanya mudah diimplementasikan, saya tidak mengerti mengapa orang akan membuat kode tanpa fitur ini.

Referensi (dalam bahasa Prancis maaf untuk itu): https://fr.slideshare.net/logilab/testinfra-pyconfr-2017

— Dermaga
sumber

1

Setidaknya sopan jika menambahkan komentar dengan suara rendah, bukankah Anda menganggapnya pemilih? Terutama pada pertanyaan semacam ini di mana perdebatan bisa sangat informatif atau bahkan konstruktif.

— Dermaga

Saya berasumsi nada jawaban Anda yang cukup agresif untuk semua orang yang telah berinteraksi dengan pertanyaan ini ditambahkan ke fakta Anda tidak memberikan referensi apa pun dari contoh Anda sendiri atau menggambarkan kerusakan yang diamati adalah alasan bagi downvoter. Akhirnya Anda mengatakan hal yang sama dengan jawaban lain, lakukan tes asap di sistem penyediaan Anda untuk memastikan sistemnya OK, yang dilakukan sebagian besar sistem dengan gagal jika mereka tidak dapat menyatukan sistem dalam kondisi yang diinginkan. Mengenai hasil edit Anda, biasanya penggabungan dilakukan setelah penggelaran ke pementasan dan memastikan tes asap lulus ...

— Tensibai

Saya pasti tidak bermaksud agresif, saya tidak menggunakan bahasa kasar saya di sini (ini jelas saya kira :)).

— Dermaga

Kami dapat mendiskusikannya di DevOps Chat jika Anda mau, saya pikir saya melihat presentasi ini atau yang seperti itu di acara devoxx beberapa tahun yang lalu. Saya sedikit tidak setuju dengan memanggil unit test itu, itu tes yang lebih fungsional.

— Tensibai

Seseorang dari tim dev saya mengatakan hal yang sama bahwa ini bukan tes unit, saya bukan dev sehingga saya mungkin salah menyebut tes unit ini, pasti

— Dermaga

1

Dalam pengalaman saya, salah satu perbedaan utama antara Dev dan Ops adalah "dependensi waktu run berat". Menginstal paket sangat tergantung pada repositori, jaringan atau kunci yang valid, atau katakanlah instantiating server cloud baru - tergantung pada sumber daya penyedia Anda.

Dalam hal penyediaan server, bahkan jika Anda tidak mengubah kode ketentuan, gambar Anda sebagian besar akan valid tetapi terkadang tidak. Jadi saya pikir pengujian sangat penting untuk memberikan gambar yang berfungsi.

Jika Anda pergi ke server tunggal hal-hal menjadi lebih buruk ... bagaimana Anda akan menguji jangkauan di seluruh pengaturan jaringan? Termasuk resolusi DNS, perutean dan firewall? Bahkan jika penyedia IaaC API Anda berfungsi seperti yang diharapkan (Saya telah melihat masalah kabel di area ini) Saya sangat suka TDD dalam kasus ini.

Karena saya belum menemukan alat pengujian di area ini, kami menulis satu di waktu luang kami: https://github.com/DomainDrivenArchitecture/dda-serverspec-crate

Jadi saya pikir TDD sangat penting di dunia DevOps!

— Jerger
sumber