Bagikan melalui

Menyebarkan ke infrastruktur Azure dengan GitHub Actions

  • Artikel

Dalam panduan ini, kita akan membahas cara menggunakan CI/CD dan Infrastructure as Code (IaC) untuk disebarkan ke Azure dengan GitHub Actions secara otomatis dan berulang.

Artikel ini adalah gambaran umum arsitektur dan menyajikan solusi terstruktur untuk merancang aplikasi di Azure yang dapat diskalakan, aman, tangguh, dan sangat tersedia. Untuk melihat contoh arsitektur cloud dan ide solusi dunia yang lebih nyata, telusuri arsitektur Azure.

Manfaat menggunakan IaC dan otomatisasi untuk penyebaran

Ada banyak cara untuk menyebarkan ke Azure termasuk portal Azure, CLI, API, dan banyak lagi. Untuk panduan ini, kita akan menggunakan automasi IaC dan CI/CD. Manfaat dari pendekatan ini meliputi:

  • Deklaratif: Saat Anda menentukan infrastruktur dan proses penyebaran dalam kode, infrastruktur dapat di-versi dan ditinjau menggunakan siklus hidup pengembangan perangkat lunak standar. IaC juga membantu mencegah penyimpangan dalam konfigurasi Anda.

  • Konsistensi: Mengikuti proses IaC memastikan bahwa seluruh organisasi mengikuti metode standar dan mapan untuk menyebarkan infrastruktur yang menggabungkan praktik terbaik dan diperkuat untuk memenuhi kebutuhan keamanan Anda. Setiap penyempurnaan yang dilakukan pada templat pusat dapat dengan mudah diterapkan di seluruh organisasi.

  • Keamanan: Templat yang dikelola secara terpusat dapat diperkuat dan disetujui oleh operasi cloud atau tim keamanan untuk memenuhi standar internal.

  • Layanan Mandiri: Teams dapat diberdayakan untuk menyebarkan infrastruktur mereka sendiri dengan menggunakan templat yang dikelola secara terpusat.

  • Peningkatan Produktivitas: Dengan menggunakan templat standar, tim dapat dengan cepat menyediakan lingkungan baru tanpa perlu khawatir tentang semua detail implementasi.

Informasi tambahan dapat ditemukan di bawah infrastruktur yang dapat diulang di Azure Architecture Center atau apa itu infrastruktur sebagai kode di Pusat Sumber Daya DevOps.

Arsitektur

Architecture overview of using CI/CD to deploy Azure

Aliran data

  1. Buat cabang baru dan periksa modifikasi kode IaC yang diperlukan.
  2. Buat Permintaan Pull (PR) di GitHub setelah Anda siap untuk menggabungkan perubahan Anda ke lingkungan Anda.
  3. Alur kerja GitHub Actions akan dipicu untuk memastikan kode Anda diformat dengan baik, konsisten secara internal, dan menghasilkan infrastruktur yang aman. Selain itu, analisis bagaimana-jika Terraform Plan atau Bicep akan berjalan untuk menghasilkan pratinjau perubahan yang akan terjadi di lingkungan Azure Anda.
  4. Setelah ditinjau dengan tepat, PR dapat digabungkan ke cabang utama Anda.
  5. Alur kerja GitHub Actions lain akan memicu dari cabang utama dan menjalankan perubahan menggunakan penyedia IaC Anda.
  6. (eksklusif untuk Terraform) Alur kerja GitHub Action yang dijadwalkan secara teratur juga harus berjalan untuk mencari penyimpangan konfigurasi apa pun di lingkungan Anda dan membuat masalah baru jika perubahan terdeteksi.

Prasyarat

