देवस्टैक के बिना जीवन:ओएसए के साथ ओपनस्टैक विकास

यदि आप एक ओपनस्टैक योगदानकर्ता हैं, तो आप अपने अधिकांश कार्यों के लिए देवस्टैक पर भरोसा कर सकते हैं। DevStack है, और लंबे समय से है, वास्तविक मंच है कि योगदानकर्ता विकास, परीक्षण और समीक्षाओं के लिए उपयोग करते हैं। इस लेख में, मैं आपको एक ऐसे प्रोजेक्ट से परिचित कराना चाहता हूं, जिसमें मेरा योगदान है, जिसे ओपनस्टैक-एन्सिबल कहा जाता है। पिछले कुछ महीनों से, मैं ओपनस्टैक अपस्ट्रीम डेवलपमेंट के लिए DevStack के विकल्प के रूप में इस प्रोजेक्ट का उपयोग कर रहा हूं, और अनुभव बहुत सकारात्मक रहा है।

डेवस्टैक में क्या गलत है?

इससे पहले कि मैं ओपनस्टैक-एन्सिबल में तल्लीन हो, मैं उन कारणों पर संक्षेप में चर्चा करना चाहता हूं जिन्होंने मुझे देवस्टैक के विकल्प की तलाश करने के लिए प्रेरित किया। कुल मिलाकर, देवस्टैक एक अच्छी तरह से विकसित परियोजना है, लेकिन कुछ वास्तु संबंधी निर्णय हैं जो मुझे परेशान करते हैं।

सबसे पहले, देवस्टैक एक अखंड इंस्टॉलर के साथ आता है। स्थापना रद्द करने के लिए, आप stack.sh run चलाते हैं और वह आपके द्वारा कॉन्फ़िगर किए गए सभी मॉड्यूल स्थापित करता है। यदि आप बाद में मॉड्यूल जोड़ना या हटाना चाहते हैं, तो एकमात्र विकल्प unstack.sh चलाना है। सब कुछ अनइंस्टॉल करने के लिए, और फिर stack.sh को फिर से चलाएँ अद्यतन विन्यास के साथ। कई बार, जब मैंने एक मॉड्यूल में स्रोत कोड परिवर्तन किए, तो मैंने अनजाने में मॉड्यूल को अनियमित तरीके से संचालित करने का कारण बना दिया। अगर मैं उस स्थिति में हूं, तो सबसे सुरक्षित विकल्प इसे फिर से स्थापित करना है, और देवस्टैक के साथ ऐसा करने का एकमात्र तरीका सब कुछ फिर से स्थापित करना है।

देवस्टैक सभी मॉड्यूलों की एक विकास स्थापना करता है, जो एक ऐसा वातावरण बनाता है जो उत्पादन परिनियोजन से बहुत अलग है। मेरी राय में, एक उचित विकास वातावरण में वह मॉड्यूल होगा जिस पर मैं काम कर रहा हूं, विकास के लिए स्थापित किया गया है, बाकी सब कुछ उत्पादन के लिए स्थापित है। डेवस्टैक के साथ ऐसा करना संभव नहीं है।

एक और समस्या जो मुझे देवस्टैक के साथ होती थी, वह है एक सुसंगत स्थिति में निर्भरता बनाए रखने के लिए निरंतर लड़ाई। देवस्टैक में, निर्भरता सभी मॉड्यूल के बीच साझा की जाती है, इसलिए एक मॉड्यूल के लिए निर्भरता को सिंक करने की एक सरल क्रिया एक श्रृंखला प्रतिक्रिया का कारण बन सकती है जिसके लिए कई अन्य मॉड्यूल को अपडेट करने की आवश्यकता होती है। कुछ हद तक, प्रति-मॉड्यूल वर्चुअल वातावरण के उपयोग के साथ हाल ही में DevStack रिलीज़ में इसे कम किया जा सकता है, लेकिन, इसके साथ भी, OS स्तर के पैकेज साझा किए जाते हैं।

ओपनस्टैक-एन्सिबल (OSA) क्या है?

