Hébergement de site Web

Nous pouvons héberger pour vous de petits site Web (un blog, un CV en ligne, la page d’un évènement ou d’une association). Cependant, certaines considérations techniques rendent plus faciles l’hébergement de certains projets. Si ce qui suit est trop technique, contactez nous directement pour savoir exactement ce qui est faisable et les critères techniques du site que vous souhaitez héberger.

Aperçu des possibilités d’hébergement

En très résumé, nous pouvons héberger facilement un site Web statique (HTML/CSS/JS côté client). Pour le nom de domaine, aucune contrainte particulière, mais c’est à vous de le gérer et de configurer la zone DNS. Si vous le souhaitez, nous pouvons vous passer un sous-domaine en <votre choix>.knightsofnii.com.

Nous pouvons également héberger des pages statiques générées par des outils automatisés (Jenkins, Hugo, etc…). La procédure est détaillée plus bas, et implique l’utilisation de notre Gitlab et d’un pipeline CI/CD spécifique pour héberger tout ça.

Pour des sites dynamiques (PHP, JS, Ruby ou autre joyeuseté côté serveur), les considérations de sécurité sont nettement plus complexes. C’est le cas le moins évident pour nous. Il faut voir au cas par cas vos besoins et nos possibilités en temps et ressources serveur.

Nom de domaine et certificat TLS

Comme nous louons déjà le nom de domaine knightsofnii.com, nous pouvons vous donner gratuitement un sous-domaine pour votre site. Si vous souhaitez utiliser un autre nom de domaine, il vous faudra le louer chez un registar (OVH ou Gandi par exemple). Comptez entre 5€/an pour les TLDs les moins cher (.fr, .ovh…) et 20€/an voir beaucoup plus pour des TLDs un peu plus fancy (.ninja, .cafe, .io… ).

Configuration de la zone DNS

Si vous voulez votre propre nome de domaine, il vous faudra configurer un ou plusieurs CNAME pointant sur notre serveur (knightsofnii.com). Vous devez faire cela pour tous les sous-domaines qui doivent pointer vers votre site. Typiquement, si vous voulez que www.votre-domaine.fr permette une redirection vers votre-domaine.fr, ajoutez un CNAME pour le domaine et le sous-domaine www.

Certificat SSL

Nous gérons de notre côté la génération du certificat SSL (pour accéder au site en HTTPS). Nous utilisons Let’s Encrypt pour les certificats. Certains vieux appareils (le vieux PC sous Windows XP du grenier ou un smartphone sous Android 4.0) peuvent ne pas avoir le certificat racine installé, mais en 2023 vous ne devriez pas voir de problème.

La génération des certificats et leur renouvellement implique que votre DNS est, et reste configuré pour pointer chez nous. Pour nous éviter des ennuis (et éviter que votre site ne soit plus accessible), veillez à nous prévenir si vous comptez changer temporairement la cible de votre site. Et évidemment, prévenez nous si vous ne souhaitez plus garder votre nom de domaine, histoire qu’on s’épargne une frayeur le jour où le renouvellement automatisé va échouer…

Hébergement de site statique

Dans le cas d’un site statique, nous pouvons vous donner accès à un répertoire que vous gérez à distance en SFTP. Le contenu de ce répertoire sera servi par Apache sous votre nom de domaine. Une fois les comptes et la configuration faite de notre côté, vous êtes donc autonome pour mettre à jour et ajouter du contenu. L’accès à distance permet aussi d’utiliser des outils automatisés (comme le CI de Gitlab) pour mettre à jour le contenu.

Accès en SFTP manuellement

Pour des raisons de sécurités, le compte créé disposera d’un accès SSH extrêmement limité : SFTP seulement (impossible d’ouvrir un shell en SSH) et « prisonnier » du répertoire contenant votre site.

Dans les détails, le répertoire qui vous est assigné est en lecture seule, et contient deux sous-répertoires dans lesquels vous pouvez écrire :

• www : les fichiers de votre site (le répertoire entier est servi par Apache)
• data: si vous avez des fichiers à stocker temporairement, qui ne doivent pas être accessibles

N’importe quel client SFTP devrait faire l’affaire pour accéder aux fichiers. Par exemple FileZilla (interface graphique, Windows/Linux/Mac) ou des outils en ligne de commande (lftp ou sftp par exemple). Sur une machine Linux, je vous recommanderai lftp pour sa fonctionnalité de « mirroiring » similaire à rsync : mirror -e -R repertoire_local/ www/ .

