Showing posts with label dotnetcore. Show all posts
Showing posts with label dotnetcore. Show all posts

Monday, May 7, 2018

Linux and Windows event more love with containers (LCOW)

I have noticed "Linux containers on Windows built with LinuxKit" (LCOW)  a while back. Today I found a blog post from briantweet actually running a Windows and Linux container together.
There are a few steps that you need to follow to get things working though.
  1. You need to be working on a later release of docker (at least 18.03 I believe)
  2. Switch to windows containers:
    image
  3. and have the experimental features enabled :
    image
  4. You need to then install the LinuxKit on your machine, which is luckily fairly simple:
    1. Download the latest release
    2. Run an elevated powershell prompt and execute the following:
      Remove-Item "$env:ProgramFiles\Linux Containers" -Force -Recurse
      Expand-Archive release.zip -DestinationPath "$Env:ProgramFiles\Linux Containers\."
  5. Now, the first thing I tried was to run the MS-SQL container on Linux (as did brian) and we both ran into the same memory issue. It is a bit hairy to fix, and you may not even need to do this depending on what you are trying to run, but just in case:
    1. We need to recompile the docker deamon. Luckily there are steps to do exactly that, in a docker container. Brian explains it quite well, but missed a few steps that I will fill in:
      1. You will find the client_local_windows.go file in the libcontainerd directory under the root of the docker source code
      2. You will need to find the configuration := &hcsshim.ContainerConfig{
        HvPartition: true,
        Name: id,
        SystemType: "container",
        ContainerType: "linux",
        Owner: defaultOwner,
        TerminateOnLastHandleClosed: true,
        }
        section, round about line 360. Then insert the MemoryMaximumInMB: 4096, in that config
      3. When running step 4 (from the steps) to build the images, add the "-m 2GB" arg., else you will have an "out of memory" error
      4. Finally, only copy over the "dockerd.exe" file to the original docker install folder under the resources directory. On my machine : C:\Program Files\Docker\Docker\resources
This allowed me to run both the Linux ms-sql image and a windows based dotnet sample image together..
image
Magic!

Monday, January 30, 2017

Deploy Docker images to a Private Azure Container Registry

This post continues the journey of creating a dotnet application, containerizing and ultimately deploying the image to production.

The first thing we need to do is to get the source into a source repository (I’m of course going to use VSTS), then we need to configure a build and then push the images to a registry. We will then be able to deploy the images from the registry to our hosts, but more on that later.
Note: Some of these steps may incur some cost, so I would highly recommend at the very least creating a Dev Essentials account. This should cover any costs while we are playing.

I’m assuming you have already pushed your code to a repository in VSTS, so the next step is to create an Azure account, if you have not got one already, and then to setup a container registry.

To create your own private azure container registry to publish the images to:
  1. Login to azure
  2. Select container registries
    image 
  3. This should give you a list and you will need to click “add” to create a new container registry
  4. Fill in the required details and create a new registry
  5. Once created, open up the blade and select the Access Key settings. This should contain the registry name, login server and user name and password details (make sure the “Admin User” is enabled)
    image

Now lets move on to VSTS.
First we need to “connect” VSTS and your container registry:
  1. Login to your VSTS project and under settings, select the services configuration:
    image
  2. Using the details that were in the Access Key settings on the Azure container registry blade, create a docker registry service with your “Login Server” as the docker registry url and the user name and password:
    image

Finally it is time to create the builds. As you would expect, go add a new “empty” build definition that links to your source repository. Instead of selecting the “Hosted” build queue, use the “Hosted Linux Preview” queue. Docker is not available on the normal hosted windows agents yet.
Add 2 command line tasks and 3 docker tasks:
image

Note: If you do not have the docker tasks, then you will need to go and install them from the market place
Now configure the tasks as follows:

Command Line 1 Tool: dotnet
Arguments: restore
Advanced/Working Folder : The folder that your source is located in. In my case it was $(build.sourcesdirectory)/dotnet_sample/
Command Line 2 Tool: dotnet
Arguments : publish -c release -o $(build.sourcesdirectory)/dotnet_sample/output/ or an "output" folder under your source location
Advanced/Working Folder : see above
Docker 1 Docker Registry Connection : the service connection that you created earlier
Action : Build an image
Docker File : The location of your docker file. In my case it was $(build.sourcesdirectory)/dotnet_sample/dockerfile
Build Context: The location of your source code. In my case $(build.sourcesdirectory)/dotnet_sample
Image Name: The name and tag that you want to give your image. In my case I just used dotnet_sample:$(Build.BuildId)
Advanced/Working Folder : same as the other working folders
Docker 2 Docker Registry Connection : the service connection that you created earlier
Action : Run a Docker Command
Command : tag dotnet_sample:$(Build.BuildId) $(DockerRegistryUrl)/sample/dotnet_sample:$(Build.BuildId) the name must be the same as in the task above, and the $(DockerRegistryUrl) must be your Azure container registry url or login server
Advanced/Working Folder : same as the other working folders
Docker 3 Docker Registry Connection : the service connection that you created earlier
Action : Push an image
Image Name : The name you passed in when tagging your container above. In my case it was $(DockerRegistryUrl)/sample/dotnet_sample:$(Build.BuildId)
Advanced/Working Folder : same as the other working folders

