Các môi trường từ xa của chúng tôi hiện đang được hỗ trợ bởi một phiên bản Linux đóng vai trò là người gác cổng giữa các nhà phát triển và môi trường thực tế (các phiên bản apache và mysql chạy Drupal). Điều này được thực hiện để hạn chế việc tiếp xúc với môi trường thực tế và hạn chế các chi tiết cần chia sẻ với nhà phát triển (ví dụ: khóa ssh, URL, địa chỉ IP).
Trên máy gatekeeper, Drush được cài đặt và một ~/.drush/sites/project.site.yml tồn tại với các chi tiết của môi trường thực tế:
'nhà phát triển':
db-url: ...
# Chi tiết nhà phát triển khác
'kiểm tra':
db-url: ...
# Chi tiết kiểm tra khác
'sống':
db-url: ...
# Chi tiết trực tiếp khác
Trên các máy cục bộ của chúng tôi, các nhà phát triển đã giới hạn quyền truy cập SSH vào máy chủ gác cổng này và có một web/drush/sites/project.site.yml trong dự án trông như thế này:
'*':
máy chủ lưu trữ: 'gatekeeper.project.net'
người dùng: 'quản trị viên'
Kỳ vọng là các nhà phát triển sẽ có thể làm điều gì đó như drush @project.dev sql:dump và Drush sẽ chuyển tiếp nó đến máy chủ gác cổng để chạy nó với nhà phát triển bí danh. Tuy nhiên, tôi nhận được lỗi sau:
Lệnh "ssh -t -o PasswordAuthentication=no [email protected] 'drush sql:dump --uri=default'" không thành công.
Có vẻ như nó chỉ chuyển tiếp drush sql:dump --uri=default đến máy chủ và không drush @project.dev sql:dump --uri=default. Điều này từng hoạt động với Drush 8, chúng tôi đã thiết lập thành công bằng phương pháp này. Nhưng điều này không còn hoạt động với Drush 9+ với cấu hình đã dịch.
Làm thế nào để tôi vượt qua @project.dev (hoặc bất kỳ bí danh nào) đến máy chủ từ xa? Tôi có thiếu một số cấu hình không? Có cách nào tốt hơn để làm điều này?