ओपनस्टैक-एन्सिबल प्रोजेक्ट एक रैकस्पेस ओपन सोर्स पहल है जो ओपनस्टैक को तैनात करने के लिए अंसिबल की शक्ति का उपयोग करता है। आपने os-ansible-deployment . नाम से इस प्रोजेक्ट के बारे में सुना होगा OpenStack बड़े तम्बू में जाने से पहले StackForge पर।

DevStack की तरह, openstack-ansible सभी OpenStack सेवाओं को सीधे उनके git रिपॉजिटरी से, बिना किसी वेंडर पैच या ऐड-ऑन के तैनात करता है। लेकिन बड़ा अंतर यह है कि ओपनस्टैक-एन्सिबल एलएक्ससी कंटेनरों में ओपनस्टैक सेवाओं को तैनात करता है, इसलिए एनोड पर होस्ट की गई सेवाओं के बीच पूर्ण ओएस स्तर और पायथन पैकेज अलगाव है।

देवस्टैक और ओपनस्टैक-एन्सिबल के बीच एक और अंतर यह है कि बाद वाला एक उत्पादन वितरण है। इसके साथ, आप एंटरप्राइज स्केल प्राइवेट क्लाउड्स को तैनात कर सकते हैं जो मुट्ठी भर नोड्स से लेकर सैकड़ों या हजारों नोड्स वाले बड़े क्लस्टर तक होते हैं।

निम्नलिखित आरेख एक ओपनस्टैक-उत्तरदायी निजी क्लाउड की संरचना को दर्शाता है:

इसे देखने के बाद, आप शायद यह सोचकर अपना सिर खुजला रहे हैं कि यह परियोजना अपस्ट्रीम विकास के लिए देवस्टैक की सादगी से कैसे मेल खा सकती है, यह देखते हुए कि यह स्पष्ट रूप से बहु-नोड निजी बादलों के लिए उन्मुख है। हिम्मत न हारिये! इसे अगले भाग में शामिल करें।

OSA ऑल-इन-वन

ओपनस्टैक-उत्तरदायी परियोजना योगदानकर्ता दिन-प्रतिदिन के काम के लिए और गेटिंग के लिए एकल-नोड परिनियोजन का उपयोग करते हैं, क्योंकि यह अधिक सुविधाजनक और संसाधन कुशल है। परिनियोजन की इस पद्धति के साथ क्लाउड सर्वर या वर्चुअल मशीन पर OSA को खड़ा करना संभव है, इसलिए इस सुविधा का लाभ लेने से यह प्रोजेक्ट DevStack से तुलनीय हो जाता है।

दुर्भाग्य से, ओएसए के एकल-नोड परिनियोजन के लिए मेजबान आवश्यकताएं देवस्टैक से अधिक हैं, मुख्य रूप से कंटेनर इन्फ्रास्ट्रक्चर द्वारा शुरू किए गए ओवरहेड के कारण। प्रयोग करने योग्य स्थापना के लिए, होस्ट के पास 16GB RAM और 80GB डिस्क स्थान होना चाहिए। इस समय, समर्थित एकमात्र होस्ट OS Ubuntu14.04 है।

देवस्टैक पर ओएसए का एक अच्छा लाभ यह है कि, कंटेनरीकृत वास्तुकला के लिए धन्यवाद, यह एकल-नोड इंस्टॉल पर भी अनावश्यक सेवाओं को तैनात कर सकता है। एक डिफ़ॉल्ट सिंगल-नोड परिनियोजन पर, गैलेरा, खरगोश एमक्यू, और कीस्टोन को अतिरेक के साथ तैनात किया जाता है, और लोड संतुलन के लिए होस्ट में HAProxy स्थापित किया जाता है।

क्या आप अपने हाथ गंदे करने के लिए तैयार हैं? यदि आपके पास एक ताजा Ubuntu14.04 सर्वर तक पहुंच है जो ऊपर बताए गए विनिर्देशों को पूरा करता है, तो आप निम्न कमांड के साथ OSArepository को क्लोन कर सकते हैं:

# apt-get -y install git
# git clone https://github.com/openstack/openstack-ansible /opt/openstack-ansible

