Reprise du message précédent :

Tu veux dire "LibreSSL" ?

 
Pas de CVE, pas de faille

LibreSSL a été viré chez OPNSense

Nous on a plusieurs states, stocké dans des S3 (AWS).
Mais on a aucun state qui correspond à toute l'infra, c'est complètement granulaire et découpé.

mais c'est quoi le workflow qui conduit à la modification de ces fichiers ?

L'exec de Terraform, sur le même projet.
C'est le seul qui est censé y toucher.

bien sûr, mais qu'est-ce qui déclenche cette action ?

Toi qui lance Terraform sur ton projet que tu viens d'éditer.
Un pipe CI/CD dans ton outil de ci/github/gitlab qui aura détecté un push sur le code de ton infra sur la bonne branche et après avoir lancé les bons linters dessus ?

En gros, t'a tes fichiers qui décrivent l'Infra de ton projet. La première fois que tu lances Terraform dessus, il va sauvegarder dans un fichier de statut l'état qu'il a créé.
Si tu change la conf (imaginons, tu change le nombre de VM "web" que t'attends), et que tu relance Terraform sur ta conf, il va comparer ce que tu attends de l'état qu'il a sauvegardé et n'appliquer que ce qui est nécessaire pour atteindre ce que tu veux (ajouter X machines à celles déjà présentes).

quelle forme a la définition du projet, typiquement ?

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 3.27"
    }
  }

 required_version = ">= 0.14.9"
}

provider "aws" {
  profile = "default"
  region  = "us-west-2"
}

resource "aws_instance" "app_server" {
  ami           = "ami-830c94e3"
  instance_type = "t2.micro"

 tags = {
    Name = "ExampleAppServerInstance"
  }
}

Bye bye F-secure Elements  bonjour Withsecure Elements  

Donc d'un côté on a un fichier json qui décrit des machines (bon c'est déjà bizarre et j'ai du mal à croire que ce soit réellement ça la source de vérité dans un vrai projet mais admettons), puis on lance un process, qui a son tour génère :
- les machines en elles mêmes, en général au sein d'un système assez évolué qui est capable de garder des métadonnées
- une sorte de copie de l'état de ces mêmes machines, stockée dans un fichier texte, une base clé-valeur ou équivalent

bah du coup j'ai l'impression que ce système de stockage des états séparé de tout le reste est vraiment de trop et que l'état pourrait être gardé soit dans la source de vérité de départ, soit via des métadonnées dans le système cible (ie des tags en général)

Non.
C'est bien ce fichier là qui est ta source de ce que tu attends. Des machines, des réseaux, des vpc, des load balancer...
T'a pas toujours des tags sur le système que tu manipules. Et t'a potentiellement besoin de conserver des IDs uniques qui n'ont rien à faire dans ta source qui décrit un état attendu et pas des IDs. C'est tout le côté pet vs cattle.

 
Alors il y a, à mon sens, deux choses.  
Tu as la source de vérité côté code, et ça c'est ton repo de source (git).  
Et tu as la source de vérité du state, et ça, ce sont les fichiers state de terraform (qui sont stocké dans un bucket en général quand tu es sur du cloud).  
 
