-
Notifications
You must be signed in to change notification settings - Fork 30
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
WIP: One compose to rule them all #150
Conversation
Codecov Report
@@ Coverage Diff @@
## main #150 +/- ##
=======================================
Coverage 90.97% 90.97%
=======================================
Files 28 28
Lines 432 432
Branches 32 32
=======================================
Hits 393 393
Misses 29 29
Partials 10 10 Continue to review full report at Codecov.
|
Bruno told me that you guys had separate SPA/Backend before but decided to merge it. I think it would not be possible to launch backend separate from SPA or vice versa with this approach. It would still be possible to have docker compose that runs everything at once, but without the |
Yes we merged them a while ago and now the API serves the SPA in prod. If running in For purpose of documentation, the reason why we merged them was mainly because the deployment process was not nice and since the API is pretty much tailored for the front-end, doesn't make much sense to have them separated. Now with one docker image we have both running and publishing a new version to Prod is just fetching the new image. I think your initial idea makes sense to improve the contributing experience:
if we do this, I think it already improves things because:
The CI build was done in this way (copy files) mainly because the .Web project expects the |
I would still have the individual docker files, like you did, but I would keep the CI build and the |
|
||
COPY --from=build /app/dist /usr/share/nginx/html | ||
|
||
ENTRYPOINT ["nginx", "-g", "daemon off;"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is just for local development, couldn't we just use ng serve
as the entrypoint and use the Angular dev server instead of nginx?
|
||
COPY --from=build /src/NuGetTrends.Web/artifacts ./ | ||
|
||
ENTRYPOINT ["dotnet", "NuGetTrends.Web.dll"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Like I mentioned in the comments, this docker file is used to produce our image that we use for deployment. I guess now it's broken since we don't have the dist
folder present here. I don't think it's that problematic that the files are copied. dotnet publish
does not include the node_modules
folder already, so maybe we could also enhance it to exclude the rest if we want to be optimal.
Edit: I just tested and dotnet publish
only includes the dist
folder, so we are good.
@@ -0,0 +1 @@ | |||
& docker compose up rabbitmq postgres pgadmin web --build |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be nice to also have the same in bash scripts :)
@@ -1,5 +0,0 @@ | |||
FROM mcr.microsoft.com/dotnet/aspnet:5.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would keep this so our deployment/CI process doesn't change.
Just noting here that I didn't really have time to spend on it this week, will come back to it a bit later~ |
What's the status of this PR? It has been there for a while. |
I completely forgot what I was doing 😅 |
This PR still makes sense although it's not complete. @Tyrrrz Btw, I notice you are also a MVP. Maybe you can join .NET foundation although it's somewhat in mess so far. We need hands to make it better. |
It can be reopened if someone wishes to continue, but I feel like it'd be easier to start over and maybe copy things over from here.
Thanks, but I have no faith nor interest in .NET foundation 🙂 |
Moved dockerfiles to root because:
Also I noticed that the existing dockerfile in NuGetTrends.Web didn't actually build the project but merely copied the publish output produced by
dotnet
. This works for CI, but makes local development harder. So I integrated the build process inside the dockerfile.Because
/Portal
is inside/NuGetTrends.Web
, I did some naive filtering to avoid copying unnecessary files into the image. Long term this could be improved with adockerignore
file. Also, I would suggest to move the frontend project to a separate top level directory next to/NuGetTrends.Web
and others.Update: just realized that you're serving the angular project from asp.net core. This might make it difficult to separate the two services. I have never used this approach so I'm not really sure what's the best solution in this case.
So far, I got the angular project running, but backend fails with 500 most likely because it can't serve the spa. What do you say about divorcing the two services and keeping them entirely separate? This would allow you to host them separately as well, making use of CDN on frontend with platforms like Netlify and Vercel.
Closes #147