Reprise du message précédent :

 
on utilise ca depuis plusieurs années
t'en entends jamais parlé. ca marche tres bien. Des fois quelques petits bugs de reco du client lors d'une coupure de ocnnexion (sortie de veille par exemple j'ai deja eu le cas) mais tu rebootes et ca revient.
pour le user c'est hyper confortable
 
par contre comme dit, c'est abandonné par MS qui le remplace par AlwaysOn VPN (et pas autovpn)
qui n'a pas les contraintes sur ipv6 (on a une vieille appli incompatible chez nous) mais qui me semble bien plus usine a gaz a deployer
 
un autre défaut majeur pour directacces qui peut poser des problemes dans des environnements tres segmenté
toutes les connexions sont vu comme provenant du serveur directaccess (ip source), du coup impossible de faire des regles par population
 
je pense que always on n'a pas non plus ce probleme la mais j'ai pas encore eu le temps de tester

"Modèle : ATA VK000480GWSXF  
Version du microprogramme : HPG2  
Température Courant : 32°C, Maximum : 40°C  
État d'utilisation des SSD : OK  
Nombre d'heures de fonctionnement : 16422  
Durée de vie restante estimée selon la charge de travail à ce jour : 1367815 jour(s)  
Utilisation du SSD : 0.05%"
 
Wouhou  

 
 
en plus rien (enfin si parceque du coup les fichiers servent aussi pour ansible avec les variables dédiés a ansible) mais par contre ca permet de bien plus simplement deployer une vm et de rajouter de l'automatisation sur certains trucs
 
par exemple on decrit une VM avec :
name: toto
template: rocky8
gabarits: p1-2 (performance generation 1 ,2 vcpu)
storagetype: local
datacenter: 1
role: webserver
 
a partir de ces info (et d'autres que je peux pas mettre ici) on va automatiquement générer le hostname de la machine (pas d'erreur de non respect de la charte de nommage) exemple : proj-env-d1-ws-toto
on génère le code terrafom, le stockage a utilisé est calculé automatiquement selon le datacenter utilisé, le storage type demandé, le gabarit de la VM (cpu/ram/espace disque) etc. Ca evite aussi le mec qui joue et qui crée des VM hors gabarits
 
c'est quand meme plus simple pour qqu'un qui doit deployer des VM d'ecrire ces quelques lignes (y'en a plus evidemment pour le réseau and co) que d'ecrire  
 
