Pilihan mematuhi strategi OCI

Halaman ini menyediakan ringkasan tentang proses build Cloud Foundry Anda butuh dari bermigrasi, dan memberikan deskripsi tentang berbagai cara dari proses bermigrasi tersebut ke proses yang membangun container yang sesuai dengan OCI.

Ringkasan proses pembangunan Cloud Foundry

Saat aplikasi dikirimkan untuk Cloud Foundry, hal tersebut akan melewati tahap build dengan kode sumber yang dikompilasi oleh buildpacks Cloud Foundry v2.

Proses output build Cloud Foundry menghasilkan arsip yang dapat dijalankan disebut droplet. Droplet tidak secara langsung kompatibel dengan spesifikasi Container Initiative (OCI) untuk menjalankan container dalam Cloud Run.

Saat memigrasikan aplikasi dari Cloud Foundry ke Cloud Run Anda harus mengubah proses build aplikasi untuk menghasilkan image standar industri OCII (terkadang disebut sebagai image Docker).

Diagram menjelaskan cara Cloud Foundry Droplet dibuat

Strategi untuk mencapai image yang mematuhi OCI

Ada tiga strategi bermigrasi yang dapat Anda pilih dari mem-build container yang sesuai dengan OCI:

Memodifikasi aplikasi Cloud Foundry (lift-and-shift)

Komponen inti dari ekosistem Cloud Foundry (Buildpack, v2 Sterncells, etc.) adalah open source. Artinya Anda dapat membuat ulang proses containerization aplikasi dengan mengikuti panduan kami untuk "Dockerize" komponen build inti guna membuat image baru yang sesuai dengan OCI.

Kelebihan:

  • Hal ini memerlukan paling sedikit pemfaktoran ulang dan penyesuaian aplikasi.
  • Proses ini dapat diulang untuk semua instance aplikasi.

Kekurangan:

  • Pipeline untuk mem-build container aplikasi yang dikelola sendiri.
  • Komponen Cloud Foundry yang lebih lama mengalami penurunan pemeliharaan dan dukungan.
  • Ada biaya pemeliharaan keamanan yang berlangsung termasuk:
    • Membangun ulang komponen secara rutin untuk memastikan Anda mendapatkan patch keamanan.
    • Membangun ulang aplikasi yang "di-dockered" secara rutin untuk menerima update keamanan dari komponen pembangunan yang dibuat ulang.

Menggunakan Buildpack Berbasis Cloud

SpesifikasiCloud Native Buildpacks (CNB) telah dibuat untuk memodernisasi dan menyatukan ekosistem buildpack. Builder yang kompatibel dengan spesifikasi CNB mengikuti standar terbuka dan membuat image yang sesuai dengan OCI. Tiga penyedia umum CNB adalah:

Kelebihan:

  • Pengelola buildpack dan penyedia platform bertanggung jawab untuk memelihara buildpack.
  • Buildpack mendukung penyimpanan ulang container pada image baru untuk update keamanan yang cepat tanpa membangun ulang container aplikasi.
  • Buildpack menghasilkan image OCI yang portabel.
  • Project CNB sedang diinkubasi berdasarkan Cloud Native Computing Foundation (CNCF) dan memiliki komunitas pengelola dan kontributor yang aktif.

Kekurangan:

  • Kesenjangan fungsionalitas dan konfigurasi antara buildpack v2 dan v3.
  • Framework dan integrasi yang diinstal untuk Anda di buildpack Java v2 mungkin saja tidak tersedia di buildpack Java CNB.

Menggunakan Dockerfile yang dikelola sendiri

Anda dapat membuat Dockerfile yang benar-benar baru untuk menyimpan aplikasi dalam container Anda. Baca artikel membangun container untuk mempelajar image container yang diterima oleh Cloud Run.

Kelebihan:

  • Memberikan Anda fleksibilitas paling tinggi dalam mendesain aplikasi.
  • Memanfaatkan alat container perusahaan Anda yang ada & strategi pembuatan.

Kekurangan:

  • Dockerisasi dan konfigurasi kustom harus dilakukan untuk setiap aplikasi, yang berpotensi memakan waktu proses mendebug dan penulisan ulang.
  • Sulit untuk menstandarkan implementasi didalam beberapa tim.
  • Melakukan patch pada image memerlukan deployment ulang dan deployment ulang secara penuh.

Rekomendasi

Tim yang memiliki resource terbatas dan ingin memindahkan aplikasi sebanyak mungkin harus terlebih dahulu mempertimbangkan Lift and Shift untuk memodifikasi strategi Cloud Foundry. Setelah aplikasi dimodernisasi agar sesuai dengan image yang mematuhi OCI,kami merekomendasikan Anda untuk mempertimbangkan menggunakan Cloud Native Buildpack atau Dockerfile yang dikelola sendiri.

Tim yang siap untuk segera bermigrasi harus mencoba Cloud Native Buildpacks lalu beralih ke Dockerfile yang dikelola sendiri jika memerlukan kontrol tingkat tinggi atas lingkungannya.

Langkah Berikutnya