ASP.NET Core: Định cấu hình ứng dụng ASP.NET Core cho App Service Azure đối với hosting platform là Linux

Khóa học qua video:
Lập trình Python All C# Lập trình C Java SQL Server PHP HTML5-CSS3-JavaScript
Đăng ký Hội viên
Tất cả các video dành cho hội viên

Ghi chú

Đối với ASP.NET trong .NET Framework, hãy xem Định cấu hình ứng dụng ASP.NET cho App Service Azure. Nếu ứng dụng ASP.NET Core của bạn chạy trong bộ chứa Windows hoặc Linux tùy chỉnh, hãy xem Định cấu hình bộ chứa tùy chỉnh cho App Service Azure.

Các ứng dụng ASP.NET Core phải được triển khai cho App Service Azure dưới dạng tệp nhị phân đã biên dịch. Công cụ xuất bản Visual Studio xây dựng giải pháp rồi triển khai trực tiếp các tệp nhị phân đã biên dịch, trong khi công cụ triển khai App Service triển khai kho lưu trữ mã trước rồi mới biên dịch các tệp nhị phân.

Hướng dẫn này cung cấp các khái niệm và hướng dẫn chính cho các nhà phát triển ASP.NET Core. Nếu bạn chưa bao giờ sử dụng App Service Azure, trước tiên hãy làm theo hướng dẫn khởi động nhanh ASP.NET Core và ASP.NET Core với Cơ sở dữ liệu SQL.

Hiển thị phiên bản .NET Core

Để hiển thị phiên bản .NET Core hiện tại, hãy chạy lệnh sau trong Cloud Shell:

az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion

Để hiển thị tất cả các phiên bản .NET Core được hỗ trợ, hãy chạy lệnh sau trong Cloud Shell:

az webapp list-runtimes --os linux | grep DOTNET

Đặt phiên bản .NET Core

Chạy lệnh sau trong Cloud Shell để đặt phiên bản .NET Core thành 3.1:

az webapp config set --name <app-name> --resource-group <resource-group-name> --linux-fx-version "DOTNETCORE|3.1"

Tùy chỉnh tự động hóa bản dựng

Nếu bạn triển khai ứng dụng của mình bằng Git hoặc các gói zip có bật tính năng tự động hóa bản dựng, thì các bước tự động hóa bản dựng App Service sẽ thực hiện theo trình tự sau:

  1. Chạy tập lệnh tùy chỉnh nếu được chỉ định bởi PRE_BUILD_SCRIPT_PATH.
  2. Chạy dotnet restore để khôi phục các phụ thuộc NuGet.
  3. Chạy dotnet publish để tạo tệp nhị phân cho bản production.
  4. Chạy tập lệnh tùy chỉnh nếu được chỉ định bởi POST_BUILD_SCRIPT_PATH.

PRE_BUILD_COMMAND và POST_BUILD_COMMAND là các biến môi trường trống theo mặc định. Để chạy các lệnh dựng sẵn, hãy xác định PRE_BUILD_COMMAND. Để chạy các lệnh hậu xây dựng, hãy xác định POST_BUILD_COMMAND.

Ví dụ sau chỉ định hai biến cho một loạt lệnh, được phân tách bằng dấu phẩy.

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings PRE_BUILD_COMMAND="echo foo, scripts/prebuild.sh"
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings POST_BUILD_COMMAND="echo foo, scripts/postbuild.sh"

Để biết các biến môi trường bổ sung để tùy chỉnh tự động hóa bản dựng, hãy xem cấu hình Oryx.

Để biết thêm thông tin về cách App Service chạy và xây dựng các ứng dụng ASP.NET Core trong Linux, hãy xem tài liệu Oryx: Cách các ứng dụng .NET Core được phát hiện và dựng.

Truy cập các biến môi trường

Trong App Service, bạn có thể đặt cài đặt ứng dụng bên ngoài mã ứng dụng của mình. Sau đó, bạn có thể truy cập chúng trong bất kỳ lớp nào bằng cách sử dụng mẫu dependency injection ASP.NET Core tiêu chuẩn:

using Microsoft.Extensions.Configuration;

namespace SomeNamespace 
{
    public class SomeClass
    {
        private IConfiguration _configuration;
    
        public SomeClass(IConfiguration configuration)
        {
            _configuration = configuration;
        }
    
        public SomeMethod()
        {
            // retrieve nested App Service app setting
            var myHierarchicalConfig = _configuration["My:Hierarchical:Config:Data"];
            // retrieve App Service connection string
            var myConnString = _configuration.GetConnectionString("MyDbConnection");
        }
    }
}

Ví dụ: nếu bạn định cấu hình cài đặt ứng dụng có cùng tên trong App Service và trong appsettings.json, thì giá trị App Service sẽ được ưu tiên hơn giá trị appsettings.json. Giá trị appsettings.json cục bộ cho phép bạn gỡ lỗi ứng dụng cục bộ nhưng giá trị App Service cho phép bạn chạy ứng dụng trong môi trường production với cài đặt production. Chuỗi kết nối hoạt động theo cách tương tự. Bằng cách này, bạn có thể giữ bí mật ứng dụng của mình bên ngoài kho lưu trữ mã và truy cập các giá trị thích hợp mà không cần thay đổi mã của bạn.

Ghi chú

Lưu ý rằng dữ liệu cấu hình phân cấp trong appsettings.json được truy cập bằng cách sử dụng dấu phân cách __ (dấu gạch dưới kép) là tiêu chuẩn trên Linux cho .NET Core. Để ghi đè cài đặt cấu hình phân cấp cụ thể trong App Service, hãy đặt tên cài đặt ứng dụng có cùng định dạng được phân tách trong khóa. bạn có thể chạy ví dụ sau trong Cloud Shell:

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings My__Hierarchical__Config__Data="some value"

Triển khai các giải pháp đa dự án

Khi một giải pháp Visual Studio bao gồm nhiều dự án, quy trình xuất bản Visual Studio đã bao gồm việc chọn dự án để triển khai. Khi bạn triển khai tới công cụ triển khai App Service, chẳng hạn như với Git hoặc với triển khai ZIP có bật tự động hóa bản dựng, công cụ triển khai App Service sẽ chọn Trang web hoặc Dự án ứng dụng web đầu tiên mà nó tìm thấy làm ứng dụng App Service. Bạn có thể chỉ định App Service dự án nào sẽ sử dụng bằng cách chỉ định cài đặt ứng dụng PROJECT. Ví dụ: chạy phần sau trong Cloud Shell:

az webapp config appsettings set --resource-group <resource-group-name> --name <app-name> --settings PROJECT="<project-name>/<project-name>.csproj"

Truy cập nhật ký chẩn đoán

ASP.NET Core cung cấp trình cung cấp ghi nhật ký tích hợp cho App Service. Trong Program.cs của dự án, hãy thêm nhà cung cấp vào ứng dụng của bạn thông qua phương thức mở rộng ConfigureLogging, như minh họa trong ví dụ sau:

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureLogging(logging =>
        {
            logging.AddAzureWebAppDiagnostics();
        })
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseStartup<Startup>();
        });

Sau đó, bạn có thể định cấu hình và tạo nhật ký bằng mẫu .NET Core tiêu chuẩn.

Để truy cập nhật ký bảng điều khiển được tạo từ bên trong mã ứng dụng của bạn trong App Service, hãy bật ghi nhật ký chẩn đoán bằng cách chạy lệnh sau trong Cloud Shell:

az webapp log config --resource-group <resource-group-name> --name <app-name> --docker-container-logging filesystem --level Verbose

Các giá trị có thể cho là --level: Error, Warning, Info, và Verbose. Mỗi cấp độ tiếp theo bao gồm cấp độ trước đó. Ví dụ: Error chỉ bao gồm các thông báo lỗi và Verbose bao gồm tất cả các thông báo.

Sau khi bật ghi nhật ký chẩn đoán, hãy chạy lệnh sau để xem luồng nhật ký:

az webapp log tail --resource-group <resource-group-name> --name <app-name>

Nếu bạn không thấy nhật ký bảng điều khiển ngay lập tức, hãy kiểm tra lại sau 30 giây.

Ghi chú

Bạn cũng có thể kiểm tra các tệp nhật ký từ trình duyệt tại https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Để dừng truyền phát nhật ký bất kỳ lúc nào, hãy nhập Ctrl+ C.

Để biết thêm thông tin về khắc phục sự cố ứng dụng ASP.NET Core trong App Service, hãy xem Khắc phục sự cố ASP.NET Core trên App Service Azure và IIS

Nhận trang ngoại lệ chi tiết

