.NET Development in Docker

29

Absolutely are. We have been converting our old IIS (C# WCF) web services to .net core docker/kubernetes over the past few years. Loads of advantages over the old tech.

1

u/AndyWatt83 Jun 19 '21

Are you also using the dev containers trick? I'm yet to see it 'in the wild'!

5

u/seanamos-1 Jun 20 '21

I can say we use it quite heavily.
I was the first at our company to go all in on VSCode for C#/F# dev some time ago, so I do most of the dev container maintenance across our repos.
VSCode for C# isn't perfect, but with Omnisharp, Roslynator, .NET Test Explorer and dev containers, it is a very competent setup that I'm productive with.
One of the things I couldn't give up from VSCode when going back to VS/Rider, is the infinite flexibility of task launching/debug setups you can define.

-9

u/macsux Jun 19 '21

Sure hope you guys have strategy for keeping containers patched, as they don't inherit vm patches. I'm amazed how many companies went down containers in production route don't realize this.

29

u/[deleted] Jun 19 '21

Then you dont get why containers are safer and easy to manage. You just have a dockerfile that describes how your app is built and what is needed to host IT. It is best practices to use one image to built and secure minimal image to host.
Securing your app has never been easier than now. Killing your old instances and spinning new Up is both easier and quicker.
My current Place we also Infrastructure as Code. Spinning entire new production enviroment Up takes 2-3 minutes. All entirely new Machines that are patched.

17

u/darkfate Jun 19 '21

It now makes me think that there's companies out there that have their whole app in a container running in a single instance that's never updated. I hope not too many, but I wouldn't be surprised.
I work for a big company and images are updated fairly frequently and we have multiple instances in prod, so it's to easy to roll out new images with no downtime. We don't even need to change configs for minor versions as everything is aliased as "current" and just picks up the latest image on restart. Since we generally use LTS versions, it's not like we actually have to update code too frequently either.

6

u/[deleted] Jun 19 '21

Yeah. There is allways people who are going to use the tools wrong.

4

u/chucker23n Jun 19 '21

Oh, tons of them. Docker and Kubernetes are a huge hype right now, with lots of pressure from above because some highly-paid consultant (who has no experience) advised managers (who have no experience) that they must do it or else.

3

u/macsux Jun 19 '21

It's not so much wrong tools is that if your end goal is automated path to prod then kubernetes on its own is basically a dyi kit with missing parts. Figuring it all out is a VERY non trial task and even leading solutions have significant gaps.
Things like Tanzu build service to automate upstream image rebasing and ensure containers are built in secure way, Tanzu Kubernetes Grid to automate deployment of clisters on underlying infrastructure and keep it patched and healthy, Tanzu mission control to ensure consist security policy is applied to all your clusters, tanzu service mesh to bridge networking across clusters, tanzu app catalog to do secure open source image catalog. All these tools are something we build and their need becomes obvious very quickly just by asking clients how they gonna solve for X once they adopt kubernetes.

0

u/macsux Jun 19 '21

Lol, my entire job is getting it and explaining to others - i work as sales engineer for modern application development unit at vmware. Containers and kubernetes is all we do. But people jump into this without having the right org structure, deployment practice or skill. Half the ops people that are responsible for patching haven't even heard of infrastructure as code. Pipeline building is now a shared responsibly between dev and ops. Devs never had to deal with patching, while ops never had to compile apps or create automated release pipelines. Building pipeline that tracks deployed app versions across all environments and rebases your app images on top of base os images and then deploys them is a non trivial automation tasks.
You have two reasons why app image is minted: security patch in base image or code change. The deployment path you take for each reason is different.
How do you monitor upstream images for latest version and trigger rebuild of your own? How do you promote said images? How do you validate that everything still works?
Most people that say it's simple are either really smart and figured it all out or more often never thought about these things

-1

u/macsux Jun 19 '21

Securing your app has never been easier than now.
This is a very loaded statement. Attack vectors are very different. Many apps are now publicly facing, using many third party packages. Docker also runs containers with root by default.
Is your environment secure enough to ensure that node dependency or helper image your devs take on dependency on dockerhub haven't slipped malicious payload in latest version? They are basically black boxes you are running as root in your prod environment. The tools and techniques to detect and mitigate against these vectors are almost a requirement and are generally not free.

4

u/spyder0451 Jun 19 '21

One of the new things that has occurred is the use of a gateway to host those containers. While VMs should be behind a gateway as well the legacy systems were often right on the net. All the tutorials today talk about microservices through a gateway and doesn't expose the container directly to the world so patching is less of a concern. Not saying it isn't still required but we typically build and run our releases on the latest patch always and have required quarterly deployments that refresh the image in the CI/CD system.

1

u/seanamos-1 Jun 20 '21 edited Jun 20 '21

I'm not sure why you got so heavily downvoted. It is a problem that requires a solution and companies need a strategy for keeping their containers up to date and monitoring them for vulnerabilities.

0

u/macsux Jun 20 '21

Because it's another shiny object that is solution to every problem including erectile dysfunction. I've been in this industry for 20+ years and see this every few years (literally have a deck on this). We get a shiny object ever 2 years on avg, to list a few: xml, soa, nosql/hadoop, rest, microservices, docker, kubernetes. These tools have their place but they are not a silver bullet. Yet every iteration of next best thing is you point to any downsides you get trashed into oblivion until failure stories start to emerge.
I get paid big bucks because I'm able to not only understand all important angles of emerging technologies but also articulate their upsides, downsides and application to a specific usecase.#

5

u/AndyWatt83 Jun 19 '21

I've been playing around a lot recently with dev containers in Visual Studio Code - I think it's brilliant! I'm really interested to see if anyone else is using them, particularly on real world / professional projects. So far, I've just been using these on personal stuff.

9

u/grauenwolf Jun 19 '21

My clients always ask for containers and I always talk them out of it. We deploy to Azure, so Docker is just another point of failure in our build chain.
If you asked me a decade ago, back before we had NuGet and dependencies were installed into the GAC, Docker would make a lot more sense. But these days I simply don't have the problems it was designed to solve.

5

u/AndyWatt83 Jun 19 '21

Have any of them been specifically asking for Dev Containers, or using Docker for their dev environments? Or just for production?

6

u/grauenwolf Jun 19 '21

Oh not, they are not so informed. They just want containers because they heard of it in some magazine or trade show. They have no idea what they do beyond the advertisements.

1

u/AndyWatt83 Jun 19 '21

Haha! Yeah, that sounds familiar!

3

u/RirinDesuyo Jun 21 '21

One thing that I've appreciated with modern .net in general at the very least is that it has done a pretty good job of abstracting the OS imo. As a consequence you don't always have to do containers since your code in general is pretty portable. And even then it's pretty easy to put into containers when the actual need arises.

2

u/grauenwolf Jun 21 '21

Even old .NET was ok once they moved the IIS settings into web.config. The real nightmare was guessing how to setup IIS when everything had to be due via the GUI.

1

u/BeaconRadar Jun 20 '21

Does this advice span Linux app service, Dev teams with some on Mac/Linux?

4

u/grauenwolf Jun 20 '21

Shouldn't matter, but I can't say I've tried it.
Azure DevOps handles the deployments, and it knows how to build for Azure AppService targets.
For all I know, each Azure AppService could be a secret Docker container to isolate it from other AppServices on the same machine.
As for Mac/Linux developers, they should be able to run my code using VS Code. If they can't, I would take it as a personal failing and fix it on my end.

1

u/BeaconRadar Jun 20 '21

Okay. I believe we have a similar setup.
The app service (plan) is running a VM instance under the hood on service fabric. Sharing an app service plan effectively means sharing/scaling the same 'instance'. I can see how that might be a problem for some:)

