dotnet / nuget-trends

Check out NuGet packages adoption and what's trending on NuGet.
https://nugettrends.com
MIT License
144 stars 25 forks source link

request: Guide for using published DockerHub images #236

Closed ppittle closed 8 months ago

ppittle commented 10 months ago

I'm experimenting with hosting Nuget-Trends, but rather than building the Web and Scheduler images myself, I was looking to use the ones already published to Docker Hub

Do you have a guide on how to update the existing docker-compose.yml file to include these images?

From what I've tried thus far, the Web container exits immediately with exceptions from Sentry.io unable to parse a Dsn.

This is what I've added to the docker-compose.yml file:

web:
    image: "nugettrends/nugettrends.web:main"   
    restart: "no"
    environment:
      Sentry__Dsn: "http://localhost"
      Serilog__WriteTo__0: ""      
    depends_on:
      - postgres
    ports:
      - "80:80"
      - "443:443"
      - "5000:5000"
      - "5001:5001"
      - "4200:4200"
bruno-garcia commented 8 months ago

From what I've tried thus far, the Web container exits immediately with exceptions from Sentry.io unable to parse a Dsn.

Can you try with "" as Sentry DSN? That should disable Sentry: https://github.com/getsentry/sentry-dotnet/blob/89a50abd8dd37294e548dd53dbef98543fe50069/src/Sentry/Dsn.cs#L63-L64

The value "http://localhost/" is an invalid DSN: https://github.com/getsentry/sentry-dotnet/blob/89a50abd8dd37294e548dd53dbef98543fe50069/src/Sentry/Dsn.cs#L66-L111

Alternatively you can get a DSN for a free account on https://sentry.io/ or host an instance for yourself for free: https://github.com/getsentry/self-hosted/

The images published to Docker Hub is what we're using in production. Publishing an image results in a release with that version.

ppittle commented 8 months ago

Confirmed that resolves the Dsn parse issue!

web:
    image: "nugettrends/nugettrends.web:main"    
    restart: "no"
    environment:
      #ASPNETCORE_ENVIRONMENT: "Development"
      ASPNETCORE_ENVIRONMENT: "Production"
      Sentry__Dsn: ""
      Serilog__WriteTo__0__Args__Dsn: ""
    depends_on:
      - postgres
    ports:
      - "80:80"
      - "443:443"
      - "5000:5000"
      - "5001:5001"
      - "4200:4200"

If I set ASPNETCORE_ENVIRONMENT to Production, the web app terminates after a few seconds with very little in the logs:

>docker logs fffabdcf68f1
Warning: Init was called but no DSN was provided nor located. Sentry SDK will be disabled.
Warning: Init was called but no DSN was provided nor located. Sentry SDK will be disabled.

If I set ASPNETCORE_ENVIRONMENT to Development, the web app errors out at

spa.UseProxyToSpaDevelopmentServer("http://localhost:4200");

Full logs:

  Debug: Logging enabled with ConsoleDiagnosticLogger and min level: Debug
Warning: Init was called but no DSN was provided nor located. Sentry SDK will be disabled.
[18:33:58 INF] Starting.
[18:33:58 WRN] Init was called but no DSN was provided nor located. Sentry SDK will be disabled.
[18:33:58 INF] Now listening on: http://[::]:80
[18:33:58 INF] Application started. Press Ctrl+C to shut down.
[18:33:58 INF] Hosting environment: Development
[18:33:58 INF] Content root path: /App
[18:34:16 INF] Request starting HTTP/1.1 GET http://xxx.xxx.xxx.xxx/ - -
[18:34:16 ERR] Connection id "0HMU8UPBQ48IG", Request id "0HMU8UPBQ48IG:00000001": An unhandled exception was thrown by the application.
System.Net.Http.HttpRequestException: Failed to proxy the request to http://localhost:4200/, because the request to the proxy target failed. Check that the proxy target server is running and accepting requests to http://localhost:4200/.

Looking for at my docker config, do I need to wire up a connection string so the web app can access the postgress db?

And any other thoughts on what I might be missing?

bruno-garcia commented 8 months ago

Warning: Init was called but no DSN was provided nor located. Sentry SDK will be disabled.

The Warning from Sentry can be safely ignored, since Sentry is installed and no DSN was provided it's just telling you that it won't do anything as it's possibly an accident that you left the DSN out. But having a Sentry DSN might help you get this going, since you should get an event in Sentry with more context on what's going on. I don't even have a logging service hooked to NuGet Trends in prod anymore (I had logz.io but wasn't using it and they deleted the account). Sentry vs Logging

If I set ASPNETCORE_ENVIRONMENT to Development, the web app errors out at

I haven't run the containers in Development mode, since locally I run the .NET processes on the IDE or in the CLI dotnet run.

If I set ASPNETCORE_ENVIRONMENT to Production, the web app terminates after a few seconds with very little in the logs:

You can change the logging level in ASP.NET Core to get more info on what's going on. Taking from the Development config:

https://github.com/dotnet/nuget-trends/blob/3b12f722505aca5423e469449549e46ab4986f6c/src/NuGetTrends.Web/appsettings.Development.json#L15-L17

If I got the path right, this can help if set via env var to Docker:

Serilog__MinimumLevel__Default=Debug Serilog__MinimumLevel__Override__Microsoft=Debug Serilog__MinimumLevel__Override__System=Debug

That should give you more on the console at least.

Looking for at my docker config, do I need to wire up a connection string so the web app can access the postgress db?

Definitely, without at least a connection string to connect to Postgres it should crash. This should be very obvious during deployment since it cant' recover from that.

And any other thoughts on what I might be missing?

Here's what I set to get the containers up:

RABBITMQ_ERLANG_COOKIE=someErlangCookie
RABBITMQ_DEFAULT_USER=rabbitmq
RABBITMQ_DEFAULT_PASS=someRabbitMQPassword

POSTGRES_PASSWORD=postgresspassword

ConnectionStrings__NuGetTrends=Username=postgres;Password=postgresspassword;Host=prod-postgres;Port=5432;Database=nugettrends;CommandTimeout=160;Include Error Detail=true;
RabbitMq__Hostname=prod-rabbitmq
RabbitMq__Username=rabbitmq
RabbitMq__Password=yourRabbitMqPassword
bruno-garcia commented 8 months ago

I hope my last reply helped out, if not, feel free to open the issue again.

ppittle commented 7 months ago

Thanks for the details - apologies I didn't get back to you. Will review when I can dedicate some more time to this, and re-open if I have questions.

Thanks again!