आपको इस निर्देशिका में प्रोजेक्ट को क्लोन करने की आवश्यकता नहीं है। इसके बजाय, आप इसे अपनी पसंद के किसी भी स्थान पर क्लोन कर सकते हैं।

अगला, एकल-नोड कॉन्फ़िगरेशन फ़ाइल जनरेट करें। सौभाग्य से, प्रोजेक्ट एक स्क्रिप्ट के साथ आता है जो आपके लिए ऐसा करती है:

# cd /opt/openstack-ansible
# scripts/bootstrap-aio.sh

उपरोक्त आदेश के चलने के बाद, निर्देशिका /etc/openstack_deploy YAML प्रारूप में कई कॉन्फ़िगरेशन फ़ाइलों के साथ पॉप्युलेट किया जाएगा। विशेष रुचि फ़ाइल user_secrets.yml है। , जिसमें आपके इंस्टॉलेशन में उपयोग किए जाने वाले सभी पासवर्ड शामिल हैं। ये पासवर्ड बेतरतीब ढंग से बनाए जाते हैं, इसलिए इन्हें याद रखना मुश्किल होता है। मैं आमतौर पर व्यवस्थापक पासवर्ड संपादित करता हूं, क्योंकि मैं इसका बहुत उपयोग करता हूं। मूल रूप से मैं इसे बदलता हूं:

keystone_auth_admin_password: cY3QHwjMLRdSuZMlKI3OvujScCNeIMdH

इसके लिए:

keystone_auth_admin_password: secrete

शेष पासवर्ड उतने उपयोगी नहीं हैं, इसलिए मैं उन्हें अकेला छोड़ देता हूं। हालांकि, आप किसी भी पासवर्ड को बदल सकते हैं जो आपको लगता है कि आपको किसी ऐसी चीज का उपयोग करने की आवश्यकता हो सकती है जिसे याद रखना आसान हो।

इसके बाद, एक और स्क्रिप्ट चलाएँ जो होस्ट में Ansible को स्थापित करती है, साथ ही कुछ Ansible एक्स्ट्रा और रैपर स्क्रिप्ट जो इसके उपयोग को आसान बनाती हैं:

# scripts/bootstrap-ansible.sh

इस बिंदु पर, होस्ट OSA इंस्टाल प्राप्त करने के लिए तैयार है, इन्स्टॉल करने वाली Ansible playbooks को चलाएँ:

# scripts/run-playbooks.sh

रैकस्पेस पब्लिक क्लाउड सर्वर पर, सभी प्लेबुक के माध्यम से एक पूर्ण रन पूरा होने में लगभग 45 मिनट लगते हैं। Ansible के साथ काम करने का एक अच्छा पहलू यह है कि सभी कार्य बेकार हैं, जिसका अर्थ है कि प्लेबुक को बिना किसी समस्या के कई बार निष्पादित किया जा सकता है। यदि कोई कार्य पहले ही किया जा चुका है, तो उसे दूसरी बार चलाने से कुछ नहीं होता है। यह वास्तव में बहुत उपयोगी है, क्योंकि यह एक लाइव सिस्टम को केवल उपयुक्त कॉन्फ़िगरेशन फ़ाइलों को बदलकर और प्लेबुक को फिर से चलाकर, पहले सब कुछ फाड़ने की आवश्यकता के बिना फिर से कॉन्फ़िगर करना संभव बनाता है।

ओपनस्टैक-उत्तरदायी का एक त्वरित दौरा

इस खंड में, मैं आपको OSA सिंगल-नोडस्ट्रक्चर का एक सिंहावलोकन देना चाहता हूं, ताकि आप में से जो बहादुर थे, वे जान सकें कि सब कुछ कहां है।

सबसे पहले, क्षितिज डैशबोर्ड तैनात किया गया है और मेजबान के सार्वजनिक आईपी पते पर पहुंच योग्य होना चाहिए। आप व्यवस्थापक . का उपयोग कर सकते हैं खाता, उस पासवर्ड के साथ जिसे आपने /etc/openstack_deploy/user_secrets.yml में दर्ज किया है file.यदि आपने इस फ़ाइल को संपादित नहीं किया है, तो आपको इस फ़ाइल को खोलना होगा और keystone_auth_admin_password का पता लगाना होगा। यह पता लगाने के लिए सेटिंग कि किस पासवर्ड का उपयोग किया गया था।

