[ English | русский | español | Indonesia | English (United Kingdom) | Deutsch ]
Manifesto OpenStack-Ansible¶
Proyek ini akan menjadi proyek Batteries included. Yang artinya, deployer dapat memperkirakan bahwa penerapan dari cabang atau tag fitur apa pun yang disebutkan harus menyediakan cloud OpenStack yang dibuat untuk produksi yang akan tersedia pada penyelesaian penerapan yang berhasil.
Ruang lingkup proyek¶
Proyek ini akan menjadi proyek Batteries included. Yang artinya, deployer dapat memperkirakan bahwa penerapan dari cabang atau tag fitur apa pun yang disebutkan harus menyediakan cloud OpenStack yang dibuat untuk produksi yang akan tersedia pada penyelesaian penerapan yang berhasil.
Namun, proyek ini hanya berfokus pada penyebaran OpenStack dan persyaratannya.
Proyek ini melakukan not PXE boot hosts. Penyiapan host dan manajemen siklus hidup diserahkan kepada operator. Proyek ini juga mengharuskan jembatan diset dalam host untuk memungkinkan kontainer untuk melampirkan ke jembatan lokal untuk akses jaringan. Lihat juga Container networking.
Ansible Usage (penggunaan Ansible)¶
Ansible menyediakan platform otomasi untuk menyederhanakan penerapan sistem dan aplikasi. Ansible mengelola sistem dengan menggunakan Secure Shell (SSH) daripada protokol unik yang memerlukan daemon atau agen jarak jauh.
Ansible uses playbooks written in the YAML language for orchestration. For more information, see Ansible - Intro to Playbooks.
Ansible adalah alat orkestrasi sederhana namun kuat yang idealnya dilengkapi untuk menyebarkan awan OpenStack-powered. Sifat deklaratif Ansible memungkinkan deployer untuk mengubah seluruh penyebaran menjadi satu set instruksi yang agak sederhana.
Peran dalam Openstack-Ansible umbrella dibangun menggunakan praktik terbaik Ansible dan berisi variabel dengan nama human yang dapat dimengerti. Semua peran independen satu sama lain dan dapat diuji secara terpisah.
Semua peran dibangun sebagai peran yang kompatibel dengan Galaxy bahkan ketika peran yang diberikan tidak dimaksudkan untuk penggunaan mandiri. Sementara proyek akan menawarkan banyak peran built-in, deployer akan dapat menurunkan atau mengesampingkan peran dengan peran eksternal menggunakan kemampuan Ansible built-in. Hal ini memungkinkan fleksibilitas ekstrem untuk para penyusun.
Sumber berdasarkan penyebaran¶
Ketika proyek OpenStack-Ansible dibuat, diperlukan untuk menyediakan sistem yang dapat mengesampingkan sembarang upstream source code OpenStack.
Ini berarti bahwa layanan OpenStack dan dependensi python mereka dibangun dan diinstal dari source code seperti yang ditemukan dalam repositori Git OpenStack secara default, tetapi memungkinkan deployer untuk menunjuk ke repositori mereka sendiri.
Ini juga memungkinkan pengembang untuk menunjuk kode mereka sendiri untuk pekerjaan mereka.
Penyebaran berbasis sumber, untuk bagian OpenStack yang dibuat dengan Python, masuk akal ketika berhadapan dengan skala dan menginginkan konsistensi dalam jangka waktu yang lama. Seorang deployer harus memiliki kemampuan untuk menyebarkan rilis OpenStack yang sama pada setiap node sepanjang siklus hidup cloud, bahkan ketika beberapa komponen adalah akhir dari kehidupan. Dengan menyediakan repositori sumber, penyebaran dapat dibuat ulang walaupun bertahun-tahun setelah penerapan awal, dengan asumsi sistem operasi dan paket yang mendasarinya tetap sama.
Ini berarti bahwa tidak akan pernah ada waktu di mana paket khusus OpenStack, seperti yang disediakan oleh distro, digunakan untuk layanan OpenStack. Repositori pihak ketiga seperti CloudArchive dan atau RDO mungkin masih diperlukan dalam penyebaran tertentu tetapi hanya sebagai sarana untuk memenuhi dependensi aplikasi.
Pengaplikasian kontainer (containerized deployment)¶
Proyek ini memperkenalkan wadah sebagai sarana untuk memisahkan layanan dari satu sama lain.
Penggunaan kontainer memungkinkan untuk abstraksi tambahan dari seluruh tumpukan aplikasi (application stack) untuk dijalankan semua dalam mesin host fisik yang sama.
Aplikasi "containerized" biasanya dikelompokkan dalam satu kontainer yang masuk akal, atau didistribusikan dalam beberapa kontainer berdasarkan aplikasi dan atau kebutuhan arsitektur.
Arsitektur kontainer bawaan telah dibuat sedemikian rupa untuk memungkinkan skalabilitas dan penyebaran yang sangat tersedia.
Sifat sederhana dari kontainer mesin memungkinkan penyusun untuk memperlakukan kontainer sebagai mesin fisik. Konsep yang sama berlaku untuk kontainer mesin dan mesin fisik: Hal ini akan memungkinkan deployer untuk menggunakan kumpulan alat operasional yang ada untuk memecahkan masalah dalam penerapan dan kemampuan untuk mengembalikan aplikasi atau layanan dalam inventaris ke keadaan kerja yang diketahui tanpa harus mendepak ulang (re-kick) host fisik.
Tidak semua layanan dalam kontainer: beberapa tidak masuk akal untuk dijalankan dalam sebuah kontainer. Logika perlu diterapkan dalam hal bagaimana layanan di kontainer. Jika persyaratan mereka tidak dapat dipenuhi karena keterbatasan sistem, (kernel, kematangan aplikasi, dll ...), maka layanan tidak diatur untuk berjalan dalam sebuah kontainer.
Contoh layanan yang tidak memiliki kontainer (un-containerized services):
Nova compute (untuk akses langsung ke perangkat virtualisasi)
Swift storage (untuk akses langsung ke drive)
Kontainer bukan berarti mengamankan sistem. Kontainer itu tidak dipilih untuk setiap penjaga keamanan yang aman akhirnya. Kontainer mesin dipilih karena kepraktisan mereka sehubungan dengan penyediaan penyebaran OpenStack yang lebih seragam. Bahkan jika abstraksi yang disediakan oleh kontainer meningkatkan keamanan penerapan secara keseluruhan, manfaat potensial ini bukan tujuan dari kontainer layanan.
