「GoogleComputeEngine」の記事 - Crieit

GCEからCloud Runに引っ越してみた

2020-04-06T07:53:02+09:00

当サービスCrieitをGoogle Compute EngineからCloud Runに引っ越ししてみました（2020/4）。選定理由、実際にやったこと、懸念点などを色々書いてみます。

費用についても書きたいのですが、まだ引っ越ししたばかりのためわかりません。１，２ヶ月ほど経ったら追記しますので気になる方はフォローやブックマークなどしておいてください。

※当記事は一部有料です。後半の実際にRunを使う方しか興味がなさそうな内容あたりは有料となっています。使ってみた感じやRunに関係ない引っ越しメモ等は無料です。費用については無料部分に書きます。

元々の構成

Compute Engineの1台構成です。f1-microインスタンスを利用しておりMySQLもこの中にインストールしているのでAlways FreeのおかげでWebサーバー、DBサーバー自体は無料運用です。ファイルなどはStorageです。

ちなみにLaravelで作られており、詳しい構成は下記に書かれています。
Crieitの構成

新しい構成

WebサーバーにCloud Run、DBサーバーはCloud SQL（db-f1-micro）にしました。Cloud SQLは無料枠がないため費用がかかりますが、とりあえず広告費用内でまかなえるので以前からそのうち使おうと思っていました。全部１台のサーバーに入れているのはやはりなんとなく怖かったため。

なぜ引っ越したのか

たまに落ちる

Compute Engineは普通のサーバーですので、やはり何らかの状況によって時々落ちるというかフリーズします。多分なにかボットのアクセスが激しい時にスワップしてしまってそのままになってしまうのだと思いますが。

とは言っても約２年くらい運営してきてそんな感じで止まることはめったにありませんでした。たまに数分だけ重いとMackerelから通知が来たりはしていましたが。ただ、最近1日に2回も大きなフリーズがあったので、さすがに怖くなったのが引っ越すことになった一番のきっかけかもしれません。

むちゃくちゃ遅い

リリースする時に深く考えず、us-eastに構築してしまいました。これのせいでもうとにかくすごく遅い。あらゆるページで表示されるまでに1秒位かかっていました。こちらも元々そのうちwestに引っ越したいなと思っていました。

なぜCloud Runを選択したのか

サーバーを管理したくなかった

最初から決めていたわけではなく、App EngineとCloud Runを試して決めよう、という感じでやっていました。どちらもマネージドで、自分でサーバーを管理する必要がありません。とにかくCloud SQLに費用を払うことになってでもサーバーを管理したくなくなったというのが一番の理由です。

結局Runの方を選んだのですが、理由としてはApp Engineはデプロイするために、結構ローカル開発環境を本番向けに変えたりスイッチしたりする必要があります。もちろんデプロイを自動化すればいい話ですが、そもそもその前に一旦試してみるのが面倒になってやめました。最初にCloud Runの実験をしていたのですが、そちらはDockerイメージ内で適当にファイルを調整すればいいのでローカル環境を汚さず簡単に試せて非常に良いと感じました。

デプロイが簡単

ローカルでコマンドをいくつか実行するだけでデプロイできます。バッチとしてまとめているので１コマンドで行けるようになりました。

@echo off
FOR /F %%i in ('git rev-parse HEAD') do set HASH=%%i
set IMAGE=gcr.io/プロジェクトID/イメージ名:%HASH%

@echo on
call gcloud builds submit --tag %IMAGE% --project プロジェクトID
call gcloud run deploy Runのサービス名 --image %IMAGE% --project プロジェクトID --region asia-northeast1 --platform managed --quiet

今回はやっていませんがCIによる自動化もコマンドベースなので簡単そうです。

GitHub Actionsを使うとCloud Runへのデリバリが最高に捗るぞ🚀 - Qiita

東京リージョンが使える

App EngineもCloud Runも東京リージョンが使えます。GCEのようにアメリカだけ無料、とかではないので安心です。ただまあネットワーク料がかかってくると思いますのでそちらは気になりますが。

実験したところ元々1秒くらいかかっていたページの表示が300～500ミリ秒くらいになっていました。すごく速いというわけではなさそうですが、とりあえず元々遅すぎたのでだいぶいい感じにはなりました。

安い？

Cloud Run自体はこんな感じで実際に使ったリソースの分しか消費されないので無料枠内で結構いけてしまうのかな…？　と感じました。これはでも実際どうかわからないため、１、２ヶ月ほどしたら追記します。

