Le manifeste arkya.json

arkya.json décrit ton application, sa taille et les services dont elle a besoin. ark plan compare au réel, ark deploy applique puis déploie.

arkya.json vit à la racine de ton dépôt. ark init l’écrit, tu le complètes, et il décrit l’état voulu :

arkya.json

{
  "app": "boutique",
  "dockerfile": "Dockerfile",
  "context": ".",
  "project": "Production",
  "size": { "cpu": 1, "ram": 2 },
  "start": "./scripts/start.sh",
  "services": {
    "db": {
      "type": "postgres",
      "size": { "cpu": 1, "ram": 1, "disk": 10 }
    },
    "worker": {
      "type": "app",
      "dockerfile": "Dockerfile.worker",
      "env": { "ROLE": "worker" }
    }
  },
  "env": {
    "LOG_LEVEL": "info"
  }
}

L’application

Champ	Rôle	Par défaut
`app`	le nom de l’application, et de son dépôt d’images : minuscules, chiffres et tirets, 3 à 40 caractères	obligatoire
`dockerfile`	le fichier à construire	`Dockerfile`
`context`	le dossier de construction	`.`
`project`	le projet où ranger l’application et ses services ; créé s’il n’existe pas	ton projet par défaut
`node`	le nœud, par son libellé ; `ark init` l’écrit pour toi	le seul nœud ouvert
`size`	`cpu` et `ram`, en vCPU et en Go, nombres entiers	1 vCPU, 1 Go
`start`	la commande lancée à la place de celle de l’image	celle de l’image
`services`	les autres services à tenir prêts	aucun
`env`	les variables de l’application	aucune

Une application n’a pas de disque : un disk dans sa taille est ignoré, et ark te le signale.

Les services

Chaque entrée de services porte un alias, db ou worker ci-dessus. Le service s’appelle <app>-<alias> chez Arkya, ici boutique-db et boutique-worker, sauf si tu lui donnes un name.

`type`	Ce que c’est	Taille
`postgres`	PostgreSQL 16	`cpu`, `ram`, `disk`
`mysql` ou `mariadb`	MariaDB 11, compatible MySQL	`cpu`, `ram`, `disk`
`redis`	Redis 7	`cpu`, `ram`, `disk`
`app`	une seconde image du même dépôt : un worker, un consommateur de file	`cpu`, `ram`

Sans taille, ark commande une base au plus petit format permis, au moins 1 vCPU, 1 Go de mémoire et 5 Go de disque.

Une seconde image accepte aussi dockerfile, context, start et env. ark deploy la construit et la met en service avec le même nom de version que l’application.

Les variables

env contient des valeurs simples, sans secret : le fichier part dans Git. ark deploy les envoie à chaque déploiement.

Le CLI 0.2.0 ne sait pas encore écrire la connexion à une base dans env : une référence comme ${db.url} fait échouer la mise en service. Pose ces variables dans l’espace client, avec les références décrites dans Variables et références.

Voir avant d’appliquer

Terminal

ark plan

ark plan compare le manifeste à ce qui existe et classe chaque service : à créer, à modifier, commande de démarrage à changer, déjà en place. Chaque ligne porte son prix mensuel, et le total dit ce que tu paieras une fois le manifeste tenu.

Terminal

ark plan --apply

--apply crée et retaille ce qui manque, sans déployer. ark deploy fait la même chose, puis construit, envoie et met en service. Les deux te demandent confirmation, et le démarrage immédiat quand ils créent un service.

Ce que le manifeste ne fait pas

Il ne supprime rien. Retirer un service du fichier ne le détruit pas. La suppression passe par ark rm.
Il ne déplace rien. Le nœud est fixé à la création.
Il ne réduit pas un disque. Le disque d’une base peut grandir, jamais rétrécir.