Reprise du message précédent :
Bonjour, on a eu un major outage sur notre host provider -> heart internet
 
Ils ont réussi l'exploit de laisser les VPS en rade pendant plus de 24 heures, soit-disant à cause du remplacement d'un power switch qui a mal tourné et qui a entrainé l'arrêt total de tout le data-center. Du bon gros foutage de gueule quoi... à noter que TOUS les sites hébergés chez eux sont tombés en même temps pendant un minimum de 12 heures jusqu'a plus de 24 heures. Un bel exploit qui va leur couter cher...  
 
vu qu'apparemment c'est à moi que reviens le challenge de bouger tous nos site ailleurs, je lorgne sur AWS (EC2)  (je lorgnais dessus depuis un certain temps déjà)
 
Des retours d'exp ? Vu l'énormité de l'infra Amazon, j'ai un peu peur du truc inhumain où quand tu as un soucis, t'es baladé d'un indien à un autre... D'un autre côté, le côté scalable pur me plait bien...

 
Je vois pas ce que ça résoud comme problème.
Si on veut avoir accès au donnée on l'aura via la DB.
A part nous rendre notre boulot plus compliqué en nous forçant à taper toutes les requêtes SQL plutot que d'afficher ça à l'écran en 2 clics et devoir demander à l'utilisateur pour voir sa session quand c'est un problème avec l'interface ça comble aucun trou de sécurité.

En général , tu ne gardes pas l'accès aux db dans ce cas. Uniquement via un sas pour les mise à jour ( par exemple un accès physique sur une bécanne , ou a minima un accès spécifique tracé)

Leur support technique assure, même avec les petits clients de ce qu'on m'a raconté. Ils sont pas donnés faut dire.

Le truc c'est qu'utiliser AWS pour EC2 seulement c'est un peu dommage. Et si tu commences à utiliser plusieurs produits, faut être conscient que le vendor lock-in peut devenir un problème.

Vu qu'on fait le support et qu'on doit mettre à jour la DB parfois, on peut demander un super user qui a accès à la DB sur base d'un ticket.
Je comprends qu'ils veuillent se protéger d'un vol de données etc mais on fait le support, si on veut avoir accès on l'aura donc autant qu'ils nous fassent confiance et arrêtent de rajouter des couches administratives qui nous ralentissent quand on fait notre boulot.

Lol accès à la DB    
Puis on te push les logs sur pastebin aussi, tant qu'à faire

Si c'est juste pour du VPS va plutot voir d'autres acteurs, aws c'est surtout quand tu as besoin de solutions complexes que tu gagnes le plus de pognon

 
En fait, si j'ai bien compris, le support c'est par compte, et non par EC2, 100$ par mois pour du response time d'une heure, pour nous, vu le nombre de sites qu'on a (une trentaine seulement, car les sites ne sont pas notre coeur d'activité), ça me semble parfaitement raisonnable. On a seulement quelques site de e-commerce basés sur du Magento qui m'inquiètent un peu plus. Ce sont d'ailleurs ces sites qui nous forcent maintenant à migrer ailleurs, parce que même si nos customers ont parfaitement compris qu'on était pour rien dans ce qui vient de se passer, ils veulent tous voir leurs sites hostés ailleurs. Ils ne pourraient pas comprendre qu'on reste chez heartinternent (c'est sans doute un peu con car finalement les problèmes il y en a sûrement partout, mais là, plus de 24heures de down, ils sont pas contents... ça représente une perte substantielle de pognon pour certains il faut dire).
C'est comme l'état d'urgence en France, ça sert à rien, mais si le gvt ne fait rien, les gens l'acceptent pas.
 
Pour les autres services amazon, ouai, ça a l'air vraiment bien. Ce qui m'inquiète un peu, c'est que j'ai lu que même si ils prétentent avoir du 99.99xx de uptime, quand ça tombe, des régions sont concernées. Enfin bon, de toutes manières, la sécu à 100%, ça n'existe pas.
 
Je pense aller vers du 50% de nos site chez Amazon et les autres 50% ailleurs pour pas tout avoir dans le même panier et pouvoir comparer. C'est quoi le mieux pour vous en ce moment à part AWS? pour des VPS linux "hightly reliable" avec traffic illimité cela va sans dire ou en tous cas, des solutions upgradables à chaud.