追記）ネットワーク料金が14円で、CPU、メモリは費用内で無料でした。やはりデプロイ時に設定するメモリ料での計算でなく、実際に使った量だけみたいです。

ロールバックも簡単

これは実際に使ってみて気づきましたが、デプロイのリビジョンが残っているため何か不具合などがあってロールバックしたくなったときも簡単に戻すことができます。このあたりはGAE等ほかの簡単デプロイ系サービスでも同じかもしれませんが。

実際にやったこと

ストレージの引っ越し

まずはアップロードされた画像が入っているストレージだけ先に引っ越しました。というのも、Crieitの場合アップロード画像は直接ストレージのURLを使うわけではなく、Now経由でCDNキャッシュさせて費用を節約させています(NowのエッジキャッシュでCloud Storage節約サーバー作成)。ということで、引っ越しても画像のURLが変わるわけではありませんし、独立して先に引っ越しできるため先に移動しました。

具体的には下記の方法です。転送機能が用意されています。S3やAzureからも可能のようです。Cloud Storage間であればコマンドでも可能です。僕の場合は1GBもなかったので一瞬で終わりました。

バケットの移動と名前変更

通信料金も変わると思いますが、引っ越すまでの期間であればたいして影響も無いでしょう。とりあえずこれで一つやることが完全に減らせました。

ファイル保存している部分の調整

セッションやキャッシュはデフォルトでファイル保存になっています。しかしCloud Runは必要に応じてインスタンスが立ち上がったりするためファイルだと正常にセッションの維持などができません。そのためデータベース保存に変更しました。具体的にはまず下記でマイグレーションファイルを生成して実行します。

php artisan session:table
php artisan cache:table

そしてあとは環境変数をdatabaseに変えます。

CACHE_DRIVER=database
SESSION_DRIVER=database

まあここは他にもRedisを使ったり自由で良いと思います。

あとはログの出力も変更しておきます。これもファイルだとログを見ることもできないため、stderrにしておきます。こうすると自動的にCloud Runのコンソール上でログを見ることができます（その他にもいくつか方法はあります）。

LOG_CHANNEL=stderr

DBの設定

今回はCloud SQLを使っています。接続にはCloud SQL Proxyを使っています。例えばLaravelの場合、下記のようにソケットを指定します。

DB_SOCKET=/cloudsql/インスタンス接続名

インスタンス名はCloud SQLの詳細画面で確認できます。

DBの移行

DBの移行は、元々使っているGoole Compute EngineにMySQLをインストールしていたので、mysqldumpを利用しました。サーバー上のデータをmysqldumpでダンプし、そしてcloud_sql_proxyを実行するとCloud SQLにソケットでアクセスできるようになりますので、それでインポートしました。具体的なインポート方法は下記のようになります。

mysql -u ユーザー名 -p -S /cloudsql/インスタンス接続名 < dump.sql

参考）
Cloud SQL Proxy を使用した接続
 GCEでcloud_sql_proxyが実行できない時

メンテナンスモード

ストレージもDBも、ユーザー操作中に移行を行うと一部データが失われてしまう可能性があります。そのためメンテナンスモードにしておく必要があります。

Laravelの場合、メンテナンスモードのコマンドが元々あるようなのでそちらを利用しました。メンテナンスモードに入るときは php artisan down 復帰するときは php artisan up です。

downの場合はメッセージや許可IPなども指定できます。

Maintenance Mode - Configuration - Laravel - The PHP Framework For Web Artisans

引っ越しの場合は新しいサーバーにアクセスが行くようになったらもう古いサーバーは使われませんので、upする必要もないかもしれません。

結局ネックとなるのはDBの同期です。Cloud Runの設定も含め、これ以外で事前にできることはなるべく済ましておきました。

プロキシ用の設定

元々Nginxを使っていた場合などは関係ない場合もありますが、プロキシ経由でなく直接アプリケーションにアクセスさせていた場合、このあたりの設定をする必要があります。例えばLaravelではTrustProxiesというミドルウェアのproxiesを許可するように設定しておく必要があります。

    protected $proxies = '*';

その他うまく動かない場合はSSLやホスト名の設定も問題ないか見てみる必要があります。Nginxのパターンとはちょっと違う可能性もありそうです。

バッチ等はどうしたか

Cloud RunはSSHアクセスできませんので、コマンドの実行や定期処理などは考える必要があります。一応公式としてはCloud Schedulerを使うということになっています。

Running services on a schedule

