Java Deploy process

Application artefact

When the build phase is finished, the application artefact is stored in the internal Zerops storage and the build container is deleted.

If you triggered the deploy pipeline manually using Zerops CLI, the application artefact is also uploaded to the internal Zerops storage.

Zerops uses the stored artefact to deploy the identical version of your application each time a new container is started:

• when a new application version is deployed
• when the application scales horizontally
• when a runtime container fails and a new container is started automatically

First deploy

When your application is deployed for the first time, Zerops will start one or more runtime containers based on the service auto scaling settings.

Zerops performs following actions for each new container:

1. Installs the runtime environment
2. Downloads the application artefact from the internal storage
3. Optionally runs the init commands
4. Starts your application using the start command
5. Optionally waits until the readiness check succeeds
6. The container is now active and receives incoming requests.

Services with multiple containers are deployed in parallel.

Info

If your application needs to be initialized in each runtime container, add init commands to zerops.yml.

Caution

Do not use the initCommands for customising your runtime environment. See how to customise the runtime environment.

Further deploys

When a previous version of your application is already running, Zerops will start new containers. The count of new containers will be the same as the count of existing containers.

Zerops performs the identical actions for each new container as the first deployment. When all new containers are started your service contains both new and old versions for a short period of time.

The old containers are then removed from the project balancer so they don't receive new requests. The Java process inside each of the old containers is terminated and all old containers are gradually deleted.

Readiness checks

If your application isn't ready to handle requests right after it is started via the start command, configure a readiness check in your zerops.yml.

If the readiness check is defined, Zerops will:

1. Start your application
2. Perform a readiness check
3. If the readiness check fails, wait 5 seconds and repeat step 2.
4. If the readiness check succeeds, set the container as active.

Application in the runtime container with a pending readiness check won't receive any incoming requests. Only active containers receive incoming requests to your Java service.

If the readiness check is still failing after 5 minutes, the specific runtime container is marked as failed and Zerops will delete it, create a new runtime container and perform the deploy.

The httpGet readiness check is successful when the URL returns HTTP status code 2xx. The timeout is 5 seconds. When the URL returns a 3xx HTTP status, the readiness check HTTP client will follow the redirect.

The exec.command readiness check is successful when the command returns status code 0. The timeout is 5 seconds.

Read the runtime log to troubleshoot failed readiness checks.

Application versions

Zerops keeps 10 last versions of your application in the internal storage.

The list of application versions is available in Zerops GUI. Go to the service detail and choose Service dashboard & runtime containers from the left menu. The active version is highlighted, show all archived version by clicking on the button below.

The pipeline detail is accessible from the additional menu. The pipeline detail contains

• The pipeline config (zerops.yml) that was used for the selected version
• The build log (if available)
• The prepare runtime log (if available)

You can download the build artefact of the selected version or delete an inactive version manually.

Restore an archived version

You can restore an archived version by choosing the Activate item from the additional menu. Zerops will deploy the selected version and the active version will be archived.

The environment variables will be restored to the latest moment when the selected version was active.