Comment j'ai construit et déployé ce portfolio

01 — Le choix de l'infrastructure

Plutôt que d'héberger ce portfolio sur une plateforme clé-en-main (GitHub Pages, Netlify, etc.), j'ai volontairement choisi de le déployer moi-même sur une VM Oracle Cloud. L'objectif : que le portfolio soit lui-même une preuve de compétences en administration systèmes, pas seulement une vitrine.

02 — Premier obstacle : capacité et rate limiting Oracle

La création d'une instance VM.Standard.E2.1.Micro a immédiatement échoué avec une erreur de capacité dans l'availability domain AD-1. En retentant plusieurs fois rapidement, j'ai déclenché un rate limit sur l'API Oracle (« Too many requests »).

Résolution : attendre entre les tentatives au lieu de retenter en boucle, alterner entre les deux shapes gratuites (leurs pools de capacité sont indépendants), et réessayer à différents moments de la journée. La capacité s'est libérée après plusieurs tentatives espacées.

03 — Nettoyage d'une VM existante

J'avais déjà une VM Oracle utilisée pour un ancien projet (un bot d'automatisation vidéo). Plutôt que de nettoyer manuellement les services, crons et fichiers résiduels — avec le risque d'en oublier un qui continue de tourner en arrière-plan — j'ai choisi de terminer l'instance et d'en recréer une propre.

04 — Serveur web : Nginx

Une fois la VM provisionnée avec une IP publique, installation de Nginx et configuration du pare-feu — à deux niveaux, ce qui est une source d'erreur classique sur Oracle Cloud :

• Le Security List / Network Security Group au niveau du VCN (dans la console Oracle)
• Le pare-feu local de la VM (ufw)

sudo apt install nginx -y
sudo ufw allow 80
sudo ufw allow 443
sudo ufw allow OpenSSH
sudo ufw enable

Oublier l'un des deux niveaux est l'erreur la plus fréquente pour quelqu'un qui découvre Oracle Cloud — les deux pare-feux doivent être ouverts indépendamment.

05 — Déploiement via Git

Le code du site est versionné sur GitHub et déployé sur la VM via git clone / git pull, plutôt que par transfert de fichiers manuel. Cela permet un historique propre et un flux de mise à jour reproductible :

git clone https://github.com/jamehj7-png/portfolio.git
cd portfolio
sudo cp index.html /var/www/html/

Une fois le token généré côté GitHub, les mises à jour du site suivent un flux simple : modification en local → commit → push → git pull sur la VM → copie vers /var/www/html/.

06 — Nom de domaine avec DuckDNS

Plutôt que de publier une adresse IP brute, j'ai relié un sous-domaine DuckDNS gratuit (jammehj.duckdns.org) à l'IP publique de la VM. Un script planifié via cron met à jour l'enregistrement DNS toutes les 5 minutes, au cas où l'IP changerait :

*/5 * * * * ~/duckdns/duck.sh >/dev/null 2>&1

07 — HTTPS avec Let's Encrypt

Certificat SSL gratuit et renouvellement automatique via Certbot, branché directement sur la configuration Nginx :

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d jammehj.duckdns.org

Certbot configure automatiquement la redirection HTTP → HTTPS et renouvelle le certificat tous les ~60 jours sans intervention manuelle.

08 — Ce que je retiens

• Une erreur d'infrastructure (capacité, rate limit) n'est pas un échec : c'est une contrainte à comprendre et contourner intelligemment.
• Sur Oracle Cloud, toujours vérifier les deux couches de pare-feu (Security List + ufw) avant de chercher plus loin un problème de connectivité.
• Un déploiement basé sur Git est plus traçable et plus sûr qu'un transfert de fichiers manuel, même pour un site simple.
• DNS dynamique + Let's Encrypt permettent d'obtenir un site en HTTPS avec un vrai nom de domaine, sans aucun coût.