Now you can save and queue the build. Hopefully it will look something like this:
image

If all has passed, a quick and easy way to see if your image is in your registry is to navigate to your docker registry’s catalogue url : “https://<<registry_url>>/v2/_catalog”. This will likely prompt you to login with the username and password that you setup previously and then you will download a json file. Opening this file will provide you with all the images hosted in your registry.

In this post we have moved from a locally created image to one residing in our private registry. In the next post we will continue the journey a bit further…

Wednesday, January 25, 2017

Windows joining in the containerization fun

So in the previous posts getting started, creating an application and configuring the container we saw how to install docker, create a sample application and deploy it and run it in a docker container.

Thus far the containers where a Linux flavor and believe it or not, we were running a dotnet application on it.

With Windows 10 (1511 November update or later) and  Windows Server 2016  and Docker Beta 26 or newer, it is possible to create windows containers.

In your system try right click on the docker icon and then select “Switch to Windows Containers”

image

Wait for it to complete.

Once it was switched over, then go back to the application that we created in <<link>> and edit the dockerfile.

Change the first line from FROM microsoft/dotnet to FROM microsoft/dotnet:nanoserver

Then, as before, run the following commands:


docker build . -t dotnet_sample --rm
docker run dotnet_sample –p 80:5000 

The simply navigate to http://localhost/ and voila!! you are not running your same application in a windows based container!

If you are skeptical about what platforms etc. you are running on, download this sample and edit the dockerfile and go to the “Docker” tab

 

As much fun as this is, the goal behind using containers is not to simply play with it on your machine. We want to automate the creation and deployment of the containers.

Next up I will show you how to automatically use VSTS to build and deploy to an Azure  Container host.

 

Wednesday, January 18, 2017

Create and run a dotnet core sample

Now that you have everything to get started, I’m going to create a simple application that we can run. If you have the dotnet core SDK installed, this is fairly simple.
Drop down to your command line / PowerShell and in a new empty folder (I’m using dotnet_sample folder which will become the "name" of the application) simply type :
dotnet new –t web
This will create a bunch of files which is basically a "starter" web application. If you had just typed in "dotnet new" a simple command line "hello world" would have been created.

Even though we have installed dotnet 1.1 core this sample is still being generated to use 1.0.1, so we want to "upgrade" it to use 1.1.
Open up the project.json file and look for the dependencies section:
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.0.1",
"type": "platform"
},

change the version to 1.1 : "version": "1.1"
then further down in the file under the "frameworks" section change "netcoreapp1.0" to "netcoreapp1.1"

The next step is to "install" or download all the dependencies. For this we simply run:
dotnet restore
Note: you may have to install gulp (if you are using a clean machine) by typing npm install -g gulp
A whole bunch of packages are downloaded and installed and gets your application in a state that is ready to run.
Finally, execute the following:
dotnet run
This will “execute” the web application and put it into a run state.
If you navigate (using your favorite browser) to http://localhost:5000 you should see something like this:
image

For completeness, here is the PowerShell prompt with the commands that are run chronologically. (yours may look a bit different due to package cache etc.)
image
Now you have a fancy new application, ready to containerize!
To package a dotnet web app we need to run:
 dotnet publish -c Release -o output

Monday, January 16, 2017

Docker– Getting Started

If you have not heard of this thing called docker or more generically containerization, then
  1. What rock have you been under?
  2. Here is a quick guide to start off with.
Even though docker is a Linux concept, Microsoft has embraced it and started building the ability to run either Windows or Linux containers in your Windows environment. The catch is, if you want to start playing on your desktop with windows containers, you will need “64bit Windows 10 Pro, Enterprise and Education (1511 November update, Build 10586 or later)” and have Hyper-V and the Container feature enabled.
Once you have that sorted you can start by installing the following:
  • Docker for Windows
    I recommend using the beta channel as this has the support for Windows containers using Hyper-V.
  • Kitematic, you can get it directly from here
  • dotnetCore SDK, ‘cause that is how we roll…
  • A cool IDE like VS Code
    If you are using VS Code then don't forget to add the Docker extension
  • And assuming you have a new, non-developer machine do not forget node. We will use it to restore packages when we start playing with demo samples.
Install docker for Windows. Once you have that installed, you will notice the docker icon in your system tray. Right click on that and select “Open Kitematic”. This will tell you where to download and ultimately put Kitematic. This is strictly not necessary, and we can do everything we need without it, but it is a “nice to have”
image
This should get you ready to start playing.
A note: if you have Visual Studio (2015.3 or newer) installed, then I can recommend you install the dotnetcore tools preview.
In the next post we will create a simple application that we can start doing stuff with.