Nicholas Giordano

Cloud Arch. & Full Stack Developer

Deploy applicazione docker personale su AZURE

In questo breve articolo vediamo come effettuare il deploy di applicazioni in docker direttamente su Microsoft Azure. Prendiamo come ipotesi quella di avere già un’applicazione “dockerizzata”, che sappiamo già funzionare in locale e che vogliamo mettere in deploy.

Dobbiamo quindi avere:

  • Applicazione che vogliamo eseguire
  • Configurazione Docker per l’applicazione che vogliamo eseguire (Dockerfile nella root dell’app)
  • Account sul portale Azure

Vedremo ora come caricare un contenitore docker, in un servizio app, partendo da un’immagine docker caricata su un registro privato di Azure. Ciò ci permette di utilizzare una qualsiasi immagine di cui abbiamo fatto la build locale. Nel nostro esempio utilizzeremo un’applicazione nest.js di cui vedremo velocemente il Dockerfile.

Sebbene il Dockerfile che vedremo sia pensato per questa particolare applicazione, la procedura di caricamento su Azure resta invariata per qualsiasi applicazione contenente un Dockerfile correttamente specificato.

Il Dockerfile

Questo file non è altro che una serie di istruzioni da dare a docker, comprende la versione base del sistema da utilizzare ed eventuali comandi da lanciare all’applicazione da dockerizzare.

Nel caso della nostra app in nest.js il file sarà qualcosa di questo tipo

FROM node:10 AS builder
WORKDIR /app
COPY ./package.json ./
RUN npm install
COPY . .
RUN npm run build


FROM node:10-alpine
WORKDIR /app
COPY --from=builder /app ./
CMD ["npm", "run", "start:prod"]

All’interno di questo file andiamo a chiedere a docker di:

  1. Fare l’installazione di tutte le dipendenze e la build nella directory /app utilizzando la versione 10 dell’immagine di node, copiando il file package.json e l’intero sorgente dell’app (./)
  2. Eseguire l’applicazione con node10-alphine che si trova nella directory /app (creata nel punto 1) tramite il comando npm run start:prod

E’ importante ricordarsi come l’istruzione CMD non sia altro che il comando che docker va a lanciare per far partire l’applicazione (nel nostro caso) o un qualsiasi altro script.

Una cosa che potrebbe saltare all’occhio per chi conosce Docker, potrebbe essere il fatto che nel Dockerfile non è dichiarata la porta d’esecuzione della nostra applicazione, questo perchè il servizio di Azure (così come la maggior parte dei servizi cloud) si occuperà di fare il provisioning automatico della porta.

Prima di iniziare il processo di creazione del registro delle immagini e la creazione del nostro processo app, se non lo abbiamo ancora fatto è il caso di testare il dockerfile andando a fare una build della nostra app dockerizzata. Per fare ciò nella root directory della nostra app (dove deve trovarsi il Dockerfile) ci basterà eseguire il seguente comando

docker build -t <username>/<nomeapp> .

dove <username> è il nostro username e <nomeapp> il nome che vogliamo dare alla nostra immagine docker, ovviamente possono essere nomi inventati e non vi sono vincoli particolari se non sui caratteri speciali che si possono inserire.

Una volta che la build ha avuto successo possiamo volendo lanciare l’immagine nella nostra istanza locale di docker, cosa che non vediamo nello specifico in questo articolo, ma che volendo possiamo fare con un comando simile a

docker run -p 49160:8080 -d <username>/<nomeapp>

Registro contenitori di Azure

Una volta che siamo certi che la nostra immagine funzioni possiamo procedere a caricarla nel registro contenitori di Azure, questo registro ha la stessa funzione del Docker Hub e possiamo considerarlo come un repository privato delle nostre immagini docker.

Per prima cosa accediamo ad azure e cerchiamo il servizio indicato

cerchiamo registro contenitori all’interno dei servizi disponibili

