Azure, DevOps, Node.Js, Technical

Hosting personal projects on low cost dedicated servers, not the cloud

For personal projects, the cloud is probably too expensive.

I say this as a person that previously hosted all of their personal projects on the Azure cloud platform. I had multiple app engines inside a single Azure App service, which worked pretty well. The main advantage of running anything in the cloud is that you don’t have to worry about server maintenance, and, if used correctly, can be cheaper for projects over a certain size. I had a few reasons for getting off the cloud:

Restricted Tech stack

Generally, a cloud service will restrict you to running some specific technologies. For example, a specific version of Node.Js. Even if your cloud service supports the technology you want to use, finding out if it supports the version you want to use is not easy. Right now, if you want to know which versions of Node.Js Azure supports, your best place to get that answer is StackOverflow , even though this information should be prominently displayed in the documentation.

The cloud offer is fast moving and hard to keep up with

The offer from cloud service providers changes a lot. I actually had to look back over my previous blog post detailing how I hosted my projects in the cloud to remind myself how it all worked. The problem is more acute on AWS, where the naming is so whacky that someone maintains a page where the names of AWS products are translated into useful plain English.  Elastic Beanstalk, anyone?

There is also a danger of just choosing the wrong cloud product. Like the guy that used Amazon Glacier (real name) storage and ended up racking up a $150 bill for a 60Gb download,

You need to learn the platform and not the technology

The argument put forward by the cloud guys often is that you get to focus on building your app and not deploying it or worrying about the infrastructure. This is absolutely true for a more trivial apps.

However we all know that it is rare for a useful application to be this flat. If you want to connect your application into another service to store data or even just files, you’ll need to learn what that service might be on that platform, and then you’ll need to learn that platform’s API in order to program against it. Generally, once you’ve got that service wired in, you’ll get some benefits, but the upfront effort is a cost that should be taken into account.

Run projects for less on physical servers

Newsflash – physical servers can be very cheap, especially used ones. Helpfully someone on reddit put together a megalist of cheap server providers. Below is a list of the main providers that are worth checking out in Europe:

  • Kimsufi – based in France. Cheap used servers. Limited availability.  No gigabit connections
  • Online.net – based in France, cheap line of “dediboxes”
  • OneProvider – based in France, but have servers located globally

As of writing, you can get a gigabit connected, 4 core,  4 Gb Ram server with OneProvider for €8 a month. Whilst comparing the cost of this hardware on a cheap provider to a cloud provider would be silly (you’re only supposed to deploy the hardware you need in the cloud), as soon as you run two web apps on an €8 box, you’re saving money.

I’ve got one server with Kimsufi, and one with Online.net. I’ve had one very small outage on Kimsufi in the 2 years that I’ve had a box there. The box was unavailable for around 10 minutes before Kimsufi’s auto monitoring rebooted the box.

I’ve had a single lengthier outage in the 18 months I’ve used Online.net which lead to a server being unavailable for about 5 hours. This was a violation of their SLA and meant that I got some money back. I detailed this outage in a previous post – “Lessons Learned from a server outage“.

Run whatever you want with on a dedicated server

When you aren’t running inside of a neatly packaged cloud product, you have full ownership of the server and can run whatever you want. The downside of this is that there is more responsibility, but in my opinion, the pros out weigh the cons, such as not having to wait for some service to become available (Example – GCS doesn’t support http to https redirection, I’m guessing you need to buy another service for that – this is a few simple lines of config in nginx)

Being able to run whatever you want also opens the door for you to be able to play around with more technology without having to worry about an increase in cost. Running my own dedicated boxes has been fun, and I’ve learned a lot by doing so

Azure

Mapping naked domains and www. domains to Azure web apps

Azure web apps can be mapped to multiple domains, as well as naked domains.

To do this, you will need access to your domain name’s DNS settings.

Go Naked

A naked domain is the domain without the “www.” that you often see on websites. There are various reasons for using a naked url, that I won’t go into in this post.

Jump into your domain name’s DNS settings. Create a CNAME entry for awverify.yourwebsite.com, and point it to your azure domain (e.g. awverify.yourwebsite.azurewebsites.net). This tells azure that you are the owner of the domain.

Now, go into your Azure control panel and locate your web app.

Select “Buy Domains” and then “Bring External Domains”:

You will then be shown a dialogue on the right with a text box where you can enter you naked domain name (e.g. yoursite.com – no www):

After you enter the naked domain, azure will load for a minute whilst is checks for your awverify CNAME dns entry.

Once verified, you can then point your actual domain to your Azure website.

Note: You can use a CNAME or an A record DNS entry to resolve the naked domain of your site. Both methods are listed below:

Method 1. Using an A record DNS entry pointed to the IP shown in the azure portal

Once verified, you Azure will reveal an IP address. This should show up just below the text box where you entered the domain name. If it doesn’t show, wait a few minutes and refresh the entire page. The IP address should then be displayed.

Head over to your DNS settings and enter an a record for “*”resolving to your ip address listed in Azure. You should now have a working naked domain name.

Method 2. Using a CNAME DNS entry pointed to the azure alias

Head over to your DNS settings and enter a CNAME record for “*” resolving to yourwebsite.azurewebsites.net. You should now have a working naked domain name.

The merits of using an A record vs a CNAME entry are not something that I will go into in this post. You can read more about the two DNS entry types here.

