Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Guard against billing surprises - DatabaseMigrations sample #300

Open
collinbarrett opened this issue Jun 2, 2024 · 6 comments
Open

Guard against billing surprises - DatabaseMigrations sample #300

collinbarrett opened this issue Jun 2, 2024 · 6 comments

Comments

@collinbarrett
Copy link

collinbarrett commented Jun 2, 2024

The DatabaseMigrations sample is working great for me in local development. However, by default, it's included when I azd up. The MigrationService seems to get deployed as an Azure Container App 'App' type rather than 'Job' type (docs), so Container Apps continually reboots it even if the migration completes successfully.

I discovered this when I looked at my Azure SQL Database free offer quota. Stopping the MigrationService container in Azure Portal caused the inflection in this chart of a db for an app still under development (no usage expected other than when I'm working on it).
image

Does Aspire have tooling to provision a 'Job' type yet?

If not, maybe we update this sample to prevent surprises? Something like the below here?

if (builder.ExecutionContext.IsRunMode) {
    builder.AddProject<Projects.DatabaseMigrations_MigrationService>("migration")
           .WithReference(db1);
}
@DamianEdwards
Copy link
Member

DamianEdwards commented Aug 6, 2024

I think the point of the sample is to have the migration app deployed though, so that it can be responsible for running migrations in the published environment too. Adding @JamesNK and @AndriySvyryd who worked on that sample.

One approach might be to model the migrations app as a web app rather than a worker, so that it doesn't shutdown after the migration is run. This is the approach taken in the AspireShop sample.

@JamesNK
Copy link
Member

JamesNK commented Aug 7, 2024

The intent of the migration app is it starts, runs any data migration, then shuts down to release resources. This is how it works in local development. That seems like the best behavior to have in ACA (or k8s)

ACA restarts the container when the app exits? Can a job be a container?

Perhaps Aspire need metadata to say that an app is job. Or metadata would be more generic and just say that the deployment environment shouldn't attempt to restart it after it exits. That metadata would then flow through to deployment.

@collinbarrett
Copy link
Author

Right, on deploy to Azure, having it run once and exit until the next artifact change sounds good to me.

The issue is by default it was deploying as an "App" type which auto-restarts if it exits. If we can somehow flip it to "Job" type, I think that might be a better fit. See these docs.

@DamianEdwards
Copy link
Member

FYI @davidfowl @ellismg @mitchdenny as this relates to tweaking ACA properties for project resources.

@mitchdenny
Copy link
Member

For the samples specifically I think there is a tension between optimizing for education (pulling some code into its own project) and optimizing for cost efficiency (running this code as a background service in a component you are already deploying anyway).

Supporting container jobs in ACA is definitely something we want to do.

@christiannagel
Copy link

I had the same issue with the restart of the initialization services and disabled this service after it was running.

With Azure Container Apps, init containers would be a great match for initialization scenarios such as creating the database:
Add support for Azure Container Apps "init containers"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants