add automated French translation of new-website
This commit is contained in:
parent
bc76ed80bb
commit
6366eb8d5d
GPG Key ID:
DC9462335BDDAC6B
208
content/posts/new-website/index.fr.md
Normal file
208
content/posts/new-website/index.fr.md
Normal file
@ -0,0 +1,208 @@
|
|||||||
|
---
|
||||||
|
title: "Nouveau site web"
|
||||||
|
slug: "nouveau-site-web"
|
||||||
|
date: "2025-06-12T08:00:00-06:00"
|
||||||
|
description: "Il y a enfin un nouveau site web sur d-b.ca."
|
||||||
|
summary: "J'ai publié mon site web personnel. Un aperçu de certaines réalisations passées et quelques détails sur la technologie utilisée pour le nouveau site."
|
||||||
|
---
|
||||||
|
|
||||||
|
J'ai enfin publié un site web correct à [https://d-b.ca/](https://d-b.ca/).
|
||||||
|
La dernière fois que j'avais quelque chose en ligne sur ce domaine remontait à
|
||||||
|
plus de 20 ans, selon le [Wayback Machine](https://web.archive.org/). Pourquoi
|
||||||
|
si longtemps? La vérité est que mes intérêts ont évolué au fil des années, et
|
||||||
|
j'ai beaucoup appris. Ce site, bien qu'utile en lui-même, est en réalité le
|
||||||
|
fruit d'une plateforme personnelle que j'ai développée au fil du temps.
|
||||||
|
|
||||||
|
## Histoire
|
||||||
|
|
||||||
|
Mon premier site web personnel a été développé alors que j'étais étudiant à
|
||||||
|
l'[Université de l'Alberta](https://ualberta.ca), à la fin du siècle dernier.
|
||||||
|
Le web était encore à ses débuts, mais l'université permettait aux étudiants
|
||||||
|
de publier du contenu web. À l'époque, c'était surtout une nouveauté qui n'a
|
||||||
|
pas duré au-delà de mon temps à l'école, mais cela a éveillé mon intérêt pour
|
||||||
|
les technologies internet et leurs applications.
|
||||||
|
|
||||||
|
Ce site initial comprenait une fonction intéressante. J'ai développé un
|
||||||
|
mécanisme pour mettre à jour automatiquement une page chaque fois que je me
|
||||||
|
connectais à l'un des ordinateurs de l'école, afin que mes amis puissent me
|
||||||
|
trouver si nécessaire. À l'époque, les mises à jour dynamiques des sites web
|
||||||
|
étaient difficiles. La méthode la plus courante était d'utiliser des
|
||||||
|
[CGI](https://fr.wikipedia.org/wiki/Common_Gateway_Interface), qui consistait
|
||||||
|
à exécuter un petit programme chaque fois qu'une page était demandée.
|
||||||
|
L'université n'autorisait pas les sites étudiants à utiliser cela. J'ai donc
|
||||||
|
rédigé des scripts shell qui étaient appelés lors de mes scripts de connexion
|
||||||
|
et de déconnexion, générant ainsi un fichier HTML statique et le stockant dans
|
||||||
|
mon répertoire de contenu web. Il fallait gérer des cas comme des connexions
|
||||||
|
multiples, et le script de déconnexion ne s'exécutait pas toujours, donc je
|
||||||
|
devais surveiller les entrées obsolètes.
|
||||||
|
|
||||||
|
### Hébergement autonome
|
||||||
|
|
||||||
|
J'ai toujours été un grand fan de l'hébergement autonome. Apprendre en mettant
|
||||||
|
un système en marche fonctionne bien pour moi. J'apprécie aussi la
|
||||||
|
confidentialité et le contrôle qu'il offre. De plus, c'est bien plus
|
||||||
|
économique à long terme!
|
||||||
|
|
||||||
|
Cela a vraiment commencé lorsque je travaillais chez un fournisseur local
|
||||||
|
d'accès à Internet. J'ai obtenu un bon accord sur une connexion large bande à
|
||||||
|
la maison, qui comprenait un petit bloc réseau (`/28`, comprenant 16 adresses
|
||||||
|
IP) que je pouvais utiliser. J'ai dédié mon ordinateur le plus puissant comme
|
||||||
|
serveur et développé plusieurs services, notamment un nouveau site web.
|
||||||
|
|
||||||
|
À l'époque, mon site web n'était pas très élaboré et était principalement
|
||||||
|
orienté vers l'expérimentation. J'ai développé un système de gestion de
|
||||||
|
contenu simple à partir de zéro en PHP, que j'ai utilisé pour publier un blog.
|
||||||
|
Il s'intégrait également aux listes de diffusion, un domaine que j'explorais
|
||||||
|
à l'époque.
|
||||||
|
|
||||||
|
### D-B.CA
|
||||||
|
|
||||||
|
À l'époque, je n'avais pas encore enregistré de nom de domaine personnel, donc
|
||||||
|
tout se trouvait sous un domaine d'un ami. En fin d'année 2002, j'ai décidé
|
||||||
|
d'enregistrer le mien, principalement pour avoir une adresse e-mail stable.
|
||||||
|
J'ai voulu intégrer les initiales de mon nom, donc j'ai choisi `d-b.ca`.
|
||||||
|
C'était un compromis, car quelqu'un squattait `db.ca` à l'époque, et, à ma
|
||||||
|
connaissance, c'est toujours le cas.
|
||||||
|
|
||||||
|
Au début, j'ai principalement focalisé mon attention sur l'exploitation de mes
|
||||||
|
services de messagerie et d'autres expérimentations, sans trop me soucier de
|
||||||
|
mon site web. Il y avait quelques pages de test de temps en temps, mais rien
|
||||||
|
de substantiel.
|
||||||
|
|
||||||
|
## Technologie moderne
|
||||||
|
|
||||||
|
L'un des projets que je suis depuis un certain temps est
|
||||||
|
[Hugo](https://gohugo.io/). J'ai eu l'occasion de travailler avec divers
|
||||||
|
systèmes de gestion de contenu web, et ils ont souvent semblé encombrants et
|
||||||
|
poser des problèmes de sécurité. Hugo est un exemple de «générateur de sites
|
||||||
|
statiques». Imaginez-le comme suit: au lieu de créer des pages web en temps
|
||||||
|
réel chaque fois qu'une personne les visite, Hugo prend tout le contenu brut
|
||||||
|
et le transforme en un ensemble de fichiers prêts à être servis, de manière
|
||||||
|
similaire à la manière dont un compilateur transforme du code en un programme
|
||||||
|
exécutable. Les ressources statiques résultantes peuvent être servies comme
|
||||||
|
des fichiers réguliers depuis n'importe quel service web, sans avoir besoin de
|
||||||
|
générer dynamiquement du contenu à partir d'une base de données, comme le font
|
||||||
|
les systèmes de gestion de contenu traditionnels.
|
||||||
|
|
||||||
|
Utiliser Hugo est beaucoup plus simple avec un modèle de base solide. Il
|
||||||
|
existe de nombreux modèles à choisir ([voir ici](https://themes.gohugo.io/)),
|
||||||
|
notamment celui que j'ai choisi ici appelé
|
||||||
|
[«Blowfish»](https://blowfish.page/). J'aime l'aspect qu'il a, et il prend
|
||||||
|
bien en charge le style de site que je souhaite.
|
||||||
|
|
||||||
|
Un autre avantage d'un générateur de sites statiques est que l'ensemble des
|
||||||
|
sources du site peut être traité comme du code logiciel, ce qui rend simple
|
||||||
|
l'utilisation d'outils de développement comme [Git](https://git-scm.com/) pour
|
||||||
|
le contrôle de version. Je garde les sources de ce site dans un dépôt public
|
||||||
|
sur mon propre serveur Git. N'hésitez pas à jeter un œil:
|
||||||
|
|
||||||
|
{{< gitea repo="d-b.ca/web" >}}
|
||||||
|
|
||||||
|
### CI/CD
|
||||||
|
|
||||||
|
J'ai également configuré un pipeline CI/CD pour construire et déployer le site
|
||||||
|
chaque fois que des modifications sont apportées au dépôt source. Qu'est-ce
|
||||||
|
que cela signifie ?
|
||||||
|
|
||||||
|
**CI** = *Intégration continue*
|
||||||
|
> C'est la pratique d'intégrer fréquemment les modifications dans un dépôt
|
||||||
|
> source. Les modifications sont vérifiées, assemblées et empaquetées via des
|
||||||
|
> processus automatisés. [Plus d'informations](https://martinfowler.com/articles/continuousIntegration.html)
|
||||||
|
|
||||||
|
**CD** = *Livraison continue*
|
||||||
|
> C'est la capacité à pouvoir prendre de nouvelles modifications (comme les
|
||||||
|
> sorties du processus CI) et les déployer et les exécuter automatiquement.
|
||||||
|
> [Plus d'informations](https://continuousdelivery.com/)
|
||||||
|
|
||||||
|
La partie CI est déclenchée par un push vers le dépôt
|
||||||
|
[web](https://git.brds.ca/d-b.ca/web) . Il exécute un workflow automatisé qui
|
||||||
|
construit le site et empaquette les artefacts résultants dans une image
|
||||||
|
conteneur basée sur le serveur web [Caddy](https://caddyserver.com/).
|
||||||
|
|
||||||
|
Une image conteneur est comme un environnement logiciel préemballé qui assure
|
||||||
|
que le site web fonctionne de manière cohérente, quel que soit
|
||||||
|
l'infrastructure sous-jacente. L'image résultante contient tout ce dont le
|
||||||
|
site a besoin pour fonctionner et peut s'exécuter sur n'importe quelle
|
||||||
|
infrastructure capable de l'héberger, comme mon propre ordinateur portable ou
|
||||||
|
mon cluster de serveurs.
|
||||||
|
|
||||||
|
L'image conteneur utilisée avec Hugo est une autre image, uniquement utilisée
|
||||||
|
pour créer l'image conteneur du site web. Je la maintiens dans ce dépôt:
|
||||||
|
|
||||||
|
{{< gitea repo="d-b.ca/hugo-builder" >}}
|
||||||
|
|
||||||
|
Une fois que le workflow a construit l'image conteneur pour exécuter le site
|
||||||
|
web, il met à jour le dépôt GitOps de livraison continue pour déployer
|
||||||
|
immédiatement cette nouvelle version sur un site de prévisualisation privé.
|
||||||
|
Une autre définition:
|
||||||
|
|
||||||
|
> **GitOps** désigne la pratique de gérer l'automatisation de l'infrastructure
|
||||||
|
> en conservant des descriptions lisibles par machine de l'infrastructure
|
||||||
|
> souhaitée dans un dépôt Git contrôlé en version. Un système de livraison
|
||||||
|
> continue surveille le dépôt pour des changements, ajoutant, modifiant ou
|
||||||
|
> supprimant immédiatement l'infrastructure pour aligner l'état du système
|
||||||
|
> opérationnel sur la description source.
|
||||||
|
|
||||||
|
Il y a de nombreux avantages à gérer l'infrastructure de cette manière. Les
|
||||||
|
changements sont automatiquement traqués, car tout est stocké dans un système
|
||||||
|
de dépôt de code existant conçu spécifiquement pour gérer et suivre les
|
||||||
|
changements. Les changements problématiques peuvent être facilement annulés en
|
||||||
|
annulant le changement dans le dépôt. L'automatisation maintient les choses
|
||||||
|
synchronisées en permanence - tout changement effectué manuellement en dehors
|
||||||
|
de ce système est immédiatement détecté et supprimé.
|
||||||
|
|
||||||
|
Quand je veux publier cette nouvelle version en tant que site web de
|
||||||
|
production, j'utilise mon dépôt GitOps privé régulier pour mettre à jour le
|
||||||
|
tag de version de l'image, et le reste se fait automatiquement. Le dépôt
|
||||||
|
GitOps de livraison continue pour le site de prévisualisation est public, vous
|
||||||
|
êtes les bienvenus pour le consulter ici:
|
||||||
|
|
||||||
|
{{< gitea repo="d-b.ca/db-cd" >}}
|
||||||
|
|
||||||
|
#### Diagramme du pipeline
|
||||||
|
|
||||||
|
{{< mermaid >}}
|
||||||
|
flowchart TB
|
||||||
|
subgraph GIT [Dépôt GIT]
|
||||||
|
WR[(Web)]
|
||||||
|
CDR[(CD)]
|
||||||
|
end
|
||||||
|
|
||||||
|
WP(Envoyer les mises à jour du site web)-->WR
|
||||||
|
WP ~~~ HBI
|
||||||
|
|
||||||
|
subgraph CI [Workflow CI]
|
||||||
|
CIP[Récupérer le dépôt source]-->BWI[Construire l'image web]
|
||||||
|
BWI-->PWI[Envoyer l'image web]
|
||||||
|
PWI-->UCD[Mettre à jour le dépôt CD]
|
||||||
|
end
|
||||||
|
|
||||||
|
PWI-->WI
|
||||||
|
WR-->CIP
|
||||||
|
|
||||||
|
subgraph DOCKER [Dépôt d'images]
|
||||||
|
HBI((Hugo
|
||||||
|
Build))
|
||||||
|
WI((Web))
|
||||||
|
end
|
||||||
|
|
||||||
|
HBI-->BWI
|
||||||
|
|
||||||
|
UCD-->CDP(Envoyer la mise à jour de l'image)
|
||||||
|
CDP-->CDR
|
||||||
|
CDR-->CDPull
|
||||||
|
|
||||||
|
subgraph CD [Processus CD]
|
||||||
|
CDPull[Récupérer le dépôt source]-->DWI[Déployer l'image web]
|
||||||
|
end
|
||||||
|
|
||||||
|
WI-->DWI
|
||||||
|
{{< /mermaid >}}
|
||||||
|
|
||||||
|
## Plateforme sous-jacente
|
||||||
|
|
||||||
|
Dans des articles futurs, je décrirai l'évolution du réseau physique et des
|
||||||
|
systèmes sur lesquels ce site s'exécute, et comment ils m'ont permis de
|
||||||
|
construire un cluster [Kubernetes](https://kubernetes.io/) pour mettre à
|
||||||
|
l'échelle ce site et exécuter d'autres services, tout cela sur du matériel que
|
||||||
|
j'ai assemblé moi-même!
|
||||||
Loading…
x
Reference in New Issue
Block a user