initial commit
added previous posts source files
This commit is contained in:
shobu
parent
00078e57aa
commit
aa7fec3b1b
BIN
shoblog/nginx/cover.jpg
Normal file
BIN
shoblog/nginx/cover.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 743 KiB |
167
shoblog/nginx/nginx.md
Normal file
167
shoblog/nginx/nginx.md
Normal file
@ -0,0 +1,167 @@
|
|||||||
|
---
|
||||||
|
options:
|
||||||
|
command_prefix: "pr:"
|
||||||
|
theme:
|
||||||
|
name: tokyonight-storm
|
||||||
|
override:
|
||||||
|
default:
|
||||||
|
# colors:
|
||||||
|
# foreground: "4c4f69"
|
||||||
|
# background: "ffffff"
|
||||||
|
code:
|
||||||
|
alignment: center
|
||||||
|
palette:
|
||||||
|
colors:
|
||||||
|
base00: "24283B"
|
||||||
|
base01: "16161E"
|
||||||
|
base02: "343A52"
|
||||||
|
base03: "444B6A"
|
||||||
|
base04: "787C99"
|
||||||
|
base05: "A9B1D6"
|
||||||
|
base06: "CBCCD1"
|
||||||
|
base07: "D5D6DB"
|
||||||
|
base08: "C0CAF5"
|
||||||
|
base09: "A9B1D6"
|
||||||
|
base0A: "0DB9D7"
|
||||||
|
base0B: "9ECE6A"
|
||||||
|
base0C: "B4F9F8"
|
||||||
|
base0D: "2AC3DE"
|
||||||
|
base0E: "BB9AF7"
|
||||||
|
base0F: "F7768E"
|
||||||
|
---
|
||||||
|
<!-- LTeX: language=fr -->
|
||||||
|
static websites with nginx
|
||||||
|
===
|
||||||
|
```file +line_numbers {1-20}
|
||||||
|
path: nginx.nix
|
||||||
|
language: nix
|
||||||
|
```
|
||||||
|
On se retrouve pour la suite de notre introduction à **nix** et **nixos**,
|
||||||
|
j'essaye un nouveau format ainsi que de rajouter un glossaire à la fin, aujourd'hui
|
||||||
|
on parle de la partie serveur et déploiement avec nginx, alors comme ont dis au States:
|
||||||
|
buckle up bookaroo.
|
||||||
|
# album du jour
|
||||||
|
## once in a long long while - low roar
|
||||||
|
|
||||||
|
<!-- pr:end_slide -->
|
||||||
|
introduction
|
||||||
|
===
|
||||||
|
```file +line_numbers {1-20}
|
||||||
|
path: nginx.nix
|
||||||
|
language: nix
|
||||||
|
```
|
||||||
|
Sous **nixos**, il est possible de définir la configuration réseau du système
|
||||||
|
de façon déclarative, ainsi que des services, qui sont généralement des daemons
|
||||||
|
que l'on peut configurer via nix.
|
||||||
|
Sous le capot, cette configuration va être
|
||||||
|
interprétée par **nix** en des options de plus en plus bas niveau, jusqu'à générer
|
||||||
|
les commandes **bash** et les **fichiers de configurations** nécessaires à l'application
|
||||||
|
de la configuration demandée.
|
||||||
|
Ainsi, ultimement, cette configuration va nous générer un fichier de configuration
|
||||||
|
**nginx** correspondant à notre virtualhost, ainsi que les commandes nécessaires
|
||||||
|
pour lancer nginx (et l'installer évidemment)
|
||||||
|
|
||||||
|
|
||||||
|
<!-- pr:end_slide -->
|
||||||
|
Paramètres généraux
|
||||||
|
===
|
||||||
|
```file +line_numbers {1, 16-19}
|
||||||
|
path: nginx.nix
|
||||||
|
language: nix
|
||||||
|
```
|
||||||
|
Sous nixos, la configuration du système est composée de modules, chaque module
|
||||||
|
est une fonction prenant un certain nombre de paramètres et retournant un set
|
||||||
|
d'options décrivant la configuration de notre système.
|
||||||
|
Au moment de builder cette dernière, tous les modules sont fusionnés afin de donner
|
||||||
|
la configuration finale à appliquer, puis cette dernière est interprétée par nix.
|
||||||
|
```nix +line_numbers
|
||||||
|
{inputs, ...}: {
|
||||||
|
# ...
|
||||||
|
}
|
||||||
|
```
|
||||||
|
On commence notre module en définissant les arguments d'entrée de ce dernier,
|
||||||
|
les `...` agissent comme une wildcard, nous autorisant à fournir plus d'argument
|
||||||
|
d'entrée dans l'appel de la fonction que ce que cette dernière ne vas actuellement
|
||||||
|
utiliser. Ce pattern permet à nix de laisser au module la liberté de déclarer
|
||||||
|
uniquement les dépendances dont il a besoin.
|
||||||
|
Ici, on déclare un argument `inputs`
|
||||||
|
dont la déclaration est en dehors du scope de cet article, mais qui contient les
|
||||||
|
dépendances de notre configuration, incluant le site packager dans l'article
|
||||||
|
précédent.
|
||||||
|
```nix +line_numbers
|
||||||
|
security.acme = {
|
||||||
|
acceptTerms = true;
|
||||||
|
defaults.email = "lelu.awen@proton.me";
|
||||||
|
};
|
||||||
|
```
|
||||||
|
l'option `services.nginx` de nixos permet d'automatiquement manager l'obtention
|
||||||
|
et le renouvellement des **certificats ssl**, par défaut, **let's encrypt** est utilisé,
|
||||||
|
mais n'importe quel CA peut être utiliser pourvu qu'il supporte le protocole
|
||||||
|
ACME. Afin d'utiliser ce service, il est nécessaire d'en accepter les conditions
|
||||||
|
d'utilisations ainsi que de fournir un email.
|
||||||
|
<!-- pr:end_slide -->
|
||||||
|
Paramètres de Nginx
|
||||||
|
===
|
||||||
|
```file +line_numbers {2-6, 15}
|
||||||
|
path: nginx.nix
|
||||||
|
language: nix
|
||||||
|
```
|
||||||
|
Par défaut, nginx va écouter sur les ports 80 (pour les requètes http) et 443
|
||||||
|
(pour SSL), on dit donc au firewall d'ouvrir les ports correspondants.
|
||||||
|
On active ensuite le service Nginx de nixos, qui vas se charger d'installer la
|
||||||
|
dernière version et de créer les units systemctl nécessaire à son fonctionnement.
|
||||||
|
Ce service propose un bon paquet d'options, mais on va ici voir uniquement la base.
|
||||||
|
Les options `recommendedTlsSettings` et `recommendedProxySettings` vont automatiquement
|
||||||
|
ajouter un set de paramètre à la conf générée de chaque virtualhost, à moins que
|
||||||
|
cette option ne soit set à la négative au niveau du dit host.
|
||||||
|
<!-- pr:end_slide -->
|
||||||
|
Paramètres du virtualhost
|
||||||
|
===
|
||||||
|
```file +line_numbers {7-14}
|
||||||
|
path: nginx.nix
|
||||||
|
language: nix
|
||||||
|
```
|
||||||
|
Et voici l'option qui nous intéresse ici, cette option est un genre de dictionnaire,
|
||||||
|
chaque clé correspond à un nom de domaine sur lequel notre virtualhost sera mapper,
|
||||||
|
et la configuration propre à ce dernier. Voyons ça en détail:
|
||||||
|
<!-- pr:newline -->
|
||||||
|
`enableACME` dit à nixos que l'on souhaite utiliser le module ACME pour ce virtualHost,
|
||||||
|
en utilisant ce dernier, il vas aller demander un certificat à let's encrypt qui
|
||||||
|
correspond au domaine de notre vhost, et renouveler ce dernier régulièrement avant
|
||||||
|
chaque expiration. De plus, il va aussi ajouter la configuration néscéssaire pour
|
||||||
|
que notre vhost prenne en charge les requêtes HTTPS.
|
||||||
|
<!-- pr:newline -->
|
||||||
|
`forceSSL` force notre vhost à rediriger les requêtes http vers le https.
|
||||||
|
<!-- pr:newline -->
|
||||||
|
`root` définis le dossier que notre serveur va servir, et si ce dernier contient
|
||||||
|
un fichier `index.html`, c'est ce fichier qui va être servis par défaut. L'astuce
|
||||||
|
ici est d'utiliser directement le paquet composé de notre site packager précédement,
|
||||||
|
après avoir pris soins d'ajouter celui-ci aux inputs de notre configuration, il se
|
||||||
|
retrouve accessible via l'argument `input.<nom du paquet>.packages.<architecture>.default`.
|
||||||
|
Au moment de l'interprétation du fichier par nix, cette variable va interpoler
|
||||||
|
avec le chemin du paquet dans le nix store (un truc du genre /nix/store/zf9kgk4fkrpjl21i26bmpbsn7q01x6lm-shoblog-front),
|
||||||
|
qui contient tout nos assets statiques.
|
||||||
|
|
||||||
|
Et voilà ! Un petit `nixos-rebuild switch` et le système lire notre config, télécharger
|
||||||
|
les paquets manquants, builder notre site, copier les assets dans le store, créer
|
||||||
|
notre virtualhost et demander les certificats. Et le plus beau c'est que si l'on
|
||||||
|
met à jour notre application, il nous suffit juste de pousser les modifications
|
||||||
|
sur notre repo et de dire à nix de checker si il y a eu des mises à jour dans ses
|
||||||
|
inputs et ce dernier vas checker le repo pour des nouveaux comits sur la branche
|
||||||
|
qu'il surveille et, le cas avenant, pull la nouvelle version, la build, et relancer
|
||||||
|
les services correspondant comme un grand.
|
||||||
|
<!-- pr:end_slide -->
|
||||||
|
Glossaire
|
||||||
|
===
|
||||||
|
nixos: distribution linux à la configuration déclarative basée sur le package mnager **nix**
|
||||||
|
nix: package manager servant à définir des environnements logiciels de manière
|
||||||
|
déclarative et reproductible
|
||||||
|
daemon: logiciel fonctionnement en arrière-plan, de façon transparente à l'utilisateur.
|
||||||
|
bash: interpréteur de commande pour les OS de type UNIX permettant d'interagir
|
||||||
|
directement avec ce dernier.
|
||||||
|
nginx: serveur web et reverse proxy assez commun et open source.
|
||||||
|
virtualhost: dans le contexte de nginx, ensemble de la configuration associée à un
|
||||||
|
domaine.
|
||||||
|
certificat ssl: fichier attestant de l'identité d'un domaine.
|
||||||
|
**C**ertificat **A**uthority: Organisation fournissant des certificats aux propriétaires
|
||||||
|
d'un domaine et servant de garantie à la validité de ces derniers.
|
||||||
20
shoblog/nginx/nginx.nix
Normal file
20
shoblog/nginx/nginx.nix
Normal file
@ -0,0 +1,20 @@
|
|||||||
|
{inputs, ...}: {
|
||||||
|
networking.firewall.allowedTCPPorts = [ 80 443 ];
|
||||||
|
services.nginx = {
|
||||||
|
enable = true;
|
||||||
|
recommendedProxySettings = true;
|
||||||
|
recommendedTlsSettings = true;
|
||||||
|
virtualHosts = {
|
||||||
|
"shobu.fr" = {
|
||||||
|
enableACME = true;
|
||||||
|
forceSSL = true;
|
||||||
|
|
||||||
|
root = "${inputs.shoblog-front.packages.x86_64-linux.default}/dist";
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
||||||
|
security.acme = {
|
||||||
|
acceptTerms = true;
|
||||||
|
defaults.email = "lelu.awen@proton.me";
|
||||||
|
};
|
||||||
|
}
|
||||||
BIN
shoblog/nginx/nix_nginx.png
Normal file
BIN
shoblog/nginx/nix_nginx.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 112 KiB |
BIN
shoblog/nginx/terminal-ls.png
Normal file
BIN
shoblog/nginx/terminal-ls.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 85 KiB |
47
shoblog/vuejs/shoblog_code.nix
Normal file
47
shoblog/vuejs/shoblog_code.nix
Normal file
@ -0,0 +1,47 @@
|
|||||||
|
{
|
||||||
|
description = "developpement and deployment flake for shoblog";
|
||||||
|
|
||||||
|
inputs.nixpkgs.url = "github:nixos/nixpkgs/nixos-25.05";
|
||||||
|
|
||||||
|
outputs = { self, nixpkgs }:
|
||||||
|
let
|
||||||
|
supportedSystems = [ "x86_64-linux" "aarch64-linux" "x86_64-darwin" "aarch64-darwin" ];
|
||||||
|
forEachSupportedSystem = f: nixpkgs.lib.genAttrs supportedSystems (system: f {
|
||||||
|
pkgs = import nixpkgs { inherit system; config.allowUnfree = true; };
|
||||||
|
});
|
||||||
|
in
|
||||||
|
{
|
||||||
|
devShells = forEachSupportedSystem ({ pkgs }: {
|
||||||
|
default = pkgs.mkShell {
|
||||||
|
packages = with pkgs; [ nodejs yarn jetbrains.webstorm yarn2nix ];
|
||||||
|
};
|
||||||
|
});
|
||||||
|
|
||||||
|
packages = forEachSupportedSystem ({ pkgs }: {
|
||||||
|
default = pkgs.mkYarnPackage {
|
||||||
|
name = "shoblog-front";
|
||||||
|
src = ./.;
|
||||||
|
|
||||||
|
packageJSON = ./package.json;
|
||||||
|
yarnLock = ./yarn.lock;
|
||||||
|
yarnNix = ./yarn.nix;
|
||||||
|
|
||||||
|
buildPhase = ''
|
||||||
|
runHook preBuild;
|
||||||
|
mkdir $TEMPDIR/dist
|
||||||
|
yarn run build --outDir $TEMPDIR/dist;
|
||||||
|
runHook postBuild;
|
||||||
|
'';
|
||||||
|
|
||||||
|
installPhase = ''
|
||||||
|
runHook preInstall
|
||||||
|
mkdir -p $out/
|
||||||
|
cp -r $TEMPDIR/dist/ $out/
|
||||||
|
runHook postInstall
|
||||||
|
'';
|
||||||
|
|
||||||
|
distPhase = ''true'';
|
||||||
|
};
|
||||||
|
});
|
||||||
|
};
|
||||||
|
}
|
||||||
172
shoblog/vuejs/vue.md
Normal file
172
shoblog/vuejs/vue.md
Normal file
@ -0,0 +1,172 @@
|
|||||||
|
---
|
||||||
|
options:
|
||||||
|
command_prefix: "pr:"
|
||||||
|
theme:
|
||||||
|
name: tokyonight-storm
|
||||||
|
override:
|
||||||
|
default:
|
||||||
|
# colors:
|
||||||
|
# foreground: "4c4f69"
|
||||||
|
# background: "ffffff"
|
||||||
|
palette:
|
||||||
|
colors:
|
||||||
|
base00: "24283B"
|
||||||
|
base01: "16161E"
|
||||||
|
base02: "343A52"
|
||||||
|
base03: "444B6A"
|
||||||
|
base04: "787C99"
|
||||||
|
base05: "A9B1D6"
|
||||||
|
base06: "CBCCD1"
|
||||||
|
base07: "D5D6DB"
|
||||||
|
base08: "C0CAF5"
|
||||||
|
base09: "A9B1D6"
|
||||||
|
base0A: "0DB9D7"
|
||||||
|
base0B: "9ECE6A"
|
||||||
|
base0C: "B4F9F8"
|
||||||
|
base0D: "2AC3DE"
|
||||||
|
base0E: "BB9AF7"
|
||||||
|
base0F: "F7768E"
|
||||||
|
---
|
||||||
|
<!-- LTeX: language=fr -->
|
||||||
|
<!-- pr:column_layout: [1,2] -->
|
||||||
|
<!-- pr:column: 0 -->
|
||||||
|
# Définition des environnements de développement du package
|
||||||
|
* on défini un seul
|
||||||
|
environnement (**default**)
|
||||||
|
* la fonction <span style="color: p:base0F">**forEachSupportedSystem**</span> à pour
|
||||||
|
fonction de générer un élément pour chaque architecture supportée par le package
|
||||||
|
* ces architectures sont définie à la ligne 8 et correspondent aux architectures
|
||||||
|
supportée par nix.
|
||||||
|
* Dans cet environnement, on fournis les packages suivants
|
||||||
|
* **nodejs**
|
||||||
|
c'est un projet vue.js, donc faut bien un runtime
|
||||||
|
* **yarn**
|
||||||
|
ici on préfèrera yarn pour pouvoir utiliser yarn2nix afin de générer les
|
||||||
|
dépendances.
|
||||||
|
* webstorm
|
||||||
|
* je l'installe que pour ce projet, donc ça me permet de le garbage collecter
|
||||||
|
quand j'en ai pas besoin (merci nix)
|
||||||
|
* **yarn2nix**
|
||||||
|
* yarn2nix est un outil qui vas lire notre fichier package.json et générer
|
||||||
|
un fichier yarn.nix avec toutes nos dépendances packager pour nix, pour des
|
||||||
|
question de reproductibilité, lors du build avec nix, les outils n'ont pas accès
|
||||||
|
à internet, il n'est donc pas possible de juste faire un "yarn add".
|
||||||
|
<!-- pr:column: 1 -->
|
||||||
|
```file +line_numbers {13-18}
|
||||||
|
path: shoblog_code.nix
|
||||||
|
language: nix
|
||||||
|
```
|
||||||
|
<!-- pr:end_slide -->
|
||||||
|
|
||||||
|
<!-- pr:column_layout: [1,2] -->
|
||||||
|
<!-- pr:column: 0 -->
|
||||||
|
# Définition des packages
|
||||||
|
|
||||||
|
* d'une manière similaire aux **devShells**, on vas ici générer un package par
|
||||||
|
architecture supportée. Lors du build (qui se fait généralement localement),
|
||||||
|
nix va néanmoins builder uniquement le package correspondant à l'architecture
|
||||||
|
de la machine.
|
||||||
|
* Pour ce faire, on utilise la fonction <span style="color: p:base0F">
|
||||||
|
**mkYarnPackage**</span> qui fournit diverses options pour générer un package
|
||||||
|
manager par **Yarn**
|
||||||
|
* **name**: assez explicite, le nom du package générer
|
||||||
|
* **src**: les source sur lequel la fonction va se baser pour générer le package
|
||||||
|
* **PackageJSON**: package.json
|
||||||
|
* **yarnLock**: yarn.lock
|
||||||
|
* <span style="color: p:base0F">**yarnNix**</span>: Ah ! C'est ici qu'on
|
||||||
|
retrouve notre fameux **yarn.nix**.
|
||||||
|
* En fait, lors du process de build et pour
|
||||||
|
pour des raisons de reproductibilité, les programmes n'ont pas accès à internet. Chez nix,
|
||||||
|
toutes les dépendances doivent être connue et regroupée à l'avance. Pour ce faire,
|
||||||
|
**yarn2nix** nous génère un fichier **yarn.nix** définissant sous forme de package
|
||||||
|
nix toutes les dépendances de notre projet, ainsi lors du build, nix vas toutes
|
||||||
|
les pull, donner le résultat à mkYarnPackage qui vas les installer dans son
|
||||||
|
environnement de build.
|
||||||
|
* Et pour finis, les phases de notre build. Par défaut, **mkYarnPackage** va
|
||||||
|
juste chercher à build un binaire basée sur la configuration de notre package.json,
|
||||||
|
dans notre cas
|
||||||
|
<!-- pr:column: 1 -->
|
||||||
|
```file +line_numbers {20-45}
|
||||||
|
path: shoblog_code.nix
|
||||||
|
language: nix
|
||||||
|
```
|
||||||
|
<!-- pr:end_slide -->
|
||||||
|
|
||||||
|
<!-- pr:column_layout: [1,2] -->
|
||||||
|
<!-- pr:column: 0 -->
|
||||||
|
## buildPhase
|
||||||
|
Le build d'un package sous nix est découpé en plusieurs phases, si la plupart
|
||||||
|
sont généralement transparente, celons le cas, certaines ont besoin d'être
|
||||||
|
override en fonction des besoins. Ici, l'on cherche à packager des assets statiques, donc:
|
||||||
|
* première étape, appeler `runhook preBuild`, rien à voir avec notre affaire, mais
|
||||||
|
cela permet à d'éventuel futur dev de venir surcharger notre package sans toucher
|
||||||
|
à notre buildphase, chaque phase à des pré et post hook de la même manière.
|
||||||
|
* `mkdir $TEMPDIR/dist`, on créer un dossier temporaire pour nos fichiers de build
|
||||||
|
* `yarn run build --outDir $TEMPDIR/dist`, on run notre script de build en précisant
|
||||||
|
notre dossier temporaire comme output
|
||||||
|
* et on run le hook de postBuild
|
||||||
|
|
||||||
|
<!-- pr:column: 1 -->
|
||||||
|
```file +line_numbers {29-34}
|
||||||
|
path: shoblog_code.nix
|
||||||
|
language: nix
|
||||||
|
```
|
||||||
|
<!-- pr:end_slide -->
|
||||||
|
|
||||||
|
<!-- pr:column_layout: [1,2] -->
|
||||||
|
<!-- pr:column: 0 -->
|
||||||
|
## installPhase
|
||||||
|
Cette phase a pour rôle de placer les fichiers résultant du build dans le store
|
||||||
|
de nix, je passe sur les hook qu'on à déjà vu précédemment
|
||||||
|
* `mkdir -p $out/`, **$out** est une variable spécifique à cette phase de build
|
||||||
|
qui pointe vers le dossier final attribué par nix pour notre package.
|
||||||
|
* `cp -r $TEMPDIR/dist/ $out/`, on copie les fichiers de notre build dans le
|
||||||
|
dossier ainsi créer et zou ! :3
|
||||||
|
|
||||||
|
<!-- pr:column: 1 -->
|
||||||
|
```file +line_numbers {36-41}
|
||||||
|
path: shoblog_code.nix
|
||||||
|
language: nix
|
||||||
|
```
|
||||||
|
|
||||||
|
<!-- pr:end_slide -->
|
||||||
|
## Résultat
|
||||||
|
Hop, un petit coup de `nix build` et sous vos yeux ébahis, nix nous pull toutes
|
||||||
|
nos dépendances, build notre projet et le place au chaud dans son store. \
|
||||||
|
Bon c'est vachement bien tout ça, mais pourquoi faire ?
|
||||||
|
On verra les avantages en détails dans d'autres articles (peut-être même dès demain ?
|
||||||
|
mystère mystère...) mais voici déjà quelques bullet points
|
||||||
|
* Reproductibilité
|
||||||
|
* Nix nous assure que, pour des entrées données, le résultat sera toujours le
|
||||||
|
même, ainsi, il nous est possible de pin un commit spécifique de nixpkgs pour
|
||||||
|
figer la release de notre paquet dans le temps. Contrairement à un package
|
||||||
|
manager plus classique (apt par exemple), lors du build de votre paquet, vous
|
||||||
|
serez ainsi assurer de toujours pull la même version de node tant que l'on
|
||||||
|
update pas le flake.lock du projet.
|
||||||
|
* Isolation
|
||||||
|
* Nix installe chaque dépendance dans un dossier appellé le **store**, chaque
|
||||||
|
dépendance étant installer dans un dossier au hash unique basé sur le nom du
|
||||||
|
package et sa version. Ce qui fait qu'il est parfaitement possible d'avoir
|
||||||
|
deux projets utilisant deux versions de node différentes sans aucun problème,
|
||||||
|
et ce sans avoir besoin de docker, d'environnement virtuel ou de faire mumuse
|
||||||
|
avec des liens symboliques. Bonus, si un autre projet nécessite la même version
|
||||||
|
de node, nix va simplement utiliser celle déjà installer, ce qui évite les
|
||||||
|
duplicatas.
|
||||||
|
* Tracking
|
||||||
|
* étant donné que toutes les dépendances de chaque package sont déclarées dans
|
||||||
|
le `flake.nix`, il suffit de lire ce dernier pour savoir quels paquets sont
|
||||||
|
nécessaires à son déploiement. De plus, si l'on enlève un paquet de l'environnement,
|
||||||
|
nix vas pouvoir checker si ses dépendances sont utiliser par d'autres paquets,
|
||||||
|
et dans la négative, les supprimer pour économiser la place.
|
||||||
|
* Configuration
|
||||||
|
* Un peu hors du scope de cet exemple, mais il est possible de définir une
|
||||||
|
fonction d'override pour un paquet afin de permettre à l'utilisateur final
|
||||||
|
de ce dernier de spécifier des paramètres à ce dernier au moment du build.
|
||||||
|
Que ce sois l'utilisation d'une version spécifique de node, ou une clé d'API
|
||||||
|
par exemple.
|
||||||
|
* en utilisant NixOS, il est possible de définir des **modules** que
|
||||||
|
l'utilisateur peut importer dans la configuration de son système afin de
|
||||||
|
déclarer des services, installer et configurer d'autres packages, configurer
|
||||||
|
des interfaces réseaux, ect... Cela peut permettre d'automatiser grandement
|
||||||
|
le déploiement de certains projets et de grandement organiser ses configurations
|
||||||
|
(comme avec la déclaration de virtualhost nginx par exemple, teasing teasing...)
|
||||||
Loading…
x
Reference in New Issue
Block a user