Add to Qovery CLI the ability to run an ephemeral pod

Feature requests & Improvements
,
1

Hello there, I have a general question about the Qovery CLI and I couldn’t find a similar question having already been asked here.

So here I go: My need is that I sometimes woud like to spawn a new ephemeral pod (similar to kubectl run -it --rm IMAGE -- bash) where I can spawn an interactive shell to. The reason for that is that sometimes, I would like some maintenance tasks like rollback a specific migration that does not include breaking changes, repair some data or inspect our NestJS App.

I’m aware that that the Qovery CLI allows to hook into a running pod via qovery shell but due to memory restrictions spawning a NestJS REPL or a migration task instantly kills my task before I can interact with it/it runs.

2

Hi @pantajoe ,

We don’t provide a built-in way to spin up an app/container inside an environment but what you could do is a shell wrapper to do it easily.

#!/bin/bash

# Replace these with your actual Application IDs
SOURCE_APP_ID="your_source_app_id"
CLONE_APP_ID="your_clone_app_id"

# Clone the application
qovery application clone -n $SOURCE_APP_ID --target-application-name $CLONE_APP_ID

# Deploy the cloned application and wait for end of deployment with -w
qovery application deploy $CLONE_APP_ID -w

echo "Application is running. Connecting to shell..."

# Connect to the shell of the cloned application
qovery shell -n $CLONE_APP_ID

# Once exited from qovery shell, delete the cloned application
echo "Exiting shell. Deleting the cloned application..."
qovery application delete $CLONE_APP_ID -w

echo "Ephemeral application deleted."

I didn’t test this script but it shows you that it’s basically possible :slight_smile: We can also think to add a built-in capability if needed.

3

Thanks for the answer! But won’t this really deploy another app that consumes the same amount of memory in the new pod?
So then when I’d try to execute my commands, they’d be run in the same pod where I again have limited memory resources.

Yeah, a new command in the CLI would be great that truly just spins up a “crashed” or “empty” container that we can hook into with an interactive shell :+1:

1 Like
4

From this script you could adapt the behaviour and change the memory settings of your ephemeral app if you need.

We could add a command that brings you the ability to update the memory (and CPU if needed) of your app. Something like:

qovery application settings —memory 4096 —cpu 2000

Then you can add this command inside the script and make sure you allocate enough resource.

—

The reason why I’m push to create your own script here is that you can really tailor the experience to what you expect. For instance, if you also need to change some environment variables it’s possible… and so on and so fourth :slight_smile:

Romaric.

1 Like
5

That’s a good suggestion. If I may add onto this, It would be even better IMO, if it was just one command that would enable you to do so. Something like:

qovery task run  \
  --organization $ORGANIZATION \
  --project $PROJECT \
  --application-name web \
  --memory 2048 \
  --cpu 1024 \
  --env "FOO=BAR,A=B,..." \
  --entrypoint "/bin/bash"
  --interactive

In the background it could chain all of those separate commands that you mentioned (clone, start, update the settings, entrpoint, env, etc.) and then eventually qovery shell.

But to get started, a command like you suggested where one can update the settings memory, cpu, entrypoint and command would be definitely great!

6

Just another thought: This could also allow users to perform non-interactive one-off tasks that are not lifecycle or cron jobs in any form. (e.g., seeding additional data, perform one specific script, enqueueing one job every once in a while, etc.)

Building on top of the example with an interactive task, this could also look like this:

qovery task run  \
 --organization $ORGANIZATION \
 --project $PROJECT \
 --application-name web \
 --memory 2048 \
 --cpu 1024 \
 --env "FOO=BAR,A=B,..." \
 --entrypoint "/bin/bash"
 --command "pnpm run db:seed"

After the command has successfully completed (or not), the temporary pod would be destroyed as with an interactive task.

1 Like