Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
Website
Manage
Activity
Members
Labels
Plan
Issues
4
Issue boards
Milestones
Code
Merge requests
0
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Model registry
Monitor
Service Desk
Analyze
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Terms and privacy
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
ACIDES
Website
Commits
3be4abbf
Commit
3be4abbf
authored
4 years ago
by
Angedestenebres
😺
Browse files
Options
Downloads
Plain Diff
Merge branch 'spellcheck' into 'master'
Spellcheck See merge request
!1
parents
f06d9434
2d7733e1
No related branches found
Branches containing commit
No related tags found
1 merge request
!1
Spellcheck
Pipeline
#2604
passed with stages
Stage: pages
Stage: deploy
in 18 seconds
Changes
2
Pipelines
1
Hide whitespace changes
Inline
Side-by-side
Showing
2 changed files
content/docs/hepto/_index.md
+5
-5
5 additions, 5 deletions
content/docs/hepto/_index.md
content/docs/hepto/architecture.md
+26
-26
26 additions, 26 deletions
content/docs/hepto/architecture.md
with
31 additions
and
31 deletions
content/docs/hepto/_index.md
+
5
−
5
View file @
3be4abbf
...
...
@@ -8,7 +8,7 @@ L'hébergement de services et de données sur Internet est aujourd'hui très
centralisé, ce qui est néfaste à plusieurs titres :
-
pour la sécurité, l'appât du gain étant d'autant plus grand que les
victimes potentielles sont nombreu
x
, et les principales plateformes
victimes potentielles sont nombreu
ses
, et les principales plateformes
n'ayant que peu d'intérêt à protéger les individus ;
-
pour la vie privée, l'accumulation de données rendant leur exploitation
lucrative, tant pour la commercialisation de services de ciblage que pour
...
...
@@ -30,7 +30,7 @@ ou bien les héberger à leur domicile, au détriment de la disponibilité,
principalement en raison des aléas électriques et de l'accès à Internet.
hepto vise à faciliter l'hébergement au domicile, en permettant à plusieurs
individus ou structure, domiciliés séparément mais disposant de connexions à
individus ou structure
s
, domiciliés séparément mais disposant de connexions à
Internet de qualité, de mettre en commun leurs ressources pour construire et
exploiter un
*cluster*
d'hébergement résilient.
...
...
@@ -46,7 +46,7 @@ Les *clusters* résultants sont :
composants, peut être hébergé pour parties en différents endroits ;
-
résilients, c'est à dire qu'un service peut reposer sur un composant
déployé simultanément en plusieurs endroits et gérer automatiquement
la réponse à incident ;
la réponse à
un
incident ;
-
économes en ressources, c'est à dire que les équipements requis pour
héberger un cluster coûtent peu, consomment peu, et que les
communications à travers Internet sont limitées lorsque possibles afin
...
...
@@ -78,7 +78,7 @@ Le projet hepto était initialement nommé « hosto » (en référence simple à
*host*
) ; il a ainsi débuté en juin 2019, regroupant principalement des
volontaires des deux associations CryptOn et TeDomum.
En se
m
ptembre 2019, les premières orientations architecturales étaient fixées
En septembre 2019, les premières orientations architecturales étaient fixées
et les premiers choix technologiques ont penché du côté de Wireguard et
de Kubernetes pour débuter un laboratoire. Le laboratoire a été assemblé
à base de matériel récupéré et installé jusqu'en décembre 2019.
...
...
@@ -90,4 +90,4 @@ version exploitable a ainsi vu le jour en mai 2020.
Il reste aujourd'hui de nombreux aspects à améliorer dans les configurations
proposées, mais hepto fournit un socle réutilisable pour déployer des
*clusters*
de petits hébergeurs. Il compte 5 contributeurs actifs.
\ No newline at end of file
*clusters*
de petits hébergeurs. Il compte 5 contributeurs actifs.
This diff is collapsed.
Click to expand it.
content/docs/hepto/architecture.md
+
26
−
26
View file @
3be4abbf
...
...
@@ -9,14 +9,14 @@ title: Architecture
Un
*cluster*
hepto est constitué :
-
d'hôtes physiques, possédés par les contributeurs au
*cluster*
;
-
de n
oe
uds du cluster, chaque n
oe
ud étant instancié sur un hôte physique ;
-
d'une surcouche réseau, regroupant ces n
oe
uds sur un même réseau privé
-
de n
œ
uds du cluster, chaque n
œ
ud étant instancié sur un hôte physique ;
-
d'une surcouche réseau, regroupant ces n
œ
uds sur un même réseau privé
virtuel (VPN) sécurisant les communications à suivre ;
-
d'une surcouche orchestration, exploitant le CPU, la RAM et le stockage
des n
oe
uds pour y déployer des applications et rendre des services ;
des n
œ
uds pour y déployer des applications et rendre des services ;
-
d'une surcouche de contribution, permettant le travail collaboratif sur
les ressources du
*cluster*
, l'historisation des modifications, le
déploiement cont
r
inu, etc. ;
déploiement continu, etc. ;
-
d'outils pré-déployés, tels que les
*reverse proxy*
d'accès aux services,
la gestion des certificats TLS, la supervision des ressources, la
collecte et le traitement des journaux, etc.
...
...
@@ -25,14 +25,14 @@ Il est distribué, c'est à dire que les ressources sont mises à disposition
par des individus collaborant, mais pas nécessairement appartenant à la même
association, entreprise, collectif, etc. Chaque contributeur peut par exemple
disposer d'un hôte à son domicile, et décider de l'allouer pour partie à un
n
oe
ud d'un premier
*cluster*
, pour partie à un n
oe
ud d'un autre
*cluster*
, et
n
œ
ud d'un premier
*cluster*
, pour partie à un n
œ
ud d'un autre
*cluster*
, et
d'en conserver la maîtrise pour stocker ses documents personnels.
Il est résilient, c'est à dire qu'une application déployée et ses données ne
sont pas gérées sur le n
oe
ud d'un unique contributeur. En cas de panne de
sont pas gérées sur le n
œ
ud d'un unique contributeur. En cas de panne de
courant, d'accès à Internet, de déménagement, ou simplement si le contributeur
décide subitement de déconnecter son n
oe
ud, le
*cluster*
continue d'exister
et les applications continuent de fonct
o
inner sur les autres n
oe
uds.
décide subitement de déconnecter son n
œ
ud, le
*cluster*
continue d'exister
et les applications continuent de foncti
o
nner sur les autres n
œ
uds.
Il est économe, c'est à dire qu'il peut reposer sur des machines à faible
consommation, et que la somme des ressources peut approcher la somme des
...
...
@@ -48,17 +48,17 @@ personnel de récupération ou d'un micro-serveur. Il peut être utilisé pour
contribuer à un ou plusieurs
*clusters*
hepto, voire servir en parallèle
d'autres applications de son propriétaire.
Un n
oe
ud matérialise l'allocation de tout ou partie des ressources de
l'hôte sur lequel il repose au profit d'un
*cluster*
hepto. Un n
oe
ud est
Un n
œ
ud matérialise l'allocation de tout ou partie des ressources de
l'hôte sur lequel il repose au profit d'un
*cluster*
hepto. Un n
œ
ud est
concrètement constitué de deux programmes : la contribution à la surcouche
réseau et la contribution à la surcouche orchestration.
Le
*cluster*
hepto est réalisé par l'ensemble des n
oe
uds qui le constituent,
Le
*cluster*
hepto est réalisé par l'ensemble des n
œ
uds qui le constituent,
il fournit les primitives réseau et d'orchestration aux applications qui
y sont hébergées.
Dans le contexte de hepto, un
*pod*
peut techniquement faire référence à
un
*pod*
Podman, technologie employée pour gérer les n
oe
uds, ou bien un
un
*pod*
Podman, technologie employée pour gérer les n
œ
uds, ou bien un
*pod*
kubernetes, technologie employée pour la couche d'orchestration.
Sauf précision, il s'agit d'un
*pod*
au sens kubernetes.
...
...
@@ -73,10 +73,10 @@ laboratoires hepto. Elles sont susceptibles d'évoluer régulièrement :
-
les hôtes sont limités aux machines de l'architecture AMD64, avec
au minimum 1Go de mémoire vive et 50Go de stockage ;
-
les n
oe
uds sont constitués par des
*pods*
Podman, eux-mêmes
-
les n
œ
uds sont constitués par des
*pods*
Podman, eux-mêmes
organisés en deux conteneurs, l'un pour la surcouche réseau, l'autre
pour la surcouche orchestration ;
-
la surcouche réseau est opérée par wesher, qui négocie et conigure des
-
la surcouche réseau est opérée par wesher, qui négocie et con
f
igure des
VPN Wireguard en
*full-mesh*
entre tous les membres du cluster ;
-
la surcouche orchestration est opérée par k3s, une version allégée
de l'orchestration de conteneur kubernetes ;
...
...
@@ -92,18 +92,18 @@ d'administration du *cluster* au niveau de la surcouche d'orchestration
et dispose de l'ensemble des clés de sécurité du
*cluster*
, y compris
celles protégeant la surcouche réseau.
Un n
oe
ud hepto fait partie du
*cluster*
, et est donc sous la
Un n
œ
ud hepto fait partie du
*cluster*
, et est donc sous la
responsabilité du responsable du
*cluster*
, de même que l'ensemble des
ressources qui y sont orchestrées, sauf délégation.
Un hôte abritant un n
oe
ud hepto est sous la responsab
le
du propriétaire
de l'équipement. Il peut s'agi
t
de la même entité que le responsable du
*cluster*
, mais il peut également s'agi
t
d'un individu ou d'un groupement
Un hôte abritant un n
œ
ud hepto est sous la responsab
ilité
du propriétaire
de l'équipement. Il peut s'agi
r
de la même entité que le responsable du
*cluster*
, mais il peut également s'agi
r
d'un individu ou d'un groupement
tiers. Par exemple, des associations peuvent mettre à disposition chacune
des hôtes pour héberger les n
oe
uds d'un
*cluster*
hepto géré en fédération
des hôtes pour héberger les n
œ
uds d'un
*cluster*
hepto géré en fédération
d'associations ; ou bien une association gérer un
*cluster*
hepto reposant
pour une part sur des n
oe
uds hébergés sur ses propres hôtes et sur des
n
oe
uds contribués par ses membes mais dont l'association n'est pas
pour une part sur des n
œ
uds hébergés sur ses propres hôtes et sur des
n
œ
uds contribués par ses membes mais dont l'association n'est pas
propriétaire.
Au sein d'un
*cluster*
hepto, le responsable du
*cluster*
peut décider
...
...
@@ -142,7 +142,7 @@ Aussi, il apparaît que les deux types de ressources doivent être gérés par
deux technologies distinctes bien que complémentaires. En résultent deux
approches envisageables :
-
soit disposer d'une connectivité réseau sécurisée entre les n
oe
uds du
-
soit disposer d'une connectivité réseau sécurisée entre les n
œ
uds du
cluster, sur la base de laquelle l'orchestration est construite ;
-
soit construire une orchestration indépendamment des propriétés de
sécurité réseau et déployer en sus les outils pour sécuriser les
...
...
@@ -184,15 +184,15 @@ pour hepto est repoussée.
#### VPN et mesh
Pour qu'une surcouche réseau à base de VPN soit efficace, il faut que le
trafic circule entre les n
oe
uds sans transiter par un n
oe
ud central. Il faut
également que tous les n
oe
uds puissent échanger avec tous les autres n
oe
uds,
trafic circule entre les n
œ
uds sans transiter par un n
œ
ud central. Il faut
également que tous les n
œ
uds puissent échanger avec tous les autres n
œ
uds,
et que chacun puisse disposer d'un espace d'adressage complet pour les
applications hébergées.
Une telle infrastructure, dénommée
*VPN full-mesh*
, n'est pas triviale à
mettre en place. C'est en reprenant et en étendant un logiciel existant,
« wesher », que hepto parvient à gérer un
*VPN full-mesh*
entre l'ensemble
des n
oe
uds garantissant la confidentialité et l'intégrité du trafic échangé,
des n
œ
uds garantissant la confidentialité et l'intégrité du trafic échangé,
et servant de base à la surcouche orchestration.
### Machines virtuelles, conteneurs, processus
...
...
@@ -205,4 +205,4 @@ TODO
### Optimisations topologiques
TODO
\ No newline at end of file
TODO
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment