CI runner di server yang sama dengan GitLab?

Saya sedang menyiapkan server GitLab di perusahaan saya dan sekarang saya menambahkan GitLab CI ke dalamnya.

Sebelum memulai tugas ini saya ingin memahami jika ada kerugian menjalankan pelari saya di server yang sama yang digunakan oleh GitLab dan GitLab CI.

Saya telah membaca bahwa ada masalah keamanan tetapi kami hanya menggunakannya secara internal sehingga saya tidak berpikir ini bisa menjadi masalah.

Apakah saya melewatkan sesuatu?

git continuous-integration gitlab

— Fez Vrasta
sumber

Jawaban:

Bayangkan situasi berikut:

Pengembang internal ingin mencelakakan perusahaan (karena menganggap dibayar rendah, karena bosnya tidur dengan istrinya; alasannya tidak penting). Ia melakukan pengujian unit yang, ketika dijalankan, alih-alih menguji aplikasi, mencari repositori GitLab dan menghapusnya. Di komit berikutnya, kejutan, semua kode sumber proyek hilang (tetapi Anda melakukan backup dan Anda mengujinya, kan?)
Atau pemberitahuan pengembang yang sama bahwa cadangan repositori dikonfigurasikan pada mesin yang sama. Dia mengubah konfigurasi ini melalui uji unit, sehingga cadangan sekarang berisi repositori yang berbeda, dan menunggu selama sebulan — waktu cadangan disimpan. Sekarang semua cadangan rusak, ia dapat melakukan tes unitnya yang menghapus kode sumber dari server.
Atau magang ingin menjual kode sumber ke kompetisi. Anda telah mengkonfigurasi akses dengan hati-hati, membatasi hanya pada apa yang dia butuhkan untuk pekerjaannya. Pada saat yang sama, ia memiliki akses tak terbatas ke repositori itu sendiri melalui unit test, mampu melakukan dump lengkap.

Kecuali tes unit dijalankan dalam konteks izin terbatas dan tidak dapat mengakses apa pun di luar direktori dan file yang mereka butuhkan untuk pengujian, menggabungkan server CI dengan server yang membuat repositori Anda memang berbahaya.

Masalah lain adalah bahwa server kontrol versi diharapkan lebih cepat. Server CI yang diinstal pada mesin yang sama dapat memperlambat komit.

— Arseni Mourzenko
sumber

Kami adalah 3 pengembang ... jika seseorang dari kami ingin merugikan perusahaan, ia dapat melakukan itu dalam ribuan cara = (... Jadi satu-satunya masalah adalah kinerja yang lambat, tetapi jika saya menggunakan mesin yang bagus saya seharusnya tidak memiliki besar masalah, kan? Terima kasih!

— Fez Vrasta

ps: bagaimana dengan chroot? Tidak dapat digunakan untuk membuat proses ini aman?

— Fez Vrasta

@FezVrasta: jika keamanan tidak menjadi perhatian dalam kasus Anda, juga bukan kinerja, satu-satunya keuntungan memiliki mesin terpisah yang dapat saya lihat adalah skalabilitas di masa depan. Tapi sejujurnya, melakukan perubahan sebelum masalah skalabilitas muncul terlihat mirip dengan optimasi prematur.

— Arseni Mourzenko

@FezVrasta: "bagaimana dengan chroot? Tidak dapat digunakan untuk membuat proses ini aman?" - Saya tidak memiliki cukup keterampilan dalam keamanan Unix untuk menjawab pertanyaan itu.

— Arseni Mourzenko

Mengingat bahwa tidak ada server pusat "semua yang tahu" untuk git ini tidak buruk karena akan dengan beberapa sistem kontrol kode sumber lainnya.

Asalkan ada syk otomatis dari server git di luar situs ke server git anter (yang diuji) saya tidak akan khawatir tentang pengaturan ini di sebuah perusahaan kecil.

Idealnya saya ingin melihat pengembang mendorong perubahan mereka ke server git server offset, kemudian server CI untuk menarik biaya dari server offset - dengan cara itu server luar kantor diuji ketika setiap check-in dilakukan.

Jika pengembang kemudian selalu melakukan penarikan dari server di tempat untuk menghemat waktu, itu bukan masalah.

— Ian
sumber

jika saya membutuhkan 2 server ... mengapa saya tidak menjalankan runner di server ke-2?

— Fez Vrasta

@FezVrasta, " server luar kantor " dapat siapa saja yang akan menjual git hosting kepada Anda, tidak harus menjadi server yang Anda miliki. Juga karena melalui internet melakukan tarik dari itu akan lambat.

— Ian

Saya menyiapkannya untuk perusahaan saya, kami menggunakan server kami sendiri ...

— Fez Vrasta