Get best of the week

Bagaimana menjadi insinyur DevOps dalam enam bulan atau bahkan lebih cepat. Bagian 5. Penempatan

Bagaimana menjadi insinyur DevOps dalam enam bulan atau bahkan lebih cepat. Bagian 1. Pendahuluan
Bagaimana menjadi insinyur DevOps dalam enam bulan atau bahkan lebih cepat. Bagian 2. Konfigurasi
Cara menjadi insinyur DevOps dalam enam bulan atau bahkan lebih cepat. Bagian 3. Versi
Bagaimana menjadi insinyur DevOps dalam enam bulan atau bahkan lebih cepat. Bagian 4. Pengemasan perangkat lunak



Segarkan memori


Gambar di atas menunjukkan seperti apa penyebaran kode biasa. Biarkan saya mengingatkan Anda di mana kami sekarang sesuai dengan peta jalan:



Jika Anda menghabiskan satu bulan untuk mempelajari setiap bagian, sekarang Anda berada di 4 bulan. Pada saat ini, Anda harus sudah tahu bagaimana menyediakan infrastruktur yang akan bekerja dengan perangkat lunak Anda, cara mengelola versi perangkat lunak dengan benar, dan cara mengemasnya untuk penggunaan di masa mendatang. Pada artikel ini, kami akan membahas cara menerapkan kode Anda dengan benar!

Penerapan Kode


Apakah Anda memperhatikan bahwa saya mengatakan "bagaimana", dan bukan "bagaimana mudah"? Bukan hanya itu saja. Sayangnya, penyebaran kode yang benar dari lingkungan pengembangan ke lingkungan prod masih merupakan proses yang menyakitkan, penuh dengan kesalahan dan crash. Ada banyak alasan untuk ini, tetapi, menurut pendapat saya, ini terutama disebabkan oleh perbedaan antara lingkungan di mana kode dibuat dan lingkungan di mana ia dijalankan.

Meminimalkan perbedaan-perbedaan ini adalah hal terbaik yang dapat Anda lakukan tidak hanya selama proses penyebaran, tetapi juga selama eksekusi setelah penerapan. Jadi, bagaimana kita mengurangi dan / atau menghilangkan perbedaan antara lingkungan prod dan non-prod kita?

Dan itu bekerja pada mobil saya!


Jika infrastruktur dev Anda terlihat seperti ini:



Dan infrastruktur prod terlihat seperti ini:



Pertimbangkan masalah Anda. Jika Anda menggunakan infrastruktur sebagai kode, dan tidak mengonfigurasi berbagai hal secara manual, maka Anda dapat menyelesaikannya hingga 90%. Jika tidak, jangan putus asa - Anda tidak sendirian. Sorot sore hari, tentukan kesenjangan yang Anda miliki (pembelajaran, budaya, orang, proses, dll.) Dan secara metodis mengisinya satu per satu.

Intinya adalah bahwa Anda tidak akan berhasil mengelola tumpukan teknologi modern jika Anda masih mengkonfigurasi hal-hal secara manual. Ini adalah aksioma. Hal pertama yang perlu Anda lakukan adalah memastikan bahwa segala sesuatu yang terkait dengan prod adalah artefak versi yang digunakan oleh server penempatan Anda.

Dengan asumsi semua ini telah dilakukan, saya akan mengambil kebebasan menyatakan bahwa cara terbaik untuk menyebarkan kode adalah tidak menyebarkannya sama sekali.

Pendekatan Penerapan Modern


Memang benar bahwa menyebarkan kode pada mesin adalah gema dari tahun 1990-an. Masalah terbesar ketika menyebarkan kode ke satu set mesin produksi adalah bahwa, menurut definisi, server prod Anda (di mana kode dieksekusi) berbeda dari server dev Anda (di mana kode ini ditulis). Tidak mengherankan bahwa segera setelah penempatan ada banyak masalah yang belum pernah diketahui sebelumnya, karena sekarang kondisinya telah berubah!

Jadi sebelum Anda menggunakan, Anda perlu memastikan bahwa artefak penempatan Anda adalah seluruh runtime, bukan bagian dari kode. Dengan kata lain, sebarkan kode Anda sekali di lingkungan pengembangan, kloning seluruh mesin yang menjalankan kode Anda, dan kemudian salin di mana pun seharusnya.