जैसा कि मैंने ऊपर उल्लेख किया है, सर्वर सभी LXC कंटेनरों में स्थापित हैं। निम्नलिखित कमांड आपको कंटेनरों की सूची दिखाता है:

root@miguel-lxc-server:~# lxc-ls -f
NAME                                          STATE    IPV4                                        IPV6  AUTOSTART
--------------------------------------------------------------------------------------------------------------------------------
aio1_ceilometer_api_container-c8e825de        RUNNING  10.0.3.203, 172.29.237.195                  -     YES (onboot, openstack)
aio1_ceilometer_collector_container-2da3371f  RUNNING  10.0.3.10, 172.29.238.178                   -     YES (onboot, openstack)
aio1_cinder_api_container-88e59c04            RUNNING  10.0.3.125, 172.29.238.106, 172.29.247.183  -     YES (onboot, openstack)
aio1_cinder_scheduler_container-69d2bec4      RUNNING  10.0.3.4, 172.29.239.79                     -     YES (onboot, openstack)
aio1_galera_container-2f36d624                RUNNING  10.0.3.95, 172.29.237.18                    -     YES (onboot, openstack)
aio1_galera_container-3b8e14d7                RUNNING  10.0.3.18, 172.29.237.166                   -     YES (onboot, openstack)
aio1_galera_container-618973ae                RUNNING  10.0.3.82, 172.29.238.189                   -     YES (onboot, openstack)
aio1_glance_container-4b41140f                RUNNING  10.0.3.21, 172.29.237.77, 172.29.246.233    -     YES (onboot, openstack)
aio1_heat_apis_container-40ec9f3e             RUNNING  10.0.3.193, 172.29.239.6                    -     YES (onboot, openstack)
aio1_heat_engine_container-36e270c9           RUNNING  10.0.3.171, 172.29.239.171                  -     YES (onboot, openstack)
aio1_horizon_container-3497588e               RUNNING  10.0.3.33, 172.29.239.114                   -     YES (onboot, openstack)
aio1_horizon_container-6cac5348               RUNNING  10.0.3.30, 172.29.238.168                   -     YES (onboot, openstack)
aio1_keystone_container-821e7cf8              RUNNING  10.0.3.38, 172.29.238.105                   -     YES (onboot, openstack)
aio1_keystone_container-d63c657e              RUNNING  10.0.3.69, 172.29.239.208                   -     YES (onboot, openstack)
aio1_memcached_container-8baf34d5             RUNNING  10.0.3.158, 172.29.237.135                  -     YES (onboot, openstack)
aio1_neutron_agents_container-21b819b7        RUNNING  10.0.3.233, 172.29.239.130, 172.29.240.182  -     YES (onboot, openstack)
aio1_neutron_server_container-b4279bbe        RUNNING  10.0.3.52, 172.29.239.216                   -     YES (onboot, openstack)
aio1_nova_api_metadata_container-79faf41a     RUNNING  10.0.3.60, 172.29.239.110                   -     YES (onboot, openstack)
aio1_nova_api_os_compute_container-fed67563   RUNNING  10.0.3.231, 172.29.239.17                   -     YES (onboot, openstack)
aio1_nova_cert_container-72f66c56             RUNNING  10.0.3.155, 172.29.237.152                  -     YES (onboot, openstack)
aio1_nova_conductor_container-7d0f1b0f        RUNNING  10.0.3.164, 172.29.239.144                  -     YES (onboot, openstack)
aio1_nova_console_container-62af2918          RUNNING  10.0.3.106, 172.29.238.236                  -     YES (onboot, openstack)
aio1_nova_scheduler_container-e6b79b3b        RUNNING  10.0.3.250, 172.29.236.153                  -     YES (onboot, openstack)
aio1_rabbit_mq_container-0e0fe308             RUNNING  10.0.3.86, 172.29.239.93                    -     YES (onboot, openstack)
aio1_rabbit_mq_container-a4a04124             RUNNING  10.0.3.253, 172.29.237.188                  -     YES (onboot, openstack)
aio1_rabbit_mq_container-b9c6dce6             RUNNING  10.0.3.22, 172.29.238.111                   -     YES (onboot, openstack)
aio1_repo_container-6a8377fc                  RUNNING  10.0.3.102, 172.29.237.47                   -     YES (onboot, openstack)
aio1_repo_container-b92c563a                  RUNNING  10.0.3.223, 172.29.239.251                  -     YES (onboot, openstack)
aio1_rsyslog_container-a6e4f7d4               RUNNING  10.0.3.170, 172.29.237.249                  -     YES (onboot, openstack)
aio1_swift_proxy_container-9f0130d3           RUNNING  10.0.3.20, 172.29.237.227, 172.29.247.52    -     YES (onboot, openstack)
aio1_utility_container-d83fab91               RUNNING  10.0.3.39, 172.29.237.161                   -     YES (onboot, openstack)

