Image container multi-arsitektur untuk perangkat IoT

Dokumen ini adalah bagian pertama rangkaian yang membahas pembuatan pipeline continuous integration (CI) otomatis untuk membangun image kontainer multi-arsitektur di Google Cloud. Konsep yang dijelaskan dalam dokumen ini berlaku untuk lingkungan cloud apa pun.

Rangkaian ini terdiri dari dokumen ini dan tutorial pendamping. Dokumen ini menjelaskan struktur pipeline untuk mem-build image container dan menjelaskan langkah-langkah tingkat tingginya. Tutorial ini akan memandu Anda dalam mem-build contoh pipeline.

Seri ini ditujukan bagi para profesional TI yang ingin menyederhanakan dan mempersingkat pipeline kompleks untuk membangun image container, atau memperluas pipeline tersebut guna mem-build image multi-arsitektur. Hal ini mengasumsikan bahwa Anda sudah familier dengan teknologi dan container cloud.

Saat mengimplementasikan pipeline CI, Anda menyederhanakan prosedur pembuatan artefak. Anda tidak perlu mengelola alat dan hardware khusus untuk mem-build image container untuk arsitektur tertentu. Misalnya, jika pipeline Anda saat ini berjalan pada arsitektur x86_64 dan menghasilkan image container hanya untuk arsitektur tersebut, Anda mungkin perlu memelihara alat dan hardware tambahan jika Anda ingin mem-build image container untuk arsitektur lain, seperti untuk kelompok ARM.

Domain Internet of Things (IoT) sering kali memerlukan build multi-arsitektur. Jika Anda memiliki fleet yang sangat banyak dengan beragam stack hardware dan software OS , proses pembuatan, pengujian, dan pengelolaan aplikasi software untuk perangkat tertentu menjadi tantangan besar. Menggunakan proses build multi-arsitektur membantu menyederhanakan pengelolaan aplikasi IoT.

Tantangan mem-build image container multi-arsitektur

Pada sebagian besa implementasi, image container bergantung pada arsitektur. Misalnya, jika Anda mem-build image container untuk arsitektur x86_64, image tersebut tidak dapat berjalan pada arsitektur kelompok ARM.

Anda dapat mengatasi batasan ini dengan beberapa cara:

Build image container di arsitektur target yang Anda perlukan dengan image container.
Kelola alat khusus dan fleet hardware. Fleet Anda membutuhkan setidaknya satu perangkat untuk setiap arsitektur yang image container-nya perlu Anda buat.
Buat image container multi-arsitektur.

Strategi yang paling cocok untuk Anda bergantung pada berbagai faktor, termasuk hal berikut:

Kompleksitas pipeline
Persyaratan otomatisasi
Resource yang tersedia untuk mendesain, menerapkan, dan memelihara lingkungan untuk mem-build image container

Misalnya, jika lingkungan runtime memiliki akses terbatas ke catu daya, Anda mungkin perlu mem-build image container di lingkungan yang terpisah dari lingkungan runtime.

Diagram berikut menggambarkan titik keputusan dalam memilih strategi yang valid.

Diagram alir untuk memutuskan strategi terbaik guna mem-build image container multi-arsitektur.

Mem-build image container pada arsitektur target

Salah satu strateginya adalah dengan mem-build setiap image container yang Anda butuhkan langsung di lingkungan runtime yang mendukung container itu sendiri, seperti yang ditunjukkan dalam diagram berikut.

Mem-build jalur dari repositori kode sumber ke lingkungan runtime.

Untuk setiap build, lakukan hal berikut:

Download kode sumber image container dari repositori kode sumber di setiap perangkat di lingkungan runtime.
Build image container di lingkungan runtime.
Simpan image container di repositori image container yang bersifat lokal untuk setiap perangkat di lingkungan runtime.

Keuntungan dari strategi ini adalah Anda tidak perlu menyediakan dan memelihara hardware selain yang diperlukan untuk lingkungan runtime. Strategi ini juga memiliki kekurangan. Pertama, Anda harus mengulangi proses build pada setiap instance hardware di lingkungan runtime, sehingga akan menyia-nyiakan resource. Misalnya, jika Anda men-deploy workload dalam container di lingkungan runtime saat perangkat tidak memiliki akses ke catu daya berkelanjutan, Anda akan membuang waktu dan daya dengan menjalankan tugas build pada perangkat tersebut setiap kali Anda perlu men-deploy workload versi baru. Selain itu, Anda perlu mempertahankan alat untuk mengakses kode sumber setiap image container guna mem-build image container di lingkungan runtime Anda.

