DOCSLIB.ORG

Containers and Cloud: from LXC to Docker to Kubernetes

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Containers and Cloud: from LXC to Docker to Kubernetes CLOUD TIDBITS WELCOME TO CLOUD TIDBITS! In each issue, I’ll look at a different “tidbit” of technology that I consider unique or eye-catching, and of particular Containers and interest to the IEEE Cloud Computing readers. Today’s tidbit focuses on container technology and how it’s emerging as an important part of the cloud computing infrastructure. Cloud: From Cloud Computing’s Multiple OS Capability Many formal definitions of cloud computing exist. The National Institute of Standards and Technol- LXC to Docker ogy’s internationally accepted definition calls for “resource pooling,” where the “provider’s computing resources are pooled to serve multiple consumers using a multitenant model, with different physical to Kubernetes and virtual resources dynamically assigned and reassigned according to consumer demand.”1 It also calls for “rapid elasticity,” where “capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward Cloud Systems with Hypervisors and commensurate with demand.” Containers Most agree that the definition implies some kind Most commercial cloud computing systems—both ser- of technology that provides an isolation and mult- vices and cloud operating system software products— itenancy layer, and where computing resources are use hypervisors. Enterprise VMware installations, split up and dynamically shared using an operating which can rightly be called early private clouds, use technique that implements the specified multiten- the ESXi Hypervisor (www.vmware.com/products/es- ant model. Two technologies are commonly used xi-and-esx/overview). Some public clouds (Terremark, here: the hypervisor and the container. You might Savvis, and Bluelock, for example) use ESXi as well. be familiar with how a hypervisor provides for vir- Both Rackspace and Amazon Web Services (AWS) use tual machines (VMs). You might be less familiar the XEN Hypervisor (www.xenproject.org/developers/ with containers, the most common of which rely on teams/hypervisor.html), which gained tremendous Linux kernel containment features, more commonly popularity because of its early open source inclusion known as LXC (https://linuxcontainers.org). Both with Linux. Because Linux has now shifted to sup- technologies support isolation and multitenancy. port KVM (www.linux-kvm.org), another open source Not all agree that a hypervisor or container is re- quired to call a given system a cloud; several special- ized service providers offer what is generally called a bare metal cloud, where they apply the referenced elasticity and automation to the rapid provisioning and assignment of physical servers, eliminating the overhead of a hypervisor or container altogether. Although interesting for the most demanding appli- cations, the somewhat oxymoron term “bare metal DAVID cloud” is something perhaps Tidbits will look at in BERNSTEIN more detail in a later column. Thus, we’re left with the working definition that Cloud Strategy Partners, cloud computing, at its core, has hypervisors or con- [email protected] tainers as a fundamental technology. 2325-6095/14/$31.00 © 2014 IEEE SEPTEMBER 2014 IEEE CLOUD COMPUTING 81 CLOUD TIDBITS APP APP APP A B C As Linux emerged as the dominant open plat- Libs Libs Libs form, replacing these earlier variations, the technol- ogy found its way into the standard distribution in the form of LXC. APP APP APP Figure 1 compares application deployment using OS OS OS A B C a hypervisor and a container. As the figure shows, A B C the hypervisor-based deployment is ideal when ap- Libs Libs Libs plications on the same cloud require different op- erating systems or OS versions (for example, RHEL Linux, Debian Linux, Ubuntu Linux, Windows Hypervisor Container engine 2000, Windows 2008, Windows 2012). The abstrac- tion must be at the VM level to provide this capabil- Host OS Host OS ity of running different OS versions. With containers, applications share an OS (and, Server Server where appropriate, binaries and libraries), and as a re- (a) (b) sult these deployments will be significantly smaller in size than hypervisor deployments, making it possible Figure 1. Comparison of (a) hypervisor and (b) container-based to store hundreds of containers on a physical host deployments. A hypervisor-based deployment is ideal when applications (versus a strictly limited number of VMs). Because on the same cloud require different operating systems or different OS containers use the host OS, restarting a container versions; in container-based systems, applications share an operating doesn’t mean restarting or rebooting the OS. system, so these deployments can be significantly smaller in size. Those familiar with Linux implementations know that there’s a great degree of binary applica- tion portability among Linux variants, with librar- alternative, KVM has found its way into more recent- ies occasionally required to complete the portability. ly constructed clouds (such as AT&T, HP, Comcast, Therefore, it’s practical to have one container pack- and Orange). KVM is also a favorite hypervisor of the age that will run on almost all Linux-based clouds. OpenStack project and is used in most OpenStack dis- tributions (such as RedHat, Cloudscaling, Piston, and Docker Containers Nebula). Of course, Microsoft uses its Hyper-V hy- Docker (www.docker.com) is an open source project pervisor underneath both Microsoft Azure and Micro- providing a systematic way to automate the faster soft Private Cloud (www.microsoft.com/en-us/server deployment of Linux applications inside portable -cloud/solutions/virtualization.aspx). containers. Basically, Docker extends LXC with a However, not all well-known public clouds use kernel-and application-level API that together run hypervisors. For example, Google, IBM/Softlayer, processes in isolation: CPU, memory, I/O, network, and Joyent are all examples of extremely successful and so on. Docker also uses namespaces to com- public cloud platforms using containers, not VMs. pletely isolate an application’s view of the underly- Some trace inspiration for containers back to the ing operating environment, including process trees, Unix chroot command, which was introduced as part network, user IDs, and file systems. of Unix version 7 in 1979. In 1998, an extended ver- Docker containers are created using base images. sion of chroot was implemented in FreeBSD and called A Docker image can include just the OS fundamen- jail. In 2004, the capability was improved and released tals, or it can consist of a sophisticated prebuilt appli- with Solaris 10 as zones. By Solaris 11, a full-blown ca- cation stack ready for launch. When building images pability based on zones was completed and called con- with Docker, each action taken (that is, command ex- tainers. By that time, other proprietary Unix vendors ecuted, such as apt-get install) forms a new layer on offered similar capabilities—for example, HP-UX con- top of the previous one. Commands can be executed tainers and IBM AIX workload partitions. manually or automatically using Dockerfiles. 82 IEEE CLOUD COMPUTING WWW.COMPUTER.ORG/CLOUDCOMPUTING Application PaaS PaaS Virtual Virtual Virtual Virtual appliance appliance PaaSPaaS PaaS appliance appliance Container Container Container Container Container Container VM VM VM VM VM VM VM OS OS OS OS OS OS OS OS OS OS OS Figure 2. Possible layering combinations for application runtimes. Each Dockerfile is a script composed Appliance,2 and Bitnami (https://bitnami Those who want to deploy applica- of various commands (instructions) and .com), provide application runtime en- tions with the least infrastructure will arguments listed successively to auto- vironments that shield the application choose the simple container-to-OS ap- matically perform actions on a base from the bare OS by providing an inter- proach. This is why container-based cloud image to create (or form) a new image. face for applications with higher-level, vendors can claim improved performance They’re used to organize deployment ar- more portable constructs. Virtual appli- when compared to hypervisor-based tifacts and simplify the deployment pro- ances gained popularity with equipment clouds. A recent benchmark of a “fast cess from start to finish. manufacturers who wanted to provide data” NewSQL system claimed that in an Containers can run on VMs too. If a a vehicle for distributing software ver- apples-to-apples comparison, running on cloud has the right native container run- sions of an appliance—for example, a IBM Softlayer using containers resulted time (such as some of the clouds men- network load balancer, WAN optimizer, in a fivefold performance improvement tioned) a container can run directly on or firewall. Virtual appliances can run over the same benchmark running on the VM. If the cloud only supports hyper- on top of a VM or a container (native Amazon AWS using a hypervisor.3 visor-based VMs, there’s no problem—the LXC-based or running on top of a VM). Software developers tend to prefer entire application, container, and OS For even more isolation from the using PaaS, which will use a container if stack can be placed on a VM and run just OS, especially desired by application available for its runtime, to maximize per- like any other application to the OS stack. programmers, application runtimes can formance as well as to manage application be reconfigured into total platform-as- clustering. If not, the PaaS will run a con- Abstractions on Top of VMs and a-service (PaaS) runtimes. Readers will tainer on a VM. Consequently, as PaaS Containers remember that last issue I discussed gains in popularity, so do containers. Both VMs and containers provide a rath- Cloud Foundry PaaS, and mentioned However, using containers for secu- er low-level construct. Basically, both that it uses container technology for de- rity isolation might not be a good idea. present an operating system interface to ployment. It’s for precisely this reason In an August 2013 blog,4 one of Dock- the developer.
Load more

Recommended publications
  • Integrating On-Premises Core Infrastructure with Microsoft Azure
    Course 10992 • Microsoft Azure Integrating On-Premises Core Infrastructure with Microsoft Azure Length This 3-day, instructor-led workshop covers a range • 3 days of components, including Azure Compute, Azure Audience Storage, and network services that customers can • IT professionals who have used on- benefit from when deploying hybrid solutions. In premises virtualization technologies, including both this context, the term hybrid means integrating Hyper-V and VMware platforms, but who want to deploy, configure, infrastructure technologies that customers host in and administer services and virtual on-premises datacenters with Azure IaaS and PaaS machines in Azure • IT professionals who have used services. This course offers an overview of these Microsoft System Center to services, providing the knowledge necessary to manage and orchestrate an on- premises server infrastructure design hybrid solutions properly. It also includes • Windows and Linux administrators who are looking to evaluate and several demonstrations and labs that enable migrate on-premises workloads students to develop hands-on skills that are and services to the cloud • IT professionals who need to necessary when implementing such solutions. implement network connectivity between on-premises environments and services that Workshop Outline Azure or Microsoft Office 365 hosts • IT professionals who want to use Module 1: Introduction to Microsoft Azure Azure to increase the resiliency and • Overview of cloud computing and Azure agility of their on-premises • Overview of
    [Show full text]
  • Kubernetes Security Guide Contents
    Kubernetes Security Guide Contents Intro 4 CHAPTER 1 Securing your container images and CI/CD pipeline 6 Image scanning 6 What is image scanning 7 Docker image scanning open source tools 7 Open source Docker scanning tool: Anchore Engine 8 Securing your CI/CD pipeline 9 Image scanning in CI/CD 10 CHAPTER 2 Securing Kubernetes Control Plane 14 Kubelet security 14 Access to the kubelet API 15 Kubelet access to Kubernetes API 16 RBAC example, accessing the kubelet API with curl 16 Kubernetes API audit and security log 17 Audit log policies configuration 19 Extending the Kubernetes API using security admission controllers 20 Securing Kubernetes etcd 23 PKI-based authentication for etcd 23 etcd peer-to-peer TLS 23 Kubernetes API to etcd cluster TLS 24 Using a trusted Docker registry 24 Kubernetes trusted image collections: Banning non trusted registry 26 Kubernetes TLS certificates rotation and expiration 26 Kubernetes kubelet TLS certificate rotation 27 Kubernetes serviceAccount token rotation 28 Kubernetes user TLS certificate rotation 29 Securing Kubernetes hosts 29 Kubernetes 2 Security Guide Using a minimal host OS 30 Update system patches 30 Node recycling 30 Running CIS benchmark security tests 31 CHAPTER 3 Understanding Kubernetes RBAC 32 Kubernetes role-based access control (RBAC) 32 RBAC configuration: API server flags 34 How to create Kubernetes users and serviceAccounts 34 How to create a Kubernetes serviceAccount step by step 35 How to create a Kubernetes user step by step 37 Using an external user directory 40 CHAPTER 4 Security
    [Show full text]
  • Running Legacy VM's Along with Containers in Kubernetes!
    Running Legacy VM’s along with containers in Kubernetes Delusion or Reality? Kunal Kushwaha NTT Open Source Software Center Copyright©2019 NTT Corp. All Rights Reserved. About me • Work @ NTT Open Source Software Center • Collaborator (Core developer) for libpod (podman) • Contributor KubeVirt, buildkit and other related projects • Docker Community Leader @ Tokyo Chapter Copyright©2019 NTT Corp. All Rights Reserved. 2 Growth of Containers in Companies Adoption of containers in production has significantly increased Credits: CNCF website Copyright©2019 NTT Corp. All Rights Reserved. 3 Growth of Container Orchestration usage Adoption of container orchestrator like Kubernetes have also increased significantly on public as well private clouds. Credits: CNCF website Copyright©2019 NTT Corp. All Rights Reserved. 4 Infrastructure landscape app-2 app-2 app-M app-1 app-2 app-N app-1 app-1 app-N VM VM VM kernel VM Platform VM Platform Existing Products New Products • The application infrastructure is fragmented as most of old application still running on traditional infrastructure. • Fragmentation means more work & increase in cost Copyright©2019 NTT Corp. All Rights Reserved. 5 What keeps applications away from Containers • Lack of knowledge / Too complex to migrate in containers. • Dependency on custom kernel parameters. • Application designed for a custom kernel. • Application towards the end of life. Companies prefer to re-write application, rather than directly migrating them to containers. https://dzone.com/guides/containers-orchestration-and-beyond Copyright©2019 NTT Corp. All Rights Reserved. 6 Ideal World app-2 app-2 app-M app-1 app-2 app-N app-1 app-1 app-N VM VM VM kernel VM Platform • Applications in VM and containers can be managed with same control plane • Management/ Governance Policies like RBAC, Network etc.
    [Show full text]
  • Ovirt and Docker Integration
    oVirt and Docker Integration October 2014 Federico Simoncelli Principal Software Engineer – Red Hat oVirt and Docker Integration, Oct 2014 1 Agenda ● Deploying an Application (Old-Fashion and Docker) ● Ecosystem: Kubernetes and Project Atomic ● Current Status of Integration ● oVirt Docker User-Interface Plugin ● “Dockerized” oVirt Engine ● Docker on Virtualization ● Possible Future Integration ● Managing Containers as VMs ● Future Multi-Purpose Data Center oVirt and Docker Integration, Oct 2014 2 Deploying an Application (Old-Fashion) ● Deploying an instance of Etherpad # yum search etherpad Warning: No matches found for: etherpad No matches found $ unzip etherpad-lite-1.4.1.zip $ cd etherpad-lite-1.4.1 $ vim README.md ... ## GNU/Linux and other UNIX-like systems You'll need gzip, git, curl, libssl develop libraries, python and gcc. *For Debian/Ubuntu*: `apt-get install gzip git-core curl python libssl-dev pkg- config build-essential` *For Fedora/CentOS*: `yum install gzip git-core curl python openssl-devel && yum groupinstall "Development Tools"` *For FreeBSD*: `portinstall node, npm, git (optional)` Additionally, you'll need [node.js](http://nodejs.org) installed, Ideally the latest stable version, be careful of installing nodejs from apt. ... oVirt and Docker Integration, Oct 2014 3 Installing Dependencies (Old-Fashion) ● 134 new packages required $ yum install gzip git-core curl python openssl-devel Transaction Summary ================================================================================ Install 2 Packages (+14 Dependent
    [Show full text]
  • Container and Kernel-Based Virtual Machine (KVM) Virtualization for Network Function Virtualization (NFV)
    Container and Kernel-Based Virtual Machine (KVM) Virtualization for Network Function Virtualization (NFV) White Paper August 2015 Order Number: 332860-001US YouLegal Lines andmay Disclaimers not use or facilitate the use of this document in connection with any infringement or other legal analysis concerning Intel products described herein. You agree to grant Intel a non-exclusive, royalty-free license to any patent claim thereafter drafted which includes subject matter disclosed herein. No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document. All information provided here is subject to change without notice. Contact your Intel representative to obtain the latest Intel product specifications and roadmaps. The products described may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. Copies of documents which have an order number and are referenced in this document may be obtained by calling 1-800-548-4725 or by visiting: http://www.intel.com/ design/literature.htm. Intel technologies’ features and benefits depend on system configuration and may require enabled hardware, software or service activation. Learn more at http:// www.intel.com/ or from the OEM or retailer. Results have been estimated or simulated using internal Intel analysis or architecture simulation or modeling, and provided to you for informational purposes. Any differences in your system hardware, software or configuration may affect your actual performance. For more complete information about performance and benchmark results, visit www.intel.com/benchmarks. Tests document performance of components on a particular test, in specific systems.
    [Show full text]
  • USING the ZERTO RED HAT CLUSTER MANAGER ZVR-RHC-5.5U3 Rev 01 Dec2017
    USING THE ZERTO RED HAT CLUSTER MANAGER ZVR-RHC-5.5U3 Rev 01 Dec2017 Using the Zerto Red Hat Cluster Manager, you can protect a Red Hat Cluster that is comprised of two virtual machines sharing a disk and is managed by Red Hat Clustering Services. Using Jenkins infrastructure hosted by Docker on a Linux virtual machine, Zerto Red Hat Cluster Manager periodically checks the status of the active and passive hosts. If they have changed, the Zerto Cluster Manager: ■ Pauses the VPG that contains the newly passive virtual machine, also known as the passive node. ■ Resumes the VPG that contains the newly active virtual machine, also known as the active node. ■ Forces a sync to ensure that the newly active virtual machine, the active node, is fully synchronized with the recovery site. You can also manually perform the tasks that the Zerto Red Hat Cluster Manager performs. This document describes the following: ■ “Zerto Red Hat Cluster Manager Requirements”, on page 1 ■ “Installing and Configuring the Zerto Red Hat Cluster Manager”, on page 2 ■ “Upgrading a Docker Container”, on page 3 ■ “Protecting a Red Hat Cluster with the Zerto Orchestrator”, on page 4 Zerto Red Hat Cluster Manager Requirements ■ The Zerto Red Hat Cluster Manager works with: ■ Zerto Virtual Replication 4.5 U1 and higher. ■ vCenter Server only. ■ Docker 1.10 and higher. ■ The shared disk in the cluster in the recovery site must be defined as an eager zeroed thick disk. Use this disk for preseeding after the VPG is created. ■ One task in the Zerto Red Hat Cluster Manager can work with a maximum of two nodes.
    [Show full text]
  • Kubernetes As an Availability Manager for Microservice Based Applications Leila Abdollahi Vayghan
    Kubernetes as an Availability Manager for Microservice Based Applications Leila Abdollahi Vayghan A Thesis in the Department of Computer Science and Software Engineering Presented in Partial Fulfillment of the Requirements for the Degree of Master of Computer Science at Concordia University Montreal, Quebec, Canada August 2019 © Leila Abdollahi Vayghan, 2019 CONCORDIA UNIVERSITY SCHOOL OF GRADUATE STUDIES This is to certify that the thesis prepared By: Leila Abdollahi Vayghan Entitled: Kubernetes as an Availability Manager for Microservice Based Applications and submitted in partial fulfillment of the requirements for the degree of Master in Computer Science complies with the regulations of the University and meets the accepted standards with respect to originality and quality. Signed by the final examining committee: ________________________________________________ Chair Dr. P. Rigby ________________________________________________ Internal Examiner Dr. D. Goswami ________________________________________________ Internal Examiner Dr. J. Rilling ________________________________________________ Co-Supervisor Dr. F. Khendek ________________________________________________ Co-Supervisor Dr. M. Toeroe Approved by: ___________________________________ Dr. L. Narayanan, Chair Department of Computer Science and Software Engineering _______________ 2019___ __________________________________ Dr. Amir Asif, Dean, Faculty of Engineering and Computer Science ii ABSTRACT Kubernetes as an Availability Manager for Microservice Based Applications Leila
    [Show full text]
  • Immutable Infrastructure, Containers, & the Future of Microservices
    Immutable infrastructure, containers, & the future of microservices Adam Miller Senior Software Engineer, Red Hat 2015-07-25 What we'll cover in this session ● Define “microservices” ● Define “containers” in the context of Linux systems ● Container Implementations in Linux ● What Immutable Infrastructure is – Example of what Immutable Infrastructure deployment workflow looks like ● Red Hat Enterprise Linux Atomic Host – How RHEL Atomic enables and enhances these concepts ● Kubernetes – Orchestrating the Immutable Infrastructure ● OpenShift – Enabling the development and container building pipeline Microservices Microservices are not entirely new. ● The vocabulary term is “new-ish” (2012 – James Lewis and Martin Fowler) ● The idea is very old – Microkernels have existed since the 1980s – Could argue that system admins have been doing this with shell scripts and pipes for years ● Applying this concept to services higher in Monolithic Kernel Microkernel the stack is a newer trend based Operating System based Operating System – Application Heavily influenced by popular technologies System Call such as web microframeworks and containers. user mode VFS IPC, File System Application UNIX Device File IPC Server Driver Server Scheduler, Virtual Memory kernel mode Device Drivers, Dispatcher, ... Basic IPC, Virtual Memory, Scheduling Hardware Hardware What are Microservices? ● Services, “the UNIX Way” – Do one thing, do it well. – Decouple tightly coupled services, make the architecture more modular. ● Loosely coupled services using programming language agnostic APIs for communication – Example: REST APIs The mythical cloud The mythical cloud Micro services Containers What are containers? ● Operating-system-level Virtualization – We (the greater Linux community) like to call them “containers” ● OK, so what is Operating-system-level Virtualization? – The multitenant isolation of multiple user Traditional OS Containers space instances or namespaces.
    [Show full text]
  • Kubernetes As an Availability Manager for Microservice Applications
    Kubernetes as an Availability Manager for Microservice Applications Leila Abdollahi Vayghan Mohamed Aymen Saied Maria Toeroe Ferhat Khendek Engineering and Computer Engineering and Computer Ericsson Inc. Engineering and Computer Science Science Montreal, Canada Science Concordia University Concordia University [email protected] Concordia University Montreal, Canada Montreal, Canada Montreal, Canada [email protected] [email protected] [email protected] Abstract— The move towards the microservice based services that can be deployed and scaled independently by fully architecture is well underway. In this architectural style, small and automated deployment machinery, with minimum centralized loosely coupled modules are developed, deployed, and scaled management [2]. Microservices are built around separate independently to compose cloud-native applications. However, for business functionalities. Each microservice runs in its own carrier-grade service providers to migrate to the microservices process and communicates through lightweight mechanisms, architectural style, availability remains a concern. Kubernetes is often using APIs [3]. Microservices address the drawbacks of an open source platform that defines a set of building blocks which monolithic applications. They are small and can restart faster at collectively provide mechanisms for deploying, maintaining, the time of upgrade or failure recovery. Microservices are scaling, and healing containerized microservices. Thus, loosely coupled, and failure of one microservice will not affect Kubernetes hides the complexity of microservice orchestration while managing their availability. In a preliminary work we other microservices of the system. The fine granularity of this evaluated Kubernetes, using its default configuration, from the architectural style makes the scaling more flexible and more availability perspective in a private cloud settings.
    [Show full text]
  • Docker and Kubernetes: Changing the Opentext Documentum Deployment Model
    White paper Docker and Kubernetes: Changing the OpenText Documentum deployment model Containerization with Docker and Kubernetes’ cloud-first technology is not only a game changer for effectively managing on-premises ™ ™ OpenText Documentum solutions, it also paves the way for deploying EIM solutions in the cloud. Contents New deployment models 3 Customer case study—Part I 3 What is containerization? 4 What are Docker containers? 4 Docker container advantages 5 Available containers 6 What is Kubernetes? 6 Kubernetes advantages 6 Customer case study—Part II 7 EIM in the cloud 7 What is the cloud? 7 Cloud EIM 8 Customer case study—Part III 9 ™ OpenText Managed Services 9 Summary 9 Docker and Kubernetes: Changing the OpenText Documentum deployment model 2/10 New deployment models ™ ™ OpenText Documentum administrators can face two challenges: 1. Effectively managing complex Documentum deployments. Highly customized, mission-critical applications consume disproportionate administrative cycles, budgets and resources to install, upgrade, maintain and enhance. Upgrading these applications requires significant investments in change management. As a result, applications are often not upgraded in a timely fashion and do not leverage the latest technology. 2. Developing a cloud strategy for Enterprise Information Management (EIM) applications. Corporate IT is under intense pressure to produce an enterprise cloud strategy. Leveraging cloud technology for Enterprise Information Management (EIM) applications can be a big win, as long as it does not impact adoption, productivity and governance. Containerization enables new deployment models to help organizations meet these challenges, effectively managing on-premises solutions and paving the way for deploying EIM solutions in the cloud. Customer case study—Part I This real-world customer case study illustrates how containerization can benefit existing Documentum customers.
    [Show full text]
  • Labtainers Student Guide
    Labtainers Student Guide Fully provisioned cybersecurity labs December 1, 2020 1 Introduction This manual is intended for use by students performing lab exercises with Labtainers. Labtain- ers provide a fully provisioned execution environment for performing cybersecurity laboratory exercises, including network topologies that include several different interconnected computers. Labtainers assume you have a Linux system, e.g., a virtual machine appliance described below. If you are accessing a Labtainers VM via a web browser, you can skip to section2. 1.1 Obtaining and installing Labtainers The easiest way to obtain Labtainers is to download one of the pre-configured virtual machines from https://nps.edu/web/c3o/virtual-machine-images, and import it into either Virtu- alBox or VMWare. Follow the brief instructions on that download page. When you first boot the resulting VM, Labtainers will take a moment to update itself. You are then provided a terminal that includes some hints, and can be used to run Labtainers. Note that the VM's Ubuntu Linux distribution is configured to NOT automatically perform system updates. It may prompt you to download and install updates. That is typically not necessary and may tie up your network bandwidth. Yes, we are suggesting you not update your Linux VM unless and until you have the time and the bandwidth. You may now skip to section2. 1.2 Alternatives to the Labtainers VM Appliance Skip this section and go to section2 if you are using a Labtainers VM appliance or accessing Labtainers remotvely via a browser. Please note that Docker runs as a privileged service on your computer, and Labtainers containers run as privileged containers.
    [Show full text]
  • LXC, Docker, and the Future of Software Delivery
    LXC, Docker, and the future of software delivery Linuxcon – New Orleans, 2013 Jérôme Petazzoni, dotCloud Inc. Best practices in development and deployment, with Docker and Containers February 2014—Docker 0.8.1 Introduction to Docker - Patel Jitendra Cluster Management with Kubernetes Please open the gears tab below for the speaker notes Satnam Singh [email protected] Work of the Google Kubernetes team and many open source contributors University of Edinburgh, 5 June 2015 Kubernetes An Introduction The promise of cloud computing Cloud software deployment is soul destroying Typically a cloud cluster node is a VM running a specific version of Linux. User applications comprise components each of which may have different and conflicting requirements from libraries, runtimes and kernel features. Applications are coupled to the version of the host operating system: bad. Evolution of the application components is coupled to (and in tension with) the evolution of the host operating system: bad. Also need to deal with node failures, spinning up and turning down replicas to deal with varying load, updating components with disruption … You thought you were a programmer but you are now a sys-admin. Why Linux Containers? What are we trying to solve? The Matrix From Hell Many payloads ● backend services (API) ● databases ● distributed stores ● webapps Many payloads ● Go ● Java ● Node.js ● PHP ● Python ● Ruby ● … Many targets ● your local development environment ● your coworkers' developement environment ● your Q&A team's test environment ● some random
    [Show full text]