resource "vsphere_virtual_machine" "proj-env-d1-ws-toto" {
  name  = "proj-env-d1-ws-toto"
  resource_pool_id  = data.vsphere_compute_cluster.cluster_1.resource_pool_id  
  storage_policy_id = data.vsphere_storage_policy.cluster_1_local_storage_policy.id
  datastore_cluster_id = data.vsphere_datastore_cluster.cluster_1_local.id
 
  wait_for_guest_net_routable = false
 
  num_cpus = 2
  memory = 8192
   
  guest_id  = data.vsphere_virtual_machine.dc_1_rocky8.guest_id
  firmware  = data.vsphere_virtual_machine.dc_1_rocky8.firmware
  folder    = vsphere_folder.dc_1_projet-env.path
  network_interface {
    network_id   = vsphere_distributed_port_group.dc_1_projet_env-reseau.id
  }
  disk {
    label = "disk0"
    size = 100
    thin_provisioned = true
  }
 
  clone {
    template_uuid = data.vsphere_virtual_machine.dc_1_rocky8.id
  }
 
 
etc...
 
sans compter tous les data nécessaire par exemple dans le cas de vmware, le datacenter, le cluster, les storages, les dvswitch etc
c'est imbitable si tu génères pas le code  
 

 
je suis pas sur de voir ce que tu veux dire

jme demande ce que ca fait de bosser dans une boite moderne, avec des creations de vm automatiques etc , je vous lis mais je n'arrive pas a y croire

On bosse sur des technologies anciennes, très anciennes, mais j'essaie de me tenir à jour quand même

 
on est pas encore a la créa automatique, et on en a pas vraiment le besoin (par exemple pour suivre des montées/baisses de charge)
mais bon typiquement a partir de ca t'as un projet avec un environement de test/preprod, tu veux le passer en prod tu dupliques les dossiers tu changes juste 2/3 infos > terraform apply > ansible-playbook et ton infra de prod est pret iso de ce que t'as fait en test/preprod

j'ai regardé ct'aprem, j'ai créé 1230 vms depuis aout 2018, soit presque une par jour de moyenne, le record étant a 11 ou 12 je crois dans une meme journée de 8h "ah il nous faut ces 25 vm pour vendredi si possible"

je reverais de voir ca a l'oeuvre, pas simplement recette => prod comme partout mais tout le process dev/recette/preprod/prod comme dans la théorie

Tout ça sans automatisation

Je dois faire 1 VM de prod par an, donc pas trop besoin ici, par contre dans le lab c'est pas pareil J'ose pas imaginer faire des VMs à ce rythme que tu as sans automatiser à mort

mais genre, tu fais ca tout à la main, monter l'ISO d'installation, remplir le setup, etc...? En 2022? Tous les jours, et plusieurs fois par jour?

ca dpened ce qu'on appelle a la main
si t'as des templates dans vmware ca prend pas non plus 500 ans mais c'est ultra relou

Je pratique plus depuis des années, mais bon quand t'as beaucoup de vms à mettre, les templates c'était quand même chiant

Ça s'appelait AutoVpn dans les premières release de Windows 10 et j'ai jamais réussi à me faire au nom définitif

clic droit dans scvmm*, new vm, créer l'enveloppe d'apres la demande en fichier excel jointe dans le ticket, accroche pxe on met l'os la langue ca descend l'image, puis majs windows, ip domaine

en gros 3 VM toutes les 40min pour du win2019+ avec creation de la fiche inventaire pendant les temps morts ca me manquera pas

*ou vcenter on n'est pas begueules

Le bonheur.

 
ah ca je dis pas
 

 
je savais pas tiens que ca s'appelait comme ca au debut

en gros il faudrait quelques devops pendant quelques semaines pour faire les moulinettes qui manquent, car changer les process ca va pas etre possible

Et Dieu inventa le SOAR

Tiens d'ailleurs grosse colère du moment    

 
Typiquement les modules créées par le CCoE chez un de mes clients (Cloud Center of Excellence pour XaTriX le noob) s'occupe de créer les modules Terraform qui vont abstraire toute cette complexité pour qu'au final les équipes applicatives n'ai qu'à mettre comme paramètres ce que tu as mis

CCNE cisco ? ok

C'est ce que je fais en tant que dev: mise a jour du playbook et template sur Ansible Tower. Test de deploy FE/BE/Batch. Quand ok go e2e puis val et prod si tout ok. A chaque fois c'est un click sur un bouton. Tu ajoutes liquibase sur ton serveur BE et tu es le roi du petrole.  

 
A vos souhaits

Zut j'en ai plein les mains,  

 
 
le problème avec cette approche c'est que tu peux te retrouver à ne devoir utiliser que les services déjà qualifiés/packagés par le CCoE  qui au bout d'un moment n'arrive plus à suivre les besoins des différents projets

Chez nous vu la gueule des référentiels cmdb and co, vaut mieux être du matin pour que ça marche

J'ai du python à refaire Fait chier
 
Certains ont commencé à tâter vraiment sérieusement du Rocky linux en entreprise?

C'est à l'étude chez nous.

Vous faites déjà du test dessus, ou c'est juste de l'étude?
 
J'ai un peu testé, ca avait l'air de faire le boulot, mais pas encore bien pratiqué assez.

 
C'est en effet le problème.
Du coup chez certaines équipes plus matures on est en mode inversé : une personne du CCoE suit l'équipe applicative en mode "consulting" pour s'assurer que les best practices (gouvernance, sécu, finops) sont respectées et des fois les modules développés par ces équipes sont intégrées par le CCoE pour être utilisées par d'autres équipes.

 
Tututut, ça ne rajoutera que quelques jours de presta, t'en fais pas, on est super forts pour ça - vendre de la presta.

 
Mec, ton avenir pro va être compliqué si tu prends pas les bons virages rapidement.

 
Y'a du test, côté build, incluant du déploiement de vm de bac à sable, oui.
C'est pas différent d'une rhel ou centos au final.

Plus sur la stabilité du truc. Bon dans un sens, aucune raison que ca ne soit pas stable. A l'utilisation, ben ca sera pareil que rhel/centos oui

Ca dépend tes envies mais pour continuer à faire l'homme à tout faire + systeme windows moisi y'aura du boulot longtemps

 
 
intéressant  

C'est exactement ce que l'on va mettre en place chez nous (bien qu'on a pas de CCoE, on est pas à cette taille là)
On a pas mal d'équipe de dev différentes pour lesquelles les besoin d'infra/cicd sont très marginaux et n'ont pas besoin d'un ingé infra/devops à 100%.  
Pour autant, on a besoin de suivre ces besoins, ces demandes, déjà pour garantir une certaine harmonie dans le choix des solutions et d'architecture techniqes.  
Ensuite, comme on a l'expertise, ça nous évite, quand on nous sollicite, d'y passer 5j à comprendre le bordel qui a été mis en place, sans respect des bonnes pratiques, etc.

Donc on envisage une ressource "volante" qui soit capable d'intervenir ponctuellement sur ces projets, tout en étant capable de suivre et participer régulièrement à la conception, évolution et mise en oeuvre de l'état de l'art de nos outils, de l'infrastructures et des processus associés.

Bonjour    
 
Est-ce que vous auriez des stations d'accueil à recommander?
HDMI, RJ45, au moins 3 USB, 1 port audio jack in/out et alimentation du PC via le port USB-C de ce dernier?
 
Je prenais la Dell D6000(S) ou la WD19(S) mais les temps de production/livraison sont vraiment trop long (le 3 juin pour le WD19 actuellement).

 
La sagesse de cet homme