Application Hosting on Enterprise Devices

Total Page:16

File Type:pdf, Size:1020Kb

Application Hosting on Enterprise Devices Use the Unused : Application Hosting on Enterprise Devices. UMA SANKAR MOHANTY Technical Leader, Customer Delivery BRKARC-1002 Cisco Webex Teams Questions? Use Cisco Webex Teams to chat with the speaker after the session How 1 Find this session in the Cisco Events Mobile App 2 Click “Join the Discussion” 3 Install Webex Teams or go directly to the team space 4 Enter messages/questions in the team space BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 3 ROCK GARDEN – CHANDIGARH (INDIA) Courtesy : Google Images BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 4 Agenda • The WW(WHAT & WHY) of Containers • KVM Hosting • Let’s Host an APP. • Success Stories • Key Takeaways • Q & A • Appendix BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 5 Agenda • The WW(WHAT & WHY) of Containers • KVM Hosting • Hosting Spectrum • Difference : KVM & LXC • IOS-XE Architecture & Container Networking • Let’s Host an APP. • Success Stories • CASE 1 : Iperf Hosting • CASE 2 : YangSuite • CASE 3 : Docker Application • CASE 4 : Syslog Server • Key Takeaways • Q&A • Appendix BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 6 The WW(WHAT & WHY) of Containers Session Objectives This Session Focuses on : • Brief Overview of Containers on Enterprise Platform • A few success stories of applications running on the IOS-XE Platforms. By the end, I hope everyone in this room gets a better understanding of containers and how to host applications on top of Enterprise Platforms which can be used for the betterment of the Network. BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 8 Virtual Machines vs Containers • Virtual Machine - Includes the application, binaries & libraries along with entire guest OS. • Containers (LXC) - OS level virtualization method for running multiple isolated Linux containers on a single control host. BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 9 Virtual Machines vs Containers Containers are isolated but share OS App 1 App 2 App 3 Bins/ Bins/ VM Bins/ Libs Libs Libs App A1 App 2 p’ App 3 Guest OS Guest OS Guest OS Container Bins/Libs Bins/LibsBins/Lis Bins/Libs Hypervisor (Type2) Container Engine Host OS Host OS Server Server BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 10 What is a Service Container? Service Containers leverage virtualization layer (LXC and KVM) to provision an application hosting environment on Cisco routers/switches. Gives ability to code application/service once and run it everywhere. Cisco Virtual Services: • Example: WAAS, SNORT Third Party Services: • Example: Wireshark, iperf etc. BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 11 Current Application Challenges Not Enough Network Bandwidth Data Reduction Most Data is not interested Filtering Use of Data at the Edge Latency Optimization Computation to be optimized Partitioning Data Normalization Application Simplification Data Redirection based on Content Dynamic Changes Data Timestamping & Algorithm analysis Analytic Support BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 12 Empowering the Edge – Leverage the Network! • Existing hardware Business footprint Applications Management Analytic Systems • No need for IoT separate compute Applications Billing machinery • Integrated security • Reduced latency & bandwidth cost BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 13 KVM Hosting Application Hosting Spectrum Different models for different application needs. Native LXC Docker KVM Type 1 Process • Strict Kernel • Emerging Industry • Any OS Hypervisor • Very Tight Requirements Standard • Complete • Service Module Integration • Good separation Only • Best performance • Linux host OS • VMWare, HyperV, Performance with some normally – Type Zen… security 2 hypervisor BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 15 Application Hosting Spectrum Linux Containers Native LXC Docker KVM Type 1 Process •Strict Kernel •Emerging Industry • AnyOS Hypervisor •Very Tight Requirements Standard •Complete • ServiceModule Integration •Good separation Only •Best Performance performance with • Linux host OS •VMWare, HyperV, some security normally – Type 2 Zen… hypervisor BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 16 Application Hosting Spectrum Cisco Developed IOX & Service Containers Native LXC Docker KVM Type 1 Process •Strict Kernel •Emerging Industry •Any OS Hypervisor •Very Tight Requirements Standard •Complete • ServiceModule Integration •Good • FutureSupport separation Only •Best Performance performance with •Linux host OS •VMWare, HyperV, some security normally – Type 2 Zen… hypervisor BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 17 Application Hosting Spectrum Open IOX & Service Containers Native LXC Docker KVM Type 1 Process •Strict Kernel • Emerging Industry • Any OS Hyperviso •Very Tight Requirements Standard • Complete r Integration • Good • Future Support separation • ServiceModule •Best performance • Linux host OS Only Performance with some normally – Type •VMWare, HyperV, security 2 hypervisor Zen… BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 18 KVM & LXC Types of Applications • Kernel Virtual Machine (KVM) • KVM application is a virtual machine that contains the full OS (kernel and root filesystem) along with the application code and dependencies in a single package. • Linux Container (LXC) • A Container application is a single package of the root file system, application code and dependencies like libraries and native binaries. BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 19 KVM & LXC Application Package The application package consists of several required and optional pieces • A Package Descriptor file describing the information and resources of the application • A Package Configuration file for applying configuration values during provisioning • The binaries, application code, application libraries, virtual disks, root file system, and manifest of the application itself BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 20 Kernel Virtual Machine (KVM) Application • OS kernel • Root file system • Dependent libraries • Language runtimes and Frameworks • Application descriptor file • Application code • Configuration files, scripts, etc BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 21 Linux Container (LXC) Application • Complete root file system • Dependent libraries • Language runtimes and Frameworks • Application descriptor file • Compiled application code Configuration files, scripts, etc BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 22 Which is LightQ1 weight, KVM or LXC ? BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 23 Enterprise Platforms •Catalyst 9000 9300, 9400, 9500 •ISR4K ISR4321, ISR4331, ISR4351, ISR4431, ISR4451 •CSR •ASR1K ASR 1001-X (HX), ASR 1002-X (HX) BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 24 IOS-XE Software Architecture Customer and 3rd Party Cisco Apps (WAAS,Snort) IOSd Applications Control Plane KVM/LXC Virtual Ethernet Linux OS Platform-Specific Data Plane ERSPAN NSH AppNav Internal Services Blade External Services Blade (UCS® E-Series) (UCS) BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 25 Cisco ISR 4400 Series Architecture IOS-XE 25% CPU Service containers live here: 75% CPU Control Plane (1 core) Data Plane Services Plane (3 cores) (6 or 10 cores) FPGE ISC Multigigabit Service Container Fabric SM-X KVM - Hypervisor Service Plane (control plane CPU) NIM BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 26 What do I need to add to an ISR4K system? Memory • Service Containers (currently) REQUIRE additional DRAM beyond the 4GB system default • Additional DRAM beyond 4GB will be available to a KVM application • Example: 8GB DRAM will have 4GB available to Service Containers • Example: 16GB DRAM will have 12GB available to Service Containers Storage • No storage is included by default and applications do not have accessto bootflash. • Options include internal MSATA SSD on 4300 Series, NIM-SSD or NIM-HD on all ISR4K. BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 27 What do I need to add to an CAT9K system? USB External Storage Memory Platform CPU vCPU CPU units M2 SATA USB 3.0 (GB) Storage (GB) (GB) 1 Core Catalyst 9300 2 (25%) 2 7400 NA 120 1 Core Catalyst 9400* 8 2 7400 960 N/A (25%) 1 Core Catalyst 9500* 8 (25%) 2 7400 NA 120 Catalyst 9500 1 Core high-performance* 8 (25%) 2 7400 960 N/A 2 Core Catalyst 9600* 8 (25%) 2 7400 960 NA BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 28 Catalyst 9000 – SSD Storage Cat 9500 Cat 9300/9500 Cat 9400 High Performance USB 3.0 M2 SATA M2 SATA 120GB 240/480/960GB 240/480/960GB Plug into Back Panel removable SUP Back Panel For Local Storage and App Hosting BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 29 Licensing DNA-Advantage licensing is required to enable App Hosting on Cat9K BRKARC-1002 © 2020 Cisco and/or its affiliates. All rights reserved.
Recommended publications
  • Remote Attestation on Light VM
    POLITECNICO DI TORINO Master's Degree in Computer Engineering Master Thesis Remote Attestation on light VM Supervisor prof. Antonio Lioy Candidate Fabio Vallone Accademic Year 2016-2017 To my parents, who helped me during this journey Summary In the last decade Cloud Computing has massively entered the IT world, changing the way services are offered to the final users. One important aspect of Cloud Computing is the needs to provide greater scalability and flexibility and this can be done by using a technique called Virtualization. This enables us to execute different virtualized ambient on a single piece of hardware. Each virtualized ambient can be seen as a node that offers some services to the final users by exchanging information with other nodes. For this reason the ability to trust each other is growing exponentially. This process is called Remote Attestation and it is from this consideration that the thesis work start. When we say that a node is trustworthy, we are saying that we are sure that all the file that are loaded into memory are the ones that are supposed to be loaded. In other word we need to be sure that the code, and in general the files loaded on that node, have not been tampered by anyone in order to produce a different behaviour of the node. It is important to note that we are not checking in anyway that the behaviour of the machine is logically correct, but we are simply checking that no one has modified it, so bug and logical error can still occurs in the code.
    [Show full text]
  • A Study on the Evaluation of HPC Microservices in Containerized Environment
    ReceivED XXXXXXXX; ReVISED XXXXXXXX; Accepted XXXXXXXX DOI: xxx/XXXX ARTICLE TYPE A Study ON THE Evaluation OF HPC Microservices IN Containerized EnVIRONMENT DeVKI Nandan Jha*1 | SaurABH Garg2 | Prem PrAKASH JaYARAMAN3 | Rajkumar Buyya4 | Zheng Li5 | GrAHAM Morgan1 | Rajiv Ranjan1 1School Of Computing, Newcastle UnivERSITY, UK Summary 2UnivERSITY OF Tasmania, Australia, 3Swinburne UnivERSITY OF TECHNOLOGY, AustrALIA Containers ARE GAINING POPULARITY OVER VIRTUAL MACHINES (VMs) AS THEY PROVIDE THE ADVANTAGES 4 The UnivERSITY OF Melbourne, AustrALIA OF VIRTUALIZATION WITH THE PERFORMANCE OF NEAR bare-metal. The UNIFORMITY OF SUPPORT PROVIDED 5UnivERSITY IN Concepción, Chile BY DockER CONTAINERS ACROSS DIFFERENT CLOUD PROVIDERS MAKES THEM A POPULAR CHOICE FOR DEVel- Correspondence opers. EvOLUTION OF MICROSERVICE ARCHITECTURE ALLOWS COMPLEX APPLICATIONS TO BE STRUCTURED INTO *DeVKI Nandan Jha Email: [email protected] INDEPENDENT MODULAR COMPONENTS MAKING THEM EASIER TO manage. High PERFORMANCE COMPUTING (HPC) APPLICATIONS ARE ONE SUCH APPLICATION TO BE DEPLOYED AS microservices, PLACING SIGNIfiCANT RESOURCE REQUIREMENTS ON THE CONTAINER FRamework. HoweVER, THERE IS A POSSIBILTY OF INTERFERENCE BETWEEN DIFFERENT MICROSERVICES HOSTED WITHIN THE SAME CONTAINER (intra-container) AND DIFFERENT CONTAINERS (inter-container) ON THE SAME PHYSICAL host. In THIS PAPER WE DESCRIBE AN Exten- SIVE EXPERIMENTAL INVESTIGATION TO DETERMINE THE PERFORMANCE EVALUATION OF DockER CONTAINERS EXECUTING HETEROGENEOUS HPC microservices. WE ARE PARTICULARLY CONCERNED WITH HOW INTRa- CONTAINER AND inter-container INTERFERENCE INflUENCES THE performance. MoreoVER, WE INVESTIGATE THE PERFORMANCE VARIATIONS IN DockER CONTAINERS WHEN CONTROL GROUPS (cgroups) ARE USED FOR RESOURCE limitation. FOR EASE OF PRESENTATION AND REPRODUCIBILITY, WE USE Cloud Evaluation Exper- IMENT Methodology (CEEM) TO CONDUCT OUR COMPREHENSIVE SET OF Experiments.
    [Show full text]
  • A Comparative Analysis Between Traditional Virtualization and Container Based Virtualization for Advancement of Open Stack Cloud
    ISSN (Online) 2394-2320 International Journal of Engineering Research in Computer Science and Engineering (IJERCSE) Vol 5, Issue 4, April 2018 A Comparative Analysis between Traditional Virtualization and Container Based Virtualization for Advancement of Open Stack Cloud [1] Krishna Parihar, [2] Arjun Choudhary, [3] Vishrant Ojha [1][2] Department of Computer Science and Engineering, Sardar Patel University of police, Security and Criminal Justice, Jodhpur Abstract: - LXD based machine containerized new concept in the virtualization world. Its give performance to the bare metal virtualizations. A Centralized system is accessed through IP and can be scalable on demand as per requirement, Technology that eases the user problem like hardware, as well as software most popular technologies, is known as Cloud Computing. As per enterprise and industries demand cloud computing holds a big part of IT world. An OpenStack is a way to manage public and private cloud computing platform. A Linux Container Hypervisor brings Cloud Computing to the next generation Hypervisor with its features Fast, Simple, Secure. The main goal of this paper is factual calibrate is determine various virtualization technique and performance analysis. Keywords— OpenStack, LXD, Cloud Computing, Virtualization, Container, Hypervisor power their public cloud infrastructure.[2] The core I. INTRODUCTION component of virtualization is Hypervisors. Analysis of structured and consistent data has seen A B. Hypervisor cloud computing technologies have been rapidly devel- It is a software which provides isolation for virtual ma- oping. resources are dynamically enlarged, virtualized as chines running on top of physical hosts. The thin layer of well as feed as a service over the Internet, it permits software that typically provides capabilities to virtual providers to provide users connected to a virtually parti-tioning that runs directly on hardware, It provides a unlimited number of resources i.e.
    [Show full text]
  • Application Container Security Guide
    NIST Special Publication 800-190 Application Container Security Guide Murugiah Souppaya John Morello Karen Scarfone This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-190 C O M P U T E R S E C U R I T Y NIST Special Publication 800-190 Application Container Security Guide Murugiah Souppaya Computer Security Division Information Technology Laboratory John Morello Twistlock Baton Rouge, Louisiana Karen Scarfone Scarfone Cybersecurity Clifton, Virginia This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-190 September 2017 U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary National Institute of Standards and Technology Kent Rochford, Acting Under Secretary of Commerce for Standards and Technology and Acting Director NIST SP 800-190 APPLICATION CONTAINER SECURITY GUIDE Authority This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130. Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority.
    [Show full text]
  • Separating Protection and Management in Cloud Infrastructures
    SEPARATING PROTECTION AND MANAGEMENT IN CLOUD INFRASTRUCTURES A Dissertation Presented to the Faculty of the Graduate School of Cornell University in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy by Zhiming Shen December 2017 c 2017 Zhiming Shen ALL RIGHTS RESERVED SEPARATING PROTECTION AND MANAGEMENT IN CLOUD INFRASTRUCTURES Zhiming Shen, Ph.D. Cornell University 2017 Cloud computing infrastructures serving mutually untrusted users provide se- curity isolation to protect user computation and resources. Additionally, clouds should also support flexibility and efficiency, so that users can customize re- source management policies and optimize performance and resource utiliza- tion. However, flexibility and efficiency are typically limited due to security requirements. This dissertation investigates the question of how to offer flexi- bility and efficiency as well as strong security in cloud infrastructures. Specifically, this dissertation addresses two important platforms in cloud in- frastructures: the containers and the Infrastructure as a Service (IaaS) platforms. The containers platform supports efficient container provisioning and execut- ing, but does not provide sufficient security and flexibility. Different containers share an operating system kernel which has a large attack surface, and kernel customization is generally not allowed. The IaaS platform supports secure shar- ing of cloud resources among mutually untrusted users, but does not provide sufficient flexibility and efficiency. Many powerful management primitives en- abled by the underlying virtualization platform are hidden from users, such as live virtual machine migration and consolidation. The main contribution of this dissertation is the proposal of an approach in- spired by the exokernel architecture that can be generalized to any multi-tenant system to improve security, flexibility, and efficiency.
    [Show full text]
  • Openshift Container Platform 4.6 Architecture
    OpenShift Container Platform 4.6 Architecture An overview of the architecture for OpenShift Container Platform Last Updated: 2021-09-22 OpenShift Container Platform 4.6 Architecture An overview of the architecture for OpenShift Container Platform Legal Notice Copyright © 2021 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, the Red Hat 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 is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
    [Show full text]
  • Master's Thesis
    Containerization of telco cloud applications Samu Toimela School of Electrical Engineering Thesis submitted for examination for the degree of Master of Science in Technology. Espoo 22.05.2017 Thesis supervisor: Prof. Jukka Manner Thesis advisor: M.Sc. Tero Venetjoki aalto university abstract of the school of electrical engineering master’s thesis Author: Samu Toimela Title: Containerization of telco cloud applications Date: 22.05.2017 Language: English Number of pages: 7+56 Department of Communications and Networking Professorship: Communications Engineering Supervisor: Prof. Jukka Manner Advisor: M.Sc. Tero Venetjoki Mobile service providers and manufacturers have moved towards virtualized network functions, because the amount of mobile data traffic has increased a lot during the past few years. Virtual machines offer high flexibility and easier management. They also enable flexible scaling, which makes it easier to respond to the varying traffic patterns during the day. However, the traditional virtual machines contain overhead and have reduced performance in most of the operations. One high performing alternative to a virtual machine is a Linux container. Linux containers do not contain additional operating system or any unnecessary services. Containers are isolated user spaces which share host computer’s kernel. This makes processes inside them perform almost as well as if they would be running directly on host. Also, the startup time of containers is extremely fast compared to virtual machines. This thesis studies, if Linux containers are suitable for telco applications. The research is conducted via proof-of-concept where parts of an existing telco appli- cation are moved to containers. First, the container technology and related tools are discussed.
    [Show full text]
  • Security of Containers
    Security of Containers Shruti Kulkarni About myself • Enterprise Security Architect • 12+ years of experience in Information Security • Experience with security frameworks like ISO27001 and PCI-DSS • Policies, Processes and Technology • CISA, CRISC, CISSP, CCSK, ITILv3 • Architecture, Design, Implementation and Maintenance of security systems What are containers? • An application container is a mechanism that is used to isolate applications from each other within the context of a running operating system instance. – Conceptually, an application container is similar to a jail filesystem. When configured to do so, applications contained within a container cannot access components outside of the established boundary. – A container has a segmented network stack, process space and instance of a filesystem – A container shares the operating system with other containers that are running on the host • Containers like any other asset need to be assured for security Uses of containers • Malware analysis • Easier deployment of repetitive jobs • Micro-services • Deployments to hybrid cloud, multi- cloud Background of containers Background • Linuxfeatures – – file system root its change to aprocess allows – chroot – Namespaces • • • • • • • thehostname theNISand domainname identifiers: twosystem isolationof provide UTS– hostsand containers andhostids between user Separates ids – User system the file host affecting without Mountmount–and systemsunmount file stack network Separates – Network communication IPCInter-process – sub-processes isolated of
    [Show full text]
  • Flatcar Container Linux Datasheet
    Datasheet: Flatcar Container Linux Why Container Linux? Modern applications are increasingly deployed as containers. Hence, enterprises need a reliable, secure foundation for those applications that can be managed at scale. Traditional enterprise Linux distributions are not well suited to this task. This is where Flatcar Container Linux comes in: Container Optimized Flatcar Container Linux is designed for containerized applications. ❏ It comes with a minimal set of components required to deploy containers, including a modern Linux kernel and the Docker container engine. ❏ Packages such as language runtimes are already bundled in container images, so are not included at the host level. ❏ Many typical Linux tools are included in a utilities container. Automated Updates Flatcar Container Linux discovers when updates are available, and can apply them automatically, ensuring the entire fleet is always up to date. For system administrators wanting more control, the Kinvolk Update Service enables update policy controls. Secure by Design Flatcar Container Linux can play a key role in your security strategy. ❏ As a minimal Linux distribution, the potential attack surface area is minimized. ❏ Flatcar has an immutable file system. This eliminates a whole class of vulnerabilities. ❏ Automatic updates ensure security patches are always up to date. Seamless Migration from CoreOS In the best traditions of the open source community, Flatcar Container Linux was created as a fork of CoreOS Container Linux, itself derived from Gentoo and ChromeOS. This ensures a seamless migration path — an in-place upgrade from ​ CoreOS to Flatcar is no more intrusive than a regular CoreOS version update. Even your existing configuration files will continue to work.
    [Show full text]
  • IBM Cloud Private System Administrator S Guide
    Front cover IBM Cloud Private System Administrator’s Guide Ahmed Azraq Wlodek Dymaczewski Fernando Ewald Luca Floris Rahul Gupta Vasfi Gucer Anil Patil Sanjay Singh Sundaragopal Venkatraman Dominique Vernier Zhi Min Wen In partnership with IBM Academy of Technology Redbooks IBM Redbooks IBM Cloud Private System Administrator’s Guide April 2019 SG24-8440-00 Note: Before using this information and the product it supports, read the information in “Notices” on page ix. First Edition (April 2019) This edition applies to IBM Cloud Private Version 3.1.2. © Copyright International Business Machines Corporation 2019. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . ix Trademarks . .x Preface . xi Authors. xii Now you can become a published author, too . .xv Comments welcome. xvi Stay connected to IBM Redbooks . xvi Part 1. IBM Cloud Private overview, architecture, and installation . 1 Chapter 1. Introduction to IBM Cloud Private. 3 1.1 IBM Cloud Private overview . 4 1.2 IBM Cloud Private node types. 6 1.2.1 Boot node . 6 1.2.2 Master node . 7 1.2.3 Worker node . 7 1.2.4 Management node . 8 1.2.5 Proxy node . 8 1.2.6 VA (Vulnerability Advisor) node . 9 1.2.7 An etcd node. 10 1.3 IBM Cloud Private architecture . 10 1.4 IBM Cloud Private features and benefits. 12 1.4.1 A unified installer. 12 1.4.2 Robust logging with ELK stack . 12 1.4.3 Monitoring and alerts .
    [Show full text]
  • Workshop Lpi Devops Tools
    WORKSHOP LPI DEVOPS TOOLS 15:35h a 16:40h Integración y despliegue continuo mediante contenedores Docker sobre Kubernetes, Openshift y Jenkins Ponente: Sergio Rodríguez de Guzmán, CTO at PUE LPI Certification Programs Changes in the last years ● [ Tagcloud ] So what? ● What does that mean for you? ● What does that mean for our candidates? ● How long will we need the Jack-of-all-trades sysadmin? ● Is it worth investing time in learning these things? ● To answer this we have to discover ... ○ … what these buzzwords really mean ○ … what their technological impact is ○ … how we can embrace the relevant portion of these tools ● Let’s take a tour through DevOps Tools Land! HOW IT USED TO BE 5 The (not so) old days ● Companies buy computers / servers ○ Probably put some virtualization on them ○ Admins install os / prepare and enroll templates ○ New servers / VMs require manual configuration ○ There is usually a process for new servers / VMs ● Software is packaged with installation routines ○ Packages tend to be large ○ Specific requirements on the runtime environment ○ Conflicts with other installed software possible ○ Post-installation configuration required The (not so) old days ● Implications ○ Admins do a lot of repetitive, boring work ○ Setting up new servers / VMs is hard ■ Testing systems live long ■ Prod / Dev parity ○ Updates / releases require downtime and work ■ Releases are risky and complicated ■ Bugs require time to get fixed ■ Large releases ○ It’s all about servers ■ Stored data ■ “Nursing” sick servers back to health Devs and Ops ● Administrators and Developers have contradictory requirements: ○ Daily fresh testing systems vs. repetitive work ○ Frequent deployments vs. uptime ○ Blaming platforms vs.
    [Show full text]
  • Host Configuration Guide
    Red Hat Satellite 6.2 Host Configuration Guide A guide to managing hosts in a Red Hat Satellite 6 environment. Edition 1.0 Last Updated: 2018-06-25 Red Hat Satellite 6.2 Host Configuration Guide A guide to managing hosts in a Red Hat Satellite 6 environment. Edition 1.0 Red Hat Satellite Documentation Team [email protected] Legal Notice Copyright © 2016 Red Hat. This document is licensed by Red Hat under the Creative Commons Attribution- ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed. 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.
    [Show full text]