Facciamo poi click su “crea nuovo”, procediamo alla creazione, selezioniamo un gruppo di risorse o ne creiamo uno nuovo se non lo abbiamo e diamo conferma. E’ fondamentale ricordarsi il nome registro in quanto ci servirà in seguito per effettuare il push della nostra immagine docker locale e per impostarlo come registro origine durante la creazione dell’app.

Una volta che abbiamo creato il nostro registro, se ci rechiamo nuovamente sulla funzione “Registro contenitori” potremo vederlo. Dovremo ora cliccarci sopra, recarci sulla voce “Chiavi di accesso” e abilitare l’account amministratore.

Una volta fatto ciò possiamo recarci nella directory locale della nostra app tramite prompt dei comandi o bash e procedere al collegamento con azure e con il push dell’immagine. Diamo per scontato che sia installato sul sistema la cli di Azure, che ci permette di operare su Azure tramite riga di comando.

Il primo passo consiste nell’autenticarci se ancora non lo abbiamo fatto, eseguiamo quindi

az login

Questo comando ci aprirà una schermata web in cui fare l’accesso, dopo di che saremo autenticati con il nostro account Azure e potremo procedere con la connessione al registro appena creato utilizzando il comando

az acr login --name <nomeregisrtro>

che nel nostro particolare caso sarà

az acr login --name mioimgtest

Una volta fatto ciò dobbiamo assegnare un tag alla nostra immagine, possiamo farlo con il comando

docker tag <username>/<nomeapp> <nomeregisrtro>.azurecr.io/<nomeapp>

Dovremo ovviamente sempre sostituire <username> e <nomeapp> con i nostri dati. Dopo di che potremo procedere al push dell’immagine con il comando

docker push <nomeregisrtro>.azurecr.io/<nomeapp>

Una volta terminato il push siamo pronti per il deploy della nostra app.

Creazione dell’applicazione

Cerchiamo ora nel pannello Azure la voce “Servizi app” e facciamo poi click su “crea”. Assicuriamoci di aver dato un nome valido alla nostra app (sarà endpoint) e assicuriamoci di aver selezionato “Docker”. Potremo quindi fare click su “Avanti: Docker”

Una volta fatto ciò ci basterò specificare l’immagine dal registro immagini creato precedentemente e procedere alla creazione dell’app.

Cliccando su “Rivedi e crea” potrò confermare la creazione della mia app.

Una volta creata, l’applicazione chiamata test-live-app sarà disponibile nel pannello “Servizi App”, dove potremo gestirla, modificare le sue risorse o cancellarla.

Recandoci sulla url assegnata sarà possibile visualizzare l’app

Linux System Administration – Basi Fondamentali

In questo brevissimo articolo andiamo a coprire quelle che sono le operazioni più comuni durante l’amministrazione di un sistema Linux, parleremo quindi di una serie di comandi da dover utilizzare in disparate situazioni per analizzare e risolvere meglio eventuali problematiche o richieste.

Attenzione: Questa non sarà una guida “all’amministrazione di un sistema”, ma una raccorda di comandi utili da utilizzare.

Partiamo dalla rete

E’ fondamentale sapere come siamo connessi, su quali e quante interfacce e sopratutto qual’è il nostro indirizzo fisico. Per chi usa linux da molto sarà da sempre stato abituato al comando ifconfig, ebbene, questo comando è ormai desueto, ma dato che ancora funzionante su sistemi datati lo tratteremo lo stesso. ifconfig ci permette di ottenere tutte le informazioni del caso sulle nostre schede direte, semplicemente lanciandolo otterremo informazioni che riguardano: ipv4, ipv6, gateway e maschere di rete per ogni scheda di rete collegata alla nostra macchina (comprese quelle virtuali). Se siamo invece su in sistema recente conviene utilizzare il più comodo comando ip. Ad esempio:

ip address show 

per ottenere le stesse informazioni che ottenevamo con ifconfig

ip add show eth0

per ottenere le informazioni su un singolo device di rete (in questo caso eth0)

Le porte utilizzate e i socket occupati

