Điểm:0

NginX: Phục vụ ứng dụng theo đường dẫn phụ

lá cờ tn

Tôi có nhiều ứng dụng trang đơn đang chạy từng ứng dụng trong vùng chứa riêng của chúng dưới hướng dẫn trực tiếp tại nhà, điều này khá đơn giản.

Bây giờ tôi muốn định tuyến đến các ứng dụng đó trong cùng một mục nhập dns bằng các đường dẫn khác nhau, ví dụ:

domain.com -> defaultAppContainer
miền.com/app1 -> vùng chứa1
miền.com/app2 -> vùng chứa2

Tôi không có tùy chọn viết lại đường dẫn trong khi định tuyến, vì vậy tôi muốn Nginx lắng nghe đường dẫn /ứng dụng1 hoặc /ứng dụng2 tương ứng và phục vụ các ứng dụng một cách chính xác từ đó. Hiện tại mọi thứ tôi đã thử đều dẫn đến lỗi.

Tôi đã xem xét hai khả năng:

  • Ủy quyền đường dẫn phụ đến nhà bằng cách sử dụng một cái gì đó như
    vị trí /ứng dụng1 {
      proxy_pass $host/;
    }
    
    Nhưng điều này dường như không hoạt động đối với giao diện người dùng, tôi cho rằng một số đường dẫn bị rối trong yêu cầu.
  • Phục vụ tất cả các tệp theo tuyến phụ, ví dụ:
    vị trí /ứng dụng1 {
      bí danh gốc /usr/share/nginx/html/;
    }
    
    Trường hợp bí danh trỏ đến thư mục cơ sở của ứng dụng web được xây dựng. Điều này mang lại cho tôi một CONN_RESET lỗi.

Ngoài ra, việc chuyển hướng đơn giản bằng 307 không phải là một tùy chọn vì điều đó sẽ dẫn đến việc ứng dụng khách gọi url cơ sở mà không có đường dẫn, sau đó url này được chuyển đến ứng dụng mặc định.

Điểm:1
lá cờ gr

Nói chung, việc chạy ứng dụng dưới tiền tố URI khi bản thân ứng dụng không mong đợi đó là một điều khó khăn và giải pháp đáng tin cậy duy nhất là sửa/thiết lập ứng dụng làm cho ứng dụng tạo ra tất cả các liên kết nội dung/tuyến tương đối hoặc bao gồm tiền tố đó được triển khai dưới. Hầu hết mọi giải pháp thay thế hiện có là viết lại các phản hồi của ứng dụng "ngay lập tức" thay thế các liên kết đã tạo bằng các liên kết mới. Một số loại câu trả lời chung chung là đây, một số cân nhắc bổ sung có thể được tìm thấy đây.

Tuy nhiên, nếu đó là một SPA thực sự, giả sử ứng dụng React sử dụng thứ gì đó như BămRouter còn hơn là Trình duyệtRouter, một cách giải quyết dựa trên việc viết lại có điều kiện theo yêu cầu người giới thiệu Tiêu đề HTTP có thể:

người phục vụ {
    ...
    nếu ($http_referer ~ ^https?://yourdomain.com/app1/) {
        viết lại ^ /app1$uri;
    }
    nếu ($http_referer ~ ^https?://yourdomain.com/app2/) {
        viết lại ^ /app2$uri;
    }
    ...
    vị trí /app1/ {
        proxy_pass http://container1/;
    }
    vị trí /app2/ {
        proxy_pass http://container2/;
    }
}

Tất cả các dấu gạch chéo được sử dụng ở đây đều được sử dụng có mục đích, việc loại bỏ bất kỳ dấu gạch chéo nào trong số chúng sẽ phá vỡ giải pháp!

Điều này không áp dụng cho bất kỳ thứ gì khác ngoài SPA (bao gồm các ứng dụng đang sử dụng định tuyến "ảo" dựa trên API lịch sử trình duyệt HTML5) vì logic viết lại sẽ bị hỏng sau lần chuyển đổi từ trang này sang trang đầu tiên.

masus04 avatar
lá cờ tn
Cảm ơn rất nhiều cho trả lời của bạn! Tất cả Ứng dụng được triển khai bằng cách sử dụng một trong các cách sau: Reac, vuejs hoặc Flutter, nhưng đây là lúc kết thúc đảm bảo và tôi không có quyền kiểm soát việc triển khai chính xác. Ngoài ra, chức năng chính xác của việc viết lại là gì?

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.