DOCSLIB.ORG

Openshift Container Platform Technical Overview

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

OPENSHIFT CONTAINER PLATFORM TECHNICAL OVERVIEW Presenter Presenter’s title Date Self-Service Standards-based Multi-language Web-scale Automation Open Source Collaboration Enterprise Grade Multi-tenant Secure 2 OPENSHIFT TECHNICAL OVERVIEW OPENSHIFT ARCHITECTURE c 3 OPENSHIFT TECHNICAL OVERVIEW LINUX CONTAINERS WHAT ARE CONTAINERS? It Depends Who You Ask INFRASTRUCTURE APPLICATIONS ● Application processes on a shared kernel ● Package apps with all dependencies ● Simpler, lighter, and denser than VMs ● Deploy to any environment in seconds ● Portable across different environments ● Easily accessed and shared 5 OPENSHIFT TECHNICAL OVERVIEW VIRTUAL MACHINES AND CONTAINERS VIRTUAL MACHINES CONTAINERS VM Container Container Container Container App App App App App App App App OS Dependencies OS deps OS deps OS deps OS deps Kernel Container Host (Kernel) Hypervisor Hardware Hardware virtual machines are isolated containers are isolated apps are not so are the apps 6 OPENSHIFT TECHNICAL OVERVIEW VIRTUAL MACHINES AND CONTAINERS Virtual Machine Container Application Application OS dependencies OS dependencies Operating System Container Host VM Isolation Container Isolation Complete OS Shared Kernel Static Compute Burstable Compute Static Memory Burstable Memory High Resource Usage Low Resource Usage 7 OPENSHIFT TECHNICAL OVERVIEW VIRTUAL MACHINES AND CONTAINERS Virtual Machine Container Application Clear ownership boundary Application Dev IT Ops OS dependencies between Dev and IT Ops OS dependencies (and Dev, sort of) drives DevOps adoption Operating System and fosters agility Container Host IT Ops Infrastructure Infrastructure Optimized for stability Optimized for agility 8 OPENSHIFT TECHNICAL OVERVIEW APPLICATION PORTABILITY WITH VM Virtual machines are NOT portable across hypervisor and do NOT provide portable packaging for applications Guest VM VM Type X VM Type Y VM Type Z Application Application Application Application Application OS dependencies OS dependencies OS dependencies OS dependencies OS dependencies Operating System Operating System Operating System Operating System Operating System LAPTOP BARE METAL VIRTUALIZATION PRIVATE CLOUD PUBLIC CLOUD 9 OPENSHIFT TECHNICAL OVERVIEW APPLICATION PORTABILITY WITH CONTAINERS RHEL Containers + RHEL Host = Guaranteed Portability Across Any Infrastructure Container Container Container Container Container Application Application Application Application Application OS dependencies OS dependencies OS dependencies OS dependencies OS dependencies RHEL RHEL RHEL RHEL RHEL Guest VM Virtual Machine Virtual Machine Virtual Machine LAPTOP BARE METAL VIRTUALIZATION PRIVATE CLOUD PUBLIC CLOUD 10 OPENSHIFT TECHNICAL OVERVIEW RAPID SECURITY PATCHING USING CONTAINER IMAGE LAYERING Image Layer 3 Application Layer Image Layer 2 Java Runtime Layer Image Layer 1 OS Update Layer Base Image Base RHEL Container Image Layers Example Container Image 11 OPENSHIFT TECHNICAL OVERVIEW A lightweight, OCI-compliant container runtime Any OCI-compliant Optimized for container from any Improve Security and Kubernetes OCI registry Performance at scale (including docker) Available in OpenShift Online (soon) Tech Preview in OCP 3.7, GA in OCP 3.8 12 OPENSHIFT TECHNICAL OVERVIEW OPENSHIFT ARCHITECTURE YOUR CHOICE OF INFRASTRUCTURE 14 OPENSHIFT TECHNICAL OVERVIEW NODES RHEL INSTANCES WHERE APPS RUN 15 OPENSHIFT TECHNICAL OVERVIEW APPS RUN IN CONTAINERS c 16 OPENSHIFT TECHNICAL OVERVIEW PODS ARE THE UNIT OF ORCHESTRATION c 17 OPENSHIFT TECHNICAL OVERVIEW MASTERS ARE THE CONTROL PLANE 18 OPENSHIFT TECHNICAL OVERVIEW API AND AUTHENTICATION 19 OPENSHIFT TECHNICAL OVERVIEW DESIRED AND CURRENT STATE 20 OPENSHIFT TECHNICAL OVERVIEW INTEGRATED CONTAINER REGISTRY 21 OPENSHIFT TECHNICAL OVERVIEW ORCHESTRATION AND SCHEDULING 22 OPENSHIFT TECHNICAL OVERVIEW PLACEMENT BY POLICY c 23 OPENSHIFT TECHNICAL OVERVIEW AUTOSCALING PODS c 24 OPENSHIFT TECHNICAL OVERVIEW SERVICE DISCOVERY c 25 OPENSHIFT TECHNICAL OVERVIEW PERSISTENT DATA IN CONTAINERS c 26 OPENSHIFT TECHNICAL OVERVIEW ROUTING AND LOAD-BALANCING c 27 OPENSHIFT TECHNICAL OVERVIEW ACCESS VIA WEB, CLI, IDE AND API c 28 OPENSHIFT TECHNICAL OVERVIEW TECHNICAL DEEP DIVE MONITORING APPLICATION HEALTH AUTO-HEALING FAILED PODS c c 31 OPENSHIFT TECHNICAL OVERVIEW AUTO-HEALING FAILED CONTAINERS c c 32 OPENSHIFT TECHNICAL OVERVIEW AUTO-HEALING FAILED CONTAINERS c c 33 OPENSHIFT TECHNICAL OVERVIEW AUTO-HEALING FAILED CONTAINERS c c 34 OPENSHIFT TECHNICAL OVERVIEW AUTO-HEALING FAILED CONTAINERS c c 35 OPENSHIFT TECHNICAL OVERVIEW NETWORKING BUILT-IN SERVICE DISCOVERY INTERNAL LOAD-BALANCING 37 OPENSHIFT TECHNICAL OVERVIEW BUILT-IN SERVICE DISCOVERY INTERNAL LOAD-BALANCING 38 OPENSHIFT TECHNICAL OVERVIEW ROUTE EXPOSES SERVICES EXTERNALLY 39 OPENSHIFT TECHNICAL OVERVIEW ROUTING AND EXTERNAL LOAD-BALANCING ● Pluggable routing architecture ○ HAProxy Router ○ F5 Router ● Multiple-routers with traffic sharding ● Router supported protocols ○ HTTP/HTTPS ○ WebSockets ○ TLS with SNI ● Non-standard ports via cloud load-balancers, external IP, and NodePort 40 OPENSHIFT TECHNICAL OVERVIEW ROUTE SPLIT TRAFFIC Split Traffic Between Multiple Services For A/B Testing, Blue/Green and Canary Deployments 41 OPENSHIFT TECHNICAL OVERVIEW EXTERNAL TRAFFIC TO A SERVICE ON A RANDOM PORT WITH NODEPORT ● NodePort binds a service to a unique port on all the nodes ● Traffic received on any node redirects to a node with the running service ● Ports in 30K-60K range which usually differs from the service ● Firewall rules must allow traffic to all nodes on the specific port 42 OPENSHIFT TECHNICAL OVERVIEW EXTERNAL TRAFFIC TO A SERVICE ON ANY PORT WITH INGRESS ● Access a service with an external IP on any TCP/UDP port, such as ○ Databases ○ Message Brokers ● Automatic IP allocation from a predefined pool using Ingress IP Self-Service ● IP failover pods provide high availability for the IP pool 43 OPENSHIFT TECHNICAL OVERVIEW CONTROL OUTGOING TRAFFIC SOURCE IP WITH EGRESS ROUTER 44 OPENSHIFT TECHNICAL OVERVIEW OPENSHIFT NETWORKING ● Built-in internal DNS to reach services by name ● Split DNS is supported via SkyDNS ○ Master answers DNS queries for internal services ○ Other nameservers serve the rest of the queries ● Software Defined Networking (SDN) for a unified cluster network to enable pod-to-pod communication ● OpenShift follows the Kubernetes Container Networking Interface (CNI) plug-in model 45 OPENSHIFT TECHNICAL OVERVIEW OPENSHIFT NETWORK PLUGINS * Flannel is minimally verified and is supported only and exactly as deployed in the OpenShift on OpenStack reference architecture 46 OPENSHIFT TECHNICAL OVERVIEW OPENSHIFT NETWORKING 47 OPENSHIFT TECHNICAL OVERVIEW OPENSHIFT SDN FLAT NETWORK (Default) ● All pods can communicate with each other across projects MULTI-TENANT NETWORK NODE NODE ● Project-level network isolation POD POD POD POD ● Multicast support ● Egress network policies POD POD POD POD NETWORK POLICY (Tech Preview) ● Granular policy-based isolation 48 OPENSHIFT TECHNICAL OVERVIEW OPENSHIFT SDN - NETWORK POLICY Example Policies ● Allow all traffic inside the project ● Allow traffic from green to gray ● Allow traffic to purple on 8080 apiVersion: extensions/v1beta1 kind: NetworkPolicy metadata: name: allow-to-purple-on-8080 spec: podSelector: matchLabels: color: purple ingress: - ports: - protocol: tcp port: 8080 49 OPENSHIFT TECHNICAL OVERVIEW OPENSHIFT SDN - OVS PACKET FLOW Container to Container on the Same Host 50 OPENSHIFT TECHNICAL OVERVIEW OPENSHIFT SDN - OVS PACKET FLOW Container to Container on the Different Hosts 51 OPENSHIFT TECHNICAL OVERVIEW OPENSHIFT SDN - OVS PACKET FLOW Container Connects to External Host 52 OPENSHIFT TECHNICAL OVERVIEW OPENSHIFT SDN WITH FLANNEL FOR OPENSTACK Flannel is minimally verified and is supported only and exactly as deployed in the OpenShift on OpenStack reference architecture https://access.redhat.com/articles/2743631 53 OPENSHIFT TECHNICAL OVERVIEW LOGGING & METRICS CENTRAL LOG MANAGEMENT WITH EFK ● EFK stack to aggregate logs for hosts and applications ○ Elasticsearch: an object store to store all logs ○ Fluentd: gathers logs and sends to Elasticsearch. ○ Kibana: A web UI for Elasticsearch. ● Access control ○ Cluster administrators can view all logs ○ Users can only view logs for their projects ● Ability to send logs elsewhere ○ External elasticsearch, Splunk, etc 55 OPENSHIFT TECHNICAL OVERVIEW CENTRAL LOG MANAGEMENT WITH EFK NODE POD POD NODE ELASTIC ELASTIC POD POD FLUENTD ELASTIC ELASTIC POD POD RHELNODE POD POD FLUENTD POD POD ELASTIC ELASTIC RHEL ELASTIC ELASTIC POD POD FLUENTD RHEL 56 OPENSHIFT TECHNICAL OVERVIEW CONTAINER METRICS 57 OPENSHIFT TECHNICAL OVERVIEW CONTAINER METRICS NODE POD POD NODE POD POD FLUENTD POD POD RHELNODE POD POD FLUENTD POD POD ELASTIC ELASTIC RHEL POD POD CADVISOR RHEL 58 OPENSHIFT TECHNICAL OVERVIEW SECURITY TEN LAYERS OF CONTAINER SECURITY Container Host & Multi-tenancy Federated Clusters Container Platform API Management Network Isolation Deploying Container Container Registry Container Content Storage Building Containers 60 OPENSHIFT TECHNICAL OVERVIEW SECRET MANAGEMENT ● Secure mechanism for holding sensitive data e.g. ○ Passwords and credentials ○ SSH Keys ○ Certificates ● Secrets are made available as ○ Environment variables ○ Volume mounts ○ Interaction with external systems ● Encrypted in transit ● Never rest on the nodes 61 OPENSHIFT TECHNICAL OVERVIEW PERSISTENT STORAGE PERSISTENT STORAGE ● Persistent Volume (PV) is tied to a piece of network storage ● Provisioned by an administrator (static or dynamically) ● Allows admins
Recommended publications
  • Open Virtualization Infrastructure for Large Telco: How Turkcell Adopted Ovirt for Its Test and Development Environments

    Open Virtualization Infrastructure for Large Telco: How Turkcell Adopted Ovirt for Its Test and Development Environments

    Open Virtualization Infrastructure for large Telco: How Turkcell adopted oVirt for its test and development environments DEVRIM YILMAZ SAYGIN BAKTIR Senior Expert Cloud Engineer Cloud Systems Administrator 09/2020 This presentation is licensed under a Creative Commons Attribution 4.0 International License About Turkcell ● Turkcell is a digital operator headquartered in Turkey ● Turkcell Group companies operate in 5 countries – Turkey, Ukraine, Belarus, Northern Cyprus, Germany ● Turkcell is the only NYSE-listed company in Turkey. ● www.turkcell.com.tr 3 Business Objectives ● Alternative solutions compatible with Turkcell operational and security standards ● Dissemination of open source infrastructure technologies within the company ● Competitive infrastructure with cost advantage 3 The journey of oVirt 4 The Journey of oVirt 3. Step three 1. Research & 2. Go-Live 3. Go-Live 4. Private Cloud 5. Go-Live Development Phase-1 Phase-2 Automation RHV 5 Research & Development ● Motivation Factors ○ Cost 1. Research & ○ Participation Development ○ Regulation ○ Independence ○ Expertise ● Risk Factors ○ Security ○ Quality ○ Compliance ○ Support ○ Worst Practices 6 Research & Development ● Why oVirt? ○ Open Source licensing 1. Research & ○ Community contribution Development ○ The same roadmap with commercial product ○ Support via subscription if required ○ Adequate features for enterprise management ○ Rest API support 6 Research & Development ● Difficulties for new infra solution ○ Integration with current infrastructure 1. Research & - Centralized Management Development - Certified/Licensed Solutions - Integration Cost ○ Incident & Problem Management - 3rd Party Support - Support with SLA ○ Acquired Habits - Customer Expectations - Quality of IT Infrastructure Services 6 Research & Development ● What we achieved ○ Building of PoC environment 1. Research & ○ V2V Migration Development ○ Upgrade Tests starting with v.4.3.2 ○ Functional Tests ○ Backup Alternative Solutions 6 Go-Live Phase-1 ● Phase-1 contains : ○ Building of new oVirt platform with unused h/w 2.
  • Red Hat Enterprise Linux 7 Libreswan Cryptographic Module Version 7.0 and Version Rhel7.20190509 FIPS 140-2 Non-Proprietary Security Policy

    Red Hat Enterprise Linux 7 Libreswan Cryptographic Module Version 7.0 and Version Rhel7.20190509 FIPS 140-2 Non-Proprietary Security Policy

    Red Hat Enterprise Linux 7 Libreswan Cryptographic Module version 7.0 and version rhel7.20190509 FIPS 140-2 Non-Proprietary Security Policy Version 1.3 Last update: 2021-05-03 Prepared by: atsec information security corporation 9130 Jollyville Road, Suite 260 Austin, TX 78759 www.atsec.com ©2021 Red Hat®, Inc. / atsec information security corporation Page 1 of 23 This document can be reproduced and distributed only whole and intact, including this copyright notice. Red Hat Enterprise Linux 7 Libreswan Cryptographic Module FIPS 140-2 Non-Proprietary Security Policy Table of contents 1 Introduction ........................................................................................................................... 3 2 Cryptographic Module Specification ...................................................................................... 4 2.1 Module Overview ......................................................................................................... 4 2.2 FIPS 140-2 Validation ................................................................................................... 5 2.3 Modes of Operation ...................................................................................................... 6 3 Cryptographic Module Ports and Interfaces ........................................................................... 7 4 Roles, Services and Authentication ....................................................................................... 8 4.1 Roles ...........................................................................................................................
  • Clouder Documentation Release 1.0

    Clouder Documentation Release 1.0

    Clouder Documentation Release 1.0 Yannick Buron May 15, 2017 Contents 1 Getting Started 3 1.1 Odoo installation.............................................3 1.2 Clouder configuration..........................................4 1.3 Services deployed by the oneclick....................................6 2 Connect to a new node 9 3 Images 13 4 Applications 15 4.1 Application Types............................................ 15 4.2 Application................................................ 16 5 Services 21 6 Domains and Bases 25 6.1 Domains................................................. 25 6.2 Bases................................................... 27 7 Backups and Configuration 31 7.1 Backups................................................. 31 7.2 Configuration............................................... 33 i ii Clouder Documentation, Release 1.0 Contents: Contents 1 Clouder Documentation, Release 1.0 2 Contents CHAPTER 1 Getting Started In this chapter, we’ll see a step by step guide to install a ready-to-use infrastructure. For the example, the base we will create will be another Clouder. Odoo installation This guide will not cover the Odoo installation in itself, we suggest you read the installation documentation on the official website. You can also, and it’s probably the easier way, use an Odoo Docker image like https://hub.docker.com/ _/odoo/ or https://hub.docker.com/r/tecnativa/odoo-base/ Due to the extensive use of ssh, Clouder is only compatible with Linux. Once your Odoo installation is ready, install the paramiko, erppeek and apache-libcloud python libraries (pip install paramiko erppeek apache-libcloud), download the OCA/Connector module on Github and the Clouder modules on Github and add them in your addons directory, then install the clouder module and clouder_template_odoo (this module will install a lot of template dependencies, like postgres, postfix etc...).
  • Of the Cloudtracker®

    Of the Cloudtracker®

    DIGITAL BANKS AND THE POWER OF THE CLOUD TRACKER® AUGUST 2020 How Holvi is Australian online-only Xinja Why the pandemic is pushing leveraging Kubernetes Bank turns to Kubernetes banks to go cloud-native for seamless service to enhance its mobile Page 8 banking features Page 19 FEATURE STORY Page 13 DEEP DIVE NEWS AND TRENDS TABLE OF CONTENTS 03 WHAT’S INSIDE Recent cloud and digital banking developments, such as why banks need to examine their container orchestration and Kubernetes investments as well as why the Royal Bank of Canada is employing AI and private cloud technology to accelerate its software innovation 08 FEATURE STORY An interview with Andrew Smith, director of technical operations for Finnish banking service Holvi, on why Kubernetes’ speed and scalability are essential to helping FIs swiftly deploy services for customers NEWS AND TRENDS 13 The latest cloud banking headlines, including why Australian business banking FinTech Tyro is using the cloud to upgrade its infrastructure and why Singapore’s Asia Digital Bank Corporation is leveraging the cloud to better contend for one of the region’s digital banking licenses DEEP DIVE 19 ACKNOWLEDGMENT An in-depth look at how the ongoing The Digital Banks And The Power Of The pandemic is pushing banks onto cloud-native ® Cloud Tracker was done in collaboration digital infrastructure and how systems like with NuoDB, and PYMNTS is grateful for the company’s support and insight. PYMNTS.com Kubernetes will prove essential for this move retains full editorial control over the following findings, methodology and data analysis. 23 ABOUT Information on PYMNTS.com and NuoDB WHAT’S INSIDE pproximately half a year has passed since the COVID-19 pandemic was declared and banks have largely determined how to continue their oper- ations as the industry faces significant challenges.
  • Deploying Netapp HCI for Red Hat Openshift on RHV HCI Netapp September 23, 2021

    Deploying Netapp HCI for Red Hat Openshift on RHV HCI Netapp September 23, 2021

    Deploying NetApp HCI for Red Hat OpenShift on RHV HCI NetApp September 23, 2021 This PDF was generated from https://docs.netapp.com/us-en/hci- solutions/redhat_openshift_deployment_summary.html on September 23, 2021. Always check docs.netapp.com for the latest. Table of Contents Deploying NetApp HCI for Red Hat OpenShift on RHV . 1 Deployment Summary: NetApp HCI for Red Hat OpenShift on RHV . 1 1. Create Storage Network VLAN: NetApp HCI for Red Hat OpenShift on RHV. 1 2. Download OpenShift Installation Files: NetApp HCI for Red Hat OpenShift on RHV . 2 3. Download CA Certificate from RHV: NetApp HCI for Red Hat OpenShift on RHV . 4 4. Register API/Apps in DNS: NetApp HCI for Red Hat OpenShift on RHV . 5 5. Generate and Add SSH Private Key: NetApp HCI for Red Hat OpenShift on RHV. 7 6. Install OpenShift Container Platform: NetApp HCI for Red Hat OpenShift on RHV . 8 7. Access Console/Web Console: NetApp HCI for Red Hat OpenShift on RHV . 10 8. Configure Worker Nodes to Run Storage Services: NetApp HCI for Red Hat OpenShift on RHV. 11 9. Download and Install NetApp Trident: NetApp HCI for Red Hat OpenShift on RHV . 13 Deploying NetApp HCI for Red Hat OpenShift on RHV Deployment Summary: NetApp HCI for Red Hat OpenShift on RHV The detailed steps provided in this section provide a validation for the minimum hardware and software configuration required to deploy and validate the NetApp HCI for Red Hat OpenShift on RHV solution. Deploying Red Hat OpenShift Container Platform through IPI on Red Hat Virtualization consists of the following steps: 1.
  • 8. IBM Z and Hybrid Cloud

    8. IBM Z and Hybrid Cloud

    The Centers for Medicare and Medicaid Services The role of the IBM Z® in Hybrid Cloud Architecture Paul Giangarra – IBM Distinguished Engineer December 2020 © IBM Corporation 2020 The Centers for Medicare and Medicaid Services The Role of IBM Z in Hybrid Cloud Architecture White Paper, December 2020 1. Foreword ............................................................................................................................................... 3 2. Executive Summary .............................................................................................................................. 4 3. Introduction ........................................................................................................................................... 7 4. IBM Z and NIST’s Five Essential Elements of Cloud Computing ..................................................... 10 5. IBM Z as a Cloud Computing Platform: Core Elements .................................................................... 12 5.1. The IBM Z for Cloud starts with Hardware .............................................................................. 13 5.2. Cross IBM Z Foundation Enables Enterprise Cloud Computing .............................................. 14 5.3. Capacity Provisioning and Capacity on Demand for Usage Metering and Chargeback (Infrastructure-as-a-Service) ................................................................................................................... 17 5.4. Multi-Tenancy and Security (Infrastructure-as-a-Service) .......................................................
  • Paas Solutions Evaluation

    Paas Solutions Evaluation

    PaaS solutions evaluation August 2014 Author: Sofia Danko Supervisors: Giacomo Tenaglia Artur Wiecek CERN openlab Summer Student Report 2014 CERN openlab Summer Student Report 2014 Project Specification OpenShift Origin is an open source software developed mainly by Red Hat to provide a multi- language PaaS. It is meant to allow developers to build and deploy their applications in a uniform way, reducing the configuration and management effort required on the administration side. The aim of the project is to investigate how to deploy OpenShift Origin at CERN, and to which extent it could be integrated with CERN "Middleware on Demand" service. The student will be exposed to modern cloud computing concepts such as PaaS, and will work closely with the IT middleware experts in order to evaluate how to address service needs with a focus on deployment in production. Some of the tools that are going to be heavily used are Puppet and Openstack to integrate with the IT infrastructure. CERN openlab Summer Student Report 2014 Abstract The report is a brief summary of Platform as a Service (PaaS) solutions evaluation including investigation the current situation at CERN and Services on Demand provision, homemade solutions, external market analysis and some information about PaaS deployment process. This first part of the report is devoted to the current status of the process of deployment OpenShift Origin at existing infrastructure at CERN, as well as specification of the common issues and restrictions that were found during this process using different machines for test. Furthermore, the following open source software solutions have been proposed for the investigation of possible PaaS provision at CERN: OpenShift Online; Cloud Foundry; Deis; Paasmaster; Cloudify; Stackato; WSO2 Stratos.
  • Red Hat Openshift Container Platform 3.6

    Red Hat Openshift Container Platform 3.6

    RED HAT OPENSHIFT CONTAINER PLATFORM 3.6 DATASHEET KEY BENEFITS OVERVIEW • Deliver your latest innova- Red Hat® OpenShift Container Platform helps organizations develop, deploy, and manage exist- tion to market faster and stay ing and container-based applications seamlessly across physical, virtual, and public cloud infra- ahead of your competition. structures. Built on proven open source technologies, Red Hat OpenShift Container Platform helps application development and IT operations teams modernize applications, deliver new services, and • Accelerate application accelerate development processes. development by giving your developers and system admin- RED HAT OPENSHIFT CONTAINER PLATFORM istrators the tools they need FOR APPLICATION DEVELOPMENT TEAMS to get the job done. OpenShift Container Platform provides developers with an optimal platform for provisioning, build- • Use a secure, enterprise- ing, and deploying applications and their components in a self-service fashion. With automated grade, container-based workflows like our source-to-image (S2I) process, it is easy to get source code from version control platform with no vendor systems into ready-to-run, docker-formatted container images. OpenShift Container Platform inte- lock-in. grates with continuous integration (CI) and continuous delivery (CD) tools, making it an ideal solution • Support DevOps and depart- for any organization. ment-wide collaboration. FOR I.T. OPERATIONS OpenShift Container Platform gives IT operations a secure, enterprise-grade Kubernetes that pro- Red Hat OpenShift Online vides policy-based control and automation for applications. Cluster services, scheduling, and orches- is a public cloud application tration provide load-balancing and auto-scaling capabilities. Security features prevent tenants from platform that lets you quickly compromising other applications or the underlying host.
  • Openshift Vs Pivotal Cloud Foundry Comparison Red Hat Container Stack - Pivotal Cloud Foundry Stack

    Openshift Vs Pivotal Cloud Foundry Comparison Red Hat Container Stack - Pivotal Cloud Foundry Stack

    OPENSHIFT VS PIVOTAL CLOUD FOUNDRY COMPARISON RED HAT CONTAINER STACK - PIVOTAL CLOUD FOUNDRY STACK 3 AT A GLANCE PIVOTAL CF OPENSHIFT • ●Garden and Diego • ●Docker and Kubernetes • ●.NET and Spring • ●.NET, Spring and JBoss Middleware • ●Only Cloud-native apps (including full Java EE) • ●Container security on Ubuntu • ●Cloud-native and stateful apps • ●Deployment automation • ●Enterprise-grade security on • ●Open Core Red Hat Enterprise Linux • ●Pivotal Labs consulting method • ●Complete Ops Management • ●100% Open Source 5X PRICE • ●Red Hat Innovation Labs consulting method BRIEF COMPARISON PIVOTAL CF OPENSHIFT GARDEN & DIEGO DOCKER & KUBERNETES • ●Garden uses OCI runC backend • ●Portable across all docker platforms • ●Not portable across Cloud Foundry distros • ●IP per container • ●Containers share host IP • ●Integrated image registry • ●No image registry • ●Image build from source and binary • ●Private registries are not supported • ●Adoption in many solutions • ●No image build • ●Adoption only in Cloud Foundry 11 NO NATIVE DOCKER IN CLOUD FOUNDRY Converters Are Terrible Cloud Foundry is based on the Garden container runtime, not Docker, and then has RunC and Windows backends. RunC is not Docker, just the lowest runtime layer Docker Developer Experience Does Not Exist in PCF PCF “cf push” Dev Experience does not exist for Docker. In Openshift v3 we built S2I to provide that same experience on top of native Docker images/containers Diego Is Not Kubernetes Kubernetes has become the defacto standard for orchestrating docker containers.
  • Forrester: Multicloud Container Development Platforms, Q3 2020

    Forrester: Multicloud Container Development Platforms, Q3 2020

    LICENSED FOR INDIVIDUAL USE ONLY The Forrester Wave™: Multicloud Container Development Platforms, Q3 2020 The Eight Providers That Matter Most And How They Stack Up by Dave Bartoletti and Charlie Dai September 15, 2020 Why Read This Report Key Takeaways In our 29-criterion evaluation of multicloud Red Hat-IBM, Google, And Rancher Lead The container development platform providers, we Pack identified the eight most significant ones — Forrester’s research uncovered a market in which Canonical, D2iQ, Google, Mirantis, Platform9 Red Hat-IBM, Google, and Rancher are Leaders; Systems, Rancher, Red Hat-IBM, VMware — VMware, D2iQ, and Platform9 Systems are and researched, analyzed, and scored them. Strong Performers; and Mirantis and Canonical This report shows how each provider measures are Contenders. up and helps infrastructure and operations Dev Experience, Distributed Operations, And professionals select the right one for their needs. Ecosystem Integrations Are Key Differentiators As developers and technology teams race to meet the demand for cloud-native applications, developer experience and development services, distributed infrastructure operations, and rich ecosystem partnerships and integrations will dictate which platform providers will lead the pack. This PDF is only licensed for individual use when downloaded from forrester.com or reprints.forrester.com. All other distribution prohibited. FORRESTER.COM FOR INFRASTRUCTURE & OPERATIONS PROFESSIONALS The Forrester Wave™: Multicloud Container Development Platforms, Q3 2020 The Eight Providers
  • HTAP WP.Indd

    HTAP WP.Indd

    Hybrid Transaction and Analytical Processing with NuoDB Whitepaper Core Tech Technical Whitepaper Hybrid Transaction and Analytical Processing with NuoDB Abstract NuoDB is a distributed SQL database management system that provides a simpler, more cost effective, and ultimately higher-scale approach to hybrid transaction and analytical processing (HTAP). In this paper, we explain the architectural basis for this assertion, and describe an HTAP example to illustrate these unique characteristics. What Is HTAP And Why Is It Important? The combination of simultaneous transactional workloads (“operational”) and analytics workloads (business intelligence, Big Data etc.) is a concept that is “ gaining traction among database vendors and industry analysts. Gartner will Data-driven businesses be publishing research on the topic in the next 12 months under the “HTAP” often need real-time moniker, HTAP meaning Hybrid Transaction/Analytical Processing. discovery and analysis HTAP is about spotting trends and being aware of leading indicators in order of transactional data to take immediate action. For example, an online retailer uses HTAP to find to make meaningful out what products are currently trending as best sellers in the last hour. changes immediately. He sees snow shovels are selling well and reacts by putting a snow shovel ” promotion on the home page to leverage the trend. Much of Big Data analytics has focused on information discovery, i.e., essentially using Hadoop for batch-oriented storing and querying of large amounts of data sometimes referred to as “data lakes.” However, data-driven businesses often need real-time discovery and analysis of transactional data to make meaningful changes immediately. Real-time discovery and analysis requires repeatable analytics on very recent data.
  • Nuodb, a Peer to Peer Distributed Database for the Cloud

    Nuodb, a Peer to Peer Distributed Database for the Cloud

    Research Seminar NuoDB, a peer to peer distributed database for the cloud Barry Morris Co-Founder & Chief Executive Officer, NuoDB Friday 19th June 2015 Abstract Traditionally, relational databases were designed for scale-up architectures. Supporting more clients or higher throughput required an upgrade to a larger server. Historically the alternatives for scale-out database management have been severely compromised, offering an unattractive choice between: a) Sacrificing transactional (ACID) guarantees (eg "NoSQL" approaches), b) Adopting tightly coupled models with significant flexibility and performance constraints (eg Shared disk or two-phase commit), or c) Application-specific data management (eg sharding). In the NewSQL model and in modern distributed datacenters, on-demand scale-out databases that maintain ACID semantics are an architectural requirement. Also critical are key features associated with being cloud-scale like ease of provisioning and management, security, agility in the face of unpredictable workloads or failures and support for widely distributed applications. Widely distributed applications, in turn, require distributed services that are highly available and can provide low latency. These are the design goals that defined the NuoDB architecture. NuoDB is a distributed database designed with global application deployment challenges in mind. It’s a true SQL service: all the properties of ACID transactions, standard SQL language support and relational logic. It’s also designed from the start as a distributed system that scales the way a cloud service has to scale providing high availability and resiliency with no single points of failure. Different from traditional shared-disk or shared-nothing architectures, NuoDB presents a new kind of peer-to-peer, on-demand independence that yields high availability, low-latency and a deployment model that is easy to manage.