![プログラミング]()
![Polygon]()
プログラミング
LaravelをCloud Runにデプロイして効率よくバックエンドを開発しよう！
何円ぐらいで済むの?
以下の手順で60.77時間、動かしてみました。リージョンは全て東京(asia-northeast1)です。
結果MySQL 実行: 97円MySQL ストレージ: 11円ストレージ(NA-APAC間の通信): 5円以上、113円でした。
一時間1.85円として計算すると、1ヶ月で1338円になります。
お詫びすいません、ケチれませんでした！！！！！
ただ、GitHubからデプロイすることで効率の良い開発スケール他GCPサービスとの円滑な連携が可能になる点は見逃せません。余裕のある方は試してみてください。
下準備GCPのセットアップgcloud CLIをインストールしておく。環境によって手順が異なるので省略。
プロジェクトを作り、支払いアカウントを紐づける。
gcloud auth loginまずはログインする。
PROJECT_NAME=(表示上のプロジェクトネーム)
PROJECT_ID=$(gcloud projects list --format 'value(projectId)' --filter name=$PROJECT_NAME)
export PROJECT_ID
gcloud config set project $PROJECT_ID
gcloud services enable \
containerregistry.googleapis.com \
cloudresourcemanager.googleapis.com \
iam.googleapis.com「表示上のプロジェクトネーム」はGCPの画面に出ているプロジェクト名。プロジェクトをセットし、APIを有効化する。
Terraformのインストールいつか使うんだろうなーと思っていた。入れてなかったのでここで入れておく。
brew install tfenv
tfenv install 0.12.6
tfenv use 0.12.6tfenvを使うのは、以下のテンプレートが0.12.6を想定していたから。随時変更しよう。
ステップ1. テンプレートを準備自分でやろうとしたがあまりにめんどくさかったので、以下のテンプレートを使う。
https://github.com/villers/laravel-cloud-run-sql
これをフォークしよう。
クローンしてビルドgit clone git@github.com:あなたのユーザー名/laravel-cloud-run-sql.git
cd laravel-cloud-run-sql
docker-compose build
euをasiaに東京で動かすので、レポジトリ内のeu.gcr.ioをasia.gcr.io に置換。
ローカルで試すdocker-compose up
起動の様子。なんでもDockerでやれば、なんかすごいことやってるみたいに見える。
docker-compose run --rm app php artisan migrate --seed
マイグレーションする。
http://localhost:8080/ で動作確認しよう。
ステップ2. GCPにコンテナをアップするサービスアカウントを用意するサービスアカウントを作り、Owner権限を与える。キーをダウンロードしてterraform-key.json として保存し、環境変数に設定、サービスアカウントとして認証する。それらが以下のコマンドでできる。ありがとうgcloud CLI!
gcloud iam service-accounts create deployer \
--display-name "Terraformのサービスアカウント"
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member serviceAccount:deployer@${PROJECT_ID}.iam.gserviceaccount.com \
--role roles/owner
gcloud iam service-accounts keys create ~/terraform-key.json \
--iam-account deployer@${PROJECT_ID}.iam.gserviceaccount.com
export GOOGLE_APPLICATION_CREDENTIALS=~/terraform-key.json
gcloud auth activate-service-account --key-file=$GOOGLE_APPLICATION_CREDENTIALS
ビルド(M1注意)export SERVICE_NAME=laravel-app-service
docker build --platform linux/amd64 -f .cloud/docker/php/Dockerfile -t asia.gcr.io/${PROJECT_ID}/${SERVICE_NAME} .
上記コマンドでアジア用タグをつけたイメージをビルドする。間違ったタグをつけたりしたら、docker images からのdocker rmi [ID] で消せる。それか、Docker Desktopのイメージ画面を使う。
--platform linux/amd64 はM1用。ARMでビルドしてもデプロイで死ぬ。このせいで数時間が無駄になった。
レジストリにプッシュgcloud auth configure-docker
docker push asia.gcr.io/${PROJECT_ID}/${SERVICE_NAME}コンテナレジストリにログインして、さっきのをプッシュする。
ステップ3. 自動でCloud SQLとLaravelをデプロイTerraform初期化cd .cloud/terraform
terraform init
ついに初回デプロイexport REGION=asia-northeast1
export INSTANCE_NAME=laravel-app-service
terraform apply \
-var "region=${REGION}" \
-var "service=${SERVICE_NAME}" \
-var "project=${PROJECT_ID}" \
-var "instance_name=${INSTANCE_NAME}"
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value:
yesと打てば、Secret Managerでキーを作り`laravel`というサービスアカウントができCloud SQLにMySQLをセットアップCloud RunでLaravelをデプロイの4つが行われる。
Cloud SQLの部分でかなり時間がかかる。
Apply complete! Resources: 26 added, 0 changed, 0 destroyed.
Outputs:
result = The laravel-app-service is now running at https://<ここにURL>
If you haven't deployed this service before, you will need to perform the initial database migrations:
cd ../..
gcloud builds submit --project <ここにプロジェクトID> --config .cloudbuild/build-migrate-deploy.yaml \
--substitutions _APP_ENV=dev,_APP_DEBUG=true,_REGION=asia-northeast1,_INSTANCE_NAME=laravel-app-service,_SERVICE=laravel-app-service
The username and password are stored in these secrets:
gcloud secrets versions access latest --secret DATABASE_URL
✨
終わるとこんなんが出てくる。
Cloud Runの画面でもURLが確認できる。マイグレーションは後でやる。
GitHubと連動してビルド・デプロイさせる実はTerraformを使うのは初回だけでいい。あとはCloud Buildを活用しよう。
ルートにcloudbuild.yaml を作る。
cloudbuild.yamlsteps:
- id: 'build_and_push'
name: 'gcr.io/kaniko-project/executor:latest'
args:
[
# https://github.com/GoogleContainerTools/kaniko/issues/1427
"--dockerfile=.cloud/docker/php/Dockerfile",
"--cache=true",
"--cache-ttl=6h",
"--destination=asia.gcr.io/${PROJECT_ID}/${_SERVICE}",
]
- id: 'migrate'
name: 'gcr.io/google-appengine/exec-wrapper'
args: ['-i', 'asia.gcr.io/${PROJECT_ID}/${_SERVICE}',
'-s', '${PROJECT_ID}:${_REGION}:${_INSTANCE_NAME}',
'-e', 'PROJECT_ID=${PROJECT_ID}',
'-e', 'APP_ENV=${_APP_ENV}',
'-e', 'APP_DEBUG=${_APP_DEBUG}',
'--', 'php', 'artisan', 'migrate']
- id: 'deploy'
name: 'gcr.io/cloud-builders/gcloud'
args: ["run", "deploy", "${_SERVICE}",
"--platform", "managed",
"--region", "${_REGION}",
"--image", "asia.gcr.io/$PROJECT_ID/${_SERVICE}"]
options:
substitutionOption: ALLOW_LOOSE
substitutions:
_APP_ENV: prod
_APP_DEBUG: "false"
_SERVICE: laravel-app-service
_REGION: asia-northeast1
_INSTANCE_NAME: laravel-app-service
ビルドのトリガー設定を変更(重要)
次に、Cloud Runのページを開く。
このボタンでビルドのトリガーを作れる。
GitHubのレポジトリと接続すればいいが、Dockerfile は間違いなので修正が必要。
「EDIT CONTINUOUS DEPLOYMENT」から設定を開き、LocationをRepository に変える。 Cloud Build configuration file (yaml or json) を選択する。/cloudbuild.yaml になっているか確認。ブランチ名を変えた場合は、適宜トリガーの設定も変える。
プッシュすればビルド、プッシュ、マイグレーション、デプロイがされる。こちらのリンクからビルド履歴が見れる。
初回は時間がかかるが...
2回目以降はKanikoがキャッシュを活用してくれる。大体二分で終わる。
え? FTPで差分をアップした方が早い? 確かにそうかもしれない。だが、全部自動化バージョンを戻せる環境を簡単に再現という点で明らかに効率がいい。積極的に活用していこう。
![>]()
内容を見る
![プログラミング]()
![Polygon]()
プログラミング
VSCodeのVueでpropsの型チェックをする方法 (TypeScript)
注意書き
以下の内容はVSCode 1.16.2Vetur v0.35.0Nuxt v3.0.0-27252999.d2cc9e4 (Vue: 3.2.20)Next 11.1.2 (React: 17.0.2)時点の内容です。あと、当然ですが全てTypeScriptです。
Nuxt3はまだベータ版ですが、起動が早い + TypeScriptが使いやすいので皆さんも試してみてください。
Vueでpropsの型チェックをさせる方法ステップ1. Veturを入れるhttps://github.com/vuejs/vetur
これがないと話にならないです。
ステップ2. 設定を変えるなぜかデフォルトで型チェックできないので、settings.json に以下の設定を追記します。
{
(前略)
"vetur.validation.templateProps": true,
"vetur.experimental.templateInterpolationService": true,
(後略)
}
ステップ3. コンポーネントを作成する<template>
<div>
<h2>{{ name }}様</h2>
<div v-if="age">
<b>{{ age }}歳なので</b>
<span>わいの{{ age && age / 20 }}倍！</span>
</div>
</div>
</template>
<script lang="ts">
export default {
name: "TestComponent",
props: {
name: {
type: String,
required: true,
},
age: {
type: Number,
required: false,
},
},
}
</script>
name は文字列(必須)で、年齢は数値(任意)です。
「名前と年齢を受け取って、年齢があれば俺の年齢と比較する」という意味不明なコンポーネントです。
ステップ4. ページで使ってみる<template>
<div>
<TestComponent name="aaa" :age="100" />
</div>
</template>
<script lang="ts">
import TestComponent from "../components/TestComponent.vue"
export default {
components: { TestComponent },
}
</script>
こんな感じでページで使います。
できましたね。
ステップ5. エラーを起こしてみる<TestComponent name="aaa" age="100" />
試しにこう書いてみてください。
Type 'string' is not assignable to type 'number'.
Veturから怒られるはずです。なぜならage="100" が文字列の「100」を渡しているからです。
が、templateInterpolationService がまだ「experimantal」なので、エラーが出る場所がおかしいです。
ちょっと待って！Reactで書けばいいやんあのですね、なんで単なる自動補完に、拡張機能と設定がわざわざ必要なんですか?
Reactで同じことをやってみてください。何も設定がいらないです。
ステップ1. コンポーネントを書くinterface Props {
name: string;
age?: number;
}
const TestComponent: React.VFC<Props> = (props) => (
<div>
<h2>{props.name}様</h2>
{props.age && (
<div>
<b>{props.age}歳なので</b>
<span>わいの{props.age / 20}倍！</span>
</div>
)}
</div>
);
export default TestComponent;
めっちゃ短くなります。
型の定義も、ただTypeScriptのinterfaceを書けばいいのです。Vueのprops よりスッキリしていて見やすいでしょう？
Next.jsのページで使うimport TestComponent from '@/components/TestComponent';
import { NextPage } from 'next';
const TestPage: NextPage = () => (
<div>
<TestComponent name="aaa" age={100} />
</div>
);
export default TestPage;
もしage に数値以外を渡すと、その場でエラーが出ます。繰り返しますが、拡張機能や設定は必要ありません。
Vueはpropsだけで記述量が多すぎるそもそもですね、たかが「名前と年齢を出す」だけで記述量が多すぎるんですよ。
export default {
name: "TestComponent",
props: {
name: {
type: String,
required: true,
},
age: {
type: Number,
required: false,
},
},
}
これ、「nameとageを受け取る」ってだけですよ。長すぎるでしょ。
interface Props {
name: string;
age?: number;
}
const TestComponent: React.VFC<Props> = (props) => (
<div>
<h2>{props.name}様</h2>
{props.age && (
<div>
<b>{props.age}歳なので</b>
<span>わいの{props.age / 20}倍！</span>
</div>
)}
</div>
);
export default TestComponent;
さっきも書きましたけど、Reactはテンプレート自体を含めてこの長さですからね。絶対こっちの方が時間の節約になります。
以上、俺がReactを使う理由の記事でした。
---
あれ？なんの記事だったっけ？
思い出した！自動補完や！
以上、VSCodeのVueでpropsの型チェックをさせる方法でした。
![>]()
内容を見る
