home

หน้าแรก
 Computer >> คอมพิวเตอร์ >  >> การเขียนโปรแกรม >> ฐานข้อมูล

ชีวิตที่ปราศจาก DevStack:การพัฒนา OpenStack ด้วย OSA

หากคุณเป็นผู้สนับสนุน OpenStack คุณน่าจะพึ่งพา DevStack สำหรับงานส่วนใหญ่ของคุณ DevStack เป็นแพลตฟอร์มโดยพฤตินัยที่ผู้ร่วมให้ข้อมูลใช้ในการพัฒนา ทดสอบ และทบทวนมาเป็นเวลานาน ในบทความนี้ ฉันอยากจะแนะนำคุณเกี่ยวกับโครงการที่ฉันเป็นผู้มีส่วนร่วม เรียกว่าopenstack-ansible ในช่วงไม่กี่เดือนที่ผ่านมา ฉันได้ใช้โปรเจ็กต์นี้เป็นทางเลือกแทนการพัฒนาต้นน้ำของ DevStackfor OpenStack และประสบการณ์ก็เป็นไปในเชิงบวกอย่างมาก

เกิดอะไรขึ้นกับ DevStack

ก่อนที่ฉันจะเจาะลึกลงไปใน openstack-ansible ฉันต้องการพูดคุยสั้นๆ ถึงเหตุผลที่กระตุ้นให้ฉันมองหาทางเลือกอื่นแทน DevStack โดยรวมแล้ว DevStack เป็นโปรเจ็กต์ที่กลมกล่อม แต่มีการตัดสินใจทางสถาปัตยกรรมสองสามอย่างที่ทำให้ฉันรำคาญ

ก่อนอื่น DevStack มาพร้อมกับตัวติดตั้งแบบเสาหิน ในการดำเนินการติดตั้ง คุณเรียกใช้ stack.sh และนั่นจะติดตั้งโมดูลทั้งหมดที่คุณกำหนดค่าไว้ หากคุณต้องการเพิ่มหรือลบโมดูลในภายหลัง ทางเลือกเดียวคือเรียกใช้unstack.sh เพื่อถอนการติดตั้งทุกอย่าง แล้วรัน stack.sh . อีกครั้ง ด้วยการกำหนดค่าที่อัปเดต สองสามครั้งเมื่อฉันทำการเปลี่ยนแปลงซอร์สโค้ดในโมดูล ฉันทำให้โมดูลทำงานในลักษณะที่ไม่ปกติโดยไม่ได้ตั้งใจ ถ้าฉันอยู่ในสถานการณ์นั้น ตัวเลือกที่ปลอดภัยที่สุดคือการติดตั้งใหม่ และวิธีเดียวที่จะทำเช่นนั้นกับ DevStack คือการติดตั้งทุกอย่างใหม่ทั้งหมด

DevStack ดำเนินการพัฒนาการติดตั้งโมดูลทั้งหมด ซึ่งสร้างสภาพแวดล้อมที่แตกต่างจากการใช้งานจริงมาก ในความเห็นของฉัน สภาพแวดล้อมการพัฒนาที่เหมาะสมจะมีโมดูลที่ฉันกำลังดำเนินการติดตั้งเพื่อการพัฒนา โดยมีการติดตั้งอย่างอื่นสำหรับการผลิต ไม่สามารถดำเนินการกับ DevStack ได้

ปัญหาอีกประการหนึ่งที่ฉันเคยมีกับ DevStack คือการต่อสู้อย่างต่อเนื่องเพื่อรักษาการพึ่งพาในสถานะที่สอดคล้องกัน ใน DevStack การขึ้นต่อกันจะถูกแชร์ระหว่างโมดูลทั้งหมด ดังนั้นการดำเนินการง่ายๆ ของการซิงค์การขึ้นต่อกันสำหรับโมดูลหนึ่งอาจทำให้เกิดปฏิกิริยาลูกโซ่ที่ต้องอัปเดตโมดูลอื่นๆ หลายโมดูล ในระดับหนึ่ง สิ่งนี้สามารถบรรเทาได้ใน DevStack รีลีสล่าสุดด้วยการใช้สภาพแวดล้อมเสมือนแบบทีละโมดูล แต่ถึงแม้จะเป็นเช่นนั้น แพ็คเกจระดับ OS จะยังคงแชร์อยู่