Gunakan Bicep

  1. Membuat Lingkungan GitHub

    Alur kerja menggunakan lingkungan dan rahasia GitHub untuk menyimpan informasi identitas Azure dan menyiapkan proses persetujuan untuk penyebaran. Buat lingkungan bernama production dengan mengikuti instruksi ini. production Di lingkungan, siapkan aturan perlindungan dan tambahkan pemberi persetujuan yang diperlukan yang Anda inginkan yang perlu ditandatangani pada penyebaran produksi. Anda juga dapat membatasi lingkungan ke cabang utama Anda. Instruksi terperinci dapat ditemukan di sini.

  2. Siapkan Azure Identity:

    Aplikasi Azure Active Directory diperlukan yang memiliki izin untuk disebarkan dalam langganan Azure Anda. Buat satu aplikasi dan berikan izin baca/tulis yang sesuai di langganan Azure Anda. Selanjutnya siapkan kredensial federasi untuk memungkinkan GitHub menggunakan identitas menggunakan OpenID Koneksi (OIDC). Lihat dokumentasi Azure untuk instruksi terperinci. Tiga kredensial federasi perlu ditambahkan:

    • Atur Jenis Entitas ke Environment dan gunakan production nama lingkungan.
    • Atur Jenis Entitas ke Pull Request.
    • Atur Jenis Entitas ke Branch dan gunakan main nama cabang.

  3. Menambahkan rahasia GitHub

    Catatan

    Meskipun tidak ada data tentang identitas Azure yang berisi rahasia atau kredensial apa pun, kami masih menggunakan rahasia GitHub sebagai cara yang nyaman untuk membuat parameter informasi identitas per lingkungan.

    Buat rahasia berikut di repositori menggunakan identitas Azure:

    • AZURE_CLIENT_ID : ID aplikasi (klien) pendaftaran aplikasi di Azure
    • AZURE_TENANT_ID : ID penyewa Azure Active Directory tempat pendaftaran aplikasi ditentukan.
    • AZURE_SUBSCRIPTION_ID : ID langganan tempat pendaftaran aplikasi ditentukan.

    Instruksi untuk menambahkan rahasia ke repositori dapat ditemukan di sini.

Menggunakan Terraform

  1. Mengonfigurasi Lokasi Status Terraform

    Terraform menggunakan file status untuk menyimpan informasi tentang status infrastruktur terkelola Anda saat ini dan konfigurasi terkait. File ini perlu dipertahankan di antara eksekusi alur kerja yang berbeda. Pendekatan yang disarankan adalah menyimpan file ini dalam Akun Azure Storage atau backend jarak jauh serupa lainnya. Biasanya, penyimpanan ini akan disediakan secara manual atau melalui alur kerja terpisah. Blok backend Terraform perlu diperbarui dengan lokasi penyimpanan yang Anda pilih (lihat di sini untuk dokumentasi).

  2. Membuat lingkungan GitHub

    Alur kerja menggunakan lingkungan dan rahasia GitHub untuk menyimpan informasi identitas Azure dan menyiapkan proses persetujuan untuk penyebaran. Buat lingkungan bernama production dengan mengikuti instruksi ini. production Pada lingkungan, siapkan aturan perlindungan dan tambahkan pemberi persetujuan yang diperlukan yang Anda inginkan yang perlu ditandatangani pada penyebaran produksi. Anda juga dapat membatasi lingkungan ke cabang utama Anda. Instruksi terperinci dapat ditemukan di sini.

  3. Siapkan Azure Identity:

    Aplikasi Azure Active Directory diperlukan yang memiliki izin untuk disebarkan dalam langganan Azure Anda. Buat aplikasi terpisah untuk akun read-only dan read/write dan berikan izin yang sesuai di langganan Azure Anda. Selain itu, kedua peran juga akan membutuhkan setidaknya Reader and Data Access izin ke akun penyimpanan tempat status Terraform dari langkah 1 berada. Selanjutnya, siapkan kredensial federasi untuk memungkinkan GitHub menggunakan identitas menggunakan OpenID Koneksi (OIDC). Lihat dokumentasi Azure untuk instruksi terperinci.

    read/write Untuk identitas, buat satu kredensial federasi sebagai berikut:

    • Atur Entity Typeproduction ke Environment dan gunakan nama lingkungan.

    read-only Untuk identitas, buat dua kredensial federasi sebagai berikut:

    • Atur Entity Type ke Pull Request.
    • Atur Entity Typemain ke Branch dan gunakan nama cabang.

  4. Menambahkan rahasia GitHub

    Catatan

    Meskipun tidak ada data tentang identitas Azure yang berisi rahasia atau kredensial apa pun, kami masih menggunakan rahasia GitHub sebagai cara yang nyaman untuk membuat parameter informasi identitas per lingkungan.

    Buat rahasia berikut di repositori menggunakan read-only identitas:

    • AZURE_CLIENT_ID : ID aplikasi (klien) pendaftaran aplikasi di Azure
    • AZURE_TENANT_ID : ID penyewa Azure Active Directory tempat pendaftaran aplikasi ditentukan.
    • AZURE_SUBSCRIPTION_ID : ID langganan tempat pendaftaran aplikasi ditentukan.

    Instruksi untuk menambahkan rahasia ke repositori dapat ditemukan di sini.

    Buat rahasia lain pada production lingkungan menggunakan read-write identitas:

    • AZURE_CLIENT_ID : ID aplikasi (klien) pendaftaran aplikasi di Azure

    Instruksi untuk menambahkan rahasia ke lingkungan dapat ditemukan di sini. Rahasia lingkungan akan mengambil alih rahasia repositori saat melakukan langkah penyebaran ke production lingkungan ketika izin baca/tulis yang ditingkatkan diperlukan.