Altra fondamentale operazione d’esser capaci di compiere è quella di conoscere quali porte/socket sono attualmente utilizzate dal sistema e sopratutto quali processi sono utilizzatori e quali ipotetici client nella nostra LAN o WAN possono connettervi. Per fare ciò dobbiamo utilizzare netstat. Utilizzare da solo netstat però ci fornisce una serie molto vasta di informazioni che vanno organizzate secondo criterio ed utilità, ad esempio possiamo passare argomenti a netstat per ottenere risultati utili alla nostra analisi nel seguente modo

netsat -tulpn

così facendo andiamo a filtrare tutte le connessioni udp e tcp (v4 e v6), lo stato di connessione (in ascolto o disconnesso), l’indirizzo di ascolto e il PID/processo che sta occupando quel socket. (Attenzione, per ottenere informazioni sul PID/processo bisogna eseguire netstat come root a meno che non vi siano processi che occupano socket e che sono lanciati dall’utente che esegue il comando).

Così come vale per ifconfig, anche netstat è ormai “obsoleto”, all’interno delle nuove distro troviamo infatti ss che può essere utilizzato come netstat e quindi chiamando ss con i seguenti parametri otteniamo lo stesso risultato

ss -tulpn

E’ interessante poi andare ad analizzare il risultato, che sarà una cosa del genere:

Netid  State   Recv-Q  Send-Q   Local Address:Port    Peer Address:Port                                             
udp    UNCONN  0       0              0.0.0.0:60389        0.0.0.0:*      users:(("avahi-daemon",pid=460,fd=14))    
udp    UNCONN  0       0          224.0.0.251:5353         0.0.0.0:*      users:(("chrome",pid=15588,fd=95))        
udp    UNCONN  0       0          224.0.0.251:5353         0.0.0.0:*      users:(("chrome",pid=15588,fd=44))        
udp    UNCONN  0       0          224.0.0.251:5353         0.0.0.0:*      users:(("chrome",pid=15525,fd=144))       
udp    UNCONN  0       0          224.0.0.251:5353         0.0.0.0:*      users:(("chrome",pid=15525,fd=81))        
udp    UNCONN  0       0              0.0.0.0:5353         0.0.0.0:*      users:(("avahi-daemon",pid=460,fd=12))    
udp    UNCONN  0       0        192.168.0.100:68           0.0.0.0:*      users:(("NetworkManager",pid=465,fd=19))  
udp    UNCONN  0       0                    *:1716               *:*      users:(("kdeconnectd",pid=1395,fd=12))    
udp    UNCONN  0       0                    *:54234              *:*      users:(("avahi-daemon",pid=460,fd=15))    
udp    UNCONN  0       0                    *:5353               *:*      users:(("avahi-daemon",pid=460,fd=13))    
tcp    LISTEN  0       0            127.0.0.1:631          0.0.0.0:*      users:(("cupsd",pid=2219,fd=8))           
tcp    LISTEN  0       0                    *:3306               *:*      users:(("docker-proxy",pid=817,fd=4))     
tcp    LISTEN  0       0                    *:6379               *:*      users:(("docker-proxy",pid=21854,fd=4))   
tcp    LISTEN  0       0                    *:8080               *:*      users:(("docker-proxy",pid=21840,fd=4))   
tcp    LISTEN  0       0                    *:80                 *:*      users:(("docker-proxy",pid=845,fd=4))     
tcp    LISTEN  0       0                    *:1716               *:*      users:(("kdeconnectd",pid=1395,fd=13))    
tcp    LISTEN  0       0                [::1]:631                *:*      users:(("cupsd",pid=2219,fd=7))           
tcp    LISTEN  0       0                    *:443                *:*      users:(("docker-proxy",pid=831,fd=4))     

ciò ci aiuta a capire quale servizio è possibile che sia raggiunto internamento dalla macchina che lo esegue e quale anche dalle macchine della rete a cui la macchina è connessa. Osservando i campi di indirizzo infatti possiamo subito distinguere i servizi locali (127.0.0.1) e quelli “pubblici” (0.0.0.0)

La gestione di base del filesystem

