Solutions TI

Déployer Hudu auto-hébergé sur Azure Container Apps avec Terraform

June 11, 2026

•

8 min

Un article de Jérémy Frandon

‍

Pourquoi diable migrer vers Azure ?

Hudu est la source documentaire principale de nexxo. Tous nos techniciens TI en dépendent pour répondre aux demandes de nos clients. Ce n'est donc pas exagéré de dire qu'Hudu est un outil critique pour nexxo.

Jusqu'à récemment, nous hébergions Hudu sur un Droplet de DigitalOcean, conformément au tutoriel disponible sur leur site.

Ce déploiement fonctionnait bien mais avait trois limitations:

Les backups automatiques de la VM DigitalOcean étaient lourdes et ne permettaient pas facilement de changer de fournisseur.
La VM devait être changée pour un modèle avec plus de RAM lorsque trop de techniciens y travaillaient en même temps (surtout après une période d'embauche), puis elle était sous-utilisée par l'équipe de techniciens de nuit.

Ayant constaté cela, et fort de mon expérience dans le déploiement d'applications web sur mesure pour nos clients Automatisation/IA, j'ai proposé à notre directeur des opérations d'étudier la possibilité de déployer Hudu dans notre environnement Azure.

Ce déploiement permettrait :

Une gestion des backups de fichiers et de bases de données en copies instantanées
Une élasticité intrajournalière de l'affectation des ressources
La possibilité pour tous les membres Automatisation/IA d'effectuer les actions de maintenance

Et dans cet article je vous montre comment nous nous y sommes pris, de la rétro-ingénierie du déploiement officiel jusqu'à la soirée de bascule.

Chaque composant du docker-compose.yml a son équivalent Azure, et l'ensemble tient en un seul module Terraform.

‍

La documentation ? Là où l'on va, on n'a pas besoin de documentation

Si vous cherchez le guide officiel pour déployer Hudu sur Azure, vous ne le trouverez pas (du moins, il n'existait pas encore au moment de la rédaction de cet article). Cependant, le guide de self-host officiel nous explique comment Hudu fonctionne via trois fichiers : .env, docker-compose.yml et default.conf.

En comprenant chacun de ces fichiers, nous pouvons trouver les équivalents Azure aux ressources auto-hébergées sur la machine virtuelle.

Le fichier .env permet la configuration de Hudu. Le fichier default.conf permet la configuration de nginx en serveur mandataire.
Le fichier docker-compose.yml définit plusieurs services: interagissant entre eux pour faire fonctionner l'application: une base de données PostgreSQL, un cache Redis, l'application Hudu hududocker/hudu:latest, l'exécuteur de tâches Hudu bundle exec sidekiq -C config/sidekiq.yml, et un serveur mandataire de sécurité linuxserver/swag.

Un conteneur, ça ne se souvient de rien

Je ne vais pas ici passer en revue les subtilités de docker-compose ou de la spécification des conteneurs OCI; gardez simplement à l'esprit que les conteneurs sont une méthode standard d'empaquetage d'application, et qu'il existe plusieurs plateformes pour exécuter ces applications comme Docker, Podman, Kubernetes, et Azure Container Apps

Chez nexxo nous utilisons cette dernière option pour héberger les automatisations et applications sur mesure de nos clients ; il était donc temps de nous autoéquiper.

Le principe de base du déploiement de conteneurs infonuagiques est de n'y conserver aucun état permanent. Si une application crashe, elle doit pouvoir être redémarrée instantanément sans perte de données. C'est pourquoi nous n'allons pas déployer PostgreSQL dans Azure Container App, mais seulement Hudu et Redis.

Pour les curieux, voici notre code Terraform, qui est presque une simple traduction du docker-compose.yml.

locals {
  hudu_image = "hududocker/hudu:2.42.1"
}

resource "azurerm_container_app" "this" {
  name                         = var.project_name
  container_app_environment_id = azurerm_container_app_environment.this.id
  resource_group_name          = azurerm_resource_group.client.name
  revision_mode                = "Single"


  dynamic "secret" {
    for_each = local.app_env_vars
    iterator = each
    content {
      name  = lower(replace(each.key, "_", "-"))
      value = tostring(each.value)
    }
  }

  template {
    min_replicas = 0
    max_replicas = 1

    container {
      name   = var.project_name
      image  = local.hudu_image
      cpu    = 0.25
      memory = "0.5Gi"

      env {
        name  = "PORT"
        value = "3000"
      }

      dynamic "env" {
        for_each = local.app_env_vars
        content {
          name        = env.key
          secret_name = lower(replace(env.key, "_", "-"))
        }
      }

      readiness_probe {
        transport = "HTTP"
        port      = 3000
        path      = "/"
        header {
          name  = "X-Forwarded-Proto"
          value = "https"
        }
        initial_delay           = 10
        interval_seconds        = 60
        timeout                 = 1
        failure_count_threshold = 30
        success_count_threshold = 1
      }

      liveness_probe {
        transport               = "TCP"
        port                    = 3000
        initial_delay           = 10
        interval_seconds        = 60
        timeout                 = 1
        failure_count_threshold = 30
      }
    }

    container {
      name   = "worker"
      image  = local.hudu_image
      cpu    = 0.25
      memory = "0.5Gi"

      dynamic "env" {
        for_each = local.app_env_vars
        content {
          name        = env.key
          secret_name = lower(replace(env.key, "_", "-"))
        }
      }

      args = ["bundle", "exec", "sidekiq", "-C", "config/sidekiq.yml"]
    }

    container {
      name   = "redis"
      image  = "redis:7.4.0"
      cpu    = 0.25
      memory = "0.5Gi"

      dynamic "env" {
        for_each = local.app_env_vars
        content {
          name        = env.key
          secret_name = lower(replace(env.key, "_", "-"))
        }
      }

      args = ["redis-server"]
    }

  }

  ingress {
    external_enabled = true
    target_port      = 3000
    transport        = "http"

    traffic_weight {
      percentage      = 100
      latest_revision = true
    }

    dynamic "ip_security_restriction" {
      for_each = var.ip_whitelist
      content {
        action           = "Allow"
        ip_address_range = ip_security_restriction.value
        name             = "allow-${index(var.ip_whitelist, ip_security_restriction.value)}"
      }
    }
  }
}

‍

Le point clé ici est min_replicas = 0 : lorsque personne ne travaille la nuit, le conteneur s'arrête complètement et ne génère aucun coût de calcul. Les readiness_probe et liveness_probe s'assurent qu'Azure ne dirige pas de trafic vers un conteneur pas encore prêt à répondre.

PostgreSQL c'est PostgreSQL

J'écrivais tantôt qu'il est déconseillé de stocker les états dans Docker. Où donc héberger la base de données?

Il se trouve qu'Azure propose un service de base de données PostgreSQL géré: Azure Database pour PostgreSQL. C'est exactement ce qu'il nous faut pour notre base de données Hudu. De plus, le dépôt Azure Verified Modules a un module Terraform nous permettant de configurer la base de données facilement.

À la fin de cette section vous trouverez le code Terraform que nous utilisons. Il faut cependant noter la configuration azure.extensions; Hudu utilise certaines extensions PostgreSQL activées par défaut dans le déploiement Docker qui doivent être autorisées dans la configuration Azure avant d'être chargées. Le reste de la configuration est standard pour une base de données Azure à faible coût. La documentation des valeurs du module se trouve ici.

resource "random_password" "db" {
  length           = 16
  override_special = "_%@"
  special          = true
}

module "db" {
  source  = "Azure/avm-res-dbforpostgresql-flexibleserver/azurerm"
  version = "0.1.4"

  name                          = "${var.project_name}-db-${random_id.this.hex}"
  location                      = var.location
  resource_group_name           = azurerm_resource_group.client.name
  administrator_login           = "psqladmin"
  administrator_password        = random_password.db.result
  server_version                = 18
  sku_name                      = "B_Standard_B2s"
  enable_telemetry              = false
  high_availability             = null
  public_network_access_enabled = true
  zone                          = "2"

  firewall_rules = {
    azure_services = {
      name             = "allow-azure-services"
      start_ip_address = "0.0.0.0"
      end_ip_address   = "0.0.0.0"
    }
  }

  databases = {
    application = {
      name      = "application"
      charset   = "UTF8"
      collation = "en_US.utf8"
    },
  }

  # Enable extensions  
  server_configuration = {
    extensions = {
      name   = "azure.extensions"
      config = "address_standardizer,address_standardizer_data_us,age,amcheck,anon,azure_ai,azure_storage,bloom,btree_gin,btree_gist,citext,credcheck,cube,dblink,dict_int,dict_xsyn,earthdistance,fuzzystrmatch,hll,hstore,hypopg,intagg,intarray,ip4r,isn,lo,login_hook,ltree,oracle_fdw,orafce,pageinspect,pg_buffercache,pg_cron,pg_diskann,pg_duckdb,pg_freespacemap,pg_hint_plan,pg_partman,pg_prewarm,pg_repack,pg_squeeze,pg_stat_statements,pg_trgm,pg_visibility,pgaudit,pgcrypto,pglogical,pgrouting,pgrowlocks,pgstattuple,plpgsql,plv8,postgis,postgis_raster,postgis_sfcgal,postgis_tiger_geocoder,postgis_topology,postgres_fdw,postgres_protobuf,semver,session_variable,sslinfo,tablefunc,tdigest,tds_fdw,timescaledb,topn,tsm_system_rows,tsm_system_time,unaccent,uuid-ossp,vector"
    }
  }
}

locals {
  db_env_vars = {
    DB_PASSWORD               = random_password.db.result
    DB_NAME                   = "application"
    DB_USERNAME               = "psqladmin"
    DB_HOST                   = module.db.fqdn
  }
}

‍

Nous avons volontairement choisi le SKU B_Standard_B2s — le moins cher disponible — avec la possibilité de le faire évoluer facilement si les besoins changent. C'est exactement l'élasticité qu'on ne pouvait pas obtenir sur DigitalOcean sans intervention manuelle.

‍

S3 c'est (Presque) Blob

Les lecteurs avertis auront remarqué qu'il y a un autre état précédemment stocké dans Docker pour la configuration docker-compose.yml. Il s'agit des volumes:. Ceux-ci sont des systèmes de fichiers persistants pour Hudu et Redis. Or, j'ai précédemment indiqué que pour notre nouveau déploiement tous les fichiers associés à un conteneur sont perdus au redémarrage.

Pour Redis, qui est utilisé ici comme cache et non comme base de données, ce n'est pas grave. On peut accepter un peu de lenteur et que Hudu fasse des requêtes à la base de données le temps de réchauffer le cache.

Pour Hudu, les volumes sont utilisés pour stocker les pièces jointes de documentation. C'est une fonction critique qu'on ne peut simplement désactiver. Que faire?

Heureusement Hudu supporte de désactiver l'utilisation du système de fichiers au profit de n'importe quel hébergeur de fichiers supportant le protocole S3 nativement. Dans notre déploiement précédent nous utilisions un Espace de stockage d'objet de DigitalOcean. Mais nous souhaitons également porter ce stockage vers Azure. Cependant Azure ne supporte pas le protocole S3. Il faut donc trouver un adaptateur entre le protocole Azure Blob et S3. Depuis la dépréciation et suppression de Minio Gateway, il n'y a pas beaucoup d'alternatives abordables. Flexify.io a une fonction gateway dans leur édition communautaire. Leur documentation est très limitée, mais après plusieurs tentatives je suis arrivé au code Terraform suivant qui fonctionne.

Retrouvez ci-dessous le code Terraform pour le déploiement d'un Blob et de l'adaptateur Flexify dans un Container App.


resource "azurerm_storage_account" "blob" {
  name                = "appblob${random_id.this.hex}"
  resource_group_name = azurerm_resource_group.client.name
  location            = var.location

  account_tier             = "Standard"
  account_replication_type = "LRS"


  min_tls_version                 = "TLS1_2"
  allow_nested_items_to_be_public = false

  blob_properties {
    # Point-in-time restore prerequisites: versioning + change feed + soft delete
    versioning_enabled  = true
    change_feed_enabled = true

    delete_retention_policy {
      days = 30
    }

    container_delete_retention_policy {
      days = 30
    }

    # Restore window must be strictly less than the soft-delete retention above
    restore_policy {
      days = 29
    }
  }
}

resource "azurerm_storage_container" "blob" {
  name                  = "appblobcontainer${random_id.this.hex}"
  storage_account_id    = azurerm_storage_account.blob.id
  container_access_type = "private"
}

locals {
  blob = {
    type       = "AZURE"
    account    = azurerm_storage_account.blob.name
    container  = azurerm_storage_container.blob.name
    access_key = azurerm_storage_account.blob.primary_access_key
  }
}

resource "random_password" "s3_identity" {
  length           = 16
  override_special = "_%@"
  special          = false
}

resource "random_password" "s3_key" {
  length           = 32
  override_special = "_%@"
  special          = false
}

resource "azurerm_container_app" "s3proxy" {
  name                         = "s3proxy"
  container_app_environment_id = azurerm_container_app_environment.this.id
  resource_group_name          = azurerm_resource_group.client.name
  revision_mode                = "Single"

  template {
    min_replicas = 0
    max_replicas = 1

    container {
      name   = "flexify-engine"
      image  = "flexifyio/engine:edge"
      cpu    = 0.5
      memory = "1Gi"

      args = ["proxy",

        "--port", "8080",

        # S3 credentials exposed to clients
        "--key-id", random_password.s3_identity.result,
        "--secret-key", random_password.s3_key.result,

        # Azure Blob backend (cloud1)
        "--cloud1", local.blob.type,
        "--cloud1-key-id", local.blob.account,
        "--cloud1-secret-key", local.blob.access_key,

        # Virtual bucket mapping
        "--virtual-bucket1", local.blob.container,
        "--virtual-bucket1-cloud1", local.blob.type,
        "--virtual-bucket1-cloud1-bucket", local.blob.container,
        "--virtual-bucket1-cloud1-key-id", local.blob.account,
        "--virtual-bucket1-cloud1-secret-key", local.blob.access_key,

        "--log-level", "DEBUG",
      "--console-log"]

      liveness_probe {
        transport               = "TCP"
        port                    = 8080
        initial_delay           = 5
        interval_seconds        = 5
        timeout                 = 1
        failure_count_threshold = 30
      }
    }
  }

  ingress {
    external_enabled = true
    target_port      = 8080
    transport        = "http"

    traffic_weight {
      percentage      = 100
      latest_revision = true
    }

    dynamic "ip_security_restriction" {
      for_each = var.ip_whitelist
      content {
        action           = "Allow"
        ip_address_range = ip_security_restriction.value
        name             = "allow-${index(var.ip_whitelist, ip_security_restriction.value)}"
      }
    }
  }
}

locals {
  blob_env_vars = {
    USE_LOCAL_FILESYSTEM = false
    AUTHENTICATE_UPLOADS = true
    S3_FORCE_PATH_STYLE  = true
    S3_ENDPOINT          = "https://${azurerm_container_app.s3proxy.name}.${azurerm_container_app_environment.this.default_domain}"
    S3_BUCKET            = local.blob.container
    S3_ACCESS_KEY_ID     = random_password.s3_identity.result
    S3_SECRET_ACCESS_KEY = random_password.s3_key.result
    S3_REGION            = "us-east-1"
    S3_USE_SSL           = true
  }
}

Le principe est simple : Flexify reçoit les clés d'accès Azure Blob et expose un endpoint compatible S3 vers lequel Hudu peut pointer. Du point de vue de Hudu, rien ne change — il parle S3 comme avant. La partie compliquée était de trouver les bons arguments CLI pour le mapping de bucket virtuel, d'où les nombreuses tentatives mentionnées.

SSL & DNS

Une fois tous les composants de Hudu hébergés, il ne reste plus qu'à le mettre en ligne. Nous utilisions déjà Cloudflare comme DNS et le serveur mandataire de sécurité s'occupait de charger et renouveler le certificat.

Le code Terraform ci-dessous n'a rien de particulier. Il fait juste collaborer Cloudflare TLS Acme/Let's Encrypt et le Container App

provider "cloudflare" {
  api_token = data.azurerm_key_vault_secret.cloudflare_token.value
}

locals {
  hostname = var.project_name
  fqdn     = "${local.hostname}.${var.root_domain}"
}


data "cloudflare_zone" "mazone" {
  filter = { name = var.root_domain }
}


resource "cloudflare_dns_record" "app" {
  zone_id = data.cloudflare_zone.nexxoapp.zone_id
  name    = local.hostname
  type    = "CNAME"
  content = "${azurerm_container_app.this.name}.${azurerm_container_app_environment.this.default_domain}"
  ttl     = 1
  proxied = false
}

resource "cloudflare_dns_record" "this_asuid" {
  zone_id = data.cloudflare_zone.nexxoapp.zone_id
  name    = "asuid.${local.hostname}"
  type    = "TXT"
  content = azurerm_container_app.this.custom_domain_verification_id
  ttl     = 1
  proxied = false
}

resource "tls_private_key" "acme_account" {
  algorithm = "RSA"
  rsa_bits  = 2048
}

resource "acme_registration" "this" {
  account_key_pem = tls_private_key.acme_account.private_key_pem
  email_address   = data.azuread_user.current.user_principal_name
}

resource "random_password" "cert_p12" {
  length  = 32
  special = false
}

resource "acme_certificate" "this" {
  account_key_pem          = acme_registration.this.account_key_pem
  common_name              = local.fqdn
  key_type                 = "2048"
  certificate_p12_password = random_password.cert_p12.result

  dns_challenge {
    provider = "cloudflare"
    config = {
      CF_DNS_API_TOKEN = data.azurerm_key_vault_secret.cloudflare_token.value
    }
  }
}

resource "azurerm_container_app_environment_certificate" "this" {
  name                         = replace(local.fqdn, ".", "-")
  container_app_environment_id = azurerm_container_app_environment.this.id
  certificate_blob_base64      = acme_certificate.this.certificate_p12
  certificate_password         = random_password.cert_p12.result
}

resource "azurerm_container_app_custom_domain" "this" {
  name                                     = local.fqdn
  container_app_id                         = azurerm_container_app.this.id
  certificate_binding_type                 = "SniEnabled"
  container_app_environment_certificate_id = azurerm_container_app_environment_certificate.this.id

  depends_on = [cloudflare_dns_record.app, cloudflare_dns_record.this_asuid]
}

locals {
  dns_env_vars = {
    DOMAIN          = local.fqdn
    URL             = var.root_domain
    SUBDOMAINS      = "hudu"
    ONLY_SUBDOMAINS = true
    VALIDATION      = "http"
    STAGING         = false
  }
}

output "app_url" {
  description = "Application URL"
  value       = "https://${local.fqdn}"
}

La nuit de la bascule

En début de soirée, nous avons fait un premier pg_dump pour sauvegarder la base de données avant tout changement et déplacement. Nous avons ensuite mis à jour Hudu à sa dernière version mineure, tout juste sortie. Puis nous avons fait un deuxième pg_dump pour pg_restore dans la base de données Azure. C'est le moment qui concentre le risque maximal : les données ont bougé, mais l'application pointe encore vers l'ancienne base. Toute l'équipe avait le doigt sur le retour arrière.

Pendant ce temps, nous utilisions rclone (merci à Pierre-Baptiste d'avoir recommandé cet outil) pour copier les données du S3 sur DigitalOcean vers le nouveau.

Une fois les copies terminées, nous avons changé les configurations du .env sur DigitalOcean pour pointer vers les nouveaux services et vérifier la compatibilité. Dans l'éventualité d'une erreur, nous aurions simplement retourné vers l'ancienne configuration. Avoir répété ce retour arrière la semaine précédente nous a permis d'aborder cette étape sereinement. Étant donné qu'il n'y a pas eu d'erreur, il ne restait plus qu'à déployer la Container App d'Hudu.

Conclusion

Hudu est maintenant déployé dans Azure. J'ai rédigé les procédures de sauvegarde et de récupération. Deux mois après la migration, l'élasticité à zéro réplique la nuit a déjà réduit notre facture de calcul de façon visible. Et surtout, plusieurs membres de l'équipe Automatisation/IA peuvent maintenant effectuer une mise à jour de version en autonomie, sans solliciter notre directeur des opérations ; ce qui était l'objectif premier. Je vous ferai peut-être part des tests et résultats dans un prochain billet 😉

Gardez une longueur d'avance grâce aux conseils d'experts

Abonnez-vous à notre infolettre pour recevoir les derniers conseils et mises à jour dans l'industrie de la technologie.