Taming Deployment with SmartFrog Steve Loughran Julio Guijarro HP - - PowerPoint PPT Presentation

▶
taming deployment with smartfrog
SMART_READER_LITE
LIVE PREVIEW

Taming Deployment with SmartFrog Steve Loughran Julio Guijarro HP - - PowerPoint PPT Presentation

Jan 30, 2024 347 likes •693 views

Taming Deployment with SmartFrog Steve Loughran Julio Guijarro HP Laboratories, Bristol, UK steve.loughran at hpl.hp.com julio.guijarro at hpl.hp.com About Us Steve Loughran Research scientist at HP Laboratories on Grid-Scale

slide-1
SLIDE 1

Steve Loughran Julio Guijarro HP Laboratories, Bristol, UK

Taming Deployment with SmartFrog

steve.loughran at hpl.hp.com julio.guijarro at hpl.hp.com

slide-2
SLIDE 2

Page 2 Taming Deployment with SmartFrog www.smartfrog.org

About Us

Steve Loughran

Research scientist at HP Laboratories on Grid-Scale Deployment Apache Ant & Axis committer Co-author of Java Development with Ant Writing the 2nd “Ant1.7” edition;

Julio Guijarro

Research scientist at HP Laboratories on Grid-Scale Deployment Leads the SmartFrog open source effort

slide-3
SLIDE 3

Page 3 Taming Deployment with SmartFrog www.smartfrog.org

The goal of our HPLabs research

  • How to host big applications

across distributed resources

– Automatically / Repeatably – Dynamically – Correctly – Securely

  • How to manage them from

installation to removal

  • How to make grid fabrics useful

for classic server-side apps

slide-4
SLIDE 4

Page 4 Taming Deployment with SmartFrog www.smartfrog.org

Deployment: why does it always go wrong?

Because

– it gets ignored – configuration is half the

problem

– nobody ever automates it – the tools are inadequate – it always goes wrong just

before you go live Deployment is unreliable, unrepeatable and doesn't scale

slide-5
SLIDE 5

Page 5 Taming Deployment with SmartFrog www.smartfrog.org

Configuration causes the problems

  • It’s the difference between

configurations that hurt

  • All those things that need to

be consistent

– configuration files – registry settings – router bindings – firewall – database – run-time values

  • Trying to track down

mismatches is hard

slide-6
SLIDE 6

Page 6 Taming Deployment with SmartFrog www.smartfrog.org

Choreography is “tricky”

Domain Controller & DNS Server Network filestore Database server App Server router

#0 #1 #2 #3 #3: app server #4: webapp (50% availability OK)

slide-7
SLIDE 7

Page 7 Taming Deployment with SmartFrog www.smartfrog.org

Deployment through development

development staging live system redistribution

configure for diagnostics & testing host on developers' boxes or local servers location/user specific configuration e.g. IP addresses, passwords, ... Self-diagnosis “near-live” configuration. Host on cut-down cluster; visible to partners managed by operations & dev teams ; 5x12 remote installation broadly accessible - secure High Availability/Fault Tolerant Scale on demand

  • perations team on call 7x24
slide-8
SLIDE 8

Page 8 Taming Deployment with SmartFrog www.smartfrog.org

  • configuration description

Configuration is deployment

Imagine a file that could declare the desired configuration state of a distributed system

– Define templates and extend them

to describe different configurations

– Cross-referencing to eliminate

duplication errors

– Composition for bigger systems

Create reality to match

– configure the declared items – start/stop them – adapt to failure or changing load

slide-9
SLIDE 9

Page 9 Taming Deployment with SmartFrog www.smartfrog.org

Imagine: SmartFrog

  • Distributed Deployment System
  • LGPL licensed
  • Written in Java
  • SourceForge hosted
  • http://smartfrog.org/
slide-10
SLIDE 10

Page 10 Taming Deployment with SmartFrog www.smartfrog.org

SmartFrog (Smart Framework for Object Groups)

A framework for describing, deploying and managing distributed service components.

  • A description language for specifying configuration
  • A runtime for realising the descriptions
  • A component model for managing service lifecycle
  • Components to deploy specific things

sfConfig extends WebService { WebServer extends LAZY Apache { port 8080; } AppServer extends Jboss; }

slide-11
SLIDE 11

Page 11 Taming Deployment with SmartFrog www.smartfrog.org

SmartFrog Description Language

  • A declarative, data description language

– Describes the configuration of a system

  • templates for deployment

– Prototypes to fill in with real values – Extend, override, combine

  • Service descriptions are interpreted by components hosted

by the runtime

– Semantics are not implemented in the language – Can accommodate wide range of services and models

slide-12
SLIDE 12

Page 12 Taming Deployment with SmartFrog www.smartfrog.org

SmartFrog Deployment Engine

SmartFrog Node SmartFrog Components Description / Code Repositories RMI RMI Deploy Descriptions SmartFrog Daemon SmartFrog Node SmartFrog Components SmartFrog Daemon SmartFrog Node SmartFrog Components SmartFrog Daemon RMI / (SOAP)

  • Distributed, decentralized, secure

