
Ini adalah versi teks dari kinerja 2018-04-25 di Saint-Petersburg Linux User Group . Kode contoh di sini: https://github.com/ultral/ansible-role-testing
Saya percaya bahwa Anda menggunakan manajemen konfigurasi, bukan bash . Yaitu konfigurasi Anda adalah kode. Jika kita mengatakan bahwa infrastruktur adalah kode, maka filosofi yang sama harus diterapkan pada pembuatannya seperti untuk pengembangan perangkat lunak. Sudahkah Anda memikirkan hal ini? Bagaimana kamu melakukannya? Dan lainnya?
Prasyarat
Dalam kasus yang dijelaskan, ada banyak yang pengantar:
- Banyak peran yang mungkin.
- Hyper-V sebagai hypervisor utama.
- Cloud pribadi dengan kemampuan terbatas untuk membuat mesin virtual dengan cepat.
- Proksi untuk akses ke Internet.
- Ketidakmampuan untuk menjalankan pengujian peran yang mungkin dilakukan di buruh pelabuhan, karena peran tersebut adalah konfigurasi dari keseluruhan VM, termasuk pengaturan jaringan misalnya.
- Ingin menggunakan kebijakan panduan hijau untuk repositori dengan peran yang dimungkinkan.
Sebelum kita melakukan apa yang kita lakukan, kita membandingkan solusi yang ada.
Proyek | Dapur uji | Molekul | Milik sendiri |
---|
Bahasa | ruby | ular sanca | bash / ruby |
Pengamat | 132 | 126 | 0 |
Bintang | 1413 | 1154 | 1 |
Garpu | 502 | 174 | 2 |
Lisensi | Apache 2.0 | MIT | Apa saja |
Berkomitmen | 1929 | 1264 | 0 |
Rilis | 101 | 121 | 0 |
Kontributor | 109 | 82 | 5 |
Kami memutuskan untuk tidak menemukan kembali roda dan mengambil solusi turnkey. Tim infrastruktur kami tahu ruby, jadi Test Kitchen & inspec dipilih
Dapur-ci

Idenya sederhana jelek. Kami membuat mesin virtual baru, menggunakan peran, menjalankan tes asap.
Kebijakan pembangunan hijau

Tapi kami memutuskan untuk pindah. Gunakan aliran ala github, mis. peran dalam brunch individu dan setelah peninjauan merjim di master. Jika tes ok, maka kami menggulirkan peran ke infrastruktur.
Virtualisasi Bersarang
Seperti yang Anda ingat, kami memiliki batasan pada pembuatan mesin virtual, jadi kami harus membuat keputusan yang tidak menyenangkan dalam bentuk virtualisasi bersarang.

Awalnya, kami mencoba Virtualbox x32 untuk tidak menyertakan dukungan bersarang. Ini ternyata bukan gagasan karena stabilitas panik kernel. Faktor penting kedua adalah bahwa kita duduk di x86_64, jadi penelitian dilanjutkan (hi libvirt), tetapi menetap di virtualbox lebih umum pada OS yang didukung.
Kesulitan
Selama peluncuran, semuanya baik-baik saja.Ada sejumlah kesulitan.
Lewati pengaturan proxy dari host ke tamu tamu
Dalam beberapa skenario pengujian, pengaturan proxy digunakan, sementara pada host dengan testkitchen, proxy transparan digunakan dan bonus yang dimungkinkan tidak menerima variabel tambahan dengan nilai kosong.
Solusi: norak - buat templat ERB.
<%= ENV['http_proxy'].to_s.empty? ? 'http://proxy.example.com:3128' : ENV['http_proxy'] %>
Manajemen pengaturan jaringan melalui ansible
Dalam beberapa peran, jaringan telah dikonfigurasi, dalam pengujian terlihat seperti ini:
- Kami mengkonfigurasi jaringan dengan menyalin file.
- Terapkan pengaturan jaringan.
- Semua itu buruk.
Solusi: Tambahkan antarmuka ke mesin virtual
Jika set tes berisi "_" semuanya jatuh
Virtualbox tidak dapat menggunakan "_" dalam nama mesin virtual. Dan mesin virtual menggunakan nama skrip.
Solusi: ganti nama set tes "vm_" => "vm-"
Menguji kasus dengan menginstal Oracle tanpa "." di akhir nama mesin virtual jatuh
Peran itu digunakan dalam penjualan bersyarat ketika mereka memutuskan untuk menutupinya dengan tes. Ketika Anda memasukkannya ke dalam VM yang disiapkan, itu memenuhi peran, itu jatuh melalui testkitchen.
Sedikit petunjuk
[root@vm-oracle vagrant]# getent ahosts vm-oracle 127.0.0.1 STREAM vm-oracle 127.0.0.1 DGRAM 127.0.0.1 RAW [root@vm-oracle vagrant]# getent ahosts vm-oracle. fe80::a00:27ff:febd:bd6a STREAM vm-oracle fe80::a00:27ff:febd:bd6a DGRAM fe80::a00:27ff:febd:bd6a RAW 10.0.2.15 STREAM 10.0.2.15 DGRAM 10.0.2.15 RAW [root@oracle vagrant]# getent ahosts oracle.example.com. 192.168.128.182 STREAM oracle.example.local 192.168.128.182 DGRAM 192.168.128.182 RAW
Adakah yang tahu apa yang sedang terjadi?
Itu adalah skenario yang menyenangkan:
- Kami mengaktifkan pengikatan IPv4 hanya di pengaturan pendengar oracle.
- oracle menggunakan FQDN.
- linux mengandung basis khusus "myhostname" untuk menyelesaikan nama domain, itu digunakan setelah / etc / hosts & dns server.
- Vagrant menciptakan VM & pembaruan
/etc/hosts
.
Saya akan menjelaskan sedikit:
Apa yang terjadi jika vm-oracle ?
- gelandangan menciptakan mesin virtual.
- pembaruan gelandangan
/etc/hosts
( vm-oracle x2) - oracle listener mendengarkan IPv4.
- pendengar oracle menyelesaikan nama domain vm-oracle. & mendapat IPv6.
- GAGAL
Apa yang terjadi dalam kasus vm-oracle. ?
- gelandangan menciptakan mesin virtual.
- pembaruan gelandangan / etc / hosts ( vm-oracle & vm-oracle. )
- oracle listener mendengarkan IPv4.
- pendengar oracle menyelesaikan nama domain vm-oracle. & mendapat IPv4
- Ok
OOM datang mengunjungi kami
OOM membunuh mesin virtual secara acak. Testkitchen pada saat yang sama memberikan semua jenis pesan aneh di log-nya.
Solusi: Tambah jumlah memori.
Build lambat
Seluruh skema ini bekerja lambat, selama puluhan menit, kadang-kadang lebih dari satu jam.
Solusi:
- Packer . Preassemble gambar mesin virtual.
- Jalankan beberapa test case secara paralel
Kesimpulan
Jika kita mengatakan bahwa infrastruktur adalah kode, maka filosofi yang sama harus diterapkan pada pembuatannya seperti untuk pengembangan perangkat lunak. Di satu sisi, kami mendapat solusi yang berfungsi, tetapi ada beberapa momen yang tidak menyenangkan:
- Tidak ramah, semuanya terlihat.
- Campuran ruby & python.
- Tidak ada peran pemeriksaan dan peran.
- Ini bekerja lambat.
- Sulit ....
Pada outputnya, molekul dengan buruh pelabuhan terlihat menarik dan lebih asli. Kami sedang memikirkannya.
Referensi