इस सूची में जाकर, आप देख सकते हैं कि किन सेवाओं को तैनात किया गया था। आप lxc-attach . का उपयोग करके कंटेनर के अंदर जा सकते हैं आज्ञा। एक विशेष रूप से दिलचस्प कंटेनर वह है जिसमें उपयोगिता . है सूची के नीचे नाम। इस कंटेनर में प्रवेश करने के लिए यह वह आदेश है जिसका आपको उपयोग करना चाहिए:

# lxc-attach -n aio1_utility_container-d83fab91

उपयोगिता कंटेनर उपयोगी है क्योंकि इसमें सभी ओपनस्टैक कमांड लाइन क्लाइंट स्थापित हैं, साथ ही जाने के लिए तैयार openrc व्यवस्थापक खाते के लिए फ़ाइल। निम्नलिखित उदाहरण सत्र में, मैं openstack . का उपयोग करता हूं उपयोगिता toquery मेरे परिनियोजन में उपयोगकर्ताओं की सूची:

root@miguel-lxc-server:~# lxc-attach -n aio1_utility_container-d83fab91
root@aio1_utility_container-d83fab91:~# source openrc
root@aio1_utility_container-d83fab91:~# openstack user list
+----------------------------------+--------------------+
| ID                               | Name               |
+----------------------------------+--------------------+
| 2257ddc66d4c41ba8500114944cbb852 | dispersion         |
| 22f1824610b34eb2a6cfaba09b8feb93 | ceilometer         |
| 271f9bd069b2440ebb27c8f460bb3bcf | neutron            |
| 2ecb372f6563410ab8138625c45a72e3 | heat               |
| 35a7c9373ff640c4ba768963c1f53f02 | keystone           |
| 37041c2377c44f5cb84ffafee5bfed6f | cinder             |
| 4b7f43c7c2cc443889cd6b5d90a30e49 | glance             |
| 6ee6a4abb7e64b3d801f2653efb9c9ec | swift              |
| 9b375e06cb0a481a8ed2f94e28e1cb39 | nova               |
| b2b90c7eed704c63bbc8ea0eb23f43c4 | admin              |
| bd3eed1e0cf54b93a0d7c6a7849be778 | stack_domain_admin |
+----------------------------------+--------------------+

कंटेनर से बाहर निकलने और होस्ट पर लौटने के लिए, exit . टाइप करें या हिट करेंCtrl-D.

यहाँ Ansible की एक और अच्छी विशेषता है:यह आपको किसी सेवा को फिर से स्थापित करने की अनुमति देता है, जैसे कि गलती से विकास के दौरान दूषित हो गई। ऐसा करने के लिए, बस प्रभावित कंटेनर को नष्ट कर दें:

# lxc-stop -n <container-name>
# lxc-destroy -n <container-name>

बीमार कंटेनर के नष्ट हो जाने के बाद, प्लेबुक को एक बार फिर चलाने से प्रतिस्थापन के रूप में एक नई किताब बन जाएगी, जो कि स्क्रैच से सब कुछ इंस्टॉल करने में लगने वाले समय के एक अंश में होगी।

डेवलपमेंट वर्कफ़्लो