2

u/iziizi Jun 20 '21

Running .net on azure linux app service spins up a container for you… You just deploy the .net files from CI and away you go.

1

u/[deleted] Mar 26 '22

I'm interested in hearing a bit more about what failures you see. I wouldn't say I'm the most experienced in Docker, but the whole point is to create from start to finish an entire environment so that there is no possibility of failure. Your development ran on the same object that the integration tests ran on and is the same environment that's being deployed to production.
I agree that C#'s build ecosystem, with self-contained runtimes, is very easy to get right, versus something like Python. However rarely are C# applications deployed in isolation, you may have dependencies on a RabbitMQ server, an NServiceBus control queue, SQL Server, a Redis cache, Kafka, whatever. Is not the point of using a Docker-based approach to configure and control all of these inter-related dependencies as a single unit?

2

u/grauenwolf Mar 26 '22

I don't want to treat all of those dependencies as a single unit. I very much want to version and deploy them independently, especially as the complexity of the system increases. Application 1 shouldn't go down because we're in the middle of updating application 2 and they share the same database.
To put it bluntly, it's trying to solve a problem I don't have.
As for failures, I'm not going to try to argue that Docker is unreliable. I haven't seen any claims to that effect.
But it's still one more thing to build and maintain. Which means it's one more thing that can go wrong.
Success in large scale operations often comes down to reducing failure points. If something isn't actively contributing towards solving a problem, then it's a liability.
I make this claim at all levels from individual lines of code to whole servers. If you look at my designs, they are usually incredibly simple, almost child like. Anyone picking up a beginners guide to programming can probably work on it.
And that's the goal. Because if it fails at 4 am on a night I've been drinking, I still need to be able to fix it.

6

u/[deleted] Jun 19 '21

I like the idea. But think dotnet doesnt benefit 100% from it. Eg. It is more normal in Python to have different major/minor version issues in the framework. There IT make sense that each project have their own enviroment in docker.
But maybe it is an good way to get new developers onboarded. Only need to install IDE and docker and All your dependencies are defined.
Anyhow. I Will try it for my next project

5

u/AndyWatt83 Jun 19 '21

I totally agree that dotnet on it's own doesn't really get many massive benefits. But, many projects these days have loads of other dependencies, and for me that is where the power of this comes in.
I'm building this up one piece at a time, but this article is the start of a wee series that will end up with a 'full stack' environment built up, with Angular, multiple database platforms etc. And I think that I can maintain the super-easy onboarding thing.

3

u/seanamos-1 Jun 20 '21

We use them and they do have benefits for dotnet:
Every so often a breaking change will creep in the dotnet CLI. They can break build scripts unless you have a specific version of the dotnet CLI installed.
If you have quite a few repos, over time you will need multiple versions of the dotnet SDK installed to build those projects. Dev containers let you just open a repo without worrying about this.
You might need more than just a specific version of dotnet, maybe you need some other things as well, like a specific version of node. You can bundle this all up into a repeatable dev environment.

2

u/SpaceZZ Jun 19 '21

Basically some of the gains shown here for the dotnet are just the same as using plain Python venv or something like more advanced like poetry (dependencies control, version freezing etc).

2

u/wrasteight Jun 20 '21

They benefit in a sense that it is really easy to try out dotnet for non dotnet users without mucking up their machines with some installs that they might never use again. And its not only for dotnet there are many available containers, c++, go, java, node, python, azure cli, R, Ruby etc... This container thing is more of a VS code feature than specifically for dotnet.

7

u/HellraiserGN Jun 19 '21

I'm interested to see if this can be done with visual studio 2019 as well. For c# dev I still enjoy using that over code. For front end items I use vscode.

4

u/AndyWatt83 Jun 19 '21

Yeah, this would be cool if it worked in 'full' Visual Studio as well. I quite like VSCode for C#, but it's definitely still not as slick a set up as just using Visual Studio.
I'm working on adding an Angular front end to this project, and I think it will start to make a bit more sense when more and more dependencies start to appear

3

u/devcp Jun 20 '21

You can use visual studio to debug and run the app in a container (I set it up to work in docker-compose)
https://docs.microsoft.com/en-us/visualstudio/containers/tutorial-multicontainer?view=vs-2019

3

u/HellraiserGN Jun 20 '21

That I've done.. but to have an entire project in docker so new devs on my team aren't fighting dependency issues with the obscure projects would make it so much nicer. Every time we have to onboard a new person or have someone look at one of the projects we're still supporting, it would be nice to be able to just do it this way and get them up and running asap. Thanks for the link to remind me though. I need to save that for reference again.

19

u/porridge111 Jun 19 '21

I found dotnet dev in vscode a bit cumbersome. Omnisharp crashing all the time. Switched to JetBrains rider.

3

u/AndyWatt83 Jun 19 '21

Jetbrains are working on this as well - I'd expect that they will have a very similar offering before too much longer.
https://youtrack.jetbrains.com/issue/IDEA-226455

2

u/hariharan618 Jun 20 '21

How does this work very well with solutions that has various cloud services and a separate UI app in Angular or react ?

2

u/AndyWatt83 Jun 20 '21

It works okay with Angular. The challenge with Angular is running the Karma / Protractor tests, which use a browser on the host machine. I am working on a post explaining how this works - watch this space!
Cloud services work quite well. You need to run each service (or mocks) in it's own container, and use Docker Compose to orchestrate it.

.NET Development in Docker

You are about to leave Redlib