9

Tôi đang sử dụng đàn hồi Beanstalk và Django 1.8.2 của Amazon. Dưới đây là các lệnh vùng chứa của tôi,của Django trên Amazon Elastic Beanstalk bị giết

container_commands: 
    01_wsgipass: 
    command: 'echo "WSGIPassAuthorization On" >> ../wsgi.conf' 
    02_makemigrations: 
    command: "source /opt/python/run/venv/bin/activate && python manage.py makemigrations --merge --noinput" 
    leader_only: true 
    03_migrate: 
    command: "source /opt/python/run/venv/bin/activate && python manage.py migrate --noinput" 
    leader_only: true 

Vì một số lý do, lệnh migrate đang bị giết. Tất cả các di chuyển đang làm việc tốt ngay cả với một cơ sở dữ liệu mới trong địa phương của tôi. Nhưng sau đây là lỗi xuất hiện trên eb-activity.log.

Synchronizing apps without migrations: 
    Creating tables... 
    Running deferred SQL... 
    Installing custom SQL... 
    Running migrations: 
    Rendering model states.../bin/sh: line 1: 21228 Killed     python manage.py migrate --noinput 
    (ElasticBeanstalk::ExternalInvocationError) 

Lưu ý: Các lệnh cùng một container đang làm việc tốt mà không có bất kỳ vấn đề trước đó tại Elastic cây đậu. Tôi đã thử với --verbose 3 với lệnh di cư nhưng đã không nhận được bất kỳ thông điệp debug khác.

Bất kỳ giải pháp? Cảm ơn trước.

+0

Hai suy nghĩ: Bạn có nhận được bất kỳ thông tin hơn trong [CFN-init.log] (http://qpleple.com/install-python-packages-on-elastic-beanstalk/) và bạn đã xem xét thay đổi của bạn [ lệnh timeots] (http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/events.common.commandtimeout.html)? –

+0

Có, thời gian chờ của tôi đã là 1000 giây. Nó không giống như một lỗi thời gian chờ. Tôi đã kiểm tra lỗi từ /var/log/cfn-init-cmd.log, nó cho thấy cùng một lỗi. Không có nhật ký gỡ lỗi chi tiết nào. – Babu

+0

Nếu bạn không nhận được lỗi hoặc chẩn đoán hữu ích nào khác từ EBS, có thể có điều gì khác đang làm? Bạn có cho rằng đó có thể là hệ điều hành - ví dụ: bạn có phải là nạn nhân của [OOM killer] (http://stackoverflow.com/questions/726690/who-killed-my-process-and-why)? –

Trả lời

5

AWS không thân thiện với nhà phát triển khi nói đến khắc phục sự cố với cơ chế đăng nhập kém.

Là người dùng AWS khao khát gần đây đã đánh giá EBS cho dự án Django, tôi hoàn toàn đồng ý với điều này vì cùng một lý do. Tôi đã kết thúc với Heroku vì điều này và lý do tôi sẽ không đi vào nhưng tôi nghĩ rằng mô hình sau đây sẽ giúp một trong hai cách.

Các bước để chuẩn bị môi trường sản phẩm của bạn có thể hoạt động ở các vị trí khác nhau; chúng không phải xảy ra trên môi trường máy chủ web mục tiêu của bạn.

Tôi đã kết thúc việc thực hiện/di chuyển các tác vụ của mình ra khỏi tự động triển khai và thực hiện các tác vụ ngay trước đó. Điều duy nhất xảy ra trong môi trường máy chủ web mục tiêu của tôi có liên quan trực tiếp đến mã trên máy chủ đó.

Nói cách khác: Tôi khuyên bạn nên nếu bạn có một công cụ CI để xây dựng/kiểm tra, bạn kéo thực hiện/di chuyển của bạn và bất kỳ chuẩn bị nào khác vào môi trường bên ngoài máy chủ web của bạn vào đường dẫn triển khai. Một cái gì đó như:

  • đang Thanh toán
  • Chạy thử nghiệm (bao gồm cả làm/di chuyển trên cơ sở dữ liệu phù du để kiểm tra nó nếu có thể) ứng dụng
  • Đặt ở chế độ bảo trì (hoặc tương tự, nếu có yêu cầu) cơ sở dữ liệu
  • Snapshot
  • Thực hiện/Di chuyển trên sản xuất
  • Triển khai
  • Nếu triển khai không thành công, rollback DB, ứng dụng rollback.

Sau đó, bạn đang tách các mối quan tâm về tự động hóa cho máy chủ ứng dụng và tự động hóa cho phần còn lại của môi trường sản xuất và để CI xử lý. Bạn thể xử lý chúng trong cùng một vị trí, nhưng rõ ràng nó một chút thời gian để làm điều đó bằng phương tiện EBS của.

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