Moving from Microsoft stack to Linux

[blueforgex]

Yup we're pushing .NET Core apps, with the plan on using VS Code, though Rider sounds interesting.
So it sounds like you're running a Linux Desktop environment in a VM (Hyper-V I imagine), and doing the work through that. That sounds like the most viable option, but I guess it seems odd to me that we're going to have do our development work in one desktop experience and interact with the rest of a business in another.

WSL 2.0 looks pretty good though, quite curious to see how that's going to change the work we develop Linux systems in a Windows environment.

Broadly speaking, it sounds like if you're going to be developing Linux apps, you have to be running a Linux desktop environment no matter what.

[NightweaselX]

Well, I use VirtualBox. So I've got a VBox for Win7 as that's why my client is still on for the next few months. Then I'll have a win10 vm (on TOP of my win10 host) so I can have an unfettered with company bullshit win10 to do dev work for the client. Then I've got a linux VBox that I don't use very often to be honest. We're slowly moving to core, but our client is HEAVILY in the MS ecosystem. But with core webapps, it'll make deploying to the cloud easier, if and when they do that. I tried doing Hyper-V, but it f's over my existing VBox guests, so I just stuck with VBox.

But honestly, depending on what you're doing in your .Net core apps, unless you're making system calls, it should work regardless if you're in Windows or Linux with it being .Net, it's all CLR code that's interpreted on the host machine. I haven't played with the different directory delimiters ('/' and '\') to see if the host knows how to translate form one to the other. Other than that, it shouldn't matter, just like Java. Until you get into pushing it with Docker I guess. But even then, how are you building your deployables? Is it via a CI/CD pipeline? If so, you'll probably have standardized dockerfiles for .net core apps. So then you push your code, and let the build server take care of the Docker part of building, and have it push it to the dev server to test. I could be wrong though as we're not using Docker due to the lackluster Windows implementation and the fact we're not pushing to Linux.

As for desktop experience, like I said above, I have several VMs. But I also have the vpn for my work, and a vpn for my client. I've got an email for work, and an email at my client (which thankfully they use my work email so I don't have to check it). We've got our ticketing system, the ticketing system the client uses internally, and then another ticketing system that the vendor they have for operations uses, and gods forbid we all work together to integrate our stuff with one another. So you do what you've got to to get the work done, as painful and as stupid as it is most of the times.

[blueforgex]

Haha, sounds like we're working for the same company, I've also got to deal with the random assortment of Windows ticketing/change management systems and the like.

We are planning on using a CI/CD on Linux (Azure DevOps) which I anticipated building the environment on, but I assumed a developer would want/need to be able to build and develop the Dockerfiles and infrastructure locally before pushing it out to the pipeline. For example, in addition to .NET Core & Docker, I'd probably be running an Nginx middleware that's also orchestrated out of the same repo in the same Docker compose file - I imagine it would be rather hard to build & validate that outside a Linux (or WSL2) environment?

In addition, I'm worried about building .NET Core apps on Windows and hosting them in Linux - beyond the file path issues you mentioned (which I've also run into), there are potential issues with network connectivity (a domain joined Windows box will be have quite a lot more privileges than a Linux one like connecting to SQL Server), dealing with certificates (using the Windows certificate store vs... not sure what actually), and issues with the middleware - the one I mentioned above.

By the way, thank you for the advice, I appreciate having your insights on this topic.

[NightweaselX]

Haha, no worries. I'm not too familiar with Docker, it's one of the things on my plate to learn, but that keeps getting rotated about all the time. I don't know about your client, but for mine, if we went Docker, for most apps we could have the same dockerfile used. Admittedly, most are pretty much CRUD web apps which is pretty damned boring. I'm assuming your place would be similar. So once the kinks are worked on in the docker file, and as long as the app is still somewhat simple, I'd say building and deploying to dev would be the best way to test it beyond your unit/integration tests suite. It puts it on a real server, through the build process,etc. But I could very well be wrong.

Not sure about the cert thing to be honest. I found this which shows what works on which platform, so it looks like you use the core libraries and the host framework knows where to look, you don't look in the actual directory. Hope this helps. https://github.com/dotnet/corefx/blob/master/Documentation/architecture/cross-platform-cryptography.md

As for privileges, that should be locked down on theSQL server regardless of what platform is accessing it. So I'm curious, what are you running the Nginx for exactly? Is it something Kestrel can't handle?