Ini disebut "penyebaran tidak berubah" dan merupakan template yang sangat kuat yang akan menghemat banyak sakit kepala setelah penyebaran. Tentu saja, jika Anda menjalankan wadah, ide yang sama berlaku: Anda menggunakan wadah yang sama di mana-mana. Anda bisa mengatakan: "berhenti! Prod saya berbeda dari dev! ”Dan itu benar, karena nama pengguna / kata sandi basis data, string koneksi, lokasi tempat sampah S3 semuanya berbeda! Ya, mereka adalah hal yang sangat berbeda.

Cara untuk mengatasi masalah ini adalah dengan menggunakan prinsip konfigurasi aplikasi 12 faktor. Aplikasi dua belas faktor menyimpan konfigurasi dalam env vars, atau variabel lingkungan env. Variabel lingkungan dapat dengan mudah diubah antara penerapan tanpa mengubah kode. Tidak seperti file konfigurasi, ada kemungkinan lebih kecil untuk secara tidak sengaja menyimpannya ke repositori kode, dan tidak seperti file konfigurasi khusus atau mekanisme konfigurasi lainnya, seperti Java System Properties, mereka adalah bahasa dan standar independen sistem operasi. Dengan demikian, seluruh konfigurasi Anda harus dieksternalisasi dan ditransfer sebagai variabel lingkungan ke komputer Anda.

Misalnya, jika Anda berada di AWS, gunakan SSM sebagai repositori eksternal parameter - terintegrasi sempurna dengan CloudFormation. Juga sangat mudah untuk mengatur variabel lingkungan langsung dari perintah AWS ssm cli. Tentu saja, penyedia cloud lainnya memiliki mekanisme serupa.

Juga, tahan keinginan untuk "memperbaiki" mesin prod Anda ketika terjadi kesalahan. Mesin harus tidak berubah, yang berarti bahwa semua koreksi yang Anda lakukan harus berasal dari dev. Tujuan Anda seharusnya untuk mencegah akses ke mesin prod sama sekali. Baik ssh, atau scp, atau akses prod - tidak pernah untuk siapa pun, tidak untuk dirinya sendiri, atau untuk peretas pemula.

Tetapi bagaimana jika saya perlu log untuk memperbaiki masalah? Anda menebaknya - majalah Anda juga harus dieksternalisasi, idealnya dikirim ke lokasi lain, baik menggunakan tumpukan ElasticSearch / Logstash / Kibana (ELK), atau menggunakan perangkat lunak komersial seperti SumoLogic atau Datadog.

Apa pun yang Anda lakukan, mesin prod Anda adalah "ternak yang bekerja" yang diganti pada tanda sedikit sakit. Mereka bukan "hewan peliharaan" yang perlu dirawat untuk disembuhkan dengan menghabiskan berjam-jam pemecahan masalah.

Saya tahu bahwa analogi ini terlalu sering digunakan, dan saya mendengar dari orang-orang yang benar-benar peduli tentang ternak bahwa ini tidak sepenuhnya benar, tetapi intinya sama - jangan “memperbaiki” mesin-mesin Anda, hanya perbaiki perkembangan Anda dan gunakan kembali .

Mekanisme Penerapan Kode


Jadi, Anda tahu apa yang harus dilakukan, tetapi Anda tidak tahu caranya. Sayangnya, ini adalah tempat Jenkins muncul. Jika Anda tidak tahu, maka Jenkins adalah salah satu server otomatisasi penyebaran open source yang paling populer.



Saya mengatakan "sayangnya" karena Jenkins (dan pendahulunya Hudson) telah ada di sekitar kita selama hampir sepuluh tahun, dan ini terlihat. Ini rumit untuk diatur dan bahkan lebih sulit untuk dipelihara. Muncul dengan jutaan plugin dengan kualitas yang meragukan. Plugin ini, pada dasarnya, rusak pada waktu yang paling tidak tepat, menjatuhkan semua yang lain di belakangnya. Bahkan, benar-benar stabil, bengkel Jenkins jarang dan biasanya hanya terlihat di organisasi terbesar.

