Các quy ước URL nội bộ doanh nghiệp

nhà phát triển ở đây ... Tôi muốn quan điểm CNTT của bạn về điều này ...

Tôi đang xây dựng một ứng dụng web nội bộ mới cho công ty của mình và bắt đầu suy nghĩ về cách nó sẽ được triển khai. Nhiều ứng dụng web hiện có ở đây được liên kết - sử dụng trực tiếp tên máy chủ của họ, như thế này:

http://webserver123/someInternalApp/

Điều này khiến tôi không thoải mái vì nhiều lý do. Tên máy chủ thay đổi, máy chủ ngừng hoạt động và người dùng không cần phải biết tên máy chủ để tìm ứng dụng web của mình. Sử dụng tên máy chủ ngăn chúng tôi hoán đổi máy chủ hoặc thêm bộ cân bằng tải. Nếu bạn có thể nghĩ về những lý do khác là điều này là xấu, hãy cho tôi biết để tôi có thể đưa ra một trường hợp tốt hơn để thay đổi thực hành này.

Trong tương lai, tôi muốn có một số tên miền tốt hơn được thiết lập trong DNS nội bộ của chúng tôi sẽ quay lại máy chủ và ứng dụng web thích hợp. Trong công việc cuối cùng của tôi, chúng tôi đã theo một quy ước như thế này:

• Cho việc sản xuất: http://someInternalApp.myCompany.com/
• Cho thử nghiệm: http://test.someInternalApp.myCompany.com/
• Cho sự phát triển: http://dev.someInternalApp.myCompany.com/

Tôi thích điều này hơn , vì tên ứng dụng là một phần quan trọng của tên miền và việc chỉ định môi trường dev / test / prod rất đơn giản. Tuy nhiên, tôi có một số đặt phòng:

• Đặt tên ứng dụng trong tên miền phụ cuối cùng sẽ tạo ra rất nhiều tên miền phụ dài, độc đáo. Tôi thích có các tên miền khác nhau cho mỗi ứng dụng, nhưng tôi cũng cảm thấy có thể khó quản lý.
• Ngoài tên ứng dụng, không có gì để chỉ định rằng URL này chỉ là nội bộ. Tôi đã đọc về các tổ chức khác sử dụng tên miền phụ như "corp.myCompany.com" hoặc "int.myCompany.com" có thể tốt. Tôi không muốn người dùng có được ấn tượng họ có thể truy cập những thứ này từ nhà.

Dưới đây là một số tùy chọn về những gì tôi đang nghiêng về các tên miền nội bộ:

Tên ứng dụng trong tên miền phụ nội bộ: (chúng hơi dài một chút, nhưng tôi nghĩ mọi thứ đều được đóng gói cùng nhau)

• http://someInternalApp.corp.myCompany.com/
• http://dev.someInternalApp.corp.myCompany.com/

Tên ứng dụng dưới dạng thư mục con: (tên miền ngắn hơn, nhưng nó ngụ ý tất cả các ứng dụng là một phần của một trang web hợp nhất, có thể không phải là nó và nó ngắt kết nối chỉ định môi trường khỏi ứng dụng)

• http://corp.myCompany.com/someInternalApp
• http://dev.corp.myCompany.com/someInternalApp

Vì vậy, hãy thảo luận ... Bạn nghĩ gì về những lựa chọn này? Có cái gì tốt hơn hoặc phổ biến hơn tôi có thể đã bỏ lỡ? Tôi có cơ hội để đưa công ty của mình đi theo con đường tốt hơn trong vấn đề này, vì vậy tôi muốn tìm một quy ước tốt để giới thiệu.

Cảm ơn!

Không bao giờ dựa vào việc ứng dụng của bạn sẽ là nội bộ hay bên ngoài. Luôn luôn phát triển như thể khán giả của ứng dụng sẽ nằm ngoài tầm kiểm soát của bạn (bởi vì nó là).

Đi với ENV.APPNAME.DOMAIN.TLD

Với www. như bí danh cho "sản xuất".

