C’ qualcuno che usa sui server una distribuzione diversa da
Debian/Ubuntu?
Qualcuno ne usa una con rolling release?
-f
ci ho provato un po di tempo fa con ArchLinux ma non stata una bella
esperienza, almeno IMHO.
le uniche rolling release che conosco sono:
-
gentoo: testata, stabile, con un buon supporto. ma devi compilarti i
pacchetti uno alla volta. IMHO non il massimo da mantenere su un server
remoto. pu essere comoda se hai N servers + 1 macchina potente dedicata
alla compilazione e fornitura di pacchetti binari che hai precompilato.
lho usata per anni in produzione per diversi servizi di rete (vpn
gateway, firewall, backups, etc…) ma era una sala server
-
arch: non la conosco benissimo, lho provata una sola volta su un
server. ben fatta (pulita, minimale, ricorda slackware), ma non la
consiglierei perch (AFAIK) non c garanzia sul fattore production-ready.
i pacchetti che installi/aggiorni necessitano della massima attenzione
(readme, messaggi pre/post installazione, sovrascrittura di
configurazioni varie). metterla su un server potrebbe darti qualche
pensiero in pi per la manutenzione
dopo una breve ricerca, ho scoperto che anche openSuse ha una versione
rolling-release. magari pu interessarti:
https://it.opensuse.org/Portal:Tumbleweed
ciao,
A.
Il giorno 16/ott/2014, alle ore 16:39, Fabrizio R.
[email protected] ha scritto:
C’ qualcuno che usa sui server una distribuzione diversa da Debian/Ubuntu?
Qualcuno ne usa una con rolling release?
–
Lo chiedo perchè Linode ad esempio sconsiglia l’esecuzione di distro
upgrade tipo ubuntu 10.04 → 12.04 etc. Consigliano installazioni
pulite,
che per quanto puoi automatizzare tutto, su un numbero alto di macchine
sono un bel pain.
-f
2014-10-16 17:42 GMT+02:00 Andrea P. [email protected]:
Il giorno 16 ottobre 2014 17:52, Fabrizio R. [email protected]
ha
scritto:
Lo chiedo perchè Linode ad esempio sconsiglia l’esecuzione di distro
upgrade tipo ubuntu 10.04 → 12.04 etc. Consigliano installazioni pulite,
che per quanto puoi automatizzare tutto, su un numbero alto di macchine
sono un bel pain.
pensato a soluzioni basate su chef/puppet/ansible/salt?
…non è automatico come vorresti ma potrebbe drasticamente diminuire la
complessità.
m.
-f
Puoi sempre usare Debian sid se vuoi evitare gli update, ma è
probabilmente più instabile di Arch o Gentoo 
2014-10-16 17:58 GMT+02:00 Michele F. [email protected]:
Comunque non so per voi, ma sul server aziendale il passaggio da squeeze
a
wheezy è stato poco più che un dist-upgrade un po’ più lungo
Il 16/ott/2014 18:05 “Fabrizio R.” [email protected] ha scritto:
Mi riferivo a quello. Ma il problema comunque di dover cambiare
indirizzo
IP ad un servizio solo perchè cambia macchina non è proprio indolore
comunque, con riferimento al downtime.
2014-10-16 17:58 GMT+02:00 Michele F. [email protected]:
(È con poco più intendo "reboot"per il kernel, non ricordo altro)
Il 16/ott/2014 17:52 “Fabrizio R.” [email protected] ha scritto:
Grazie per il link. E’ tutto sacrosanto quello che dici, se hai a che
fare
con progetti importanti, i quali richiedono ovviamente un setup
complesso.
Parlando di progetti pi economici, load balancer o proxy HA non sono
sempre parte dell’architettura.
Ad ogni modo mi pare sia ormai pacifico che la soluzione usare
automation
tools e rifare il setup allo scadere del LTS.
2014-10-17 12:33 GMT+02:00 Riccardo T. [email protected]:
Fabrizio R. wrote in post #1160326:
Grazie per il link. E’ tutto sacrosanto quello che dici, se hai a che
fare
con progetti importanti, i quali richiedono ovviamente un setup
complesso.
Parlando di progetti pi economici, load balancer o proxy HA non sono
sempre parte dell’architettura.
Ad ogni modo mi pare sia ormai pacifico che la soluzione usare
automation
tools e rifare il setup allo scadere del LTS.2014-10-17 12:33 GMT+02:00 Riccardo T. [email protected]:
Il load balancer di Linode costa circa $20, se non sbaglio ed ha un
pannello web semplicissimo. Questo sito (Rails3) gira so tre linode
dietro ad il load balancer: https://www.chinadialogue.net/. Mysql usa la
replicazione master-master con galera, quindi posso fare la manutenzione
a uno o due server senza avere interruzioni del servizio. Il downtime e`
di 3-4 minuti al mese e non ha causa del sito ma di Linode.
Comunque si Chef ti permetterebbe un update veloce alla scadenza del
LTS, ma anche di testare con vagrant o meglio ancora con
http://kitchen.ci/. Serverspec e` un’ottimo strumento per testare
servizi, pacchetti etc… ma se lo usi ogni fine di LTS, forse i vecchi
test manuali sono abbastanza
Qualcuno per caso ha provato Docker seriamente? Ne parlano un gran
bene…
Io c’ho solo giochicchiato, sembra carino ma non mi scattata la “molla”
diciamo (forse non ci ho giochicchiato abbastanza?)
Il 17/ott/2014 14:20 “Riccardo T.” [email protected] ha scritto:
Aggiornare una distribuzione direttamente in un server in produzione e rischioso. In applicazioni critiche con SLA e da pazzi. Con la
virtualizzazione e possibile create un nuovo server per ogni nuova software release [1], ed e possibile testare cambiamenti
all’infrastruttura e configurazione del server con la nuova versione del
software. Questo rende obsoleti aggiornamenti delle distribuzioni live a
rolling release, be` meno importanti o pericolosi.
Lo sviluppo di una nuova app dovrebbe tenere in considerazione su quale
server girera, il continuos deployment, la configurazione del server. Usare tool come Chef e oramai indispensabile a meno che non usiate
Heroku.
Non vedo il problema di aggiornare il numero IP. Usando un proxy come
HA-proxy o nodebalancers[2] quando il nuovo server e` pronto basta
aggiornare il bilanciatore con i nuovi IP.
Se non volete creare un nuovo server per ogni nuova software release
potere almeno create nuovi server quando aggiornate la configurazione
con Chef.
Se dovete iniziare da zero con Chef e tutto il resto vi consiglio NixOS
[3]. Ad ogni cambiamento i file
sono ricreati in una directory che ha una hash. In questo modo e`
possibile fare un rollback. NixOS ha un suo strumento per DevOps
chiamato NixOps [4]. Al momento mi sembra lo stato dell’arte.
Dimenticavo, hanno anche Hydra, un continuos build system [5].
[1] http://chadfowler.com/blog/2013/06/23/immutable-deployments/
[2] https://www.linode.com/nodebalancers
[3] http://nixos.org/
[4] GitHub - NixOS/nixops: NixOps is a tool for deploying to NixOS machines in a network or cloud.
[5] GitHub - NixOS/hydra: Hydra, the Nix-based continuous build system
Noi lo usiamo in produzione ma personalmente non me ne occupo, so solo
che chi gestisce le DevOps da noi molto contento.
Personalmente uso Ansible e Ubuntu LTS o al massimo CentOS.
–
Luca P.
[email protected]
Avevo iniziato lavorare con Chef e chef solo (il setup della versione
opensource di Chef centralizzato mi sembrava complicato). Per un p
andato bene. Poi mi sono rimesso a studiare puppet seriamente. Non
potrei
essere pi felice, una volta installato il master aggiungere nodi un
attimo e la configurazione del client su una fresh install ancora pi
veloce. La DSL un p astrusa all’inizio rispetto a quella di chef che
ruby code, ma alla fine ti ci ritrovi.
Docker ce l’ho sul radar da qualche tempo, ma non ho ancora
approfondito.
Penso per che se non hai intenzione di fare hosting o PaaS non abbia
molto
senso.
2014-10-17 17:03 GMT+02:00 Luca P. [email protected]: