Applications Docker

Ton application Docker en ligne, depuis Paris.

Pousse ton image, on la met en ligne avec HTTPS, ton domaine et ses journaux. Facturée à la minute ; éteinte, elle ne coûte plus rien, puisqu’elle n’a pas de disque.

Déployer mon applicationLire le guide
Allumée
dès 1,50 €/mois
Éteinte
0 €/mois
Hébergée
Paris, Equinix PA5
$ ark deploy- construction de registry.arkya.gg/c-7f3a91c04d2e/site-guilde:8f2c1d9a44e0 pour linux/amd64  …ok image construite : registry.arkya.gg/c-7f3a91c04d2e/site-guilde:8f2c1d9a44e0- envoi de registry.arkya.gg/c-7f3a91c04d2e/site-guilde:8f2c1d9a44e0- enregistrement de la version chez Arkyaok version 8f2c1d9a44e0 disponible- analyse de l'imageok rien de sérieux dans cette image- mise en service de site-guilde:8f2c1d9a44e0ok site-guilde tourne en 8f2c1d9a44e0  site-guilde-k7p2x9q.arkya.app

En trois étapes.

Tu as un Dockerfile ? ark construit l’image, l’envoie sur ton registre privé et la met en ligne, avec sa base dans le même projet.

  1. Un Dockerfile

    Ton image tourne telle quelle chez nous, à quatre conditions :

    • écouter sur $PORT, en 0.0.0.0 : Arkya pose le port au démarrage ;
    • n’écrire que dans /home/container ou /tmp (100 Mo) : le reste est en lecture seule ;
    • tourner sans root : le conteneur prend l’uid 988, tes fichiers doivent lui être lisibles ;
    • s’arrêter proprement sur SIGTERM : passé 30 secondes, il est coupé.

  2. ark init

    Le CLI crée l’application dans ton projet et écrit arkya.json : son nom, sa taille, et la base qu’elle attend si tu en déclares une.

    {  "app": "site-guilde",  "dockerfile": "Dockerfile",  "size": { "cpu": 1, "ram": 1 },  "services": {    "db": {      "type": "postgres",      "name": "guilde-db",      "size": { "cpu": 1, "ram": 1, "disk": 10 }    }  }}

  3. ark deploy

    Il construit l’image pour linux/amd64, l’envoie sur ton registre privé, la fait analyser, commande la base déclarée si elle manque, puis met l’application en ligne, en HTTPS.

    $ npm install -g @arkyanet/cli$ ark login$ ark deploy$ ark logs site-guilde --follow

Les variables qui pointent vers la base (${guilde-db.HOST}, ${guilde-db.PORT}) et tes secrets se posent sur l’application, dans l’espace client. Avec la version actuelle du CLI, ne mets pas de référence ${…} dans le bloc env du manifeste : ark deploy la refuserait.

Ce qui est inclus.

Tout ce qu’il faut pour qu’une image devienne un service en ligne, sans option à cocher ni supplément.

  • Un registre privé

    Tes images vont sur registry.arkya.gg, dans un espace à toi. ark login y connecte Docker, et chaque version poussée y reste.

  • Des images analysées

    Chaque version passe à l’analyse de sécurité (Trivy). Une faille qui permet de sortir du conteneur bloque la mise en service ; les autres te sont signalées.

  • HTTPS tout de suite

    Ton application répond sur <app>-<ref>.arkya.app, avec un certificat Let’s Encrypt, sans aucun réglage.

  • Ton domaine

    Ajoute app.exemple.fr à l’application, pose un CNAME vers son adresse arkya.app : le certificat suit tout seul.

  • Variables et références

    Tes secrets restent hors du code. ${guilde-db.HOST} et ${guilde-db.PORT} désignent une base du projet et sont résolus au démarrage.

  • Journaux en direct

    Écris sur la sortie standard : ark logs <app> --follow la montre en direct, --build montre la construction. L’espace client affiche les mêmes journaux.

  • Retour à une version

    ark deploy --release <version> remet une version déjà poussée en service, sans reconstruire. L’onglet Versions de l’espace client fait pareil en un clic.

  • Ton équipe, avec ses droits

    Invite des membres sur le projet avec un rôle : Lecteur, Opérateur, Développeur ou Admin. Personne n’a besoin de ton mot de passe.

  • Une API et des jetons

    Tout ce que fait le CLI passe par l’API publique. Un jeton d’API te suffit pour déployer depuis ta CI ou tes scripts.

Avec sa base, dans le même projet.

Une application n’a pas de disque : ses données vont dans une base managée du projet. Elle la joint par le réseau privé, sans adresse à recopier ni port ouvert sur Internet.

  • PostgreSQL, MariaDB ou Redis. Déclare la base dans arkya.json ou crée-la depuis l’espace client, dans le même projet.
  • Une référence plutôt qu’une adresse. ${guilde-db.HOST} suit la base, même si son hôte change. Rien à recopier, rien à mettre à jour.
  • Rien d’ouvert sur Internet. L’application parle à sa base par le réseau privé du projet ; personne d’autre ne la joint.
Découvrir les bases de données
site-guilde
Application, 1 vCPU, 1 Go
${guilde-db.HOST}:${guilde-db.PORT}
guilde-db
PostgreSQL 16, 1 vCPU, 1 Go, 10 Go

Ce que coûte ton application.

Processeur et mémoire se paient à la minute, au tarif du cluster. Une application n’a pas de disque : éteinte, elle ne paie plus rien.