Mempertahankan fleet hardware dan alat khusus

Strategi kedua adalah mempertahankan fleet hardware yang dikhususkan untuk tugas yang mem-build image container. Diagram berikut menggambarkan arsitektur strategi ini.

Jalur build dari repositori kode sumber ke lingkungan build khusus.

Untuk setiap build, lakukan hal berikut:

Download kode sumber image container di perangkat dalam fleet yang memiliki arsitektur hardware yang diperlukan dan resource untuk mem-build image container.
Buat image container.
Simpan image container di repositori image container terpusat.
Download image container pada setiap perangkat di lingkungan runtime saat Anda perlu men-deploy instance baru image tersebut.

Untuk strategi ini, Anda harus menyediakan minimal satu instance dari setiap arsitektur hardware yang Anda perlukan untuk mem-build image container. Dalam lingkungan produksi yang tidak umum, Anda mungkin memiliki lebih dari satu instance untuk meningkatkan fault-tolerant lingkungan dan untuk mempersingkat waktu build jika Anda memiliki beberapa tugas build secara serentak.

Strategi ini memiliki beberapa keunggulan. Pertama, Anda dapat menjalankan setiap tugas build sekali saja dan menyimpan image container yang dihasilkan dalam repositori image container terpusat, seperti Container Registry. Selain itu, Anda dapat menjalankan rangkaian pengujian pada perangkat dalam fleet build yang sangat mirip dengan arsitektur hardware yang Anda miliki di lingkungan runtime. Kekurangan utama dari strategi ini adalah Anda harus menyediakan dan memelihara infrastruktur dan alat khusus untuk menjalankan tugas yang mem-build image container. Biasanya, setiap tugas build tidak menggunakan banyak resource atau waktu secara desain, sehingga infrastruktur ini selalu tidak aktif.

Mem-build image container multi-arsitektur

Dalam strategi ketiga ini, Anda menggunakan pipeline tujuan umum untuk mem-build image container multi-arsitektur, seperti yang ditunjukkan diagram berikut.

Membangun jalur dari repositori kode sumber ke pipeline multi-arsitektur untuk tujuan umum.

Untuk setiap build, lakukan hal berikut:

Download kode sumber image container.
Buat image container.
Simpan image container di repositori image container terpusat.
Download image container pada setiap perangkat di lingkungan runtime saat Anda perlu men-deploy instance baru image tersebut.

Keuntungan utama strategi ini adalah Anda tidak perlu menyediakan dan memelihara hardware atau alat khusus. Misalnya, Anda dapat menggunakan pipeline dan alat continuous integration/deployment berkelanjutan (CI/CD) yang sudah ada untuk mem-build image container multiarsitektur. Anda juga dapat memperoleh manfaat dari performa arsitektur hardware tujuan umum yang lebih baik, seperti x86_64, dibandingkan dengan yang hemat energi, seperti yang ada dalam kelompok ARM.

Strategi ini mungkin juga menjadi bagian dari inisiatif yang lebih luas tempat Anda menerapkan prinsip DevOps. Misalnya, Anda dapat mengimplementasikan pipeline CI/CD untuk hardware khusus.

Mengimplementasikan pipeline untuk mem-build image container multi-arsitektur

Di bagian ini, kami menjelaskan implementasi referensi pipeline CI/CD yang mengikuti strategi ketiga, yaitu mem-build image container multi-arsitektur.

Implementasi referensi memiliki komponen berikut:

Repositori kode sumber untuk mengelola kode sumber untuk image container. Misalnya, Anda dapat menggunakan Cloud Source Repositories atau repositori GitLab.
Lingkungan runtime CI/CD untuk mem-build image container, seperti Cloud Build.
Platform untuk mengelola container dan image container yang mendukung image container multi-arsitektur, seperti Docker.
Registry image container seperti Container Registry. Jika ingin menyimpan image container lebih dekat ke node tempat image diperlukan, Anda dapat menjalankan registry image container, seperti Docker Registry, secara langsung di lingkungan saat ini.