Khi ứng dụng ASP.NET Core của bạn tạo ra một ngoại lệ trong trình gỡ lỗi Visual Studio, trình duyệt sẽ hiển thị một trang ngoại lệ chi tiết, nhưng trong App Service, trang đó được thay thế bằng một thông báo lỗi chung chung HTTP 500 hoặc An error occurred while processing your request.. Để hiển thị trang ngoại lệ chi tiết trong App Service, hãy thêm cài đặt ứng dụng ASPNETCORE_ENVIRONMENT vào ứng dụng của bạn bằng cách chạy lệnh sau trong Cloud Shell.

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings ASPNETCORE_ENVIRONMENT="Development"

Phát hiện phiên HTTPS

Trong App Service, việc chấm dứt TLS/SSL xảy ra tại bộ cân bằng tải mạng, vì vậy, tất cả các yêu cầu HTTPS đều đến được ứng dụng của bạn dưới dạng các yêu cầu HTTP không được mã hóa. Nếu logic ứng dụng của bạn cần biết liệu các yêu cầu của người dùng có được mã hóa hay không, hãy định cấu hình Forward Headers Middleware trong Startup.cs:

  • Định cấu hình middleware với ForwardedHeadersOptions để chuyển tiếp các header X-Forwarded-For và X-Forwarded-Proto ở định dạng Startup.ConfigureServices.
  • Thêm dải địa chỉ IP riêng vào các mạng đã biết để middleware có thể tin tưởng bộ cân bằng tải App Service.
  • Gọi phương thức UseForwardedHeadersStartup.Configure trước khi gọi middleware khác.

Đặt cả ba yếu tố lại với nhau, thì code của bạn trông giống như ví dụ sau:

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();

    services.Configure<ForwardedHeadersOptions>(options =>
    {
        options.ForwardedHeaders =
            ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
        // These three subnets encapsulate the applicable Azure subnets. At the moment, it's not possible to narrow it down further.
        options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("::ffff:10.0.0.0"), 104));
        options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("::ffff:192.168.0.0"), 112));
        options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("::ffff:172.16.0.0"), 108));
    });
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseForwardedHeaders();

    ...

    app.UseMvc();
}

Để biết thêm thông tin, hãy xem Định cấu hình ASP.NET Core để hoạt động với máy chủ proxy và bộ cân bằng tải.

Mở phiên SSH trong trình duyệt

Để mở phiên SSH trực tiếp với vùng chứa của bạn, ứng dụng của bạn phải đang chạy.

Dán URL sau vào trình duyệt của bạn và thay thế <app-name> bằng tên ứng dụng của bạn:

https://<app-name>.scm.azurewebsites.net/webssh/host

Nếu bạn chưa được xác thực, bạn bắt buộc phải xác thực bằng đăng ký Azure của mình để kết nối. Sau khi được xác thực, bạn sẽ thấy một trình bao trong trình duyệt, nơi bạn có thể chạy các lệnh bên trong vùng chứa của mình.

kết nối SSH

Ghi chú

Mọi thay đổi bạn thực hiện bên ngoài thư mục /home đều được lưu trữ trong chính vùng chứa đó và không tồn tại sau khi khởi động lại ứng dụng.

Để mở phiên SSH từ xa từ máy cục bộ của bạn, hãy xem Mở phiên SSH từ trình bao từ xa.

robot933456 trong nhật ký

Bạn có thể thấy thông báo sau trong nhật ký vùng chứa:

2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"

Bạn có thể yên tâm bỏ qua thông báo này. /robots933456.txt là đường dẫn URL giả mà App Service sử dụng để kiểm tra xem vùng chứa có khả năng phân phát yêu cầu hay không. Phản hồi 404 chỉ đơn giản cho biết rằng đường dẫn không tồn tại, nhưng nó cho App Service biết rằng vùng chứa vẫn hoạt động bình thường và sẵn sàng đáp ứng các yêu cầu.

Bước tiếp theo

Hướng dẫn: Ứng dụng ASP.NET Core với Cơ sở dữ liệu SQL

Câu hỏi thường gặp về dịch vụ ứng dụng Linux

Hoặc, xem các tài nguyên bổ sung:

Biến môi trường và tham chiếu cài đặt ứng dụng

Nguồn: learn.microsoft.com
» Tiếp: Bảo mật ứng dụng App Service Azure bằng miền tùy chỉnh và chứng chỉ được quản lý
« Trước: Định cấu hình ứng dụng ASP.NET Core cho App Service Azure đối với hosting platform là Windows
Khóa học qua video:
Lập trình Python All C# Lập trình C Java SQL Server PHP HTML5-CSS3-JavaScript
Đăng ký Hội viên
Tất cả các video dành cho hội viên
Copied !!!