-
-
Notifications
You must be signed in to change notification settings - Fork 14
/
2022-cdktf-nixos.html
822 lines (716 loc) · 32.8 KB
/
2022-cdktf-nixos.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
---
title: Gérer une infrastructure avec Terraform, CDKTF et NixOS
description: |
Comment j'utilise CDKTF, Terraform, Nix et NixOS pour gérer mon infrastructure
personnelle.
uuid: a8682289-f1ec-4f54-ac54-839d2dc46417
attachments:
"https://github.com/vincentbernat/cdktf-take1": dépôt pour CDKTF
"https://github.com/vincentbernat/nixops-take1": dépôt pour NixOps
tags:
- distribution-nixos
---
Il y a quelques années, j'ai réduit mon infrastructure personnelle au strict
minimum. Jusqu'en 2018, elle représentait une douzaine de conteneurs tournant
sur un seul serveur [Hetzner][][^hetzner]. J'ai migré mon courriel vers
[Fastmail][] et mes zones DNS vers [Gandi][]. Il ne me restait plus que mon blog
à héberger. À ce jour, ma petite infrastructure est composée de 4 machines
virtuelles exécutant [NixOS][] sur *Hetzner Cloud* et [Vultr][], d'une poignée
de zones DNS sur *Gandi* et [Route 53][], et de quelques distributions
[Cloudfront][]. Elle est gérée par [CDK pour Terraform][CDK for Terraform]
(CDKTF), tandis que les déploiements de *NixOS* sont gérés par [NixOps][].
Dans cet article, je présente brièvement *Terraform*, *CDKTF* et l'écosystème
*Nix*. J'explique également comment utiliser *Nix* pour accéder à ces outils
dans votre shell afin de les utiliser rapidement.
!!! "Mise à jour (11.2023)" Récemment, *HashiCorp* [a opté pour la Business
Source License][switched to the Business Source License] pour tous ces
logiciels. C'est une déception, notamment pour *Terraform* qui est un composant
clé pour automatiser les infrastructures et qui a bénéficié d'une large
communauté. Il existe désormais un fork communautaire, [OpenTofu][], mais
celui-ci ne couvre pas *CDKTF*.
[^hetzner]: C'était un AMD Athlon 64 X2 5600+ avec 2 Go de RAM et 2 disques de
400 Go en RAID logiciel. Je payais quelque chose autour de 59 € par mois
pour cela. Si c'était une bonne affaire en 2008, en 2018, ce n'était plus
rentable. Il fonctionnait sous Debian Wheezy avec [Linux-VServer][] pour
l'isolation, tous deux dépassés en 2018.
[TOC]
# CDKTF : infrastructure en tant que code
[Terraform][] est un outil d'« infrastructure en tant que code ». Vous pouvez
définir votre infrastructure en déclarant des ressources avec le [langage
HCL][HCL language]. Ce dernier possède quelques fonctionnalités supplémentaires,
comme des boucles permettant de déclarer plusieurs ressources à partir d'une
liste, des fonctions intégrées que vous pouvez appeler dans les expressions et
l'expansion de variables dans les chaînes de caractères. *Terraform* s'appuie
sur un large [ensemble de fournisseurs][large set of providers] pour gérer les
ressources.
## Gérer des serveurs
Voici un court exemple utilisant le [fournisseur pour Hetzner Cloud][Hetzner
Cloud provider] pour créer une machine virtuelle :
```terraform
variable "hcloud_token" {
sensitive = true
}
provider "hcloud" {
token = var.hcloud_token
}
resource "hcloud_server" "web03" {
name = "web03"
server_type = "cpx11"
image = "debian-11"
datacenter = "nbg1-dc3"
}
resource "hcloud_rdns" "rdns4-web03" {
server_id = hcloud_server.web03.id
ip_address = hcloud_server.web03.ipv4_address
dns_ptr = "web03.luffy.cx"
}
resource "hcloud_rdns" "rdns6-web03" {
server_id = hcloud_server.web03.id
ip_address = hcloud_server.web03.ipv6_address
dns_ptr = "web03.luffy.cx"
}
```
L'expressivité de _HCL_ est assez limitée et je trouve qu'un langage généraliste
est plus pratique pour décrire les ressources. C'est là qu'intervient _CDK pour
Terraform_ : vous pouvez gérer votre infrastructure à l'aide de votre langage de
programmation préféré, notamment TypeScript, Go et Python. Voici l'exemple
précédent utilisant _CDKTF_ et TypeScript :
```typescript
import { App, TerraformStack, Fn } from "cdktf";
import { HcloudProvider } from "./.gen/providers/hcloud/provider";
import * as hcloud from "./.gen/providers/hcloud";
class MyStack extends TerraformStack {
constructor(scope: Construct, name: string) {
super(scope, name);
const hcloudToken = new TerraformVariable(this, "hcloudToken", {
type: "string",
sensitive: true,
});
const hcloudProvider = new HcloudProvider(this, "hcloud", {
token: hcloudToken.value,
});
const web03 = new hcloud.server.Server(this, "web03", {
name: "web03",
serverType: "cpx11",
image: "debian-11",
datacenter: "nbg1-dc3",
provider: hcloudProvider,
});
new hcloud.rdns.Rdns(this, "rdns4-web03", {
serverId: Fn.tonumber(web03.id),
ipAddress: web03.ipv4Address,
dnsPtr: "web03.luffy.cx",
provider: hcloudProvider,
});
new hcloud.rdns.Rdns(this, "rdns6-web03", {
serverId: Fn.tonumber(web03.id),
ipAddress: web03.ipv6Address,
dnsPtr: "web03.luffy.cx",
provider: hcloudProvider,
});
}
}
const app = new App();
new MyStack(app, "cdktf-take1");
app.synth();
```
La commande de `cdktf synth` génère un fichier de configuration pour
_Terraform_, `terraform plan` prévisualise les changements et `terraform apply`
les applique. Maintenant que vous disposez d'un langage généraliste, vous pouvez
utiliser des fonctions.
## Gérer des enregistrements DNS
Si l'utilisation de _CDKTF_ pour 4 serveurs web peut sembler un peu exagérée, il
en va tout autrement lorsqu'il s'agit de gérer quelques zones DNS. Avec
[DNSControl][], qui utilise JavaScript comme langage, j'ai pu définir la zone
`bernat.ch` avec ce bout de code :
```js
D("bernat.ch", REG_NONE, DnsProvider(DNS_BIND, 0), DnsProvider(DNS_GANDI),
DefaultTTL('2h'),
FastMailMX('bernat.ch', {subdomains: ['vincent']}),
WebServers('@'),
WebServers('vincent');
```
Cela produit 38 enregistrements. Avec _CDKTF_, j'écris :
```ts
new Route53Zone(this, "bernat.ch", providers.aws)
.sign(dnsCMK)
.registrar(providers.gandiVB)
.www("@", servers)
.www("vincent", servers)
.www("media", servers)
.fastmailMX(["vincent"]);
```
Toute la magie est située dans les fonctions appelées. Vous pouvez regarder le
fichier [dns.ts][] dans le dépôt [cdktf-take1][] pour comprendre comment cela
fonctionne. Rapidement :
- `Route53Zone()` crée une zone sur *Route 53*,
- `sign()` signe la zone avec une clé maître,
- `registrar()` inscrit la zone auprès du registre de domaines et configure DNSSEC,
- `www()` crée les enregistrements `A` et `AAAA` pour les serveurs web,
- `fastmailMX()` crée les enregistrements `MX` et d'autres enregistrements liés
pour configurer *Fastmail* en tant que fournisseur de courriel.
Voici le contenu de la fonction `fastmailMX()`. Elle génère quelques
enregistrements et retourne la zone en cours pour faciliter le chaînage :
```ts
fastmailMX(subdomains?: string[]) {
(subdomains ?? [])
.concat(["@", "*"])
.forEach((subdomain) =>
this.MX(subdomain, [
"10 in1-smtp.messagingengine.com.",
"20 in2-smtp.messagingengine.com.",
])
);
this.TXT("@", "v=spf1 include:spf.messagingengine.com ~all");
["mesmtp", "fm1", "fm2", "fm3"].forEach((dk) =>
this.CNAME(`${dk}._domainkey`, `${dk}.${this.name}.dkim.fmhosted.com.`)
);
this.TXT("_dmarc", "v=DMARC1; p=none; sp=none");
return this;
}
```
Je vous encourage à parcourir le [dépôt][cdktf-take1] pour plus de détails !
## À propos de Pulumi
Ma première tentative autour de _Terraform_ a été d'utiliser [Pulumi][]. Vous
pouvez trouver cette tentative sur [GitHub][pulumi-github]. C'est assez
similaire à ce que je fais actuellement avec _CDKTF_. La principale différence
est que j'utilise Python au lieu de TypeScript[^python] car ce dernier ne
m'était pas familier à l'époque.
[^python]: Je n'ai pas non plus utilisé Python car le support de *Poetry* dans
*Nix* était [cassé][broken] quand j'ai commencé à essayer d'utiliser
_CDKTF_.
_Pulumi_ est antérieur à _CDKTF_ et il utilise une approche légèrement
différente. _CDKTF_ génère une configuration pour _Terraform_ (au format JSON au
lieu de HCL), laissant la planification, la gestion des états et le déploiement
à ce dernier. Il est donc lié aux limites de ce qui peut être exprimé par
_Terraform_, notamment lorsque vous devez transformer des données obtenues d'une
ressource à une autre[^transform]. _Pulumi_ a besoin de fournisseurs spécifiques
pour chaque ressource. De nombreux fournisseurs encapsulent des fournisseurs
_Terraform_.
[^transform]: *Pulumi* peut [appliquer des fonctions arbitraires][apply
arbitrary functions] à l'aide de `apply()`. Cela permet de transformer les
données qui ne sont pas connues lors de l'étape de planification.
*Terraform* a des [fonctions][tf functions] pour un usage similaire mais
elles sont plus limitées.
Bien que _Pulumi_ offre une bonne expérience utilisateur, je suis passé à
_CDKTF_ car écrire des fournisseurs pour _Pulumi_ est une corvée. _CDKTF_ ne
nécessite pas de passer par cette étape. En dehors des grands acteurs (AWS,
Azure et Google Cloud), l'existence, la qualité et la fraîcheur des fournisseurs
_Pulumi_ sont inégales. La plupart des fournisseurs s'appuient sur un
fournisseur _Terraform_ et il se peut qu'ils soient en retard de quelques
versions, qu'il leur manque quelques ressources ou qu'ils présentent des bogues
qui leur sont propres.
Lorsqu'un fournisseur n'existe pas, vous pouvez en écrire un à l'aide de la
bibliothèque [pulumi-terraform-bridge][]. Le projet Pulumi fournit un
[modèle][boilerplate] à cet effet. J'ai eu une mauvaise expérience avec celui-ci
lors de l'écriture de fournisseurs pour [Gandi][provider-gandi] et
[Vultr][provider-vultr] : le `Makefile` [installe automatiquement
Pulumi][pulumi-pr51] en utilisant `curl | sh` et [ne fonctionne pas avec
`/bin/sh`][pulumi-pr52]. Il y a un manque d'intérêt pour les contributions
communautaires[^maint] ou même pour [les fournisseurs pour les acteurs
tiers][providers for smaller players].
[^maint]: Les deux modifications mentionnées ne sont pas encore fusionnées. La
seconde est remplacée par la [PR #61][pulumi-pr61], soumise deux mois plus
tard, qui impose l'utilisation de `/bin/bash`. J'ai également soumis la
[PR #56][pulumi-pr56], qui a été fusionnée 4 mois plus tard et rapidement
annulée sans explication.
# NixOS & NixOps
[Nix][nix-lang] est un langage de programmation purement fonctionnel.
[Nix][nix-tool] est aussi le nom du gestionnaire de paquets qui est construit
au-dessus du langage _Nix_. Il permet aux utilisateurs d'installer des paquets
de manière déclarative. [nixpkgs][] est un dépôt de paquets. Vous pouvez
[installer _Nix_][nix-install] au-dessus d'une distribution Linux ordinaire. Si
vous voulez plus de détails, une bonne ressource est le [site
officiel][nix-web], notamment la [section « Apprendre »][learn section]. La
courbe d'apprentissage est rude, mais la récompense est grande.
## NixOS : distribution Linux déclarative
[NixOS][] est une distribution Linux construite au-dessus du gestionnaire de
paquets _Nix_. Voici un bout de configuration pour ajouter quelques paquets :
```nix
environment.systemPackages = with pkgs;
[
bat
htop
liboping
mg
mtr
ncdu
tmux
];
```
Il est possible de modifier une dérivation[^derivation] existante pour utiliser une version
différente, activer une fonctionnalité spécifique ou appliquer un correctif.
Voici comment j'active et configure _Nginx_ pour désactiver le module `stream`,
ajouter le module de [compression Brotli][Brotli compression module] et ajouter
le module d'[anonymisation des adresses IP][IP address anonymizer module]. De
plus, au lieu d'utiliser _OpenSSL 3_, je continue à utiliser _OpenSSL
1.1_[^openssl].
[^derivation]: Grosso modo, une dérivation est un synonyme pour paquet dans
l'écosystème *Nix*.
```nix
services.nginx = {
enable = true;
package = (pkgs.nginxStable.override {
withStream = false;
modules = with pkgs.nginxModules; [
brotli
ipscrub
];
openssl = pkgs.openssl_1_1;
});
```
Si vous avez besoin d'ajouter certaines modifications, c'est également possible.
À titre d'exemple, voici comment j'ai corrigé en avance les [failles de sécurité
découvertes en 2019 dans *Nginx*][dos-nginx] en attendant que cela soit corrigé
dans *NixOS*[^security] :
```nix
services.nginx.package = pkgs.nginxStable.overrideAttrs (old: {
patches = old.patches ++ [
# HTTP/2: reject zero length headers with PROTOCOL_ERROR.
(pkgs.fetchpatch {
url = https://github.com/nginx/nginx/commit/dbdd[…].patch;
sha256 = "a48190[…]";
})
# HTTP/2: limited number of DATA frames.
(pkgs.fetchpatch {
url = https://github.com/nginx/nginx/commit/94c5[…].patch;
sha256 = "af591a[…]";
})
# HTTP/2: limited number of PRIORITY frames.
(pkgs.fetchpatch {
url = https://github.com/nginx/nginx/commit/39bb[…].patch;
sha256 = "1ad8fe[…]";
})
];
});
```
[^openssl]: *OpenSSL 3* a de nombreux [problèmes de performance][performance regressions].
[^security]: _NixOS_ peut être un peu lent à intégrer les correctifs car il est
nécessaire de reconstruire une partie du cache binaire. Dans ce cas précis,
cela a été rapide : la vulnérabilité et les correctifs ont été publiés le 13
août 2019 et disponibles dans NixOS le 15 août. À titre de comparaison,
Debian n'a publié la version corrigée que le 22 août, ce qui est
inhabituellement tardif.
Si cela vous intéresse, jetez un coup d'œil à ma configuration relativement
réduite : [`common.nix`][common.nix] contient la configuration à appliquer sur
tous les serveurs (SSH, utilisateurs, paquets communs), [`web.nix`][web.nix]
contient la configuration pour les serveurs web et [`isso.nix`][isso.nix]
exécute [Isso][] dans un conteneur _systemd_.
## NixOps : outil de déploiement pour NixOS
Sur un seul nœud, la configuration de _NixOS_ se trouve dans le fichier
`/etc/nixos/configuration.nix`. Après l'avoir modifiée, vous devez exécuter la
commande `nixos-rebuild switch`. _Nix_ va chercher toutes les dépendances
possibles dans le cache binaire et construit le reste. Il crée une nouvelle
entrée dans le menu du chargeur de démarrage et active la nouvelle
configuration.
Pour gérer plusieurs nœuds, il existe plusieurs options, dont [NixOps][],
[deploy-rs][], [Colmena][] et [morph][]. Je ne les connais pas toutes, mais de
mon point de vue, les différences ne sont pas si importantes. Il est également
possible de construire un tel outil soi-même car _Nix_ fournit les blocs de
construction les plus importants : `nix build` et `nix copy`. _NixOps_ est l'un
des premiers outils publiés mais je vous encourage à explorer les alternatives.
La configuration de *NixOps* est écrite avec la langage *Nix*. Voici une
configuration simplifiée pour déployer `znc01.luffy.cx`, `web01.luffy.cx` et
`web02.luffy.cx`, à l'aide des fonctions `server` et `web` :
```nix
let
server = hardware: name: imports: {
deployment.targetHost = "${name}.luffy.cx";
networking.hostName = name;
networking.domain = "luffy.cx";
imports = [ (./hardware/. + "/${hardware}.nix") ] ++ imports;
};
web = hardware: idx: imports:
server hardware "web${lib.fixedWidthNumber 2 idx}" ([ ./web.nix ] ++ imports);
in {
network.description = "Luffy infrastructure";
network.enableRollback = true;
defaults = import ./common.nix;
znc01 = server "exoscale" [ ./znc.nix ];
web01 = web "hetzner" 1 [ ./isso.nix ];
web02 = web "hetzner" 2 [];
}
```
# Connecter le tout avec Nix
L'écosystème _Nix_ est une solution unifiée aux différents problèmes liés à la
gestion des logiciels et des configurations. Les [environnements de
développement déclaratifs et reproductibles][declarative and reproducible
developer environments] en constituent une caractéristique très intéressante.
Cela ressemble aux environnements virtuels de Python, mais ils ne sont pas
spécifiques à un langage.
## Courte introduction aux « flakes » Nix
J'utilise les « [flakes][] », une nouvelle fonctionnalité de _Nix_ qui améliore
la reproductibilité en fixant toutes les dépendances et en isolant le processus
de construction. Bien que cette fonctionnalité soit marquée comme
expérimentale[^experimental], elle est de plus en plus populaire et vous pouvez
trouver `flake.nix` et `flake.lock` à la racine de certains dépôts.
[^experimental]: Comme les _flakes_ sont expérimentaux, de nombreuses
documentations ne les utilisent pas et c'est un aspect supplémentaire à
apprendre.
A titre d'exemple, voici le contenu du `flake.nix` livré avec [Snimpy][], un
outil SNMP interactif pour Python reposant sur [libsmi][], une bibliothèque C :
```nix
{
inputs = {
nixpkgs.url = "nixpkgs";
flake-utils.url = "github:numtide/flake-utils";
};
outputs = { self, ... }@inputs:
inputs.flake-utils.lib.eachDefaultSystem (system:
let
pkgs = inputs.nixpkgs.legacyPackages."${system}";
in
{
# nix build
packages.default = pkgs.python3Packages.buildPythonPackage {
name = "snimpy";
src = self;
preConfigure = ''echo "1.0.0-0-000000000000" > version.txt'';
checkPhase = "pytest";
checkInputs = with pkgs.python3Packages; [ pytest mock coverage ];
propagatedBuildInputs = with pkgs.python3Packages; [ cffi pysnmp ipython ];
buildInputs = [ pkgs.libsmi ];
};
# nix run + nix shell
apps.default = {
type = "app";
program = "${self.packages."${system}".default}/bin/snimpy";
};
# nix develop
devShells.default = pkgs.mkShell {
name = "snimpy-dev";
buildInputs = [
self.packages."${system}".default.inputDerivation
pkgs.python3Packages.ipython
];
};
});
}
```
Si *Nix* est installé sur votre système :
- `nix run github:vincentbernat/snimpy` exécute *Snimpy*,
- `nix shell github:vincentbernat/snimpy` fournit un shell avec *Snimpy* prêt à être utilisé,
- `nix build github:vincentbernat/snimpy` construit le paquet Python,
- `nix develop .` fournit un shell pour développer autour de *Snimpy* depuis un
clône du dépôt[^checkout].
[^checkout]: Comme dans les autres exemples, il est possible de remplacer `.`
par `github:vincentbernat/snimpy`. Cependant, obtenir les dépendances de
*Snimpy* sans son code source a peu d'intérêt.
Pour plus d'informations sur les *flakes*, regardez le [tutoriel de
Tweag][nix-flakes].
## Nix et CDKTF
A la racine du [dépôt que j'utilise pour CDKTF][cdktf-take1], il y a un fichier
[`flake.nix`][cdktf-take1-flake.nix] pour configurer un shell avec _Terraform_
et _CDKTF_ installés et avec les variables d'environnement nécessaires pour
automatiser mon infrastructure.
Terraform est déjà présent dans _nixpkgs_, mais je dois appliquer une rustine sur
le fournisseur _Gandi_. Ce n'est pas un problème avec Nix !
```nix
terraform = pkgs.terraform.withPlugins (p: [
p.aws
p.hcloud
p.vultr
(p.gandi.overrideAttrs
(old: {
src = pkgs.fetchFromGitHub {
owner = "vincentbernat";
repo = "terraform-provider-gandi";
rev = "feature/livedns-key";
hash = "sha256-V16BIjo5/rloQ1xTQrdd0snoq1OPuDh3fQNW7kiv/kQ=";
};
}))
]);
```
*CDKTF* est écrit en TypeScript. J'ai un fichier
[`package.json`][cdktf-take1-package.json] avec toutes les dépendances
nécessaires, y compris celles pour utiliser TypeScript comme langage cible :
```json
{
"name": "cdktf-take1",
"version": "1.0.0",
"main": "main.js",
"types": "main.ts",
"private": true,
"dependencies": {
"@types/node": "^14.18.30",
"cdktf": "^0.13.3",
"cdktf-cli": "^0.13.3",
"constructs": "^10.1.151",
"eslint": "^8.27.0",
"prettier": "^2.7.1",
"ts-node": "^10.9.1",
"typescript": "^3.9.10",
"typescript-language-server": "^2.1.0"
}
}
```
J'utilise [Yarn][] pour obtenir un fichier [`yarn.lock`][cdktf-take1-yarn.lock]
qui peut ensuite être utilisé directement pour construire la dérivation
contenant toutes les dépendances :
```nix
nodeEnv = pkgs.mkYarnModules {
pname = "cdktf-take1-js-modules";
version = "1.0.0";
packageJSON = ./package.json;
yarnLock = ./yarn.lock;
};
```
L'étape suivant est de générer les fournisseurs *CDKTF* à partir des
fournisseurs _Terraform_ et de les inclure dans une dérivation :
```nix
cdktfProviders = pkgs.stdenvNoCC.mkDerivation {
name = "cdktf-providers";
nativeBuildInputs = [
pkgs.nodejs
terraform
];
src = nix-filter {
root = ./.;
include = [ ./cdktf.json ./tsconfig.json ];
};
buildPhase = ''
export HOME=$(mktemp -d)
export CHECKPOINT_DISABLE=1
export DISABLE_VERSION_CHECK=1
export PATH=${nodeEnv}/node_modules/.bin:$PATH
ln -nsf ${nodeEnv}/node_modules node_modules
# Build all providers we have in terraform
for provider in $(cd ${terraform}/libexec/terraform-providers; echo */*/*/*); do
version=''${provider##*/}
provider=''${provider%/*}
echo "Build $provider@$version"
cdktf provider add --force-local $provider@$version | cat
done
echo "Compile TS → JS"
tsc
'';
installPhase = ''
mv .gen $out
ln -nsf ${nodeEnv}/node_modules $out/node_modules
'';
};
```
Enfin, nous définissons l'environnement de développement :
```nix
devShells.default = pkgs.mkShell {
name = "cdktf-take1";
buildInputs = [
pkgs.nodejs
pkgs.yarn
terraform
];
shellHook = ''
# No telemetry
export CHECKPOINT_DISABLE=1
# No autoinstall of plugins
export CDKTF_DISABLE_PLUGIN_CACHE_ENV=1
# Do not check version
export DISABLE_VERSION_CHECK=1
# Access to node modules
export PATH=$PWD/node_modules/.bin:$PATH
ln -nsf ${nodeEnv}/node_modules node_modules
ln -nsf ${cdktfProviders} .gen
# Credentials
for p in \
njf.nznmba.pbz/Nqzvavfgengbe \
urgmare.pbz/ivaprag@oreang.pu \
ihyge.pbz/ihyge@ivaprag.oreang.pu; do
eval $(pass show $(echo $p | tr 'A-Za-z' 'N-ZA-Mn-za-m') | grep '^export')
done
eval $(pass show personal/cdktf/secrets | grep '^export')
export TF_VAR_hcloudToken="$HCLOUD_TOKEN"
export TF_VAR_vultrApiKey="$VULTR_API_KEY"
unset VULTR_API_KEY HCLOUD_TOKEN
'';
};
```
Les dérivations listées dans `buildInputs` sont disponibles dans le shell
fourni. Le contenu de `shellHook` est exécuté lors du démarrage du shell. Il
établit des liens symboliques pour rendre disponible l'environnement JavaScript
construit à une étape précédente, ainsi que les fournisseurs _CDKTF_ générés. Il
exporte également toutes les informations d'identification[^obfuscated].
[^obfuscated]: J'utilise le gestionnaire de mots de passe [pass][]. Le nom des
mots de passe sont brouillés uniquement pour éviter les courriers
indésirables.
J'utilise également [direnv][] avec un fichier [`.envrc`][cdktf-take1-envrc]
pour passer automatiquement dans l'environnement de développement. Cela permet
également à ce dernier d'être disponible depuis _Emacs_, notamment lors de
l'utilisation de [lsp-mode][] pour obtenir les complétions. `nix develop .`
permet aussi d'activer manuellement l'environnement.
J'utilise les commandes suivantes pour déployer[^cdktf-cli] :
```console
$ cdktf synth
$ cd cdktf.out/stacks/cdktf-take1
$ terraform plan --out plan
$ terraform apply plan
$ terraform output -json > ~-automation/nixops-take1/cdktf.json
```
[^cdktf-cli]: La commande `cdktf` sait appeler les commandes `terraform`, mais
je préfère les utiliser directement car elles sont plus flexibles.
La dernière commande produit un fichier JSON contenant les données nécessaires
pour finir le déploiement avec _NixOps_.
## NixOps
Le [fichier JSON][cdktf-take1-cdktf.json] exporté par *Terraform* contient la
liste des serveurs avec quelques attributs :
```json
{
"hardware": "hetzner",
"ipv4Address": "5.161.44.145",
"ipv6Address": "2a01:4ff:f0:b91::1",
"name": "web05.luffy.cx",
"tags": [
"web",
"continent:NA",
"continent:SA"
]
}
```
Dans le fichier [`network.nix`][nixops-take1-network.nix], cette liste est
importée et transformée en un ensemble d'attributs décrivant les serveurs. Une
version simplifiée ressemble à cela :
```nix
let
lib = inputs.nixpkgs.lib;
shortName = name: builtins.elemAt (lib.splitString "." name) 0;
domainName = name: lib.concatStringsSep "." (builtins.tail (lib.splitString "." name));
server = hardware: name: imports: {
networking = {
hostName = shortName name;
domain = domainName name;
};
deployment.targetHost = name;
imports = [ (./hardware/. + "/${hardware}.nix") ] ++ imports;
};
cdktf-servers-json = (lib.importJSON ./cdktf.json).servers.value;
cdktf-servers = map
(s:
let
tags-maybe-import = map (t: ./. + "/${t}.nix") s.tags;
tags-import = builtins.filter (t: builtins.pathExists t) tags-maybe-import;
in
{
name = shortName s.name;
value = server s.hardware s.name tags-import;
})
cdktf-servers-json;
in
{
// […]
} // builtins.listToAttrs cdktf-servers
```
Pour `web05`, on obtient ceci :
```nix
web05 = {
networking = {
hostName = "web05";
domainName = "luffy.cx";
};
deployment.targetHost = "web05.luffy.cx";
imports = [ ./hardware/hetzner.nix ./web.nix ];
};
```
Comme pour *CDKTF*, à la racine du [dépôt que j'utilise pour
NixOps][nixops-take1], il y a un fichier [`flake.nix`][nixops-take1-flake.nix]
pour fournir un shell avec *NixOps* configuré. Comme *NixOps* ne supporte pas
les déploiements progessifs, j'utilise généralement ces commandes pour déployer
sur un unique serveur[^disable] :
```console
$ nix flake update
$ nixops deploy --include=web04
$ ./tests web04.luffy.cx
```
[^disable]: Si le changement est risqué, je [désactive le serveur][disable the
server] avec _CDKTF_. Cela le retire des enregistrements DNS.
Si les tests se déroulent sans soucis, je déploie les autres nœuds un par un
avec la commande suivante :
```console
$ (set -e; for h in web{03..06}; do nixops deploy --include=$h; done)
```
La commande `nixops deploy` déploie tous les serveurs en parallèle et peut donc
provoquer une panne si tous les serveurs *Nginx* sont indisponibles au même
moment.
---
Cet article est en chantier depuis trois ans. Le contenu a été mis à jour et
affiné au fur et à mesure de mes expérimentations. Il y a encore beaucoup à
explorer[^todo], mais j'estime que le contenu est désormais suffisant pour être
publié ! 🎄
[^todo]: Je voudrais remplacer *NixOps* avec une alternative gérant les
déploiements progressifs et les tests. Je voudrais aussi passer à [Nomad][]
ou *Kubernetes* pour déployer les applications.
*[HCL]: HashiCorp Configuration Language
*[CDKTF]: Cloud Development Kit for Terraform
[fastmail]: https://www.fastmail.com/
[hetzner]: https://www.hetzner.com/ "Hetzner: dedicated servers, cloud, storage & hosting"
[linux-vserver]: http://linux-vserver.org/Welcome_to_Linux-VServer.org "Linux-VServer"
[gandi]: https://www.gandi.net/en "Gandi: Domain Names, Web Hosting, Mail"
[nixos]: https://nixos.org/ "Nix: reproducible builds and deployments"
[pulumi]: https://www.pulumi.com/ "Pulumi: universal infrastructure as code"
[route 53]: https://aws.amazon.com/route53/ "Amazon AWS: Route 53"
[cloudfront]: https://aws.amazon.com/cloudfront/ "Amazon AWS: CloudFront"
[cdk for terraform]: https://developer.hashicorp.com/terraform/cdktf "Cloud Development Kit for Terraform"
[nixops]: https://github.com/NixOS/nixops "NixOps: tool for deploying to NixOS machines in a network or cloud"
[pulumi-github]: https://github.com/vincentbernat/pulumi-take1
[apply arbitrary functions]: https://www.pulumi.com/docs/intro/concepts/inputs-outputs/#apply
[tf functions]: https://developer.hashicorp.com/terraform/language/functions
[pulumi-terraform-bridge]: https://github.com/pulumi/pulumi-terraform-bridge
[boilerplate]: https://github.com/pulumi/pulumi-tf-provider-boilerplate
[provider-gandi]: https://github.com/vincentbernat/pulumi-gandi-old "Deprecated Pulumi provider for Gandi"
[provider-vultr]: https://github.com/vincentbernat/pulumi-vultr "Pulumi provider for Vultr"
[pulumi-pr51]: https://github.com/pulumi/pulumi-tf-provider-boilerplate/pull/51 "PR #51: Do not install pulumi automatically"
[pulumi-pr52]: https://github.com/pulumi/pulumi-tf-provider-boilerplate/pull/52 "PR #52: Fix Makefile to work with a POSIX shell"
[pulumi-pr61]: https://github.com/pulumi/pulumi-tf-provider-boilerplate/pull/61 "PR #61: Explicitly specify bash as shell in Makefile"
[pulumi-pr56]: https://github.com/pulumi/pulumi-tf-provider-boilerplate/pull/56 "PR #56: Use go:embed instead of go generate for schema"
[pulumi-pr66]: https://github.com/pulumi/pulumi-tf-provider-boilerplate/pull/66 "PR #66: Revert “Use go:embed instead of go generate for schema”"
[providers for smaller players]: https://twitter.com/briggsl/status/1473009153983623176
[nix-lang]: https://nixos.org/manual/nix/stable/language/index.html "Nix, the language"
[nix-tool]: https://nixos.org/manual/nix/stable/introduction.html "Nix, the package manager"
[nixpkgs]: https://github.com/NixOS/nixpkgs
[ChatGPT]: https://chat.openai.com/chat
[nix-install]: https://nixos.org/manual/nix/stable/installation/multi-user.html
[nix-web]: https://nixos.org/
[nix.dev]: https://nix.dev/
[learn section]: https://nixos.org/learn.html
[nix-flakes]: https://www.tweag.io/blog/2020-05-25-flakes/ "Nix Flakes, Part 1: An introduction and tutorial"
[declarative and reproducible developer environments]: https://web.archive.org/web/2022/https://nixos.org/guides/declarative-and-reproducible-developer-environments.html
[terraform]: https://www.terraform.io/
[hcl language]: https://developer.hashicorp.com/terraform/language/modules
[large set of providers]: https://registry.terraform.io/browse/providers
[scaleway provider]: https://registry.terraform.io/providers/scaleway/scaleway/latest/docs
[puppet language]: https://puppet.com/docs/puppet/7/puppet_language.html
[hetzner cloud provider]: https://registry.terraform.io/providers/hetznercloud/hcloud/latest/docs
[dns.ts]: https://github.com/vincentbernat/cdktf-take1/blob/main/luffy/dns.ts
[cdktf-take1]: https://github.com/vincentbernat/cdktf-take1
[brotli compression module]: https://github.com/google/ngx_brotli
[ip address anonymizer module]: https://github.com/masonicboom/ipscrub
[performance regressions]: https://github.com/openssl/openssl/issues/17627#issuecomment-1060123659
[dos-nginx]: https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-002.md
[isso]: [[en/blog/2020-docker-nixos-isso.html]] "Running Isso on NixOS in a Docker container"
[web.nix]: https://github.com/vincentbernat/nixops-take1/blob/master/tags/web.nix
[common.nix]: https://github.com/vincentbernat/nixops-take1/blob/master/tags/common.nix
[isso.nix]: https://github.com/vincentbernat/nixops-take1/blob/master/tags/isso.nix
[deploy-rs]: https://github.com/serokell/deploy-rs "simple multi-profile Nix flake deploy tool"
[morph]: https://github.com/DBCDK/morph/ "NixOS deployment tool"
[colmena]: https://github.com/zhaofengli/colmena "Simple, stateless NixOS deployment tool"
[akvorado]: [[en/blog/2022-akvorado-flow-collector.html]] "Akvorado: a flow collector, enricher, and visualizer"
[snimpy]: [[en/blog/2013-snimpy.html]] "Snimpy: SNMP & Python"
[cdktf-take1-flake.nix]: https://github.com/vincentbernat/cdktf-take1/blob/main/flake.nix
[cdktf-take1-package.json]: https://github.com/vincentbernat/cdktf-take1/blob/main/package.json
[cdktf-take1-yarn.lock]: https://github.com/vincentbernat/cdktf-take1/blob/main/yarn.lock
[cdktf-take1-envrc]: https://github.com/vincentbernat/cdktf-take1/blob/main/.envrc
[yarn]: https://yarnpkg.com/ "Yarn package manager"
[pass]: https://www.passwordstore.org/ "The standard Unix password manager"
[direnv]: https://github.com/direnv/direnv/ "direnv: unclutter your .profile"
[lsp-mode]: https://github.com/emacs-lsp/lsp-mode/ "Language Server Protocol Support for Emacs"
[nixops-take1]: https://github.com/vincentbernat/nixops-take1
[nixops-take1-flake.nix]: https://github.com/vincentbernat/nixops-take1/blob/master/flake.nix
[nixops-take1-network.nix]: https://github.com/vincentbernat/nixops-take1/blob/master/network.nix
[libsmi]: https://www.ibr.cs.tu-bs.de/projects/libsmi/ "libsmi: library to Access SMI MIB Information"
[flakes]: https://nixos.wiki/wiki/Flakes "Flakes on NixOS wiki"
[cdktf-take1-cdktf.json]: https://github.com/vincentbernat/nixops-take1/blob/master/cdktf.json
[disable the server]: https://github.com/vincentbernat/cdktf-take1/commit/606e6fb657179408b163664dd74ff5ab38b28246
[vultr]: https://www.vultr.com/ "Vultr.com: SSD VPS Servers, Cloud Servers and Cloud Hosting"
[nomad]: https://www.nomadproject.io/ "Nomad: Orchestration Made Easy"
[broken]: https://github.com/nix-community/poetry2nix/issues/750 "Issue #750: infinite recursion"
[dnscontrol]: https://stackexchange.github.io/dnscontrol/ "DNSControl: Synchronize your DNS to multiple providers from a simple DSL"
[switched to the business source license]: https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license
[opentofu]: https://opentofu.org/ "The open source infrastructure as code tool"