Arsitektur referensi ini menggunakan Moby BuildKit dan QEMU untuk mem-build image container Docker multi-arsitektur. Dalam hal ini, Moby BuildKit otomatis mendeteksi arsitektur yang tersedia melalui emulasi hardware QEMU dan secara otomatis memuat biner yang sesuai dan terdaftar dalam kemampuan binfmt_misc kernel Linux.

Diagram berikut mengilustrasikan stack teknis yang bertanggung jawab atas setiap build image container multi-arsitektur yang didukung oleh arsitektur referensi ini.

Komponen terkait untuk arsitektur referensi multi-arsitektur ini.

Arsitektur referensi ini menggunakan manifes image Docker, maka Anda tidak perlu menyediakan tag image container untuk setiap arsitektur hardware target; Anda dapat menggunakan tag yang sama untuk beberapa arsitektur. Misalnya, jika Anda mem-build versi 1.0.0 image container multiarsitektur, Anda tidak memerlukan tag unik untuk setiap arsitektur hardware, seperti 1.0.0-x86_64, atau 1.0.0_ARMv7 Anda menggunakan tag 1.0.0 yang sama untuk semua arsitektur hardware yang Anda build, dan menggunakan manifes gambar Docker untuk mengidentifikasi setiap image container dengan benar.

Contoh berikut menampilkan manifes gambar untuk image Alpine Linux resmi, tempat Anda menemukan informasi tentang arsitektur yang didukung oleh versi tertentu image container tersebut:

{
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
   "manifests": [
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 528,
         "digest": "sha256:ddba4d27a7ffc3f86dd6c2f92041af252a1f23a8e742c90e6e1297bfa1bc0c45",
         "platform": {
            "architecture": "amd64",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 528,
         "digest": "sha256:401f030aa35e86bafd31c6cc292b01659cbde72d77e8c24737bd63283837f02c",
         "platform": {
            "architecture": "arm",
            "os": "linux",
            "variant": "v7"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 528,
         "digest": "sha256:2c26a655f6e38294e859edac46230210bbed3591d6ff57060b8671cda09756d4",
         "platform": {
            "architecture": "arm64",
            "os": "linux"
         }
      }
   ]
}

Saat Anda mendesain pipeline otomatis untuk mem-build image container, sebaiknya sertakan rangkaian pengujian komprehensif yang memvalidasi kepatuhan terhadap persyaratan setiap image container. Misalnya, Anda dapat menggunakan alat seperti Chef InSpec, Serverspec, dan RSpec untuk menjalankan rangkaian pengujian kepatuhan terhadap image container sebagai salah satu tugas pipeline build.

Mengoptimalkan pipeline untuk mem-build image container

Setelah memvalidasi dan mengonsolidasikan pipeline untuk mem-build image container, Anda akan mengoptimalkan pipeline. Migrasi ke Google Cloud: Mengoptimalkan lingkungan Anda berisi panduan tentang cara mengoptimalkan lingkungan. Framework ini menjelaskan framework pengoptimalan yang dapat Anda gunakan untuk membuat lingkungan Anda lebih efisien dibandingkan dengan kondisinya saat ini. Dengan mengikuti framework pengoptimalan, Anda akan melalui beberapa iterasi untuk mengubah status lingkungan.

Salah satu aktivitas pertama dari setiap iterasi pengoptimalan adalah menetapkan serangkaian persyaratan dan sasaran untuk iterasi tersebut. Misalnya, salah satu persyaratannya adalah memodernisasi proses deployment Anda, yaitu bermigrasi dari proses deployment manual ke proses deployment dalam container yang sepenuhnya otomatis. Untuk mengetahui informasi selengkapnya tentang cara memodernisasi proses deployment, lihat Migrasi ke Google Cloud: Bermigrasi dari deployment manual ke deployment otomatis dalam container.

Langkah selanjutnya

Coba tutorial yang menyertainya, Membuat image container multi-arsitektur untuk perangkat IoT.
Baca referensi kami tentang DevOps.
Baca tentang Kubernetes dan tantangan pengiriman software berkelanjutan.
Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.