Il est très fortement déconseillé de stocker toute son infra sur 1 seul state.  
La raison est qu'il va faire une vérification de tout ce qui a bougé pour appliquer les changements que tu veux lui faire passer.  
Et il peut y avoir énormément de ressources à vérifier, donc ça peut prendre beaucoup de temps.  
Puis quel intérêt de vouloir vérifier si tes DNS publiques ont changé si tu déploies juste une base de données dans un réseau privé (c'est un exemple).  
 
C'est pour ça qu'en général, on découpe par module:
- par exemple, un module pour toute la partie réseau
- un module pour une partie applicative (un serveur web)
- un module pour cette même partie applicative (par exemple la base de données)
- etc..
 
Plus tu réduis ton scope de changement, moins tu verrouilles tes ressources et plus vite tu déploies.  
 
Avec terraform, tu peux même aller plus loin, et faire un espace (workspace) par environnement.  
Ainsi, avec le même code d'IaC, tu peux déployer identiquement la même chose entre l'environnement de dev vers l'env de prod.  
Tu peux variabiliser et dire que si t'es dans un environnement de prod, tu déploies un cluster (n ressources) au lieu d'1, etc..
 
 
 
 

Press F-Secure to pay respect.

c'est quoi ces discussions qui iraient très bien sur le topic sysadmin

 
et a mon avis, en tout cas chez nous c'est comme ca, t'ecris jamais du terraform direct, parceque le code est ultra relou et degueulasse
 
chez nous on a des fichiers yaml qui decrivent l'infra.
ces fichiers yaml sont parsé et on génère le code terraform.
 
et oui ton state terraform est jamais monolithique, c'est suicidaire  
on a par exemple plusieurs state terraform par projet et environnement, un pour les VM, un pour le réseau
le seul qui est global c'est pour ce qui est transverse / pas réellement multi tenant, par exemple les firewall, 1 state par firewall
 
si tu ajoutes une vm dans un projet, tu vas jouer que le terraform des vm dans ce projet, la modif prend quelques secondes.
 
tout le code yaml parsé par nos générateurs sert aussi a remplir la CMDB (pour avoir une visu graphique de l'existant)
on travaille a la génération de la doc automatiquement a partir des descriptions d'infra et de firewall (diagramme de flux and co)
 
l'avantage de ce systeme :
- les gens qui déploient des infras n'ont pas a connaitre les syntaxes terraform, ils ont juste a savoir décrire ce qu'ils veulent
- c'est beaucoup beaucoup plus lisible, si tu sais lire du yaml et que tu connais ansible, t'as quasi plus besoin d'ecrire de la doc et on va essayer de la généréer > doc tjs a jour meme en cas de modif
 
quand tu fais un terraform apply, il va comparer ce qu'il a lui dans son état, vs ce qu'il trouve en réel dans la cible, tout ce qui differe est modifié
l'avantage :
- toute modif appliqué a l'infra manuellement est remise en l'etat par rapport a ce que ta source de vérité demande
- t'as pas besoin de gérer les suppressions, t'as plus besoin d'une vm, tu la supprimes dnas ton terraform > terraform apply > 1 vm qui n'existe pas dans le state existe dans la cible > je supprime

 
C'est pas le topic dev    

 
Joli

RIEN capté à vos histoires

Nous et nos clients, on fait du terraform directement. Jamais vu de surcouche. On fait des modules prédéfinis qu'utilisent les applicatifs

et c'est comme ça que tu es remplacé par du yaml

 
C'est parce que tu es sobre. Reviens dans quelques heures

Yep pareil ici, jamais eu de surcouche.  
 
J'ai par contre regardé du côté de Terragrunt pour rendre le code encore plus malléable mais je suis finalement pas allé plus loin que ça, terraform faisait déjà suffisamment ce dont j'avais besoin.  
 
Sur AWS j'ai déployé une infra complète en IaC juste avec du terraform (et du packer/ansible mais ça c'est encore un autre sujet),  y a du loadbalancing, du fargate, des comptes IAC, de la sécu, etc..

Tu sais comment on fait les bébés ?

En branchant la souris sur le port PS2 ?  

 
que contiennent en plus / en moins / en différent les fichiers yaml, par rapport aux fichiers terraform ?
 
 

 
et au final il y a des grosses différences entre le modèle de données/découpage des tfstates et le modèle de données de la CMDB ?

c'est une extension les .yaml non ? j'ai cru voir passer mais jconfond ptet

Il y a du monde qui utilise DirectAccess ?
 
Sur le papier ça a l'air bien, l'idée étant se passer des vpn sans ouvrir toute l'infra aux 4 vents.
Mais j'en ai jamais vu et je me demande pourquoi.

On a utilisé ça un temps à ma cogip précédente. Enfin je sais pas ce que c'est devenu depuis, mais à l'époque c'était un VPN.

Ah ouais c'est chaud la faut abattre

J'en ai déployé quelques uns.
Sur le papier c'est top mais ça pose quelques contraintes liées à l'utilisation obligatoire d'ipv6 (et donc des technologies de transition).
Le déploiement peut être assez laborieux, c'est compliqué à troubleshooter (pas beaucoup de log, tout est chiffré...) mais une fois que ça fonctionne c'est robuste, t'en entends plus parler.
On a eu des problèmes de montée en charge au premier confinement, sans comprendre pourquoi (les serveurs se tournaient les pouces). On a fini par déployer plus de serveurs moins puissants, même Microsoft était incapable de nous aider malgré des case en sévérité A.

Et on en arrive à la vraie réponse : c'est pas techniquement deprecated mais c'est abandonné par MS. Vise plutôt AutoVpn qui est la techno sur laquelle ils continuent de travailler.

Ah ouais, d'un coup je croyais être rouillé, mais en fait pas tant que ca  

Flexion, Extension, Flexion, Extension  

j'ai vu passer des fichiers nommés comme ça, ca peut aussi bien vouloir dire que c'est préhistorique et encore utilisé, ou bien moderne et que ca a réussi a s'infiltrer a l'hosto

mon dieu mon dieu tout ces acronymes dans rien que le 1er paragraphe de l'article wikipedia

Et un conscient et subconscient, et deux conscient et subconscient, et trois conscient et subconscient.  

yaml.docx

J'ai lu "Firefox, extension, ..."
 
 

Tiens, sur un "contrôleur" S100i SR (Software RAID) avec pilote 106.12.6.0 à jour sur ML110G10 à jour sous 2019 std en DC, je suis obligé de toggler (ON > OFF > ON) une fois l'état du cache dans les propriétés du contrôleur dans SSA (à jour aussi) pour récupérer le cache en écriture sur un volume RAID 1 non système (2x 4 To HPE FW à jour aussi).
 
Relou.

la semaine derniere on a décommissionné une vm ansible+docker non touchée depuis 2017, elle... lançait des taches planifs sur un 2012r2 car pourquoi faire simple ?

 
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