ただし、httpアクセスになるためちょっとコードを調整したりする必要もあり面倒です。そのため、今回はGCEからの移転ということもあり、定期処理や時々コマンドを実行したいときはもうそのGCE上で行うようにすることにしました。アプリケーションのDB接続もCloud SQLに行うようにしてあります。リージョンも違うので遅いとは思いますがどれも一瞬実行するだけなので問題は恐らく無いでしょう。Cloud SQLへの接続はcloud_sql_proxyをSystemdでサービス化して行っています（参考 GCP Cloud SQLにCloud SQL Proxyで接続しよう。Systemd化してデーモン化！ | システムガーディアン株式会社）。

以下は有料です。下記のような内容を書いています。

実際に作ったDockerfileの例（Laravel & Apache）
vendorフォルダが無視されることへの対処
.envファイルが無視されることへの対処
ポートの指定について
Dockerイメージのビルド方法（Cloud Buildの利用）
Cloud Runのサービスを作成する具体的な手順とエラーにならないようにするための注意点
独自ドメインの利用方法
ステージング環境の作成例
Cloudflareで525 SSL handshake failedエラーが出た場合

GCEでcloud_sql_proxyが実行できない時

2020-04-04T09:25:04+09:00

Google Compute EngineからCloud SQLに接続する方法は２つある。一つはプライベートIPで直接繋ぐ方法と、Cloud SQL Proxyを使う方法。リージョンが違ったりする場合はProxyを使う必要がある。

ここで実際にダンロードしてきたcloud_sql_proxyを実行するのだが、なんだかPermissionが足りないとか色々エラーが出て実行できない時がある。サービスアカウントの権限を見てみても、元々GCE用のサービスアカウントはガッツリ権限が付与されているので関係なさそう。

で、何だったかというと、サービスアカウントの権限以外にも、Compute Engine自体にCloud API アクセススコープというものがあり、それのSQLが有効になっていなかった。具体的にはCompute Engineのインスタンス詳細ページを一番下までスクロールすると書かれている。

これのSQLを有効にすれば実行できるようになる。ただし有効にするためにはサーバーを一度停止させる必要があるので注意。

GCEのMicro Instance with burstable CPU runningに注意

2020-03-08T22:46:20+09:00

GCPのGoogle Compute EngineにはAlways Freeによる無料枠があるため、f1-microというインスタンスタイプであればサーバー自体は無料で運用することができる。

ただし、あくまでもCloud Platformなので、実際にはサーバーを動作させるためのあれこれで費用がかかったりする。例えばネットワーク料金や、IPの料金など。もちろんこのあたりも無料枠があるので基本的にはだいたい無料で運用できる。かかるとしても数円程度。

料金が発生するパターン

しかし、色々試しているうちに費用が発生してしまうパターンが見つかった。料金表を見ていると「Micro Instance with burstable CPU running in Americas」ということで1,730円分も料金が発生していることに気づいた（無料クレジット期間のためまだ無料だが）。

これは何かというと、公式のマニュアルにも書かれているCPUバーストという機能。

CPU バースト

CPUが足りなくなった時に、自動的にCPUを一時的に追加してくれるというもの。追加料金は通常は無いのだが、f1-microのようなマシンタイプの場合はこのように追加料金になるらしい。

僕が前々から使っているこのCrieitなどで使っているf1-microサーバーではこの料金がかかったことはない。ただ、どうも使い方によってはこれが激しく使われる事があり、このように追加料金が発生してしまうっぽい。

具体的にはこの記事のパターンで発生した。

GCEをDBサーバーにしてGAEでサービスを無料運用する

単にDBサーバーとして利用していた、というだけなので、通常であればさほど料金が発生することはない。ただ、もしかしたら上記の構成だとちょこちょこ何かしらのアクセスや接続が発生してしまい、負荷につながってしまうのかもしれない。詳しいことは全くわからない。何にしろ、f1-microの無料枠は時間で決まっているので、このバーストにより時間が無料枠分を超えてしまう。

対処方法

GCPを利用し始めて1年間は無料クレジットが付いているため、基本的に問題になることは無いだろう。ちょこちょこ料金明細を見ておいて、おかしかったらその利用方法では費用が発生してしまう可能性があるため、構成を見直せばいい。それでどうしても費用とパフォーマンスがあわないようであればその間に他のサーバーを検討すればいい。

すでに無料クレジットの期間が終わってしまっている場合は注意が必要。無料だと思っていてこの料金がかかってしまうとちょっとびっくりする。

GCEをDBサーバーにしてGAEでサービスを無料運用する（を構築したけど費用がかかった）

2020-01-07T23:15:57+09:00

