DarksideCookie

Yesterday I had a couple of hours left over as I was on a train on the way to do a presentation. So I thought i would play around a little with the Azure Container Service. Seeing that I have gotten hooked on Docker, having the ability to spin up a Docker cluster while on the train using just my mobile phone for the connection, seems like a really cool thing. I guess normal people read books and watch Netflix on the train. Me...I spin up 5 Docker clusters...

Setting up an Azure Container Service is really simple, so let's have a look at it.

Setting up a new Container Service

You just go to the portal and choose to add a new Azure Container Service, and accept that it will use the Resource Manager deployment model. Then you have to fill out a bit of information.

More...

In the previous posts, I have talked about everything from what Docker is, to how you can set up a stack of containers using docker-compose, but all of the posts have been about setting up containers on a single machine. Something that can be really useful, but imagine being able to deploy your containers just as easily to a cluster of machines. That would be awesome!

With Docker Swarm, this is exactly what you can do. You can set up a cluster of Docker hosts, and deploy your containers to them in much the same way that you would deploy to a single machine. How cool is that!

Creating a cluster, or swarm

To be able to try out what it’s like working with a cluster of machines, we need a cluster of machines. and by default, Docker for Windows/Mac includes only a single Docker host when it’s installed. However, it also comes with a tool called docker-machine that can be used to create more hosts very easily.

More...

In the previous posts about Docker, here, here and here, we’ve looked at what Docker is, how to set up a basic container and how to set up a stack of containers using docker-compose. One thing we haven’t talked about is the fact that most projects use some form of persistent data store, and the most common store, at least in my world, is a relational database of some sort. So this time, I want to cover something that might seem slightly odd…setting up an MS SQL Server…on Linux…in Docker.

Yes, you heard me right… I’m going to show you how to set up an MS SQL Server instance in a Linux-based Docker container. Something that wouldn’t have been possible, in any way, not too long ago, but Microsoft “recently” released a version of MS SQL Server that runs on Linux, which is really cool. And running it in Docker just makes sense!

Running MS SQL Server in a Docker container

Starting a SQL Server instance in a Docker isn’t that hard, but there are a couple of things that need to be set up for it to work.

More...

So far in this little blog series about Docker, I have covered what Docker is, how it works, how to get a container up and running using pre-built images, as well as your own images. But so far, it has all been about setting up a single container with some form of application running inside it. What if we have a more complicated scenario? What if we have a couple of different things we want to run together? Maybe we want to run our ASP.NET Core app that we built in the previous post behind an nginx instance instead of exposing the Kestrel server to the internet… Well, obviously Docker has us covered.

However, before we go any further, I just want to mention that I will only be covering something called docker-compose in this post. This can be used to create a stack of containers that are set started and stopped together. I will not be covering distributing the application accross several nodes this time. There will be more about that later. And even if that is probably the end goal in a lot of cases, being able to just run on a single host can be useful as well. Especially while developing stuff.

What is docker-compose?

When you installed Docker for Windows or Docker for Mac, you automatically got some extra tools installed. One of them is docker-compose, which is a tool for setting up several containers together in a stack, while configuring their network etc. Basically setting up and configuring a set of containers/apps that work together.

More...

In my last couple of posts, I have talked about OWIN. What it is, how it works, why it is interesting and so on. I have talked mostly about the hosting side of it, and a bit about how we can plug into the OWIN pipeline using what is called middleware… However, so far, the middleware has been ridiculously simple, and done very little, which isn’t really helpful I guess. And besides not doing very much interesting work, they have also not interacted very much with the request pipeline. Most of them, or maybe even all of them, have just terminated the pipeline and returned a simple response…

In this post, I want to take a look at how OWIN abstracts the server, and the request and response, and also how we can use this abstraction to extend the functionality of our pipeline.

More...

My last post about OWIN covered a little bit about the different hosting options, and then quite a bit about OWIN middleware. However, I found the hosting coverage to be a little weak, so I thought I would do one more, much shorter post, on just the different hosts available.

As mentioned before, there are 4 different OWIN hosts available from Microsoft. 3 from project Katana and one from project Helios.

Actually, there are 5. There is also a test host that can be used to test OWIN middleware in Unit tests etc in-memory, instead of having to open a port and listen for incoming requests…

The first, and simplest to get started with is the Katana self-host. But since we saw that being used in the last post, I will skip that one…

More...

In my previous post about OWIN, I talked a bit about what OWIN is, and why it is important. This time, I want to take a little more of a dive into how we can use it, and how we code things using it.

var http = require('http');
var server = http.createServer(function(req,res) {
    res.end('Hello World');
});
server.listen(8080);
console.log('Server running...listening on port 8080');

The above code snippet has nothing at all to do with OWIN. It is actually Node.js code for creating a web server and responding to HTTP requests. However, the above code is the main reason I like Node. The simplicity and tiny amount of code needed to get going is awesome!

It doesn’t do much, but it gives as a very crude, but powerful starting point in just a couple of lines of code. It is then up to us to take it from there and do what we want. Something we often do by turning to our package manager and asking for some cool functionality that someone else has already built.

More...

Ok, so straying a bit away from the AngularJS posts I have been doing lately, I want to talk a bit about OWIN. Why? Well, I recently took a look at it, after putting it off WAY too long, and found it to be awesome! And the goal with this post is to explain what it is, why it is cool, and why Microsoft is putting it into ASP.NET MVC projects by default…

But let’s start with “what is OWIN”… Well, OWIN stands for “Open Web Interface for .NET” and you can find more about OWIN as such at http://owin.org/. And now that you are back from that site, you are probably not a whole lot more in tune with what OWIN is, and the reason for that is probably that the site contains very little information. And it contains that little information because OWIN _is_ really that small. It is just a definition of an interface used to decouple the web applications we build, from the servers that are hosting it…

More...

In the last part, we went had a thorough look at scopes, and scope “inheritance”. That means that we have now covered setting up Angular, creating modules and controllers, and how to utilize two-way data binding using the scope object. The next step is to learn how to work with dependency injection in Angular to provide the same dependency injected service structure that Angular uses internally.

Dependency injection isn’t complicated as such, you register a service that another unit of code can request to get access to. That is the extremely simple definition. To support this in Angular we depend on the $provide service. This service is used to locate dependencies that other pieces of code require. Unfortunately, something as simple as this, actually becomes a little complicated and hard to grasp in Angular. Not because it is really complicated, but because there are so many options…

More...

In the previous part, I talked fairly detailed about how the scopes use prototypical inheritance, and how we can use this to our advantage by either using simple property types, or by using complex types.

In this part, I want to cover some functionality given to us by Angular when using the scope…

More...