Docker meetup - PaaS interoperability

Download Docker meetup - PaaS interoperability

Post on 14-Apr-2017

457 views

Category:

Internet

4 download

Embed Size (px)

TRANSCRIPT

<ul><li><p>1</p><p>Tl : +33 (0)1 58 56 10 00 Fax : +33 (0)1 58 56 10 01 www.octo.com OCTO 2013 </p><p>50, avenue des Champs-Elyses 75008 Paris - FRANCE </p><p>PaaS Interoperability </p><p>Thomas Lacroix &amp; Ludovic Piot </p></li><li><p>2</p><p>Agenda </p><p>CONTEXT AND PROJECT 1 </p><p>CLOUD COMPUTING AND PAAS 2 </p><p>STANDARDIZATION 4 </p><p>INTEROPERABILITY, PORTABILITY 3 </p><p>TECHNOLOGIES 5 </p><p>CAMP2DOCKER 6 </p></li><li><p>3</p><p>5 months </p><p>R&amp;D internship </p><p>lob.ops@octo </p><p>Context 1</p></li><li><p>4</p><p>Architecture and implementation of an interoperable PaaS solution</p><p>Project </p><p>Considering the: technical dimension: standard and technology study, architecture, implementation economical dimension: pricing, business model, economic impact of interoperability and standardization </p><p>1</p></li><li><p>5</p><p>Cloud computing 1 2</p><p>OpEx is </p><p>the New </p><p>CapEx* Operation expenditure ** Capital expenditure </p><p>*</p><p>** </p></li><li><p>6</p><p>Definition 1 2</p><p>Cloud computing is a model for enabling ubiquitous convenient on-demand network access to a shared pool of configurable computing resources networks servers storage applications services that can be rapidly provisioned released with minimal management effort service provider interaction </p></li><li><p>7</p><p>Models </p><p>CHARACTERISTICS </p><p>Public </p><p>Private </p><p>Hybrid </p><p>DEPLOYMENT </p><p>1 2</p><p>On-demand self-service Broad network access </p><p>Resource pooling </p><p>Rapid elasticity </p><p>Measured service </p></li><li><p>8</p><p>PaaS </p><p>The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using </p><p>programming languages and tools supported by the provider. </p><p>The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, </p><p>but has control over the deployed applications and possibly application hosting environment configurations </p><p>1 2</p></li><li><p>9</p><p>Agility and time-to-market Operational simplicity</p><p>Expertise Trade-offs between CapEx et OpEx</p><p>PaaS Benefits 1 2</p></li><li><p>10</p><p>PaaS Providers </p><p>PUBLIC BOTH/HYBRIDE PRIVATE </p><p>1 2</p></li><li><p>11</p><p>Market study </p><p>Magic Quadrant for Enterprise Application Platform as a Service </p><p>Magic Quadrant for On-Premises Application Platforms </p><p>1 2</p></li><li><p>12</p><p>PaaS Model 1 2</p></li><li><p>13</p><p>PaaS Model: Deis example 1 2</p></li><li><p>14</p><p>$ curl -sSL http://deis.io/deisctl/install.sh | sudo sh $ git clone https://github.com/deis/deis.git $ export DEIS_NUM_INSTANCES=3 </p><p>$ cd deis $ make discovery-url $ vagrant up $ ssh-add ~/.vagrant.d/insecure_private_key $ export DEISCTL_TUNNEL=172.17.8.100 $ deisctl install platform </p><p>$ deisctl start platform $ pip install ./client/ $ deis register http://deis.local3.deisapp.com $ deis keys:add </p><p>Provisionning 1 2</p></li><li><p>15</p><p>$ deis clusters:create dev local3.deisapp.com \ # create a cluster --hosts=172.17.8.100,172.17.8.101,172.17.8.102 \ </p><p> --auth=~/.vagrant.d/insecure_private_key </p><p>$ git clone https://github.com/deis/example-ruby-sinatra.git $ cd example-ruby-sinatra $ deis create Creating application... done, created lambda-hawthorn </p><p>Git remote deis added </p><p>Deploying onto 1 2</p></li><li><p>16</p><p>$ git push deis master Counting objects: 92, done. Delta compression using up to 4 threads. Compressing objects: 100% (87/87), done. </p><p>Writing objects: 100% (92/92), 19.29 KiB | 0 bytes/s, done. Total 92 (delta 40), reused 0 (delta 0) </p><p>-----&gt; Ruby app detected -----&gt; Compiling Ruby/Rack -----&gt; Using Ruby version: ruby-1.9.3 </p><p>-----&gt; Installing dependencies using 1.5.2 Running: bundle install --without development:test ... </p><p>-----&gt; Discovering process types Procfile declares types -&gt; web Default process types for Ruby -&gt; rake, console, web -----&gt; Compiled slug size is 12M -----&gt; Building Docker image </p><p>Uploading context 11.81 MB </p><p>Deploying onto 1 2</p><p>Step 3 : ENTRYPOINT ["/runner/init"] ---&gt; Running in 94eb867135db ---&gt; f49031ecd6c1 Successfully built f49031ecd6c1 </p><p>-----&gt; Pushing image to private registry Launching... done, v2 </p><p> -----&gt; lambda-hawthorn deployed to Deis http://lambda-hawthorn.local3.deisapp.com </p><p> To learn more, use `deis help` or visit http://deis.io </p><p> To ssh://git@local3.deisapp.com:2222/lambda-hawthorn.git </p><p> * [new branch] master -&gt; master </p></li><li><p>17</p><p>$ curl -s http://lambda-hawthorn.local3.deisapp.com Powered by Deis! </p><p>Running onto 1 2</p></li><li><p>18</p><p>$ deis scale web=4 Scaling containers... but first, coffee! </p><p>done in 12s </p><p>Scaling out with 1 2</p></li><li><p>19</p><p>Pricing: Heroku </p><p>Computing Units </p><p>Database </p><p>Support </p><p>1 2</p></li><li><p>20</p><p>Pricing: Heroku </p><p>Add-ons </p><p>1 2</p></li><li><p>21</p><p>Pricing: Openshift Online 1 2</p></li><li><p>22</p><p>Pricing: AWS Elastic Beanstalk 1 2</p></li><li><p>23</p><p>Pricing: Google App Engine </p><p>Computing Units </p><p>Database </p><p>Search </p><p>1 2</p></li><li><p>24</p><p>Use Case Cloud Computing Discussion Group: the ability to write code that works with more than one Cloud provider simultaneously, regardless of the differences between the providers </p><p>Cohen: Cloud computing interoperability is the ability for multiple Cloud providers to work together* or interoperate, whereas Cloud portability is the ability of data and application components to be easily moved and reused regardless of the provider, operating system, storage, format or API </p><p>Goyal: * including process execution, security, migration/cloning control, standards, transparency, and manageability and regulatory compliance </p><p>Definitions of Cloud computing interoperability 1 2 3</p></li><li><p>25</p><p>Distributed Computing Reference Model </p><p>http://www.opengroup.org/cloud/cloud/cloud_iop/dcrm.htm </p><p>Categories of portability and interoperability </p><p> Data Portability Application Portability Platform Portability Application Interoperability Platform Interoperability Management Interoperability Publication and Acquisition Interoperability </p><p>1 2 3</p></li><li><p>26</p><p>Challenges 1 2 3</p></li><li><p>27</p><p>Benefits 1 2 3</p></li><li><p>28</p><p>Scenarios 1 2 3</p></li><li><p>29</p><p>Federation 1 2 3</p></li><li><p>30</p><p>Standards 1 2 3 4</p></li><li><p>31</p><p>The standardization initiatives seem to rotate around three key enablers for tackling Cloud computing interoperability. </p><p> a standardized API/interface and a common management model a common data model/semantic the utilization of a marketplace/broker </p><p>Approaches 1 2 3 4</p></li><li><p>32</p><p>Cloud Standards 1 2 3 4</p></li><li><p>33</p><p>Official description: The OASIS TOSCA TC works to enhance the portability of cloud applications and services. </p><p> TOSCA will enable the interoperable description of application and infrastructure cloud services, the relationships between parts of the service, and the operational behavior of these services (e.g., deploy, patch, shutdown)--independent of the supplier creating the service, and any particular cloud provider or hosting technology. </p><p>Formed in January 2012 </p><p>OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) </p><p>1 2 3 4</p></li><li><p>34</p><p>TOSCA: Members 1 2 3 4</p></li><li><p>35</p><p>Standardizes the language to describe The infrastructure of an IT Service (the topology) How to orchestrate operational behaviour (plans such as build, deploy, patch, shutdown, etc.) </p><p>Declarative model that spans applications, virtual and physical infrastructure </p><p>TOSCA: What is it ? 1 2 3 4</p></li><li><p>36</p><p>TOSCA: Service template 1 2 3 4</p></li><li><p>37</p><p>Topology example 1 2 3 4</p></li><li><p>38</p><p>Topology example 1 2 3 4</p></li><li><p>39</p><p>Topology example 1 2 3 4</p></li><li><p>40</p><p>Orchestration plan 1 2 3 4</p></li><li><p>41</p><p>Declarative -&gt; What ? I want this, realize it ! Runtime interprets topology and does deployment </p><p>Imperative -&gt; How ? First do this, then do that Management plan explicitly describes each step </p><p>Orchestration 1 2 3 4</p></li><li><p>42</p><p>Cloud Service Archive (CSAR) 1 2 3 4</p></li><li><p>43</p><p>Architecture of a TOSCA environnent 1 2 3 4</p></li><li><p>44</p><p>Official description: The OASIS CAMP TC advances an interoperable protocol that cloud implementers can use to package and deploy their applications. </p><p> CAMP defines interfaces for self-service provisioning, monitoring, and control. Based on REST, CAMP is expected to foster an ecosystem of common tools, plugins, libraries and frameworks, which will allow vendors to offer greater value-add </p><p>Formed in August 2012 17 members: </p><p>OASIS Cloud Application Management for Platforms (CAMP) </p><p>1 2 3 4</p></li><li><p>45</p><p>Resource Model and Interface RESTfull API JSON serialization Models applications, components, services and their relationships Extensible </p><p>Application description and packaging ZIP, TAR or TGZ YAML metadata Extensible </p><p>Language, framework and platform agnostic </p><p>CAMP: What is it ? 1 2 3 4</p></li><li><p>46</p><p>Interoperably manage applications and their use of the platform Deploy Manage lifecycle (configure/customize, start, stop, snapshot, suspend, restart, delete) </p><p> Monitoring Portably migrate applications between platforms </p><p> Construct a package and deploy it Export a package from one platform and deploy it to another </p><p>nCAMP: existing demo CAMP implementation http://ec2-107-20-16-71.compute-1.amazonaws.com/campSrv/ </p><p>CAMP: What can it do ? 1 2 3 4</p></li><li><p>47</p><p>CAMP Ressources 1 2 3 4</p></li><li><p>48</p><p>name: VitaMinder description: Vitamin and Supplement Tracking camp_version: CAMP 1.1 origin: http://www.oracle.com/nCAMP/Hand artifacts: - name: VitaMinder WAR artifact_type: com.oracle.nCAMP:WAR content: { href: VitaMinder.war } requirements: - requirement_type: com.oracle.nCAMP:ConnectTo com.oracle.nCAMP.dbName: VitaMinder fulfillment: id: db characteristics: - characteristic_type: com.oracle.nCAMP:SQL - requirement_type: com.oracle.nCAMP:HostOn fulfillment: characteristics: - characteristic_type: com.oracle.nCamp:ServletContainer - name: Supplement SQL artifact_type: com.oracle.nCAMP:SQL_script content: { href: vitaminder.sql } requirements: - requirement_type: com.oracle.nCAMP:LoadInto fulfillment: id:db </p><p>CAMP: Planfile example 1 2 3 4</p></li><li><p>49</p><p>Deployment 1 2 3 4</p></li><li><p>50</p><p>Technologies 1 2 3 4 5</p></li><li><p>51</p><p>I. Codebase: One codebase tracked in revision control, many deploys II. Dependencies: Explicitly declare and isolate dependencies III. Config: Store config in the environment IV. Backing Services: Treat backing services as attached resources V. Build, release, run: Strictly separate build and run stages VI. Processes: Execute the app as one or more stateless processes VII.Port binding: Export services via port binding VIII.Concurrency: Scale out via the process model IX. Disposability: Maximize robustness with fast startup and graceful </p><p>shutdown X. Dev/prod parity: Keep development, staging, and production as similar as </p><p>possible XI. Logs: Treat logs as event streams XII.Admin processes: Run admin/management tasks as one-off processes </p><p>1 2 3 4 5</p></li><li><p>52</p><p>1 2 3 4 5</p></li><li><p>53</p><p>1 2 3 4 5</p></li><li><p>54</p><p>1 2 3 4 5</p></li><li><p>55</p><p>Docker containers orchestration </p><p>Using a configuration file </p><p>Used with Orchard (CaaS solution) </p><p>Bought by Docker in July 2014. </p><p>1 2 3 4 5</p></li><li><p>56</p><p>libswarm is a toolkit for composing network services. </p><p>It defines a standard interface for services in a distributed system to communicate with each other. This lets you: </p><p> Compose complex architectures from reusable building blocks Avoid vendor lock-in by swapping any service out with another </p><p>1 2 3 4 5</p></li><li><p>57</p><p>camp2docker 1 2 3 4 5 6</p><p>camp.yaml </p></li><li><p>58</p></li><li><p>59</p><p>BACKUP </p></li><li><p>60</p><p>Total Cost of Ownership (TCO) Cots lis lachat, proprit, utilisation et maintenance dun produit </p><p>Availability Temps de disponibilit dun service sur une priode donne </p><p>Time to Market Temps pour implmenter une nouvelle application, ou pour pousser un nouveau service sur le march </p><p>Opportunity Costs Manque gagner potentiel entre deux investissements </p><p>Churn Rate Nombre de clients perdus dans une priode donne </p><p>Productivity Mesure de lefficacit dun dpartement ou dune entreprise Peut tre calculer grossirement comme le revenue par tte </p><p>Service Level Agreement (SLA) Contrat dans lequel on formalise la qualit du service en question </p><p>Mtriques indirectes </p></li><li><p>61</p><p>Non-Recurring Costs Acquisition Implementation </p><p>Ongoing Costs Application Deployment and Testing Vendor Support Administration &amp; Management Monitoring, Diagnostics &amp; Tuning </p><p>Cost model </p></li><li><p>62</p><p>Payback method Temps requis pour recouvrer linvestissement dans un produit ou service </p><p>Net Present Value (NPV) Flux de trsorerie actualis reprsentant l'enrichissement supplmentaire d'un investissement par rapport au minimum exig par les apporteurs de capitaux </p><p>Return on investment (ROI) Ratio financier qui mesure le montant d'argent gagn ou perdu par rapport la somme initialement investie dans un investissement </p><p>Mtriques directes </p></li></ul>