GCPでリリースしたサービスが1年経ち無料クレジットの期限をむかえそうになりました。Cloud SQLを使ってデプロイしたためその後は有料になってしまうのですが、誰も使っていないサービスのためなんとか無料で運用できる方法は無いかと考えました。ちなみに下記のような構成です。

Node.js
MySQL5.7

しかしサービスの性質上ちょっとデータベースのデータも多めで、HerokuのMySQLだと無料プランでは無理なのかな…という気がしました。そうするとMySQLを使えて無料で運用できるサービスが他にはありません。

そこでふと、アプリケーション・サーバーはGoogle App Engine、データベースサーバーをGoogle Compute Engineで運用してみたらどうだろう、と思い立ちやってみました。

後日談の追記

こういうのが出るみたいなので無料は無理なのかもしれません。Micro instance with burstable CPU running。

普通にサーバーとして使ってる時は出ないのでGAEかネットワークから必要以上に接続が来てしまうのかもしれませんね…。（もしくは最近新しく作ったGCEだと出るようになったとかだったり？）

追記）
GCEにWeb+DB全部入れにしたら費用がかからなくなったのでやはりこの構成だと費用がかかるみたいです。

GAEからGCEにローカル接続する

結局のところ、今回の話ではこれが一番重要です。そもそもApp EngineからCompute Engineにローカル接続できるのか、と。

これは実はこの記事を書いている2020/1時点では日本語マニュアルではまだβ版という表記が残っている、リリースされたばかりの「サーバーレスVPCアクセス」という機能を使うことによって可能です。

Connecting to a VPC network | App Engine standard environment for Node.js docs | Google Cloud

Compute EngineはVPCネットワーク内に位置しているのですが、App Engineはこれとは別のネットワークに存在しています。そのため、このサーバーレスVPCアクセスという機能を使うことで、下記にも書かれていますがApp Engineのスタンダード環境やCloud FunctionsからCompute EngineやCloud SQLに内部IPでアクセスできるようになります。

Serverless VPC Access の構成 | VPC | Google Cloud

日本語だとデプロイ時にbetaをつけろと書かれていますが恐らく今は不要だと思います。

サーバーレスVPCアクセスの設定

サーバーレスVPCアクセスのページを開くとコネクタを作成というリンクがあるのでクリックします。

作成画面に必要な項目を入力して作成します。

注意が必要な点としてまだリリースされたばかりのためリージョンが少ないです。最初にApp Engineを登録してしまうと、同じリージョンがない…！　みたいなことになるので気をつけましょう。us-central1であればGAEのus-centralと合います。

IP範囲は補足に書かれている感じで大丈夫です。要するに、既存のVPCネットワークのIPとかぶっていないIP範囲であれば大丈夫です。

App Engineの設定

App Engineのリージョンは先程作成したコネクタのリージョンに合わせて作成しましょう。多分作ってしまった後は変更できないのではないかと思います……。ただ、ちょっとApp Engineを作り直せない関係で色々試すことができたわけではないので、リージョンが違ったらダメかどうかは詳しく検証できていません。

あとはapp.yamlに、このコネクタに接続するための設定を追記します。

vpc_access_connector:
  name: "projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME"

REGIONとCONNECTOR_NAMEはコネクタのものです。これでデプロイすれば接続され、Compute Engineの内部IPと接続することができるようになります。

Compute Engineの設定

デフォルトだとCompute Engineの内部IPはエフェメラルになっているため、時々勝手に変わってしまいます。

静的内部IPアドレスを予約して固定にしておきましょう。外部IPは不要です。固定外部IPを使っていた場合は、ただそれを外すだけだと使われない外部IPになってしまい、費用が発生してしまいますのでIPを解放しておきましょう。

あとはMySQLをインストールして設定しましょう。どこからもアクセスできないのでMySQLユーザーは ユーザー名@'%' とかでいいのではないかと思います（違ったら教えていただけると助かります）。

問題なければこれで接続できます（のはず……）

諸々設定

とはいえGAEは無料枠があるというだけでそれ以降は有料となってしまいます。こにさんのブログを参考にしてなるべくオーバーしないようにすると良いでしょう。

Google App Engineを無料で運用する方法（2018年版） - koni blog

スタンダード環境にてAutoScalingのF1というプランです。スケールしないプランもありますがそちらは無料枠が少なく毎月有料になってしまいます。

どちらにしろすごくアクセスのあるサイトだと有料になってしまうと思いますので今回のようにもう誰も使っていないサービスを残しておくとか、作ったばかりのサービスで試す場合とかにこの構成だと良いのではないかと思います。

