Github Actions上とローカルMac上のmakeタスクの挙動が異なっていてプチハマりした件
タスクランナーとしてmakeタスクをよく利用しています。 その際、ローカルのMacで問題なく動くのに、GitHub Actions上で異なる動作になっていてプチハマりしてたのでメモします。 なお、GitHub Actionsで利用しているDocker Imageは ubuntu-latest です。 makeタスクの内容 docker composeのサービス起動待ちのために以下のようなワンライナーのタスクを作ることがあります。 [1] 以下は localhost:8080の疎通ができるまで1秒スリープしながら 600回繰り返す（おおよそ最大10分待つ） という何のことはないタスクです。 waiting-for-service: @echo "waiting for service ..." @for i in {0..600}; do if [ `curl -fs http://loca
Cloud Run Jobsを利用したマネージドCron(Scheduler)が便利
まだプレビュー版ではありますが、Cloud Run Jobsを利用すると、簡単にコンテナで動かせるcronジョブを設定することができて超便利なので紹介してみます。 疑問: 通常のCloud RunでもScheduler利用出来るのでは？ 出来ます。ただし、HTTPエンドポイントを独自で用意してあげたり、PubSubと連携する必要があり、若干の面倒くささがあります[1]。 しかし Cloud Run Jobsを利用すると Scheduler(Cron)からCloudRunアプリ直接実行することが出来る のでとても手軽にCron実行が出来るのです。 実際にどうやるか ちなみにこの記事で書く内容は、ほぼCodeLabsの Cloud Run ジョブを使ってみる から抜粋した内容になりますので、一から試して理解したい方はこちらをご参照ください。 なお、アプリケーションの詳細や権限設定については割愛
GitHubでプルリクエストを一発で作るURL
CI/CD と プルリクエスト こちらの記事のようにブランチとリリースが紐付いていることがあります。 その際、自動でPRを作る対応をしても良いんですが、デプロイフロー上難しかったりサクッと対応したい場合などはREADMEにPR作成リンクなど貼っておくだけで簡易的なリリース運用は出来そうです。 それを実現するためにどのような方法があるかを調べてみました。 普通にPRを作るURL 最初にブランチを push するときにプルリクエストを作るリンクが画面に表示されていると思います。 確認すると以下のようなフォーマットになっていますね。 もちろんこのフォーマットでも良いんですが、実はカスタマイズしにくいエンドポイントなので他の方法を探します。 ブランチをカスタマイズしてPRを作るURL 実は公式ドキュメントに クエリパラメータを利用したプルリクエストの作成 についての記述があります。 ここを見ると、
GitHub Actionsでワークフローは使いまわしたいけど環境別に変数切り替えしたい場合
要するに、staging環境とproduction環境でやることは一緒だけど環境変数だけ切り替えて利用したい ということを実現したい。 変数受け渡し周りで意外とハマったのでメモしておく。 ブランチ・デプロイ戦略 Gitlab Flow がわかりやすいのでこれベースで説明していく。 以下のデプロイフローを想定。 環境毎のブランチにpushされると、GitHub Actionsでその環境にデプロイする - developブランチにpushすると、develop環境にデプロイ - stagingブランチにpushすると、staging環境にデプロイ - productionブランチにpushすると、production環境にデプロイ ファイル構成設計 以下のような感じで置くイメージ .github/ workflows/ deploy.yaml > 共通で利用できる実際に実行するワークフローya
TerraformでCloud SQLの自動バックアップを行う設定
公式ドキュメントには設定の説明は書いてはいるが、そのまま利用できるexampleが意外と見つからなかったのでメモ。 設定 resource "google_sql_database_instance" "instance" { name = "db-instance-name" region = "asia-northeast1" database_version = "POSTGRES_14" settings { tier = "db-f1-micro" # 自動バックアップ設定 backup_configuration { enabled = true # UTC(JST=02:00) start_time = "17:00" # mysql #binary_log_enabled = true # postgres #point_in_time_recovery_enabled =
Terraformでリソース不整合になったときにはstate rmで解決するかもしれない
※注意 terraform state rm で解決するのはおそらく場合によります 状況 tfファイルでresourceAとresourceBが同じ実リソースを向いてしまってて、その状態でplanがno changeになる状況。 具体的なイメージはこんな感じ。 同じ名前のDBユーザを作ろうとしてしまった感じですね（これ自体は設定ミス） # resourceA resource "google_sql_user" "dbuserA" { name = "hoge" # > 同じユーザを作ろうとしてしまっている！ instance = "instance1" password = "hogepass" } # resourceB resource "google_sql_user" "dbuserB" { name = "hoge" # > 同じユーザを作ろうとしてしまっている！ instan
Cloud Run上で動かすNext.jsアプリのDockerイメージサイズを軽くする
業務にて Cloud Run内でNext.jsアプリを動かすことになった。 その時イメージサイズについて四苦八苦した結果、ある程度の最適化ができたのでその時の検証結果をここに記しておく。 準備編：イメージサイズ検証のためのアプリケーション yarn create next-app コマンドのオプションを設定することにより、Docker内で動作するサンプリアプリケーションのテンプレートを作ることが可能なので今回はそれを利用して検証してみる。 以下のコマンドで nextjs-docker というアプリケーションが作られる。 $ yarn create next-app --example with-docker nextjs-docker ... $ cd nextjs-docker ＄ yarn dev yarn run v1.22.19 $ next dev ready - started
Postgresqlのserial型カラムのシーケンスを取得・設定したい
現象 Postgresqlのローカル環境構築で、serial型に対して値を指定して初期データロードした結果、シーケンス値が進まずに登録されてしまってInsert時にDuplicate Errorになってしまうという事案があった。 -- create > CREATE TABLE animal ( id SERIAL, name VARCHAR(10), PRIMARY KEY(id) ); -- initial load > INSERT INTO animal (id, name) VALUES (1, 'cat'); > INSERT INTO animal (id, name) VALUES (2, 'dog'); -- insert (without id) > INSERT INTO animal (name) VALUES ('tiger'); ERROR: duplicate
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Cloud Run内で利用するDNSサーバ設定について