Pointing a www. to your azure application as well (or any other subdomain)

As well as having a naked domain work, you will probably also want your www to work as well. This can be done using the same methods above, but crucially you will need to tell Azure that you also have ownership of the subdomain as well:

e.g. In order to verify www.yourwebiste.com, you need to create a CNAME dns entry for awverify.www.yourwebsite.com that resolves to awverify.yourwebiste.azurewebsites.net

In order to verify blog.yourwebiste.com, you need to create a CNAME dns entry for awverify.blog.yourwebsite.com that resolves to awverify.yourwebiste.azurewebsites.net

Again, once verified, you are free to setup and A record or CNAME record DNS entry to point to your Azure Web App.

 

Azure

Hosting multiple websites inside an azure app service

This information is up to date as of November 2015. The Azure offer changes a lot, so this information may become quickly out of date.

A few years back, Scott Hanselman wrote a blog post on how you could utilize the “Standard” tier of Azure websites to save money by hosting multiple sites. Well, that was back in 2013 and the azure offer has significantly changed.

Firstly, Azure Websites has now been merged under Azure App Service, along with a few other services. Here is a 5 minute video from channel 9 explaining what exactly is in Azure App Services.

So, how do I get that “Shared” tier multiple websites setup that Scott Hanselman originally blogged about? Well, the Azure App Service pricing details page looks like you can get there with the “Basic” tier, which is cheaper than “Standard”:

azure-app-service-pricing-nov-2105
Azure App Service offer. Screenshot grabbed in November 2015

And how do I actually set this up in my Azure portal?

Confusingly, what is priced as an Azure App Service basically means everything under the “Web + Mobile” under the “new” option in the azure portal:

azure-portal-Web-Mobile

Why? Because:

An App Service plan is the container for your app. The App Service plan settings will determine the location, features, cost and compute resources associated with your app.

More info here.

You get told this information when setting up your app service plan and location (not sure why it defaults to Brazil…)

azure-portal-app-service-plan

So, an App Service Plan is basically the billable container for your apps.

So if you want to create a new web app under the same App Service, simply select it when setting up a new Web App.

Azure, MVC, MVC 3, MVC4, Technical

Redirecting legacy pages in asp.net

Picture this situation.

An old (legacy) application has landed on your project pile. It is largely built in php, and you intend on re-writing it in asp.net MVC.

You will therefore need to somehow inform any parties that may be trying to access the old urls ending in .php, that the resource they are looking for has moved permanently. You may also wish to do this for SEO reasons.

This is something that cannot be achieved easily through routing; by default, IIS will not pass requests for resources ending in .php to your application. Your routing will therefore never be put to use for resources ending with .php.

The nicest solution I found to this issue is to setup a list of redirects within the system.Webserver section of your web.config file. The following listing below will send a HTTP Response status of 301 (Moved Permanently) for any requests for index.php and for prices.php:

<system.webServer>
 <httpRedirect enabled ="true" httpResponseStatus="Permanent" exactDestination="true">
 <add wildcard="/prices.php" destination="/prices"/>
 <add wildcard="/index.php" destination="/"/>
 </httpRedirect>
</system.webServer>

Index.php will now redirect to /, and prices.php will now redirect to /prices.

This code is currently running in the wild on Azure.

If you are unsure if you need a Permanent redirect or not, have a read of this article from Google.

Azure, Entity Framework, SQL Server

Drop all tables in a SQL Server database (Azure Friendly!)

Most online solutions to this problem will point you in the direction of the undocumented stored procedure, “sp_MSforeachtable“. This stored procedure takes in a string of SQL as a parameter, and will execute this string for each non system table in your database.

Here’s the problem: undocumented stored procedures suck. Their usage has been determined by reverse engineering. They are not officially supported. Their implementation and usage could change with updates and new versions, or could disappear totally.

Here’s something that illustrates my point: “sp_MSforeachtable” does not exist in SQL Azure. So, if your development environment is SQL Server 2008 but your production environment is SQL azure and you are using “sp_MSforeachtable“, you will get problems when you go live, which sucks.

Below is a simple, Azure and Entity Framework friendly bit of SQL that will drop all tables in your database, with the exception of your entity framework migration history table – “__MigrationHistory“:


while(exists(select 1 from INFORMATION_SCHEMA.TABLES where TABLE_NAME != '__MigrationHistory'))
begin
 declare @sql nvarchar(2000)
 SELECT TOP 1 @sql=('DROP TABLE ' + TABLE_SCHEMA + '.[' + TABLE_NAME
 + ']')
 FROM INFORMATION_SCHEMA.TABLES
 WHERE TABLE_NAME != '__MigrationHistory'
exec (@sql)
 PRINT @sql
end

 

If you need to drop your table constraints first, the following code will allow you to do so:


while(exists(select 1 from INFORMATION_SCHEMA.TABLE_CONSTRAINTS where CONSTRAINT_TYPE='FOREIGN KEY'))
begin
 declare @sql nvarchar(2000)
 SELECT TOP 1 @sql=('ALTER TABLE ' + TABLE_SCHEMA + '.[' + TABLE_NAME
 + '] DROP CONSTRAINT [' + CONSTRAINT_NAME + ']')
 FROM information_schema.table_constraints
 WHERE CONSTRAINT_TYPE = 'FOREIGN KEY'
 exec (@sql)
 PRINT @sql
end

Credit to SQL Server Central for the above snippet.