Azure App Service용 Linux Ruby 앱 구성
이 문서에서는 Azure App Service가 Linux 컨테이너에서 Ruby 앱을 실행하는 방법 및 필요한 경우 App Service의 동작을 사용자 지정하는 방법에 대해 설명합니다. Ruby 앱은 필요한 gems를 모두 사용하여 배포해야 합니다.
이 가이드에서는 App Service에 기본 제공된 Linux 컨테이너를 사용하는 Ruby 개발자를 위한 주요 개념과 지침을 제공합니다. Azure App Service를 사용한 경험이 없는 경우 먼저 Ruby 빠른 시작 및 PostgreSQL을 사용하는 Ruby 자습서를 수행해야 합니다.
Ruby 버전 표시
현재 Ruby 버전을 표시하려면 Cloud Shell에서 다음 명령을 실행합니다.
az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion
지원되는 Ruby 버전을 모두 표시하려면 Cloud Shell에서 다음 명령을 실행합니다.
az webapp list-runtimes --os linux | grep RUBY
대신 사용자 고유의 컨테이너 이미지를 빌드하여 지원되지 않는 Ruby 버전을 실행할 수도 있습니다. 자세한 내용은 사용자 지정 Docker 이미지 사용을 참조하세요
Ruby 버전 설정
Cloud Shell 다음 명령을 실행하여 Ruby 버전을 2.7로 설정합니다.
az webapp config set --resource-group <resource-group-name> --name <app-name> --linux-fx-version "RUBY:2.7"
참고
배포 중에 다음과 비슷한 오류가 표시되는 경우:
Your Ruby version is 2.7.3, but your Gemfile specified 2.3.1
또는
rbenv: version `2.3.1' is not installed
즉 프로젝트에 구성된 Ruby 버전이 실행 중인 컨테이너에 설치된 버전과 다릅니다(위의 예제에서 2.7.3). 위의 예제에서 Gemfile 및 .ruby-version을 모두 확인하고, Ruby 버전이 설정되어 있지 않거나 실행 중인 컨테이너에 설치된 버전으로 설정되어 있는지 확인합니다(위의 예제에서 2.7.3).
환경 변수 액세스
App Service에서, 앱 코드 외부에서 앱 설정을 지정할 수 있습니다. 그런 다음, 표준 ENV['<path-name>'] 패턴을 사용하여 액세스할 수 있습니다. 예를 들어 앱 설정 WEBSITE_SITE_NAME에 액세스하려면 다음 코드를 사용합니다.
ENV['WEBSITE_SITE_NAME']
배포 사용자 지정
Git 리포지토리를 배포하거나 빌드 자동화가 사용되는Zip 패키지를 배포하면 배포 엔진(Kudu)은 기본값으로 다음 배포 후 단계를 자동으로 실행합니다.
- Gemfile이 있는지 확인합니다.
bundle clean을 실행합니다.bundle install --path "vendor/bundle"을 실행합니다.bundle package를 실행하여 gem을 vendor/cache 폴더에 패키지합니다.
--without 플래그 사용
--without 플래그를 사용하여 bundle install을 실행하려면 BUNDLE_WITHOUT앱 설정을 쉼표로 구분된 그룹 목록으로 설정합니다. 예를 들어 다음 명령은 플래그를 development,test로 설정합니다.
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings BUNDLE_WITHOUT="development,test"
이 설정이 정의되면 배포 엔진에서 --without $BUNDLE_WITHOUT를 사용하여 bundle install을 실행합니다.
자산 미리 컴파일
배포 후 단계에서는 기본적으로 자산을 미리 컴파일하지 않습니다. 자산을 미리 컴파일하도록 설정하려면 ASSETS_PRECOMPILE앱 설정을 true로 설정합니다. 그러면 배포 후 단계의 끝에서 bundle exec rake --trace assets:precompile 명령이 실행됩니다. 예를 들면 다음과 같습니다.
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings ASSETS_PRECOMPILE=true
자세한 내용은 정적 자산 제공을 참조하세요.
시작 사용자 지정
기본적으로 Ruby 컨테이너는 다음 순서로 Rails 서버를 시작합니다(자세한 내용은 시작 스크립트 참조).
- 아직 없는 경우 secret_key_base 값을 생성합니다. 이 값은 앱을 프로덕션 모드에서 실행하는 데 필요합니다.
RAILS_ENV환경 변수를production으로 설정합니다.- 이전에 실행된 Rails 서버에서 남긴 tmp/pids 디렉터리에서 .pid 파일을 삭제합니다.
- 모든 종속성이 설치되어 있는지 확인합니다. 그렇지 않은 경우 로컬 vendor/cache 디렉터리에서 gem을 설치합니다.
rails server -e $RAILS_ENV을 실행합니다.
시작 프로세스는 다음과 같은 방법으로 사용자 지정할 수 있습니다.
정적 자산 제공
Ruby 컨테이너의 Rails 서버는 기본적으로 프로덕션 모드에서 실행되며, 자산이 미리 컴파일되어 웹 서버에서 제공된다고 가정합니다. Rails 서버에서 정적 자산을 제공하려면 다음 두 가지 작업을 수행해야 합니다.
자산 미리 컴파일 - 정적 자산을 로컬로 미리 컴파일하고 수동으로 배포합니다. 또는 배포 엔진이 대신 처리하도록 합니다(자산 미리 컴파일 참조).
정적 파일 제공 사용 - Ruby 컨테이너에서 정적 자산을 제공하려면
RAILS_SERVE_STATIC_FILES앱 설정을true로 설정합니다. 예를 들면 다음과 같습니다.az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings RAILS_SERVE_STATIC_FILES=true
비 프로덕션 모드에서 실행
Rails 서버는 기본적으로 프로덕션 모드에서 실행됩니다. 예를 들어 개발 모드에서 실행하려면 RAILS_ENV앱 설정을 development로 설정합니다.
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings RAILS_ENV="development"
그러나 이 설정만으로 인해 Rails 서버가 개발 모드로 시작되어 localhost 요청만 허용되고 컨테이너 외부에서는 액세스할 수 없습니다. 원격 클라이언트 요청을 허용하려면 APP_COMMAND_LINE앱 설정을 rails server -b 0.0.0.0으로 설정합니다. 이 앱 설정을 사용하면 Ruby 컨테이너에서 사용자 지정 명령을 실행할 수 있습니다. 예를 들면 다음과 같습니다.
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings APP_COMMAND_LINE="rails server -b 0.0.0.0"
수동으로 secret_key_base 설정
App Service에서 해당 값을 생성하는 대신 사용자 고유의 secret_key_base 값을 사용하려면 SECRET_KEY_BASE앱 설정을 원하는 값으로 설정합니다. 예를 들면 다음과 같습니다.
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings SECRET_KEY_BASE="<key-base-value>"
진단 로그 액세스
App Service의 애플리케이션 코드 내부에서 생성된 콘솔 로그에 액세스하려면 Cloud Shell에서 다음 명령을 실행하여 진단 로깅을 켭니다.
az webapp log config --resource-group <resource-group-name> --name <app-name> --docker-container-logging filesystem --level Verbose
--level에 대한 가능한 값은 Error, Warning, Info 및 Verbose입니다. 각 후속 수준에는 이전 수준이 포함됩니다. 예를 들어 Error에는 오류 메시지만 포함하고 Verbose에는 모든 메시지를 포함합니다.
진단 로깅이 설정되면 다음 명령을 실행하여 로그 스트림을 확인합니다.
az webapp log tail --resource-group <resource-group-name> --name <app-name>
콘솔 로그가 즉시 표시되지 않으면 30초 후에 다시 확인합니다.
참고
https://<app-name>.scm.azurewebsites.net/api/logs/docker의 브라우저에서 로그 파일을 검사할 수도 있습니다.
언제든지 로그 스트리밍을 중지하려면 Ctrl+C를 입력합니다.
브라우저에서 SSH 세션 열기
컨테이너와 직접 SSH 세션을 열려면 앱을 실행해야 합니다.
브라우저에 다음 URL을 붙여넣고 <app-name>을 앱 이름으로 바꿉니다.
https://<app-name>.scm.azurewebsites.net/webssh/host
아직 인증을 받지 못한 경우 연결하기 위해서는 Azure 구독에서 인증을 받아야 합니다. 인증되면 컨테이너 내부에서 명령을 실행할 수 있는 브라우저 내부 셸을 확인합니다.
참고
/home 디렉터리 외부에서 변경한 사항은 컨테이너 자체에 저장되며 앱을 다시 시작한 이후에는 유지되지 않습니다.
로컬 컴퓨터에서 원격 SSH 세션을 열려면 원격 셸에서 SSH 세션 열기를 참조하세요.
로그의 robots933456
컨테이너 로그에 다음 메시지가 표시될 수 있습니다.
2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"
이 메시지는 무시해도 괜찮습니다. /robots933456.txt는 App Service에서 컨테이너가 요청을 처리할 수 있는지 확인하기 위해 사용하는 더미 URL 경로입니다. 404 응답은 단순히 경로가 존재하지 않는다는 것을 나타내지만 컨테이너가 정상 상태이고 요청에 응답할 준비가 되었음을 App Service에 알려줍니다.