あとCloud SQLのように便利な機能はないので適宜バックアップを取っておきましょう。

Google Cloud Storage無料DBバックアップ

また、DBサーバーはメモリが不足してしょっちゅう止まる可能性もありますので、swapの設定もしておいた方が良いでしょう。

2020年からはGCEの外部IPが有料となりますが無料枠もあります

2020-01-03T22:24:35+09:00

GCPのクラウドサーバーであるGoogle Compute EngineはAlways Freeという無料枠によりf1-microは無料で利用ができます（細かい条件はあります）。しかし2019年から囁かれはじめたとおり、2020年からは外部IPが有料となりました。

新年あけましておめでとうございますしてから、僕にも請求アラートが飛んでくるようになりました。見てみるとたしかに外部IPの費用分が追加されていました。（External IPの箇所）

ただし無料枠の割引もあるようです。

詳しくは下記に書かれていました。

Google Cloud の無料枠 | Google Cloud Platform の無料枠 | Google Cloud

注: Google Cloud では、2020 年 1 月 1 日から VM インスタンスの外部 IP アドレスの使用に料金がかかります。ただし、Google Cloud の無料枠では当月内の合計時間数と同等の時間数を使い切るまで、使用中の外部 IP アドレスを無料でご利用いただけます。使用中の外部 IP アドレスの Google Cloud 無料枠は、f1-micro インスタンスだけでなく、すべてのインスタンスタイプに適用されます。

無料枠はf1-microだけだと思うのでちょっとよく意味はわからないのですが、とりあえずf1-microであればずっと無料で行けるのではないかと思います。（実際に１ヶ月丸々試せてはいないので今後も引き続き見ていきますが）

とはいえ課金＋割引という方式のようですので、無料枠無視の請求アラートにしていた場合は、設定によってはアラートが飛んでくるようになっています。煩わしいようであれば請求アラートの設定を調整しておいた方が良さそうです。

GoogleからAPIキーが公開されているよとアラートが来た

2019-12-12T22:32:10+09:00

Googleから怪しげなメールが届いた。本文を見てみると「Google Cloud Platform または API プロジェクト（プロジェクト名）の認証情報が不正使用された可能性があります」とのこと。

ドキッとした。クラウド破産…！？

調査

メール内の最初の方に、ここで一般公開されている、というURLが書かれていた。そこにアクセスしてみる。GitHubだった。するとたしかに僕のサイトっぽい名前のファイルがある。中身はバイナリファイルだったが、どうもここにAPIキーが含まれているらしい。

料金の確認

ちなみにプロジェクトはこのCrieitのプロジェクト。メールに色々と確認手順が書かれていたが、とりあえず読まずに料金がどうなっているだろうかを急いで確認してみた。今月の料金は……10円。とりあえず問題はなさそうでホッとした。が、そうこうしている間に何かしら利用されて今後料金が加算されていってしまう可能性がある。

何のAPIキーかを確認

細かくメールを見たかったがメール内にAPIキーが書かれていたので、ひとまずGCPのダッシュボードでそれが一体何のAPIキーなのかを調べてみることにした。

確認方法はGCPコンソールの「APIとサービス」→「認証情報」。ここでAPIキーの一覧を見ることができる。

問題となったのはこの画像の右下端に表示されている Browser key (auto created by Google Service) というもの。なんとなく見覚えがある。だいたいFirebaseのプロジェクトに関連付けた時に勝手に作られているものがこんな感じだったような気がした。Browser keyということなのでそれっぽい。

どこで使っているかを確認

とにかくどこで使っているかを確認してみることに。本番サーバーにログインし、.envを開いて検索してみた。しかし見つからない。

ということでローカル上でプロジェクトをVSCode開いて検索してみる。すると見つかった。やはりFirebaseのAPIキーだった。これは公開しないとどうしようもないのと、ちょっとした機能で使っているだけのため環境分けをするのも面倒だったので直接コミットしてある。ということでそれを見つけた。

そもそもFirebaseのAPIキーとは

Firebaseのプロジェクトを作ったことがある方であればよく見るものだと思うが、こういった設定。これのapiKeyというところが今回問題となったAPIキー。

僕が普段良く作っているWebアプリケーションの場合、この設定はブラウザで動作するもののため、そもそも公開しなければならない。そのため後悔自体は問題がないはず。

何が問題か

何が問題かというと、適切なセキュリティ設定が行われていない状態だと問題となる可能性がある。無料のSparkプランや月額制のFlameプランであればさほど問題にはならない。あるとしてもリソースを利用しつくされてサービスが止まるだけ。