Altra operazione di sistema pressoché basilare consiste nel montare semplici partizioni e constatare quanto spazio è occupato da una particolare cartella. Tutte le distribuzioni linux hanno una cartella /mnt solitamente dedicata come “punto di mount” canonico, bisogna ricordare però che è possibile montare una qualsiasi partizione/unità locale o remota in qualsiasi cartella ovunque vi siano i permessi per farlo. Il comando mount se lanciato senza argomenti mostra un listato di tutto ciò che è montato sul sistema, se invece vogliamo montare un’unità ci basterà lanciare

mount *cosa voglio montare* *dove voglio montare*

Che nella realtà dei fatti, immaginando di voler montare la partizione /dev/sda2 sarà

mount /dev/sda2 /mnt

Nel caso in cui volessimo montare automaticamente una o più partizioni/volumi remoti automaticamente al boot dovremo modificare il file fstab con un qualsiasi editor di testo. Tale file si trova in /etc

E se volessimo controllare lo stato di utilizzo di uno o più dischi in un formato “umanamente leggibile?” Per fare ciò possiamo utilizzare df nel seguente modo:

df -h

per visualizzare le partizioni fisiche o remote

df -ah

per visualizzare tutte le partizioni (anche ad esempio i punti di mount virtuali di un’ipotetica applicazione o servizio dockerizzato sulla nostra macchina)

Se invece vogliamo sapere quanto occupi una particolare cartella possiamo utilizzare il comando ls in funzione estesa con il paramertro -l o più professionalmente il comando du

du -sh miacartella/

che restituirà la dimensione della cartella denominata miacartella

La gestione dei processi e dei servizi

Altra cosa fondamentale da saper fare è quella di saper gestire i processi e i servizi/demoni. In primo luogo ci interessa sapere quante risorse un determinato processo sta utilizzando, e in questo caso possiamo utilizzare le utility top o htop (il primo solitamente sempre installato in qualsiasi versione). Se vogliamo però essere più diretti ed individuare un singolo processo e tutti i thread in esso coinvolti possiamo utilizzare ps e grep in pipe e nel seguente modo:

ps aux | grep *nomeprocesso* 

Che restituirà l’utilizzo delle risorse (CPU) occupate da un processo e dai suoi figli.

Se invece parliamo di servizi, oltre a poter usare una pipe come quella sopra descritta per valutare lo stato d’esecuzione, è fondamentale poter operare su questi ed in particolar modo conoscerne lo stato (running, not running, error) e operare su quest’ultimo. Può essere utilizzato il comando service, anch’esso però deprecato nelle distribuzioni più recenti che sono passate alla gestione dei servizi utilizzando systemd. Prima di vedere la differenza d’approccio è però importante sapere cosa possiamo chiedere al gestore dei servizi/demoni:

  • status
  • start
  • stop
  • reload

Utilizzando il comando service la sintassi si presenta in questo modo:

service *nomeservizio* *operazione*

dove nomeservizio è il servizio su cui investigare e operazioni è invece una tra quelle descritte in precedenza. Se ad esempio volessimo conoscere lo stato del servizio nginx utilizzando questo comando dovremo digitare:

service nginx status

Tenendo invece in considerazione il nuovo approccio della maggior parte delle distribuzioni di nuova release che utilizzando systemd come gestore dovremo digitare:

systemctl status nginx

L’unica differenza tra i due comandi è quindi relativa al posizionamento dei loro argomenti, che risultano invertiti.

E se c’è qualcosa che non sappiamo?

In tutte le distro è presente l’utililty man che non è altro che un manuale per ogni comando, se quindi vogliamo sapere come funziona un programma o comando e come utilizzarlo ci basterò fare

man *comando*

che restituirà tutte le informazioni necessarie ad un utilizzo anche molto approfondito del *comando* passato come argomento.

Una cosa fondamentale che manca in questo breve articolo è la trattazione delle operazioni schedulate, il cron, che verrà trattato in un articolo interamente dedicato ad esso.

Estendere partizione LVM su un VPS

