FORMATION OPENSTACK UTILISATEUR
1 ABOUT THESE TRAINING MATERIALS
2 . 1 TRAINING MATERIALS WRITTEN BY PARTICULE
ex Osones/Alterway Cloud Native experts Devops experts Our training offers: https://particule.io/en/trainings/ Sources: https://github.com/particuleio/formations/ HTML/PDF: https://particule.io/formations/
2 . 2 COPYRIGHT License: Creative Commons BY-SA 4.0 Copyright © 2014-2019 alter way Cloud Consulting Copyright © 2020 particule. Since 2020, all commits are the property of their owners
2 . 3 INTRODUCTION
3 . 1 GOALS OF THE TRAINING: CLOUD Understand concepts and benefits of cloud Know the vocabulary related to cloud Overview of cloud market players and focus on AWS and OpenStack Know how to take advantage of IaaS Be able to decide what is cloud compatible or not Adapt its system administration and development methods to a cloud environment
3 . 2 GOALS OF THE TRAINING: OPENSTACK Discover OpenStack and use its different services Know how the project works and its capabilities Understand the internals of each OpenStack component Be able to make the right configuration choices Be capable of manually deploying an OpenStack cloud providing IaaS Know the best practices for deploying OpenStack Be able to track down the cause of an error in OpenStack Be able how to react in front of a bug and know the fix process
3 . 3 REQUIREMENTS Advanced sys admin skills for Linux such as Ubuntu, Red Hat or Debian, including: Package management Configuration files and services handling LVM (Logical Volume Management) and filesystems Notions: Virtualization: KVM (Kernel-based Virtual Machine), libvirt Network: iptables, namespaces SQL Optional: Comfortable in a Python environment
3 . 4 CLOUD, OVERVIEW
4 . 1 FORMAL DEFINITION
4 . 2 SPECIFICATIONS Provide one or more service(s)... Self service Through the network Sharing resources Fast elasticity Metering Inspired by the NIST definition https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800- 145.pdf
4 . 3 SELF SERVICE User goes directly to the service No humain intermediary Immediate responses Services catalog for their discovery
4 . 4 THROUGH THE NETWORK User uses the service through the network The service provider is remote to the consumer Network = internet or not Usage of standard network protocols (typically: HTTP)
4 . 5 SHARING RESSOURCES A cloud provided services to multiple users/organizations (multi-tenant) Tenant or project: logical isolation of resources Resources are available in large quantities (considered unlimited) Resources usage is not visible Accurate location of resources is not visible
4 . 6 FAST ELASTICITY Provisionning and deletion of resources almost instantaneous Enables scaling Ability to automate these scaling actions Virtually no limit to this elasticity
4 . 7 METERING Usage of cloud resources is monitored by the provider The provider can do capacity planning and billing from these informations User is therefore billed depending on accurate usage of resources User can take advantage of these informations
4 . 8 MODELS service models: IaaS, PaaS, SaaS deployment models: public, private, hybrid
4 . 9 IAAS Infrastructure as a Service Infrastructure: Compute Storage Network Target users: administrators (system, storage, network)
4 . 10 PAAS Platform as a Service Two concepts: Environment to develop/deploy an application (language/framework specific - example: Python/Django) Higher level resources than infrastructure, example: DBMS Target users: application developers
4 . 11 SAAS Software as a Service Target users: end users Not to be confused with the economic definition of SaaS
4 . 12 SOMETHING AS A SERVICE? Load balancing as a Service (Infra) Database as a Service (Platform) MyApplication as a Service (Software) etc.
4 . 13 SERVICE MODELS IN ONE DIAGRAM
IaaS - PaaS - SaaS (source: Wikipedia) 4 . 14 PUBLIC OR PRIVATE CLOUD? Who is it for? Public: everyone, available on internet Private: to an organization, available on its network
4 . 15 HYBRID CLOUD Usage of multiple public and/or private clouds Attractive concept but implementation is hard a priori Some use cases fit perfectly Continuous integration (CI) Incentives: Avoid lock-in Cloud bursting
4 . 16 VIRTUALIZATION INSTANT Let's make it clear. Virtualization is a technology that can implement the compute function A cloud providing compute resources can use virtualization But it can also use: Bare-metal Containers
4 . 17 APIS ARE KEY Reminder: API stands for Application Programming Interface In the software sense: Interface for a program to use a library In the cloud sense: Interface for a program to use a service (XaaS) Programming interface (through the network, often HTTP) Explicit boundary between the provider and the user Defines how the user interacts with the cloud to manage their resources Manages: CRUD (Create, Read, Update, Delete)
4 . 18 API REST One ressource == one URI (Uniform Resource Identifier) Usage of HTTP verbs to define operations (CRUD) GET POST PUT DELETE Usage of HTTP return codes Resources are represented in the HTTP responses' body
4 . 19 REST - EXAMPLES
GET http://endpoint/volumes/ GET http://endpoint/volumes/?size=10 POST http://endpoint/volumes/ DELETE http://endpoint/volumes/xyz
4 . 20 REAL EXAMPLE
GET /v2.0/networks/d32019d3-bc6e-4319-9c1d-6722fc136a22 { "network":{ "status":"ACTIVE", "subnets":[ "54d6f61d-db07-451c-9ab3-b9609b6b6f0b" ], "name":"private-network", "provider:physical_network":null, "admin_state_up":true, "tenant_id":"4fd44f30292945e481c7b8a0c8908869", "provider:network_type":"local", "router:external":true, "shared":true, "id":"d32019d3-bc6e-4319-9c1d-6722fc136a22", "provider:segmentation_id":null } }
4 . 21 WHY CLOUD? ECONOMICAL POINT OF VIEW Consider IT resources as service provider resources Shift the "investment" budget (Capex) to the "operation" budget (Opex) Cut costs by sharing resources, and maybe with economies of scale Reduce delivery times Match costs to the real usage of resources
4 . 22 WHY CLOUD? TECHNICAL POINT OF VIEW Abstract from the lower layers (server, network, OS, storage) Get rid of the technical administration of resources and services (DB, firewalls, load-balancing, etc.) Design infrastructures which can scale on the fly Act on resources through lines of code and manage infrastructures "as code"
4 . 23 MARKET
4 . 24 AMAZON WEB SERVICES (AWS), LEADER
AWS logo
Started in 2006 At first: "e-commerce" web services for developers Then: other services for developers And finally: infrastructure resources Recently, SaaS
4 . 25 PUBLIC IAAS ALTERNATIVES TO AWS Google Cloud Platform Microsoft Azure Rackspace DreamHost DigitalOcean In France: Cloudwatt (Orange Business Services) Numergy (SFR) OVH Ikoula Scaleway Outscale
4 . 26 PRIVATE IAAS OpenStack CloudStack Eucalyptus OpenNebula
4 . 27 OPENSTACK IN A FEW WORDS
OpenStack logo
Was born in 2010 OpenStack Foundation since 2012 Written in Python and distributed under Apache 2.0 license Large support from the industry and various contributions
4 . 28 PUBLIC PAAS EXAMPLES Amazon Elastic Beanstalk (https://aws.amazon.com/fr/elasticbeanstalk) Google App Engine (https://cloud.google.com/appengine) Heroku (https://www.heroku.com)
4 . 29 PRIVATE PAAS SOLUTIONS Cloud Foundry, Foundation (https://www.cloudfoundry.org) OpenShift, Red Hat (https://www.openshift.org) Solum, OpenStack (https://wiki.openstack.org/wiki/Solum)
4 . 30 INFRASTRUCTURE AS A SERVICE CONCEPTS
4 . 31 BASICS Infrastructure: Compute Storage Network
4 . 32 COMPUTE RESOURCES Instance Image Flavor Keypair (SSH)
4 . 33 INSTANCE Dedicated to compute Short typical lifetime, to be considered ephemeral Should not store persistent data Non persistent root disk Based on an image
4 . 34 CLOUD IMAGE Disk image containing an already installed OS Infinitely instanciable Can talk to the metadata API
4 . 35 METADATA API http://169.254.169.254 Available from the instance Provides informations about the instance Exposes userdata The cloud-init tool helps take advantage of this API
4 . 36 FLAVOR Instance type in AWS Defines an instance model regarding CPU, RAM, disk (root), ephemeral disk The ephemeral disk has, like the root disk, the advantage of often being local and thus fast
4 . 37 KEYPAIR SSH public key + private key Cloud manages and stores the public key This public key is used to give SSH access to the instances
4 . 38 NETWORK RESOURCES 1/2 L2 network Network port L3 network Router Floating IP Security group
4 . 39 NETWORK RESOURCES 2/2 Load Balancing as a Service VPN as a Service Firewall as a Service
4 . 40 STORAGE RESOURCES Cloud provides two kinds of storage Block Object
4 . 41 BLOCK STORAGE Volumes that can be attached to an instance Access to raw devices such as /dev/vdb Ability to use any kind of file system Ability to use LVM, encryption, etc. Compatible with all existing applications Requires provisioning space by defining volume size
4 . 42 SHARED STORAGE? Block storage is not a shared storage solution like NFS NFS is at a higher layer: file system A volume is a priori connected to a single host
4 . 43 "BOOT FROM VOLUME" Starting an instance with its root disk on a volume Root disk data persistence Gets similar to classical server
4 . 44 OBJECT STORAGE API: CRUD on data Push and retrieve objects in/from a container/bucket No data hierachy, no directories, no file system Read/write access through APIs only No provisioning necessary Application must be designed to take advantage of object storage
4 . 45 ORCHESTRATION Orchestrate creation and management of resources in the cloud Architecture definition in a template Resources created from a template make a stack There are also orchestration tools (rather than services)
4 . 46 USAGE BEST PRACTICES
4 . 47 WHY BEST PRACTICES? Two differents possible views: Don't change anything Risk not meeting expectations Limit usage to test & dev use case Adapt to new cloud compliant practices to take advantage of it
4 . 48 HIGH AVAILABILITY (HA) Cloud control plane (APIs) is HA Managed resources might not be
4 . 49 PET VS CATTLE How to consider instances? Pet Cattle
4 . 50 INFRASTRUCTURE AS CODE With code Provision infrastructure resources Configure said resources, instances in particular The job is changing: Infrastructure Developer
4 . 51 SCALING Scale out rather than Scale up Scale out: horizontal scaling Scale up: vertical scaling Auto-scaling Managed by the cloud Managed by an external component
4 . 52 CLOUD READY APPLICATIONS Store their data in an appropriate place Are architected to be fault tolerant Etc. Cf. https://12factor.net/
4 . 53 BEHIND CLOUD
4 . 54 HOW TO IMPLEMENT A COMPUTE SERVICE Virtualization (system) Containers Bare metal
4 . 55 STORAGE IMPLEMENTATION: (SOFTWARE DEFINED STORAGE) SDS
Warning: not to be confused with the block vs object topic Use of commodity hardware No hardware RAID Software is responsible for the data Hardware failures are taken into account and managed The Ceph project and the OpenStack Swift component implement SDS See also Scality
4 . 56 SDS - CAP THEOREM Consistency - Availability - Partition tolerance
4 . 57 OPENSTACK: THE PROJECT
5 . 1 OVERVIEW
5 . 2 HIGH LEVEL
Simple version
5 . 3 HISTORY Started in 2010 Goal: the Free Open Source Cloud Operating System Merge of two projects from Rackspace (Storage) and NASA (Compute) Free software distributed under Apache 2.0 license Birth of the Foundation in 2012
5 . 4 MISSION STATEMENT To produce a ubiquitous Open Source Cloud Computing platform that is easy to use, simple to implement, interoperable between deployments, works well at all scales, and meets the needs of users and operators of both public and private clouds.
5 . 5 RELEASES Austin (2010.1) Bexar (2011.1), Cactus (2011.2), Diablo (2011.3) Essex (2012.1), Folsom (2012.2) Grizzly (2013.1), Havana (2013.2) Icehouse (2014.1), Juno (2014.2) Kilo (2015.1), Liberty (2015.2) Mitaka (2016.1), Newton (2016.2) Ocata (2017.1), Pike (2017.2) Queens (2018.1), Rocky (2018.2) Stein (2019.1), Train (2019.2) Early 2020: Ussuri
5 . 6 SOME OF THE SUPPORTERS/CONTRIBUTORS ... Editors: Red Hat, Suse, Canonical, Vmware, ... Hardware makers: IBM, HP, Dell, ... Hardware makers/network: Juniper, Cisco, ... Hardware makers/storage: NetApp, Hitachi, ... Also: NASA, Rackspace, Yahoo, OVH, Citrix, SAP, ... Google! (since July 2015) https://www.openstack.org/foundation/companies/
5 . 7 ... AND USERS All the previously mentioned contributors In France: Cloudwatt and Numergy Wikimedia CERN Paypal Comcast BMW Etc. Not counting confidential deployments https://www.openstack.org/user-stories/
5 . 8 THE DIFFERENT SUB-PROJECTS https://www.openstack.org/software/project-navigator/ OpenStack Compute - Nova OpenStack (Object) Storage - Swift OpenStack Block Storage - Cinder OpenStack Networking - Neutron OpenStack Image Service - Glance OpenStack Identity Service - Keystone OpenStack Dashboard - Horizon OpenStack Telemetry - Ceilometer OpenStack Orchestration - Heat
5 . 9 THE DIFFERENT SUB-PROJECTS (2) But also: Bare metal (Ironic) Queue service (Zaqar) Database service (Trove) Data processing (Sahara) DNS service (Designate) Shared File Systems (Manila) Key management (Barbican) Container (Magnum) Others Client CLI and libraries OpenStack deployment tools Libraries used by OpenStack Tools used to develop OpenStack 5 . 10 APIS Each project supports its OpenStack API Some projects support the corresponding AWS API (Nova/EC2, Swift/S3)
5 . 11 THE 4 OPENS Open Source Open Design Open Development Open Community https://governance.openstack.org/tc/reference/opens.html https://www.openstack.org/four-opens/
5 . 12 THE OPENSTACK FOUNDATION Main governance entity and legal representation of the project Board members are part of the sponsoring companies and elected by individual members Everyone can (freely) become an individual member Human resources: marketing, event managemement, release management, a few developers (mainly on infrastructure) 600 organizations across the world 80000 individual members in 170 countries
5 . 13 THE OPENSTACK FOUNDATION
Main entities of the Foundation
5 . 14 OPEN INFRASTRUCTURE Lately, the OpenStack Foundation expands to Open Infrastructure Beyond OpenStack, new projects: Kata Containers Zuul Airship StarlingX
5 . 15 RESOURCES Announcements (new versions, security advisories): [email protected] Documentation portal: https://docs.openstack.org/ API/SDK: https://developer.openstack.org/ Project governance: https://governance.openstack.org/ Releases: https://releases.openstack.org/ Support: https://ask.openstack.org/ [email protected] #openstack@Freenode
5 . 16 RESOURCES News: Official blog: https://www.openstack.org/blog/ Planet: http://planet.openstack.org/ Superuser: http://superuser.openstack.org/ Commercial resources: https://www.openstack.org/marketplace/ among others Job board: https://www.openstack.org/community/jobs/
5 . 17 USER SURVEY Regular survey done by the Foundation (every 6 months) Targets deployers and users Usable data: https://www.openstack.org/analytics
5 . 18 CERTIFIED OPENSTACK ADMINISTRATOR (COA) The only certification: Approved by the OpenStack Foundation Not linked to a specific company Content: Mainly OpenStack cloud user oriented https://www.openstack.org/coa/requirements/ Practical aspects: Practical exam, remote, duration: 2.5 hours Cost: $300 (one re-take possible) Ressources https://www.openstack.org/coa/ Tips: https://www.openstack.org/coa/tips/ Handbook: http://www.openstack.org/coa/handbook (unofficial) Exercises: https://github.com/AJNOURI/COA 5 . 19 RESOURCES - FRENCH COMMUNITY AND ASSOCIATION
Logo OpenStack-fr https://openstack.fr/ - https://asso.openstack.fr/ Meetups: Paris, Lyon, Toulouse, Montréal, etc. OpenStack Days France (Paris): https://openstackdayfrance.fr Attending events such as Paris Open Source Summit Communication channels: [email protected] #openstack-fr@Freenode
5 . 20 USING OPENSTACK
6 . 1 PRINCIPLE All the features are available through the API Clients (including Horizon) go through the API Credentials are required, with the OpenStack API: user password project (tenant) domain
6 . 2 OPENSTACK APIS One API per OpenStack service Versioned, backwards compatiblity is guaranteed Body of requests and responses is formatted with JSON REST architecture Managed resources are specific to a project https://developer.openstack.org/#api
6 . 3 API ACCESS Direct, using HTTP, with tools like curl With a library Official implementations in Python OpenStackSDK Other implementations, including for other languages (example: jclouds) Shade (Python library which includes business logic) With official command line tools With Horizon Through higher-level third-party tools (example: Terraform)
6 . 4 OFFICIAL CLIENTS OpenStack provides official clients Historically: python-PROJECTclient (Python library and CLI) Today: openstackclient (CLI) CLI tools Authentication is done by passing credentials as parameters, environment variables or configuration file The --debug parameter shows the HTTP connection
6 . 5 OPENSTACK CLIENT Unified CLI client openstack
6 . 6 KEYSTONE: AUTHENTICATION, AUTHORIZATION AND SERVICE CATALOG
6 . 7 PRINCIPLES Keystone is responsible for authentication and authorization and service catalog. Standard user authenticates against Keystone Admin user often interacts with Keystone
6 . 8 API API v3: port 5000 Manages: Users, groups Projects (tenants) Roles (link between user and project) Domains Services and endpoints (service catalog) Provides: Tokens (authentication tokens)
6 . 9 SERVICE CATALOG For each service, multiple endpoints are possible depending on: region interface type (public, internal, admin)
6 . 10 TYPICAL USAGE SCENARIO
Interactions with Keystone
6 . 11 NOVA: COMPUTE
6 . 12 PRINCIPLES Mainly manages instances Instances are created from images provided by Glance Instances' network interfaces are associated with Neutron ports Block storage can be provided to instances by Cinder
6 . 13 INSTANCE PROPERTIES Ephemeral, a priori not HA Defined by a flavor Built from an image Optional: volume attachments Optional: boot from volume Optional: public SSH key Optional: network ports
6 . 14 API Managed resources: Instances Flavors (instance types) Keypairs: resources dedicated to each user (not part of a project)
6 . 15 ACTIONS ON INSTANCES Reboot / shutdown Snapshot Logs VNC access Resize Migration (admin)
6 . 16 GLANCE: IMAGE REGISTRY
6 . 17 PRINCIPLES Image (and snapshot) registry Image properties
6 . 18 API API v2: current version, manages images and snapshots API artifacts: future version, more common
6 . 19 IMAGE TYPES Glance supports a wide range of image types, limited by Nova's underlying technology support raw qcow2 ami vmdk iso
6 . 20 IMAGE PROPERTIES IN GLANCE The user can define a number of properties among which some will be used at instance creation Image type Architecture Distribution Distribution version Minimum disk space Minimum RAM
6 . 21 IMAGE SHARING Public image: available to all projects By default, only the admin can make an image public Shared image: available to one or multiple other project(s)
6 . 22 DOWNLOADING IMAGES Most OS provide regularly updated images: Ubuntu : https://cloud-images.ubuntu.com/ Debian : https://cdimage.debian.org/cdimage/openstack/ CentOS : https://cloud.centos.org/centos/
6 . 23 NEUTRON: NETWORK
6 . 24 API The API exposes these main resources: Network: layer 2 Subnet: layer 3 Port: can be attached to an instance interface, a load- balancer, etc. Router Floating IP, security group
6 . 25 FLOATING IPS In addition to fixed IPs which are set on instances Allocation (reservation for the project) of an IP from a pool Association of an allocated IP to a port (of an instance, for example) Not directly set on instances
6 . 26 SECURITY GROUPS Similar to a firewall in front of each instane An instance can be associated to one or multiple security groups Ingress and egress access rules Rules per protocol (TCP/UDP/ICMP) and port Targets an IP address, a network or another security group
6 . 27 ADDITIONAL FEATURES Beyond the basic L2 and L3 networking features, Neutron may provide other services: Load Balancing Firewall: different from security groups VPN: to reach a private network without floating IPs QoS
6 . 28 CINDER: BLOCK STORAGE
6 . 29 PRINCIPLES Provides volumes (block storage) that can be attached to instances Manages different volume types Manages volume snapshots and volume backups
6 . 30 USAGE Additional volume (and persistent storage) on an instance Boot from volume: OS is on the volume Backup to object store (Swift ou Ceph) feature
6 . 31 HEAT: ORCHESTRATION
6 . 32 PRINCIPLES Heat is the native OpenStack solution, orchestration service Heat provides an API to manage stacks from templates A Heat template follows the HOT (Heat Orchestration Template) format, based on YAML
6 . 33 A HEAT ORCHESTRATION TEMPLATE (HOT) TEMPLATE parameters - resources - outputs heat_template_version: 2013-05-23 description: Simple template to deploy a single compute instance resources: my_instance: type: OS::Nova::Server properties: key_name: my_key image: F18-x86_64-cfntools flavor: m1.small
6 . 34 BUILD A TEMPLATE FROM EXISTING RESOURCES Multiple projects are being developed Flame (Cloudwatt) HOT builder Merlin
6 . 35 HORIZON : WEB DASHBOARD
6 . 36 PRINCIPLES Provides a web interface Uses existing APIs to provide a user interface Ability to log in without specifiying a project: Horizon determines the list of available projects
6 . 37 USAGE One interface per project (ability to switch) Availability of the service catalog Download of a clouds.yaml config file Restricted “admin” area
6 . 38 CLOUD-READY ARCHITECTURES
7 . 1 DESIGN AN APPLICATION FOR THE CLOUD
7 . 2 ADAPT OR THINK “CLOUD READY” APPLICATIONS 1/3 See OpenStack project design tenets and Twelve-Factor https://12factor.net/ Distributed rather than monolithic architecture Eases scaling Limits failure domain Loose coupling between components
7 . 3 ADAPT OR THINK “CLOUD READY” APPLICATIONS 2/3 Message bus for inter-component communication Stateless: allows multiple access routes to the application Dynamic: application must adapt to its environnement and reconfigure itself when necessary Allow deployment and operation using automation tools
7 . 4 ADAPT OR THINK “CLOUD READY” APPLICATIONS 3/3 Limit as much as possible hardware or software specific dependencies that may not work in a cloud Integrated fault tolerance Do not store data locally, but rather: Database Object storage Use standard logging tools
7 . 5 DESIGN AN INFRASTRUCTURE FOR THE CLOUD
7 . 6 AUTOMATION Automate infrastructure management: mandatory Resources creation Resources configuration
7 . 7 INFRASTRUCTURE AS CODE Work like a developer Describe your infrastructure as code (Heat/Terraform, Ansible) Track changes in a VCS (git) Set up code review Use testing mechanisms Take advantage of continuous integration and deployment systems
7 . 8 ORCHESTRATION NEED Manage all kind of resources through a unique entrypoint Infrastructure description in a file (template) Heat (included in OpenStack), Terraform
7 . 9 TESTS AND CONTINUOUS INTEGRATION Code style Syntax validation Unit tests Integration tests Full deployment tests
7 . 10 FAULT TOLERANCE Take advantage of application abilities Don't try to make the compute infrastructure HA
7 . 11 AUTOSCALING GROUP Group of similar instances Variable number of instances Automated scaling depending on metrics Enables horizontal scaling
7 . 12 MONITORING Take into account instances' lifecycle: DOWN != ALERT Monitor the service rather than the server
7 . 13 BACKUP Be able to recreate your instances (and the rest of the infrastructure) Data (application, logs): block, object
7 . 14 HOW TO MANAGE IMAGES? Use of generic images and personalization at launch Creation of intermediary and/or completely personalized images: Cold modification: libguestfs, virt-builder, virt- sysprep Modification through an instance: automation possible with Packer Build from scratch: diskimage-builder (TripleO) Build from scratch with distribution-specific tools (openstack-debian-images for Debian)
7 . 15 CONCLUSION
8 . 1 POUR CONCLURE Le cloud révolutionne l’IT OpenStack est le projet libre phare sur la partie IaaS L’utilisation d’un cloud IaaS implique des changements de pratique Les métiers d’architecture logicielle et infra évoluent
8 . 2