問題となるのは従量制のBlazeプラン。今回のCrieitのアプリケーションはこれだった。この場合、従量制なのでいたずらで無限ループなどをされると恐らくとんでもない料金になってしまう可能性がある。とはいえ僕の場合Realtime Databaseと匿名認証を有効化していただけなのでさほど問題にはなりにくかったかもしれない。Firestoreを利用している場合は危険な可能性がある。

セキュリティの設定

恐らく、SNS認証＋Firestoreのセキュリティルール設定済み、であれば問題にはならないだろう。問題になりそうなのは、匿名認証＋Firestoreという場合。SNS認証は認証可能なURLを設定できるため、その設定さえしておけば不正利用は難しい。しかし匿名認証はURL指定ができないため、APIキーを利用すれば誰でもアプリケーションを動かすことが出来てしまう。このパターンだとまずそう。ちなみに今回はこのパターン。

ではこの場合どうすればいいのか。メールにも書かれていた。

API キーに API キー制限を追加します（該当する場合）。

そう、先程スクショで説明した認証情報のページで、該当のAPIキーをクリックすると認証情報の設定ができる。ここでAPIキーの利用制限の設定ができる。GCPで直接自分で作ったキーの場合はできることを知っていたのだが、なんとなくFirebaseが勝手に作ったものは同じものという認識がなかったので気づかなかった。

とりあえず、リファラーの設定をしておいた。

何か間違っていたら機能が止まってしまうかもしれないが、今回は大したことのない機能のために使っているので気にせず設定した。これで一覧ページに元々出ていたアラートアイコンも消えた。

まとめ

そもそもこの設定はFirebaseの方で出来た方がいいんじゃないか…と常々思っていた。わりとこのあたりの事を知らない方もいるのでは。

とにかくクラウドの利用は気をつけよう。そういえば料金アラートは設定していたので何にしろ何かあってもすぐ気づけたかもしれない。

細かく試して書いたわけではないため、もしこの記事で間違えている情報などあれば情報提供いただけるとありがたいです。

GCEでインスタンスを作るときにやることリスト

2019-11-17T14:30:30+09:00

今更ながらGoogle Compute Engine(GCE)を使ってみたいなと思い、
インスタンス作るときにやった手順をまとめてみた。

ほぼ、以下の2つの記事を見てやった手順をまとめただけの備忘録。
・ GCE の無料枠のサーバを立るときに、初見でハマりそうなところ - Qiita
・ GCPで永久無料枠を利用してサービスを立ち上げたときにしたことの備忘録 - Qiita

1. インスタンス作成

imageはUbuntu 18.04(Minimal)を選択

f1-microにする
80, 433ポートを開放する
- 「HTTPトラフィックを許可する」にチェック
- 「HTTPSトラフィックを許可する」にチェック
IPを固定にする
- 「ネットワーキング」>「ネットワークインターフェース」>「外部IP」
- 「プライマリ内部IP」とは違うので注意

2. SSHの設定

2-1. ポート変更

メニューの「VPCネットワーク」>「ファイアウォールルール」から
「ファイアウォールルールの作成」を押して作成
- ターゲットタグ: original-allow-ssh
- ソースIPの範囲: 0.0.0.0/0
- プロトコルとポート: tcp 40022
VMの「ネットワークタグ」に「ターゲットタグ」をつける
「VMインスタンス」にある該当のVMの「接続」＞「SSH」を押してブラウザでログイン

# apt updateしないとvimをインストールできない
$ sudo apt update
$ sudo apt install -y vim

$ sudo vim /etc/ssh/sshd_config
$ sudo systemctl restart sshd

  #Port 22
+ Port XXXX （XXXX は さっき開けたポート番号）
  #AddressFamily any
  #ListenAddress 0.0.0.0
  #ListenAddress ::

sshdを再起動したら、編集したブラウザは閉じずに、
「接続」>「ブラウザからカスタムポートで SSH を開く」から
変更したポートで接続してみて、つながるかどうかを確認

うまくできたらポートを閉じる

「ファイアウォールルール」に移動
「ファイアウォールルールの作成」を押して作成
- ターゲットタグ: disallow-ssh22
- 一致したときのアクション: 拒否
- ソースIPの範囲: 0.0.0.0/0
- プロトコルとポート: tcp 22
VMの「ネットワークタグ」に「ターゲットタグ」をつける

2-2. 公開鍵の認証

# 鍵を生成。アカウント名はmemorylovers
$ ssh-keygen -t rsa -f ~/.ssh/gcp_key -C memorylovers