आप निश्चित रूप से जानना चाहते हैं कि व्यावहारिक रूप से मैं देवस्टैक के प्रतिस्थापन के रूप में ओएसए ऑल-इन-वन परिनियोजन का उपयोग कैसे करता हूं। इस प्रक्रिया में कुछ सरल चरण शामिल हैं:

1. OSA-AIO तैनात करें

   जाहिर है, सब कुछ सिंगल-नोड ओपनस्टैक-एन्सिबलक्लाउड को तैनात करने से शुरू होता है। मैं आमतौर पर अपने होस्ट के रूप में एक रैकस्पेस पब्लिक क्लाउड सर्वर का उपयोग करता हूं, लेकिन आप ऊपर सूचीबद्ध विनिर्देशों के साथ किसी भी उबंटू 14.04 होस्ट का उपयोग कर सकते हैं।

2. लक्ष्य कंटेनर में संलग्न करें

   मैं फिर उस कंटेनर के अंदर जाता हूं जो उस सेवा को चलाता है जिस पर मैं काम करना चाहता हूं, lxc-attach का उपयोग करके आदेश मैंने ऊपर दिखाया। अगर मैं अतिरेक के साथ तैनात की गई सेवा पर काम करने जा रहा हूं, तो मैं पहले केवल एक कंटेनर को सक्रिय छोड़ने के लिए HAProxyconfiguration को संपादित करता हूं। यदि चयनित कंटेनर में कुछ गलत हो जाता है, तो शेष कंटेनरों को बैकअप के रूप में उपयोग किया जा सकता है।

3. लक्ष्य सेवा बंद करो

   कंटेनर उस सेवा का उत्पादन संस्करण चला रहा है जिस पर मैं काम करना चाहता हूं। क्योंकि यह सेवा मेरे किसी काम की नहीं है, मैं मानक service <name> stop का उपयोग करके इसे रोकता हूं। आज्ञा। उदाहरण के लिए, अगर मैं हीट-इंजन कंटेनर में हूं, तो मैं service heat-engine stop चलाऊंगा ।

4. क्लोन विकास संस्करण

   अब मेरे पास एक कंटेनर है जो लक्ष्य सेवा को चलाने के लिए तैयार है, इसलिए मैं उस वास्तविक कोड को क्लोन कर सकता हूं जिसके साथ मैं काम करूंगा। इसके लिए, अगर मैं समीक्षा कर रहा हूं, तो मैं आधिकारिक गिट भंडार, कस्टम परिवर्तनों के साथ मेरा कांटा, या शायद गेरिट से पैच का उपयोग कर सकता हूं।

5. निर्भरता अपडेट करें

   विकास संस्करण को निर्भरता के एक अलग सेट की आवश्यकता हो सकती है, जो कि Ansible playbooks द्वारा स्थापित किया गया था, इसलिए, सुरक्षा के लिए, Irun pip install -r requirements.txt कंटेनर में। चूंकि OSA अपना निजी पायथन पैकेज रिपॉजिटरी बनाता है, इसलिए हो सकता है कि इसमें पैकेज का एक आवश्यक संस्करण उपलब्ध न हो। जब ऐसा होता है, तो मैं no-index = False . सेट करता हूं कंटेनर के /root/.pip/pip.conf . में pypi तक पहुंच सक्षम करने के लिए फ़ाइल करें, और फिर पुन:प्रयास करें।

6. डेटाबेस सिंक करें

   ओएसए के साथ स्थापित मूल संस्करण और मेरे विकास संस्करण के बीच एक और संभावित अंतर डेटाबेस माइग्रेशन में है, इसलिए मैं हमेशा डेटाबेस को सिंक करता हूं, बस मामले में। ऐसा करने का आदेश सेवाओं के बीच थोड़ा भिन्न होता है, लेकिन इसके लिए आमतौर पर db_sync के साथ प्रबंधन स्क्रिप्ट को लागू करने की आवश्यकता होती है विकल्प। उदाहरण के लिए, कीस्टोन के साथ काम करते समय, डेटाबेस को सिंक करने का आदेश keystone-manage db_sync है।

7. यदि आवश्यक हो, तो मूल कॉन्फ़िगरेशन फ़ाइलों में परिवर्तन करें

   प्लेबुक सभी सेवाओं के लिए कॉन्फ़िगरेशन फ़ाइलें बनाती हैं, इसलिए, अधिकांश मामलों में, कॉन्फ़िगरेशन जो /etc में छोड़ा गया था इंस्टॉलर द्वारा निर्देशिका का उपयोग विकास के लिए परिवर्तनों के बिना किया जा सकता है। अगर मुझे अपने काम से संबंधित कोई भी कस्टम परिवर्तन करने की आवश्यकता है, तो मैं उन्हें एक टेक्स्ट एडिटर के साथ मैन्युअल रूप से बना देता हूं।

8. मैन्युअल रूप से चलाएँ, या एक सेवा के रूप में स्थापित और चलाएँ

   अंत में, विकास संस्करण शुरू किया जा सकता है। इसे आसानी से करने के लिए, बस सीधे पायथन एप्लिकेशन चलाएँ। उदाहरण के लिए, यदि मैं हीट-इंजन सेवा पर काम कर रहा हूँ, तो मैं bin/heat-engine चला सकता हूँ टर्मिनल से बाहर जाने वाले लॉग के साथ, अग्रभूमि में सेवा शुरू करने के लिए परियोजना की मूल निर्देशिका से। सेवा को रोकने के लिए, मैं Ctrl-C दबा सकता हूं, ठीक वैसे ही जैसे यह DevStack में किया गया है।

   टर्मिनल के अनुकूल डिबगर्स, जैसे कि पीडीबी (कमांड लाइन) या पुडब (इंटरैक्टिव), कंटेनरों के अंदर स्थापित किए जा सकते हैं और बढ़िया काम कर सकते हैं। यदि आप PyCharm जैसे अधिक जटिल डिबगर्स का उपयोग करना पसंद करते हैं, तो होस्ट से कंटेनर में ssh पर रिमोट डिबगिंग भी संभव है।

   अधिकांश सेवाओं के लिए, उन्हें मैन्युअल रूप से चलाना DevStack की तरह आराम से काम करने के लिए पर्याप्त है। एकमात्र अपवाद उन सेवाओं के लिए है जो सीधे पाइथोनस्क्रिप्ट नहीं चलाती हैं, जैसे कीस्टोन, जो सामान्य रूप से अपाचे के अंतर्गत चलता है। हालांकि अपाचे का उपयोग उत्पादन में किया जाता है, विकास के लिए सीधे पायथन एप्लिकेशन को चलाना पूरी तरह से सुरक्षित है, जो संभवतः एक इवेंटलेट आधारित वेब सर्वर चलाएगा। यदि किसी कारण से अपाचे का उपयोग करना वांछित है, तो विकल्प python setup.py install चलाकर विकास संस्करण को स्थापित करना है। और फिर पहले से स्थापित अपाचे सेवा को service apache2 restartके साथ पुनरारंभ करें . एप्लिकेशन को इसकी स्रोत निर्देशिका से python setup.py develop के साथ इंस्टॉल करके चलाना भी संभव है। और फिर अपाचे साइट कॉन्फ़िगरेशन फ़ाइल में होम निर्देशिका जोड़ना।

OSA-AIO:The Pros

देवस्टैक के स्थान पर ओएसए के साथ काम करना ज्यादातर सुखद अनुभव रहा है। अब निर्भरता संघर्ष नहीं होना बहुत अच्छा है, क्योंकि ओएसए के साथ, अगर इनीड किसी एक सेवा को फिर से आधार देना चाहता है और इसके लिए नई निर्भरता की आवश्यकता होती है, तो अन्य सेवाएं अपने स्वयं के कंटेनरों में अप्रभावित रहती हैं।

