Kelas master singkat tentang pengembangan kode infrastruktur
Pada bulan Oktober tahun ini, saya membuat presentasi di konferensi HashiConf 2018, di mana saya berbicara tentang 5 pelajaran utama yang saya dan rekan Gruntwork pelajari dalam proses menciptakan dan memelihara perpustakaan lebih dari 300.000 baris kode infrastruktur yang digunakan oleh ratusan perusahaan dalam sistem produksi. Dalam publikasi ini, saya akan berbagi video dan slide dari presentasi, serta versi teks singkat dari deskripsi 5 pelajaran utama.
Video dan slide
Intro: DevOps Now in the Zaman Batu
Terlepas dari kenyataan bahwa industri ini penuh dengan kata-kata progresif yang modis: Kubernetes, layanan mikro, kisi-kisi layanan, infrastruktur yang tidak dapat diubah, data besar, danau data, dll. Kenyataannya adalah bahwa ketika Anda terbenam dalam penciptaan infrastruktur, Anda tidak akan merasa sangat modis dan progresif.
Secara pribadi, DevOps lebih mengingatkan saya pada ini:
Membuat infrastruktur tingkat produksi sulit. Ini adalah stres nyata. Dan makan banyak waktu. Banyak waktu.
Ini menunjukkan berapa banyak waktu yang diperlukan untuk mengimplementasikan proyek infrastruktur berikutnya. Kami mengandalkan data empiris yang kami kumpulkan selama bekerja dengan ratusan perusahaan yang berbeda:
Pelajaran 1. Daftar Periksa untuk Infrastruktur Manufaktur
Proyek DevOps selalu memakan waktu lebih lama dari yang Anda harapkan. Selalu. Kenapa begitu
Alasan pertama adalah potongan rambut yak . Di bawah ini adalah ilustrasi yang jelas tentang fenomena ini, (ini adalah kutipan dari seri "Malcolm in the Spotlight")
Alasan kedua adalah bahwa proses menciptakan infrastruktur tingkat produksi (misalnya, infrastruktur tempat perusahaan Anda akan pakai) terdiri dari ribuan komponen kecil. Sebagian besar pengembang tidak mengetahui detail ini, oleh karena itu, ketika mengevaluasi suatu proyek, Anda biasanya melupakan banyak tugas penting (dan memakan waktu).
Untuk menghindarinya, setiap kali mulai mengerjakan bagian baru dari infrastruktur, gunakan daftar periksa berikut:
Tidak semua elemen daftar akan diperlukan untuk setiap bagian infrastruktur, tetapi Anda harus secara sadar dan eksplisit mendokumentasikan elemen mana yang Anda terapkan, dan yang Anda putuskan untuk dilewati dan mengapa.
Pelajaran 2. Kotak Alat
Kami mencantumkan alat utama yang kami di Gruntwork gunakan untuk membuat dan mengelola infrastruktur (per 2018):
- Bentuk Terra . Kami menggunakan Terraform untuk menyebarkan seluruh infrastruktur yang mendasarinya, termasuk jaringan, subsistem penyeimbangan beban, basis data, alat manajemen pengguna dan izin, dan semua server kami.
- Packer . Kami menggunakan Packer untuk mengonfigurasi dan membuat gambar mesin virtual yang kami jalankan di server kami.
- Docker . Beberapa server kami membentuk kluster tempat kami menjalankan aplikasi sebagai wadah Docker. Untuk cluster Docker, kami terutama menggunakan alat-alat berikut: Kubernetes , ECS, dan Fargate .
Semua alat ini berguna, tetapi bukan itu intinya. Anda perlu memahami bahwa beberapa alat tidak cukup. Penting juga untuk mengubah perilaku tim.
Secara khusus, bahkan alat terbaik di dunia tidak akan membantu tim Anda jika mereka tidak ingin menggunakannya atau mereka tidak punya cukup waktu untuk belajar cara menggunakannya. Jadi, kesimpulan kuncinya adalah bahwa penggunaan "infrastruktur sebagai kode" adalah investasi, yaitu, biaya awal tertentu akan diperlukan untuk Anda. Jika Anda berinvestasi dengan bijak, Anda akan menerima dividen besar dalam jangka panjang.
Pelajaran 3. Modul besar itu jahat
Pendatang baru untuk penerapan "infrastruktur sebagai kode" sering mendefinisikan seluruh infrastruktur mereka untuk semua lingkungan mereka (lingkungan pengembangan, lingkungan menengah, lingkungan produksi, dll.) Dalam satu file atau satu set file yang digunakan secara keseluruhan. Sia-sia.
Berikut adalah beberapa kelemahan dari pendekatan ini:
- Kecepatan rendah Jika seluruh infrastruktur didefinisikan di satu tempat, maka pelaksanaan perintah apa pun akan memakan banyak waktu. Kami menghadapi situasi di perusahaan ketika tim
terraform plan membutuhkan waktu 5-6 menit untuk menyelesaikannya! - Keamanan rendah . Jika Anda mengelola seluruh infrastruktur bersama, maka untuk mengubah sesuatu Anda memerlukan izin untuk mengakses semuanya. Artinya, hampir setiap pengguna harus menjadi administrator, dan ini juga sangat merepotkan.
- Risiko tinggi . Jika Anda meletakkan semua telur dalam satu keranjang, maka buat situasi di mana satu kesalahan lokal dapat mengganggu operasi seluruh infrastruktur. Misalnya, ketika Anda membuat perubahan kecil ke aplikasi eksternal di lingkungan pengembangan, kesalahan ketik tunggal atau perintah yang salah dapat menyebabkan penghapusan database produksi.
- Sulit dimengerti . Semakin banyak kode ditempatkan di satu tempat, semakin sulit bagi satu orang untuk memahami semua ini. Dan ketika semua ini terhubung, bagian-bagian yang tidak dapat dipahami akan memainkan lelucon kejam dengan Anda.
- Sulit untuk diuji . Menguji kode infrastruktur sulit; menguji sejumlah besar kode infrastruktur hampir tidak mungkin. Kami akan kembali ke sini nanti.
- Sulit untuk dianalisis . Output dari perintah seperti rencana terraform menjadi tidak berguna, karena tidak ada yang mengganggu untuk melihat ribuan baris. Selain itu, analisis kode menjadi tidak berguna.
Singkatnya, Anda harus membuat kode dari modul komposit kecil, berdiri sendiri, dan dapat digunakan kembali. Ini bukan berita atau penemuan. Anda telah mendengar ini ribuan kali, meskipun dalam situasi yang sedikit berbeda:
"Lakukan satu hal dan lakukan dengan baik" - Filsafat Unix.
“Aturan fungsi pertama adalah mereka harus kecil. Aturan kedua menyatakan bahwa fungsi harus lebih kecil. " - "Kode bersih"
Pelajaran 4. Kode infrastruktur tanpa tes otomatis salah
Jika kode infrastruktur Anda tidak memiliki tes otomatis, itu tidak berfungsi dengan benar. Anda belum tahu tentang itu. Tetapi menguji kode infrastruktur sulit. Anda tidak memiliki "host lokal" (misalnya, Anda tidak dapat menggunakan cloud pribadi virtual AWS VPC di laptop Anda), atau "unit test" nyata (misalnya, Anda tidak dapat mengisolasi kode Terraform dari dunia "luar", karena seperti kali dan dirancang untuk berkomunikasi dengan dunia luar).
Oleh karena itu, untuk menguji kode infrastruktur dengan benar, Anda biasanya harus menyebarkannya di lingkungan nyata, menjalankan infrastruktur nyata, memverifikasi bahwa kode tersebut berfungsi, dan kemudian memecahkannya (untuk deskripsi gaya pengujian ini: lihat Terratest, ini adalah pustaka sumber terbuka yang menyertakan alat untuk menguji kode Terraform , Packer dan Docker, bekerja dengan AWS, GCP, dan Kubernetes API, menjalankan perintah shell secara lokal dan pada server jarak jauh melalui SSH, serta banyak fitur lainnya). Jadi, saat menguji infrastruktur, Anda perlu sedikit mendefinisikan kembali kondisinya:
Tes unit menggunakan dan menguji satu atau lebih modul infrastruktur yang terkait erat dari jenis yang sama (misalnya, modul untuk satu basis data).
Tes integrasi menggunakan dan menguji beberapa modul infrastruktur dari berbagai jenis untuk memverifikasi bahwa mereka bekerja bersama (misalnya, modul basis data dan modul layanan web).
Tes ujung ke ujung (e2e) menyebarkan dan menguji seluruh arsitektur.
Harap perhatikan bahwa diagram adalah piramida: kami memiliki banyak unit test, lebih sedikit tes integrasi dan sangat sedikit tes e2e. Mengapa Itu tergantung pada durasi masing-masing jenis tes:
Tes infrastruktur membutuhkan banyak waktu, terutama di tingkat atas piramida, dan, tentu saja, Anda akan ingin menemukan dan memperbaiki kesalahan sebanyak mungkin di bagian paling bawah. Untuk melakukan ini, Anda perlu:
- Buat modul mandiri yang kecil dan sederhana (lihat Pelajaran 3) dan tulis banyak unit test untuk mereka - pastikan modul itu berfungsi dengan benar.
- Gabungkan blok-blok kecil, sederhana, dan teruji ini untuk menciptakan infrastruktur yang lebih canggih yang Anda uji dengan uji integrasi dan E2E yang lebih sedikit.
Pelajaran 5. Proses Pelepasan
Untuk merangkum semua hal di atas. Inilah cara Anda sekarang akan membuat dan mengelola infrastruktur Anda:
- Periksa daftar periksa untuk infrastruktur tingkat produksi dan pastikan Anda bekerja ke arah yang benar.
- Tentukan "infrastruktur sebagai kode" Anda dengan alat-alat seperti Terraform, Packer, dan Docker. Pastikan tim Anda memiliki cukup waktu untuk mempelajari alat-alat ini (lihat Sumber Daya DevOps ).
- Buat kode dari modul komposit kecil dan berdiri sendiri (atau gunakan modul standar dari Infrastruktur sebagai Perpustakaan Kode ).
- Siapkan tes otomatis untuk modul Anda dengan Terratest .
- Lengkapi permintaan untuk memasukkan perubahan Anda untuk meninjau kode Anda.
- Lepaskan versi kode yang baru.
- Salin versi kode baru dari satu lingkungan ke lingkungan lain.