deployment engine

  • Loads and instantiates the

components making up each service

  • Supplies the correct configuration

data to each component

slide-13
SLIDE 13

Page 13 Taming Deployment with SmartFrog www.smartfrog.org

access tier web tier application tier database tier edge routers routing switches authentication, DNS, intrusion detect, VPN 1st level firewall 2nd level firewall load balancing switches web servers web page storage (NAS) database SQL servers storage area network (SAN) application servers files (NAS) switches switches

  • min/max no. of

web servers

  • min no. of app

servers

  • specific EJB’s
  • size of data,
  • no. of tables

Template parameters

  • transaction rate
  • response times
  • constructed from templates for
  • web server
  • application server
  • …
  • example of multiple domains
  • (sub-)system templates require

strong notion of validation

  • collections of sub-templates are

a common feature

A complex template can cover everything

slide-14
SLIDE 14

Page 14 Taming Deployment with SmartFrog www.smartfrog.org

Goal: two tier app

MySQL database Tomcat server WAR application Two hosts

Database server MySQL App Server Tomcat +WebApp

slide-15
SLIDE 15

Page 15 Taming Deployment with SmartFrog www.smartfrog.org

MySQL

MySQLTemplate extends Prim { sfClass "org.sf.mysql"; port TBD; } sfConfig extends Compound { port 80; mySql extends MySQLTemplate { sfProcessHost "svr1"; port ATTRIB:port; db "myDB"; username "user"; password LAZY securePassW; } }

svr1 $ service service service service port=80 mySql mySql mySql mySql port=80 sfstart mySQL.sf svr1 service $ $ sfstart mySQL.sf svr1 service sfterminate svr1 service $ sfterminate svr1 service

slide-16
SLIDE 16

Page 16 Taming Deployment with SmartFrog www.smartfrog.org

Demo

MySQL

slide-17
SLIDE 17

Page 17 Taming Deployment with SmartFrog www.smartfrog.org

TomcatTemplate extends Prim { sfClass "org.sf.tomcat"; port TBD; peer TBD; } sfConfig extends Compound { port 80; tomcat extends TomcatTemplate { sfProcessHost "svr2"; port ATTRIB:port; peer LAZY svr1; } }

$ svr2

Tomcat

service service service service port=80 tomcat port=80 sfstart tomcat.sf svr2 service $ sfstart service.sf svr2 service $ sfstart tomcat.sf svr2 service sfterminate svr2 service $ sfterminate svr2 service

slide-18
SLIDE 18

Page 18 Taming Deployment with SmartFrog www.smartfrog.org

Demo: Tomcat + Web Application

slide-19
SLIDE 19

Page 19 Taming Deployment with SmartFrog www.smartfrog.org

Service extends Compound { sfClass "org.sf.service"; port TBD; } sfConfig extends Service { port 80; mySql extends MySQLTemplate { sfProcessHost "svr1"; port ATTRIB:port; } tomcat extends TomcatTemplate { sfProcessHost "svr2"; port ATTRIB:port; peer LAZY mySql; } }

svr1 $ svr2

Integration: Deploying a Service

service service service service port=80 mySql mySql mySql mySql port=80 tomcat port=80 peer sfstart service.sf svr1 service $ sfstart service.sf svr1 service $ sfstart service.sf svr1 service sfterminate svr1 service $ sfterminate svr1 service

slide-20
SLIDE 20

Page 20 Taming Deployment with SmartFrog www.smartfrog.org

Demo

Integration: Deploying everything

slide-21
SLIDE 21

Page 21 Taming Deployment with SmartFrog www.smartfrog.org

Components are like Ant tasks: they do the heavy lifting

Report to container/ping Halt the build or ignore Failure Lifecycle methods execute() Lifespan sfResolve() IntrospectionHelper Binding Component Task Unit of work System Project Unit of execution SmartFrog Daemon Ant Runtime SmartFrog Ant

slide-22
SLIDE 22

Page 22 Taming Deployment with SmartFrog www.smartfrog.org

Implementing a component

import com.hp.smartfrog.Prim.*; import java.rmi.*; public class Example extends PrimImpl implements Remote { private String hostname; public Example() throws RemoteException { } public void sfDeploy() throws Exception { super.sfDeploy(); hostname=sfResolve("hostname","",true); } public void sfStart() throws Exception { super.sfStart(); sfReplaceAttribute("Started",new java.util.Date()); } public void sfTerminateWith(TerminationRecored tr) { /* any component specific termination code */ super.sfTerminateWith(tr); } }

lifecycle methods called by the runtime extend base class implement a Remote interface

slide-23
SLIDE 23

Page 23 Taming Deployment with SmartFrog www.smartfrog.org

How to write a new one? Describing components

MyExample extends { sfClass "Example"; hostname "localhost"; } something extends MyExample { sfProcessHost "192.168.2.1"; sfProcessName "subproc-2"; hostname "laptop"; timestamp LAZY:Started; }

initial template component location

  • ther configuration data

instantiated

initialized

terminated

failed

running

sfDeployWith(ComponentDescription) sfDeploy() sfStart() sfTerminateWith(TerminationRecord)

Parse

slide-24
SLIDE 24

Page 24 Taming Deployment with SmartFrog www.smartfrog.org

Composition

Systems are composed of applications that are composed of components Applications: are deployed and managed as a group Built in components that manage other components

  • shared lifecycle (Compound): start and end components together
  • sequential: when one component stops, the next starts, …
  • parallel: start components together, but end separately
  • failure handling: start one component if another fails

mySystem extends Compound { appServer extends JBoss {} database extends Oracle {} apps extends Compound { ... } }

slide-25
SLIDE 25

Page 25 Taming Deployment with SmartFrog www.smartfrog.org

What ones do we have?

distributed unit testing JUnit configure JMX objects JMX integration dynamic node discovery SLP, Anubis HTTPD, jetty, tomcat, web page liveness check WWW: telnet, scp, ftp, email Networking remote forwarding/control of logs Logging sequential, conditional, retry operations Workflow shell scripts, Java, maven2 library download Execution tempfiles, directories, text & XML files Filesystem

slide-26
SLIDE 26

Page 26 Taming Deployment with SmartFrog www.smartfrog.org

Where is SmartFrog being used?

SE3D: HP/Alias Film Rendering:

http://se3d.co.uk/

CERN Openlab

  • Install, configure and uninstall a PBS/Torque cluster
  • SmartFrog RPMs (it also installs SF as a service)
  • http://openlab-mu-internal.web.cern.ch/

University UFCG, Brasil

  • JBOSS

http://www.lsd.ufcg.edu.br/~gustavo/smartfrog/jboss.tgz

PlanetLab: distributed application research

http://www.planet-lab.org/

slide-27
SLIDE 27

Page 27 Taming Deployment with SmartFrog www.smartfrog.org

Key points

  • Deployment and configuration is a serious

problem

  • Large Scale Deployment is fun research
  • With SmartFrog you can

– describe deployments – instantiate them across a network – host components that form the application

slide-28
SLIDE 28

Page 28 Taming Deployment with SmartFrog www.smartfrog.org

Get involved!

  • Download and play with the tool!
  • Join the mailing list and send us any questions!
  • Check out and build the code from CVS. Start with

small projects, work up to big clusters...

  • Look at http://se3d.co.uk/ to see what you can do

with 500+ servers For more information and downloads:

www.smartfrog.org

slide-29
SLIDE 29

Page 29 Taming Deployment with SmartFrog www.smartfrog.org

Questions?

slide-30
SLIDE 30

Page 30 Taming Deployment with SmartFrog www.smartfrog.org

LGPL?

  • Better that than inventing a new one.
  • Apache stance is currently “you can depend on, but

not redistribute LGPL libraries”

  • So use it, don’t be scared. LGPL only means you

must provide the source of any changes to SmartFrog or its bundled components, not any components/descriptors you write.

slide-31
SLIDE 31

Page 31 Taming Deployment with SmartFrog www.smartfrog.org

Security

  • SmartFrog needs to protect against deployment or
  • ther management actions from rogue entities
  • Cannot rely purely on SSH/user accounts/etc as

SmartFrog has active communicating agents

  • As SmartFrog downloads configuration descriptions

and code, we need to protect against introduction

  • f rogue code
  • Communications over SSL
  • Signed JARs to contain everything
  • Private CA for each deployment.
slide-32
SLIDE 32

Page 32 Taming Deployment with SmartFrog www.smartfrog.org

Not XML?

  • There is an XML derivative language being

standardised at the Global Grid Foundation

  • Join the CDDLM working group to get involved

– https://forge.gridforum.org/projects/cddlm-wg – http://xml.coverpages.org/computingResourceManagement.html#cddlm

  • We have found that an XML language is harder for

humans to work with, but it has value in XML/XSL pipelines, e.g. Cocoon, inside Ant, XDoclet...

  • XSD is particularly troublesome, as are bits of

XPath

  • Maybe RDF would be work better :)
slide-33
SLIDE 33

Page 33 Taming Deployment with SmartFrog www.smartfrog.org

The component lifecycle is that of a system

instantiated initialized terminated failed running sfDeployWith(ComponentDescription) sfDeploy() sfStart() sfTerminateWith(TerminationRecord)

slide-34
SLIDE 34

Page 34 Taming Deployment with SmartFrog www.smartfrog.org

  • Each configuration domain is associated with a configuration interpreter,

programmed to reify the configurations associated with that domain

  • Each description from a domain is matched with one of these interpreters

to reify the description

  • The full semantics of a description is defined by

interpreter + description

  • The description is in effect a parameter to the interpreter defining the

configuration state of the sub-system involved

  • Can freely define new interpreters and new "languages" as required

Components: Interpreters of Descriptions

I