Bagaimana cara menyusun kode terkait DevOps dan konfigurasi dalam repositori kode?


10

Kami telah berkembang sebagai perusahaan, produk kami berkembang dan kegiatan dan upaya yang terkait dengan DevOps kami juga tumbuh - kami telah beralih dari Bamboo ke Jenkins yang lebih fleksibel dan dapat dikonfigurasi, menggunakan jaringan pipa penyebaran dan plugin lainnya; beralih ke Ansible dan mulai menggunakan Docker di sana-sini secara internal.

Semua hal ini memerlukan beberapa tingkat pengkodean atau konfigurasi - Skrip dan konfigurasi yang memungkinkan, skrip groove Jenkins, konfigurasi Dockerfiles dan YAML.

Untuk saat ini, kami telah membuat terpisah "ops" repositori dengan direktori tingkat tinggi untuk jenkins, ansible, dockerdan other(yang merupakan nama yang mengerikan, tapi untuk saat ini semua otomatisasi "lainnya" DevOps hal-hal yang ada).

Pendekatan kami tidak terasa benar dan mungkin tidak skala, tetapi apa praktik terbaik dan rekomendasi untuk menjaga kode terkait DevOps dalam repositori atau repositori kode?


6
Saya menggunakan metode "setiap bagian adalah aplikasi, satu repo per aplikasi", dalam chef yang berarti 1 repo per buku masak.
Tensibai

@Tensibai benar, saya takut satu repo "ops" akan dengan cepat menjadi tidak praktis. Terima kasih.
alecxe

1
Itu telah menjadi bentuk warisan manajemen buku masak di chef, 1 repo dengan semua buku resep, dan terbukti sebagai footgun dalam banyak kasus karena perubahan, tapi aku kurang nyaman dengan mengatakan bahwa itu akan cocok juga, pipa Jenkins (jika v2) dan File buruh pelabuhan harus hidup dengan proyek yang mereka tangani IMO, dan saya tidak tahu apa yang Anda masukkan di bawah yang lain sehingga saya tidak bisa benar-benar memberikan saran apa pun di sini
Tensibai

@Tensibai mengerti! Lainnya sebagian besar terdiri dari utilitas bash dan python atau skrip yang dieksekusi secara berkala untuk beberapa alat internal..mereka tidak benar-benar cocok di mana pun dan kami tidak dapat memikirkan tempat yang lebih baik daripada "lainnya" .. Saya akan melihat apakah saya dapat memposting konten direktori menjadi pertanyaan juga. Terima kasih.
alecxe

1
Saya akan membaginya dalam beberapa repo dengan 'afinitas' kerja, skrip yang bekerja pada aplikasi X bersama-sama, Anda mungkin memiliki skrip yang digunakan pada dua aplikasi, tetapi jika aplikasi A mengubah cara skrip harus menangani aplikasi mana ia berbicara untuk , lebih baik memiliki dua versi yang terpisah, jadi ATEOTD saya akan menyimpannya dengan aplikasi yang terkait atau jika mereka span beberapa aplikasi dalam repositori spesifik per tugas, sehingga Anda selalu memiliki versi yang sejalan dengan aplikasi yang digunakan dan Anda tidak perlu memberi tag pada skrip yang tidak terkait pada saat yang bersamaan.
Tensibai

Jawaban:


3

Organisasi saat ini dari kode dan konfigurasi yang Anda gambarkan disusun oleh solusi teknis yang terlibat. Ini adalah desain yang buruk yang akan menambah banyak overhead dalam kegiatan pemeliharaan kami dan juga akan menambahkan banyak jebakan di jalan kami. Sebagai gantinya, organisasi itu harus terstruktur di sekitar artefak yang kami sebarkan.

Alasan untuk ini adalah bahwa kami ingin mempertimbangkan artefak ( misalnya gambar buruh pelabuhan atau paket perangkat lunak) sebagai objek dari kata kerja berikut:

  • membangun
  • uji
  • menyebarkan

untuk mempertimbangkan set minimal tugas otomatis yang ingin kita lakukan. Jika kita ingin mengubah sesuatu tentang bagaimana kata kerja tes diimplementasikan, mudah untuk mengunjungi folder yang sesuai dengan artefak dalam repositori yang sesuai dan kemudian menemukan item otomatisasi khusus jenkins yang perlu diperbarui. Sebaliknya, jika resep otomasi terstruktur di sekitar solusi teknis, maka kita perlu mengetahui bahwa jenkins terlibat dalam prosedur pengujian dan menemukan item otomatisasi terkait artefak di sana. Dalam situasi yang kompleks, organisasi di sekitar solusi teknis membuat pembaruan sangat sulit, karena kita harus mengetahui secara apriori semua solusi teknis yang terlibat dalam beberapa layanan untuk memperbaruinya.

Misalnya repositori yang berisi kode untuk situs web dan layanan mikro "a" dapat memiliki sub-direktori berikut yang didedikasikan untuk operasi:

./ops/website
./ops/micro-service-a

masing-masing memiliki tiga skrip yang dipanggil build, testdan deploy. Sekarang organisasi item otomasi telah diklarifikasi, mari kita mengalihkan perhatian ke konfigurasi.