De 1 vCPU à 8 vCPU, de 1 Go à 16 Go de mémoire, réglables quand tu veux.

Prix TTC pour un mois de 30 jours allumé en continu, débités de ton solde prépayé. Une base du projet se paie à part : elle garde son disque, même éteinte.

Allumée tout le mois
1,50 €soit 0,21 ct/h
Éteinte tout le mois
0 €pas de disque, rien à payer
Déployer mon application

Ce qu’une application n’est pas.

Mieux vaut le savoir avant de pousser ton image. La première limite est la plus importante : rien de ce qu’elle écrit sur place ne survit.

Il te faut une machine ? Voir les VPS
  • Pas de disque persistant. Le système de fichiers repart de l’image à chaque déploiement et à chaque redémarrage. Comptes, fichiers téléversés, sessions : ce qui doit rester va dans une base ou un stockage externe.
  • Pas de construction depuis Git. Tu pousses une image Docker, construite par ark build sur ton poste ou dans ta CI. Pas de buildpack ni de branche surveillée.
  • Pas de root. Le conteneur tourne avec l’uid 988 sur une racine en lecture seule ; ce qui demande root (paquets, /etc) se fait à la construction de l’image.
  • Pas une machine à administrer. Ni SSH, ni systemd, ni tâche planifiée sur l’hôte. Pour un Linux à toi, en root, prends plutôt un VPS.
  • Un seul exemplaire. Ton application tourne en une instance, que tu agrandis en processeur et en mémoire. Pas de mise à l’échelle horizontale automatique.

Ce que tu peux y mettre.

Tout ce qui tient dans une image et garde ses données ailleurs. Quatre cas courants, et ce qu’il faut y surveiller.

  • Un bot Discord

    discord.js, discord.py

    Une image Alpine avec Node ou Python, le jeton du bot dans les variables. Il n’a pas besoin de répondre sur son adresse : il lui suffit de tourner.

  • Une API

    FastAPI, Express

    Uvicorn ou Node écoutent sur 0.0.0.0:$PORT. La base PostgreSQL du projet se joint par sa référence, sans adresse en dur.

  • Un site Next.js

    sortie standalone

    Construis en output: "standalone", pose HOSTNAME=0.0.0.0 et lance node server.js : il lit $PORT. Ce qu’il écrit hors de /tmp et /home/container échoue.

  • Un back-office PHP

    php-cli Alpine

    Le serveur intégré (php -S 0.0.0.0:$PORT) suffit pour un outil interne ; Apache, lui, veut écrire dans /var/run. Les sessions vont dans /tmp ou en base.

Les quatre règles en détail, un Dockerfile complet et les pannes courantes sont dans le guide Dockerfile de la documentation, à côté de la référence du CLI ark.

Questions sur les applications.

Faut-il savoir Docker ?

Un peu. Il te faut un Dockerfile qui construit ton application ; ark build s’occupe du reste, de l’architecture à l’envoi au registre. Si ton projet n’en a pas, le guide Dockerfile de la documentation part d’un exemple qui marche, et la plupart des frameworks publient leur modèle.

Où vont mes fichiers ?

Nulle part de durable : une application n’a pas de disque. /home/container et /tmp (100 Mo) servent à écrire pendant qu’elle tourne, et repartent vides à chaque déploiement. Les données qui comptent vont dans une base du projet ou dans un stockage externe.

Puis-je utiliser mon domaine ?

Oui. Ajoute-le sur l’application, puis pose chez ton registraire un CNAME vers son adresse arkya.app, sans proxy devant. Le certificat HTTPS est émis dès que le DNS pointe chez nous.

Comment revenir à la version d’avant ?

Toutes les versions poussées restent disponibles. ark deploy --release <version> remet l’ancienne en service sans reconstruire, en une trentaine de secondes ; l’onglet Versions de l’espace client fait la même chose en un clic.

Quelles images sont refusées ?

Celles qui embarquent une faille permettant de sortir du conteneur : elles menacent aussi les autres clients, l’analyse les bloque. Les images Debian complètes (node:22, php:8.3-cli) tombent souvent dans ce cas à cause de linux-libc-dev ; une base Alpine ou -slim passe. Les autres failles te sont signalées sans bloquer.

Puis-je déployer depuis GitHub Actions ?

Oui. Dans le job, installe @arkyanet/cli, passe un jeton d’API par la variable ARKYA_TOKEN, lance ark login puis ark deploy --yes --demarrage-immediat --tag <commit>. Le nom de version vaut alors le commit, et le retour arrière reste un ark deploy --release. --demarrage-immediat ne sert qu’à la création d’un service payant : sans terminal, c’est ainsi que tu demandes qu’il démarre tout de suite.

Puis-je déployer depuis Git, sans image ?

Non. Arkya ne construit pas depuis ton dépôt : tu pousses une image, construite par ark build sur ton poste ou dans ta CI. Ce qui tourne est exactement ce que tu as construit.

Que coûte une application éteinte ?

Rien. Éteinte, elle ne paie ni processeur ni mémoire, et elle n’a ni disque ni sauvegarde. Si elle a une base, la base continue de payer son disque, et ses sauvegardes au-delà de 10 Go offerts.

Le reste de ton projet.

Ta prochaine mise en ligne tient en une commande.

Installe le CLI avec npm install -g @arkyanet/cli, connecte ton compte avec ark login, puis lance ark deploy.

Déployer mon applicationLui ajouter une base