Bringing more value to Aspire

[raffaeler]

Hi, I love Aspire for the inner loop, it definitely resolves a number of headaches, anyway I believe it can bring more value.

Working with TLS / certificates is still too hard

In theory, I should not need to work with TLS on localhost during the development. But when you work on authentication-related features, this is a must. The difficulties with Keycloak enforcing HSTS on localhost is a clear example.
The certificates created by dotnet dev-certs are good for a single app, but are not accepted by Python and cannot be used to fully test an authentication scenario with Keycloak as there is the need to validate the handshake with different dns names.
Same pain when deploying a service in a container.

Dockerfile

The AddDockerfile support in Aspire is very useful to validate the settings and the true isolation of a service from the host. Anyway, you cannot use it continuosly as the image is re-created from scratch every time you run Aspire which is very time-consuming.
There is the need to switch from .AddDockerfile to .AddContainer to avoid the continuous re-depoloyment.
This is an interesting example of what you need to prepare the distributed app to the deployment.

OTEL and docker

In the inner loop everything is localhost, but when using a container creted by a Dockerfile, you need to specify .WithEnvironment("OTEL_EXPORTER_OTLP_ENDPOINT", "http://host.docker.internal:port" to make the service contribute to the OpenTelemetry data. By default the addresses is localhost and this makes the OTEL calls fail.
This is another example of the problem you get when going in production.

Prepare to deployment

As for the previous point, I am not arguing that Aspire should enter the business of deployment, but it should smooth the rough edges that we still have when an Aspire distributed application should be deployed.
The Aspirate project is a clear example of the 'piece' needed to do that.
I do not expect Aspire to absorb Aspirate, but IMO it should make it easier to build tools that ease the phases post-development.

• Switching from a docker file to the container image
• Clearly identify the environment variables and the addresses that must/will be changed to deploy the app to production
• Providing a library that can deserialize and consume the manifest using a model.
  For example Aspirate has its own deserializer for the model manifest, but this should be offered by Aspire so that other tools can use it and provide other ways to deploy the solution.

I may have missed other points. I may also have missed some Aspire capabilities resolving one or more of these issues.
In any case I think that the great success of Aspirate is a clear sign that any development in this direction would be welcomed.

Thanks

[raffaeler]

As a side note, I created my own tool to create a pair of certificates: a true CA and a web TLS certificate based on that CA.
This allows me to resolve some issue, but there are still issues depending on the framework/language used in the service.
In fact, Python, Java and .NET have different ways to trust specific certificates.
Aspire could bring more value here, by defining the way to deploy the certificates within the integration (component).

[davidfowl]

Luckily all 3 of these things are on our radar. We'll be using feedback like this to prioritize which gets done in what order.

PS: Are you planning to build custom deployment tooling?

[raffaeler]

HI David, great to hear that.
I just finished building a .NET only tool for the certificates that builds a chain of non-self-signed certs which include localhost and a bunch of fake domains (like *.docker.internal). Basically it replaces the self-signed certificate created with dotnet dev-certs.

Now I am slamming my head on the wall because Aspire forces my projects to listen only to localhost. This makes every diagnostics very complicated.
Ideally, I would love to see my Aspire projects living in a virtual network with a mini-DHCP and mini-DNS to fully simulate the flows that I will have in production.

For the next step I was investigating the possibility to build the CI yaml and this is why I was asking about deserializing the manifest.

I don't want of course put any effort where you already planned something as it would be wasted time.
I expect Aspire makes building any integration tool very straightforward.

[davidfowl]

The AddDockerfile support in Aspire is very useful to validate the settings and the true isolation of a service from the host. Anyway, you cannot use it continuosly as the image is re-created from scratch every time you run Aspire which is very time-consuming.
There is the need to switch from .AddDockerfile to .AddContainer to avoid the continuous re-depoloyment.
This is an interesting example of what you need to prepare the distributed app to the deployment.

FYI @karolz-ms @danegsta

[danegsta]

@raffaeler Aspire 9.0 will add support for persistent containers, which can be re-used across AppHost runs. There are some scenarios where we’ll still rebuild a persistent container (we set a label on the container with a hash of certain configuration values such as environment, image to run, exposed ports, and launch command and check to see if that hash matches on subsequent runs. If it has changed we rebuild the container so that it matches the new configuration.

This feature can be paired with Dockerfile builds, with the caveat that we still run a Dockerfile build to determine if the final image hash has changed, as that contributes to the Aspire configuration hash for persistent containers. Docker uses build caches to speed up subsequent builds if they haven’t materially changed, which should mean rebuilding takes a fraction of the time of a first build. The main thing to look out for if you try the feature out and we seem to still be doing a full build+ replacing the container each run are COPY or ADD commands in the Dockerfile. If the files being copied in have changed between runs, that will invalidate the build cache for the rest of the Dockerfile and result in a new final image hash.

We’re looking forward to feedback on the persistent containers feature as users start trying it out (both when it works as you expect and when it doesn’t).

[raffaeler]

Thank you for the details @danegsta
I am closely following Aspire previews and I was aware of the new great feature even if I didn't stressed it yet.

From the development perspective the AddDockerfile is a pure development feature which, before or later, will consolidate to an image with a specific tag.
Said that, having two extension methods forces the dev to comment/uncomment one or the other in the AppHost. The discriminant between the two should instead be a trigger which decides whether the image should be rebuilt or not.

In other words, I would merge the two extension methods to a single one where the dockerfile (if specified), is just the recipe to cook a new image when the trigger tell the AppHost to do it.
The trigger could either be a filesystem watch over the project folder (any file change) or something more specific that the developer could specify with the help of a lambda.
In the lambda I would expect to receive the project folder as well as the docker image info, when/if available.
This triggering system could perfectly fit also in the persistent container scenario that you already have implemented.

Does it sounds that bad?

[danegsta]

One idea we’ve been considering for a future update to persistent containers is letting users override the config hash logic to control the specific hash value we generate. By doing so, a user could have fine grained control over exactly when we rebuild/recreate a persistent container.

As for AddDockerfile only being necessary in development, there are some patterns I’ve seen for customizing development vs runtime AppHost behavior that may be a good fit for this problem. You can check the IsRunMode property and conditionally call AddDockerfile only if true. That way when you publish, you’ll use the default image configuration, but in development AddDockerfile will override that config and take precedence.

[raffaeler]

As for AddDockerfile ...

IsModeRun is a partial solution. When you rebuild the manifest, what will you understand from it?

During the development phase you have to play with the dockerfile until it stabilizes run after run. From that moment on, you'll probably stick to the generated image and later on, when you have to deploy, you only need the image.
At the very end, .AddDockerfile and .AddContainer manage the same service which mutates in the binary form depending on whether you have to debug the code or not.

Going further, .AddPythonProject (aka .AddPythonApp in Aspire 9) (and others) and .AddContainer are also the same thing. Most of the time, you certainly want to deploy the python application in a container.

Expanding what I wrote before I would love to have the ability to declare a mutually exclusive depedendency of those resources, based on some trigger. Deployment is just a special trigger which should be clearly identifiable in the manifest as well.

[davidfowl]

On TLS: https://anthonysimmon.com/dotnet-aspire-containers-trust-self-signed-certificates/

[raffaeler]

Thank you David.
FYI I wrote a tool to generate a full chain instead of a self-signed certificate to simulate a real network on the local machine and it works nicely. I replaced the ASP.NET Core self-signed certificate with this chain and VS also accepts the certificate nicely thanks to the custom OID.

I need a full chain to run the local services on localhost but with different DNS names, in order to simulate an oauth exchange with Keycloak and other services.

The problem comes from Aspire that doesn't let me use anything else than localhost when I start the services.
I need instead to run my services on arbitrary dns names (mapped in the hosts file) pointing to localhost.
Any chance to relax this limitation?

Thanks!

[davidfowl]

Any chance to relax this limitation?

Feature needs to be designed, but yes in some 9.x we will enable it.