Mon objectif \u00e9tait de b\u00e2tir, \u00e0 partir du produit Oracle Database 23ai Free<\/em>, une solution Oracle APEX sans couts de licence, capable de supporter un tr\u00e8s grand nombre d\u2019utilisateurs. Pour r\u00e9sumer : une Database \u00ab applicative \u00bb et une arm\u00e9es d\u2019 Oracle APEX en frontal.<\/p>\n\n\n\n Quand on souhaite utiliser Oracle APEX \u00e0 une large \u00e9chelle, il faut adapter les ressources en cons\u00e9quence et cela conduit \u00e0 utiliser un serveur de plus en plus puissant. Cette augmentation \u00e9limine au passage tout recours \u00e0 des licences Oracle Database de type free<\/em> en raison des limitations de ces versions (2Go RAM, 2 cores, 12 Go disk \u2026) mais \u2026 il existe des cas de figure o\u00f9 Oracle APEX peut \u00eatre utilis\u00e9 de fa\u00e7on partitionn\u00e9e, c\u2019est-\u00e0-dire plusieurs instances APEX ind\u00e9pendantes<\/strong> acc\u00e9dant \u00e0 une m\u00eame Database de donn\u00e9es via des DB Links par exemple, ou via des API REST.<\/p>\n\n\n\n Le produit Oracle APEX est une plateforme de d\u00e9veloppement dont les pr\u00e9requis sont :<\/p>\n\n\n\n Une instance APEX<\/strong> correspond \u00e0 l\u2019installation physique du code APEX dans une Database. Une instance peut h\u00e9berger des espaces logiques de travail appel\u00e9s workspaces<\/em>. Les d\u00e9veloppeurs et les utilisateurs travailleront toujours dans le contexte d\u2019un workspace<\/em>.<\/p>\n\n\n\n Habituellement, l\u2019instance APEX et les donn\u00e9es applicatives sont colocalis\u00e9es dans la m\u00eame Database et de ce fait, une question int\u00e9ressante est de savoir comment se r\u00e9partit la consommation de ressources. En effet, il y a l\u2019activit\u00e9 relative \u00e0 la manipulation des donn\u00e9es applicatives et puis celle qui est sp\u00e9cifique au fonctionnement d\u2019APEX (acc\u00e8s aux metadata et g\u00e9n\u00e9ration dynamique des pages). Si l\u2019on s\u00e9pare l\u2019activit\u00e9 d\u2019APEX de celle li\u00e9e aux DATA applicatives, la mise a l\u2019\u00e9chelle pourra \u00eatre r\u00e9alis\u00e9e de fa\u00e7on plus rationnelle.<\/p>\n\n\n\n Voici quelques cas d\u2019usage pour notre pool APEX : <\/p>\n\n\n\n Je me suis impos\u00e9 la contrainte de n\u2019utiliser que les licences gratuites disponibles chez Oracle tout en sachant les limitations d\u2019Oracle Database Free :<\/em><\/p>\n\n\n\n Dans l\u2019approche initiale, j\u2019ai consid\u00e9r\u00e9 que le tandem \u00ab database d\u00e9di\u00e9e \u00e0 APEX + ORDS \u00bb constituait l\u2019entit\u00e9 qui ferait l\u2019objet de la clusterisation<\/em>. Je n\u2019ai donc pas fait un d\u00e9coupage entre la database APEX d\u2019une part et plusieurs ORDS en frontal d\u2019autre part. Par cons\u00e9quent, le pod <\/em>(au sens Kubernetes) relatif \u00e0 l\u2019activit\u00e9 APEX est constitu\u00e9 de deux containers :<\/p>\n\n\n\n Dans le sch\u00e9ma ci-dessus, Les pods<\/em> sont mat\u00e9rialis\u00e9s par une boite de couleur grise. la database DATA est de type free<\/em>. Elle pr\u00e9sente des limitations, comme indiqu\u00e9 pr\u00e9c\u00e9demment, mais cette database DATA peut tr\u00e8s bien \u00eatre une database Oracle avec une licence de type Standard ou Enterprise, et se situer dans un environnement on-premise<\/em> ou sur le cloud. APEX communiquera avec la database DATA via un database link.<\/p>\n\n\n\n J\u2019ai test\u00e9 le concept chez OVH en utilisant leur support de Kubernetes.<\/p>\n\n\n\n Les nodes<\/em> sont de type D2-8 (4 CPU 8 GB RAM 50 GB disk)<\/p>\n\n\n\n Remarque : La configuration D2-4 (2 CPU 4 GB RAM 50 GB disk n\u2019est pas adapt\u00e9e car le pod<\/em> sort en status \u00ab evicted<\/em> \u00bb au bout de quelques secondes (m\u00e9moire insuffisante ?).<\/p>\n\n\n\n Cf tableau des couts pour avoir une estimation du budget<\/p>\n\n\n\n Afin de limiter les taches de setup, je m\u2019appuie sur les images docker suivantes deux images docker qui sont fournies par oracle<\/a> :<\/p>\n\n\n\n Je pr\u00e9f\u00e8re prendre free 23ai<\/em> plut\u00f4t que express<\/em> car free23ai<\/em>, parmi ses fonctionnalit\u00e9s nouvelles, \u00e9limine le besoin de g\u00e9rer un wallet db pour acc\u00e9der \u00e0 des ressources web et c\u2019est un tr\u00e8s grand avantage. Parmi les variantes, il faut choisir full<\/em>. La version Lite<\/em> rend l\u2019installation d\u2019APEX impossible car il manque des packages.<\/p>\n\n\n\n Pour l\u2019image free<\/em>, j\u2019ai choisi de la faire d\u00e9marrer avec sa base \u00abpre-built\u00bb.<\/p>\n\n\n\n Pour la base centrale, il s\u2019agit d\u2019un singleton qui pourrait \u00eatre d\u00e9ploy\u00e9e sous forme de ReplicaSet<\/em> avec un niveau r\u00e9plica=1 mais dans mon cas, j\u2019ai choisi l\u2019option statefulSet<\/em> (nom DNS stable m\u00eame apr\u00e8s un red\u00e9marrage). Cf db.yaml<\/p>\n\n\n\n Comme chaque pod<\/em> d\u00e9di\u00e9 \u00e0 APEX doit \u00eatre d\u00e9ploy\u00e9 une seule fois<\/strong> sur chacun des trois nodes<\/em> poss\u00e9dant le label \u00ab\u00a0front\u00a0\u00bb, j\u2019ai choisi un type Daemonset<\/em>. Un s\u00e9lecteur installe le pod sur tous les nodes<\/em> poss\u00e9dant le label \u00ab\u00a0front\u00a0\u00bb. \u00a0cf pod-apex.yaml et le script nodes.ps1. Ensuite, on cr\u00e9e un service nomm\u00e9 \u00ab apex \u00bb de type clusterIP qui s\u2019appliquera \u00e0 tous les pods pod-apex instanci\u00e9s. Cf apex.yaml. Je ne l\u2019ai pas cr\u00e9\u00e9 de type LoadBalancer car cette t\u00e2che sera accomplie par un ingress<\/em> et c\u2019est au niveau de cet ingress<\/em> que l\u2019on demandera de l\u2019affinit\u00e9 de session.<\/p>\n\n\n\n Ajouter un Nginx Ingress Controller au cluster k8s.<\/p>\n\n\n\n OVH fournit un chart Helm<\/a> pour r\u00e9aliser cette op\u00e9ration.<\/p>\n\n\n\n Cr\u00e9er un ingress cf Ingress.yaml<\/p>\n\n\n\n Ici je demande de l\u2019affinit\u00e9 de session bas\u00e9e sur la pr\u00e9sence d\u2019un cookie qui est enti\u00e8rement g\u00e9r\u00e9 par Ingress et que j\u2019ai nomm\u00e9 \u00ab kub-apex \u00bb.<\/p>\n\n\n\n J\u2019avais tent\u00e9 d\u2019utiliser un service de type LoadBalancer<\/em> mais je ne suis pas parvenu \u00e0 obtenir un niveau satisfaisant d\u2019affinit\u00e9 de session. Le seul mode qui fonctionnait \u00e9tait l\u2019affinit\u00e9 d\u2019adresse IP, ce qi ne me convenait pas enti\u00e8rement puisque je voulais des sticky sessions<\/em> bas\u00e9es sur la valeur d\u2019un cookie.<\/p>\n\n\n\n Au bout d\u2019un quart d\u2019heure (parfois une demi-heure) le cluster est op\u00e9rationnel. On peut d\u00e9marrer encore plus vite comme c\u2019est discut\u00e9 plus loin.<\/p>\n\n\n\n R\u00e9cup\u00e9rer l\u2019adresse IP du contr\u00f4leur Ingress :<\/p>\n\n\n\n kubectl get svc ingress-nginx-controller -n ingress-nginx -o wide<\/p>\n\n\n\n Produits tierces utiles<\/p>\n\n\n\n Le produit Lens de Mirantis <\/a> pour disposer d\u2019 un tableau de bord permettant de visualiser d\u2019un coup d\u2019\u0153il l\u2019\u00e9tat des ressources du cluster Kubernetes. Sinon, il faut enchainer \u00e0 l\u2019infini des commandes kubectl.<\/p>\n\n\n\n Ci-dessous la console Lens montrant l\u2019\u00e9tat des dix pods lanc\u00e9s sur le cluster. Un pod pour DB DATA et neuf pods APEX.<\/p>\n\n\n\n R\u00e9sum\u00e9 de l\u2019ordre de lancement des fichiers yaml :<\/p>\n\n\n\n On suppose que le Ingress Controler<\/em> a d\u00e9j\u00e0 \u00e9t\u00e9 ajout\u00e9 juste apr\u00e8s la cr\u00e9ation du cluster K8s.<\/p>\n\n\n\n L\u2019image ords-developer v\u00e9rifie au startup la pr\u00e9sence d\u2019un fichier conn_string.txt et teste une connexion bas\u00e9e sur la chaine qui se trouve \u00e0 l\u2019int\u00e9rieur de ce fichier. Si cela \u00e9choue, la cr\u00e9ation du container est abandonn\u00e9e. Dans Docker compose<\/em> il existe une directive qui permet de pr\u00e9ciser quelle est la condition de d\u00e9marrage, mais pas dans Kubernetes. J\u2019ai choisi donc de ne pas avoir recours \u00e0 un container interm\u00e9diaire mais plut\u00f4t de laisser faire la nature. C\u2019est \u00e0 dire que le contr\u00f4leur K8S , dont il faut saluer l\u2019opini\u00e2tret\u00e9, fera autant de tentatives qu\u2019il est n\u00e9cessaire jusqu\u2019\u00e0 ce que la BD soit pr\u00eate \u00e0 recevoir des connexions. C\u2019est la raison pour laquelle on observera un nombre de restart<\/em> de l\u2019ordre de 2 ou 3. Cela est sans cons\u00e9quence.<\/p>\n\n\n\n Pour un chargement plus rapide, il est int\u00e9ressant de pr\u00e9alimenter la base APEX avec les objets sp\u00e9cifiques \u00e0 APEX. Cette op\u00e9ration dure en effet une quinzaine de minutes.<\/p>\n\n\n\n Apr\u00e8s avoir fait un commit<\/em> du container de DB Apex dans son \u00e9tat \u00ab install\u00e9e, j\u2019ai obtenu un nouvelle image que j\u2019ai pouss\u00e9e sur un registre priv\u00e9 chez OVH.<\/p>\n\n\n\n Un d\u00e9ploiement de la configuration pod-apex ne prend alors que moins de deux minutes au lieu de quinze. A chaque nouvelle version de l\u2019image ords-developer, il faudra r\u00e9g\u00e9n\u00e9rer cette image pour conserver l\u2019avantage de gain de temps.<\/p>\n\n\n\n Lorsqu\u2019il s\u2019agit d\u2019un sc\u00e9nario de d\u00e9ploiement d\u2019une application, c\u2019est-\u00e0-dire un contexte dans lequel c\u2019est essentiellement le runtime d\u2019APEX qui sera sollicit\u00e9, alors on privil\u00e9giera un load balancing bas\u00e9 sur l\u2019affinit\u00e9 de session. Ici, l\u2019objectif est de garantir l\u2019utilisation la plus sym\u00e9trique possible et ce n\u2019est pas l\u2019utilisateur qui choisit son pod.<\/p>\n\n\n\n S\u2019il s\u2019agit en revanche d\u2019un sc\u00e9nario o\u00f9 l\u2019on utilise les capacit\u00e9s de d\u00e9veloppement d\u2019APEX, alors il est primordial de pouvoir travailler dans la dur\u00e9e sur une instance (dur\u00e9e \u00e9lev\u00e9e de cookie) ou mieux, connaitre l\u2019instance sur laquelle on travaille, de fa\u00e7on \u00e0 pouvoir y revenir ult\u00e9rieurement \u00e0 partir d\u2019un autre device,<\/em> par exemple. Ici, on cr\u00e9era autant de services qu\u2019il y a de pods<\/em> et on fixera des r\u00e8gles de routage au niveau de l\u2019Ingress, bas\u00e9es sur le nom de host virtuel. Par exemple, http:\/host1.mydomain\/ords\/apex sera rout\u00e9e syst\u00e9matiquement vers le service associ\u00e9 au pod_1 et http:\/host1.mydomain\/ords\/apex sera dirig\u00e9 vers pod_2., etc. Cela implique donc de cr\u00e9er des noms de host au niveau de son DNS. J\u2019ai essay\u00e9 d\u2019utiliser un routage bas\u00e9 sur un path d\u2019url mais je n\u2019ai pas obtenu de r\u00e9sultat correct.<\/p>\n\n\n\n Afin de disposer d\u2019une instance la plus op\u00e9rationnelle possible, j\u2019ai rajout\u00e9 plusieurs scripts qui r\u00e9alisent les taches additionnelles suivantes :<\/p>\n\n\n\n Tous les scripts sh et sql sont enregistr\u00e9s dans un configmap (ords-configmap) qui est mont\u00e9 comme un volume et mapp\u00e9 sur un r\u00e9pertoire. Pour rappel, la taille maximale d\u2019un configMap est de 1 Mo.<\/p>\n\n\n\n La banni\u00e8re de type \u00ab instance \u00bb est cr\u00e9\u00e9e \u00e0 partir d\u2019un api plsql fournie avec APEX. On prend le nom du node ainsi que son num\u00e9ro d\u2019index qui servira pour fixer une couleur arbitraire entre 1et 16.<\/p>\n\n\n\n Ci-dessous, une r\u00e9p\u00e9tition de connexions dans des Private Wind<\/em>ows a abouti \u00e0 neuf sessions sur chacun des neuf pods APEX disponibles.<\/p>\n\n\n\n Chaque Workspace poss\u00e8de son annuaire d\u2019utilisateurs autoris\u00e9s \u00e0 se connecter. Dans le cas d\u2019un pool, il sera plus pertinent de d\u00e9l\u00e9guer la phase d\u2019authentification \u00e0 un module tiers, comme un annuaire LDAP, par exemple ou un OAUTH.<\/p>\n\n\n\n Je n\u2019ai pas mis en place TLS dans mon prototype.<\/p>\n\n\n\n Les \u00e9tapes sont d\u00e9crites dans un document OVH<\/a>.<\/p>\n\n\n\n Pour trois instances APEX et une base partag\u00e9e, voici les couts minimums escompt\u00e9s en euros avec une projection pour une dur\u00e9e d\u2019une journ\u00e9e de dix heures ou une dur\u00e9e d\u2019un mois .<\/p>\n\n\n\n * La Registry est optionnelle.<\/p>\n\n\n\n Les nodes<\/em> qui ont \u00e9t\u00e9 utilis\u00e9s chez OVH sont r\u00e9f\u00e9renc\u00e9s dans la cat\u00e9gorie Discovery<\/em>, ce qui signifie que leur cout horaire est attractif mais que leurs performances peuvent \u00eatre variables. Ces shapes<\/em> sont id\u00e9ales pour faire des tests.<\/p>\n\n\n\n Pour un sc\u00e9nario avec un nombre raisonnable d\u2019utilisateurs (une cinquantaine ?), l\u2019offre Oracle nomm\u00e9e Oracle APEX Service<\/a><\/em> est plut\u00f4t comp\u00e9titive (122 USD\/mois \u00e0 la date de mars 2025).<\/p>\n\n\n\n En compute<\/em>, une instance Oracle \u00e9quivalente VM.Standard.E4.Flex (2 OCPU, 8 Go RAM, 100 Go disk) revient \u00e0 46,85 euros\/mois. Comparable \u00e0 la B2-15 de chez OVH qui est \u00e0 46,20 \u20ac\/mois. Celle que j\u2019ai utilis\u00e9e chez OVH est une instance de cat\u00e9gorie Discovery, donc moins pr\u00e9dictible qu\u2019une B2-15.<\/p>\n\n\n\nPourquoi un pool d\u2019instances Oracle APEX ?<\/h1>\n\n\n\n
Rappel sur la plateforme de d\u00e9veloppement Oracle APEX<\/h2>\n\n\n\n
\n
\n
Approche et choix techniques<\/h1>\n\n\n\n
\n
Contenu d\u2019un pod<\/em><\/h2>\n\n\n\n
\n
Sch\u00e9ma simplifi\u00e9 du cluster<\/h2>\n\n\n\n
![\"\"](\"https:\/\/gpmfactory.com\/wp-content\/uploads\/2025\/03\/Capture-decran-2025-03-03-221621.png\")
<\/figure>\n\n\n\nMise en place du cluster<\/h1>\n\n\n\n
Etapes pour cr\u00e9er un pool de pods APEX et un pod DB centrale (DATA)<\/h2>\n\n\n\n
Etapes pr\u00e9liminaires au niveau d\u2019OVH<\/h3>\n\n\n\n
\n
Choix des images pour les containers<\/h3>\n\n\n\n
\n
\n
Il s\u2019agit de l\u2019image qui se charge de l\u2019installation d\u2019APEX, \u00e0 la diff\u00e9rence de celle qui s\u2019appelle ords<\/em> et qui n\u2019installe que la partie ords.<\/li>\n<\/ul>\n\n\n\n
Si on choisit un type ReplicaSet ou Deployement, le controleur k8s peut \u00eatre amen\u00e9 \u00e0 instancier deux pods sur le m\u00eame node.<\/p>\n\n\n\n![\"\"](\"https:\/\/gpmfactory.com\/wp-content\/uploads\/2025\/03\/image-1.png\")
<\/figure>\n\n\n\nTache<\/strong><\/strong><\/td> Commande<\/strong><\/strong><\/td> Ordre<\/strong><\/strong><\/td><\/tr> Affecter label aux nodes<\/td> Powsershell label_nodes.ps1<\/td> 1<\/td><\/tr> Cr\u00e9er les secrets<\/td> Kubectl create secret ords-secret<\/td> 2<\/td><\/tr> Cr\u00e9er les CongigMaps<\/td> kubectl create configmap \u2026<\/td> 3<\/td><\/tr> Cr\u00e9er DB DATA<\/td> Kubectl apply -f db.yaml<\/td> 4<\/td><\/tr> Cr\u00e9er les pod Apex<\/td> Kubectl apply -f pod-apex.yaml<\/td> 5<\/td><\/tr> Cr\u00e9er le service Apex<\/td> Kubectl apply -f apex-run.yaml<\/td> 6<\/td><\/tr> Cr\u00e9er le Ingress<\/td> Kubectl apply -f ingress-run.yaml<\/td> 7<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Remarque \u00e0 propos des d\u00e9pendances entre containers :<\/h3>\n\n\n\n
Diminuer le temps de d\u00e9marrage de la plateforme APEX<\/h3>\n\n\n\n
Mode de routage vers le pool en fonction du sc\u00e9nario<\/h3>\n\n\n\n
Sinon, il faudra cr\u00e9er des services de type NodePort, r\u00e9cup\u00e9rer les adresses IP affect\u00e9s et utiliser ces adresses distinctes dans l\u2019url.<\/p>\n\n\n\nScripts custom<\/em> ajout\u00e9s dans le container ords-developer<\/h3>\n\n\n\n
\n
![\"\"](\"https:\/\/gpmfactory.com\/wp-content\/uploads\/2025\/03\/image.png\")
<\/figure>\n\n\n\nAuthentification<\/h3>\n\n\n\n
TLS<\/h3>\n\n\n\n
Couts de fonctionnement<\/h1>\n\n\n\n
El\u00e9ment<\/strong><\/td> Description<\/strong><\/td> Nombre<\/strong><\/td> Tarif horaire<\/strong><\/td> Tarif<\/strong> mensuel<\/strong><\/td> Montant \/heure<\/strong><\/td> Montant<\/strong> \/jour<\/strong><\/td> Montant \/mois<\/strong><\/td><\/tr> Nodes<\/strong><\/td> D2-8 (4 CPU 8 GB RAM 50 GB disk)<\/td> 4<\/td> 0,0357<\/td> 19,8<\/td> 0,1428<\/td> 1,428<\/td> 79,2<\/td><\/tr> Load Balancer<\/strong><\/td> Size Small<\/td> 1<\/td> 0,0083<\/td> 6,059<\/td> 0,0083<\/td> 0,083<\/td> 6,059<\/td><\/tr> Adresse IP<\/strong><\/td> Adresse IP<\/td> 1<\/td> 0,0025<\/td> 1,5<\/td> 0,0025<\/td> 0,025<\/td> 1,5<\/td><\/tr> Registry (*)<\/strong><\/td> 200 Go, 15 connexions<\/td> 1<\/td> 0,0237<\/td> <\/td> 0,0237<\/td> 0,237<\/td> 17,064<\/td><\/tr> TOTAL<\/strong><\/td> <\/td> <\/td> <\/td> <\/td> 0,1536<\/td> 1,536<\/td> 103,823<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Fichiers de configuration<\/h1>\n\n\n\n