Mengapa saya menyarankan Anda mulai dengan Jenkins? Karena, terlepas dari semua kekurangannya, masih sangat populer dan banyak digunakan di bidang TI. Mengenal Jenkins, khususnya bagaimana Jenkinsfile terstruktur , merupakan keuntungan besar bagi prospek pekerjaan dan tidak dapat diabaikan. Saat menjelajahi Jenkins, pastikan Anda menggunakan plugin Pipeline BlueOcean baru , dan bukan pada pipeline pekerjaan Jenkins yang sudah usang. Ini sangat penting jika Anda ingin pipa CI / CD Anda hidup tepat di dalam kode repo GitHub / GitLab Anda. Jadi, pipa itu sendiri adalah sepotong kode versi!



Faktanya, ini sangat penting sehingga perlu diulangi lagi: semuanya adalah kode! Aplikasi Anda, bagaimana itu digunakan, bagaimana itu dilacak, bagaimana itu dikonfigurasi, dll semua potongan kode berversi tepat disimpan di GitHub / GitLab / Anywhere. Tujuannya adalah untuk menciptakan lingkungan yang bebas dari ketidakkonsistenan untuk pengembang utama (insinyur perangkat lunak yang menulis kode fungsional).

Misalnya, saya harus dapat:

  • tulis microservice kecil Anda sendiri;
  • tambahkan tes yang menurut saya perlu;
  • Tambahkan Jenkinsfile
  • tambahkan konfigurasi monitoring-as-code;
  • tentukan parameter saya di file env.yaml;
  • simpan semua ini dalam satu repositori;
  • membuat Jenkins secara otomatis mendeteksi repositori yang ditentukan;
  • bangun microservice Anda;
  • menguji;
  • Expand (menggunakan metode Canary atau Blue-Green);
  • mengatur pengiriman pesan ke email Anda ketika ini selesai!

Inilah tujuannya, pencapaian yang merupakan inti dari misi inti para insinyur DevOps.

Alternatif untuk Jenkins


Seperti yang saya katakan sebelumnya, Jenkins sudah ada sejak lama, dan hari ini ada yang lain, menurut pendapat saya, yang terbaik, meskipun alternatif yang kurang populer. Salah satunya adalah AWS CodeDeploy . Ini memiliki keterbatasan, tetapi pengembang telah membuat peningkatan yang signifikan selama setahun terakhir, dan jika Anda bekerja di AWS, saya mendorong Anda untuk mencoba CodeDeploy.

Alternatif kedua adalah modul integrasi kontinu GitLab CI. Jika organisasi Anda menjalankan GitLab, Anda mungkin harus mulai bekerja dengannya, karena cukup terintegrasi dengan GitLab lainnya.

Akhirnya, GitHub telah mengumumkan alatnya sendiri untuk menyebarkan aplikasi Tindakan , yang didukung oleh otomasi mereka sendiri.

Faktanya, saya tidak berpikir alat sangat penting di sini. Adalah penting untuk mengetahui bahwa segala sesuatu, termasuk pipa penyebaran kode, adalah artefak berversi, dan tidak ada yang lebih baik kecuali jika itu berasal dari dev.

Bagaimanapun juga, jika Anda mulai dengan Jenkins, cobalah mengaturnya sebagai sebuah wadah. Ini tidak terlalu sulit dan akan menjadi kesempatan luar biasa untuk mempelajari cara menggunakan server kontainer Jenkins dengan Jenkins yang dapat diperluas, node kerja kontainer. Bahkan, Anda dapat memulai tanpa orkestrasi wadah, yang merupakan subjek dari artikel selanjutnya.

Akan dilanjutkan segera ...

Sedikit iklan :)


Terima kasih untuk tetap bersama kami. Apakah Anda suka artikel kami? Ingin melihat materi yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman Anda, cloud VPS untuk pengembang dari $ 4,99 , analog unik dari server entry-level yang diciptakan oleh kami untuk Anda: Seluruh kebenaran tentang VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps mulai dari $ 19 atau cara membagi server? (opsi tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).

Dell R730xd 2 kali lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya kami yang memiliki 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV dari $ 199 di Belanda!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mulai dari $ 99! Baca tentang Cara Membangun Infrastruktur Bldg. kelas c menggunakan server Dell R730xd E5-2650 v4 seharga 9.000 euro untuk satu sen?

More articles:


All Articles