Menguji infrastruktur Anda sebagai kode dengan Pulumi. Bagian 2

Halo semuanya. Hari ini kami membagikan kepada Anda bagian terakhir dari artikel “Menguji infrastruktur sebagai kode menggunakan Pulumi” , terjemahan yang disiapkan khusus untuk siswa dari kursus “Praktek dan Alat DevOps” .



Pengujian Penempatan


Gaya pengujian yang diuji adalah pendekatan yang kuat, memungkinkan kami menguji kotak putih untuk memeriksa bagian dalam kode infrastruktur kami. Namun, agak membatasi apa yang dapat kami verifikasi. Pengujian dilakukan berdasarkan rencana penempatan di dalam memori yang dibuat oleh Pulumi sebelum penyebaran langsung dan oleh karena itu penyebaran itu sendiri tidak dapat diuji. Untuk kasus seperti itu, Pulumi memiliki kerangka uji integrasi. Dan kedua pendekatan ini bekerja sangat baik bersama!

Kerangka kerja pengujian integrasi Pulumi ditulis dalam Go, dan dengan bantuannya kami menguji sebagian besar kode internal kami. Jika pendekatan pengujian unit yang dibahas sebelumnya lebih seperti pengujian kotak putih, maka pengujian integrasi adalah kotak hitam. (Ada juga opsi untuk pengujian internal menyeluruh.) Kerangka kerja ini dibuat untuk mengambil program Pulumi penuh dan melakukan berbagai operasi siklus hidup untuk itu, seperti mengerahkan tumpukan baru dari awal, memperbarui dengan variasi, dan menghapusnya, mungkin beberapa kali. Kami menjalankannya secara teratur (misalnya, pada malam hari) dan sebagai tes stres.

(Kami berupaya memastikan bahwa kemampuan pengujian integrasi serupa ada dalam SDK bahasa asli. Anda dapat menggunakan kerangka pengujian integrasi Go terlepas dari bahasa tempat program Pulumi Anda ditulis).

Dengan menjalankan program menggunakan kerangka kerja ini, Anda dapat memeriksa hal-hal berikut:

  • Kode proyek Anda benar secara sintaksis dan berfungsi tanpa kesalahan.
  • Pengaturan konfigurasi tumpukan dan rahasia berfungsi dan ditafsirkan dengan benar.
  • Proyek Anda dapat berhasil digunakan di penyedia cloud yang Anda pilih.
  • Proyek Anda dapat berhasil ditingkatkan dari kondisi awal ke N status lain.
  • Proyek Anda dapat berhasil dihancurkan dan dihapus dari penyedia cloud Anda.

Seperti yang akan segera kita lihat, kerangka kerja ini juga dapat digunakan untuk melakukan validasi runtime.

Tes integrasi sederhana


Untuk melihat ini dalam tindakan, kita akan melihat repositori pulumi/examples , karena tim kami dan komunitas Pulumi menggunakannya untuk menguji kumpulan permintaan, komitmen, dan pembangunan malam mereka sendiri.

Di bawah ini adalah tes sederhana dari contoh kami , yang melakukan penyediaan bucket S3 dan beberapa objek lainnya :

example_test.go:


 package test import ( "os" "path" "testing" "github.com/pulumi/pulumi/pkg/testing/integration" ) func TestExamples(t *testing.T) { awsRegion := os.Getenv("AWS_REGION") if awsRegion == "" { awsRegion = "us-west-1" } cwd, _ := os.Getwd() integration.ProgramTest(t, &integration.ProgramTestOptions{ Quick: true, SkipRefresh: true, Dir: path.Join(cwd, "..", "..", "aws-js-s3-folder"), Config: map[string]string{ "aws:region": awsRegion, }, }) } 

Tes ini melewati siklus hidup dasar untuk membuat, memodifikasi, dan menghancurkan tumpukan untuk aws-js-s3-folder . Diperlukan waktu sekitar satu menit untuk melaporkan tes yang lulus:

 $ go test . PASS ok ... 43.993s 