Kondisi dan persyaratan utama tentang organisasi konfigurasi ditetapkan oleh deploykata kerja ketika diterapkan pada artefak seperti layanan. Kata deploykerjanya harus memiliki parameter berikut:

  • versi artefak untuk digunakan,
  • target penyebaran artefak, yang menggambarkan lingkungan konkret tempat artefak yang digunakan akan dijalankan ( mis. kluster dan titik akhir yang harus diajak bicara)
  • kredensial yang harus digunakan untuk terhubung ke titik akhir lainnya ( mis. database)
  • konfigurasi runtime (seperti berapa lama entri cache seharusnya hidup, dll.)

Dari perspektif operasional, pemecahan parametrisasi ini sesuai dengan derajat alami kebebasan masalah penyebaran - selain dari kredensial yang dapat digabungkan dengan konfigurasi runtime, tetapi lebih baik memisahkannya untuk menghindari penyebarannya secara sembarangan.


5

Saya dapat menjawab tentang buruh pelabuhan, salah satu praktik terbaik untuk menggunakan buruh pelabuhan adalah dengan menyimpan file buruh pelabuhan dan menulis file dalam repositori proyek yang sama, jadi di mana pun Anda mengkloning proyek, Anda dapat membuat gambar buruh pelabuhan, dan ada baiknya untuk simpan beberapa versi buruh pelabuhan menulis file misalnya (prod, staging, dev) sehingga Anda dapat membangun gambar dan menjalankan wadah dengan opsi spesifik untuk setiap env misalnya untuk mesin dev Anda dapat menggunakan jaringan tertentu dan menjalankan lebih banyak dependensi wadah atau apa pun.


4

Setiap kode alat masuk ke dalam repo sendiri. untuk mis

  1. Template Jenkins Groovy menjadi repo Jenkins
  2. Playbook YAML yang memungkinkan dalam repo sendiri (dengan peran, tugas, sub direktori inventaris
  3. Templat Cloudformation / Terrform dalam repo sendiri
  4. File Docker di 5 sendiri .. Dan Sebagainya

Ini akan membantu Anda meningkatkan skala dalam hal proses orkestrasi dan mempertahankan berbagai cabang untuk setiap lingkungan

Ini akan memberi Anda lebih banyak kontrol granular dan membongkar semua overhead versi Anda ke sistem kontrol versi. Juga buat cabang terpisah untuk setiap lingkungan dan beri tag kode untuk setiap rilis produksi (seperti yang kami lakukan untuk basis kode aplikasi). Pikirkan Infra dan proses dalam hal kode. (Setiap perubahan dalam proses harus dikodifikasi dan dikirim ke QA, SIT, UAT dan kemudian ke PROD) mirip dengan aplikasi.

Misalnya, Anda mungkin memiliki V2.1 dari Ansible running di Production (master branch) tetapi V2.0 dari docker container berjalan di Prod (master branch)

Demikian pula, simpan skrip DB / skrip bash di repositori mereka sendiri dan mungkin Anda dapat memiliki file periksa kesehatan (JSON / YAML) yang dikonfigurasikan untuk memperlihatkan versi semua alat / bagian di setiap URL yang dikerahkan untuk setiap tujuan pelacakan dan otomatisasi. (Agar webhook Anda membaca URL dan mengotomatiskan penerapan)


2
Jebakan dari pendekatan ini adalah, v2.1 dalam qa dan tidak divalidasi dan Anda harus menambal produksi dengan segera, Anda tidak dapat memodifikasi v2.0 dan jika Anda membuat v2.2 untuk tambalan ini ada risiko tinggi menjadi hilang atau ditimpa ketika v2.1 pergi ke produksi, kalikan dengan jumlah kode terpisah dalam repo dan Anda segera memiliki mimpi buruk dari backports (berfungsi, tapi saya harus menambahkan penafian ini :))
Tensibai

3
Menggunakan cabang untuk melacak informasi khusus lingkungan / penyebaran tampak seperti pola-semut bagi saya: jika kami memiliki 20 lingkungan, ini berarti bahwa kami memiliki 20 cabang yang harus disinkronkan ... kemungkinan sumber kesalahan dan kebingungan. Bisakah Anda menjelaskan mengapa Anda tidak menggunakan file konfigurasi untuk melacak informasi khusus lingkungan / penyebaran dan apa alur kerja Anda bekerja dengan cabang-cabang ini? Ini bukan masalah sepele!
Michael Le Barbier Grünewald

3

Membuat perbedaan antara Ops, Dev dan DevOps mempromosikan isolasi dan menerapkan pola pikir "melemparkannya di atas tembok". Untuk meningkatkan kerja sama antar tim, seseorang harus meletakkan segala sesuatu di repositori yang diperlukan untuk membangun dan menggunakan proyek.

Karena itu, jawaban untuk pertanyaan:

Bagaimana cara menyusun kode terkait DevOps dan konfigurasi dalam repositori kode?

adalah bahwa jika konfigurasi diperlukan untuk menjalankan proyek maka seseorang harus meletakkannya di direktori yang sama.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.