I’ve accomplished quite a lot this festive season. My last endeavour was deploying my project to the cloud. This entailed figuring out how Docker works, AWS container services and Travis CI among other things. Basically this all hinged round this rather good document: Deploy .NET Core with Docker to EC2 Container Service. I also connected it up to AWS RDS services using SQL Express 2017. So at the end of the day I’d reached my goal: I had my service deployed into a container on a linux host running in the cloud. And on top of that set it up in the code to automatically connect to the RDS database while in the cloud and to the localDB instance while its under testing on my laptop. Awesome.

One of the nice things about Container services in EC2 is being able to inject environment variables into the image at runtime so you don’t have to store any AWS keys with the source code. You just configure them with the container’s ‘task definition’ and apply them at runtime and get the code to look for its keys from the environment variables which have now been made available via this injection.

In .net core 2.0 you can hook into the environment via the IHostingEnvironment interface to see if you’re running in a production mode profile or a development mode profile and then switch your settings appropriatey. I switch to AWS RDS connection string (which I extract from environment variables which will be injected into the running container) and otherwise use the localDB. Which actually reminds me, I need to install 2017 Sql Express so I can have parity between my AWS and local environment as setup while I’m testing my code. Because you can’t have localBD on linux, it wouldn’t be quite the same, so having a connection to a local sql express 2017 is similar to a connation to RDS which is a SQL 2017 express instance. That’s one of my my next jobs.

I’ve also had some good luck with AWS however it has become quite apparent that to truly be ‘agile’ one needs to use CloudFormation templates to bring environments up and down. Agile meaning that I can do my stuff and then shut it all down and then bring it all up again real quick so I don't have to pay for hours and hours of running resources. So after I got my service deployed I deleted it and all its resources that it was using.

So basically What I’ve got up and running now is a .net core 2.0 web api service that uses EntityFramework Core 2.0. It also uses swagger for the API documentation and simple interaction. This was all to convert my project from full blown Asp.net MVC5(which is awesome btw) because I want to run it in the cloud as a scalable component and the problem with it is that full–blown MVC5 couples the front end website and the backend service tightly together. I want to deploy the two components as two separate things. The service will be a .net core web api service using EF(I had to change things to work rather with EF core 2.0 and not EF6 btw) and I want the front end to be totally independent on the code on the backend and just use HTTP to communicate with it. So I converted the front end MVC5 views to Angular 5 components and the backend to .net core 2.0.

So now I’ve got two independent components one in Angular/Html/TypeScript and one in C# .net core 2. Now I’ve been able to deploy the service as a Docker container to AWS and it works just perfectly. This is the first time I’ve seen .net core run in a container on a linux host. Very cool.

Now what I need to do is put the front end into a image and deploy that as a container too. This way these two parts can scale out much more easily in a cloud environment – my motivation was part Linux containers as well as AWS and using a scalable software architecture (Microservices like).

So I need to figure out how to learn how to script elastic container services and elastic cloud instances among other things. I’ll do that next I guess but I think this will take a while to learn so until I commit, I’ll just chill and do other things. Speaking of which:

I watched Ferdinand the bull movie as well as the new Star wars.