dotCloud and go

879 views
811 views

Published on

Published in: Technology
1 Comment
2 Likes
Statistics
Notes
No Downloads
Views
Total views
879
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
10
Comments
1
Likes
2
Embeds 0
No embeds

No notes for slide
  • \n
  • È utile riferire il contenuto della presentazione ad un esempio di massima... ed in questo caso mi riguarda da vicino!\n
  • Sicuramente non ve ne sarete accorti, ma sono un tantino sovrappeso. L’idea è quella di un sistema per la registrazione giornaliera del mio peso... quantomeno per vergognarmi a dovere!\n
  • Il sistema è costituito da quattro blocchi funzionali separati: un front-end per l’interazione con gli utenti, un database “no SQL” per memorizzare i dati dell’ultimo mese, un back-end per le operazioni dietro le quinte ed un database SQL per registrare i dati da qui all’eternità. Certo, un’architettura un po’ roboante per registrare una sola misurazione al giorno, ma diciamo che vista la stazza il sistema si potrebbe appesantire rapidamente.\n
  • L’interazione dell’utente è con il Front-End attraverso l’utilizzo di un comune browser; il Front-End interagisce a sua volta con il database “no SQL” (redis in particolare) per sia per visualizzare i dati relativi all’ultimo mese che per registrarne di nuovi. In particolare, si può: visualizzare i dati mensili di ciascun utente, inserire una nuova misura oppure richiedere l’export dei dati storici relativi ad un utente (questo export verrà spedito via email a cura del Back-End).\n
  • Redis implementa un meccanismo Sottoscrizione/Pubblicazione molto comodo per gestire delle code; il Back-End è impostato per ascoltare le notifiche tanto in relazione all’inserimento/aggiornamento dei dati di peso di un giorno (per salvarli nel database completo) quanto per ricevere le richieste di export dei dati. In entrambi i casi viene utilizzata una lista per trasferire i dati secondo una gestione a coda, ed il meccanismo di notifica per evitare che il Back-End faccia richieste continue per vedere se ci sono nuovi dati.\n
  • Come conseguenza dell’inserimento/aggiornamento di uno o più dati di peso, il Back-End consuma la coda relativa ai “new-weights” provvedendo all’inserimento nel database MySQL. Una volta terminato si rimette in ascolto aspettando la notifica successiva.\n
  • Analogamente, il Back-End consuma anche la coda di richieste di export dei dati, provvedendo a raccogliere i dati dal database per l’utente richiesto, formattarli come file CSV e spedirli via email all’indirizzo passato dal Front-End nella richiesta di export.\n
  • I quattro elementi base dell’architettura sono stati implementati con tecnologie differenti: Perl/Dancer per il Front-End e Perl “semplice” per il Back-End, oltre ovviamente ai due database basati su Redis e MySQL.\n
  • Il problema ora è che questo marchingegno dovrebbe essere messo da qualche parte a cui posso accedere facilmente ovunque mi trovi...\n
  • ... il che poi non è l’unico problema, perché dovrò anche capire come farò a mettere tutti questi elementi differenti...\n
  • ... per non parlare del fatto che tutto questo processo mi richiederà plausibilmente una bella fetta di tempo.\n
  • E qui, finalmente, dopo solo 13 slide... arriviamo a dotCloud.\n
  • La homepage è piuttosto invitante: sono disponibili tante combinazioni in “stack” applicativi differenti in una piattaforma di controllo e gestione unica, il che sembra l’ideale per ospitare la nostra applicazione che è basata su quattro elementi differenti fra loro. Fortunatamente - altrimenti questa presentazione avrebbe avuto seri problemi - questi quattro elementi che abbiamo scelto sono tutti supportati.\n
  • Di cloud c’è molto da parlare, soprattutto perché dopo il calcio sembra un argomento in cui ognuno ha una sua idea. All’interno della tassonomia più classica - l’Infrastruttura come Servizio, la Piattaforma come Servizio, il Software come Servizio - dotCloud si colloca decisamente come un un fornitore di Piattaforma, ossia strizza l’occhio allo sviluppatore dandogli un ambiente che NON deve gestire a più basso livello (come sarebbe successo con IaaS, ad esempio Amazon EC2 o Rackspace Servers) ma che gli consente di implementare la propria applicazione, non di utilizzarne una già costruita (come avviene tipicamente con SaaS).\n
  • Di cloud c’è molto da parlare, soprattutto perché dopo il calcio sembra un argomento in cui ognuno ha una sua idea. All’interno della tassonomia più classica - l’Infrastruttura come Servizio, la Piattaforma come Servizio, il Software come Servizio - dotCloud si colloca decisamente come un un fornitore di Piattaforma, ossia strizza l’occhio allo sviluppatore dandogli un ambiente che NON deve gestire a più basso livello (come sarebbe successo con IaaS, ad esempio Amazon EC2 o Rackspace Servers) ma che gli consente di implementare la propria applicazione, non di utilizzarne una già costruita (come avviene tipicamente con SaaS).\n
  • Non rimane che iscriversi, tanto è gratuito...\n
  • ... anche se dovrete riempire un po’ di scartoffie digitali.\n
  • Se avete un account, potete entrare e trovare la roboante “dashboard” di ingresso...\n
  • ... ossia una pagina piuttosto anonima che vi invita ad installare il programma di controllo a linea di comando. Questa pagina dovrà cambiare, spero non sia avvenuto prima di questo talk!\n
  • Lo strumento principale di interazione con dotCloud è - secondo il principio della minima sorpresa - un programma che si chiama dotcloud.\n
  • Installarlo dovrebbe essere piuttosto semplice, visto che il modo consigliato per farlo è utilizzare un altro programma chiamato “easy_install”. Diciamo che quanto a marketing siamo sulla strada giusta... ma il marketing non basta.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Non ostante easy_install sia supportato anche da versioni precedenti di Python, per utilizzare dotcloud (il programma) è necessario avere Python 2.7 almeno, ma non Python 3.\n
  • Questo può essere un problema per parecchi, perché se siete dei nostalgici come me starete utilizzando una distribuzione che probabilmente ancora non include questa versione di Python. A me è toccato installarlo a mano. Dunque easy_install è un ottimo gestore... il problema è tutto quello su cui poggia! Sarebbe stato bello avere pythonbrew... o quantomeno sapere se c’erano alternative.\n
  • Siamo pronti per creare la nostra prima applicazione. Il principio della minima sorpresa continua a spadroneggiare, perché basta lanciare il sottocomando “create” dando il nome della nostra applicazione.\n
  • L’applicazione, in particolare, è stata organizzata in una struttura come quella in figura: il Front-End ha una sua directory “www”, il Back-End una sua “backend”. Oltre a queste due cartelle si nota la presenza di un file di configurazione YAML il cui nome lascia sospettare la sua destinazione.\n
  • Il file è in effetti quanto verrà utilizzato per costruire il nostro stack applicativo.\n
  • In particolare possiamo riconoscere, a livello più elevato, i differenti servizi necessari per realizzare la nostra applicazione. Per ciascun servizio viene specificato il “type”, ossia “perl” per applicazioni di Front-End web, “perl-worker” per applicazioni di Back-End in Perl, redis e mysql per i due tipi di database.\n
  • Nel file specifichiamo anche che le directory di base per Front-End e Back-End sono separate, in modo che possiamo avere una struttura pulita. DotCloud saprà quindi che nelle macchine dove verrà realizzato il Front-End la directory di riferimento sarà “www”, mentre in quelle del Back-End sarà “backend”.\n
  • Il tipo di servizio “perl” è orientato alla realizzazione di Front-End di tipo web basati, per l’appunto, su Perl. Il modello di riferimento in questo caso è quello dell’interfaccia PSGI, che costituisce un porting piuttosto felice nel mondo Perl di idee nate in ambito Ruby/Python. Non ostante la directory abbia vari elementi, quelli realmente interessanti per dotCloud sono due: app.psgi e Makefile.PL.\n
  • app.psgi, in particolare, è l’applicazione web vera e propria. Deve SEMPRE esistere in un servizio dotCloud di tipo “perl”. Nel caso specifico si è utilizzato il framework Dancer, molto comodo e costruito in modo da rispettare l’interfaccia PSGI. Come si potrà intuire, la vera “ciccia” dell’applicazione si trova all’interno del modulo “whatever”, che - l’avrete già indovinato - è nella directory lib. In realtà qui però può esserci qualunque cosa che possa essere considerata aderente alle specifice PSGI.\n
  • L’altro file molto importante - per quanto tecnicamente non obbligatorio - è Makefile.PL. Va generato in maniera analoga a quanto si farebbe per una distribuzione su CPAN; come in quel caso, quindi, è utile perché contiene una sezione PREREQ_PM dove possiamo andare ad inserire tutti i prerequisiti della nostra applicazione web.\n
  • La tipologia di servizio “perl-worker” è anch’essa basata su Perl, ma è orientata all’esecuzione di programmi di lunga durata (demoni). Anche in questo caso il file Makefile.PL può/deve essere utilizzato per specificare i requisiti in termini di moduli da installare, altrimenti il perl che avremo a disposizione non ci permetterà di lavorare.\n
  • Il file più peculiare in questo caso è però supervisord.conf, che non è altro che il file di configurazione del progamma supervisord. Tramite questo file possiamo specificare quanti programmi devono essere eseguiti contemporanemente e monitorati per controllare che vengano tenuti in esecuzione. Ovviamente potrete soddisfare ogni vostra curiosità su http://supervisord.org/; nel caso in questione, basta notare che per ciascun demone c’è un titolo con il nome da dare ed una riga “command” dove specifichiamo cosa va eseguito.\n
  • Avrete sicuramente fatto caso che nella specifica dei comandi compaiono dei percorsi piuttosto curiosi. Ebbene sì, poiché questi programmi verranno eseguiti su delle macchine... queste macchine hanno un filesystem ed i vostri programmi del Back-End li troverete proprio lì!\n
  • In particolare, quando la vostra applicazione viene distribuita, all’interno della macchina del Back-End (nel Front-End è analogo) viene creata una directory con la directory base che ha un nome non anticipabile. Il sistema di dotCloud, però, vi garantisce che verrà anche creato un link simbolico che da /home/dotcloud/current punta verso la directory principale del servizio.\n
  • In poche parole, /home/dotcloud/current non fa altro che puntare a quella sottodirectory che abbiamo specificato come “approot” nel file di configurazione dotcloud.yml.\n
  • Abbiamo capito cosa succede a Front-End e Back-End... ma per i database che succede? In realtà vengono create delle macchine virtuali “speciali” anche in quel caso - la specialità risiede nel fatto che le macchine di tipo “redis” contengono il server ed il client Redis e quelle di tipo MySQL... lo avrete già indovinato.\nIl problema però è: come ci si connette a questi due database? Dove stanno, soprattutto?\n
  • Per rispondere a queste domande dobbiamo tornare alla struttura delle directory che ci troviamo nelle macchine del Front-End e del Back-End. Abbiamo già detto che /home/dotcloud/current punta alla directory specificata come approot per ciascuna applicazione, ma nella directory /home/dotcloud ci sono altri due file interessanti: environment.yml (in formato YAML) ed environment.json (in formato JSON).\n
  • Molto prosaicamente, questi due file contengono entrambi le informazioni necessarie per raggiungere i servizi dati del nostro stack, includendo cioè gli indirizzi di dove si trovano, su quale porta sono in ascolto e quali sono le credenziali di accesso.\n
  • A questo punto, a seconda che ci piaccia di più JSON o YAML, è facile scrivere una routine che va a leggere il file di configurazione giusto per caricare le differenti variabili che ci servono per la connessione.\n
  • Per Redis avremo bisogno della password e dei dettagli sulla connessione, ossia il nome della macchina su cui è ospitato il nostro servizio e la porta. Nel restituire un oggetto Redis facciamo anche un favore all’utente e “sblocchiamo” la connessione inviando la password.\n
  • Incidentalmente, “get_redis” fa ridere. Beh, almeno MI fa ridere.\n
  • \n
  • Per la connessione MySQL il discorso è analogo: basta andare a prendere le variabili giuste dalla configurazione caricata e creare l’oggetto utilizzando il modulo DBI. Il resto è roba standard.\n
  • Questo codice è in realtà utile tanto al Front-End quanto al Back-End... dove collocarlo? Occorre duplicare?\n
  • L’aspetto interessante è che sia l’istanza di Front-End che quella di Back-End contengono in realtà tutto il codice, ossia anche quello dell’altra istanza. Analogamente a quanto succede con /home/dotcloud/current (che punta alla appdir impostata nel file dotcloud.yml), l’infrastruttura di dotCloud crea anche un link simbolico che da /home/dotcloud/code punta alla directory principale della distribuzione.\n
  • Con questi presupposti, dunque, la soluzione più semplice è quella di aggiungere un’area comune a cui i vari servizi possono attingere.\n
  • Nel caso specifico, però, c’è un modulo su CPAN che serve proprio a questo scopo...\n
  • ... ma non ne parleremo oltre, visto che si tratta di autopromozione!\n
  • \n
  • Per andare in produzione è sufficiente “spingere” la nostra applicazione su dotcloud. La prima volta verranno normalmente inizializzati gli ambienti caricando i vari moduli impostati nei prerequisiti, quindi ci metterà un po’ di tempo; successivamente dovrebbe essere più rapido, a meno di non aggiungere svariati altri prerequisiti.\n
  • Nel caso dell’esempio io utilizzo git, per cui dotcloud “sa cosa fare” e prende i file da git. Questo è un punto su cui occorre fare attenzione, perché per default va a prendere il ramo “master” e non è detto che sia quello su cui state lavorando o che sia quello che volete effettivamente attivare su dotCloud.\n
  • Se utilizzate mercurial il comportamento è analogo.\n
  • In alternativa potete non utilizzare nessuno dei due, nel qual caso il meccanismo di invio scelto da dotcloud sarà rsync.\n
  • \n
  • Nel tempo di questa breve digressione il caricamento dell’applicazione dovrebbe essere terminato.\n
  • Il programma dotcloud mette a disposizione vari comandi; in questa fase, è utile vedere cosa sia stato effettivamente creato per la nostra applicazione - ossia il nostro “stack” - e dove sia possibile raggiungerla con il browser.\nIl comando list, nell’esempio, riporta una cosa interessante: per ciascun servizio è stata attiva un’istanza. Queste istanze altro non sono che macchine virtuali attivate nella nuvola di Amazon EC2.\n
  • Certo, la grafica lascia a desiderare... ma ad occhio e croce il Front-End funziona visto che riporta anche un elenco degli utenti presenti ed un paio di registrazioni.\n
  • Il comando “info” è molto utile per avere informazioni generali sui vari servizi. Avrete notato che il nome dei servizi è composto dal nome dell’applicazione, un punto e poi il nome del servizio vero e proprio all’interno dell’applicazione. In questo modo potete avere dei servizi “backend” in tutte le applicazioni, senza che questi si disturbino fra loro.\n
  • \n
  • Il comando run torna immediatamente utile perché c’è un’ultima cosa che è stata lasciata in sospeso nelle basi dati. Con Redis non c’è bisogno di inizializzazione perché sostanzialmente “autovivifica”, ma con MySQL occorre definire una tabella, altrimenti è difficile scriverci qualcosa.\nUtilizzando il comando info possiamo vedere la password - analogamente potremmo entrare nel Front-End o nel Back-End e leggerla dentro il file environment.*, ma a che pro se esiste un comando apposito?\nCon il comando run possiamo invece lanciare qualsiasi comando remoto; in questo caso, dunque, lanciamo il client di mysql per poter definire la tabella dove il Back-End salva i dati. Certo, certo: alla creazione della tabella potrebbe provvedere il Back-End stesso, ma poi come mostravo il comando run?\n
  • Ovviamente nessuno di noi pensa che andrà liscia al primo tentativo. Nemmeno nei 100 successivi, per la verità.\n
  • Il primo santo a cui votarsi è il comando logs, che ci consente di vedere i log specifici di ciascun servizio.\n
  • Nel Back-End, ad esempio, dà una visione contemporanea di tutti i file nella directory /var/log/supervisor/, ossia dei log dei nostri programmi più il log del supervisord stesso. Potete decidere di salvare i log da qualche altra parte, ma è particolarmente comodo utilizzare STDERR e lasciare che vengano messi in un posto dove possono essere raccolti facilmente con il comando logs.\n
  • Che fare se i log non bastano? A parte la consueta chiodata, ovviamente?\n
  • Beh, il comando run può tornare utile anche in questa occasione.\n
  • In particolare, tramite run possiamo eseguire comandi nell’istanza remota, quindi è un po’ come avere una shell a disposizione. Magari un po’ lenta, visto che si dove riconnettere ad ogni comando.\n
  • Che fare quindi se vogliamo andare oltre?!?\n
  • Beh, non rimane che entrare da terminale sull’istanza che ospita il servizio che fa le bizze.\n
  • No, l’accesso come root non è contemplato.\n
  • A seconda dell’istanza troveremo ovviamente un ambiente differente con programmi differenti a disposizione. Ad esempio, redis-cli è disponibile nell’istanza di tipo “redis” ma non nell’istanza del backend - anche se avrebbe fatto comodo.\n
  • Trovo che Pitfall! fosse un gioco stupendo, ma occorre stare attenti a non cadere!\n
  • Una delle noie maggiori che ho trovato è il fatto che occorre sempre fare “git commit” prima di effettuare il push, altrimenti dotcloud non prende le modifiche nella directory di lavoro. Stiamo ovviamente parlando del caso in cui venga utilizzato git.\n
  • \n
  • Un’alternativa molto rapida e molto comoda quando si stanno facendo prove è utilizzare “--all”. In questo modo viene ignorato il meccanismo di base della distribuzione e viene sempre utilizzato rsync.\n
  • L’altro aspetto a cui prestare attenzione è che il push normalmente prende il ramo “master”, per cui se si lavora ad un altro ramo occorre ricordarsi di includere il nome del ramo giusto. Questa la trovo una mancanza, poiché è semplice sapere quale sia il ramo attivo di una directory di lavoro; probabilmente però per chi ci lavora “sul serio” è un meccanismo di protezione, per cui non borbotterò oltre.\n
  • Dopo averci dato tanta libertà... purtroppo dotCloud ha posto anche delle restrizioni.\n
  • Da poco tempo è infatti uscito il prezziario. È proprio vero che una volta si stava meglio: se si entrava nella beta, infatti, si poteva giocare molto. Ora sembra che il piano gratuito consenta di avere al massimo due servizi... che fine farà il mio carrozzone che ne ha quattro?\n
  • \n
  • Certo, si può sempre barare...\n
  • ... ad esempio creando account multipli ed utilizzando un servizio di directory centralizzato dove vengono salvate le configurazioni di tutte le applicazioni (i file “environment.*” per intenderci). Un esempio di una directory di questo tipo è nel link nella slide e - senza nemmeno dirlo - l’applicazione è fatta per girare su dotcloud utilizzando due servizi.\n
  • \n
  • dotCloud and go

    1. 1. dotCloud and goUna Breve Introduzione a DotCloud 1
    2. 2. L’immancabile esempio 2
    3. 3. 3
    4. 4. 4
    5. 5. 5
    6. 6. 6
    7. 7. 7
    8. 8. 8
    9. 9. 9
    10. 10. dove lo metto? 10
    11. 11. COME lo metto? 11
    12. 12. QUANTO TEMPO CI METTO? 12
    13. 13. dotCloud 13
    14. 14. 14
    15. 15. IaaS - PaaS - SaaS 15
    16. 16. IaaS - PaaS - SaaS 15
    17. 17. 16
    18. 18. 17
    19. 19. 18
    20. 20. 19
    21. 21. dotcloud 20
    22. 22. easy_install 21
    23. 23. Easy Install è un modulopython (easy_install)incluso in setuptools chevi consente di scaricare edinstallare automaticamentepacchetti Python. 22
    24. 24. Easy Install è un modulopython (easy_install)incluso in setuptools chevi consente di scaricare edinstallare automaticamentepacchetti Python. 23
    25. 25. Sì, Python 24
    26. 26. (è il motivo per cuiqueste slide sono nere) 25
    27. 27. 26 (-:
    28. 28. Python 2.7 27
    29. 29. 28 )-:
    30. 30. $ dotcloud create whateverCreated application "whatever" 29
    31. 31. 30
    32. 32. $ cat dotcloud.ymlwww: type: perl approot: wwwbackend: type: perl-worker approot: backendnosqldb: type: redissqldb: type: mysql 31
    33. 33. $ cat dotcloud.yml www: type: perl approot: www backend: type: perl-worker approot: backend nosqldb: type: redis sqldb: type: mysql32
    34. 34. $ cat dotcloud.yml www: type: perl approot: www backend: type: perl-worker approot: backend nosqldb: type: redis sqldb: type: mysql33
    35. 35. type: perl 34
    36. 36. $ cat app.psgi#!/usr/bin/env perluse Dancer;use whatever;dance(); 35
    37. 37. $ cat Makefile.PL... PREREQ_PM => { Test::More => 0, YAML => 0, Dancer => 1.3070, Plack::Request => 0, Template => 0, JSON => 0, Redis => 0, ... },... 36
    38. 38. type: perl-worker 37
    39. 39. $ cat supervisord.conf[program:exporter]command = perl /home/dotcloud/current/bin/exporter[program:saver]command = perl /home/dotcloud/current/bin/saver 38
    40. 40. $ cat supervisord.conf[program:exporter]command = perl /home/dotcloud/current/bin/exporter[program:saver]command = perl /home/dotcloud/current/bin/saver 39
    41. 41. $ cat supervisord.conf[program:exporter]command = perl /home/dotcloud/current/bin/exporter[program:saver]command = perl /home/dotcloud/current/bin/saver 40
    42. 42. $ cat dotcloud.yml www: type: perl approot: www backend: type: perl-worker approot: backend nosqldb: type: redis sqldb: type: mysql41
    43. 43. Connettersi 42
    44. 44. 43
    45. 45. $ cat /home/dotcloud/environment.ymlDOTCLOUD_ENVIRONMENT: defaultDOTCLOUD_NOSQLDB_REDIS_HOST: whatever-polettix.dotcloud.comDOTCLOUD_NOSQLDB_REDIS_LOGIN: redisDOTCLOUD_NOSQLDB_REDIS_PASSWORD: ...DOTCLOUD_NOSQLDB_REDIS_PORT: 13749DOTCLOUD_NOSQLDB_REDIS_URL: ...DOTCLOUD_PROJECT: whateverDOTCLOUD_SERVICE_ID: 0DOTCLOUD_SERVICE_NAME: wwwDOTCLOUD_SQLDB_MYSQL_HOST: whatever-polettix.dotcloud.comDOTCLOUD_SQLDB_MYSQL_LOGIN: rootDOTCLOUD_SQLDB_MYSQL_PASSWORD: ...DOTCLOUD_SQLDB_MYSQL_PORT: 13747DOTCLOUD_SQLDB_MYSQL_URL: ... 44
    46. 46. use JSON qw< from_json >;use File::Slurp qw< read_file >;sub get_dotcloud_config { my $filename = shift || /home/dotcloud/environment.json; my $config_text = read_file($filename); my $config = from_json($config_text); return $config;} ## end sub get_dotcloud_config 45
    47. 47. sub get_redis { my $config = get_dotcloud_config(); my ($password, $hostname, $port) = map { $config->{DOTCLOUD_NOSQLDB_REDIS_ . $_} } qw< PASSWORD HOST PORT >; require Redis; my $redis = Redis->new(server => "$hostname:$port"); $redis->auth($password); return $redis;} 46
    48. 48. ROTFLsub get_redis { my $config = get_dotcloud_config(); my ($password, $hostname, $port) = map { $config->{DOTCLOUD_NOSQLDB_REDIS_ . $_} } qw< PASSWORD HOST PORT >; require Redis; my $redis = Redis->new(server => "$hostname:$port"); $redis->auth($password); return $redis;} 47
    49. 49. (mi basta poco) 48
    50. 50. sub get_dbh { my $config = get_dotcloud_config(); my ($username, $password, $hostname, $port) = map { $config->{DOTCLOUD_SQLDB_MYSQL_ . $_} } qw< LOGIN PASSWORD HOST PORT >; require DBI; my $dbh = DBI->connect( "dbi:mysql:host=$hostname;port=$port" . ";database=whatever", $username, $password, { RaiseError => 1}, ); return $dbh;} 49
    51. 51. 50
    52. 52. 51
    53. 53. use lib /home/dotcloud/code/lib; 52
    54. 54. DotCloud::Environment 53
    55. 55. 54
    56. 56. ora... in produzione 55
    57. 57. $ dotcloud push whatever# Found dotcloud.yml: Using /home/poletti/sviluppo/perl/whatever as a base directory# upload /home/poletti/sviluppo/perl/whatever ssh://dotcloud@uploader.dotcloud.com:443/whatever/branch:master# git...2011-08-27 09:00:16 [api] Deploy whatever scheduledfor revision=latest2011-08-27 09:00:16 [api] Waiting for the build. (Itmay take a few minutes)2011-08-27 09:00:17 [api] All the services are ready.Beginning the build.... 56
    58. 58. uso git 57
    59. 59. potete usare mercurial 58
    60. 60. oppure niente 59
    61. 61. io uso git 60
    62. 62. fatto 61
    63. 63. $ dotcloud list whateverwhatever: - www (type: perl; instances: 1) - nosqldb (type: redis; instances: 1) - sqldb (type: mysql; instances: 1) - backend (type: perl-worker; instances: 1)$ dotcloud url whateverwww: http://www.whatever.dotcloud.com/ 62
    64. 64. 63
    65. 65. $ dotcloud info whatever.backendbuild_revision: git-b2f52d5cluster: wolverineconfig: {}created_at: 1313990084.301964image_version: b81a3f3949a8 (latest)ports:- name: ssh url: ssh://dotcloud@whatever-polettix.dotcloud.com:13750state: runningtype: perl-worker 64
    66. 66. telecomando:dotcloud run 65
    67. 67. type: mysql$ dotcloud info whatever.sqldbcluster: wolverineconfig: mysql_password: <the-password>created_at: 1313990083.324873...$ dotcloud run whatever.sqldb -- mysql -u root -pEnter password:Welcome to the MySQL monitor. Commands end with ;or g....mysql> CREATE TABLE weight (... 66
    68. 68. troubleshooting? 67
    69. 69. dotcloud logs (Luke!) 68
    70. 70. $ dotcloud logs whatever.backend# tail -F /var/log/supervisor/*.log==> /var/log/supervisor/exporter-stderr---supervisor-2y6P9O.log <==[2011/08/27 01:35:25 INFO ] serving pending requests if needed...[2011/08/27 01:35:25 INFO ] waiting for more export requests...[2011/08/27 01:39:20 INFO ] serving pending requests if needed...[2011/08/27 01:39:20 INFO ] waiting for more export requests...[2011/08/27 01:39:42 INFO ] got element to export: {"email":"flavio@polettix.it","username":"silvia"}[2011/08/27 01:42:18 INFO ] serving pending requests if needed...[2011/08/27 01:42:18 INFO ] waiting for more export requests...[2011/08/27 01:42:30 INFO ] got element to export: {"email":"flavio@polettix.it","username":"silvia"}[2011/08/27 09:00:24 INFO ] serving pending requests if needed...[2011/08/27 09:00:24 INFO ] waiting for more export requests...==> /var/log/supervisor/exporter-stdout---supervisor-foI5vi.log <====> /var/log/supervisor/saver-stderr---supervisor-pt1_hK.log <==[2011/08/27 01:35:25 INFO ] waiting for more data...[2011/08/27 01:36:04 INFO ] got element to save: {"epoch":1313913600,"weight":83200,"username":"flavio"}[2011/08/27 01:37:25 INFO ] got element to save: {"epoch":1313827200,"weight":62000,"username":"silvia"}[2011/08/27 01:39:20 INFO ] performing initial transfer if needed...[2011/08/27 01:39:20 INFO ] waiting for more data...[2011/08/27 01:42:18 INFO ] performing initial transfer if needed...[2011/08/27 01:42:18 INFO ] waiting for more data...[2011/08/27 01:44:04 INFO ] got element to save: {"epoch":1313913600,"weight":78000,"username":"whatever"}[2011/08/27 09:00:24 INFO ] performing initial transfer if needed...[2011/08/27 09:00:24 INFO ] waiting for more data...==> /var/log/supervisor/saver-stdout---supervisor-iQDgpA.log <====> /var/log/supervisor/supervisord.log <==2011-08-27 01:42:18,703 INFO spawned: saver with pid 195872011-08-27 01:42:18,713 INFO spawned: exporter with pid 195882011-08-27 01:42:19,914 INFO success: saver entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)2011-08-27 01:42:19,943 INFO success: exporter entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)2011-08-27 09:00:22,067 INFO stopped: saver (terminated by SIGTERM)2011-08-27 09:00:22,070 INFO stopped: exporter (terminated by SIGTERM)2011-08-27 09:00:24,079 INFO spawned: saver with pid 197292011-08-27 09:00:24,086 INFO spawned: exporter with pid 197302011-08-27 09:00:25,426 INFO success: saver entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)2011-08-27 09:00:25,426 INFO success: exporter entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 69
    71. 71. PIÙ troubleshooting? 70
    72. 72. dotcloud run (like hell) 71
    73. 73. $ dotcloud run whatever.www -- ps afx# ps afx PID TTY STAT TIME COMMAND 3558 ? S 0:00 sshd: dotcloud@pts/0 3559 pts/0 Rs+ 0:00 _ ps afx 144 ? Ss 0:44 /usr/bin/python /usr/ 3495 ? S 0:00 _ /usr/local/bin/uwsg 3496 ? S 0:00 _ /usr/local/bin/ 72
    74. 74. ANCORA PIÙtroubleshooting? 73
    75. 75. dotcloud ssh 74
    76. 76. dotcloud ssh (no root, sorry!) 75
    77. 77. $ dotcloud ssh whatever.backend# $SHELLdotcloud@whatever-default-backend-0:~$$ dotcloud ssh whatever.nosqldb# $SHELLredis@whatever-default-nosqldb-0:~$ redis-cliredis> auth ...OKredis> smembers users1) "silvia"2) "flavio"3) "whatever" 76
    78. 78. 77
    79. 79. $ git commit 78
    80. 80. OPPURE 79
    81. 81. $ dotcloud push --all whatever 80
    82. 82. $ dotcloud push whatever -b branch 81
    83. 83. 82
    84. 84. 83
    85. 85. È tutto molto triste 84
    86. 86. 85
    87. 87. Account Multipli:https://github.com/polettix/dotmulti 86
    88. 88. 87

    ×