Bagikan melalui

Rekomendasi untuk penandaan dan pembuatan versi gambar kontainer

  • Artikel

Saat mendorong gambar kontainer ke registri kontainer dan kemudian menyebarkannya, Anda memerlukan strategi untuk penandaan dan penerapan versi gambar. Artikel ini membahas dua pendekatan dan di mana masing-masing cocok selama siklus hidup kontainer:

  • Tag stabil - Tag yang Anda gunakan kembali, misalnya, untuk menunjukkan versi utama atau minor seperti mycontainerimage:1.0.
  • Tag unik - Tag yang berbeda untuk setiap gambar yang Anda dorong ke registri, seperti mycontainerimage:abc123.

Tag stabil

Rekomendasi: Gunakan tag yang stabil untuk mempertahankan gambar dasar untuk bangunan kontainer Anda. Hindari penyebaran dengan tag yang stabil, karena tag tersebut terus menerima pembaruan dan dapat menyebabkan inkonsistensi di lingkungan produksi.

Tag stabil berarti pengembang, atau bangunan sistem, dapat terus menarik tag tertentu, yang terus mendapatkan pembaruan. Stabil bukan berarti kontennya dibekukan. Sebaliknya, stabil menyiratkan gambar harus stabil sesuai maksud dari versi tersebut. Agar tetap "stabil", mungkin akan dilayani untuk menerapkan patch keamanan atau pembaruan kerangka kerja.

Contoh

Tim kerangka kerja mengirimkan versi 1.0. Mereka tahu mereka akan mengirimkan pembaruan, termasuk pembaruan kecil. Untuk mendukung tag yang stabil untuk versi utama dan minor tertentu, mereka memiliki dua set tag yang stabil.

  • :1 – tag stabil untuk versi utama. 1 mewakili versi "terbaru" atau "terakhir" 1.*.
  • :1.0- tag stabil untuk versi 1.0, memungkinkan pengembang untuk mengikat pembaruan 1.0, dan tidak digulirkan ke 1.1 ketika dirilis.

Ketika pembaruan gambar dasar tersedia, atau semua jenis rilis layanan kerangka kerja, gambar dengan tag stabil diperbarui ke digest terbaru yang mewakili rilis stabil terbaru dari versi itu.

Dalam hal ini, tag utama dan minor akan terus dilayani. Dari skenario gambar dasar, ini memungkinkan pemilik gambar untuk memberikan gambar yang dilayani.

Menghapus manifes yang belum ditandai

Jika gambar dengan tag stabil diperbarui, gambar yang ditandai sebelumnya tidak ditag, menghasilkan gambar tidak berpemilik. Data manifes dan lapisan unik gambar sebelumnya tetap berada di registri. Untuk mempertahankan ukuran registri, Anda dapat secara berkala menghapus manifes yang tidak terinstal yang dihasilkan dari pembaruan gambar yang stabil. Misalnya, pembersihan otomatis manifes yang tidak ditandai lebih lama dari durasi yang ditentukan, atau tetapkan kebijakan retensi untuk manifes yang tidak diberi tag.

Tag unik

Rekomendasi: Gunakan tag unik untuk penyebaran, terutama di lingkungan yang dapat menskalakan beberapa node. Anda mungkin ingin penyebaran yang disengaja dari versi komponen yang konsisten. Jika kontainer Anda dimulai ulang atau orkestrator menskalakan lebih banyak instans, host Anda tidak akan secara tidak sengaja menarik versi yang lebih baru, tidak konsisten dengan node lain.

Penandaan unik berarti bahwa setiap gambar yang didorong ke registri memiliki tag yang unik. Tag tidak digunakan kembali. Ada beberapa pola yang dapat Anda ikuti untuk menghasilkan tag unik, termasuk:

  • Stempel tanggal - Pendekatan ini cukup umum, karena Anda dapat dengan jelas mengetahui kapan gambar dibangun. Tapi, bagaimana cara menghubungkannya kembali ke sistem bangunan Anda? Apakah Anda harus menemukan bangunan yang selesai pada saat yang sama? Anda berada di zona waktu apa? Apakah semua sistem bangunan Anda dikalibrasi ke UTC?

  • Git commit - Pendekatan ini berfungsi sampai Anda mulai mendukung pembaruan gambar dasar. Jika pembaruan gambar dasar terjadi, sistem build Anda dimulai dengan Git commit yang sama dengan build sebelumnya. Namun, gambar dasar memiliki konten baru. Secara umum, Git commit menyediakan tag semi-stabil.

  • Manifest digest - Setiap gambar kontainer yang didorong ke registri kontainer dikaitkan dengan manifes, diidentifikasi oleh hash SHA-256 yang unik, atau digest. Meskipun unik, digest-nya panjang, sulit dibaca, dan tidak terkait dengan lingkungan bangunan Anda.

  • Build ID - Opsi ini mungkin yang terbaik karena kemungkinan inkremental, dan memungkinkan Anda untuk berkorelasi kembali ke bangunan tertentu untuk menemukan semua artefak dan log. Namun, seperti digest manifes, mungkin sulit bagi manusia untuk membacanya.

    Jika organisasi Anda memiliki beberapa sistem bangunan, mengawali tag dengan nama sistem bangunan adalah variasi pada opsi ini: <build-system>-<build-id>. Misalnya, Anda dapat membedakan bangunan dari sistem bangunan Jenkins tim API dan sistem bangunan Azure Pipelines tim web.

Mengunci tag gambar yang diterapkan

Sebagai praktik terbaik, kami sarankan Anda mengunci tag gambar yang diterapkan, dengan mengatur atribut write-enabled ke false. Praktik ini mencegah Anda menghapus gambar secara tidak sengaja dari registri dan mungkin mengganggu penyebaran Anda. Anda dapat menyertakan langkah penguncian dalam pipeline rilis Anda.

Mengunci gambar yang disebarkan masih memungkinkan Anda untuk menghapus gambar lain yang tidak diterapkan dari registri Anda menggunakan fitur Azure Container Registry untuk memelihara registri Anda. Misalnya, pembersihan otomatis manifes yang tidak ditandai lebih lama dari durasi yang ditentukan, atau tetapkan kebijakan retensi untuk manifes yang tidak diberi tag.

Langkah berikutnya

Untuk diskusi yang lebih rinci tentang konsep dalam artikel ini, lihat posting blog Docker Tagging: Praktik terbaik untuk menandai dan membuat versi gambar docker.

Untuk membantu memaksimalkan kinerja dan penggunaan registri kontainer Azure yang hemat biaya, lihat Praktik terbaik untuk Azure Container Registry.