{"id":28464698,"url":"https://github.com/wildcodeschool/wns-deploy-angular-spring","last_synced_at":"2026-01-20T16:24:44.795Z","repository":{"id":178968273,"uuid":"659772661","full_name":"WildCodeSchool/wns-deploy-angular-spring","owner":"WildCodeSchool","description":null,"archived":false,"fork":false,"pushed_at":"2023-10-15T13:10:19.000Z","size":553,"stargazers_count":2,"open_issues_count":0,"forks_count":4,"subscribers_count":5,"default_branch":"main","last_synced_at":"2025-08-26T12:46:14.000Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"TypeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/WildCodeSchool.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2023-06-28T14:24:39.000Z","updated_at":"2024-08-06T07:39:16.000Z","dependencies_parsed_at":null,"dependency_job_id":"a4e4dc1e-008b-4cd0-ba2f-dac9d038524c","html_url":"https://github.com/WildCodeSchool/wns-deploy-angular-spring","commit_stats":null,"previous_names":["wildcodeschool/wns-deploy-angular-spring"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/WildCodeSchool/wns-deploy-angular-spring","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/WildCodeSchool%2Fwns-deploy-angular-spring","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/WildCodeSchool%2Fwns-deploy-angular-spring/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/WildCodeSchool%2Fwns-deploy-angular-spring/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/WildCodeSchool%2Fwns-deploy-angular-spring/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/WildCodeSchool","download_url":"https://codeload.github.com/WildCodeSchool/wns-deploy-angular-spring/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/WildCodeSchool%2Fwns-deploy-angular-spring/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28606971,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-20T16:10:39.856Z","status":"ssl_error","status_checked_at":"2026-01-20T16:10:39.493Z","response_time":117,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-06-07T05:10:16.021Z","updated_at":"2026-01-20T16:24:44.774Z","avatar_url":"https://github.com/WildCodeSchool.png","language":"TypeScript","readme":"# Déploiement d'un projet Angular / Spring Boot\n\n## Présentation\n\nCe projet est constitué :\n\n* `./back` d'un backend Sprint Boot 3 qui se connecte à une base de donnée PostgreSQL\n* `./front` et d'un frontend Angular 15.\n* `./deploy` \u0026 `.github/workflows` de fichiers de configuration et de scripts assurant le déploiement de ce projet vers un serveur, grâce à GitHub Actions\n* `./docker-compose.dev.yml` d'un fichier compose permettant de créer et lancer l'application en local\n\nLe front ne fait qu'afficher une page (`HomeComponent`) incluant : \n* La version : prod ou preprod, récupérée depuis `front/src/environments/environment.ts` (qui bascule vers `front/src/environments/environment.prod.ts`) lorsque l'environnement Angular est production\n* La connectivité au back : grâce au `HealthCheckService`, on appelle périodiquement `/api/ping` pour vérifier que l'accès au backend depuis le frontend est bien fonctionnel.\n\n## Démarrer\n\nPour lancer le projet en local sur une machine de développement\n\n```\ncd back \n./mvnw spring-boot:build-image\ncd ..\nGATEWAY_PORT=8889 docker compose -f docker-compose.dev.yml up --build --force-recreate -d\n```\n\nLa webapp devrait être accessible à l'adresse `http://localhost:8889`\n\n### Explication du processus de build\n\nLe projet Docker Compose va compiler le front Angular dans un container en utilisant `./front/Dockerfile`. La compilation va générer les fichiers dans un dossier de sortie qui est sur un volume Docker.\n\nCela permet qu'un autre container, faisant tourner nginx, puisse utiliser le dossier du volume afin d'afficher le front. \nLe container nginx fait aussi proxy vers le backend. Comme l'indique `./nginx.conf`, toutes les requêtes commençant par `/api/` vont être redirigées vers `http://back:8080/` donc le container du backend. Le hostname `back` est généré grâce à docker compose, car tous les containers sont dans le même _network_ Docker. \n\nLe backend est tout simplement lancé à partir de l'image Docker qui a été générée par la commande `./mvnw spring-boot:build-image`. En local cette commande est lancée à la main et génère une image Docker : `local/wns-deploy-angular-spring-back:latest`\n\nOn peut constater que les containers dépendent les uns des autres. On définit donc l'ordre de lancement grâce à `depends_on` : \n\n```text\n`db` (postgresql) -- puis --\u003e `back` --\\\n`front`---------------------------------\u003e-- puis --\u003e `nginx`   \n```\n\n## Déploiement automatisé ou CD (Continuous Deployment)\n\nComme l'illustre le schéma ci-dessous, ce projet propose un cycle de déploiement automatisé se basant sur :\n* Les GitHub Actions\n* DockerHub\n* Un webhook\n* Docker compose \n\n[Explications](#explications)\n\n![](./docs/deployment_cycle.png)\n\n### Explications\n\n#### **GitHub Action**\nComme défini dans le fichier `.github/workflows/on-push.yaml`, lorsque GitHub détecte un push sur la branche `main` ou `dev`, une GitHub Action est lancée.\nCette GitHub Action va venir construire : \n* une image docker pour le backend grâce au plugin Spring Boot pour Maven\n* une image docker pour le frontend avec nginx et les fichiers compilés du front\n\n_NOTE_ Les actions utilisent des secrets qui [doivent être définis dans la configuration](https://docs.github.com/en/actions/security-guides/encrypted-secrets#creating-encrypted-secrets-for-a-repository) (réservée aux admins) du repository GitHub afin d'éviter que des informations sensibles se retrouvent dans les fichiers versionnés\n\nLes images sont taggées avec le nom de la branche, pour pouvoir déterminer si le déploiement doit se faire : \n* `main` =\u003e le déploiement doit se faire en **production**\n* `dev` =\u003e déploiement en **pré-production**\n\nUne fois les images construites, elles sont publiées sur Docker Hub dans l'espace de l'utilisateur qui a été configuré.\n\n#### **DockerHub** \n\nEn configurant un webhook sur la page DockerHub de votre image, dans l'espace Docker de l'utilisateur vers lequel les images ont été publiées, vous pourrez appeler une URL de votre choix à chaque fois qu'une nouvelle version du tag de l'image docker est publiée.\n\nNous souhaitons par ce biais appeler un script sur notre serveur pour déclencher le déploiement.\n\n#### **Webhook sur le serveur**\nLe package Linux `webhook` permet justement d'exposer une URL (port par défaut 9000) et de déclencher une action sur le serveur en passant les paramètres de la requête\nInstaller le package webhook sur votre serveur si ce n'est pas déjà fait : \n```\nsudo apt install webhook\n```\n\nL'idéal est de [créer un service système Linux](https://timleland.com/how-to-run-a-linux-program-on-startup/) pour ce programme afin de garantir qu'il soit toujours lancé, même après un redémarrage système.\n\nLa configuration de webhook permettant de lancer le script est située ici `./deploy/webhook.conf`, elle est à placer dans `/etc/webhook.conf`.\nEn observant cette configuration on note : \n* Qu'on appelle le script `/home/ubuntu/scripts/fetch-and-deploy.sh`\n* Avec en arguments des valeurs issues du BODY de la requête de webhook :\n  * `push_data.tag` : Le tag de l'image qui a été publié sur DockerHub `main` ou `dev`\n  * `push_data.pusher` : L'utilisateur qui a fait le push sur DockerHub, cela va nous permettre de savoir dans quel espace DockerHub récupérer les images à déployer\n  * La description complète du JSON envoyé par DockerHub est consultable ici : https://docs.docker.com/docker-hub/webhooks/\n\n_IMPORTANT_ Le script doit être déployé au même chemin que celui dans `/etc/webhook.conf` et **être exécutable** (http://dev.petitchevalroux.net/linux/rendre-script-executable-linux.262.html) \n\nPour suivre les appels au service webhook, consultez ses logs avec la commande ci-dessous. Si DockerHub appelle bien votre service, vous verrez des lignes apparaitre. \n```\nsudo journalctl -f -u webhook -n 200\n```\n\nAssurez-vous bien que le service est démarré :\n```\nsudo systemctl restart webhook\n```\n\n_IMPORTANT 2_ Il faut redémarrer le service dès que vous modifiez `/etc/webhook.conf`.\n\nVous pouvez tester le script directement en lui passant les arguments qui vous arrangent : \n```\nbash /path/to/the/fetch-and-deploy.sh main lgrignon\n```\n\nIl faut que ce script crée les 3 containers de l'application (pour la préproduction, remplacer `prod` par `preprod`) : \n- app_prod_db\n- app_prod_back\n- app_prod_front\n\nVous pouvez ensuite tester que l'application marche en accédant à `http://\u003cIP DE VOTRE SERVER\u003e:8000` si vous avez déployé l'app de production (branche main)\nSinon `http://\u003cIP DE VOTRE SERVER\u003e:8002` pour la préproduction. \nLe statut de la connexion au back doit être **YES**\n\n⚠️ Il y a un bug volontairement laissé sur le site : l'environnement affiche toujours l'environnement production. Ce bug sera corrigé dans la quête https://odyssey.wildcodeschool.com/quests/2786\n\n### Troubleshooting / Correction des problèmes\n\n#### GitHub Action\nSur l'onglet Actions de votre repository GitHub vous pouvez suivre les logs du job lancé par votre push\n\n#### Webhook\nSur votre serveur, pour vérifier ce que provoque l'appel du webhook, le log du scripts\n```\nsudo journalctl -f -u webhook -n 200\n```\nNote : webhook doit avoir été créé comme un service\n\n#### Containers\nPour suivre les logs de vos containers, par exemple pour le back de production : \n```\ndocker logs app_prod_back -f --tail 200\n```\nou les logs nginx\n\n```\ndocker logs app_prod_front -f --tail 200\n```\n\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fwildcodeschool%2Fwns-deploy-angular-spring","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fwildcodeschool%2Fwns-deploy-angular-spring","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fwildcodeschool%2Fwns-deploy-angular-spring/lists"}