Download præsentationen
Præsentation er lastning. Vent venligst
Offentliggjort afRasmus Mortensen Redigeret for ca. et år siden
1
Fra classic til cloud - Cloud based build & deployment IT & Telestyrelsen 2010 Møde d. 13 april 2010
2
Agenda • Introduktion - Hvad betyder skyen • Paradigmeskifte – Fra ”classic” til ”cloud” • Case: TradeShift – Lessons learned • Build, deploy og operation • Erfaringer og opsummering • Spørgsmål
3
I think there is a world market for maybe five computers -- ”Berømt” citat af Thomas Watson, IBM 1943
4
De fem computere i verden • Amazon EC2 • Google AppEngine • Microsoft AZURE • Salesforce Force.com • Facebook Applications
5
Vi er en forholdsvis lille planet • 6.880.100.000 beboere (wikipedia.com) • 1.966.000.000 er on-line (internetworldstats.com) • 500.000.000 er på Facebook (facebook.com) – De bruger i øvrigt 700.000.000.000 minutter per måned (23 timer/bruger/måned) – Ca. 25% af markedet – FB viser 1.000.000.000.000 Ads per år. (mashable.com)
6
Cloud – et ny paradigme • Internet hastighed og båndbredde til alle • WiFi og Mobil høj(nok)hastighed ”overalt” • Ekstrem skalerbar service – 1 til 100 servere på ”no time” • Integration med andre systemer – REST, Soap, XML, JSON • Apps til kundespecifikke funktioner
7
Fra Classic til Cloud Classic Som vi gjorde for 10 år siden Classic Som vi gjorde for 10 år siden Cloud Som vi gør det I dag Cloud Som vi gør det I dag
8
Erfaringer– Classic • SDC – Netbank, Aktie handels portal, CMS til 150 penge institutter i Norden, performance optimering • CSC, PBS – Payment gateway, Logistic hub integration Deutche Post • Nykredit, KMD – Konsulent arbejde • FedEx, Aldo, DHL, LaPoste, Sydney Airport, … – Logistik styrings opgaver og integration
9
Erfaring(er)- Cloud • Tradeshift – Global E-faktura – Amazon EC2, github, zendesk, • Bookieman.net – Vagt planlægning og afvikling – Rackspace, bitbucket • OfficeDesign – Mindre dansk, nu ”virtuelt” firma – Basecamp, Highrise, Bitbucket, Gmail, GAE, Hyperspin, e- conomics
10
Teknologier ClassicCloud Udviklings paradigmeVandfaldAgil Programmerings sprogStatisk (Java, C#, C++)Dynamisk (Python, Ruby, Scala) SCMVCS (CVS, SVN)DVCS (Mercurial, git) RepositoryIntern serverBitbucket, github, code.google.com, codeplex HostingInterne servereAmazon, Google, AZURE, Salesforce, Facebook Mail og kalenderExchange, GroupWise, Notes Gmail, Google Apps Projekt styringMS ProjectBasecamp, PODIO, Timelog Issue trackingExcel, AccessTrac, Jira CRMMS CRM, SuperOfficeSalesforce, highrise
11
Build, test, deploy - Classic Devel Test Staging Produktion Repository •Single repository (Subversion, CVS) •Lokale udviklingsmaskiner •Testsetup er nedskaleret version af produktion •Staging ligner produktion •Kode skubbes fremad i systemet, ofte med manuelle operationer •Stor forskel på Test og Produktions miljø •Produktion står stille medens ny kodebase installeres •Rollback kan være svær
12
Build, test, deploy - Cloud Build Test Produktion2 Repository Devel Artifacts Produktion1Produktionn •Distribueret versions kontrol •Test, Staging og Produktion er ens •Pull arkitektur •Switch Staging til Produktion
13
Drift, support og overvågning • Classic • Drift – Bemandet kontrol rum • Overvågning – TNG, Tivoli, OpenView • Support – Lokal løsning • Cloud • Drift – Hotline/SMS • Overvågning – Hyperspin, site24x7.com, Hyperic • Support – Zendesk
14
Case - TradeShift • Global e-faktura management – Med Social media dimension • Historie – 2009 Dec Første design møde – 2010 Maj Produktion DK – 2010 Jul Launch EU – 2010 AugLaunch USA • Ekstrem skalerbar forretning – 0 til 1.000.000 brugere på et kvartal
15
Amazon Elastic Compute Cloud (EC2) • AMI – Amazon Machine Image: Et image som er gemt. • S3 – Snapshot af AMI gemmes her. • Instans: Kørende version af AMI. En ”PC” der kan installeres og konfigureres efter behov. • EBS – Elastic Block Store: Persistent lagring. • EIP – Elastic IP Addresses: Reservering af ”fast” IP adresse. • Security groups: Amazon firewall som kobles på instanser når de startes. • CloudWatch: Metrikker på en instans. • Auto Scaling: Oprettelse af nye instanser baseret på metrikker. • ELB – Elastic Load Balancing: Distribuering af trafik imellem instanser.
16
Amazon EC2 i use case contekst Frontend Backend PostgreSQL ESB (API) I.S. Public zone DMZ Private zone
17
Build • ”Single” click build og release af projekter. • Build – Fleksibel, åben og næsten standard. • Versionering af pakker, moduler og releases. • Cloud baseret build/deploy servere. • Nye releases kan automatisk deployes • Nye instanser startes automatisk
18
Build arkitektur Mercurial Hudson Nexus Maven
19
Build, Test and Deploy
20
Deploy • ”Single” click deployment af servere og services, hvor alt sættes op automatisk. • Automatiserede tests køres efter deploy. • Minimalt manuelt arbejde sikrer maksimal tiltro til deploy. • Fleksibel overgang fra test til staging, og videre til produktion. • Opstramning i release proceduren konfigureres efter behov. • Framework er allerede lavet. Konfigureres vha. XML. • Nye komponenter tilføjes i Python
21
Deployment cycle Hudson build Hudson build Change production servers Configure servers Install packages Restore Backup snapshot Create packages Create servers Test deployment
22
Operation • Hyperic – Overvågning af instanser og deploys. • Hyperic agenter konfiguration igennem deployment. • Hyperic server er placeret i EC2. • 24/7 hotline.
23
• Module release • Tradeshifts release Software release
24
Deploy • Software release – Moduler der skal fordeles
25
Deploy • Moduler fordelt på forskellige servere
26
Deploy • Hvordan deployes der til Amazon instanser – Deploy tool opbygning Test Staging Production Id Step 1 Step 2 Step 3 Step n Step 2 Step 3 Step 5 Step 2 Step 7 Step 8 (Data)
27
Deploy • Hvordan deployes der til Amazon instanser – Deploy opdelt i ansvarsområder / steps 1.”Capture data” fra fra kørende build 2.”Instantiate amazon resources” 1.Instance, EIP, EBS, S3 access, SQS etc 3.”Configure modules” dynamisk konfiguration af moduler i forhold til det aktuelle deploy 4.”Create install packeges” pak software + konfiguration + installere i zip filer til brug på nye amazon instanser 5.”Install instances” kopier og intaller software på amazon instanser 6.”Restore persistent data” tag test/produktions data fra backup og ”rul ud” på nye instanser 7.”Integrations test” test at systemet fungere med test/produktions data
28
Dynamisk konfiguration af moduler i forhold til det aktuelle deploy (Data) Konfigurations- database Server layout Ekstra konfigurations værdier ’Secrets’ Module A Module B Module C
29
Konfiguration af deploy • Deploy konfiguration – Software release – definere software releasen der skal benyttes (version, snapshot, beta, rc, final) – Server layout – Service – information om diverse services – Security group – firewall konfiguration – Instance type – server størrelsen – Elastic ip – ved brug af fast ip – Elastic blok store – hardisk snapshot der skal benyttes – Software component – En component svarer til Maven artifact, e.g. Tradeshift-backend
30
Konfiguration af deploy • Deploy specifikke værdier – Forskellige backup lokationer – Loglevel - Debug i Test – Forskellige email setups, alle mails til test eller rigtig email udsendelse – Opsætning af database driver: e.g. postgres til test, oracle til produktion – Generelt kan der gives ekstra konfiguration med heri
31
Konfiguration af deploy • Håndtering af ’secrets’ – keys – Key filer – ssh, keystore, ssl certifikater – Password • Deploy server er ”trusted” og indeholder alle ’secrets’ – Man refererer fra deployConfiguration.xml til stier / filer på build serveren – Deploy konfigurerer moduler med adgang til databaser, backup, nøgler mm.
32
Konfiguration af deploy • Modulers ’config’ folder – Mulighed for at customisere en installerings sekvens på serveren – Mulighed for at medbringe filer, zip filer, kataloger m.m. – Konfiguration af.xml og.properties filer med • Konfiguration af værdier som først er kendt på deploy tidspunkt – Private / public ip’er af servere – Private / public ip’er af forskellige software serivices • Deploy specifikke værdier – Modul specifikke værdier – Værdier fra deployment
33
Konfiguration af deploy • Eksempel på.properties fil • Eksempel på.xml fil commercial = ${server.Frontend-Product.privateDns} product = ${server.Frontend-Commercial.privateDns} commercialPublic = ${server.Frontend-Product.publicDns} productPublic = ${server.Frontend-Commercial.publicDns} tradeshift-backend
34
Erfaringer • Lokal test bliver sværere for udviklere – Men fuld deploy og test er meget nemmere. • Forholdet til servere og testmiljø ændrer sig væsentligt for udviklere. – Nu er der løbende forsøg på at reducere antal kørende servere • Der er altid styr på konfiguration. – Der kan ikke deployes uden • Continuous integration fungerer.
35
Forbrug og priser • 9 dages periode ~ 17 instanser i gennemsnit • 1 måned – 1 instans ~ 78$ – Samt det løse
36
Næste projekt – lessons learned • Overvågning fra anden sky – Fx. Google • DVCS frem for VCS – Mercurial frem for Subversion • Pull frem for Push under deploy • Endnu mere dynamik – Python frem for Java • Fleksibilitet frem for performance
37
Referencer Logistics… Sikre track and trace på alle det Britiske forsvars forsendelser. Udvikler interface system til kommunikation mellem PostDanmark’s systemer – for alle pakker sendt med PostDanmark. Sikre at de I Charles De Gaul fragt terminal kan udføre statistik på hele deres operation – så der kan optimeres på processerne. Håndtere den interne styring af kufferter mellem flyene I Lufthavnen I Sydney.
38
Kontakt info René Nejsum e-mail: rne@logistics.as Tlf. 29 99 19 70 Logistics A/S Gasværksvej 26B 9000 Aalborg
Lignende præsentationer
© 2024 SlidePlayer.dk Inc.
All rights reserved.