Ada banyak opsi untuk menyesuaikan perilaku tes ini. Lihat struktur ProgramTestOptions untuk daftar opsi lengkap. Misalnya, Anda dapat mengonfigurasi titik akhir Jaeger untuk melacak ( Tracing ), menunjukkan bahwa Anda mengharapkan tes ExpectFailure selama pengujian negatif ( ExpectFailure ), menerapkan serangkaian "suntingan" ke program untuk transisi status berurutan ( EditDirs ), dan banyak lagi. Mari kita lihat bagaimana menggunakannya untuk memverifikasi penyebaran aplikasi.

Memeriksa Properti Sumber Daya


Integrasi yang disebutkan di atas memastikan bahwa program kami "berfungsi" - tidak macet. Tetapi bagaimana jika kita ingin memeriksa properti dari stack yang dihasilkan? Sebagai contoh, bahwa jenis sumber daya tertentu dipersiapkan (atau tidak) dan bahwa mereka memiliki atribut tertentu.

Parameter ExtraRuntimeValidation untuk ExtraRuntimeValidation memungkinkan kita untuk melihat status yang direkam oleh Pulumi setelah penyebaran (keadaan pasca penempatan) sehingga kami dapat melakukan pemeriksaan tambahan. Ini termasuk snapshot lengkap dari keadaan tumpukan yang dihasilkan, termasuk konfigurasi, nilai output yang diekspor, semua sumber daya dan nilai properti mereka, serta semua dependensi antara sumber daya.

