/ #GCP 

【GCP】サーバーデプロイ方法3選!Ansible、イメージ起動、起動スクリプトの解説

Google Cloud Platformこと【GCP】使ってますか?
Webサーバーを作るには、色々インストールしたりしますよね。
今回はそのインストール方法(デプロイ)について自分の見解を解説します。

こんにちは、クラウドランスの望月です。
最近しごとでGCPをめちゃくちゃ使ってるんですよねー。
そこでゲームAPIサーバのデプロイの経験値が溜まったのでアウトプットします。

3つのステップをふんでデプロイ方法が変遷していったので、
その時の見解や難易度、メリット、デメリットなど自分の所感を書きます。

目次

  1. なにはともあれ直接コマンドでインストール
  2. Ansibleは複雑怪奇で俺しか解らなくなった
  3. イメージコピーは簡単で楽ちん
  4. 起動スクリプトは作るの大変だけど、応用が効いてベスト

1. なにはともあれ直接コマンドでインストール

前提として普通のゲームバックエンドAPIサーバを作るとします。
インストールするソフトとしては以下のものでしょう。

  • Apache
  • PHP
  • Laravel などのフレームワーク

それとgithubやgitlabにアプリケーションソースがコミットされるとしましょう。

普通に作るならば、以下の手順になります。

  1. yumでApacheとPHP、Laravelをインストール
  2. Apacheの設定をアプリ用に設定する
  3. PHPの設定をアプリ用に設定する
  4. githubからソースを展開する
  5. 環境に合わせた接続情報をセットする

ほか細かい作業がありますが、大まかに以上のような作業をすることでしょう。

例えば本番環境、テスト環境、審査環境と何個もこの環境を作るとします。
毎回同じ作業をするのはミスも起きるし、
なにより1回やった手順をまたやらなくてはいけないですよね。

これは面倒くさいし、カッコ悪いです。

そこで何らかのめんどくさくない方法をとる必要があります。
それが以下に示す方法です。

  1. Ansibleを使ってインストール作業をコード化する
  2. そもそもインストールして完成したサーバのイメージを焼いて、サーバをコピーする
  3. インストールコマンドを書いた起動スクリプトを使い、サーバを立ち上げる

この順番は開発していくなかで、採用した順番で最終的には3の方法を変遷しました。
以下、なんでそれを使って、実際どうだったかを解説します。

2. Ansibleは複雑怪奇で俺しか解らなくなった

Ansibleはサーバーのミドルウェアのインストールをコード化するツールです。
昔のトレンドワードで言うところのインフラ・アズ・ア・コードみたいな感じですね。

まずいきなりデメリットですが、コードが複雑化しやすいです。
コード化のメリットは属人化を防げる所なのですが、逆に複雑化したAnsibleは、
書いた人にしか解らないです。

そして、Ansibleも学習コストが中程度あるので、
Ansibleを知ってる人、勉強した人しか使えないです。
つまり作った人がメンテするしかなくなることになります。

仕組みや機能は素晴らしいのですが、シンプルさに欠けますね。

よって、これで管理するのはツライという結論になりました。

3.イメージコピーは簡単で楽ちん

これはかなりいい方法です。

出来上がって安定したサーバーのイメージを焼いて、取っておく方法です。
焼いたイメージを元にサーバーを立てれば、元のサーバーと全く同じ状態のサーバーが2分で出来ます。

これは楽ですね。あとは環境に合わせて、DBとの接続情報や、環境変数をちょろっと変更するだけです。

しかし、これにもデメリットがあります。
ソースを更新するたびに、イメージを焼いて、その状態を保持する必要があります。
それはイメージを焼くのもコマンド化したり、Jenkinsでビルド化したりするとよいですね。

それでもイメージが増えたり、イメージを焼く時間が8分ほどかかったり、
少々スマートさが無いですね。

起動後に何も変更したくない場合は環境毎にイメージが必要になるかもしれません。

しかしながらイメージからサーバーを作る手法は、シンプルで使いやすいです。

4. 起動スクリプトは作るの大変だけど、応用が効いてベスト

最後に、上級編の方法です。

最終的に自分はベテランのエンジニアのアドバイスもあり、この方法を採用しました。

まず起動スクリプトってなんぞや?ってことですね。
これはサーバーを起動する時にシェルスクリプトを挟む方法です。

やり方はWebコンソールで起動する時に、
起動スクリプト欄に直接シェルスクリプトを書きます。

他にもストレージに起動スクリプトをアップロードしておき、
そのパスを指定する事もできます。

さらに応用編として環境変数を変数(メタデータ)として読み込ませる事ができます。

ちゃんといい感じに作った起動スクリプトを指定して、
環境別に違う値は変数として渡す事で、一発でその環境のサーバを作る事ができます。

デメリットとしては、インストール方法をシェルスクリプトで記述するので、
それなりにコードをしっかりエラーなく作り込まなければならない事です。

エラーになると、そこで処理が止まるので、いちいちインストール作業がストップします。
ちゃんと動くスクリプトを作り込むのはそれなりの時間と労力が必要です。

しかし一度作ってしまえば、サーバーはかなり安定して立ち上がるのでスマートです。

GCPにはインスタンステンプレートといって、
サーバーを立ち上げる為のテンプレートを作る事ができます。
このテンプレートに起動スクリプトを指定するのがベストなパターンです。

このテンプレートをインスタンスグループに指定すると良いですね。
そうするとマネージドグループといって、オートスケールやローリング更新を使う事が出来ます。

起動スクリプトのなかに、githubからソースを展開する処理を含めると、
最新ソースを展開する処理が楽になります。
変数にブランチ名を指定したテンプレートを使う事で応用的にデプロイする事も出来ます。

この柔軟な変数指定をうまく活用する事ができるのが応用編の使い方ですね。
イメージからサーバーを起動する方法ではこうはなりません。

5. まとめ

さて、今回はGCPのデプロイ方法について3つの方法の勘所を紹介しました。

じぶん自身イメージを焼いてサーバー作成、やったー俺スゲーみたいに思っていたのですが、
もっと効率的でスマートな方法もあるという事を業務で学びました。

実際に、Ansible → イメージコピー → 起動スクリプトとステップを踏んで使ってきました。
それぞれメリットデメリットがありますので、そのステップに最適な方法を選択すると良いですね。

最後にそれぞれの見解を1行にまとめて終わりにします。

  • 一番簡単なのはイメージコピー
  • 応用が効いてスマートなのは起動スクリプト
  • ちょっと今から採用するのはおすすめしないAnsible

以上今回はGCPのサーバーデプロイのお話でした。


このブログではフリーランス情報やプログラミング情報の発信を
続けていこうと思うのでぜひ応援お願いします。
また、Twitterでも日々の為になる技術情報やフリーランスについての
有益な情報をつぶやくので、いいなと思った方はTwitterのフォローをお願いします。

ブログの著者:IT業界10年以上のベテランフリーランスエンジニア。
会社員時代に比べ年収2.5倍にUP。
AWSとGCPの両方でゲーム系インフラの構築,運用と
C#とPHPでのサーバープログラミングの二刀流で絶賛稼働中。
有益なIT情報を発信出来きるように日々IT情報収集が日課です。
ブログではフリーランスやIT情報を毎日更新中です。

自分のスキルレベルと経歴をまとめたページを作りました。
お仕事のご依頼の際には参考にしていただければと思います。

クラウドランス 望月 のポートフォリオサイト

またブログに関する感想やご意見、応援などがありましたら、
こちらから自分宛てにTweetして頂ければと思います。