So I finally got my Angular wrapped in .Net Core 2.2 app working in a Docker Container on a production server.
-
Wow what a trip! Sort of excited that I finally got my app to work in a production environment. Having to learn Docker like real fast, and then really having to understand how .Net Core 2.2 works. What made it worst was wrapping Angular V7 in .Net Core 2.2, making it much more complicated now. And then connecting it to MongoDB running in another container. Working with VS2017 and Docker VS2017 gives you the ability to run your .Net Core 2.2 app in a Docker for Windows container so you can test and debug. But after creating the container, you can't start it again unless you use VS2017 to run it again. What ends up happening is that VS2017 does 1/2 the work in the background and uses the needed components from your shared drive and you can't see it unless you look really close at the output. Now try and use release to build that app and put it in a container, still won't work because your missing the rest of the files needed to run it that are on your shared drive. When you go to peek inside a debug container, it's totally different than a release container. You have to alter your Dockerfile to copy the rest of the files needed to run isolated without a shared drive. Then when you push to Docker Hub you will have everything required. Visual Studio 2017 will program your environment variables, but to run self contained you have to create them in your Dockerfile or docker-compose.yaml file. eg.
DOTNET_RUNNING_IN_CONTAINER=trueVS2017 and Azure: I actually got to the point where I thought that Docker support for VS2017 was locked into Azure, and that they didn't want us to host Docker containers ourselves, but that was not the case. What it boiled down to was going back to basics and building my project by command line to better understand how "dotnet" works and then build the Docker container. Once I understood the relationship between the two, I was able to go back to VS2017 and craft a better Dockerfile, and then compose it. But what works in Docker for Windows is a whole different story in Docker for Linux. So to answer some questions that you may have: Can you host your .Net Core 2.2 app in Docker just using Kestrel - YES Can you program Kestrel to use SSL with an embedded PFX file - YES Can you control Kestrel's ciphers such as TLS, no SSL - YES Do you need a reverse proxy server such as Nginx - NO - so far I haven't had to Will the stock Dockerfile work - NO - You have to modify it to your needs Do the current MongoDB C# V2.8 drivers work with Docker and -
Wow what a trip! Sort of excited that I finally got my app to work in a production environment. Having to learn Docker like real fast, and then really having to understand how .Net Core 2.2 works. What made it worst was wrapping Angular V7 in .Net Core 2.2, making it much more complicated now. And then connecting it to MongoDB running in another container. Working with VS2017 and Docker VS2017 gives you the ability to run your .Net Core 2.2 app in a Docker for Windows container so you can test and debug. But after creating the container, you can't start it again unless you use VS2017 to run it again. What ends up happening is that VS2017 does 1/2 the work in the background and uses the needed components from your shared drive and you can't see it unless you look really close at the output. Now try and use release to build that app and put it in a container, still won't work because your missing the rest of the files needed to run it that are on your shared drive. When you go to peek inside a debug container, it's totally different than a release container. You have to alter your Dockerfile to copy the rest of the files needed to run isolated without a shared drive. Then when you push to Docker Hub you will have everything required. Visual Studio 2017 will program your environment variables, but to run self contained you have to create them in your Dockerfile or docker-compose.yaml file. eg.
DOTNET_RUNNING_IN_CONTAINER=trueVS2017 and Azure: I actually got to the point where I thought that Docker support for VS2017 was locked into Azure, and that they didn't want us to host Docker containers ourselves, but that was not the case. What it boiled down to was going back to basics and building my project by command line to better understand how "dotnet" works and then build the Docker container. Once I understood the relationship between the two, I was able to go back to VS2017 and craft a better Dockerfile, and then compose it. But what works in Docker for Windows is a whole different story in Docker for Linux. So to answer some questions that you may have: Can you host your .Net Core 2.2 app in Docker just using Kestrel - YES Can you program Kestrel to use SSL with an embedded PFX file - YES Can you control Kestrel's ciphers such as TLS, no SSL - YES Do you need a reverse proxy server such as Nginx - NO - so far I haven't had to Will the stock Dockerfile work - NO - You have to modify it to your needs Do the current MongoDB C# V2.8 drivers work with Docker and -
Good idea! But I need to get more knowledgeable about it first. A couple of things back fired on me as I tried to perfect Kestrel to obtain a "A" rating on GMetrix, but I figured it out. As I perfected external HTTP request, I broke the internal HTTP request. And I still have to fix the problem with using the refresh button on the browser which is an Angular or SPA issue not playing nice with .Net Core's routing. I see Microsoft has created a new project template for React/Angular/SPA that seems to have fixed it; and it uses a more native version of Angular for wrapping without using Web Pack. This I'm happy to see because it makes more sense to be able to just create an Angular project and then wrap it in .Net Core. But overall, just getting .Net Core 2.2.4 working in Docker for production use using SSL would be a good place to start. Maybe later this month. The link below is a working example of the project running in Docker using just Kestrel. It's a work in progress, the refresh button may not work, and I'm trying to determine the best way to fix it.
If it ain't broke don't fix it Discover my world at jkirkerx.com