Per chi avesse mai acquistato un server virtuale presso un qualsiasi servizio cloud: Aruba, Register o simili; una volta configurata per la prima volta la propria macchina dopo aver scelto i tagli di memoria, la tipologia di processore e lo spazio di archiviazione può nascere l’esigenza di modificare uno di questi parametri per un qualsiasi motivo. Modificare potenza di calcolo e tagli di memoria è un’operazione abbastanza banale in quanto ci basterà recarci sul nostro pannello di amministrazione del servizio e semplicemente aggiungere più RAM o più cores alla nostra macchina e i cambiamenti saranno subito applicati dopo un riavvio. Per quanto riguarda invece lo spazio di archiviazione il discorso è differente in quanto si, si può aggiungere più “spazio” di memoria semplicemente acquistandolo dal nostro pannello clienti, ma questo non sarà automaticamente disponibile in quanto non automaticamente allocato.

In questo breve articolo vediamo dunque come estendere la partizione primaria del nostro vps con l’eventuale “free space” acquistato.

ATTENZIONE: prima di effettuare qualsiasi operazione di ridimensionamento o partizionamento è fondamentale eseguire un backup di tutti i dati presenti sulla macchina onde evitare di perdere tutto nel caso di errori! Se leggendo questa guida non sei sicuro di quello che stai facendo contatta il tuo fornitore di servizi che ti fornirà supporto tecnico (a pagamento).

Passo 1: creazione di un nuova partizione con lo spazio non allocato

Colleghiamoci tramite ssh alla nostra macchina e utilizzando cfdisk andiamo a creare una nuova partizione: questa dovrà essere di tipo Logico e avere il formato 8E. Possiamo fare tutto ciò digitando cfdisk sulla riga di comando e utilizzare le frecce direzionali per selezionare lo spazio allocato, cliccare su new, impostare tipologia e formato e poi fare click su write per salvare le modifiche.

Passo 2: creare un volume fisico per la partizione creata

Una volta creata la partizione ad essa sarà assegnato un riferimento (es: /dev/sda6), dobbiamo a questo punto creare un volume fisico per questa partizione e per farlo ci basterà fare da riga di comando:

pvcreate /dev/sda6

*in caso di errori, nel caso in cui ad esempio il sistema indichi che la partizione /dev/sda6 (nel nostro caso) fosse non pronta o non trovata ci basterà riavviare la macchina virtuale e ripetere la creazione del volume fisico.

Una volta fatto ciò andiamo a controllare i volumi fisici, diamo quindi il comando

pvdisplay

che ci restituisce un qualcosa di simile:

E’ fondamentale ricordare il vg name dell volume appena creato per la nostra partizione

Passo 3: estendere il volume appena creato

Possiamo farlo ricordandoci il vg name e dando il comando

vgextend vg /dev/sda6

Passo 4: controllare il volume logico da espandere

Il volume logico da espandere non è altro che la partizione virtuale alla quale vogliamo aggiungere il nostro “free space” che in questo momento della guida corrisponde al volume /dev/sda6 precedentemente creato.

Per far ciò in primo luogo dobbiamo capire il nome della partizione logica da espandere, digitiamo quindi

lvdisplay

che ci restituirà qualcosa del genere

una volta compreso il nome del volume da espandere da terminale possiamo dare il comando

lvextend -l+100%FREE /dev/vg/lv_root

che espanderà il nostro volume logico, ed infine per espandere il file system e rendere disponibile lo spazio non allocato diamo il comando

resize2fs /dev/mapper/vg-lv_root

Una volta fatto ciò il nostro disco primario risulterà aumentato dello spazio specificato al momento della creazione della partizione /dav/sda6

Passo 5: controllare che tutto si andato come dovrebbe

Per controllare l’effettiva applicazione delle modifiche basterà dare il comando

df -h

Una volta fatto ciò non sarà inoltre necessario riavviare la nostra vps. I cambiamenti saranno immediati.

😀

ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY

