Migrate ASP.NET Framework apps that rely on ODBC drivers to Azure App Service

Introduction

(This article was created based on the information in October 2020) I think one of the things to consider when migrating existing in-house systems on-premises to the cloud is the choice of migrating to IaaS or PaaS. Given the advantages and restrictions of both IaaS and PaaS, I think it is not uncommon to adopt PaaS and make decisions to proceed with business. However, if the application is deeply dependent on the functions of the OS, it is possible that the application cannot be migrated to PaaS and must be migrated to a virtual machine on IaaS. So, as one of the solutions, consider containerizing the application, putting the OS-dependent part in the container, and operating the container with PaaS. Azure App Service has long provided support for Windows containers as a preview, but Ignite 2020 Announcement (https://news.microsoft.com/ignite-2020-book-of-news/#142- Windows container support for App Service is now generally available (GA) in azure-app-service-updates-include-new-cost-savings-options-windows-container-support-github-actions-integration). I would like to use this to consider an example of migrating an in-house system running on-premise to Azure PaaS.

This time, as shown in the image below, an example of migrating an ASP.NET Framework application that depends on ODBC on an IIS server running in an on-premise environment to App Service (Webapp), which is a PaaS of Azure, with minimal application changes. Will be taken up.

Containerize an existing ASP.NET Framework app

If you're developing your current ASP.NET Framework app in Visual Studio, you can turn your app into a Windows container with just a few simple steps. If you are using Visual Studio 2019 / Visual Studio 2017 (version 15.7 or later), you can use Docker support simply by installing the necessary components in the Visual Studio Installer and preparing Docker Desktop. (For details, see https://docs.microsoft.com/ja-jp/visualstudio/containers/overview?view=vs-2019) As an aside, ASP.NET Framework apps do not support Linux containers, and Windows Only containers are available. To actually use Docker support, open the ASP.NET Framework project you want to containerize and add Docker support from Solution Explorer, as shown in the image below.

Adding Docker support will check the startup of Docker for Windows and will start the Windows container if it is not running or if the Linux container is running. After that, the following Dockerfile is automatically generated in the project, and the preparation for creating the image of the Docker container is completed.

Dockerfile

FROM mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2019
ARG source
WORKDIR /inetpub/wwwroot
COPY ${source:-obj/Docker/publish} .

At this point, the ASP.NET Framework app has been containerized to Windows, but in this state the app is just running on Windows, so ODBC-dependent apps cannot connect to the database. Next, add the process to install the ODBC driver inside the container in the Dockerfile. I think that you will install ODBC using the following Powershell Add-OdbcDsn etc. on your Windows etc., but if you write the process as it is on the Dockerfile, it will not work well and you will be addicted to it, so be careful.

Powershell

Add-OdbcDsn -Name "DSNNAME" -DriverName "PostgreSQL Unicode" -DsnType "User" -Platform "32-bit" -SetPropertyValue @("Server=SERVERNAME.com","Database=DBNAME","SSLMode=require","Username=SOMEONE")

The following is a description example in the actual Dockerfile. Write a Powershell command directly from the RUN command usingSHELL ["powershell", "-command"]instead of specifying Powershell with the RUN command and executing the normal Powershell command after -command. If you do so, you can create an image without any errors.

Dockerfile

FROM mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2019
ARG source
WORKDIR /inetpub/wwwroot
COPY ${source:-obj/Docker/publish} .

SHELL ["powershell", "-command"]

#Download ODBC driver for PostgreSQL
ADD https://ftp.postgresql.org/pub/odbc/versions/msi/psqlodbc_12_01_0000-x86.zip /
ADD https://ftp.postgresql.org/pub/odbc/versions/msi/psqlodbc_12_01_0000-x64.zip /

#Extract the zip file and install the driver
RUN Expand-Archive -Path c:\psqlodbc_12_01_0000-x86.zip -DestinationPath c:\odbc\ ; \
    Start-Process c:\odbc\psqlodbc_x86.msi -Wait
RUN Expand-Archive -Path c:\psqlodbc_12_01_0000-x64.zip -DestinationPath c:\odbc64\ ; \
    Start-Process c:\odbc64\psqlodbc_x64.msi -Wait

#RUN powershell -If command is used, an error will occur in the parameter specification part.
#RUN powershell -command Add-OdbcDsn -Name "DSNNAME" -DriverName "PostgreSQL Unicode" -DsnType "User" -Platform "32-bit" -SetPropertyValue @("Server=SERVERNAME.com","Database=DBNAME","SSLMode=require","Username=SOMEONE")

#32bit
RUN Add-OdbcDsn -Name 'DSNNAME' -DriverName 'PostgreSQL Unicode' -DsnType 'System' -Platform '32-bit' -SetPropertyValue @('Server=SERVERNAME.com','Database=DBNAME','SSLMode=require','Username=SOMEONE')
#64bit
RUN Add-OdbcDsn -Name 'DSNNAMEx64' -DriverName 'PostgreSQL Unicode(x64)' -DsnType 'System' -Platform '64-bit' -SetPropertyValue @('Server=SERVERNAME.com','Database=DBNAME','SSLMode=require','Username=SOMEONE')

After that, you can confirm that the container application is executed locally by executing the build.

Upload the containerized app to the container registry and publish it in App Service

Now that you have an ASP.NET Framework app that relies on the ODBC driver to run on a container, you're ready to deploy your app to App Service, which is a PaaS. This time, we'll push the container image to Azure Container Registry and configure it to auto-deploy to App Service. (Of course, the same thing can be achieved by pushing the image to Docker Hub) You could push the image from the Docker command to Azure Container Registry on the command line, but this time we'll use Visual Studio to push the container image to Azure Container Registry.

In Solution Explorer, right-click on the project of the app you want to containerize and select "Publish ..." from the menu.

Then click Docker Container Registry as the publisher.

Select the Azure Container Registry and choose from the subscriptions you have for the Azure Container Registry you want to push the image to. Here, you may be required to log in to your Microsoft account. Also, if your Azure subscription doesn't have Azure Container Registry, create it on the Azure portal or in Visual Studio. (Click here for how to create Azure Container Registry: https://docs.microsoft.com/en-us/azure/container-registry/container-registry-get-started-portal)

When you're ready to push the image to Azure Container Registry, press the Publish button to push the image.

Next, create an App Service that actually runs the app. [Announcement of Ignite 2020](https://news.microsoft.com/ignite-2020-book-of-news/#142-azure-app-service-updates-include-new-cost-savings-options-windows- It is said that Windows container support is supported by Premium V3 SKU in container-support-github-actions-integration), so I would like to use that this time. (App Service See here for more information on related updates (https://techcommunity.microsoft.com/t5/apps-on-azure/migrate-modernize-net-applications-with-azure/ba-p/1696499) Please give me) Select Create App Service on the portal and select the setting to create a Docker container with Windows OS. During the preview period, there were App Service Plan SKUs for Windows containers called PC2 to PC4, but with this update, we are now choosing the same Premium V3 SKUs as the others. (Conversely, Windows containers can only be created with Premium V3 instances at present. It seems that verification etc. can be done while keeping the price down by using the Dev / Test price set from November.)

The following Docker tab specifies the image source for the container that App Service runs on. This time, specify the Azure Container Registry you created earlier. Then deploy the App Service with the default settings.

After deploying the App Service, you can specify the image of the container hosted by the App Service from the "Container Settings" of the portal. You can also turn on Continuous Deployment to automatically update the image of the container running in App Service every time the image is updated.

You have now run an ASP.NET Framework app that relies on the ODBC driver on the App Service.

in conclusion

This time, I used an instance of App Service Premium V3 SKU to run an ASP.NET Framework app that relied on the ODBC driver as a Windows container. I think the good news is that PaaS, which is highly flexible and economical, has become an option for migrating existing systems to the cloud and running in containers. The App Service Premium V3 SKU also offers regional VNET integration and options for running apps in closed environments, such as Private Link, so please consider that as well.

(This article was created based on the information in October 2020)