Hari ini kita akan berbicara tentang apa itu SCM dan menceritakan beberapa kisah melalui prisma yang akan kita pertimbangkan Ansible, SaltStack, Chef and Puppet, memilih opsi terbaik untuk tugas tertentu.
Materi ini didasarkan pada transkrip
laporan oleh Andrei Filatov , insinyur sistem utama di EPAM Systems, dari konferensi Oktober DevOops 2017 kami.
Apa itu SCM dan apa yang dimakannya?
Apa itu SCM? Pertama-tama, itu adalah hal yang memungkinkan infrastruktur kami dari keadaan A untuk mengeksekusi negara B dengan mengeksekusi beberapa kode. Banyak pengembang yang bukan insinyur DevOps dalam praktik berpikir bahwa ada sesuatu yang terjadi dengan cara "otomatis". pada infrastruktur.
Metode "otomatis" mengimplementasikan kami SCM (System Configuration Management). Untuk apa ini? Terutama untuk membangun infrastruktur yang berulang dan konsisten. SCM memperluas proses CI / CD dengan baik. Karena ini adalah kode, ini dapat disimpan dalam sistem kontrol versi apa pun: Git, Mercurial. Cukup sederhana untuk dikembangkan dan dipelihara.
Final adalah siklus otomatisasi tertutup: semuanya dapat dilakukan secara otomatis, mulai dari membuat infrastruktur hingga menggunakannya dan menggunakan kode.
Apa itu SCM: Ansible
Pertimbangkan pelamar kami. Yang pertama adalah Ansible. Ini memiliki arsitektur tanpa agen, jika kita berbicara tentang versi open source, ditulis dengan Python, ia memiliki DSL seperti Yaml, mudah diperluas karena modul yang ditulis dengan Python, sangat sederhana dan ringan. Ansible memiliki ambang masuk terendah - Anda dapat mengajar siapa pun.
Ada pengalaman ketika seseorang, tidak tahu Python, tidak tahu apa-apa tentang SCM, masuk Ansible hanya dalam dua hari dan sudah mulai melakukan sesuatu.
Di bawah ini adalah contoh dari ChatOps: pemberi notifikasi di Slack. Kode Ansible yang melihat Yaml bukanlah hal baru.
- block: - name: "SlackNotify : Deploy Start" local_action: module: slack token: "{{ slack_url }}" attachments: - title: "Deploy to {{ inventory_hostname }} has been Started" text: "<!here> :point_up_2:" color: "#551a8b" - include: configure.yml tags: - configure - include: remote-fetch.yml tags: - remote - include: assets.yml
Apa itu SCM: Koki
Chef adalah arsitektur klien-server, ada server Chef dan klien Chef. Konfigurasi berbasis pencarian, ditulis dalam Ruby, memiliki Ruby DSL. Dengan demikian, di dalam buku resep dan masakan Anda, Anda dapat menggunakan kekuatan penuh Ruby, tetapi saya tidak menyarankan melakukan ini. Chef memiliki komunitas besar dan seperangkat alat terbesar di antara semua SCM. Ini seperti apa kode Chef, ini adalah penyebaran Jetty.
Apa itu SCM: SaltStack
SaltStack memiliki arsitektur tanpa agen yang bekerja dalam mode dorong menggunakan Salt-SSH, dan arsitektur client-server ketika ada Salt-master dan Salt-minion. Penekanannya adalah pada otomatisasi waktu nyata, eksekusi paralel dari semua proses, dan ditulis dengan Python. Juga bahasa seperti Yaml, kode ini sangat mirip dengan Ansible.
#ntp-packages: pkg.installed: - pkgs: - ntp - ntpdate #/etc/ntp.conf: file: - managed - source: salt:
Apa itu SCM: Wayang
Penawar terakhir kami adalah Wayang. Ini juga memiliki arsitektur client-server, seperti Chef, konfigurasi tidak didasarkan pada pencarian, tetapi pada "fakta" yang datang dengan Puppet-master, ditulis dalam Ruby, memiliki DSL seperti Ruby. Tetapi orang-orang Wayang tidak diizinkan untuk menggunakan kode Ruby murni dalam manifes mereka. Ini adalah plus dan minus. Ini adalah seperti apa kode manifestasi Wayang:
class { 'mysql::server' : root_password => 'password' } mysql::db{ ['test', 'test2', 'test3']: ensure => present, charset => 'utf8', require => Class['mysql::server'], } mysql::db{ 'test4': ensure => present, charset => 'latin1', } mysql::db{ 'test5': ensure => present, charset => 'binary', collate => 'binary', }
SCM dalam praktek
SaltStack dalam lingkungan demiliterisasi
Pertama-tama, saya ingin membagikan proyek yang ditulis di SaltStack. Ini adalah proyek kami sebelumnya dan rasa sakit yang paling segar, dan rasa sakit yang paling segar selalu yang paling menyakitkan. Pelanggan kami terlibat dalam penyimpanan data - ini adalah produksi server besi untuk menyimpan data pada GPFS, GlusterFS, tetapi pembuatan kustom. Dia datang kepada kami dengan tugas-tugas berikut:
- Membuat penginstal USB / DVD. Anda perlu membuat media dari mana semuanya diinstal. Ini dilakukan untuk pelanggan pelanggan yang tinggal di daerah tertutup, di mana server paling sering tidak memiliki Internet. Kita perlu mengemas dalam satu ISO, mengirim ke insinyur lapangan yang akan menyebarkan semua yang dibutuhkan di situs.
- Menyebarkan sekelompok produk. Pelanggan memiliki beberapa produk besar, kami harus dapat menggunakannya dalam mode kluster.
- Manajemen, konfigurasi, dan pemeliharaan cluster menggunakan CLI-utility. Kerangka kerja kami harus membantu insinyur lapangan mengelola kluster.
Pelanggan memiliki beberapa persyaratan. Pertama-tama, ia memiliki sejumlah besar keahlian Python, bahkan hanya pengembang C dan Python. Pelanggan segera berkata: "Kami ingin SaltStack", tanpa meninggalkan pilihan.
Apa yang kita hadapi Pelanggan memiliki beberapa produk dalam instalasi, semua harus dengan Salt-Masters. Tetapi kita dihadapkan dengan masalah penskalaan konfigurasi Multi-Master. Misalnya, di Info NODE (status server tertentu), kami memilih milidetik dengan konfigurasi dua-master, detik dengan tiga master, dan dengan lima kami tidak pernah menunggu operasi selesai. MultiMaster adalah fitur yang baik, tetapi tidak skalanya dengan baik.
Masalah kedua yang kami temui adalah kerja tim: SaltStack memiliki Runner and Module. Modul adalah ekstensi yang beroperasi pada Salt Minion, di sisi mesin. Runner berjalan di sisi server. Kami sering mengalami pertempuran: apa yang harus dilakukan Runner, dan apa yang harus dilakukan Modul.
Lalu kami menemukan kejutan kecil dari cache.mine:
ime = ImeActions() id = __grains__['id'] if id == ime.master_id: ret = __salt__['mine.get'](id, 'ime_actions.make_bfs_uuid') ime_dict = ret.get(id, None) if not ime_dict: try: result = __salt__['mine.send']('ime_actions.make_bfs_uuid') except Exeption, e: log.error("Failed to generate uuid: {0}.".format(str(e))) result = False else:
Kami memiliki utilitas yang ditulis dalam C. Kami menjalankannya, itu menghasilkan ID acak. Itu harus unik di antara semua peserta di cluster, masing-masing, kita perlu melakukan ini sekali pada master, dan kemudian mendistribusikannya di antara mesin. Kami menggunakan cache.mine untuk ini. Ternyata, dia tidak mengalami reboot.
"Kondisi balapan." Paralelisasi baik, tetapi dalam keadaan konfigurasi dasar.orchestrate masuk ke state.sls sedang berjalan jika proses panjang terjadi. Pada batas waktu, dia percaya bahwa Negara telah selesai, meskipun masih berjalan, dan sedang mencoba untuk memulai yang berikutnya. Terjadi kesalahan. Dan masalah ini belum diperbaiki.
Anda dapat
melihat GitHub .
Apa yang bisa kami gunakan selain SaltStack?
SaltStack di lingkungan DMZ
- DMZ Paket koki hebat, Wayang juga. Dan dengan Ansible, masalahnya adalah - jika tidak ada Tower - tidak ada cara untuk memulai konfigurasi dalam mode Tarik dari node kami, yang harus dilakukan di zona demiliterisasi.
- Kerangka kerja untuk CLI (dalam Python). Chef dan Wayang tidak sangat cocok, tetapi jika Anda tidak memiliki batasan untuk hanya menggunakan Python, Anda dapat menulis dalam Ruby dan menggunakan API Chef atau Wayang. Toolkit yang mungkin tidak mendukung ini.
- Manajemen Cluster. Chef sangat cocok untuk mengelola cluster, Wayang juga, dan Ansible pada awalnya ditulis untuk mengelola cluster di Amazon.
Koki di lingkungan yang besar dan dinamis
Pelanggan datang dengan tugas mengkonsolidasikan semua sumber daya dalam satu cloud - itu adalah Openstack. Sebelum itu, semuanya tersebar: sesuatu di Rackspace Cloud, sesuatu di server khusus atau pusat data pribadi mereka.
Mereka menginginkan manajemen sumber daya yang sepenuhnya dinamis, dan juga agar aplikasi mereka dapat menambah kapasitas bagi diri mereka sendiri jika perlu. Artinya, kita membutuhkan infrastruktur dinamis yang lengkap dan lingkungan yang sepenuhnya dinamis baik naik turun.
Untuk membangun proses CD dengan benar, Anda memerlukan lingkungan yang sepenuhnya otomatis. Kami menciptakan SDLC - Siklus Hidup Pengembangan Perangkat Lunak untuk mereka, dan menerapkannya, termasuk untuk SCM. Mereka lulus tes integrasi tidak hanya dari aplikasi, tetapi juga infrastruktur.
Karenanya, ketika ada yang tidak beres dengan kami, kami, seperti orang-orang dari Netflix, harus dapat membunuh sumber daya yang rusak dan mengembalikan pekerja yang baru dan terjamin ke tempat mereka.
Masalah apa yang kita hadapi:
- Itu 2013, digunakan Chef 10, di mana pencarian lambat. Kami memulai pencarian, berkeliling semua mobil, dan butuh selamanya. Kami mencoba memecahkan masalah dengan konvensi penamaan, serta pemilihan dan pencarian fqdn. Ini mempersempit ruang lingkup pencarian, karena itu dipercepat.
Tetapi beberapa operasi perlu dilakukan di seluruh lingkungan. Dengan demikian, pencarian dijalankan sekali di awal, hasilnya disimpan dalam atribut, dan menggunakan Ruby kami menyaring hasilnya: kami mem-parsing potongan yang kami butuhkan dan melakukan apa yang diperlukan.
if !Chef::Config[:solo] search(:node, "fqdn:*metro-#{node[:env]}-mongodb*").each do |mongo| @mongodbs << mongo.fqdn end else @mongodbs = ["lvs-metro-#{node[:env]}-mongodb3001.qa.example.com"] end
Intinya: gunakan konvensi penamaan, jalankan pencarian sekali, gunakan Ruby untuk menyaring hasil yang diinginkan.
- Menggunakan "node.save" tidak aman, hati-hati dan hati-hati. Kami mengalami masalah ini ketika menggunakan cluster MySQL, dan menggunakan node.save di dalam resep pada node MySQL yang tidak sepenuhnya dikonfigurasi. Dan pada saat Scale-up, beberapa aplikasi memberikan 500 kesalahan. Ternyata kami menyimpan node pada waktu yang salah: ia pergi ke server Chef, di sana klien Chef di UI mengambil node baru yang tidak dikonfigurasi sebelum mode operasi.
- Kurangnya "bentangan" dapat membunuh server chef. Splay adalah parameter klien Chef yang memungkinkan Anda untuk mengatur rentang ketika klien pergi ke server untuk konfigurasi. Dengan beban yang besar, ketika Anda perlu menggunakan banyak node pada saat yang sama, ini tidak akan mematikan server.
Apa yang bisa kita gunakan sebagai pengganti koki?
- Provisi dinamis SaltStack sangat sempurna karena memiliki SaltCloud yang terintegrasi sempurna di mana saja. Wayang memiliki fungsi serupa, tetapi hanya tersedia di Wayang Perusahaan, untuk uang. Ansible sangat cocok jika perusahaan "tinggal" di Amazon, jika sesuatu yang lain - Anda dapat mengikatnya menjadi alternatif, tetapi tidak begitu nyaman.
- SDLC. Chef memiliki segalanya, dari Test Kitchen hingga memilih alat untuk pengujian integrasi. SaltStack memiliki semua alat Python yang tersedia, sekarang Wayang memiliki segalanya. Ansible memiliki Spec Peran, Anda dapat menggunakan Chef's Test Kitchen, tetapi itu bukan alat asli.
- Penggantian sumber daya. Semuanya baik-baik saja di Chef, di SaltStack Anda dapat menyelesaikan SaltCloud ke kondisi yang diinginkan, di alat Wayang hanya dalam versi Enterprise, dan Ansible bekerja dengan baik hanya dengan Amazon.
EPAM Private Cloud dengan Chef
Setahun setengah sebelum munculnya AWS OpsWorks, kami ingin membuat Amazon CloudFormation canggih dengan mengintegrasikan Chef sehingga sumber daya tidak hanya digunakan, tetapi juga dikonfigurasikan.
Tugas global kedua adalah membuat katalog layanan sehingga pelanggan dan pengguna dapat menggunakan CLI untuk menggunakan tumpukan LAMP yang benar-benar siap digunakan, misalnya.
Kami memilih Chef, tetapi proyek harus mendukung SCM yang berbeda. Kami mulai dengan Chef-Server bawaan, dan pengguna juga bisa menggunakan Chef-Server mereka sendiri, yang dihosting di suatu tempat bersama mereka. Artinya, kami tidak mendapatkan akses ke sumber daya pengguna dan laptop, tetapi tetap berhasil.
Setiap SCM dapat digunakan untuk mengimplementasikan CloudFormation + OpsWork, semua orang cocok. Untuk membuat katalog - semua orang kecuali SaltStack akan melakukan ini dengan baik. SaltStack memiliki nuansa: sangat sulit untuk menemukan spesialis yang mengenal SaltStack dengan baik dan dapat membuat layanan dan mengisi katalog.
Popularitas SCM dalam EPAM
Ini adalah statistik popularitas SCM dalam EPAM. SaltStack sangat jauh di belakang. Di tempat pertama Ansible, ini adalah yang paling sederhana dan dengan ambang masuk yang rendah. Ketika kami mencoba menemukan seseorang di pasar dengan pengetahuan tentang SCM, pasar terlihat hampir sama.
Bekerja dengan Ansible
Kiat yang bisa saya berikan saat bekerja dengan Ansible:
- Gunakan 'akselerasi', menyebarkan konfigurasi 2-6 kali lebih cepat dari SSH (untuk el6). Untuk yang lainnya, ada 'pipelining'. Ini dimatikan untuk kompatibilitas ke belakang, tetapi menyalakan kembali pipelining sangat mudah, saya sarankan melakukannya.
- Gunakan 'with_items'
- name: project apt dependencies installed apt: name: "{{ item }}" become: yes with_items: - build-essential - acl - git - curl - gnupg2 - libpcre3-dev - python-apt - python-pycurl - python-boto - imagemagick - libmysqlclient-dev
Dalam contoh ini, kami memasang paket, skema ini dapat digunakan untuk membuat pengguna dan operasi serupa.
- Dengan hati-hati gunakan 'local_action' dan 'delegated'. Yang pertama memungkinkan Anda untuk mendapatkan sesuatu yang mirip dengan SaltStack Runner, yang kedua mampu mendelegasikan tugas ke mesin tertentu.
- name: create postgresql database postgresql_db: name: "{{ database_name }}" login_host: "{{ database_host }}" login_user: "{{ database_master_user }}" login_password: "{{ database_master_password }}" encoding: "UTF-8" lc_collate: "en_US.UTF-8" lc_ctype: "en_US.UTF-8" template: "template0" state: present delegate_to: "{{ groups.pg_servers|random}}"
Ini adalah bagian dari pembuatan basis data. Tanpa baris terakhir, operasi akan dilakukan beberapa kali dan jatuh pada upaya kedua untuk membuat database yang sama.
- Optimalkan peran dan kinerja Anda dengan tag. Ini secara signifikan dapat mengurangi waktu tunggu.
Kesimpulan
Bagi saya, Ansible adalah favorit. SaltStack sangat baik, sangat fleksibel, tetapi membutuhkan pengetahuan Python, tanpa mereka SaltStack lebih baik tidak digunakan. Chef adalah peluru perak universal untuk tugas dan skala apa pun, tetapi membutuhkan lebih banyak pengetahuan daripada Ansible. Dan siapa yang menggunakan Wayang - Saya tidak tahu. Pada prinsipnya, ini sangat mirip dengan Chef, tetapi dengan nuansa tersendiri.
Menit periklanan. Jika Anda menyukai laporan ini dari konferensi DevOops - perhatikan bahwa pada 14 Oktober DevOops 2018 baru akan diadakan di St. Petersburg, akan ada banyak hal menarik dalam programnya. Situs ini sudah memiliki pembicara dan laporan pertama.