openstack-ansible (OSA) คืออะไร

โครงการ openstack-ansible เป็นโครงการโอเพ่นซอร์สของ Rackspace ที่ใช้พลังของ Ansible ในการปรับใช้ OpenStack คุณอาจเคยได้ยินชื่อโครงการนี้ว่า os-ansible-deployment บน StackForge ก่อนที่มันจะย้ายไปที่เต็นท์ขนาดใหญ่ของ OpenStack

เช่นเดียวกับ DevStack openstack-ansible ปรับใช้บริการ OpenStack ทั้งหมดโดยตรงจากที่เก็บ git โดยไม่ต้องมีแพตช์หรือส่วนเสริมของผู้ขาย แต่ความแตกต่างที่สำคัญคือ openstack-ansible ปรับใช้บริการ OpenStack ใน LXCcontainers ดังนั้นจึงมีการแยกระดับ OS และแพ็คเกจ Python ที่สมบูรณ์ระหว่างบริการที่โฮสต์บนแอโนด

ความแตกต่างอีกประการระหว่าง DevStack และ openstack-ansible คือส่วนหลังคือการแจกจ่ายการผลิต ด้วยวิธีนี้ คุณสามารถปรับใช้ไพรเวทคลาวด์ระดับองค์กรที่มีตั้งแต่โหนดจำนวนหนึ่งไปจนถึงคลัสเตอร์ขนาดใหญ่ที่มีโหนดหลายร้อยหรือเหตุการณ์มากมาย

ไดอะแกรมต่อไปนี้แสดงโครงสร้างของ openstack-ansible privatecloud:

ชีวิตที่ปราศจาก DevStack:การพัฒนา OpenStack ด้วย OSA

หลังจากดูสิ่งนี้แล้ว คุณอาจกำลังเกาหัวคิดว่าโปรเจ็กต์นี้ตรงกับความเรียบง่ายของ DevStack สำหรับการพัฒนาต้นน้ำได้อย่างไร เนื่องจากมันเน้นไปที่คลาวด์ส่วนตัวแบบหลายโหนดอย่างชัดเจน อย่าสิ้นหวัง! Icover นี้ในหัวข้อถัดไป.

OSA All-In-One

ผู้สนับสนุนโครงการ openstack-ansible ใช้การปรับใช้โหนดเดียวสำหรับการทำงานในแต่ละวันและสำหรับเกตติ้ง เนื่องจากสะดวกกว่าและประหยัดทรัพยากร ด้วยวิธีการปรับใช้นี้ จะทำให้ OSA ทำงานบนเซิร์ฟเวอร์คลาวด์หรือเครื่องเสมือนได้ ดังนั้นการใช้ประโยชน์จากคุณลักษณะนี้จะทำให้โครงการนี้เปรียบได้กับ DevStack

น่าเสียดายที่ข้อกำหนดของโฮสต์สำหรับการปรับใช้ OSA แบบโหนดเดียวนั้นสูงกว่า DevStack สาเหตุหลักมาจากโอเวอร์เฮดที่แนะนำโดยโครงสร้างพื้นฐานคอนเทนเนอร์ สำหรับการติดตั้งที่ใช้งานได้ โฮสต์ต้องมี RAM 16GB และพื้นที่ดิสก์ 80GB ในขณะนี้ ระบบปฏิบัติการโฮสต์เดียวที่รองรับคือ Ubuntu14.04

ข้อดีอย่างหนึ่งที่ OSA มีเหนือ DevStack คือต้องขอบคุณสถาปัตยกรรมที่มีคอนเทนเนอร์ ทำให้สามารถปรับใช้บริการที่ซ้ำซ้อนได้แม้ในการติดตั้งโหนดเดียว ในการปรับใช้โหนดเดียวที่เป็นค่าเริ่มต้น galera, rabbitmq และkeystone จะถูกปรับใช้ด้วยความซ้ำซ้อน และ 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 extras และ wrapper script อีกสองสามตัวที่ทำให้การใช้งานง่ายขึ้น:

# scripts/bootstrap-ansible.sh

ณ จุดนี้ โฮสต์พร้อมที่จะรับการติดตั้ง OSA เรียกใช้ Ansible playbooks ที่ทำการติดตั้ง:

# scripts/run-playbooks.sh

บนเซิร์ฟเวอร์ Rackspace Public Cloud การดำเนินการเต็มรูปแบบผ่าน playbooks ทั้งหมดจะใช้เวลาประมาณ 45 นาทีจึงจะเสร็จสมบูรณ์ ข้อดีอย่างหนึ่งของการทำงานร่วมกับ Ansible ก็คืองานทั้งหมดนั้นไม่มีศักยภาพ หมายความว่าสามารถดำเนินการ playbooks ได้หลายครั้งโดยไม่ก่อให้เกิดปัญหาใดๆ หากงานได้ดำเนินการไปแล้ว การเรียกใช้งานครั้งที่สองจะไม่มีผลใดๆ สิ่งนี้มีประโยชน์มากจริง ๆ เนื่องจากทำให้สามารถกำหนดค่าระบบจริงใหม่ได้ง่ายๆ โดยเปลี่ยนไฟล์การกำหนดค่าที่เหมาะสมและเรียกใช้ playbook อีกครั้ง โดยไม่จำเป็นต้องทำลายทุกอย่างก่อน

การแนะนำอย่างรวดเร็วของ openstack-ansible

ในส่วนนี้ ฉันต้องการให้คุณเห็นภาพรวมของ OSA single-nodestructure เพื่อให้คุณที่กล้าพอที่จะยืนหยัดได้รู้ว่าทุกสิ่งทุกอย่างอยู่ที่ไหน

ประการแรก แดชบอร์ด Horizon ถูกปรับใช้และควรสามารถเข้าถึงได้จากที่อยู่ IP สาธารณะของโฮสต์ คุณสามารถใช้ ผู้ดูแลระบบ บัญชีด้วยรหัสผ่านที่คุณป้อนใน /etc/openstack_deploy/user_secrets.yml ไฟล์ หากคุณไม่ได้แก้ไขไฟล์นี้ คุณต้องเปิดไฟล์นี้และค้นหา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

คอนเทนเนอร์ยูทิลิตี้มีประโยชน์เนื่องจากมีการติดตั้งไคลเอนต์บรรทัดคำสั่ง OpenStack ทั้งหมด รวมถึง openrc ที่พร้อมใช้งาน ไฟล์สำหรับบัญชีผู้ดูแลระบบ ในเซสชันตัวอย่างต่อไปนี้ ฉันใช้ openstack ยูทิลิตีเพื่อสอบถามรายชื่อผู้ใช้ในการปรับใช้ของฉัน:

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 หรือ hitCtrl-D

นี่เป็นอีกหนึ่งคุณลักษณะที่ดีของ Ansible:ช่วยให้คุณสามารถติดตั้งบริการใหม่ได้เช่นเดียวกับบริการที่เสียหายระหว่างการพัฒนาโดยผิดพลาด ในการทำเช่นนี้ เพียงทำลายคอนเทนเนอร์ที่ได้รับผลกระทบ:

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

หลังจากที่ตู้คอนเทนเนอร์ที่ป่วยถูกทำลาย การเรียกใช้ playbook อีกครั้งจะทำให้มีการสร้างอันใหม่ขึ้นมาทดแทน ซึ่งจะใช้เวลาเพียงเสี้ยววินาทีในการติดตั้งทุกอย่างตั้งแต่เริ่มต้น

ขั้นตอนการพัฒนา

