Perkhidmatan Maklumat Data Satelit Alam Sekitar Kebangsaan (NESDIS) telah mengurangkan kos pengurusan konfigurasi untuk Red Hat Enterprise Linux (RHEL) sebanyak 35% dengan berhijrah daripada Perusahaan Boneka ke Menara Ansible. Dalam video "bagaimana kami melakukannya" ini, jurutera sistem Michael Rau menerangkan kes untuk penghijrahan ini, berkongsi petua berguna dan pengajaran yang dipelajari daripada berpindah dari satu SCM ke SCM yang lain.
Dalam video ini anda akan belajar:
- bagaimana untuk mewajarkan kepada pengurusan kemungkinan beralih daripada Perusahaan Boneka kepada Menara Ansible;
- apakah strategi yang perlu digunakan untuk membuat peralihan selancar mungkin;
- petua untuk transcoding PE manifes ke Ansible Playbook;
- Cadangan untuk pemasangan optimum Menara Ansible.
Hello semua, nama saya Michael Rau, saya seorang Jurutera Sistem Kanan di ActioNet, yang bekerja untuk perkhidmatan NESDIS Pentadbiran Lautan dan Atmosfera Kebangsaan (NOAA). Hari ini kita akan bercakap tentang pemangkasan tali - pengalaman saya sendiri berhijrah daripada Perusahaan Boneka ke Menara Ansible. Tema pembentangan ini adalah untuk "melihat parut saya" yang ditinggalkan selepas saya membuat peralihan ini pada awal tahun ini. Saya ingin berkongsi apa yang saya pelajari melalui proses ini. Jadi apabila anda mengambil sesuatu seperti ini, menggunakan pengalaman saya, anda boleh membuat peralihan tanpa sebarang kerja tambahan.
Anda melihat slaid yang serupa dengan ini pada permulaan setiap pembentangan di Ansible Fest. Slaid ini menggariskan sejarah automasi syarikat saya. Saya bukan orang baru dalam hal ini kerana saya telah menggunakan Puppet/Puppet Enterprise sejak 2007. Saya mula bekerja dengan Ansible pada 2016, dan seperti ramai pengguna lain produk ini, saya tertarik dengan kemungkinan "helah" menggunakan baris arahan dan skrip ringkas (buku permainan). Pada penghujung tahun 2017, saya menghubungi pihak pengurusan saya tentang sebab kukuh untuk berpindah ke Menara Ansible. Dalam satu minit saya akan memberitahu anda tentang sebab yang mendorong saya untuk mengambil langkah ini. Selepas menerima persetujuan pihak pengurusan, ia mengambil masa beberapa bulan lagi untuk menyiapkan rancangan itu, dan saya membuat peralihan pada Januari-Februari tahun ini. Jadi, kami meninggalkan Puppet sepenuhnya dan memihak kepada Ansible, dan ini adalah perkara yang hebat.
Perkara yang paling menarik perhatian saya tentang Ansible ialah keupayaan untuk menulis dan menggunakan peranan serta buku permainan. Peranan sangat bagus untuk mencipta tugas yang berbeza tetapi berkaitan dan meletakkan semua data yang berkaitan dengan tugas tersebut di satu tempat. Buku main ialah sintaks YAML, fail skrip yang menerangkan tindakan untuk satu atau lebih hos. Saya memberitahu pengguna tentang ciri ini, terutamanya pembangun perisian. Ansible Tower memberi anda keupayaan untuk berkata, "tidak, anda tidak mempunyai akses shell, tetapi saya memberi anda keupayaan untuk menjalankan semua proses Tower dan memulakan semula perkhidmatan apabila anda memerlukannya." Saya akan memberitahu anda tentang persekitaran kerja dan peralatan yang kami gunakan.
Ini ialah LAN persekutuan, 7 tapak fizikal yang disambungkan melalui MPLS awan, 140 pelayan RHEL, 99% daripadanya adalah maya (vSphere), perkakasan SuperMicro, storan rangkaian NexentaStore, satu set suis Cisco, Arista dan Cumulus serta pengurusan ancaman bersatu Fortinet UTM alatan pada setiap tapak.
Rangkaian persekutuan bermakna saya mesti menggunakan semua langkah keselamatan maklumat yang disediakan oleh undang-undang. Anda harus ingat bahawa Puppet Enterprise tidak menyokong kebanyakan perkakasan yang kami gunakan. Kami terpaksa menggunakan perkakasan bajet kerana agensi kerajaan menghadapi masalah untuk membiayai item perbelanjaan ini. Itulah sebabnya kami membeli perkakasan SuperMicro dan memasang peralatan kami daripada bahagian individu, yang penyelenggaraannya dijamin oleh kontrak kerajaan. Kami menggunakan Linux dan ini adalah salah satu sebab penting untuk bertukar kepada Ansible.
Sejarah kita dengan Puppet adalah seperti berikut.
Pada tahun 2007, kami mempunyai rangkaian kecil 20-25 nod, di mana kami menggunakan Puppet. Pada asasnya, nod ini hanyalah "kotak" RedHat. Pada tahun 2010, kami mula menggunakan antara muka web Puppet Dashboard untuk 45 nod. Apabila rangkaian terus berkembang, kami berpindah ke PE 2014 pada tahun 3.3, membuat peralihan lengkap dengan penulisan semula nyata untuk 75 nod. Ini terpaksa dilakukan kerana Puppet suka menukar peraturan permainan, dan dalam kes ini mereka menukar sepenuhnya bahasa. Setahun kemudian, apabila sokongan untuk versi 3 Puppet Enterprise tamat, kami terpaksa berhijrah ke PE 2015.2. Kami terpaksa menulis semula manifes sekali lagi untuk pelayan baharu dan membeli lesen dengan rizab 100 nod, walaupun pada masa itu kami hanya mempunyai 85 nod.
Hanya 2 tahun telah berlalu, dan kami sekali lagi terpaksa melakukan banyak kerja untuk berhijrah ke versi baharu PE 2016.4. Kami membeli lesen untuk 300 nod, hanya mempunyai 130. Kami sekali lagi terpaksa membuat perubahan besar pada manifes kerana versi baharu bahasa itu mempunyai sintaks yang berbeza daripada bahasa versi 2015. Akibatnya, SCM kami bertukar daripada kawalan versi SVN kepada Bitbucket (Git). Ini adalah "hubungan" kami dengan Puppet.
Jadi, saya terpaksa menerangkan kepada pihak pengurusan mengapa kami perlu berpindah ke SCM yang berbeza menggunakan hujah berikut. Yang pertama ialah harga perkhidmatan yang tinggi. Saya bercakap dengan lelaki di RedHat dan mereka berkata bahawa kos menjalankan rangkaian 300 nod dengan Menara Ansible adalah separuh daripada kos Perusahaan Boneka. Jika anda juga membeli Enjin Ansible, kosnya adalah lebih kurang sama, tetapi anda akan mendapat lebih banyak ciri daripada PE. Oleh kerana kami adalah syarikat milik kerajaan yang dibiayai daripada belanjawan persekutuan, ini adalah hujah yang cukup kuat.
Hujah kedua ialah serba boleh. Puppet hanya menyokong perkakasan yang mempunyai ejen Puppet. Ini bermakna ejen mesti dipasang pada semua suis, dan ia mestilah versi terkini. Dan jika sesetengah suis anda menyokong satu versi, dan sesetengahnya menyokong yang lain, anda perlu memasang versi baharu ejen PE pada mereka supaya semuanya boleh berfungsi dalam sistem SCM yang sama.
Sistem Menara Ansible berfungsi secara berbeza kerana ia tidak mempunyai sebarang ejen, tetapi ia mempunyai modul yang menyokong suis Cisco dan semua suis lain. SCM ini menyokong OS Qubes, Linux dan 4.NET UTM. Menara Ansible juga menyokong pengawal storan rangkaian NexentaStore berdasarkan kernel Illumos, sistem pengendalian berasaskan Unix sumber terbuka. Ini adalah sokongan yang sangat kecil, tetapi Menara Ansible melakukannya.
Hujah ketiga, yang sangat penting untuk saya dan untuk pentadbiran kami, adalah kemudahan penggunaan. Saya menghabiskan 10 tahun menguasai modul Boneka dan kod manifes, tetapi saya belajar Ansible dalam masa seminggu kerana SCM ini lebih mudah untuk digunakan. Jika anda menjalankan fail boleh laku, sudah tentu, melainkan anda melakukannya secara tidak perlu, maka pengendali yang bijak dan responsif akan bekerjasama dengan mereka. Buku permainan berasaskan YAML mudah dipelajari dan cepat digunakan. Mereka yang tidak pernah mendengar tentang YAML sebelum ini boleh membaca skrip dan memahami cara ia berfungsi dengan mudah.
Sejujurnya, Puppet menjadikan tugas anda sebagai pembangun lebih sukar kerana ia berdasarkan penggunaan Puppet Master. Ia adalah satu-satunya mesin yang dibenarkan untuk berkomunikasi dengan ejen Boneka. Jika anda telah membuat sebarang perubahan pada manifes dan ingin menguji kod anda, anda mesti menulis semula kod untuk Puppet Master, iaitu, mengkonfigurasi fail Puppet Master /etc/hosts untuk menyambungkan semua pelanggan dan memulakan perkhidmatan Puppet Server. Hanya selepas ini anda akan dapat menguji pengendalian peralatan rangkaian pada satu hos. Ini adalah prosedur yang agak menyakitkan.
Semuanya lebih mudah dalam Ansible. Apa yang anda perlu lakukan ialah membangunkan kod untuk mesin yang boleh berkomunikasi melalui SSH dengan hos yang sedang diuji. Ini lebih mudah untuk digunakan.
Kelebihan besar Menara Ansible seterusnya ialah keupayaan untuk memanfaatkan sistem sokongan sedia ada anda dan mengekalkan konfigurasi perkakasan sedia ada anda. SCM ini menggunakan semua maklumat yang tersedia tentang infrastruktur dan perkakasan anda, mesin maya, pelayan, dsb. tanpa sebarang langkah tambahan. Ia boleh bercakap dengan pelayan Satelit RH anda, jika anda mempunyai satu, dan memberikan anda integrasi yang anda tidak akan dapat dengan Puppet.
Satu lagi perkara penting ialah kawalan terperinci. Anda tahu bahawa Puppet ialah sistem modular, ia adalah aplikasi pelayan pelanggan, jadi anda mesti menentukan aspek sedia ada bagi semua mesin anda dalam satu manifes yang panjang. Dalam kes ini, keadaan setiap elemen individu sistem mesti diuji setiap setengah jam - ini adalah tempoh lalai. Beginilah cara Puppet berfungsi.
Menara menyelamatkan anda daripada itu. Anda boleh menjalankan pelbagai proses pada pelbagai peralatan tanpa sekatan; anda boleh melakukan kerja asas, menjalankan proses penting lain, menyediakan sistem keselamatan dan bekerja dengan pangkalan data. Anda boleh melakukan semua yang sukar dalam Perusahaan Boneka. Jadi, jika anda mengkonfigurasinya pada satu hos, perubahan itu akan mengambil masa untuk berkuat kuasa pada hos yang tinggal. Dalam Ansible, semua perubahan berkuat kuasa pada masa yang sama.
Akhir sekali, mari kita lihat modul keselamatan. Menara Ansible melaksanakannya dengan sangat menakjubkan, dengan ketepatan dan penjagaan yang tinggi. Anda boleh memberi pengguna akses kepada perkhidmatan tertentu atau kepada hos tertentu. Saya melakukan ini dengan pekerja saya yang biasa bekerja pada Windows, mengehadkan akses mereka kepada shell Linux. Saya memastikan bahawa mereka mempunyai akses kepada Menara supaya mereka hanya boleh melakukan kerja dan menjalankan hanya perkhidmatan yang berkaitan dengan mereka.
Mari lihat perkara yang perlu anda lakukan lebih awal untuk memudahkan peralihan anda ke Menara Ansible. Pertama sekali, anda perlu menyediakan peralatan anda. Jika beberapa elemen infrastruktur anda belum ada dalam pangkalan data, anda perlu menambahkannya di sana. Terdapat sistem yang tidak mengubah ciri-cirinya dan oleh itu tiada dalam pangkalan data Boneka, tetapi jika anda tidak menambahnya di sana sebelum berpindah ke Menara, anda akan kehilangan beberapa kelebihan. Ini mungkin pangkalan data awal "kotor", tetapi ia harus mengandungi maklumat tentang semua peralatan yang anda miliki. Oleh itu, anda harus menulis skrip perkakasan dinamik yang secara automatik akan menolak semua perubahan infrastruktur ke dalam pangkalan data, kemudian Ansible akan mengetahui hos mana yang harus ada pada sistem baharu. Anda tidak perlu memberitahu SCM ini hos yang anda tambahkan dan hos yang tidak lagi wujud, kerana ia akan mengetahui semua ini secara automatik. Lebih banyak data terdapat dalam pangkalan data, lebih berguna dan fleksibel Ansible. Ia berfungsi seolah-olah ia hanya membaca kod bar status perkakasan daripada pangkalan data.
Luangkan sedikit masa untuk membiasakan diri dengan baris arahan dalam Ansible. Jalankan beberapa arahan tersuai untuk menguji skrip perkakasan, tulis dan jalankan beberapa skrip buku main yang mudah tetapi berguna, gunakan templat Jinja2 jika sesuai. Cuba tulis peranan dan skrip untuk proses berbilang langkah yang kompleks menggunakan konfigurasi perkakasan yang biasa ditemui. Main dengan perkara ini, uji cara ia berfungsi. Dengan cara ini anda akan belajar cara menggunakan alatan penciptaan perpustakaan yang digunakan dalam Menara. Saya telah mengatakan bahawa saya mengambil masa kira-kira 3 bulan untuk bersedia untuk peralihan. Saya fikir berdasarkan pengalaman saya, anda akan dapat melakukan ini dengan lebih cepat. Jangan anggap masa ini disia-siakan, kerana kelak anda akan merasai segala kebaikan dari kerja yang dilakukan.
Seterusnya, anda perlu memutuskan apa yang anda harapkan daripada Menara Ansible, apa sebenarnya yang perlu dilakukan oleh sistem ini untuk anda.
Adakah anda perlu menggunakan sistem pada perkakasan kosong, pada mesin maya kosong? Atau adakah anda ingin mengekalkan keadaan operasi asal dan tetapan peralatan sedia ada? Ini adalah aspek yang sangat penting untuk syarikat awam, jadi anda perlu memastikan bahawa anda akan dapat berhijrah dan menggunakan Ansible pada konfigurasi sedia ada anda. Kenal pasti proses pentadbiran rutin yang anda mahu automasi. Ketahui sama ada anda perlu menggunakan aplikasi dan perkhidmatan tertentu pada sistem baharu. Buat senarai perkara yang anda mahu lakukan dan utamakannya.
Kemudian mula menulis kod skrip dan peranan yang akan membolehkan tugasan yang anda rancang untuk diselesaikan. Gabungkan mereka ke dalam Projek, koleksi logik buku permainan yang berkaitan. Setiap Projek akan tergolong dalam repositori Git yang berasingan atau repositori berbeza bergantung pada pengurus kod yang anda gunakan. Anda boleh mengurus skrip playbook dan direktori playbook dengan meletakkannya secara manual dalam Laluan Pangkalan Projek pada pelayan Tower, atau dengan meletakkan playbook dalam mana-mana sistem pengurusan kod sumber (SCM) yang disokong oleh Tower, termasuk Git, Subversion, Mercurial dan Red Hat Pandangan. Dalam satu Projek anda boleh meletakkan seberapa banyak skrip yang anda mahu. Sebagai contoh, saya mencipta satu Projek asas di mana saya meletakkan skrip untuk elemen teras RedHat, skrip untuk teras Linux dan skrip untuk garis dasar yang lain. Oleh itu, dalam satu projek terdapat pelbagai peranan dan senario yang diuruskan daripada satu repositori Git.
Menjalankan semua perkara ini melalui baris arahan adalah cara yang baik untuk menguji fungsinya. Ini akan menyediakan anda untuk pemasangan Menara.
Mari kita bercakap sedikit tentang transcoding manifes Boneka, kerana saya menghabiskan banyak masa untuk perkara ini sehingga saya mengetahui perkara yang sebenarnya perlu dilakukan.
Seperti yang saya katakan sebelum ini, Puppet menyimpan semua tetapan dan pilihan perkakasan dalam satu manifes yang panjang, dan manifes ini menyimpan semua perkara yang perlu dilakukan oleh SCM ini. Apabila membuat peralihan, anda tidak perlu menjejalkan semua tugas anda ke dalam satu senarai; sebaliknya, fikirkan tentang struktur sistem baharu: peranan, skrip, teg, kumpulan dan perkara yang perlu dilakukan di sana. Beberapa elemen rangkaian autonomi harus dikumpulkan ke dalam kumpulan yang mana skrip boleh dibuat. Elemen infrastruktur yang lebih kompleks yang melibatkan sejumlah besar sumber, termasuk kelas serba lengkap, boleh digabungkan menjadi peranan. Sebelum berhijrah, anda perlu membuat keputusan mengenai perkara ini. Jika anda mencipta peranan atau senario besar yang tidak sesuai pada satu skrin, anda harus menggunakan teg untuk dapat menangkap bahagian infrastruktur tertentu.
18:00
Beberapa iklan π
Terima kasih kerana tinggal bersama kami. Adakah anda suka artikel kami? Ingin melihat kandungan yang lebih menarik? Sokong kami dengan membuat pesanan atau mengesyorkan kepada rakan, , analog unik pelayan peringkat permulaan, yang kami cipta untuk anda: (tersedia dengan RAID1 dan RAID10, sehingga 24 teras dan sehingga 40GB DDR4).
Dell R730xd 2 kali lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya disini di Belanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - daripada $99! Baca tentang
Sumber: www.habr.com