はじめに こんにちは、クラウドエースのイリゴチです。 社内外のレポートやチェックシートなど、PDF を Google Cloud Storage に保存して運用するケースは多いと思います。 しかし、バケットを「非公開」のまま Looker Studio の表に「PDF を開く」リンクを出したい、というニーズも少なくありません。 本記事では、Cloud Run Functions（2nd gen） で「署名付き URL」を発行して即リダイレクトする小さな HTTP 関数を用意し、Looker Studio の 計算フィールド でその関数 URL を組み立ててクリック可能なリンクを表示す

SCSK いわいです。 前回からだいぶ間が空いてしまいましたが、今回はRaspberry Pi 5で気温/気圧/湿度センサーを使って測定し、 Webで表示するシステムを構築したいと思います。 DBに取得データを格納し、あとから検索できるといろいろ便利です。 今回は前回セットアップした環境をそのまま流用します。(Rapspberry Pi5のみ) Raspberry PiでWebサーバ(冗長構成)を構築②　今度はセンサー 前回はRaspberry Pi 2台でWebサーバを冗長化し、LED点灯を行いました。今回は気温/気圧/湿度センサーを使って情報取得部分を冗長化します。 blog.usize-tech.com 2025.02.17   下準備 使用するRaspberry Piは前回同様に以下のものです。 【Raspberry Pi 5】 CPU: Broadcom BCM2712 quad-core Arm Cortex A76 processor @ 2.4GHz Memory: 8GB OS: Bookworm 前回同様にflaskを利用してWeb画面に測定結果を表示、DBから過去の測定結果を表示できるシステムを組んでみます。 【追加で用意するもの】 温湿度・気圧センサーモジュールキット(BME280使用)  ジャンパーケーブル×５ ブレッドボード×1 Webサーバアクセス用PC   システムのイメージ PythonでFlaskアプリケーションを作成します。今回はWeb画面に測定結果をグラフ表示するようにしてみます。 さらにDB（sqlite3）を使用して、センサーでの測定結果をローカルDB(bme280_data.db)に格納し、 過去のデータを検索できるようにします。 イメージはこんなカンジで。   今回のシステムで導入する機能と各ライブラリの説明は以下のとおりです。 機能 ライブラリ 説明 Webサーバ Flask 軽量なWebフレームワーク。センサー値や予測結果をWebアプリとしてブラウザに表示。 センサー通信 Smbus2 ラズパイとI2C通信する。BME280と通信するために利用。   bme280 Bosch製の温湿度・気圧センサー BME280用のPythonライブラリ。データ取得する。 データ保存 sqlite3 軽量な組み込み型データベースSQLiteを操作するためのライブラリ。計測データをローカルDBに保存・検索するために利用。 時刻処理 datetime 計測時刻の記録に利用。ローカルDBに保存するtimestampを生成。 Flaskとsmbus2とbme280は前回導入済み、sqlite3とdatetimeはデフォルトでインストールされているライブラリです。   温湿度・気圧センサーモジュールキットとRaspberry Piを接続する 前回同様にブレッドボードに温湿度・気圧センサーモジュールキットを接続します。 ※BME280のSDOもRaspberry Piの6ピンに接続します。 　　　 次に回路とRaspberry Pi 5を接続します。 センサ側 Raspberry Pi 5 BME280 VDD 3.3V：1ピン BME280 GND GND：9ピン BME280 SDI GPIO2(SDA)：3ピン BME280 SDO GND：6ピン BME280 SCK GPIO3(SDL)：5ピン 【Raspberry Pi 5のピン配置】 Raspberry Pi 5 Pinouts including GPIO for the 40 Pin Header – element14 Community 接続が終わったら、以下のコマンドを実行します。 sudo i2cdetect -y 1 実行結果に「76」という表記があれば、正常に接続できています。   Pythonスクリプトの作成 ファイル名はtemp_DB.pyにしてみました。 ChatGPTを利用してPythonスクリプトを作りました。 Pythonスクリプトで実行していることは以下です。 センサーからデータを読む BME280から温度・湿度・気圧の最新値を取得します。 データを保存する 取得した値を毎回データベース(SQLite)に記録していきます。 Webページで表示する FlaskでWebページを作り、以下を表示します。 最新の値（温度・湿度・気圧） データをグラフ化したもの 期間や間隔を指定した検索グラフ   2秒ごとに自動更新 ブラウザは2秒ごとに新しい測定値を取りに行き、自動でグラフや数値を更新します。 データ検索 期間と間隔を指定して、過去データをまとめてグラフ表示します。 Pythonスクリプトの実行 次に各Raspberry PiでWebサーバを起動します。 python3 temp_DB.py   Webブラウザからアクセス Webサイトアクセス用PCでブラウザを起動し、以下のURLにアクセスします。 http://Raspberry Pi 5のIPアドレス:5000 センサーが稼働し、2秒ごとに現在の「温度」「気圧」「湿度」が表示されます。 画面右側では2秒ごとに「温度」「気圧」「湿度」のグラフが表示されます。 画面下側では過去データの検索結果を表示します。 これで乾燥対策もばっちりです。 次はDBに格納したデータを使っていろいろ試してみたいと思います。

