배경

약간의 처리를 GCE의 f1-micro 인스턴스로 docker를 사용해 정기 실행하고 있었습니다만, 왠지 작년 11월경부터 동작이 무거워져 처리가 완료할 수 없게 되었습니다. 원래 spec 부족이라고 생각했기 때문에, 최근에 알았던 Cloud Run이라면 Ruby 그대로 이행할 수 있는 것이 아닐까, 라고 생각했습니다.

Cloud Run에서는 볼륨에 해당하는 기능을 사용할 수 없으므로 파일에 저장된 데이터를 다른 방법으로 저장해야 했습니다. 시행착오의 결과, 이번은 Firestore에 보존하는 것이 좋다고 하는 결론이 되었으므로, 이 기사를 쓰고 있습니다.

샘플

Ruby2.6은 현재 Ruby2.7에서 grpc gem을 bundle 할 수 없기 때문입니다. 며칠 후에 할 수있는 기색이 있습니다. .

요점

Cloud Run은 처리 내용이 무엇이든 HTTP 요청을 받고 실행하는 메커니즘입니다. 따라서 기존 처리를 요청이 오면 실행하는 웹 응용 프로그램으로 다시 작성해야 합니다.

Cloud Run은 동일한 프로젝트라면 구성을 전혀 수행하지 않고 Firestore에 액세스할 수 있습니다.

이동하는 방법

1개 1개의 프로세스는 각 서비스의 기본적인 것이므로, 공식 문서나 Google등에서 조사할 수 있다고 생각합니다.

Firestore 데이터

GCP의 동일한 프로젝트에서 Firebase를 실행하고 Firestore도 이동하도록 하고 다음과 같이 데이터를 넣습니다.

컨테이너 빌드

gcloud builds submit . --project=your-awesome-project --config=cloudbuild.yaml

프로젝트 이름을 바꾸자.

서비스 설정

서비스가 구성되면 자동으로 첫 번째 배포가 이루어지므로 즉시 실행할 수 있습니다.

실행

Firestore의 데이터를 당겨서 이것을 알 수 있습니다.

지금까지 Cloud Run을 움직이는 이야기는 끝입니다. 이어서 개발 시에 손으로 동작시키는 방법에 대해 씁니다.

손으로 움직이는 방법

서비스 계정 키 발급

게시할 때 JSON을 다운로드하여 저장합니다.

키 배치

리포지토리 아래에 data 디렉토리를 만들고 키 파일을 넣고,

env.sample

# Replace file name
GOOGLE_APPLICATION_CREDENTIALS=/data/your-awesome-project-deadbeef1234.json

키 파일의 이름으로 다시 쓰고 .env로 저장합니다. 이 환경 변수는 Firestore용 gem이 읽습니다.

시작

docker-compose up

에서 http://localhost:8080 로 이동하여 {:foo=>"bar", :hoge=>"piyo"} 라고 표시되면 OK입니다.

TIPS

STDOUT.sync = true를 넣지 않으면 처리 로그가 나오지 않을지도

cron 같은 정기 실행하는 방법

이런 느낌의 설정으로 갈 수 있다