Ultimamente mi sono imbattuto, utilizzando un server gestito tramite Plesk, nel seguente messaggio d’errore: “ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY”. Stiamo parlando ovviamente di un messaggio dovuto a qualcosa di non funzionante riguardante i certificati SSL/TSL, la cosa buffa è che però il suddetto messaggio non appariva su tutti i browser che andavano a visitare i domini e che i certificati installati sul suddetto dominio risultavano pienamente validi. La problematica si verificava infatti solamente quando vecchi browser o sistemi con una vecchia versione di Android andavano a navigare verso gli indirizzi in questione. Come tutti i server gestiti dalle recenti versioni di Plesk, le pagine web vengono “servite” utilizzando nginx come reverse proxy per Apache il che garantisce una quantità di migliorie sotto il punto di vista della gestione dei traffici anche più elevati e buoni margini di operabilità dei servizi offerti dalla nostra macchina in una vastità molto ampia di scenari d’utilizzo. Proprio per questa cosa ho pensato che potesse essere nginx il problema paradossalmente parlando. Infatti una volta disattivato ed utilizzando il solo Apache la problematica è totalmente rientrata. E’ però una valida soluzione uccidere un servizio che ci aiuta in così tanti modi? Ovviamente no, motivo per cui mi sono messo a cercare una soluzione diversa! Consideriamo ovviamente che una dinamica del genere la vediamo affliggere i nostri domini solo nel caso in cui li abbiamo su un server personale, vps o dedicato che sia e che assolutamente mai si verifica se utilizziamo hosting gestito da una qualsiasi compagnia che si rispetti, se vediamo quindi comparire il messaggio d’errore su un nostro piano hosting il problema è probabilmente dovuto ad altro (SPDY o Chiper).

Qual’è quindi la soluzione al mio problema se non voglio (giustamente) disattivare il reverse proxy? Semplice! Fornire ad nginx opportune direttive che gli permettano di rispondere correttamente anche a sistemi un po “vecchi” ed “inadeguati” che vanno a dialogare con lui.

Le direttive da dare ad nginx sono le seguenti, ed andranno date per ogni dominio di cui è reverse proxy

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
ssl_prefer_server_ciphers on

In questo modo anche i browser più vecchi riusciranno a verificare l’autinticità del certificato SSL/TSL facendo accedere l’utente finale alle reali pagine di destinazione.

Perchè preoccuparci di una cosa del genere però? Magari abbiamo il nostro dominio sul nostro sistema gestito tramite plesk e mai abbiamo notato una cosa del genere e i nostri siti sempre hanno funzionato in maniera opportuna. Ebbene, il problema è proprio qui. Tutto funziona correttamente, il problema non si nota fino a quanto un tuo cliente non raggiunge un dominio al quale il suo dispositivo dice che per “ragioni di sicurezza” non può accedere, e questa ovviamente è una cosa che vogliamo scongiurare a tutti i costi 😉

Redirect ad un sito mobile con javascript

Redirect ad un sito mobile? Se ci accorgiamo che il visitatore si trova a visitare una nostra pagina da dei particolari dispositivi possiamo farlo

Ci troviamo ormai in una delicata situazione di passaggio, la maggior parte dei siti web vengono ormai visitati da dispositivi mobili: telefoni, tablet; ed una delle prime caratteristiche che ormai un qualsiasi sito web moderno deve avere essere la grafica “responsive”, quella che si adatta in automatico in base alle dimensioni dello schermo sul quale viene visualizzata.

Bene direte voi, riprogettiamo tutto, rendiamo tutto responsive. Questa sarebbe un’idea magnifica, spesso però non è sempre e subito rapidamente fattibile. Cosa fare allora? Perdere i visitatori che arrivano da mobile o rendergli particolarmente complicata la navigazione tra i nostri contenuti?

 

La risposta è chiaramente NO!

 

Per questo javascript ci viene in grande aiuto: vediamo oggi un semplice script che verifica se il nostro visitatore si trova a navigare da un dispositivo mobile e in caso di risposta affermativa effettua in automatico il redirect ad una qualsiasi nostra pagina. Certo, questo non risolve il problema alla base, ma almeno, progettando l’adeguamento del nostro sito e dei nostri contenuti possiamo nel frattempo creare delle pagine ad hoc per i nostri contenuti più importanti.