Penyebaran dengan Tindakan GitHub

Gunakan Bicep

Ada dua alur kerja utama yang disertakan dalam arsitektur referensi:

  1. Pengujian Unit Bicep

    Alur kerja ini berjalan pada setiap penerapan dan terdiri dari serangkaian pengujian unit pada kode infrastruktur. Ini menjalankan build bicep untuk mengkompilasi bicep ke templat ARM. Ini memastikan tidak ada kesalahan pemformatan. Selanjutnya, ia melakukan validasi untuk memastikan templat dapat disebarkan. Terakhir, checkov, alat analisis kode statis sumber terbuka untuk IaC, akan berjalan untuk mendeteksi masalah keamanan dan kepatuhan. Jika repositori menggunakan GitHub Advanced Security (GHAS), hasilnya akan diunggah ke GitHub.

  2. Bicep What-If / Deploy

    Alur kerja ini berjalan pada setiap permintaan pull dan pada setiap penerapan ke cabang utama. Tahap bagaimana-jika alur kerja digunakan untuk memahami dampak perubahan IaC pada lingkungan Azure dengan menjalankan bagaimana-jika. Laporan ini kemudian dilampirkan ke PR untuk mudah ditinjau. Tahap penyebaran berjalan setelah analisis bagaimana-jika ketika alur kerja dipicu oleh dorongan ke cabang utama. Tahap ini akan menyebarkan templat ke Azure setelah tinjauan manual dinonaktifkan.

Menggunakan Terraform

Ada tiga alur kerja utama yang disertakan dalam arsitektur referensi:

  1. Pengujian Unit Terraform

    Alur kerja ini berjalan pada setiap penerapan dan terdiri dari serangkaian pengujian unit pada kode infrastruktur. Ini menjalankan terraform fmt untuk memastikan kode di-lin dengan benar dan mengikuti praktik terbaik terraform. Selanjutnya melakukan validasi terraform untuk memeriksa apakah kode secara sindikat benar dan konsisten secara internal. Terakhir, checkov, alat analisis kode statis sumber terbuka untuk IaC, akan berjalan untuk mendeteksi masalah keamanan dan kepatuhan. Jika repositori menggunakan GitHub Advanced Security (GHAS), hasilnya akan diunggah ke GitHub.

  2. Terraform Plan / Apply

    Alur kerja ini berjalan pada setiap permintaan pull dan pada setiap penerapan ke cabang utama. Tahap rencana alur kerja digunakan untuk memahami dampak perubahan IaC pada lingkungan Azure dengan menjalankan rencana terraform. Laporan ini kemudian dilampirkan ke PR untuk mudah ditinjau. Tahap penerapan berjalan setelah rencana ketika alur kerja dipicu oleh pendorongan ke cabang utama. Tahap ini akan mengambil dokumen rencana dan menerapkan perubahan setelah peninjauan manual ditandatangani jika ada perubahan yang tertunda pada lingkungan.

  3. Deteksi Penyimpangan Terraform

    Alur kerja ini berjalan secara berkala untuk memindai lingkungan Anda untuk penyimpangan konfigurasi atau perubahan apa pun yang dilakukan di luar Terraform. Jika ada penyimpangan yang terdeteksi, Masalah GitHub dinaikkan untuk memperingatkan pengurus proyek.