DOCSLIB.ORG

Infrastructure As Code

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Infrastructure as Code Towards Dynamic and Programmable IT systems Sotirios Naziris November, 2019 Infrastructure as Code Towards Dynamic and Programmable IT systems A thesis submitted in fulfillment of the requirements for the Master of Science degree in Internet Science and Technology Faculty of Electrical Engineering, Mathematics and Computer Science Author Graduation Committee Name: Sotirios Naziris Chairman: Dr. L. Ferreira Pires (UT) Institute : University of Twente Members: Dr. M. J. van Sinderen (UT) 7500 AE Enschede ing. R. IJpelaar (Thales) The Netherlands Abstract The manual installation and configuration of IT systems has been a tedious and time consuming process that created several challenges to the engineers during the maintenance and management process of the IT systems. The introduction of cloud computing in combination with the rise of the virtualization technology have managed to address some of these challenges. However, these virtualized cloud systems are followed by a huge portfolio of new tools and platforms that are difficult to learn and maintain. As a result, organizations started investigating the software-defined technology as a new and effective way to meet these new standards and serve the constantly increasing demand of the industry. The software-defined technology describes every part of an IT system that can be performed entirely by software, ranging from the infrastructure to the deployment level of an IT system. The goal of this research project was to investigate the software-defined technology and suggest how it can be used in order to improve the static IT infrastructure of an organization. The literature study of this research focuses on the concepts and the available software-defined tools at each layer of an IT system. Based on the knowledge acquired from the literature study, a reference architecture of the infrastructure and the network layer of a generic software-defined system was proposed that describes the interconnections between the different software-defined concepts. The next step was the design of a software-defined system that uses specific tools and technologies, and is based on a specific list of requirements. The requirements were formed by studying the needs of an actual mission critical organization. The final step was the validation of the design, which was performed by conducting a series of semi-structured interviews with seven industry experts. The validation results showed that the software-defined technology can improve the scalability, upgradability and documentation of an IT system, but the proposed design involves high levels of complexity, which might affect the performance and the required learning curve of the system. Overall, the interviewees acknowledged the potential of this technology and mentioned that its current maturity is inadequate for mission critical systems. Based on these remarks, a list of recommendations and several aspects that require additional future research are included in this thesis. i Preface This thesis was written to fulfill the final step of my “Internet Science and Technology” master programme at the University of Twente. The report had been written within a seven months period, started on May 2019 and was officially finalized on November 2019. The project was inspired and performed in cooperation with Thales Nederland, which is a company that specializes in naval systems, logistics and air defense systems and they are in constant search of new technologies that could help them improve their current systems. At this point, I would like to express my sincere gratitude to all the people that helped me complete this master thesis project. First of all, I would like to thank my university supervisors, Luis and Marten for their guidance throughout this research procedure. Their feedback was really useful on improving the structure of the thesis and finding the correct research approach. Furthermore, I would like to thank my supervisors from Thales for their useful feedback and support. I would like to thank Remco for his help especially on the technical part and for our great cooperation during our weekly meetings. I would also like to thank Gerrit Binnenmars for coming up with the idea of this project and for challenging me to think creatively and unconventionally. In addition, I would like to acknowledge the help from Andreas Frank who showed great interest into my project and provided fruitful feedback on the writing of this master thesis project. Additionally, I would like to express my gratitude to the rest of the Thales employees who participated in the validation interviews and offered their valuable insights on my designs. Moreover, I would like to thank my parents for supporting me throughout my entire life and for giving me the opportunity to continue with my studies abroad. Last but not least, I would like to thank my girlfriend Virginia for her love and emotional support during the tough times that I faced during the completion of this project. I hope that the reading of this thesis will be useful and interesting to you, and you can always contact me in case you have any questions or comments. Sotiris Enschede, Netherlands ii Table of contents Abstract ............................................................................................................................. i Preface ............................................................................................................................. ii Table of contents ............................................................................................................. iii List of Figures .................................................................................................................. vi List of Tables .................................................................................................................. vii Acronyms ....................................................................................................................... viii 1 Introduction ............................................................................................................... 1 1.1 Problem Statement ......................................................................................................... 1 1.2 Software-Defined Concept .............................................................................................. 2 1.3 Scope .............................................................................................................................. 3 1.4 Research Methodology ................................................................................................... 4 1.5 Literature Study ............................................................................................................... 5 1.6 Thesis Structure .............................................................................................................. 6 2 Software-Defined Infrastructure ................................................................................ 7 2.1 General Elements ........................................................................................................... 7 2.2 Benefits of Infrastructure as Code ................................................................................ 10 2.3 Provisioning Tools ......................................................................................................... 12 2.3.1 Terraform ............................................................................................................... 12 2.3.2 Openstack Heat ..................................................................................................... 14 2.3.3 Comparison of the provisioning tools ..................................................................... 14 2.4 Configuration Tools ....................................................................................................... 15 2.4.1 Chef ....................................................................................................................... 15 2.4.2 Puppet ................................................................................................................... 17 2.4.3 Ansible ................................................................................................................... 18 2.4.4 Saltstack ................................................................................................................ 19 2.4.5 Comparison of the configuration tools ................................................................... 20 3 Software-Defined Technology at the Network Layer ............................................... 22 3.1 Software-Defined Networking ....................................................................................... 22 3.1.1 Southbound Interfaces ........................................................................................... 24 iii 3.1.2 Northbound Interfaces ........................................................................................... 25 3.1.3 SDN Controllers ..................................................................................................... 26 4 Software-Defined Computing .................................................................................. 31 4.1 Benefits of SDC ............................................................................................................ 32 4.2 SDC Tools ....................................................................................................................
Recommended publications
  • Compass – a Streamlined Openstack Deployment System

    Compass – a Streamlined Openstack Deployment System

    2013年11月7日星期四 Compass – A Streamlined OpenStack Deployment System Shuo Yang Principal Architect of Cloud Computing, US R&D Center Outline of This Talk 1 Scope of Problem for Compass 2 Compass Explained 3 DRY, Truly Open Deployment 1 Compass at a Glimpse Think Big, Start Small A General System to Deploy Distributed Systems, Extensibility as a Primary Design Goal Not Limited to OpenStack, but Streamlined Our OpenStack Deployment Like a Charm To Be Open Sourced – Apache 2.0 Soon 100% Python, 5000 Line of Python Code Successfully Deployed Several Dogfood Clusters Compass Wiki Page: https://wiki.openstack.org/wiki/Compass 2 Data Center as a Computer Open Cloud OS (OpenStack) Open Deployment (Compass) OpenStackLinux Quantumeth0, lo Nova/proc Cinder/dev Live Auto CD / Deploy GRUB NIC CPU Disk SwitchSwitchSwitch CPUCPUServer DiskStorage NIC CPU Disk (5020) (2285/1285) (N8000/N900) OpenStack Control Channel LILO/GRUB/LiveCD for OpenStack HW/SW Configuration Deployment Channel 3 Why We Are Doing This? Full HW Portfolio in Data Center No.1 as Storage Revenue Growth No. 2 as `x86 Server Revenue Growth Needless to Say, Networking Gears.. OpenStack Makes the Above a Full Global Excellent Telecom Cloud Solution Cloud Solution Provider of year 2012 4 OpenStack Deployment System Overview Crowbar TripleO (“under the cloud” mode) Pioneer effort, a Ruby web app, Chef based Attractive concept to OpenStack folks: configuration management deploy OpenStack from OpenStack Fuel DevStack A great web apps, Puppet based A great tool for simple OpenStack
  • Red Hat Satellite 6.3 Architecture Guide

    Red Hat Satellite 6.3 Architecture Guide

    Red Hat Satellite 6.3 Architecture Guide Planning Satellite 6 Deployment Last Updated: 2019-04-16 Red Hat Satellite 6.3 Architecture Guide Planning Satellite 6 Deployment Red Hat Satellite Documentation Team [email protected] Legal Notice Copyright © 2019 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/ . In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries. Node.js ® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
  • Migrate-To-WVD-And-Beyond-By-Marius-Sandbu

    Migrate-To-WVD-And-Beyond-By-Marius-Sandbu

    Migrate to WVD and Beyond Published by Marius Sandbu on December 11, 2020 This blog post is split into different sections. Plan Assess Foundation Migrate/Rebuild/Extend Operate and Govern 1. Plan So if you want to move from an existing VDI platform to Windows Virtual Desktop (WVD) there are a lot of requirements that you need to understand (and not just the technical requirements). You are essentially moving to a cloud based ecosystem where WVD might be one of the workloads that is part of the big puzzle. And of course when hosting a VDI platform you need to have the applications and the data close together to ensure that you have an optimized end-user experience. In most organizations you have already invested time and money into training and processes to manage and operate the existing VDI platform. Also you might have 3.party management tools which are used to manage your VDI Service. Understand the state you are coming from: Existing VDI Solution – Technology Management & Operations – Process Knowledge and Expertise – People These will of course change when you migrate to WVD and you would need to ensure that you have the right skill and competency in place to manage a WVD enviroment ( in addition to the other workloads in Azure as well) Just to showcase how the difference might be from a technology perspective. Other standing the VDI workloads and requirements End-user requirements – Devices, Peripherals and Working Patterns End-user endpoints – Domain Join or Azure AD Based Workloads – Power Users or Office Workers Supporting
  • Infrastructure As Code with Oracle Linux & Terraform Running On

    Infrastructure As Code with Oracle Linux & Terraform Running On

    Infrastructure as Code with Oracle Linux & Terraform Running on Oracle Public & Private Cloud UKOUG Midlands Summit Simon Hayler Technical Product Manager 28th February 2019 Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle. Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 2 Oracle Linux for Oracle Cloud Infrastructure Enhanced Developer Cloud-Ready, Integrated Cost Effective Compute Platform • Access to frequent and latest Oracle • Oracle Cloud developer tools such as • Oracle Linux Support is provided at Linux image updates Terraform, SDK's, and CLI are no additional cost on OCI deployed faster and easier via local • • Faster downloads from mirrored yum server Take advantage of its 24 x7 best-in- Oracle Container Registry and OL class support services and tools yum server within OCI • Easy access to Linux developer and preview software channels in local • No need to budget for OS support • Zero-downtime OS kernel and user OL yum server fees on OCI space updates with Ksplice pre- • installed in OCI • Thousands of EPEL packages built Use Oracle Linux as part of a fully and signed by Oracle for security and and extensively tested cloud • Comprehensive containers and compliance infrastructure stack container management support • Software Collection Library support • Oracle Linux Storage Appliance included to install recent versions of offers an easy way to build NFS and Python, PHP, NodeJS, nginx, and Samba shared storage in OCI more Copyright © 2019, Oracle and/or its affiliates.
  • Digital Ocean the Shopify of Cloud Computing

    Digital Ocean the Shopify of Cloud Computing

    DigitalOcean (DOCN) – The Shopify of Cloud Computing $200 Price Target Citron – Learning from Our Mistakes One of the greatest blunders we have made over the past 20 years of publishing Citron Research, is not realizing the power of Shopify when the stock was $100. At the time it seemed like another overpriced software company that allowed people to perform the simplest of tasks… making websites. What we failed to recognize and attribute enough value to was that: 1. Customers LOVED the product 2. The Small and Medium Sized Business (SMB) market was a lot larger than we anticipated and could work through its own churn 3. The power of a passionate and dedicated developer network 4. The ease of cross selling once a large customer base was established Congratulations to everyone who owned Shopify through the years. Citron has been waiting patiently for another company to come along with the same profile, hoping with fingers crossed that valuation would be investible… and it has finally come to market. Enter DigitalOcean – The Shopify of Cloud Computing DigitalOcean (DOCN) is a cloud computing platform purpose-built for SMBs (i.e., the Shopify of cloud computing or AWS for SMBs) at a fraction of the cost of large cloud providers. The transformation to the cloud for large enterprises is obviously already on its way. Just look at Amazon with Wall Street analysts estimating the value of AWS at $700-800 billion. The next wave is the SMB transformation to the cloud and multi cloud. We’ve seen this movie before and just like how Shopify and Square saw that SMBs were not far behind large enterprises in adopting ecommerce and digital payments, DigitalOcean is in the leading position to capitalize on this mega trend.
  • Infrastructure As Code with Terraform Greg@Blacksintechnology:~$ Whoami Greg Greenlee Agenda

    Infrastructure As Code with Terraform Greg@Blacksintechnology:~$ Whoami Greg Greenlee Agenda

    Infrastructure as Code with Terraform greg@blacksintechnology:~$ whoami Greg Greenlee Agenda ● What is IaC? ○ Benefits ● What is Terraform? ● Why do we need Terraform? ● How do we use Terraform? ○ Providers ○ Resources ○ Variables (inputs) ○ Outputs ○ Data Structures ○ Modules ○ Conditionals ○ Iterations ○ Terraform State ● How do I get started? What Is Infrastructure as Code? The ability to describe/define your infrastructure and application in source code Benefits of IaC ● Software methodologies, tools and practices ○ Code reviews ○ Automated testing ○ linting Automation Version Control Thor-1.0 Rollback Thor-1.no Documentation Also…. Correlation Visibility Traceability What is Terraform? ● Infrastructure as code management tool that uses a declarative language to build infrastructure ● Written in Go ● terraform.io Imperative vs Declarative Imperative (How) Declarative (What) ● Buy chocalate cake mix I need a chocolate cake big enough to feed 20 ● Open cake mix box people ● Pour cake mix in bowl ● Add ingredients ● Stir ● Pour in pan ● Preheat oven to 350 ● Place pan in oven ● Bake at 350 ● etc Why do we need Terraform? Infrastructure is hard! Idempotent Cloud agnostic DEV STAGING PRODUCTION How do we use Terraform? Installs as a single binary (https://www.terraform.io/downloads.html) ● MacOS ● Linux ● Windows ● FreeBSD ● Solaris Usage ● Terraform init ○ initializes terraform directory ○ pulls in plugins for specified provider ○ Pulls in modules ● Terraform fmt ○ Rewrites terraform config files to canonical format and style ● Terraform
  • Terraform Scripts in Oracle Weblogic Server for OCI

    Terraform Scripts in Oracle Weblogic Server for OCI

    Oracle® Cloud Terraform Scripts in Oracle WebLogic Server for OCI F35192-09 August 2021 Oracle Cloud Terraform Scripts in Oracle WebLogic Server for OCI, F35192-09 Copyright © 2020, 2021, Oracle and/or its affiliates. Primary Author: Oracle Corporation This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end users are "commercial computer software" or "commercial computer software documentation" pursuant to
  • Automating the Enterprise with Ansible

    Automating the Enterprise with Ansible

    AUTOMATING THE ENTERPRISE WITH ANSIBLE Dustin Boyd Solutions Architect September 12, 2017 EVERY ORGANIZATION IS A DIGITAL ORGANIZATION. Today, IT is driving innovation. If you can’t deliver software fast, your organization can’t meet the mission, period. Digital organizations are essentially software. If they expect to thrive in a digital environment, they must have an improved competence in software delivery. Gartner 2015 2 COMPLEXITY KILLS PRODUCTIVITY. Complexity is the enemy of innovation, which is why today’s enterprises are looking to automation and DevOps tools and practices. DevOps can help organizations that are pushing to implement a bimodal strategy to support their digitalization efforts. Gartner 2015 3 WHEN YOU AUTOMATE, YOU ACCELERATE. Ansible loves the repetitive work your people hate. It helps smart people do smarter work. All with fewer errors and better accountability. Automation can crush complexity and it gives you the one thing you can’t get enough of… time. 4 “Ansible delivers DevOps to a broader class of enterprise users that include those inside the business units and teams where agile practices and fast provisioning of infrastructure are in demand.” JAY LYMAN, 451 RESEARCH – NOV 2013 GARTNER COOL VENDOR 2015 “Previous vendors in this [DevOps] market often require unique programming skills. Ansible’s simple language reduces the barrier to adoption and opens it up to a variety of skill sets…” 5 AUTOMATION = ACCELERATION “With Ansible Tower, we just click a button and deploy to production in 5 minutes. It used to take us 5 hours with 6 people sitting in a room, making sure we didn’t do anything wrong (and we usually still had errors).
  • Openstack: Openstack Vpnaas Ipsec Policy V2

    Openstack: Openstack Vpnaas Ipsec Policy V2

    OpenStack Provider The OpenStack provider is used to interact with the many resources supported by OpenStack. The provider needs to be congured with the proper credentials before it can be used. Use the navigation to the left to read about the available resources. Example Usage provider "openstack" { user_name == "admin" tenant_name == "admin" password == "pwd" auth_url == "http://myauthurl:5000/v2.0" region == "RegionOne" } resource "openstack_compute_instance_v2" "test-server" { } Conguration Reference The following arguments are supported: auth_url - (Optional; required if cloud is not specied) The Identity authentication URL. If omitted, the OS_AUTH_URL environment variable is used. cloud - (Optional; required if auth_url is not specied) An entry in a clouds.yaml le. See the OpenStack os- client-config documentation (https://docs.openstack.org/os-client-cong/latest/user/conguration.html) for more information about clouds.yaml les. If omitted, the OS_CLOUD environment variable is used. region - (Optional) The region of the OpenStack cloud to use. If omitted, the OS_REGION_NAME environment variable is used. If OS_REGION_NAME is not set, then no region will be used. It should be possible to omit the region in single- region OpenStack environments, but this behavior may vary depending on the OpenStack environment being used. user_name - (Optional) The Username to login with. If omitted, the OS_USERNAME environment variable is used. user_id - (Optional) The User ID to login with. If omitted, the OS_USER_ID environment variable is used. application_credential_id - (Optional) (Identity v3 only) The ID of an application credential to authenticate with. An application_credential_secret has to bet set along with this parameter. application_credential_name - (Optional) (Identity v3 only) The name of an application credential to authenticate with.
  • Oracle Cloud Infrastructure Getting Started Guide 4 Table of Contents

    Oracle Cloud Infrastructure Getting Started Guide 4 Table of Contents

    Getting Started Guide 11/26/2019 Copyright © 2016, 2019, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government. This software or hardware is developed for general use in a variety of information management applications.
  • Migration to the Oracle Cloud with an Oracle Goldengate Hub Configuration

    Migration to the Oracle Cloud with an Oracle Goldengate Hub Configuration

    Migration to the Oracle Cloud with an Oracle GoldenGate Hub Configuration April 6, 2020 Copyright © 2020, Oracle and/or its affiliates Confidential: Public Document DISCLAIMER This document in any form, software or printed matter, contains proprietary information that is the exclusive property of Oracle. Your access to and use of this confidential material is subject to the terms and conditions of your Oracle software license and service agreement, which has been executed and with which you agree to comply. This document and information contained herein may not be disclosed, copied, reproduced or distributed to anyone outside Oracle without prior written consent of Oracle. This document is not part of your license agreement nor can it be incorporated into any contractual agreement with Oracle or its subsidiaries or affiliates. This document is for informational purposes only and is intended solely to assist you in planning for the implementation and upgrade of the product features described. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described in this document remains at the sole discretion of Oracle. Due to the nature of the product architecture, it may not be possible to safely include all features described in this document without risking significant destabilization of the code. 1 White Paper|Migration to the Oracle Cloud with an Oracle GoldenGate Hub Configuration Copyright © 2020, Oracle and/or its affiliates | Public Document TABLE OF CONTENTS Disclaimer 1 Purpose Statement & Intended Audience 4 Introduction 4 Configuration Overview 5 Oracle GoldenGate 5 Oracle GoldenGate Hub 6 Nginx Reverse Proxy Server 7 Target Database Instantiation 8 Naming Conventions Used Throughout This Paper 8 Configuration Prerequisites 9 Configure the Oracle Cloud Network 9 Evaluate Source Database Support for Oracle GoldenGate 10 Configure the Source Database 11 1.
  • Cobbler Provider

    Cobbler Provider

    Cobbler Provider The Cobbler provider is used to interact with a locally installed Cobbler (http://cobbler.github.io) service. The provider needs to be congured with the proper credentials before it can be used. Use the navigation to the left to read about the available resources. Example Usage provider "cobbler" { username == "${var.cobbler_username}" password == "${var.cobbler_password}" url == "${var.cobbler_url}" } resource "cobbler_distro" "ubuntu-1404-x86_64" { } Argument Reference The following arguments are supported: username - (Required) The username to the Cobbler service. This can also be specied with the COBBLER_USERNAME shell environment variable. password - (Required) The password to the Cobbler service. This can also be specied with the COBBLER_PASSWORD shell environment variable. url - (Required) The url to the Cobbler service. This can also be specied with the COBBLER_URL shell environment variable. insecure - (Optional) Ignore SSL certicate warnings and errors. This can also be specied with the COBBLER_INSECURE shell environment variable. cacert_file - (Optional) The path or contents of an SSL CA certicate. This can also be specied with the COBBLER_CACERT_FILE shell environment variable. cobbler_distro Manages a distribution within Cobbler. Example Usage resource "cobbler_distro" "ubuntu-1404-x86_64" { name == "foo" breed == "ubuntu" os_version == "trusty" arch == "x86_64" kernel == "/var/www/cobbler/ks_mirror/Ubuntu-14.04/install/netboot/ubuntu-installer/amd64/linux" initrd == "/var/www/cobbler/ks_mirror/Ubuntu-14.04/install/netboot/ubuntu-installer/amd64/initrd.gz" } Argument Reference The following arguments are supported: arch - (Required) The architecture of the distro. Valid options are: i386, x86_64, ia64, ppc, ppc64, s390, arm. breed - (Required) The "breed" of distribution. Valid options are: redhat, fedora, centos, scientic linux, suse, debian, and ubuntu.