Ironic - A modern approach to machine deployment
Ironic is a modern open-source tool for hardware provisioning. Combining a RESTful API, a scale-out control plane, and pluggable hardware drivers for both in- and out-of-band management, Ironic installs operating systems in a fast, efficient, and reliable fashion. In fact, Ironic does not “install” an operating system in the traditional sense – it doesn’t use a kickstart/preseed file or an ISO image. Instead, compressed machine images are copied onto each host, and a minimal configuration (IP, host name, SSH keys) is applied at first boot. This guarantees the consistency of the initial state of each machine in a way that traditional installers do not. Bonus: it’s also faster! With a vibrant community of developers from the most popular server hardware vendors, Ironic’s support for many of the latest and greatest management technologies is coming directly from the creators of these technologies. Meanwhile, the project’s leaders work to create a common abstraction layer that provides a consistent experience across all supported hardware. But Ironic is still a young project – it was only started in 2013 – and there is much on the roadmap. In this session, Devananda will demonstrate how to install Ironic with Ansible, modify a cloud image for bare metal, and deploy it to a server. He will discuss the history and architecture of the project, and its current goals and challenges. Attendees should be familiar with the task of hardware provisioning and standards like PXE and IPMI, but do not need deep knowledge of related tools.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (6)
Ähnlich wie Ironic - A modern approach to machine deployment
Ähnlich wie Ironic - A modern approach to machine deployment (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Ironic - A modern approach to machine deployment
- 1. IRONIC A MODERN APPROACH TO MACHINE DEPLOYMENT DEVANANDA VAN DER VEEN @DEVANANDA GITHUB.COM/DEVANANDA/TALKS
- 2. ABOUT Performance Consultant Engineer @ HP Cloud Likes interactive audiences Favorite whisky: Nikka
- 3. Observation: Every company has their own PXE-based installation framework Binary image copy improves repeatability and reduces entropy So why not do this for bare metal, too?
- 4. Ironically, a physical machine behaves a lot like a VM or a container Based on the name, you might have expected that joke
- 7. Build and customize your own images $ pip install diskimagebuilder $ diskimagecreate o myimage t qcow2 a amd64 ubuntu vm serialconsole cloudinitdatasources "vm" element creates partition table and installs a bootloader Don't ask me why it's called "vm"
- 8. You can build your own deploy ramdisk Or download a and image from our build server $ pip install diskimagebuilder $ ramdiskimagecreate o myramdisk a amd64 ubuntu deployironic kernel ramdisk http://tarballs.openstack.org/ironic-python- agent/coreos/files
- 9. STANDARD PROTOCOLS Power IPMI: intelligent platform management interface, for remote control of machine power state, boot device, serial console, etc. SNMP: simple network management protocol, often used with Power Distribution Units for remote control of power status.
- 10. STANDARD PROTOCOLS Boot DHCP: dynamic host configuration protocol, used to locate the NBP on the network, and provide the host OS with IP address during init TFTP: trivial file transfer protocol, copies the NBP over the network PXE: pre-boot execution environment, allows host to boot from network [g,i]PXE: recent enhancements make PXE more flexible, supported on most hardware
- 11. IPMI HAS NOT SIGNIFICANTLY CHANGED IN THE LAST 10 YEARS Meanwhile, vendors continue to add new (and different!) capabilities to their management controllers, each with different protocols
- 12. A new standard is in the works (RedFish) but software will continue to change faster than hardware standards
- 13. Vendor value is derived from quality of hardware, services, support, and integration not from proprietary solutions to common problems
- 14. ARCHITECTURE
- 16. DRIVER API
- 17. This gives driver authors a lot ofsimplicity flexibility While the REST API provides common abstraction for provisioning a pool of servers repeatably regardless of vendor
- 18. Resource types: Node, Port, Driver (*) Documentation is continually built from source and packaged with each release REST API docs.openstack.org/developer/ironic/webapi/v1.html (*) There is a fourth resource type, "chassis". This is a remnant of early designs, and doesn't perform a meaningful function today
- 21. Every driver is different and requires specific attributesdriver_info You enter this once, when enrolling the Node Read the driver's documentation Or discover it from the API
- 23. Instances are assumed to be different. Therefore, is cleared after instance deletion. instance_info
- 24. Vendors can implement additional capabilities which are to their driver.passed directly These are implemented at: /v1/drivers/NAME/vendor_passthru/ /v1/nodes/UUID/vendor_passthru/ In practice, this is little used, as drivers are encouraged to converge into a common API.
- 25. This is just an example. Different drivers do things differently, after all. DEPLOYMENT SEQUENCE
- 28. PROVISIONING STATE MACHINE STATE - stable (or passive) state R:verb - request that begins a transition [STATE*/TARGET] - active, momentary, or error state
- 29. Progress is reflected in the API "power_state" : "power on", # last known power st "target_power_state" : null, # nonnull if "provision_state" : "deploying", # current provision s "target_provision_state" : "active", # last requested prov "updated_at" : "20150602T19:39:04+00:00", # exposed timing data "reservation" : Leni, # exposed lock status
- 30. PROVISIONING STATE MACHINE (it's always more complicated than you expect)
- 31. Use Ansible for automation Separate and reusable playbooks KEEPING IT SIMPLE
- 33. First things first: input environment vars $ cat bifrost/playbooks/inventory node_default_network_interface: eth0 network_interface: eth2 ipv4_subnet_mask: 255.255.255.0 ipv4_gateway: 192.168.1.1 ipv4_nameserver: 8.8.8.8 dhcp_pool_start: 192.168.2.200 dhcp_pool_end: 192.168.2.250 deploy_kernel: "{{http_boot_folder}}/coreos_production_pxe.vmlinuz" deploy_ramdisk: "{{http_boot_folder}}/coreos_production_pxe_imageoem.cpio.gz deploy_image_filename: "deployment_image.qcow2" deploy_image: "{{http_boot_folder}}/{{deploy_image_filename}}"
- 34. installs external dependencies, configures your environment Install $ bash ./scripts/envsetup.sh $ source /opt/stack/ansible/hacking/envsetup $ cd playbooks $ ansibleplaybook K vvvv i inventory/localhost install.yaml
- 35. supply inventory file OR use CLI to create Nodes, Ports Enroll $ ansibleplaybook vvvv i inventory/localhost enroll.yaml e baremetal_csv_file=baremetal.csv $ ironic nodecreate d agent_amttool n nuc i amt_password='Pa$$w0rd' i amt_address='192.168.2.3' i amt_username= p cpu_arch=x86_64 p local_gb=64 p memory_mb=8192 p cpus=2 i deploy_ramdisk='http://192.168.2.2:8080/coreos_production_pxe_imageoe i deploy_kernel='http://192.168.2.2:8080/coreos_production_pxe.vmlinuz' $ ironic portcreate n $UUID a ec:a8:6b:fe:e1:b0
- 36. reads inventory file OR gathers list from Ironic directly then populates and starts the deploy Deploy $ ansibleplaybook vvvv i inventory/bifrost_inventory.py deploydynamic.yaml instance_info
- 37. OPENSTACK?