Untuk melihat contoh dasar ini, mari kita verifikasi bahwa program kami membuat satu Ember S3 :

  integration.ProgramTest(t, &integration.ProgramTestOptions{ // as before... ExtraRuntimeValidation: func(t *testing.T, stack integration.RuntimeValidationStackInfo) { var foundBuckets int for _, res := range stack.Deployment.Resources { if res.Type == "aws:s3/bucket:Bucket" { foundBuckets++ } } assert.Equal(t, 1, foundBuckets, "Expected to find a single AWS S3 Bucket") }, }) 

Sekarang, ketika kita menjalankan uji go, itu tidak hanya akan melalui baterai tes siklus hidup, tetapi juga, setelah berhasil menyebarkan tumpukan, itu akan melakukan pemeriksaan tambahan dari keadaan yang dihasilkan.

Tes runtime


Sejauh ini, semua tes telah secara eksklusif tentang perilaku penyebaran dan tentang model sumber daya Pulumi. Bagaimana jika Anda ingin memverifikasi bahwa infrastruktur yang Anda siapkan benar-benar berfungsi? Misalnya, bahwa mesin virtual sedang berjalan, ember S3 berisi apa yang kita harapkan, dan sebagainya.

Anda mungkin sudah menemukan cara untuk melakukan ini: opsi ExtraRuntimeValidation untuk ExtraRuntimeValidation adalah peluang besar untuk ini. Pada titik ini, Anda menjalankan uji Go sewenang-wenang dengan akses ke status penuh sumber daya program Anda. Keadaan ini mencakup informasi seperti alamat IP mesin virtual, URL, dan semua yang diperlukan untuk interaksi nyata dengan aplikasi dan infrastruktur cloud yang diterima.

Misalnya, program pengujian kami mengekspor properti bucket webEndpoint disebut websiteUrl , yang merupakan URL lengkap tempat kami dapat memperoleh index document disesuaikan. Meskipun kami dapat mempelajari file status untuk menemukan bucket dan membaca properti ini secara langsung, dalam banyak kasus, tumpukan kami mengekspor properti yang bermanfaat, seperti ini, yang memudahkan kami untuk memeriksa:

 integration.ProgramTest(t, &integration.ProgramTestOptions{ // as before ... ExtraRuntimeValidation: func(t *testing.T, stack integration.RuntimeValidationStackInfo) { url := "http://" + stack.Outputs["websiteUrl"].(string) resp, err := http.Get(url) if !assert.NoError(t, err) { return } if !assert.Equal(t, 200, resp.StatusCode) { return } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if !assert.NoError(t, err) { return } assert.Contains(t, string(body), "Hello, Pulumi!") }, }) 

Seperti pemeriksaan runtime kami sebelumnya, pemeriksaan ini akan dilakukan segera setelah menaikkan tumpukan, dan semua ini sebagai tanggapan terhadap go test panggilan sederhana untuk go test . Dan ini hanyalah puncak gunung es - semua fitur tes Go yang dapat Anda tulis dalam kode tersedia.

Integrasi Infrastruktur Berkelanjutan


Adalah baik untuk dapat menjalankan tes pada laptop ketika banyak perubahan dilakukan pada infrastruktur untuk mengujinya sebelum mengirimkannya ke ulasan kode. Tetapi kami dan banyak klien kami sedang menguji infrastruktur di berbagai tahap siklus hidup pengembangan:

  • Di setiap kumpulan terbuka, permintaan pengujian sebelum merger.
  • Menanggapi setiap komit, untuk memeriksa ulang bahwa penggabungan dilakukan dengan benar.
  • Secara berkala, misalnya, pada malam hari atau setiap minggu untuk pengujian tambahan.
  • Sebagai bagian dari pengujian kinerja atau pengujian stres, yang biasanya dilakukan dalam periode waktu yang lama dan menjalankan pengujian secara paralel dan / atau menggunakan program yang sama beberapa kali.

Untuk masing-masing dari mereka, Pulumi mendukung integrasi dengan sistem integrasi berkelanjutan favorit Anda. Dengan integrasi berkelanjutan, ini memberi Anda cakupan pengujian yang sama untuk infrastruktur Anda seperti halnya untuk perangkat lunak aplikasi.

Pulumi memiliki dukungan untuk sistem CI umum. Inilah beberapa di antaranya:


Untuk informasi lebih lanjut, lihat dokumentasi Pengiriman Berkelanjutan .

Lingkungan efemeral


Fitur yang sangat kuat yang terbuka adalah kemampuan untuk menyebarkan lingkungan fana hanya untuk tujuan pengujian penerimaan. Konsep dan stack proyek Pulumi dirancang untuk dengan mudah menyebarkan dan menghancurkan lingkungan yang sepenuhnya terisolasi dan independen, semua dalam beberapa perintah CLI sederhana atau melalui kerangka pengujian integrasi.

Jika Anda menggunakan GitHub, Pulumi menawarkan Aplikasi GitHub , yang akan membantu Anda menghubungkan pengujian penerimaan ke kumpulan permintaan di dalam pipa CI Anda. Cukup instal aplikasi dalam repositori GitHub, dan Pulumi akan menambahkan informasi tentang pratinjau infrastruktur, pembaruan, dan hasil pengujian ke CI dan kumpulan permintaan Anda:



Saat menggunakan Pulumi untuk tes penerimaan dasar Anda, Anda akan memiliki kemampuan otomatisasi baru yang akan meningkatkan kinerja tim dan memberi kepercayaan pada kualitas perubahan.

Ringkasan


Dalam artikel ini, kami melihat bahwa ketika menggunakan bahasa pemrograman untuk tujuan umum, banyak metode pengembangan perangkat lunak yang berguna dalam mengembangkan aplikasi kami tersedia bagi kami. Mereka termasuk pengujian unit, pengujian integrasi, dan interaksi mereka untuk melakukan pengujian runtime yang luas. Tes mudah dijalankan berdasarkan permintaan atau dalam sistem CI Anda.

Pulumi adalah perangkat lunak open source, gratis untuk digunakan dan bekerja dengan bahasa pemrograman dan cloud favorit Anda - coba hari ini !

Bagian pertama

Source: https://habr.com/ru/post/id463637/


All Articles