En provider connu, ta DigitalOcean aussi.

J'ai pas eu que de bons retours sur le support EC2 ces derniers temps (discussions avec quelques gros consommateurs au FOSDEM)

Ta besoin de VM persistantes plus que de l'instance jetable c'est ça ?

Pas de problématique sur où est située la data (confidentialité tout ça) ?

 
On a plusieurs projets en cours qui vont avoir besoin d'être sur des hosts très scalables. Et puis j'ai envie de pas mourir idiot, ça peut être bon pour moi d'utiliser AWS vu que cela a l'air de plus en plus demandé. Mais ok pour le conseil. De toutes manières, je pense aller aussi voir un autre acteur au moins pour une partie de nos sites.

Non mais aws le premier point c'est de revoir l'archi de ton infra pour survivre à une perte d'AZ ou de régions.
Et comment tu utilises les services on top pour baisser tes coûts de hosting et d'ingénierie.

 
oui
 

 
A part pour un projet, le reste non. Mais j'ai vu qu'ils (AWS) ont une région Europe de l'Ouest pour cela. Je me demande d'ailleurs si il y a une réelle garantie que les données sont pas ailleurs... Ya des gusses indépendants qui controlent ça ? lol , Ils font comment ? Ils ouvrent les serveurs, prennent une loupe et .. Ah ouai, les données sont bien là, je les voit bouger.    

 
Oui, en faisant des recherches, ce sont exactement les problématiques que j'ai pu voir.

mp pour le détail

Ils sont audités, certifiés ISO tout ça. Avec un traceroute tu peux facilement voir que tes instances sont dans le pays où elles sont censées être hein

Garantie juridique tu peux trouver des juristes qui ne sont pas d'accord.
Sur le plan technique ils ont autre chose à foutre que de dupliquer des volumes pour le fun.

Voilà, il faut que tes app soient comme ça.
 
Sinon tu prend des providers plus « traditionnels » (Online.net)

Quitte à avoir un support en carton, OVH est moins cher.
 
C'est pas dur de trouver des gens qui ont eu des problèmes chez DO, Linode, Vultr, ... et si tu commences à gérer la redondance toi-même, pas sûr que tu y gagnes comparé à AWS.
Une autre question que je me poserais: est-ce que le premier botnet ukrainien venu peut mettre mon hébergeur à genoux.

 
Ah non, plutôt crever que partir chez eux. Online >>>>>>> OVH.

 
Tu fais comment quand un utilisateur te demande de prendre des actions qui nécéssitent de modifier la DB ?

 
Ici on n'a jamais accès aux données de prod.  
 
Ils ont des outils d'anonymisation pour nous envoyer des données en volume.
 
Et quand il faut modifier la DB, on livre un patch SQL, tout simplement. Qui doit donc être validé de manière un peu floue, parce qu'on n'a justement pas les données de prod.
 
Du coup, ça arrive que ça foire : récemment on a eu le cas, on n'a pas anticipé le cas de données pas valides au sens métier dans la DB. Comme on n'avait pas le cas dans nos données de recette, ça a marché chez nous, mais pas chez eux. Dans ces cas là on corrige le patch
 
Mais dans plein de domaines, c'est normal de pas avoir accès aux données, d'autant plus si tu es prestataire.

Tiens puisqu'on parlait d'Amazon/DO tout à l'heure, je m'amuse bien avec CloudInit dans Xen Orchestra. Une mini démo pour vous montrer l'intérêt, si jamais vous ne connaissiez pas (pas taper, moi je trouve ça excellent )

D'abord :

• se créer une VM avec un petit disque root (4 GiB)
• installer son OS serveur préféré + le package CloudInit
• désactiver le Mdp root, mettre l'user par défaut sudoer sans Mdp et convertir en template

Une fois ceci fait, vous pouvez créer une VM à partir de ce template et lui passer de la config à son boot.

Concrètement à la création, renseigner un champ particulier (ici custom pour mettre tout ce dont j'ai envie, sinon juste la clef ssh est possible) :

Ici, j'ai juste passé cette config :

Une fois ceci fait, 20 secondes après avoir cliqué sur « Create », vous avez l'IP qui remonte via Xen Orchestra, donc un simple SSH dessus suffit :

J'ai donc le bon hostname, la bonne clef SSH autorisée, mes paquets voulus installés (qui n'étaient pas dans le template), mon OS à jour.