คุณต้องการที่จะรู้ว่าฉันใช้การปรับใช้ OSA all-in-one แทน DevStack ได้อย่างไรในทางปฏิบัติ กระบวนการนี้เกี่ยวข้องกับขั้นตอนง่ายๆ ไม่กี่ขั้นตอน:

  1. ปรับใช้ OSA-AIO

    แน่นอน ทุกอย่างเริ่มต้นด้วยการปรับใช้ openstack-ansiblecloud โหนดเดียว ปกติแล้วฉันจะใช้เซิร์ฟเวอร์ Rackspace Public Cloud เป็นโฮสต์ของฉัน แต่คุณสามารถใช้โฮสต์ anyUbuntu 14.04 ด้วยข้อกำหนดที่ฉันระบุไว้ข้างต้นได้

  2. แนบไปกับคอนเทนเนอร์เป้าหมาย

    จากนั้นฉันก็เข้าไปในคอนเทนเนอร์ที่เรียกใช้บริการที่ฉันต้องการทำงานโดยใช้ lxc-attach คำสั่งที่ฉันแสดงไว้ข้างต้น ถ้าฉันจะทำงานบนบริการที่ถูกปรับใช้ด้วยความซ้ำซ้อน ขั้นแรกฉันจะแก้ไข HAProxyconfiguration เพื่อให้มีคอนเทนเนอร์เพียงอันเดียวที่ทำงานอยู่ คอนเทนเนอร์ที่เหลือสามารถใช้เป็นข้อมูลสำรองได้หากมีสิ่งผิดปกติเกิดขึ้นกับคอนเทนเนอร์ที่เลือก

  3. หยุดบริการเป้าหมาย

    คอนเทนเนอร์กำลังเรียกใช้บริการเวอร์ชันที่ใช้งานจริงที่ฉันตั้งใจจะใช้งาน เนื่องจากบริการนี้ไม่มีประโยชน์สำหรับฉัน ฉันจึงหยุดโดยใช้ service <name> stop มาตรฐาน สั่งการ. ตัวอย่างเช่น ถ้าฉันอยู่ในคอนเทนเนอร์ฮีทเครื่องยนต์ ฉันจะเรียกใช้ service heat-engine stop .

  4. เวอร์ชันพัฒนาโคลน

    ตอนนี้ฉันมีคอนเทนเนอร์ที่เตรียมไว้สำหรับเรียกใช้บริการเป้าหมาย ดังนั้นฉันจึงยกเลิกโค้ดจริงที่จะใช้งาน สำหรับสิ่งนี้ ฉันอาจใช้ที่เก็บ git อย่างเป็นทางการ ส้อมของฉันที่มีการเปลี่ยนแปลงแบบกำหนดเอง หรืออาจเป็นโปรแกรมแก้ไขจาก Gerrit หากฉันกำลังตรวจสอบ

  5. อัปเดตการพึ่งพา

    เวอร์ชันการพัฒนาอาจต้องใช้ชุดการพึ่งพาที่แตกต่างจากเวอร์ชันที่ติดตั้งโดย Playbooks Ansible ดังนั้นเพื่อความปลอดภัย Irun pip install -r requirements.txt ในภาชนะ เนื่องจาก OSA สร้างที่เก็บแพ็คเกจ Python ส่วนตัวของตัวเอง เวอร์ชันที่จำเป็นของ apackage อาจไม่พร้อมใช้งานในนั้น เมื่อสิ่งนั้นเกิดขึ้น ฉันตั้งค่า no-index = False ในคอนเทนเนอร์ /root/.pip/pip.conf เพื่อเปิดใช้งานการเข้าถึง pypi แล้วลองอีกครั้ง

  6. ซิงค์ฐานข้อมูล

    ความแตกต่างที่เป็นไปได้อีกประการระหว่างเวอร์ชันดั้งเดิมที่ติดตั้งกับ OSA และเวอร์ชันการพัฒนาของฉันคือการโยกย้ายฐานข้อมูล ดังนั้นฉันจึงซิงค์ฐานข้อมูลเสมอ เผื่อในกรณีที่ คำสั่งในการดำเนินการนี้จะแตกต่างกันเล็กน้อยระหว่างบริการ แต่โดยปกติแล้วจะต้องเรียกใช้สคริปต์การจัดการด้วย db_sync ตัวเลือก. ตัวอย่างเช่น เมื่อทำงานกับ Keystone คำสั่งในการซิงค์ฐานข้อมูลคือ keystone-manage db_sync

  7. ทำการเปลี่ยนแปลงไฟล์ปรับแต่งดั้งเดิม หากจำเป็น

    playbooks สร้างไฟล์การกำหนดค่าสำหรับบริการทั้งหมด ดังนั้นโดยส่วนใหญ่แล้ว การกำหนดค่าที่เหลืออยู่ใน /etc ไดเร็กทอรีโดยโปรแกรมติดตั้งสามารถใช้งานได้โดยไม่มีการเปลี่ยนแปลงในการพัฒนา หากฉันจำเป็นต้องทำการเปลี่ยนแปลงแบบกำหนดเองที่เกี่ยวข้องกับงานของฉัน ฉันจะทำการเปลี่ยนแปลงด้วยตนเองด้วยโปรแกรมแก้ไขข้อความ

  8. เรียกใช้ด้วยตนเอง หรือติดตั้งและเรียกใช้เป็นบริการ

    ในที่สุด เวอร์ชันการพัฒนาสามารถเริ่มต้นได้ หากต้องการทำสิ่งนี้อย่างง่ายดาย เพียงเรียกใช้แอปพลิเคชัน Python โดยตรง ตัวอย่างเช่น ถ้าฉันกำลังทำงานเกี่ยวกับบริการฮีทเอ็นจิ้น ฉันสามารถเรียกใช้ bin/heat-engine จากไดเร็กทอรีรากของโปรเจ็กต์เพื่อเริ่มบริการในเบื้องหน้า โดยมีการบันทึกไปยังเทอร์มินัล หากต้องการหยุดบริการ ฉันกด Ctrl-C ได้เหมือนที่ทำใน DevStack

    ดีบักเกอร์ที่เป็นมิตรต่อเทอร์มินัล เช่น pdb (บรรทัดคำสั่ง) หรือ pudb (แบบโต้ตอบ) สามารถติดตั้งภายในคอนเทนเนอร์และใช้งานได้ดี การดีบักระยะไกลผ่าน ssh จากโฮสต์ไปยังคอนเทนเนอร์ยังสามารถทำได้ หากคุณต้องการใช้ดีบักเกอร์ที่ซับซ้อนมากขึ้น เช่น PyCharm

    สำหรับบริการส่วนใหญ่ การเรียกใช้ด้วยตนเองก็เพียงพอที่จะทำงานได้อย่างสะดวกสบายเช่นเดียวกับ DevStack ข้อยกเว้นเพียงอย่างเดียวคือสำหรับบริการที่ไม่ได้เรียกใช้ Pythonscripts โดยตรง เช่น Keystone ซึ่งปกติทำงานภายใต้ Apache แม้ว่า Apache จะใช้ในการผลิต แต่สำหรับการพัฒนานั้นปลอดภัยอย่างสมบูรณ์ที่จะเรียกใช้แอปพลิเคชัน Python โดยตรง ซึ่งอาจเรียกใช้เว็บเซิร์ฟเวอร์ตามเหตุการณ์ หากต้องการใช้ Apache ไม่ว่าจะด้วยเหตุผลใดก็ตาม ทางเลือกอื่นคือการติดตั้งเวอร์ชันการพัฒนาโดยการเรียกใช้ python setup.py install แล้วเริ่มบริการ Apache ที่ติดตั้งไว้แล้วใหม่ด้วย service apache2 restart . นอกจากนี้ยังสามารถเรียกใช้แอปพลิเคชันจากไดเร็กทอรีต้นทางด้วยการติดตั้งด้วย python setup.py develop แล้วเพิ่มโฮมไดเร็กทอรีไปยังไฟล์การกำหนดค่าไซต์ Apache

