Deploy: make a version of an app
A version is made every time, of what the call gives and, for what it leaves out, of what the app has; the app's own fields become what the version is made of. The same tag deployed again is another version: the tag may name another image by then. The version is built on the app's nodes and takes the app's traffic when every one of them has it (GET it with wait_seconds to wait for that). Takes write; giving the app a secret it does not have takes admin besides.
https://api.glac.ai/v1/apps/{app}/versionsAutorização
Parâmetros de caminho
Parâmetros de cabeçalho
Corpo da requisiçãoJSONopcional
- volumesoptionalarray | null
What its instances mount, kept with each version made after: volumes of the project's (
POST /v1/volumes), by name or id as written, each looked up when the app is made or changed and when a version is deployed (404volume_not_found). No two at one path. A service with a volume of its own (one that is not shared) is stateful: it has one instance, which has the volume (scale.max_instances1 or null,scale.min_instances0 or 1, nokeys: 400volume_single_instance), on the machine of its volumes, which are on one machine (409volumes_apart). Its versions are built there with the start command held back; the instance is made at the service's address on the project's network, named as the service is (or ashostnamesays), mounts the volumes first (a new one given what the image has there, unlessnocopy), then starts the command and takes connections once it is up asreadysays; every start of it from its disk does the same. It sleeps as any keyed instance does (scale.sleep_after_ms; never with a floor of 1), is woken by a connection on the project's network, and is deleted by its owner alone, or with the app. A version deployed later replaces it: the old one's command is stopped asstopsays, the new one is made with the same volumes at the same address, and the traffic is the new one's when it is up; one that does not come up has the version before made again with the volumes as they were left, and the deploy fails with what the new one said (app.deploy_failed). Not given: none. - drivesoptionalarray | null
The Drives its instance mounts read-write (slice D8), kept with each version made after: Drives of the project's, by name or id as written, each looked up when the app is made or changed and when a version is deployed (404
drive_not_found; a volume of another kind is none). A service with a Drive is stateful, as one with a volume of its own is (volumes): one instance, which has its Drives, made on the node that holds them, or on another of their region they are brought to. A Drive has one writer: an app of many instances (scale.max_instancesother than 1 or null,scale.min_instancesabove 1, orkeys) is refused, 409drive_single_writer; read-only mounts of a Drive's snapshots, which many may have, are a sandbox's (modesnapshot, slice D7) and no app's version mounts one yet, and a keyed app gives each key a Drive of its own (key_drives). No two of its volumes and Drives at one path; an instance mounts 8 Drives and volumes of its own at the most (409too_many_drives). Not given: none. - key_drivesoptionalarray | null
The Drives each key's instance has of its own (slice D8; reports/workers/keyed-upgrade.md, where they were
key_volumes), of a keyed app alone (keys; 400invalid_fieldotherwise), kept with each version made after. A key's Drives are made when its first instance is made, on the node it is made on and in its region, and mounted before its start command runs (its versions are built with the command held back); every instance the key has after (its first deleted idle, or by its id) mounts the same Drives, by their names; an upgrade of its instance to a version that names other ones mounts them by their names too: one the version names that the key has none of is made then, one it no longer names is left off and kept (POST /v1/apps/{app}/instances/{key}/upgrade); they are deleted with the key (DELETE /v1/apps/{app}/instances/{key}) or with the app. A key's Drive is shown inGET /v1/volumeswith itsapp_idandkey, is billed as any Drive, counts toward what the project's Drives hold together and not toward their number, and is not the project's to delete or to mount elsewhere (409key_drive). Not given: none.
Returns
201
The version, building.
- statusstringrequired
building: its template is being built on the app's nodes.ready: every one of them has it; it took the app's traffic then, unless a newer deploy or a rollback had taken the app away from it.failed:errorsays why, and the traffic stayed where it was. A version that is ready isbuildingagain while a rollback to it has it built again (its template had been taken off the nodes:collected_at), andreadyorfailedafter, by how that went. - errorobject | nullrequired
Why it failed. The codes are a node's for a sandbox that fails the same way (
image_not_found: the image is not in its registry, or is not public, which is all a registry that wants a login says to a version that names noimage_pull_secret;image_pull_failed;registry_auth_failed: the registry refused the credentials ofimage_pull_secret, andmessageends with what the registry said, without them;image_unpack_failed,invalid_image,boot_failed: the start command did not come up, andmessagehas what the ready check got and what the start command printed last, in the image's own words), a node's refusal of what the version is made of (invalid_fieldand the like), or the control plane's own:secret_not_foundandsecret_unreadable(a secret the version names is gone, or cannot be read, when a node is asked to build it;messagenames it),invalid_field(the secret ofimage_pull_secretno longer holds a user name and a password),secret_host_not_allowed(the secret ofimage_pull_secretmay no longer go to the image's registry;messagenames it, the registry and where it may go),no_capacity(no machine was there to build it on, or the node had no slot to),drive_full(no machine that could build it had room on its data drive for its template:messageis what the first of them said, how full its drive is; where another had room it was built there),build_failed(a node failed at something of its own), a node's own code where it failed so at the question what the image is, or at the build, three times (internal:messagehas its words, the status it answered and the id of the request, which its log has the reason under),template_differs,runtime_not_supported(a node that is to serve it runs a sandboxd from before runtime settings, and builds nothing without the version'sruntime),deploy_stalled(a machine that is to build it took nothing of it for two minutes:messagehas what it said),deploy_timed_out. - digeststring | nullrequired
The image it is, by its digest (
sha256:...). Of a deployed version, the one its deploy resolved (the digest ofresolved.image), null until then. Of a version of an app of the Sandboxes product (managed_by.objectsandboxes): a naming of the app's image is the image its tag named when the first sandbox of it was made; a tag that is moved later makes another version of the app, under that naming, at the first sandbox of the image it names then. Null until a sandbox of it says, and for the base template's. - collected_atstring | nullrequired
When the version's template was taken off the nodes: the nodes keep the templates of the version that has the app's traffic and of the app's newest versions that are ready (three, the one that has the traffic among them as a rule), and of no other. The version is what it was otherwise, and a rollback to it builds it again first.
nullwhile the nodes keep its template, and again once it has been built again.format: date-time - buildobject | nullrequired
How far the nodes of the version's deploy are with it, as the deploy saw them last: it is kept when the deploy has ended, and is that deploy's from then on (a node that builds the version later, because it was away or is new, changes nothing here). Numbers and a node's words, and no node's name.
nulluntil the deploy has picked the version's nodes (its image is found first), for a version from before deploys kept this, and from the moment a rollback has the version built again until that deploy has picked its nodes.