19
So Your OpenStack Cloud is Built...Now What’s Next? Walter Bentley Cloud Solutions Architect – Private Cloud

So Your OpenStack Cloud is Built... Now What's Next - Walter Bentley - OpenStack Day Israel 2016

Embed Size (px)

Citation preview

So Your OpenStack Cloud is Built...Now What’s Next?Walter Bent leyCloud Solut ions Arch i tect – Pr ivate C loud

2@ d j s t a y fl y p r o

Walter BentleyCloud Solutions Architect, RPC

Twitter: @djstayflyproLinkedIn: http://goo.gl/r2p21i

GitHub: wbentley15Blog: hitchnyc.com

• Over 17 years of IT experience • New Yexan (a New Yorker living in

Texas)• Cloud Advocate (hybrid is my favorite)• Author & Knowledge sharer• OpenStack believer• Motorcyclist & DJ (literally…no lie)• Always about living life now!

3@ d j s t a y fl y p r o

Talking Points• Review some common cloud decisions and day-to-day operator tasks• Learn why OpenStack and automation work great together• Review some automation considerations before getting started• Step thru how to automate various tasks with OpenStack• Benefits of adopting an ‘Administration DevOps’ state of mind and

next steps

4@ d j s t a y fl y p r o

So you have a cloud, now what?

Why not create some roles and playbooks to automate all those pre-configurations

5@ d j s t a y fl y p r o

Decisions, decisions…

6@ d j s t a y fl y p r o

OpenStack AutomationAPIs and/or

CLIDashboard

Hypervisor

7@ d j s t a y fl y p r o

Before you get started…

A few possible automation considerations:

• Create a plan with goals, objectives and planned outcomes• Make framework decisions ahead of time; then stick to them• Code consistency

Defining environment variables

API vs. CLI Where to run the codeShould the automation code run locally on the control plane or remotely? Yes, you have to decide

Within your automation code you have to decide whether to consume the OpenStack API or CLI

Automation code should leverage variables as much as possible; variables can be defined globally or per role/recipes/manifests/modules

Image FPO

8

D e m o : Tu r n A p p l i c a t i o n S t a c k s i n t o C o d ew i t h H e a t

8

9@ d j s t a y fl y p r o

OpenStack Scenario #1As a cloud operator,you want to empower the QA team with the ability to stand up their own test environments… • What would be your approach for doing this with OpenStack? Provide

QA with a project and say good luck?• Is there more you could do for them? How could you make this a single

‘push button’ solution?

Image FPO

10

D e m o : A u t o m a t e c l o u d a d m i n i s t r a t i o n t a s k sw i t h A n s i b l e

10

11@ d j s t a y fl y p r o

cloud operator

cloud consumer

api cli

12@ d j s t a y fl y p r o

OpenStack Scenario #2As a cloud operator,what if you were tasked with creating 50 users and projects… • How long would it take you using Horizon? Using the CLI?• Keep in mind you have password standards to meet, given a tight

timeline and will need to avoid mistakes/typos.• What if you need to now adjust the quotas for all 50 projects next?

Image FPO

13

D e m o : A u t o m a t e m a n a g i n g m u l t i p l e c l o u d o r c h e s t r a t i o nw i t h O n e O p s

13

14@ d j s t a y fl y p r o

OpenStack Scenario #3As a cloud operator,what if you were tasked with managing two separate cloud regions in two separate datacenters… • Could you easily do this? Would you manage them as two separate

clouds or as one?• Would executing single API or CLI requests be enough?• Is there a way to have a single interface to handle them all?

Image FPO

15

‘ A D M I N I S T RAT I O N D E VO P S ’ S TAT E O F M I N D15

16@ d j s t a y fl y p r o

Cloud Lifecycle

DISCOVER/ASSESS

Compute

Memory

StorageSegregation

GoalsObjectivesOutcomes

ARCHITECT

Network

Redundancy

Sizing/Scaling Strategy

IMPLEMENT SUPPORT

Monitor

Troubleshoot

Escalation/Tickets

SECURITY

CAPACITY PLANNING

17@ d j s t a y fl y p r o

‘Administration DevOps’ Concepts and Principles

17

Automate everything – do it once and run it hundreds of times

Influence application design; cloudy applications should:

easily scale horizontally be designed to consume disposable

computing resources be designed in a share nothing approach

(stateless) be built in an DevOps model be built to expect failures

18

Q&A Sess ion

Twitter: @djstayflyproEmail: [email protected]

O N E FAN AT I C A L P L AC E | S A N AN T O N I O , T X 7 8 2 1 8U S S A L E S : 1 - 8 0 0 - 9 6 1 - 2 8 8 8 | U S S U P P O RT: 1 - 8 0 0 - 9 6 1 - 4 4 5 4 | W W W. RAC K S PAC E . C O M

© RACKSPACE LTD. | RACKSPACE® AND FANATICAL SUPPORT® ARE SERVICE MARKS OF RACKSPACE US, INC. REGISTERED IN THE UNITED STATES AND OTHER COUNTRIES. | WWW.RACKSPACE.COM

Thank youTwitter: @djstayflypro

Email: [email protected]