मैंने यह भी पाया है कि मुझे शायद ही कभी खरोंच से पूरी तैनाती को फिर से बनाने की आवश्यकता होती है। मैं आमतौर पर ऐसा तब करता हूं जब मैं पूरे सिस्टम को ओपनस्टैक की एक नई रिलीज में अपग्रेड करना चाहता हूं, लेकिन, दिन-प्रतिदिन के काम के लिए, मुझे स्थानीय अपडेट या मरम्मत करना आसान लगता है। मौजूदा स्थापना के लिए। मैं एक कंटेनर को नष्ट करने में सक्षम होना पसंद करता हूं और फिर बाकी सेवाओं को छुए बिना इसे मेरे लिए पुन:उत्पन्न करता हूं।

अंत में, मुझे वास्तव में यह पसंद है कि ओएसए मुझे सिस्टम के किस हिस्से को विकास पैकेज के रूप में स्थापित करने की अनुमति देता है, जबकि बाकी ओपनस्टैक क्लाउड को उत्पादन उपयोग के लिए स्थापित और कॉन्फ़िगर किया गया है।

OSA-AIO:The Cons

लेकिन निश्चित रूप से, जैसा कि हर चीज के मामले में होता है, OSA के साथ काम करने के कुछ पहलू हैं जो महान नहीं हैं, इसलिए मैं आपको कहानी का वह पक्ष भी देना चाहता हूं।

OSA एक युवा परियोजना है, और इसलिए, इसे समुदाय का व्यापक समर्थन नहीं है जो कि DevStack को प्राप्त है। यह विशेष रूप से महत्वपूर्ण है यदि आप उन मॉड्यूल पर काम करते हैं जो ओपनस्टैक के मूल में नहीं हैं। जिस समय मैं इसे लिख रहा हूं, ओएसए कीस्टोन, नोवा, न्यूट्रॉन, ग्लांस, सिंडर, स्विफ्ट, हीट, सीलोमीटर और होराइजन की तैनाती का समर्थन करता है। यदि आप ऐसे मॉड्यूल पर काम करना चाहते हैं जो इस सूची में शामिल नहीं है, तो ओएसए शायद आपके लिए उतना उपयोगी नहीं है। लेकिन दूसरी तरफ, यदि आप एक ऐसे मॉड्यूल के लिए एक उत्तरदायी प्लेबुक बनाना चाहते हैं जो वर्तमान में समर्थित नहीं है, तो आपको खुले हाथों से प्राप्त किया जाएगा।

सामान्य तौर पर, एक अपवाद के साथ, सभी मॉड्यूल के लिए Ansiblevariables के रूप में उजागर किए गए कॉन्फ़िगरेशन विकल्पों की एक उचित संख्या है। जब न्यूट्रॉन की बात आती है, तो विन्यास उतना लचीला नहीं होता है। कंटेनरों और वीएम के बीच नेटवर्क सुरंगों को हमेशा लिनक्स ब्रिज का उपयोग करने के लिए कॉन्फ़िगर किया गया है। उदाहरण के लिए, यदि आपको ओपन वीस्विच के साथ काम करने की आवश्यकता है, तो आपको प्लेबुक चलाने के बाद कॉन्फ़िगरेशन को मैन्युअल रूप से संशोधित करना होगा, जो मजेदार नहीं है। साथ ही, इस समय कोई भी न्यूट्रॉन प्लग इन समर्थित नहीं है।

निष्कर्ष

मुझे आशा है कि आप ओपनस्टैक के साथ मेरे वर्कफ़्लो को सीखने और उपयोग करने के लिए दिलचस्प पाएंगे। हीट अपस्ट्रीम सुविधाओं और बग फिक्स पर काम करते समय इसने मेरा समय बचाया है। मैंने कीस्टोनफेडरेशन को डीबग करने और उसका निवारण करने के लिए भी OSA पर बहुत अधिक भरोसा किया है।

यदि आप ओएसए का उपयोग करने में रुचि रखते हैं, तो मैं आपको थोड़ी सी खोज करने के लिए भी प्रोत्साहित करता हूं, क्योंकि इससे आपको अधिक लेख और ब्लॉग पोस्ट (जैसे कि यह एक या यह अन्य) पर ले जाया जाएगा, जिसमें अन्य ओपनस्टैक योगदानकर्ता बताते हैं कि उन्होंने ओएसए को अपने में कैसे शामिल किया स्वयं के कार्यप्रवाह.