Fix the database to separate the production database from the test database#34
Merged
Conversation
… each with its own volume and Flyway service, removes the old entrypoint-initdb.d volume and relies on POSTGRES_DB for automatic DB creation
… POSTGRES_DB value to auto‑create its own database (prod_blog_db for prod, test_blog_db for test)
…_POSTGRES_* vars, runs Flyway exclusively on the test DB, drops all unused prod secrets and uses prod Argon2 parameters in CI
… separate volumes and Flyway, drops the init script thanks to POSTGRES_DB auto‑creation, simplifies CI to a test‑only DB using TEST_POSTGRES_* secrets, removes unused vars and updates the volume path for Postgres 18+
…Argon2 hasher test can read time_cost, memory_cost, and parallelism from env_config. Values are set to the same prod parameters using existing ARGON2_* secrets
…in CI, mapping TEST_ARGON2_* env vars to the prod secrets so no additional test‑specific secrets are required
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Contexte de l'ancien système
Avant cette refonte, l'architecture utilisait un unique container Postgres 18 contenant deux bases de données distinctes :
prod_blog_db: base de productiontest_blog_db: base de tests (créée via un script d'initialisationdocker-entrypoint-initdb.d/01-create-test-db.sh)Le port
5432était partagé. Un service Flyway s'exécutait sur chaque base. En local, le fonctionnement était correct mais le CI présentait une faille : les variablesDATABASE_URLetTEST_DATABASE_URLpointaient toutes les deux vers la même base de données. Les tests et la production utilisaient donc la même base dans le pipeline CI, annulant toute isolation. Par ailleurs, la base de test dans le CI ne disposait pas de la tableflyway_schema_historycar aucun Flyway n'était exécuté dessus.Résumé des modifications
Séparation de la base de données en deux containers Postgres 18 distincts :
Changements
Infrastructure Docker
Le service unique
dbest remplacé par deux containers distincts :blog_db_prod: port 5433, baseprod_blog_db, utilisateurprod_userblog_db_test: port 5434, basetest_blog_db, utilisateurtest_userChaque container possède son propre volume persistant et son propre service Flyway (
flyway_prod/flyway_test). Le scriptdocker-entrypoint-initdb.d/01-create-test-db.sha été supprimé car chaque container crée automatiquement sa base via la variablePOSTGRES_DB.Le chemin des volumes a été corrigé pour la compatibilité Postgres 18+ (
/var/lib/postgresql/data→/var/lib/postgresql).Pipeline CI
La base de données du CI utilise désormais exclusivement la base de test
test_blog_db. Les identifiants sont passés via les secrets avec des variables de test. Flyway s'exécute sur cette même base pour garantir la présence de la tableflyway_schema_history.Les variables obsolètes ont été supprimées. Les paramètres Argon2 de production sont utilisés dans le CI pour être au plus proche des conditions réelles.