Self-hosted .net Core + docker baby steps

Apologies for the n00b question, but after years of successfully running self-hosted ServiceStack apps from the 3.x days, I’m trying to jump into hosting SS aps using docker, and I’ll admit to being relatively new to hands-on with docker.

Here’s where I’m currently stuck:
:white_check_mark: create from template, edit and can successfully run the .net core self-host & scripts sample apps
:white_check_mark: can build docker image (using the nice VS Code plugin)
:white_check_mark: noticed that the VS Code docker plugin does not easily support adding -p flags for the API ports… so using VS Code terminal window to run: docker run -dp 5001:5001 selfhosted:latest
:white_check_mark: runs, no errors. Shows up as running in the Windows Docker app
:x: fails when trying to go to https://localhost:5001/hello/test in the browser.

Any advice on what I might be doing wrong, or thoughts as to why I can’t access the API? Was kinda hoping for a hello-world docker kickstart rather than the rather lengthy Travis/ECS guide.

According to this Tutorial: Get started with Docker apps in Visual Studio Code, that’s the last step.

Appreciate it, thanks!

Hi @sirthomas,

The default container port when built using docker build is port 80 since it is using dotnet publish in the Docker build process itself. So your run command will need to be slightly modified.

docker run -dp 5001:80 selfhosted:latest

This will bind the host (your local machine) port of 5001 to the container port of 80, so you still navigate to http://localhost:5001/metadata.

Hope that helps.

Thanks @layoric, that seemed to get me over that first hump; however, with the added twist of making sure not to use https. That said, I’m a little perplexed as to why that is, considering the launch settings specify "applicationUrl": "https://localhost:5001/". I’m more accustomed to the previous .ListenOn(...) call that supported wildcards to bind to all IPs.

Next step - manually deploying to AWS ECS.

ps: as a curious aside, I copied the bin output folder to try running it in console on a Windows EC2, and that works via localhost, yet despite setting the port rules in the security group & local firewall I cannot access the API via the elastic IP (which itself is fine as I use that EC2 for MQ & other services). Thoughts?
[update] I found the trick for binding to all interfaces: app.Urls.Add("http://*:5001"); as seen here: WebApplicationBuilder in Minimal API apps

The launchSettings.json is to do with dotnet run Development configurations where as once the application has been published (dotnet publish) this isn’t used.

When you are using AWS ECS, your Task Definition file is analogous to a docker run command or docker compose yml configuration file, it is just proprietary to AWS ECS. If you are going to be using Docker more widely than just AWS ECS, might be best to checkout AWS Docker Compose support to use with ECS deployments.

When your application is deployed and hosted, generally you will use some kind of reverse proxy which will map the host port (the port your container is exposed on the machine running the Docker daemon) to ports 80/443 to a specific domain. In AWS, you would use the Application Load Balancer, or you can run your own NGINX proxy if your application doesn’t need to be horizontally scaled across multiple machines. This will work with ECS managed applications on the one host as long as they share the same Docker network.

If you publish an example to GitHub of what you are building and deploying I can take a look further.

Hope that helps!

ok thanks - looks like I have some homework.

If you publish an example to GitHub of what you are building and deploying I can take a look further.

For now I’ve just been using the sample selfhost & script apps to get some hands-on with dotnetcore, docker and ecs (and lament the simplicity of prev approach :wink: ), as a precursor to a few new Script / API projects I want to get started.

I appreciate the tips. Once I get all the steps done I’ll try to write it up for others.

1 Like

After spending time to manually spin up ECS and figuring out how to get my powershell+aws+docker CLIs to interact, I think I have finally landed on a much more user-friendly approach that I’m going to explore:

Visual Studio ➜ AWS Toolkit ➜ Right-click ➜ Publish to AWS ➜ Elastic Beanstalk

Took some trial & error to get my user profile with the appropriate permissions, but wow, once I got it I must say I’m impressed. Spins up a micro linux EC2 with nginx, security group, elastic IP, and all ready to go for load balancing & scaling configurations as needed.

samplescript_publish-to-aws

2 Likes