Di seguito lo script:

<script>
if( 
 navigator.userAgent.match(/Android/i) || 
 navigator.userAgent.match(/webOS/i) || 
 navigator.userAgent.match(/iPhone/i) || 
 navigator.userAgent.match(/iPod/i) || 
 navigator.userAgent.match(/BlackBerry/i)
){
location.href="http://sitomobile.it";
}</script>

Configurazione di base di un web server linux: Apache, PHP e Mysql

Mai avuto necessità o curiosità di installare / configurare un web server linux?

Ci sono tanti modi di mettere online un sito web, possiamo utilizzare uno dei tanti piani di hosting messi a disposizioni da uno dei tantissimi provider, oppure possiamo aver bisogno di una soluzione più personalizzabile, più potente o magari necessitiamo di funzioni che il semplice piano di hosting, con tutte le sue “limitazioni” non ci permette di implementare. In questa breve e semplice guida vedremo come installare e configurare un server LAMP (Linux-Apache-Mysql-PHP) sulla nostra macchina linux o il nostro ipotetico server remoto (VPS o dedicato che sia).

Vedremo passo passo come installare i componenti e i servizi che permettono ad una macchina connessa in rete di diventare un vero e proprio erogatore di servizi online. La seguente guida può essere utile per tutti coloro che per la prima volta passano da un piano hosting (dalla pappa pronta insomma), ad una soluzione molto più personale e per certi versi affidabili. Non vedremo come trasformare il nostro computer di casa in un server (ci sarebbero troppe questioni su DNS, NameServer e IP statici da analizzare, cosa che farò in un altra guida).

Passo 1: Connessione alla macchina remota

Passaggio fondamentale è collegarsi tramite SSH (secure shell), alla macchina remota (VPS o server dedicato) che dobbiamo andare a configurare, volendo possiamo anche creare un web server locale (e questa cosa possiamo farla anche con il nostro computer di casa o dell’ufficio, con un raspberry o una qualsiasi board computer), ma in questo caso non sarà necessario effettuare nessun collegamento ssh bensì semplicemente basterà aprire un terminale.

Apriamo un qualsiasi terminale UNIX e digitiamo:

1
ssh root@ip_macchina

dove andremo a sostituire con ip_macchina l’indirizzo IP della macchina alla quale vogliamo collegarci.

Se la connessione andrà a buon fine ci verrà chiesto di memorizzare una chiave e di inserire una password (quella dell’utente root della macchina remota alla quale ci stiamo connettendo), ed una volta fatto ciò ci si aprirà all’interno del terminale la shell della macchina remota, proprio come se stessimo eseguendo un terminale su quella macchina.

Se avete un sistema Windows e volete collegarvi tramite SSH potete utilizzare il programma Putty.

Passaggio 2: Installazione di Apache

Andiamo ora ad installare il cuore del nostro web server, Apache2, che sarà la piattaforma per il nostro web server. Ci sono anche altri programmi come Apache, ad esempio ngix, ed in seguito vedremo come e quando utilizzarne uno o l’altro.

Da terminale digitiamo:

1
sudo apt-get install apache2 apache2-doc apache2-mpm-prefork apache2-utils libexpat1 ssl-cert

Ad installazione conclusa dobbiamo ora attivare Apache2 (che  è un servizio), per attivarlo/disattivarlo/riavviarlo basterà digitare da terminale

4
5
6
7
sudo service apache2 start //per avviarlo
sudo service apache2 stop //per fermarlo
sudo service apache2 reload //per applicare modifiche alle impostazioni
sudo service apache2 restart //per riavviarlo

Ora navigando verso l’indirizzo IP della nostra macchina, o andando su localhost (se siamo in locale digitate semplicemente localhost nell’indirizzo del browser oppure il vostro IP locale 127.0.0.1), dovremmo vedere una schermata del genere:

schermata-da-2016-09-20-08-43-59

Se ciò accade significa che abbiamo fatto tutto correttamente e che Apache è stato correttamente installato. A questo punto possiamo già mettere online un sito web in HTML, senza utilizzare PHP o un database, ma raramente i siti web moderni vengono realizzati senza questi due elementi.

Passaggio 3: Installazione di PHP

Installando questo applicativo andremo a rendere compatibile il nostro web server con tutto ciò che utilizza PHP per funzionare.

Da terminale digitiamo:

sudo apt-get install libapache2-mod-php5 php5 php5-common php5-curl php5-dev php5-idn php-pear php5-recode php5-snmp php5-sqlite php5-xmlrpc php5-mcrypt php5-memcache php5-mhash php5-ming php5-mysql php5-ps php5-pspell

Php però non è solo questo, ci sono moltissimi altri pacchetti che contengono ulteriori altre funzioni di compressione o interpretazione, spesso capita che installando sul nostro web server un servizio che utilizza php, come un qualsiasi CMS, ci venga chiesto di installare un determinato componente php, in questo caso sarà molto semplice “individuare” il nome del componente tra quelli installabili sul nostro sistema, digitiamo da terminale

 apt-cache search php5

Questo comando mostra tutti i pacchetti nominati php5, da questi possiamo individuare ciò che ci serve e installarlo con il classico apt-get 😉

Passaggio 3: installazione di mysql

Da terminale digitiamo

sudo apt-get install mysql-server mysql-client

ATTENZIONE: L’installazione di mysql necessita di maggiori attenzioni rispetto a quelle fatte fino ad ora, ci sarà infatti chiesta una password dell’utente “root”, questa password e questo utente non hanno nulla a che vedere con il vostro sistema o con l’utente root con il quale siete autenticati, corrisponde bensì all’utente con diritti massimi su tutti i database che andrete a creare, è buona norma inserire una password complessa e ben diversa dal quella del superuser di sistema. E’ inoltre buona norma non utilizzare mai l’utente root per la gestione tramite codice di un database, è consigliabile creare un utente singolo con password propria e privilegi su un singolo database per ogni progetto che utilizza mysql che andremo a realizzare od implementare, ma a questa cosa sarà dedicata una guida intera 😀

Così come per apache, anche mysql è un servizio, da terminale digitiamo quindi

sudo service mysql start //per avviarlo
sudo service mysql stop //per bloccarlo

 

Una volta fatto ciò il nostro sistema LAMP è pronto!

In una prossima guida vedremo come andare a configurare in modo personale PHP, Come creare Host virtuali (più siti su un solo server) e come andare ad aumentare la sicurezza della nostra installazione di mysql. Per ora andiamo a capire come modificare il “nostro” sito web attuale, ossia la pagina di default di apache che abbiamo visto in precedenza.

Basterà semplicemente andare a modificare o sostituire o cancellare il file index (index.html) nella cartella di dafault di Apache2 situata in /var/www/html

Una volta giunti in questa cartella ci comporteremo come se fossimo su un normalissimo hosting!

Attenzione: Bisogna prestare particolare attenzione ai permessi che vengono utilizzati sui file presenti all’interno della cartella pubblica HTML (quella di cui parlavamo sopra), possono infatti verificarsi errori 503 o peggio, possiamo dare accesso non volendo alla modifica di file ed esecuzione di script a personaggi che non dovrebbero. Per stare tranquilli possiamo utilizzare un gruppo utente con i permessi “perfetti” o quasi per il web, il gruppo in questione è www-data, con il relativo utente www-data (valido per debian e derivate).

Digitiamo da terminale

sudo chown -R www-data:www-data /var/www/html

In questo modo applicheremo questi “permessi” (o meglio ownershp) all’intera cartella pubblica html, è importante ricordare che ogni qualvolta creeremo una cartella all’interno di quella pubblica “html”, con un utente diverso da www-data, dovremmo riapplicare nuovamente l’ownership onde evitare problemi o errori.