Docker OpenStack Cloud Foundry

Editor's Notes

• #5: Cloud computing needs to be built on open source and standards. To build flexible and interoperable cloud architectures, IBM is building on open cloud projects - OpenStack for IaaS, deployment automation tools like Chef, PaaS fabrics  like Cloud Foundry , databases like MongoDB, portable workload template standards  like TOSCA and many others. 
• #9: why Cloud Foundry fits so well ? Well to begin with its 100% OpenSource like OpenStack, which means no vendor lock-ins. The tools and software you will build for Cloud Foundry can be easily ported across all implementations. And 2ndly its a fits exactly in Platform as a Service space. Just like OpenStack provides a great foundation for compute, networking and storage, Cloud Foundry provides that for your runtimes, apps and services. And last but not the least, as we are hearing through the conference, it has very vibrant community. Both IBM and Rackspace are platinum founding members of the Cloud Foundry community, along with a host of other companies. And the community is growing - with more than 1200 developers , 700k lines of code and 43 companies contributing. I iBM is also #2 in contributions to Cloud Foundry and we have 42 IBMers who are approved to contribute to the core Cloud Foundry code base. We have contributed to many components like Elastic runtimes , Eclipse integration and even open sourced many IBM components like WebSphere Java build pack, admin UI, and Performance acceptance tests.
• #14: Docker uses a client-server architecture.  The Docker client talks to the Docker daemon, which does the heavy lifting of building, running, and distributing your Docker containers.  Both the Docker client and the daemon can run on the same system, or you can connect a Docker client to a remote Docker daemon.  The Docker client and daemon communicate via sockets or through a RESTful API.
• #15: Namespaces Docker takes advantage of a technology called namespaces to provide the isolated workspace we call the container. When you run a container, Docker creates a set of namespaces for that container. This provides a layer of isolation: each aspect of a container runs in its own namespace and does not have access outside it. Some of the namespaces that Docker uses are: The pid namespace: Used for process isolation (PID: Process ID). The net namespace: Used for managing network interfaces (NET: Networking). The ipc namespace: Used for managing access to IPC resources (IPC: InterProcess Communication). The mnt namespace: Used for managing mount-points (MNT: Mount). The uts namespace: Used for isolating kernel and version identifiers. (UTS: Unix Timesharing System). Control groups Docker also makes use of another technology called cgroups or control groups. A key to running applications in isolation is to have them only use the resources you want. This ensures containers are good multi-tenant citizens on a host. Control groups allow Docker to share available hardware resources to containers and, if required, set up limits and constraints. For example, limiting the memory available to a specific container. Union file systems Union file systems, or UnionFS, are file systems that operate by creating layers, making them very lightweight and fast. Docker uses union file systems to provide the building blocks for containers. Docker can make use of several union file system variants including: AUFS, btrfs, vfs, and DeviceMapper. Container format Docker combines these components into a wrapper we call a container format. The default container format is called libcontainer. Docker also supports traditional Linux containers using LXC. In the future, Docker may support other container formats, for example, by integrating with BSD Jails or Solaris Zones.
• #16: Virtual Machines Each virtualized application includes not only the application - which may be only 10s of MB - and the necessary binaries and libraries, but also an entire guest operating system - which may weigh 10s of GB. Docker The Docker Engine container comprises just the application and its dependencies. It runs as an isolated process in userspace on the host operating system, sharing the kernel with other containers Compared with Hypervisors, Docker which is OS-Level Virtualization: CPU Performance => native performance Memory Performance => few % for (optional) accounting Network Performance => small overhead; can be optimized to zero overhead creating a new base image takes a few seconds (copy-on-write) apps in different containers can share the same binaries / libs
• #18: Namespaces Docker takes advantage of a technology called namespaces to provide the isolated workspace we call the container. When you run a container, Docker creates a set of namespaces for that container. This provides a layer of isolation: each aspect of a container runs in its own namespace and does not have access outside it. Some of the namespaces that Docker uses are: The pid namespace: Used for process isolation (PID: Process ID). The net namespace: Used for managing network interfaces (NET: Networking). The ipc namespace: Used for managing access to IPC resources (IPC: InterProcess Communication). The mnt namespace: Used for managing mount-points (MNT: Mount). The uts namespace: Used for isolating kernel and version identifiers. (UTS: Unix Timesharing System). Control groups Docker also makes use of another technology called cgroups or control groups. A key to running applications in isolation is to have them only use the resources you want. This ensures containers are good multi-tenant citizens on a host. Control groups allow Docker to share available hardware resources to containers and, if required, set up limits and constraints. For example, limiting the memory available to a specific container. Union file systems Union file systems, or UnionFS, are file systems that operate by creating layers, making them very lightweight and fast. Docker uses union file systems to provide the building blocks for containers. Docker can make use of several union file system variants including: AUFS, btrfs, vfs, and DeviceMapper. Container format Docker combines these components into a wrapper we call a container format. The default container format is called libcontainer. Docker also supports traditional Linux containers using LXC. In the future, Docker may support other container formats, for example, by integrating with BSD Jails or Solaris Zones.
• #19: Namespaces Docker takes advantage of a technology called namespaces to provide the isolated workspace we call the container. When you run a container, Docker creates a set of namespaces for that container. This provides a layer of isolation: each aspect of a container runs in its own namespace and does not have access outside it. Some of the namespaces that Docker uses are: The pid namespace: Used for process isolation (PID: Process ID). The net namespace: Used for managing network interfaces (NET: Networking). The ipc namespace: Used for managing access to IPC resources (IPC: InterProcess Communication). The mnt namespace: Used for managing mount-points (MNT: Mount). The uts namespace: Used for isolating kernel and version identifiers. (UTS: Unix Timesharing System). Control groups Docker also makes use of another technology called cgroups or control groups. A key to running applications in isolation is to have them only use the resources you want. This ensures containers are good multi-tenant citizens on a host. Control groups allow Docker to share available hardware resources to containers and, if required, set up limits and constraints. For example, limiting the memory available to a specific container. Union file systems Union file systems, or UnionFS, are file systems that operate by creating layers, making them very lightweight and fast. Docker uses union file systems to provide the building blocks for containers. Docker can make use of several union file system variants including: AUFS, btrfs, vfs, and DeviceMapper. Container format Docker combines these components into a wrapper we call a container format. The default container format is called libcontainer. Docker also supports traditional Linux containers using LXC. In the future, Docker may support other container formats, for example, by integrating with BSD Jails or Solaris Zones.
• #20: Namespaces Docker takes advantage of a technology called namespaces to provide the isolated workspace we call the container. When you run a container, Docker creates a set of namespaces for that container. This provides a layer of isolation: each aspect of a container runs in its own namespace and does not have access outside it. Some of the namespaces that Docker uses are: The pid namespace: Used for process isolation (PID: Process ID). The net namespace: Used for managing network interfaces (NET: Networking). The ipc namespace: Used for managing access to IPC resources (IPC: InterProcess Communication). The mnt namespace: Used for managing mount-points (MNT: Mount). The uts namespace: Used for isolating kernel and version identifiers. (UTS: Unix Timesharing System). Control groups Docker also makes use of another technology called cgroups or control groups. A key to running applications in isolation is to have them only use the resources you want. This ensures containers are good multi-tenant citizens on a host. Control groups allow Docker to share available hardware resources to containers and, if required, set up limits and constraints. For example, limiting the memory available to a specific container. Union file systems Union file systems, or UnionFS, are file systems that operate by creating layers, making them very lightweight and fast. Docker uses union file systems to provide the building blocks for containers. Docker can make use of several union file system variants including: AUFS, btrfs, vfs, and DeviceMapper. Container format Docker combines these components into a wrapper we call a container format. The default container format is called libcontainer. Docker also supports traditional Linux containers using LXC. In the future, Docker may support other container formats, for example, by integrating with BSD Jails or Solaris Zones.
• #24: Namespaces Docker takes advantage of a technology called namespaces to provide the isolated workspace we call the container. When you run a container, Docker creates a set of namespaces for that container. This provides a layer of isolation: each aspect of a container runs in its own namespace and does not have access outside it. Some of the namespaces that Docker uses are: The pid namespace: Used for process isolation (PID: Process ID). The net namespace: Used for managing network interfaces (NET: Networking). The ipc namespace: Used for managing access to IPC resources (IPC: InterProcess Communication). The mnt namespace: Used for managing mount-points (MNT: Mount). The uts namespace: Used for isolating kernel and version identifiers. (UTS: Unix Timesharing System). Control groups Docker also makes use of another technology called cgroups or control groups. A key to running applications in isolation is to have them only use the resources you want. This ensures containers are good multi-tenant citizens on a host. Control groups allow Docker to share available hardware resources to containers and, if required, set up limits and constraints. For example, limiting the memory available to a specific container. Union file systems Union file systems, or UnionFS, are file systems that operate by creating layers, making them very lightweight and fast. Docker uses union file systems to provide the building blocks for containers. Docker can make use of several union file system variants including: AUFS, btrfs, vfs, and DeviceMapper. Container format Docker combines these components into a wrapper we call a container format. The default container format is called libcontainer. Docker also supports traditional Linux containers using LXC. In the future, Docker may support other container formats, for example, by integrating with BSD Jails or Solaris Zones.
• #27: In this case the integration is provided by BOSH. BOSH is a release deployment and lifecycle management tool for Cloud Foundry, and it provides Cloud Provide Interface, for deploying Cloud Foundry on VMWare, AWS and OpenStack. BOSH Cloud Provider Interface has few of the methods which need to be implemented for any  IaaS, and in this case have been implemented for OpenStack and leverage the preexisting open source fog ruby gem In addition to this, Cloud Foundry has certain requirements from the IaaS - basically it needs the IaaS to provide support for static ips for intercommunication, persistent disks for storing runtimes and application files, specialized security groups for management and application traffic, and custom vm configurations for different components of Cloud Foundry. As Egle described, OpenStack via its Compute, Networking and Storage components provides all these capabilities, and more.
• #29: In this case the integration is provided by BOSH. BOSH is a release deployment and lifecycle management tool for Cloud Foundry, and it provides Cloud Provide Interface, for deploying Cloud Foundry on VMWare, AWS and OpenStack. BOSH Cloud Provider Interface has few of the methods which need to be implemented for any  IaaS, and in this case have been implemented for OpenStack and leverage the preexisting open source fog ruby gem In addition to this, Cloud Foundry has certain requirements from the IaaS - basically it needs the IaaS to provide support for static ips for intercommunication, persistent disks for storing runtimes and application files, specialized security groups for management and application traffic, and custom vm configurations for different components of Cloud Foundry. As Egle described, OpenStack via its Compute, Networking and Storage components provides all these capabilities, and more.
• #30: In this case the integration is provided by BOSH. BOSH is a release deployment and lifecycle management tool for Cloud Foundry, and it provides Cloud Provide Interface, for deploying Cloud Foundry on VMWare, AWS and OpenStack. BOSH Cloud Provider Interface has few of the methods which need to be implemented for any  IaaS, and in this case have been implemented for OpenStack and leverage the preexisting open source fog ruby gem In addition to this, Cloud Foundry has certain requirements from the IaaS - basically it needs the IaaS to provide support for static ips for intercommunication, persistent disks for storing runtimes and application files, specialized security groups for management and application traffic, and custom vm configurations for different components of Cloud Foundry. As Egle described, OpenStack via its Compute, Networking and Storage components provides all these capabilities, and more.
• #31: In this case the integration is provided by BOSH. BOSH is a release deployment and lifecycle management tool for Cloud Foundry, and it provides Cloud Provide Interface, for deploying Cloud Foundry on VMWare, AWS and OpenStack. BOSH Cloud Provider Interface has few of the methods which need to be implemented for any  IaaS, and in this case have been implemented for OpenStack and leverage the preexisting open source fog ruby gem In addition to this, Cloud Foundry has certain requirements from the IaaS - basically it needs the IaaS to provide support for static ips for intercommunication, persistent disks for storing runtimes and application files, specialized security groups for management and application traffic, and custom vm configurations for different components of Cloud Foundry. As Egle described, OpenStack via its Compute, Networking and Storage components provides all these capabilities, and more.
• #32: In this case the integration is provided by BOSH. BOSH is a release deployment and lifecycle management tool for Cloud Foundry, and it provides Cloud Provide Interface, for deploying Cloud Foundry on VMWare, AWS and OpenStack. BOSH Cloud Provider Interface has few of the methods which need to be implemented for any  IaaS, and in this case have been implemented for OpenStack and leverage the preexisting open source fog ruby gem In addition to this, Cloud Foundry has certain requirements from the IaaS - basically it needs the IaaS to provide support for static ips for intercommunication, persistent disks for storing runtimes and application files, specialized security groups for management and application traffic, and custom vm configurations for different components of Cloud Foundry. As Egle described, OpenStack via its Compute, Networking and Storage components provides all these capabilities, and more.
• #34: Step on the Gas: See how Open Technologies are driving the future of the enterprise Todd Moore, Director, Open Technologies and Partnerships David Lindquist, Chief Technology Officer / Vice President Strategy and Architecture OpenStack, Cloud Foundry, Docker and more. These are the open technologies reshaping the new model for Cloud and are the source of inspiration for more change to come. Join Dave Lindquist, IBM's VP & CTO Strategy and Architecture of IBM's Cloud Technology and Todd Moore IBM's Director for Open Technologies to get the inside story on how these technologies and others are reshaping the IT industry and the model for Enterprise software development. Learn how open source software is driving interoperability amongst vendor solutions at an unparalleled velocity of innovation. See how this fuels IBM's long standing commitment to the growth and health of open source communities such as OpenStack. IBM contributes new features and function to OpenStack, but even more importantly, we improve interoperability and stability. Join us to learn where we are currently engaged, such as our substantial commitments to DefCore and RefStack, and to learn our thoughts on the future, and along the way see some of the cool demos of new product offerings IBM has built on OpenStack   IBM and OpenStack: Collaborations beyond the code Manuel Silveyra, Daniels Krook As the largest open source project in the world, OpenStack is produced by a huge and diverse community of global contributors. The most high profile efforts come from the individuals and organizations that produce the code and package the releases, however there are many other ways to get involved. In this sponsored session, we will highlight some of the key ways that IBM participates in the OpenStack community. We'll start off by reviewing some of our major code contributions, then we will highlight our conference and summit content, local meetup leadership activity, social media activism, web content, and more. After this presentation, you'll appreciate the full range of the activities that make an open source community strong, and learn how you can take part in the OpenStack community, as IBMers have. Finally, you'll have a chance to provide your feedback to guide IBM with its community activities, and have a starting point to get involved yourself. A Use Case Driven view of IBM’s OpenStack based Offerings Moe Abdula, Vice President of Cloud Strategy IBM has made a huge commitment to OpenStack, and too that end we have built a number of solutions on top of OpenStack.  Whether you are looking for a hosted managed OpenStack instance ready to use in under and hour, or you want to build an on premise OpenStack region using a hardened distribution, or if you want to orchestrate the delivery of cloud service across multiple OpenStack regions; IBM has a solution for you.  In this session we will look at adoption use cases and customer examples that highlight the breadth of our offerings.  We will cover the following solutions: IBM Cloud OpenStack Services, IBM Cloud Manager with OpenStack, IBM PowerVC, IBM Cloud Orchestrator IBM OpenStack Offerings in Action Moe Abdula, Vice President of Cloud Strategy and offerings SMEs In the previous session you have heard about our offerings now we will show you a demonstration of some of them in action.  Our scenario will revolve around an innovator looking to build cloud solutions on OpenStack.   We will explore from getting started with OpenStack all the way up to delivering production workloads fully integrated into data center processes.   You should walk away from this session with a detailed understanding of how IBM can help you succeed with OpenStack.