L'autre truc fun, c'est qu'à la création du template, vous pouvez choisir un disque root plus grand. Eh bien CloudInit va agrandir le FS tout seul, donc vous aurez bien la nouvelle capacité disponible.

Après il existe plein d'autres trucs marrant avec, comme exécuter des commandes au boot, appeler des URLs avec des requêtes POST, ajouter des dépôts APT, préconfigurer un minion Salt/Ansible/Puppet etc etc. cf la page d'exemples

Certes, ça existe depuis longtemps chez Amazon, DO, OpenStack Mais c'est très utile, et combiné à un self service qui va bien, c'est assez chouette je trouve

Voilà désolé du dérangement Si vous voulez savoir comment ça marche derrière, c'est aussi rigolo (à base de buffer FAT envoyé en stream sur l'API de XenServer)

Tu taff sur un serveur de pre-prod qui réplique quotidiennement (ou pas) la prod.
Faire du support direct sur la prod, ça tient pas mal du cow-boy qui a pas sa place dans une grande structure.

On a un serveur de pre-prod qui est une réplique niveau code applicatif et données applicatives mais les données business sont différentes.
Donc quand un user nous demande par exemple d'archiver des données de la DB, à part en ayant accès en prod je vois pas comment tu peux faire.
Ou simplement quand on te demande tous les mois de te faire un export d'une table parce que personne veut payer pour développer le rapport et que ça te prend 5 min à faire.

git

Y U DO DIS TO ME

j'utilise de plus en plus git gui

 
bouton droit => "use local" ou "use remote" ou "revert to base" ou "run merge tool"

Là j'essaie de rebase une branche un peu bitrottée où j'ai déplacé du code sur une branche qui a modifié ce même code, les conflits triviaux de 2 lignes ils ont du mal à scaler

1/ Tu fais un script admin, testé, avec des autorisations déclarée . TU ne fais pas un mysqldump/pg_dump/ora_xxxx en ligne de commande
 
2/ tu développes le rapport ( vu qeu c'est une obligation de sécu)

 
git gui est quand même pas mal limité comparé à SourceTree/Git Extensions/etc  

A mon sens, il y a un problème de responsabilité dans ce cas-la. Ce genre de truc, ça devrait être géré par les équipes de support de prod, pas par les devs

=> c'est un outils simple pour réaliser des commits stage (dont résolution des conflits) + commentaire + commit + push
=> pour anlayser l'historique, faire des tags et des branches j'utilise gitk
=> pour faire des choses plus compliquées (rare) j'utilise la command line, ça reste encore le plus efficace    

D'un autre côté un dev est souvent le mieux placé pour faire du support.

Bon fin de la deuxième semaine, j'ai réussi à signer un contrat de travail, mon MacBook est commandé. C'est vraiment papy joue à la startup. J'ai eu le temps de faire mes débuts en plasturgie ( ), de commencer à trouver du monde pour faire du découpage par jet d'eau et une tonne de trucs pendant ce temps.

The Expanse, je commande les bouquins au milieu de regarder la saison 1, il se trouve qu'elle se finit sur un gros cliffhanger

y a beaucoup a lire et a apprendre, tu vas pas etre decu. Par contre, ca prends enormement de temps de voir ce qui est faisable, et ensuite l'appliquer.  
M'enfin y a des trucs plutot cool qu'on a commence a evaluer comme DynamoDB ou Lambda, IAM . ( ref sympa: https://pragprog.com/book/brapps/se [...] -page-apps )

'tain j'ai une question de plasturgie sur reddit en cours, je mate une vidéo sur les FPGA et j'ai un logiciel lié au découpage au jet d'eau ouvert dans mon virtualbox, c'est n'importe quoi

Dites les jeunes question droit du travail :
Si je travaille chez moi pour un employeur américain, quelles sont les possibilités ?
- Je monte mon entreprise et je lui vends une prestation.
- Il ouvre une filiale en France et m'emploie comme une entreprise française.
- Est-ce qu'il y a plus simple que cette dernière solution pour être employé ?
- Autre chose ?

Moi j'ai la grippe chui au lit
Et la chaudière est de nouveau en panne, ils passent lundi avec d'autres pièces à changer...

http://sci-hub.io/
merde, je découvre ça que maintenant !

Not Safe For Kadreg