G-gen の杉村です。当記事では、Google Cloud のフルマネージドなコンテナプラットフォームである Cloud Run サービスで、 ビルドなしのソースコードからのデプロイ （Deploy from source without build）を試してみた結果をご紹介します。 はじめに Cloud Run サービスのデプロイ方法 制約事項 前提条件 関連記事 ディレクトリとソースコードの準備 パッケージのインストール デプロイと動作確認 ビルドありの場合との比較 デプロイの所要時間 起動時のパフォーマンス はじめに Cloud Run サービスのデプロイ方法 Cloud Run サービスにおけるデプロイは、大きく分けて「コンテナイメージによるデプロイ」「ソースコードからのデプロイ」の2種類があります。このうち後者の「ソースコードからのデプロイ」は、さらに2種類に分けられます。 ビルド あり のソースからのデプロイ（Deploy from source with build） ビルド なし のソースからのデプロイ（Deploy from source without build） 上記のうち 1. は、ソースコードを指定するだけで、コマンドライン等から簡単に Cloud Run にデプロイできる手法です。デプロイにあたって Dockerfile の準備等は必要ありません。ソースコードの存在するディレクトリでコマンドライン等によりデプロイを実行すると、自動的に Cloud Build による Docker イメージのビルドが開始され、Cloud Run サービスにデプロイされます。 一方で 2. は、Cloud Build による Docker イメージのビルドをスキップします。ソースコードの存在するディレクトリでコマンドライン等によりデプロイを実行すると、アプリケーションのパッケージが Cloud Storage バケットにアップロードされます。Cloud Run では指定された各言語向けのベースイメージが実行され、その上でパッケージを取得して実行します。 参考 : Deploy services from source code 当記事では、 2. のビルド なし のソースからのデプロイを実際に試してみた結果をご紹介します。 制約事項 ビルドなしのソースからのデプロイでは、以下のような制約事項があります。 Cloud Run jobs では使用不可 特定のランタイムしかサポートされない（Node.js、Python、Go、Java 等） ソースアーカイブは圧縮後 250 MiB 以下 バイナリやスクリプトは x86 アーキテクチャ互換のみ すべての依存関係がパッケージ化されている必要あり その他の制約事項や最新情報は、以下の公式ドキュメントを参照してください。 参考 : Deploy services from source code - Limitations 前提条件 当記事の検証は、Google Cloud の Cloud Shell 上で行いました。 また、gcloud CLI のバージョンは以下のとおりです。 Google Cloud SDK 548.0.0 2025年11月21日現在（検証実施時）の Cloud Shell には、デフォルトで Google Cloud SDK 547.0.0 がインストールされており、このバージョンでは後に紹介する gcloud beta run deploy コマンドの --no-build オプションが実装されていませんでした。同バージョンでコマンドを実行しようとすると、以下のエラーが出力されます。 ERROR: (gcloud.beta.run.deploy) unrecognized arguments: --no-build 同オプションを使用するため、検証に先んじて gcloud コマンドをバージョンアップしました。 参考 : Install the gcloud CLI - Manage an installation 関連記事 Cloud Run の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp ディレクトリとソースコードの準備 アプリケーションの専用ディレクトリを作成し、以下のファイルを準備しました。 main.py requirements.txt main.py は、Cloud Storage オブジェクト gs://my-sample-bucket/sample.txt の情報を取得（describe）して標準出力に出力するシンプルなものです。ソースコードパッケージに Google Cloud クライアントライブラリを含めてデプロイするケースを検証したいため、このようなアプリケーションにしました。 main.py import json import os import sys # モジュールを検索する対象パス（sys.path）に packages を追加 sys.path.insert( 0 , os.path.join(os.path.dirname(__file__), 'packages' )) from flask import Flask from google.cloud import storage app = Flask(__name__) @ app.route ( '/' ) def describe_gcs_object (): bucket_name = "my-sample-bucket" blob_name = "sample.txt" try : storage_client = storage.Client() bucket = storage_client.bucket(bucket_name) blob = bucket.get_blob(blob_name) if blob is None : return f "Object {blob_name} not found in bucket {bucket_name}." , 404 # 日付時刻をテキスト形式に変換 time_created_text = blob.time_created.strftime( "%Y-%m-%d %H:%M:%S UTC" ) updated_text = blob.updated.strftime( "%Y-%m-%d %H:%M:%S UTC" ) # ログ出力内容 properties = { "message" : "Object metadata has been printed to standard output." , "Bucket" : blob.bucket.name, "Name" : blob.name, "Content-Type" : blob.content_type, "TimeCreated" : time_created_text, "Updated" : updated_text, "Size" : blob.size, "Generation" : blob.generation, "Metageneration" : blob.metageneration, "Etag" : blob.etag, "Crc32c" : blob.crc32c, "ComponentCount" : blob.component_count, "StorageClass" : blob.storage_class, } message_json = json.dumps(properties) print (message_json) return "OK" except Exception as e: print (f "Error describing Cloud Storage object: {e}" , file =sys.stderr) return "An error occurred." , 500 if __name__ == "__main__" : app.run(debug= True , host= '0.0.0.0' , port= int (os.environ.get( 'PORT' , 8080 ))) requirements.txt Flask== 2.3 . 2 gunicorn== 20.1 . 0 google-cloud-storage== 2.7 . 0 パッケージのインストール ソースコードと同じディレクトリに、サブディレクトリ packages を作成しました（名称は任意）。 mkdir packages その後、以下のコマンドを実行しました。 pip install -r requirements.txt -t packages このコマンドにより、ディレクトリ packages に、必要な Python ライブラリが格納されます。 デプロイと動作確認 ソースコードと同じディレクトリで、以下のコマンドを実行します。 gcloud beta run deploy my-test-service \ --project = my-project \ --region = asia-northeast1 \ --no-allow-unauthenticated \ --source . \ --no-build \ --base-image = us-central1-docker.pkg.dev/serverless-runtimes/google-22/runtimes/python312 \ --command = python \ --args = main.py およそ30秒後、デプロイが完了しました。以下のコマンドで動作確認をしたところ、オブジェクトの情報が Cloud Logging に出力され、期待どおりに動作することが確認できました。 curl -X GET " https://my-test-service-1234567890.asia-northeast1.run.app " \ -H " Authorization: bearer $( gcloud auth print-identity-token ) " ビルドありの場合との比較 デプロイの所要時間 今回検証した「ビルド なし のソースからのデプロイ（Deploy from source without build）」のデプロイは、30秒〜35秒程度で完了しました。 もう1つの手法であるビルド あり のソースからのデプロイ（Deploy from source with build）とのデプロイ所要時間を比較するため、同じソースコードとパッケージを、ビルドありの手法でデプロイしました。その結果、所要時間は2分00秒〜2分05秒程度でした。 起動時のパフォーマンス 「ビルドなしのソースからのデプロイ」では、各言語ランタイム向けのベースイメージを使用してコンテナを起動します。Cloud Run はコンテナが立ち上がった後にソースコードを取得・展開し、実行環境を整えます。 そのため、事前にソースコードをイメージ内にビルド（内包）しておく他の手法と比較すると、コンテナ起動時に「ソースコードの取得・展開」という処理が加わります。 これにより、特にコールドスタート時（初回アクセス時）において、リクエストからレスポンスが返るまでのレイテンシが増加する可能性があります。 ただし、このパフォーマンスへの影響について公式ドキュメントへの明記はなく、当記事でも高負荷なパッケージを用いた検証までは行えていません。あくまで仕様から推測される懸念点であるため、本番環境での採用を検討される際は、従来のデプロイ手法とパフォーマンスを比較検証することを推奨します。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it