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

Add sample of container with persistent volume mount #52

Merged
merged 3 commits into from
Nov 30, 2023

Conversation

DamianEdwards
Copy link
Member

Fixes #44

Comment on lines 4 to 8
var sqlpassword = builder.Configuration["sqlpassword"] ??
throw new InvalidOperationException("""
A password for the local SQL Server container is not configured.
Add one to the AppHost project's user secrets with the key 'sqlpassword', e.g. dotnet user-secrets set sqlpassword <password>
""");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is to workaround our bug? Why not generate one?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you generate one each time, then the user created during the first run can't be logged in to during the subsequent runs. At least, that's what I saw.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mitchdenny does this align with your expectations of the SQL Server container?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is to workaround our bug?

But yes, in preview.1 you have to work around our bug of the generated passwords not meeting the complexity requirements. I had this originally doing Guid.NewGuid().ToString() but found that I'd get database login errors on runs subsequent to the one the migrations are applied to.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You know to get around the persistent password problem (generically) we could look at capturing and storing the generated password so that it is reused on subsequent executions of the AppHost. That way folks wouldn't need to worry about doing these config shenanigans (unless they really want to).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea. I can see one challenge being that the logical place to store it would be user secrets but that requires mutating the AppHost project (it requires a property to be set to set the user secrets ID), and mutating the project file automatically while the app is running is probably not a great idea.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mitchdenny
Copy link
Member

I like this. It's a good approach to solving the persistent container issue.

@DamianEdwards DamianEdwards merged commit e33643e into main Nov 30, 2023
@DamianEdwards DamianEdwards deleted the damianedwards/sql-volume-mount branch November 30, 2023 18:25
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

Successfully merging this pull request may close these issues.

Using a SQL Container with a Volume
3 participants