Untuk sementara, saya sedang mengerjakan proyek yang menggunakan GitLab Runner dengan Docker sebagai pelaksananya. Karena runner dihosting di CentOS 7, semuanya masuk akal—sampai kami mulai mempertimbangkan untuk memindahkannya ke CentOS 8, dan dunia kami meledak.
Hal pertama yang kami pikirkan adalah, karena Podman adalah pengganti drop-in, ini seharusnya mudah (Anda dapat membayangkan sendiri kebenaran pernyataan itu). Sebenarnya, Podman tidak memiliki API yang digunakan GitLab Runner untuk mengelola container, jadi meskipun kami dapat melakukan semuanya secara manual, kami belum melakukannya.
Oke, kembali ke papan gambar, bagaimana kalau kita mengajukan masalah GitLab untuk GitLab Runner untuk mengimplementasikan Podman sebagai eksekutor? Ternyata masalah itu sudah ada. Jawaban yang diparafrasekan adalah, "kami tidak mengambil pelaksana baru, tetapi jika Anda menulisnya sendiri, kami dapat melihat apakah kami dapat menerimanya." Pengetahuan saya tentang internal GitLab Runner lebih buruk daripada bahasa Jerman saya, dan yang bisa saya katakan hanyalah "Danke", bahkan tidak keseluruhan kata.
Jangan coba ini di rumah
Migrasi "sederhana" ini tidak berarti apa-apa, tetapi, sebagai upaya terakhir, kami pikir, pasti ada cara untuk menginstal Docker di CentOS8. Nah, Anda dapat membaca beberapa "tutorial" yang melakukannya, tetapi tutorial tersebut membuat Anda ingin menonjolkan mata, jadi itu bukanlah pilihan. (Serius, jangan coba ini di rumah).
[ Anda mungkin juga menyukai: Peningkatan integrasi systemd dengan Podman 2.0 ]
Beberapa waktu berlalu, dan untuk sementara kami pindah ke proyek lain yang lebih mendesak. Meskipun kami ingin memindahkan semuanya ke CentOS 8, tidak perlu terburu-buru.
Tetapi kemudian beberapa bulan yang lalu, kami menemukan postingan yang mengatakan bahwa Podman mengimplementasikan REST API yang kompatibel dengan Docker. Rasanya seperti mereka membaca pikiran kita; ini adalah apa yang kami butuhkan. Ini seharusnya mudah sekarang. (Anda lihat ke mana saya akan pergi dengan ini, kan?)
Kami mulai menguji lagi ketika Podman 2.0 dirilis, semuanya senang dan optimis. GitLab Runner terhubung ke soket tetapi gagal membuat volume. Kemudian kami membaca catatan rilis lebih hati-hati, dan mereka mengatakan bahwa titik akhir untuk volume belum diimplementasikan, tetapi sudah ada di pohon utama (segera menjadi 2.1). Jadi kita masih punya kesempatan.
Backport yang diretas
Beberapa hari berlalu; kami membuat backport retas dari titik akhir volume ke 2.0 dan mencoba cabang utama juga, tetapi semuanya gagal, dan kami tidak tahu alasannya.
Untungnya, Podman 2.1 dirilis cukup cepat, dan kami kembali ke jalurnya. Kami mulai lagi, tapi kali ini, kami mengambil pendekatan yang berbeda. Setelah berkomentar sedikit tentang masalah Podman terkait, kami mulai berkumpul di #podman di IRC dan mengajukan pertanyaan tentang masalah ini. Kami mendapat beberapa jawaban dari para pengembang, dan saat itulah segalanya menjadi menarik!
Kami menyiapkan repo pengujian di GitLab, mendaftarkan banyak pelari, dan mulai menangani setiap masalah, satu per satu. Kami juga menyiapkan instance Docker untuk digunakan sebagai baseline tetapi memantau semua komunikasinya dengan GitLab Runner menggunakan socat —dengan begitu, kami dapat melihat dengan tepat apa yang sedang terjadi dan apa yang perlu kami sesuaikan.
Kami mulai dengan masalah di mana pekerjaan itu tampaknya berhasil, tetapi sebenarnya tidak melakukan apa-apa; yang terburuk, itu tidak mencatat apa pun, jadi orang-orang harus memperbaiki log terlebih dahulu dan kemudian kembali ke masalah utama. Dengan menyingkir, ada masalah lain dengan entri /dev, yang juga diselesaikan. Setelah beberapa hari pengujian, semuanya mulai terlihat sangat bagus; kita bisa menjalankan one-liner dengan mudah tanpa banyak kesulitan. Jadi kami pikir kami sudah selesai, tetapi kami sebenarnya masih memiliki sedikit cara untuk pergi.
Ketika kami pindah ke pekerjaan yang berjalan lebih lama, pekerjaan itu dipotong di tengah karena masalah dalam pelacakan koneksi yang tidak aktif. Perbaikan yang menyebabkan masalah lain dengan Podman tidak pernah ditutup, tetapi pengelola Podman mengatasi kedua masalah ini.
Bug untuk bug
Namun, ada satu masalah yang mengganggu kami sejak awal—itu menyebabkan kami harus menghapus volume sebelum setiap kali dijalankan. Hal yang tidak seorang pun memberi tahu Anda tentang kompatibilitas adalah terkadang, untuk mencapai ini, Anda harus kompatibel dengan bug-untuk-bug. Docker memiliki masalah yang diajukan lebih dari lima tahun yang lalu tentang fakta bahwa ketika Anda meminta untuk membuat volume yang sudah ada, volume tersebut akan menampilkan "semuanya baik-baik saja" dan bertindak seolah-olah tidak pernah terjadi apa-apa. Podman, di sisi lain, mengembalikan pesan kesalahan yang benar (penekanan pada "was" karena sekarang ia bertindak dengan cara yang sama seperti Docker, setidaknya dalam mode compat. Bug-for-bug, kan?)
Dengan tidak adanya masalah besar tersebut, beberapa hal kecil muncul, tetapi semuanya berjalan lancar, setidaknya sejauh yang kami bisa uji.
[ Panduan pemilik API:7 praktik terbaik program API yang efektif ]
Menutup
Jadi, bagaimana keadaannya sekarang? Nah, semua masalah yang kami alami dengan Podman semuanya sekarang telah diperbaiki di cabang utama, dan jika semuanya berjalan dengan baik, itu akan menjadi bagian dari rilis Podman 2.2 yang akan datang. Itu akan menandai rilis Podman pertama yang dapat dijalankan dengan GitLab Runner langsung dari kotaknya, tanpa ia menyadari bahwa ia sedang berbicara dengan Podman. Itu adalah pencapaian yang sangat penting bagi kami.