$ chmod 400 ~/.ssh/gcp_key 

# 公開鍵をコピー
$ cat ~/.ssh/gcp_key.pub | pbcopy

メニューの「VMインスタンス」から該当のVMを選択し、編集画面へ
SSHキーに貼り付けて、保存

接続確認をしてみる

$ ssh memorylovers@ -p <指定したポート> -i ~/.ssh/gcp_key

2-3. SSHの設定を変更

ポート番号以外について、確認・設定していく

  # プロトコルを2にする
+ Protocol 2

  # rootログインを無効にする
  #PermitRootLogin prohibit-password
+ PermitRootLogin no

  # パスワード認証を無効にする
  PasswordAuthentication no
  ChallengeResponseAuthentication no

  # 認証の試行回数を制限する
  #MaxAuthTries 6
+ MaxAuthTries 5

設定が終わったらsshdを再起動して設定を反映

$ sudo systemctl restart sshd

以上!! これでインスタンスが作成できた！

こんなのつくってます!!

積読用の読書管理アプリ『積読ハウマッチ』をリリースしました！
積読ハウマッチは、Nuxt.js+Firebaseで開発してます!

もしよかったら、遊んでみてくださいヽ(=´▽`=)ﾉ

要望・感想・アドバイスなどあれば、
公式アカウント(@MemoryLoverz)や開発者(@kira_puka)まで♪

参考にしたサイト

Google Compute Engine利用時に使うgcloudコマンド備忘録

2019-11-14T08:49:36+09:00

Google Compute Engineを使っているとサーバーと接続するために色々なgcloudコマンドを利用する必要がある。普段はシェルの実行履歴から呼び出して使っているけど、何かのひょうしにPCが壊れて履歴がなくなってしまったら困るし、結構一から使い方を探すと見つからなかったりするのでとりあえずまとめておく。

SSH接続

gcloud compute --project "my-project-id" ssh --zone "us-east1-b" "instance-1"

ポートフォワーディング

ローカルPCでサーバーのデータベースと接続するときとか

gcloud compute --project "my-project-id" ssh --zone "us-east1-b" "instance-1" -- -L 13306:localhost:3306

SCPで送信

SCPでファイルを送ったり受信したりする時。ファイルとフォルダによってちょっと違う。

ファイルを送信

gcloud compute scp --project "my-project-id" --zone "us-central1-f" instance-1:/home/dala00/profile.sql.gz .

フォルダを送信

gcloud compute scp --project "my-project-id" --zone "us-west1-b" --recurse instance-1:/home/dala00/questions localdir

コマンドを実行する

gcloud compute --project "my-project-id" ssh --zone "us-west1-b" dala00@"instance-1" --command 'touch bbb.txt;rm aaa.txt'

Crieitの構成

2018-09-04T18:37:50+09:00

Crieitの構成をまとめたものが無かったのでまとめておきます。(2018/8現在)

一応Qiitaには以前書いていましたのでより細かい部分が気になる場合はそちらを見てください。

Qiitaの様なサービス作成中ローカル環境構築連載(1)
Qiitaの様なサービス作成中サーバーで公開する連載(5)

運用費は無料です。

言語＆フレームワーク

PHP7.2
Laravel5.8
Vue2

データベース

MySQL8.0

デザイン

Bootstrap Material Design

サーバー

Google Compute Engine (f1-micro 1台にDBまで全部のせ）
Apache2.4

追記）2020/4 Cloud Run＋Cloud SQLに引っ越し
GCEからCloud Runに引っ越してみた

CDN

Cloudflare

追加システム

なぜCrieitを作り始めて55時間で公開できたのか？

2018-06-07T08:47:36+09:00

先日Crieitをαααバージョンとして公開しました。公式ツイッターがつぶやいていたので多分5/29だと思います。

そういえば作り始めたのはいつだっただろう、と思い見てみました。多分artisanの日付だと思うので5/1。

ということで大体１ヶ月弱だったようです。

毎日開発出来たわけではないと思いますが、ちょっと多めに作業した日もあると思いますのでだいたい平均２時間として、30日はいかないので多分おおよそ合計55時間ほどでしょうか。フルタイムで考えると約7人日。~~仕事やめれば毎週これくらいの規模のものをリリースできることになりますね！~~

これは速いのでしょうか？　そうではないのでしょうか？　具体的に何をやってたかを述べつつ検証してみます。

開発環境構築

開発環境はDockerで構築しました。PHP7.2のDocker環境は以前に作っていたので、ちょっと修正してちゃちゃっとdocker-compose.ymlを作って完了です。他にもElixir & Phoenixや、goの環境などもあります。普段から色々作って慣れておくと急に何か作りたい時に速く走り出せます。

なので開発環境にDockerをよく使っているエンジニアだったらだいたいこんな感じで普通だと思います。

あとはLaravel Installerを使ってインストールすればアプリケーションもすぐ動作します。

実際に開発すること

実際の開発ですが、正直あまりコードも書いていないと思います。とりあえず色々なパーツを組み合わせていくことがメイン。具体的には下記のような事などです。

Laravel Socialite

Socialiteを使うことで簡単にソーシャルログインが作成できます。これもマニュアル通り作るだけ。

僕はソーシャルログイン情報保存用にテーブルを分けましたが、Laravelは最初からユーザーのモデルとマイグレーションファイルも入ってますのでそれを改造するだけでもいいかもしれません。

JavaScript

Laravelは最初からVueが入っています。そのためcsrfトークン用のヘッダーを設定したり色々初期化などしなくてもすぐVue & axiosで開発できます。

yarn run hot

でホットリロードできるので、jsファイルを更新するとすぐ勝手にブラウザに反映もされます。

記事編集画面

ここもタグ入力コンポーネントであるvue-tags-inputと、markdownエディタであるTOAST UI Editorを使ったので、ほとんどそれでできてしまいます。あとはボタンをつけたり通信して保存したりするだけ。

はてなブログからのインポート

今回自分で使いたかったので、はてなブログからのインポートを作成しました。

直リンクはダメだと思うので画像を取得して保存したり、はてなブログの独自リンクタグを通常のmarkdownに変換するために各リンクのhtml & titleタグを取得して、文字コードがおかしかったり404でエラーになったりして無限ループになり画像を何千も保存してしまったり（無料枠じゃなかったら怖いですね）

本質とは関係ない機能なのですが、ここで結構時間を使ってしまったと思います。高速開発重視だったら絶対に手を出してはいけないところですね。

つまりは？

まあ何しろ、上記のように実際には開発が速いわけではなく、そもそもそんなにやる事がない、という事が分かるかと思います。ベースとなるのは記事データのテーブルだけで、あとは適当にタグ等がbelong belongとくっついているだけですので。

公開作業

公開方法は色々あると思いますが、僕はGoogle Compute Engineのf1-microがAlways Freeになってからはずっとそればかり使っています。もう7, 8アプリケーションくらいはそれで公開しているのでだいぶ慣れています。

そもそも、仕事も趣味もプログラミングなので、それ以前からアプリケーションを公開するためのサーバー設定は慣れています。（メンテナンスとかはよくわかっていません）

ただ、慣れているかは関係なく、Google Compute Engineでリリースしたアプリケーションについては、アプリケーションを公開するまでのコマンド実行手順を全部メモっているので、それを見て実行していくだけでちゃちゃっとリリース出来てしまいます。こうやって最初だけ頑張って色々書き残しておくと、その後が非常に楽です。

αバージョン

そもそも、現在αバージョンです。前述の通り、メインとなる記事テーブル周りの処理だけを優先して作っており、それ以外のところはほとんど作っていません。ユーザーのプロフィール編集機能もありませんし、「いいね」機能もコメント機能すらありません。

つまり、公開優先でそもそも完成すらしていないので、何もやっていないからすぐ公開できた、というだけなのです。多分同じくらいの経歴のエンジニアならサービス全体をちゃちゃっと見るとすぐ感じたと思いますが、特に何も速いわけではありません。むしろインポート作ってたせいで遅いくらいでしょう。

まとめ

以上の通り、公開できた理由は速かったわけではなく、単純にそれくらいしか作らなかったために早かっただけです。

WEBサービスを実際にいくつか作った事がある人ならわかると思いますが、想像以上に人は集まりませんし成功しません。あまり頑張りすぎても誰も使ってくれず無駄になることが多いので、あまり作りこまずにとりあえず公開可能なところで区切って使ってみてもらうことが割と重要だったりします。どうやって速く作るかじゃなく、どうやって早く公開するか、というところです。

もちろんガッツリ作りこんだ方がいいパターンもあるかもしれませんのでそれはプロジェクトの方針等から適宜決める必要があるのかもしれません。

失敗したら次を考えて（既にもう色々作りたいものがあるので）どんどん作っていきたいので、こういった形でうまく行くかを早めに判断する手法は大字です。

ちなみにCrieitは失敗しても僕のブログになるので特に終了することなく永久に継続予定です。