Yaoploy

Describe the desired application completely

An application declaration contains a name, image and replica target, with optional private TCP listening or public HTTP service. Every update supplies the complete declaration; omitting a former field removes that choice. Zero replicas retains the declaration while requesting that execution stop.

The controller durably retains complete declarations and immutable read-only images. Each node agent receives a complete plan, prepares the image in the shared runtime and starts the process. A public HTTP application needs two further checks: it first signals readiness, then Server verifies the current plan, image and session before publishing eligible endpoints to Yaogress.

Start integration with a clear process entry point

An application supplies a complete image with /app/run as its foreground entry point. It runs from /app and must not depend on an interactive shell, implicit environment variables or another daemon to hold its lifecycle. Business configuration and required material are supplied explicitly through the runtime arrangement.

A network application uses the listening socket supplied by the agent and reports readiness only after its dependencies, routes or data have actually initialized. A Worker without a listener performs its work as a process; it does not need an artificial HTTP interface merely to appear in the gateway.

1. Deliver runnable content

   Prepare the entry point, dependencies and configuration relationship. Define normal termination and any business cleanup that must finish before exit.

2. Declare replicas and ingress

   Submit the complete application declaration and select the capabilities actually needed for a Worker, private TCP service or public HTTP service.

3. Report readiness before receiving work

   Use the inherited listener and send one valid notification after initialization of the current process. The controller then checks and synchronizes public ingress.

Converge within current managed membership

A node’s identity comes from the actual IPv4 source of its control connection. Registration must be followed by an admitted assignment subscription before it becomes managed. Heartbeats, the subscription and the current session maintain that relationship. Reentry at the same address retains its node identity but replaces the old session.

Scheduling retains suitable assignments, removes surplus and fills deficits on eligible nodes, with at most one instance of an application on each managed node. A disconnected member can be replaced immediately while its old processes continue. The replica target therefore does not enforce a global execution limit.

Let applications establish readiness

The node agent obtains and verifies a complete image, mounts its read-only application directory and starts the foreground program. Configuration has an explicit directory, materials resolve relative to the application working directory, and output stays on the console. Applications cooperate in a common node runtime with shared root administrator privileges.

Listener applications inherit the actual bound socket, avoiding a probe-and-rebind race. After initialization, the current live child sends one readiness notification and closes its separate pipe. Only the complete notification is valid. Late events from an older process cannot publish its endpoint again.

1. Prepare

   Receive and verify the image, then prepare mounts and inputs.

2. Start

   Bind the actual listener and hand it to the foreground child.

3. Become ready

   Complete application initialization and send the one-shot notification.

4. Supervise

   Withdraw readiness on failure or exit; retry only after settlement.

Keep execution and ingress status distinct

Each public application has one stable service record in the Yaogress gateway, containing its complete hostname rules and current eligible backends. An endpoint must match the current application, image, node session and adopted plan. With no ready backends, the desired ingress state is removal of that service.

A route conflict does not permit a partial hostname or backend publication. Execution and gateway synchronization are reported separately: a process can be ready while ingress remains pending. Complete registry equality still does not establish a successful HTTP request.

Trace a deployment through the same application identity

Start with the image and replica target in the durable declaration, then inspect the current node session and adopted assignment plan, and finally match them to a live child and ingress registration. An application name alone does not connect these facts. Readiness from an old session, image or plan cannot establish the current deployment.

If the process is ready but ingress is not synchronized, inspect conflicts and results for the complete service registration. Once the registration agrees, use an actual HTTP request to check the selected endpoint and application response. Separating these stages avoids restarting an application without evidence when the remaining issue is an ingress conflict.

• Admission condition: a live process is ready under the current plan

  The application, image, node session and adopted plan must all match before the endpoint is eligible for the current public backend set.

• Unsupported guarantee: the replica target is a global execution count

  A process may survive after its disconnected node leaves current management. Business effects requiring exclusion need their own authority or deduplication.

• Check next: registration matches the desired service

  This establishes the registration result. Actual connectivity, request handling and business output still need corresponding observations.

Preserve responsibility through reconnects and replacements

Every child exit, including a normal exit, withdraws readiness and enters supervised retry. Failed cleanup retains the original work and blocks conflicting startup for that application. Losing control connectivity does not establish remote termination. Applications own business authorization, duplicate suppression, exclusive writes and external durable data.

Specified verification uses two identical node environments to check requests through the actual socket, endpoint propagation, child restart, reconnection and controller restart. Declarations and images persist while membership and plans rebuild from new sessions. Applicable experiment records are required to establish those results.