Launch

After receiving the command to launch, the Amverum cloud searches the Code folder for configuration file amverum.yaml. There are three possible situations:

  1. amverum.yaml is missing, but Dockerfile can be found.

  • Starts running the image resulting from building Dockerfile.

  1. amverum.yaml and Dockerfile are both missing.

  • Startup fails.

  1. amverum.yaml is present.

  • Starts running the application.

Startup process with amverum.yaml

build_proc Amverum Cloud reads the meta section of the amverum.yaml configuration file and looks for a suitable launcher in the list of supported environments. A launcher is a ready-made image with programs installed that will allow you to run the application (python, JVM, etc.). The image selected by the configuration is launched in a new container with the parameters specified in the run section of the same configuration.

During the process of creating a container, two folders are mounted into it:

  • artifacts - folder with files obtained as a result of the build process (may be overwritten during rebuilding). Mounting occurs in the /app folder of the running container.

  • data - persistent storage folder, which is not affected by the build process and, therefore, the files remain untouched. To store data obtained during the program’s operation, such as: DB, logs, etc., you must use this folder. Mounting occurs in the /{persistenceMount} folder specified in the configuration (by default, /data).

During the launch process, the application status will be «Starting up», which will change to «Application running» if successful. If the status is «Deployment error» or the project hangs in the «Starting up» status for a long time, you should look for the problem in the run section of the configuration file.

Life cycle

Important

In the first minutes of the application’s operation, the status may be «Application error», since the application has not yet formally started and Amverum cannot clearly determine its exact status.

Amverum strives to ensure uninterrupted operation of the deployed application. If the application terminates for any reason (an exception occurred, the program reached the end), it will be automatically restarted. If an error occurs that prevents the application from running for more than a minute, the application status changes to «Application error», but the cloud continues to try to restart it again and again. If the first deployed application remains in this state for more than half an hour, it will automatically stop and change to the «Stopped due to a repeating error» status.

Important

To prevent application errors, we recommend going to the «Application Log» tab.

Stopping the application

If you need to temporarily stop the project, you can use the «Turn on/off» button or set the desired number of replicas equal to zero on the toolbar. In this case, the data in all folders remains untouched.

If the application is in the disabled status for more than 30 days, it is automatically frozen.

Freezing the application

If you no longer need the application, but you want to save the data in the repository and in persistent storage, you can use the «Freeze project» button in the «Settings» tab.

When freezing, the Artifacts folder is completely cleared, as well as the associated domains. The application goes into the «Frozen» status. To unfreeze, you need to initialize the project build process and set the number of desired replicas to more than zero.

Application log

To monitor the application, you should use the log output console, which is located in the «Application log» tab. Loading logs may take some time and work with a delay.

To load logs, you need to click on the «Load history» button, which is located in the lower right corner of the log window and looks like a dial. load_logs