Triển khai Jetty trên Azure App Service hoạt động như thế nào?

Question

Tôi có một ứng dụng web Java mà tôi chạy trên một phiên bản Dịch vụ ứng dụng Azure. Để triển khai nó, tôi sử dụng một repo Bitbucket với một tập tin .war bên trong nó. Khi tôi cam kết một tập tin .war mới cho repo này, nó được cho là được triển khai tự động bởi dịch vụ. Tuy nhiên, thường xuyên hơn không, tôi phải khởi động lại, triển khai lại hoặc thậm chí tải lên tệp .war qua FTP để triển khai được hoàn tất thành công.

Tôi có một phiên bản Jetty duy nhất nằm trong dịch vụ này, do đó tệp .war của tôi có tên là ROOT.war. AFAIK, khi được tải lên dịch vụ (cho dù qua Bitbucket hoặc FTP), tệp .war này sẽ được hủy lưu trữ trong cùng một thư mục, là /site/wwwroot/webapps. Trong trường hợp của tôi, điều này không xảy ra. Ứng dụng web hoạt động với tệp ROOT.war ngồi một mình bên trong /site/wwwroot/webapps. Và mỗi lần trong một thời gian, tôi nhận được một thư mục ROOT dưới /site/wwwroot/webapps, với hai tệp mặc định index.jsp và background.png. Tôi không có ý tưởng nhỏ nào khiến thư mục ROOT xuất hiện với các tệp mặc định này. Các đầu mối duy nhất tôi có là nó đã xảy ra một vài lần sau khi tôi thay đổi một biến môi trường.

Cũng sau khi thư mục ROOT xuất hiện với tệp máy chủ trống, cách duy nhất tôi có thể triển khai lại ứng dụng là xóa thư mục ROOT này qua FTP hoặc bảng điều khiển được cung cấp trong cổng và chỉ sau đó triển khai lại yêu cầu thành công với ứng dụng web của tôi.

Vì vậy, nếu nó không đủ rõ ràng, câu hỏi của tôi là những gì đang xảy ra ở đây? Tôi không thể làm được gì ngoài hành vi mà tôi đang phải đối mặt. Tôi cảm thấy như tôi đang sử dụng dịch vụ Azure này một cách mù quáng, và không thể sửa chữa bất cứ điều gì khi có sự cố. Có bất kỳ tài nguyên nào có thể giải thích điều gì xảy ra trong nền khi ứng dụng web được triển khai không?

Answer 1

Vì vậy, Ứng dụng API Azure là PAAS, không phải dịch vụ IAAS. Bạn có thể truy cập nền tảng PaaS bằng cách đến yoursite.scm.azurewebsites.net, nơi bạn có thể duyệt hệ thống tệp trong CMD hoặc Powershell và bạn có thể xem các quy trình đang chạy. Điều này có thể cảm thấy như bạn đang ở trên một máy ảo duy nhất, nhưng bạn thì không. Dữ liệu bạn thấy ở đây được sao chép vào các phiên bản ứng dụng API của bạn. Bạn có thể kiểm soát số lượng phiên bản bạn có thông qua việc mở rộng ứng dụng API của mình.

Tôi thường thấy vấn đề của bạn với việc triển khai, sau đó ROOT bị trống (làm việc nội bộ để xem lỗi này ...). Phương pháp tốt nhất hoạt động mọi lúc với tôi, là dừng ứng dụng API của bạn, tự UNZIP ROOT.war của bạn theo cách thủ công. Di chuyển tệp vào/ROOT /, sau đó khởi động ứng dụng API của bạn.

Bạn chỉ cần đặt ROOT.war và để hệ thống giải nén khi bạn bật lại, nhưng điều này đôi khi có thể dẫn đến thư mục ROOT trống, sau đó yêu cầu khởi động lại khác.

Tất cả điều này giúp tôi chuyển sang Spring-Boot. Không yêu cầu giải nén. Chỉ cần cấu hình web.config của bạn và thả tệp jar.

https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-java-custom-upload#springboot

Answer 2

Tôi gặp vấn đề tương tự. Giải pháp là gọi điểm cuối sau khi triển khai.

1. Dừng dịch vụ ứng dụng Azure.
2. Triển khai tạo phẩm ROOT.war trong thư mục/webapps.
3. Khởi động Dịch vụ ứng dụng Azure.
4. Gọi URL của Dịch vụ ứng dụng một lần.

Bốn bước là rất quan trọng và bắt đầu quá trình bạn đã đề cập trước đó (triển khai tự động).

Tôi mất rất nhiều thời gian để tìm ra vấn đề là gì.