Nếu bạn chỉ triển khai nội bộ, bạn có quyền tự do tuyệt vời trong việc lựa chọn. Tuy nhiên, với các Tên miền cấp cao mở ra như gần đây, bạn muốn cẩn thận để không xung đột với một tên bên ngoài mới sắp tới.

ví dụ: bạn có thể triển khai dưới dạng http://contact.app/ nhưng nếu Tapp .app được đăng ký thì bạn có thể thấy mình xung đột.

Vì vậy, có lẽ bạn là tốt nhất khi sử dụng một cái gì đó như http: //contact.local/ hoặc http: //contact.lan/

Vì lý do của Apple và khả năng tương thích dịch vụ Bonjour của họ, tốt nhất bạn nên tránh .local vì vậy có lẽ nên đi với .lan

Ngoài ra, chỉ cần http: //contact.ourcompany/ sẽ hoạt động khá tốt nếu tên công ty của bạn rất khó có thể trở thành TLD.

Tôi sẽ tránh tên ứng dụng như một thư mục con vì nó không cần thiết và chỉ làm cho nó dài hơn. Lưu trữ ảo là cách để đi đến đó với một URL duy nhất cho mỗi ứng dụng.

Và bạn hoàn toàn chính xác trong việc tránh tên máy chủ, đó là điều không nên bởi vì máy chủ đến và đi.

Chỉnh sửa 1 : Xem RFC2606 và chọn lựa từ sử dụng nội bộ có sẵn của TLD được tham chiếu ở đó.

Cũng như một ghi chú cho các bình luận - .local và .lan như tôi khuyên bạn không thể đăng ký theo RFC ở trên. Bạn có thể sử dụng .priv và .test cũng vì những lý do tương tự.

Điều này dựa trên ý kiến ​​nào đó bởi vì khi bạn chỉ triển khai ứng dụng của mình trong nội bộ, bạn có toàn quyền kiểm soát và thực sự không quan trọng bạn làm gì ...

Hầu hết người dùng sẽ đánh dấu những ứng dụng web nội bộ nào họ cần sử dụng, vì vậy đừng băn khoăn quá nhiều về URL của họ.

Là sysadmin, tôi sẽ thích nhiều ứng dụng hơn cho tôi lựa chọn triển khai trong thư mục con có thể định cấu hình hoặc gốc trên tên miền phụ, cho phép lựa chọn sử dụng tên miền phụ hay không.

Cần một nhà phát triển chu đáo hơn để không đi theo con đường "dễ dàng" và chỉ bao gồm một tham chiếu (tương đối) được mã hóa cứng " href=/images/bullet.png" trên một trang ngẫu nhiên và thay vì xây dựng một tham chiếu từ một số cài đặt triển khai / cấu hình " href={HTTP-PROTO}://{IMG-HOST}/{IMG-BASEDIR}/bullet.png"

Vui lòng thực hiện các lựa chọn triển khai của bạn như bất kỳ tên máy chủ, số cổng, lựa chọn nào trong cài đặt cấu hình HTTP / HTTPS và không mã hóa chúng.

Tôi thường ở cuối nhận "quản lý muốn tất cả các ứng dụng nội bộ http://intranet/apps/vì appname.intranetnó rất khó hiểu. Và ngược lại với các nhà cung cấp của chúng tôi, chúng tôi cần appname.intranetcho thiết bị / ứng dụng của chúng tôi khi chúng tôi có kiểm tra tích hợp chống lại iframes, inlining man-in-the -middle-Tấn công và ủy quyền ngược ....

Tôi đã thấy rằng rất nhiều ứng dụng web thương mại dự kiến ​​sẽ được triển khai trong thư mục gốc của máy chủ web và không hoạt động quá đáng tin cậy khi được triển khai trong một số thư mục con ngẫu nhiên. Ví dụ, chúng bao gồm các đường dẫn được mã hóa cứng hoặc ít hơn đến /css/main.csscác thư mục con, gây khó khăn cho việc lưu trữ nhiều ứng dụng trên cùng một máy chủ. Nhưng những người đó cũng không quá lo lắng về tính di động của mã của họ.