2014-05-14 17 views
5

Tôi tự hỏi thực tiễn tốt nhất khi triển khai node.js phức tạp với beanstalk đàn hồi là gì mà không dựa vào kho npm bên ngoài (và xử lý thông tin đăng nhập và tính sẵn sàng cao của kho lưu trữ git được quản lý riêng cho gói phát triển nội bộ).Triển khai dự án node.js phức tạp với beanstalk đàn hồi

Có vẻ như có một trường phái tư duy giảng dạy để thực sự kiểm tra node_modules vào cây nguồn cho các dự án đang thực sự được triển khai.

nguồn 1: http://www.futurealoof.com/posts/nodemodules-in-git.html

nguồn 2: http://eng.yammer.com/managing-node-js-dependencies-and-deployments-at-yammer/

Vì vậy, có vẻ như kiểm tra chúng trong là cách tiếp cận đúng, nhưng sau đó có một vấn đề về định dạng nhị phân khác nhau đối với một số gói biên dịch (phát triển trên mac và triển khai tới linux)

Tôi đã thử làm theo yammer guys được đề xuất (mô-đun kiểm tra ngoại trừ các thư mục bin), nhưng ngay cả sau đó địa phương "npm xây dựng lại" lệnh không thành công (nó cố gắng chmod một cái gì đó trong một thư mục bin mà không tồn tại trong mô-đun express.js) vì vậy tôi thậm chí còn không cố gắng xem môi trường triển khai mặc định beanstalk sẽ làm gì với kho lưu trữ như vậy. Tôi giả sử nó chạy "npm install" (mà sẽ không làm gì cả), nhưng nó sẽ chạy "npm rebuild"?

Vì vậy, một lần nữa, thực tiễn tốt nhất để triển khai một dự án phức tạp với nhiều phụ thuộc là gì? Nó phải là một vấn đề được giải quyết ngay bây giờ trong thế giới nút/beanstalk, phải không?

Cảm ơn

+0

Bạn có thể sử dụng một lib dựa trên binary.If env dàn của bạn là 100% giống như env sản xuất của bạn sau đó đi trước, kiểm tra trong thư mục node_modules, không có câu hỏi.Bạn không cần npm xây dựng lại nếu bạn không sử dụng các phiên bản khác nhau của nút trong dàn dựng và trong production.Just sao chép tất cả mọi thứ và bạn nên được tốt. – mpm

+0

mongodb bson, kerberos sử dụng nhị phân và tôi đang phát triển trên máy mac trong khi triển khai tới máy amazon linux, tôi không thể cam kết nhị phân vào kho lưu trữ –

+0

Tôi hiểu. Nhưng tại thời điểm này, bạn có thể muốn suy nghĩ về việc sử dụng thứ gì đó như lang thang, sẽ làm cho cuộc sống của bạn đơn giản hơn nhiều. – mpm

Trả lời

2

Đây là cấu hình của tôi thực hiện những gì bạn đang nói đến. Lưu nó vào thư mục .ebextensions và bạn sẽ được thiết lập. Sự khác biệt duy nhất giữa tôi và câu trả lời vượt trội trong https://stackoverflow.com/a/23242623/34340NPM_CONFIG_UNSAFE_PERM = true dòng, mà tôi học được từ https://forums.aws.amazon.com/thread.jspa?messageID=534612

packages: 
    yum: 
    git: [] 
    gcc: [] 
    make: [] 
    openssl-devel: [] 
    libxml2: [] 
    libxml2-devel: [] 

files: 
    "/opt/elasticbeanstalk/env.vars" : 
    mode: "000775" 
    owner: root 
    group: users 
    content: | 
     export HOME=/home/ec2-user # ADDED EXPORT COMMAND 
     export NPM_CONFIG_LOGLEVEL=error 
     export NPM_CONFIG_UNSAFE_PERM=true 
     export NODE_PATH=`ls -td /opt/elasticbeanstalk/node-install/node-* | head -1`/bin 
    "/opt/elasticbeanstalk/hooks/appdeploy/pre/50npm.sh" : 
    mode: "000775" 
    owner: root 
    group: users 
    content: | 
     #!/bin/bash 
     . /opt/elasticbeanstalk/env.vars 
     function error_exit 
     { 
     eventHelper.py --msg "$1" --severity ERROR 
     exit $2 
     } 

     #install not-installed yet app node_modules 
     if [ ! -d "/var/node_modules" ]; then 
     mkdir /var/node_modules ; 
     fi 
     if [ -d /tmp/deployment/application ]; then 
     ln -s /var/node_modules /tmp/deployment/application/ 
     fi 

     OUT=$([ -d "/tmp/deployment/application" ] && cd /tmp/deployment/application && $NODE_PATH/npm install 2>&1) || error_exit "Failed to run npm install. $OUT" $? 
     echo $OUT 
    "/opt/elasticbeanstalk/hooks/configdeploy/pre/50npm.sh" : 
    mode: "000666" 
    owner: root 
    group: users 
    content: | 
     #no need to run npm install during configdeploy 
+0

Tôi giả định giải pháp này làm cho npm cài đặt nhanh hơn, nhưng nó không loại bỏ sự phụ thuộc vào npmjs hoặc các máy chủ khác khi triển khai các phiên bản mới, cũng không giải quyết vấn đề các phiên bản mô-đun không nhất quán trong các phiên bản, phải không? –

+0

Đúng vậy - các dịch vụ bên ngoài và các phiên bản mô-đun không nhất quán vẫn có thể ảnh hưởng đến bạn. Đối với những tình huống đó, bạn có thể muốn di chuyển ra khỏi "git aws.push" hướng tới một cái gì đó như https://github.com/simoneb/grunt-awsebtdeploy + một sự trợ giúp lành mạnh của package.json versioning & npm shrinkwrap chặt chẽ. –

Các vấn đề liên quan