OSA-AIO:ข้อดี

การทำงานกับ OSA แทน DevStack ถือเป็นประสบการณ์ที่น่าพึงพอใจ การไม่มีความขัดแย้งในการพึ่งพาอีกต่อไปเป็นเรื่องที่ดี เพราะสำหรับ OSA หาก Ineed ทำการรีเบสบริการใดบริการหนึ่งและต้องการการขึ้นต่อกันใหม่ บริการอื่นๆ จะไม่ได้รับผลกระทบในคอนเทนเนอร์ของตนเอง

ฉันยังพบว่าฉันแทบไม่ต้องสร้างการปรับใช้ใหม่ทั้งหมดตั้งแต่เริ่มต้น ฉันมักจะทำอย่างนั้นเมื่อฉันต้องการอัปเกรดทั้งระบบเป็น OpenStack รุ่นใหม่ แต่สำหรับการทำงานในแต่ละวัน ฉันพบว่าการอัปเดตหรือซ่อมแซมในเครื่องนั้นทำได้ง่าย ไปยังการติดตั้งที่มีอยู่ ฉันชอบที่จะสามารถทำลายคอนเทนเนอร์ แล้วให้ Ansible สร้างใหม่ให้ฉันโดยไม่ต้องแตะต้องบริการที่เหลือ