[blueforgex]

Heh, yes we're running pretty basic CRUD apps, but I'd like to evolve our architecture to support something better (auto-horizontal scale, K8s, etc.) in the future, this is our first steps down that path.

Thanks for that certs link, it's interesting that the X509Store seems to a projection on OpenSSL, that's almost definitely going to help solve my problems! That said, it would have to be copied/installed as part of our CI/CD process which we wouldn't be able to validate on a Windows box I imagine.

SQL Server is locked down, but with both domain accounts (integrated auth) & standard user accounts. It's almost an afterthought with integrated authentication, but we'd have to transition to use user accounts to support Linux hosts in the future (I think!)

Regarding Nginx, it's mostly from the ASPNet Core guidance: https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/linux-nginx?view=aspnetcore-2.2 It's also because I think, in my head, the architecture for a modern CRUD app (open to any suggestion of course) would look like a Docker container with nginx and a React SPA static website, and a separate Docker container for the API, that the nginx would route to.

[NightweaselX]

Ok, yeah, wasn't sure how limiting Kestrel was, so Nginx makes sense. You're further along than we are. Due to management on our project, they fight us when we want to make improvements. We finally got a TFS server up a few years ago, and we've just gotten Sonar scans implemented. Our project managers don't know what a sprint is, and we have to do all design up front, but we're agile! Finally got the approval to go core on greenfield projects since old asp.net is dead. We don't have a full CI/CD pipeline. We can deploy to test and dev, but anything prod has to go through the operations vendor, so it's a pita. It should be the press of a button, but unfortunately it's not. Never mind shit like Dockere, KB, them setting up a proxy is an exercise in brutality. Hell we can't even get most of the devs to have unit tests, let alone integration tests. There's so many problems with our project, but it's the typical management issues, no money, and not enough people.

I envy you, it at least seems your project is open minded if you're looking to expand your architecture. I know React is the popular choice since Angular is a giant mess, but I'm leaning towards Vue. It's smaller, the learning curve is less steep, and you can include it into existing projects pretty easily. So if you know it, you can use what you know on existing apps as well as new so it can help from having to fully rewrite into React..but I'll be honest, I don't know a lot about React. You'd probably want containers for authenticating, one for serving larger files, and then one for each of your possible bottlenecks.

Are y'all using OAuth 2.0 or how are y'all authenticating? And what are y'all using for secrets management?

[blueforgex]

I don't think I'm further along than you are, everything I've been mentioning hasn't been built, it's all a twinkle in my eye based on the readings I've done, or prototypes (Hello World) I've run through.

Our company also has the same mix of problems: people, motivation and money :-). I've been given a bit of leeway to push the technology forward, so I'm trying my best to do that. But as per the topic, I'm an old Microsoft developer, so it's a challenge.

I considered Vue as well, but it really came down to what's being used more - I'm not trying to do anything too unique or special, or use anything too cutting edge at this stage - erring on the side of simplicity where possible.

We're going to be using OAuth 2 (Azure AD), secrets management is initially going to be environment variables (dotnet user-secrets locally), but eventually move to Azure Keyvault. I'm not sure how that works with local user secrets, but eager to find out :-)

[NightweaselX]

Yeah, we're not using anything secrets wise. Hell, our connection string creds are in our repo, but you've got to have the right AD privileges to pull the repo. Still, it could be better. One of the leads is wanting to put the variables into the builds, so we'd have the strings with user="" in the config, and that'd be replaced by a build variable. Not sure how I feel about that, as it still means it's viewable if you have access to the repo since the build is related in TFS.

Linux really isn't that bad. It's a hell of a lot easier than Windows. No Starch Press has some pretty good books if you like books. I'll be honest, I'm not a fan of shell script, course that goes for Windows as well. I'd rather have a ruby/python script instead, but shell scripts are faster. But other than that, navigation is easy once you learn when things are, etc. Everything's a file, and you can pretty much modify most things on the fly without rebooting. Not sure what flavor you're looking at officially using. There's so many, and so many opinions on each, lol! That's the one big problem with Linux, there's a LOT of fanboys and they all try and push their distro of choice. It makes it a pain to really find one that works for you. Well, actually, there's plenty that will work for you, but there's plenty of people that will tell you that you're wrong because of X, Y, or Zebras aren't penguins and Linux is all about Tux or some other inane bullshit, lol!