.NET Core app on Linux VPS with Direct Admin

I recently made the jump from shared to VPS hosting, been putting it off for some time, fearing a steep learning curve and a lot of wasted time setting and maintaining the server. Up until now, I can say that hasn’t been the case though. The fact that I wanted to switch to HTTPS without having to pay for a certificate, and the promise of .NET core working on Linux where the last incentives I needed to bite the bullet and go for it.

The objective was to serve my blog and my .NET project via HTTPS running side by side on the same server. Below you can find the step by step guide on how I got it working.

Step by step installation

My VPS is running CentOS 7 with DirectAdmin on top of it, I bought a license for it to make my life easier and couldn’t be more happy with it. Setting up HTTPS with Let’s Encrypt and everything else needed to run my domains was extremely easy, even for a Linux newbie like me.

The first step to run a .NET Core app on the server was to install the SDK. An alternative is to publish the apps as self-contained packages, which includes the framework needed to run on their deployment. But this means that for each app you publish you are basically copying the entire framework. As I plan on running multiple Core apps it made more sense to just install the framework once and then deploy against the target framework version directly. This makes the deploys lighter and, being the admin of the server, there was nothing stopping me from going ahead with it. Another plus for setting up your own VPS.

It’s very simple to install, you just follow the steps for your OS that Microsoft has documented so well and you are done.

sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc

sudo sh -c 'echo -e "[packages-microsoft-com-prod]\nname=packages-microsoft-com-prod \nbaseurl=https://packages.microsoft.com/yumrepos/microsoft-rhel7.3-prod\nenabled=1\ngpgcheck=1\ngpgkey=https://packages.microsoft.com/keys/microsoft.asc" > /etc/yum.repos.d/dotnetdev.repo'

sudo yum update
sudo yum install libunwind libicu
sudo yum install dotnet-sdk-2.0.0

export PATH=$PATH:$HOME/dotnet

Next step on the list is setting up Apache as a reverse proxy to forward HTTP calls to the Kestrel web server hosting your app. There are some other options, but because I wanted to run .NET Core apps side by side with, say, WordPress I wanted to keep Apache running. So setting up a reverse proxy on the domain I plan to use to host the Core apps made more sense to me. It’s valuable to mention that you can do this on a domain by domain basis, meaning that Apache will work as a reverse proxy only on the domains (or sub-domains for that matter) that you set it up for. The rest of your domains will work as they did before.

To set up the reverse proxy with DA is once more very easy, just follow their guide and done. The advantage of using a control panel like DA I guess. Adding it to the first box is enough, don’t worry too much about the exact placement inside the <VirtualHost> tag.

 

More detailed info, including how to set up a service to run your app, can be found in the docs by Microsoft.

Once you have .NET Core installed and Apache running as a reverse proxy for your app’s domain it’s just a matter of copying your app files to your desired folder and running the app. This can be done via the .NET Core CLI or by setting up a service as mentioned before. If you want to run some quick test, the CLI will do, if on the other hand, you want to run it permanently then the service is the way to go.

dotnet /pathToYourApp/App.dll

Another resource I used was this guide that did something similar with Debian, you may find it useful.

A red sports car is now orbiting the sun

Reality is now one step closer to Ready Player One. Gets you thinking about what’s possible and what’s not. Not so long ago rockets just destroyed themselves, hopefully after a successful mission, but many times before. That was how it was, that was reality. Then a small group of people dreamed otherwise, they imagined a different reality, one in which rockets were no different than planes, one where what happened last week was possible. But this dream was far away, by a lot if you place yourself back then. Rockets didn’t land and rockets didn’t evolve quickly, we were using decades-old technology for a reason. Evolving has an immediate cost, but it also has the great reward of taking you to the next level.

I was hooked almost from the start, being a space nerd, knowing that we walked on the moon once, seeing us rooted on our home planet again was heartbreaking. What happened to the dream? Did we become complacent? But at the same time, I could understand it, space is hard, and rocket science is, well, rocket science. So I accepted it, I accepted once more reality as it was. Lucky for us not everyone was as complacent as me.

The first part I missed, Falcon 1 was like a little bit of history to me, I learn it after the fact. But seeing the first Falcon 9’s fly was a treat, it ignited that dormant dream again, the infinite possibilities of space, truly unimaginably big. The grasshopper was what really hit me though, there it was, a glimpse of the future. The Falcon proved it was possible to challenge the status quo, to fight the big guys. But the grasshopper was the evolution, that Ready Player One stuff. It just was very little then, like a new sprout on a tree, far from being a huge branch, but with the potential to be one.

With my brother we were crazy, rewatching each hop like a magic trick by the best magician of the moment. It was not so much what we saw, but what it meant, if this thing kept going forward it was going to change reality, and boy it did.

These guys are right now building a rocket to colonize another planet. Just thinking about it takes me back to that hopefulness the grasshopper provoked. They proved themselves now, they showed us that they can pull it off. So it’s easy to believe them now, at least for me, but the dream is so big that still is hard to comprehend. That’s why I think having a red roadster floating in space is so handy. There it is, in all it’s absurdity, in all its impossibleness, showing us that yesterday’s reality is not set in stone, today’s reality can make it obsolete.

So get ready mars, we are coming.

My takeaways are:

The importance of setting goals, right from the start the goal of SpaceX was to make humanity interplanetary. This shaped every action they took, they couldn’t just build rockets the same way. They needed to reduce the cost of going to space, thus making reusable rockets was a must. And to accomplish this they needed to evolve quickly and fail fast.

The value of iteration. Taking things step by step, breaking a big problem into little ones so it becomes manageable. The grasshopper is an excellent example of this.