สุดท้ายนี้ ฉันชอบที่ OSA อนุญาตให้ฉันเลือกว่าส่วนใดของระบบที่ฉันติดตั้งเป็นแพ็คเกจการพัฒนา ในขณะที่ยังคงติดตั้งและกำหนดค่า OpenStack บนคลาวด์ที่เหลือและกำหนดค่าสำหรับการใช้งานจริง

OSA-AIO:ข้อเสีย

แต่แน่นอนว่า เช่นเดียวกับกรณีของทุกอย่าง มีบางแง่มุมของการทำงานร่วมกับ OSA ที่ไม่ดีนัก ดังนั้นผมจึงอยากนำเสนอด้านนั้นให้กับคุณเช่นกัน

OSA เป็นโครงการใหม่ ดังนั้นจึงไม่ได้รับการสนับสนุนอย่างกว้างขวางจากชุมชนที่ DevStack ชื่นชอบ นี่เป็นสิ่งสำคัญอย่างยิ่งหากคุณทำงานบนโมดูลที่ไม่ได้เป็นแกนหลักของ OpenStack ในขณะที่ฉันกำลังเขียนสิ่งนี้ OSA รองรับการปรับใช้ Keystone, Nova, Neutron, Glance, Cinder, Swift, Heat, Ceilometer และ Horizon หากคุณต้องการทำงานในโมดูลที่ไม่รวมอยู่ในรายการนี้ OSA อาจไม่เป็นประโยชน์สำหรับคุณ แต่ในอีกด้านหนึ่ง หากคุณต้องการสร้าง Ansible playbook สำหรับโมดูลที่ไม่ได้รับการสนับสนุนในขณะนี้ คุณจะได้รับอาวุธเปิด

โดยทั่วไป มีตัวเลือกการกำหนดค่าจำนวนมากพอสมควรที่เปิดเผยเป็น Ansiblevariables สำหรับทุกโมดูล โดยมีข้อยกเว้นเพียงข้อเดียว เมื่อพูดถึงนิวตรอน การกำหนดค่าไม่ยืดหยุ่นเท่าที่ควร อุโมงค์เครือข่ายในคอนเทนเนอร์และ VM ถูกกำหนดค่าให้ใช้ Linux Bridge เสมอ ตัวอย่างเช่น หากคุณต้องการใช้งานOpen vSwitch คุณจะต้องแก้ไขการกำหนดค่าด้วยตนเองหลังจากรัน playbooks ซึ่งไม่สนุก นอกจากนี้ยังไม่สนับสนุนปลั๊กอินนิวตรอนในขณะนี้

บทสรุป

ฉันหวังว่าคุณจะพบเวิร์กโฟลว์ของฉันด้วย openstack-ansible ที่น่าสนใจในการเรียนรู้และใช้งาน มันช่วยฉันประหยัดเวลาในการทำงานกับคุณสมบัติอัพสตรีมความร้อนและการแก้ไขข้อบกพร่อง ฉันยังใช้ OSA อย่างมากในการดีบักและแก้ไขปัญหา Keystonefederation

หากคุณสนใจที่จะใช้ OSA ฉันยังแนะนำให้คุณทำการค้นหาเล็กน้อย เพราะนั่นจะนำคุณไปสู่บทความและโพสต์ในบล็อกเพิ่มเติม (เช่นอันนี้หรืออันนี้) ซึ่งผู้ร่วมให้ข้อมูลของ OpenStack คนอื่นๆ จะอธิบายว่าพวกเขารวม OSA เข้ากับ OSA อย่างไร เวิร์กโฟลว์ของตัวเอง