프로덕션 코드 설정으로 구성된 AMI가 있습니다. 서버 설정으로 Nginx + unicorn을 사용하고 있습니다. 내가 직면 한 문제는 트래픽이 올라갈 때마다 인스턴스 로그인을 부팅하고 git pull, 번들 업데이트 및 자산 사전 컴파일이 필요하다는 것입니다. 시간이 많이 걸립니다. 그래서이 모든 프로세스를 피하고 싶습니다.부팅하는 동안 서버에 번들 업데이트를 번들하는 가장 좋은 방법
이제이 AMI에서 새 인스턴스를 부팅하자마자 git pull, 번들 업데이트 및 사전 컴파일과 같은 전체 배포 프로세스를 자동화 할 수있는 스크립트/프로세스로 이동하려고합니다.
이 작업을 수행하는 가장 좋은 방법이 있습니까? 어떤 도움을 주시면 감사하겠습니다.
/etc/rc.local에 코드를 삽입 할 수 있습니다 (이 파일의 명령은 서버로드시 실행됩니다).
하지만 가장 좋은 방법은 (capistrano)입니다. deploy.rb 파일에 require "capistrano/bundler"을 추가해야하며 번들 업데이트가 자동으로 실행됩니다. 자세한 내용은이 문서를 읽을 수 있습니다 : https://semaphoreapp.com/blog/2013/11/26/capistrano-3-upgrade-guide.html 다른 방법이 (가 현재 어디에 있든 당신은 여전히이 내부의/var/www /에서 응용 프로그램을 탑재 또는 수)
별도의 EBS 볼륨에 응용 프로그램을 배포하는 것입니다
배포 한 후에는이 볼륨의 EBS 스냅 샷을 만듭니다. 새 인스턴스를 만들 때 스냅 샷에서 인스턴스에 대한 새 볼륨을 만들도록 ec2에 지시하므로 인스턴스는 이미 설치된 최신 보석/코드로 시작됩니다 (번들 설치에는 몇 분이 걸릴 수 있음). 모든 시작 스크립트는 볼륨을 마운트하는 것입니다 (또는 ami를 만들 때 fstab에 추가 한 경우에도 그렇게 할 필요가 없습니다). 나는 이와 같이 확장 작업을 선호하지 않습니다 (예 : 배포 할 때 github 또는 rubygems가 중단되는 경우 수행 할 작업)
아마존의 자동 확장 서비스를 사용하여 한 걸음 더 나아갈 수도 있습니다. 간단히 말하자면 ami, 인스턴스 유형, 볼륨 스냅 샷 등을 지정하는 실행 구성을 만듭니다. 그런 다음 고정 된 일정이나 cloudwatch 메트릭에 따라 그룹 크기를 수동으로 (웹 콘솔 또는 api를 통해) 제어합니다. Amazon은 시작 구성의 정보를 사용하여 필요에 따라 인스턴스를 만들거나 파괴합니다.
'capistrano'는이 작업이 많으므로 번들 업데이트/설치를위한 레시피를 작성하고 유니콘을 다시 시작할 수 있습니다 (작업자를 하나씩 다시 시작하고 시작합니다). –