Déploiement automatique et outils de générations de sites statiques via Gitlab

Si vous êtes déjà familier avec Git, il est possible d’utiliser notre Gitlab – ou une autre instance – et l’outil de CI/CD intégré pour déployer automatiquement votre site après chaque push sur le dépôt. Quelques raisons peuvent vous motiver :

• le confort de ne rien avoir à faire de plus sur votre machine que de commit/push
• la possibilité de construire votre site avec un outil comme Jenkins ou Hugo, sans avoir à faire la contruction et l’envoie des fichiers générés
• la possibilité de collaborer sur le projet sans avoir à partager les codes d’accès et à configurer les machines de tout le monde

Si vous voulez configurer un dépôt Gitlab pour déployer le site automatiquement, vous devrez :

• ajouter un fichier .gitlab-ci.yml à la racine de votre dépôt (détails plus bas)
• ajouter une clé privée en tant que « secret » du dépôt sur Gitlab
  • la clé publique correspondante doit nous être transmise pour l’ajouter à votre compte

Le fichier .gitlab-ci.yml

Ce fichier contient les instructions pour le CI/CD de Gitlab. Il décrit un ensemble de processus à exécuter pour construire et déployer votre dépôt. Nous allons rester sur un cas simple dans un premier temps : votre dépôt contient directement les fichiers de votre site web (pas d’étape de construction). Pour plus de détails, consultez la documentation de Gitlab sur le format de ce fichier.

Par défaut, les commandes s’exécuteront dans un container Docker (ici une image de debian). Un ensemble de variables d’environnement sont des secrets qu’il faudra ajouter à notre dépôt Gitlab (détails dans la section suivante) : PRODUCTION_PRIVATE_KEY (la clé privée), PRODUCTION_USER et PRODUCTION_SERVER (votre login et le nom de domaine de notre serveur). Les étapes sont assez simple, même si le code final est un peu alambiqué :

1. avant toute chose (before_script), installer quelques paquets et placer notre clé privée (ainsi qu’un petit fix abscon mais nécessaire)
2. synchroniser (miroir) le dossier www de votre site avec le contenu entier du dépôt (./)

Voici un exemple documenté :

# l'image Docker à utiliser, celle là est minimale et devrait faire le taff
image: debian:stable-slim

# l'étape 'deploy_production' qui met en synchronise tous nos fichiers
deploy_production:
  stage: deploy
  environment:
    # quelques infos non nécessaires, mais qui permettent à Gitlab de nous mettre un petit lien vers notre site
    name: production
    url: "https://<l'adresse de votre site>"

  before_script:
    # XXX added ssh-client for the stupid fix required below
    - apt-get update -y && apt-get install lftp  ssh-client -y
    - mkdir -p ~/.ssh
    # PRODUCTION_PRIVATE_KEY is marked as a private *file* in Gitlab config
    - cp "$PRODUCTION_PRIVATE_KEY" ~/.ssh/id_rsa && chmod 0600 ~/.ssh/id_rsa
    # XXX small trick because of a current bug in lftp version shipped by recent debian images...
    # see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964953
    - ssh -Tn -o StrictHostKeyChecking=accept-new "$PRODUCTION_USER@$PRODUCTION_SERVER" || echo "Key added"

  script:
    # si vous voulez seulement qu'un sous-dossier soit synchnonisé, changez la partie
    # `mirror -e -R <répertoire à copier>/ www/` en laissant bien un '/' à la fin du nom de dossier
    - lftp -c "set sftp:auto-confirm yes ; open -u $PRODUCTION_USER, sftp://$PRODUCTION_SERVER ; mirror -e -R ./ www/ ; quit"

  # déployer seulement quand vous mettez à jour la branche "main",
  # rennomez ou enlevez cette section si vous voulez déployer depuis d'autres branches
  only:
    - main

Ajouts des « secrets » nécessaires sur Gitlab

Pour ne pas laisser des informations sensibles (comme la clé privée de déploiement) en clair dans le dépôt Git, nous utilisons des variables de projet Gitlab. Ces variables sont transmises lors de l’exécution du CI en tant que variables d’environnement. Pour ajouter/modifier des variables, aller dans le menu de projet, Settings > CI/CD.

Vous devez ensuite ajouter les variables suivantes: