📚

この1年でインフラ担当としてやったことその1

2021/12/04に公開

Google Cloud

この記事は「イエソドアウトプット筋トレーニング Advent Calendar 2021」4日目の記事です。

自己紹介

インフラ担当として働いていますが、最近は開発の都合もありインフラの仕事があまりできていない人です。
昨年の11月にイエソドで初めてのインフラ担当としてジョインしました。
そこで行った改善策や、引っかかった点などがあれば数回に分けて書いていこうと思います。
正直感想文のような内容になってしまうと思いますが、自身の振り返りと誰かの参考になればという思いで書いていこうと思います。

昨年のタイミングでのインフラ構成

イエソド社ではクラウドプロバイダーとしてGCPを使用しており、サービスは全てコンテナ化されておりGKE上で動作しています。それは私がジョインしたタイミングからそのままで今も変わっていません。
私がジョインしたタイミングでは、環境は2つありました。本番用環境と検証環境があり、それらは同一クラスタ内で管理をされていました。
CI/CDについてはCloudBuildを使用しており、環境差分についてはトリガーの設定値において吸収をしていました。

IAPによるアクセス制御の有効化

まず初めに、GCPの機能であるIAPを使用して本番環境以外のページにアクセスできるユーザーの制限を行いました。IAPの詳細については割愛しますが、これにより従来だとベーシック認証やIPアドレス等で制限をかけていたアクセス制限をGoogleのアカウントで管理をできるようになります。設定もGCLBを使用していると簡単に行うことができ、管理コンソールから設定を有効化し、アクセスを許可するユーザーやグループを追加するだけで設定を行うことができます。これにより、ベーシック認証のパスワード漏洩によるリスクの軽減や管理が楽になり、例えば開発者グループをIAPでアクセスができることを許可するグループとして設定をしておけば、新しいメンバーがジョインしたり、移動した際の対応が不要になりました。

インフラ資産のコード化

次に行ったこととして、インフラ資産のコード化です。インフラ資産のコード化(IaC)の重要性については今更語ることでもないと思います。また、このタイミングで開発者がもっと自由に試せるsandbox環境や営業が顧客へのデモとして使用するための環境が必要になってくるという要求が上がってきました。そのため、既存の資産をterradormで管理するようにしました。terraformの選定理由としては、ドキュメントの豊富さと実績をもとに選定しました。そこで結構地味ながら大変だったのが、既存資産をtfstateに全て取り込むことでした。既存資産からterraformのコードを生成するツール等も試してはみましたが、弊社はサービスのメインとしてはKubernetes上で動作をしているため、GCPのインフラ資産としてはそこまで多くなく、tfstateを一つずつimportしていく方が個人的には楽でした。また、このタイミングで複数環境を今後管理していくことになることはわかっていたので、terraform workspaceをGCPのプロジェクト単位で切り出し環境差分を管理するようにしました。また、同一プロジェクト内で複数環境を取り扱うことも想定できたので、基本的に全てvarについては、for_eachを使用して環境名をIndexにして、mapとして管理をするようにしました。

k8sリソースの管理をkustomizeに移行

terraform側である程度プロジェクトごとの環境差分をコントロールできるようになり、次にk8s内のリソースの環境差分吸収に取り掛かりました。それまではk8s内の環境差分についてもCloudBuildのトリガーの設定値で吸収をしていました。それだけだと柔軟な差分を生むのは難しく、例えば環境ごとのコンテナリソースの調整であったり、CronJobの調整などを柔軟に環境ごとに変えていくには不十分でした。そのためk8s内のリソースはkustomizeを使って管理するように移行しました。構成はシンプルにbaseディレクトリに全リソースの基本設定を書き、overlaysディレクトリ配下に各環境ごとの差分patchを書いていくようにしました。patchについては基本patchesJson6902を使用して明示的に差分を書くようにしていきました。またアプリケーションイメージについてはCIのタイミングでトリガーごとにビルドした対象の環境ごとのイメージに書き換わるようにCIでkustomizeのコマンドを叩いてkustomize.yamlを書き換えするようにCloudbuild側も設定をしました。Cloudbuildのトリガーは、特定ブランチのコミットとしているので、ビルドされたイメージのタグをCOMMITのshaを使用してそのタグに書き換えるようなコマンドを叩いています。

例:CloudBuild側のビルドコンテナ内で叩くコマンド

cd /kustomize/overlays/${_ENV}/XXXXX && kustomize edit set image gcr.io/XXXXX/XXXXX=gcr.io/XXXXX/XXXXX:${COMMIT_SHA}

例:変更されたoverlays配下のkustomize.yaml

images:
- name: gcr.io/XXXXX/XXXXX
  newName: gcr.io/XXXXX/XXXXX
  newTag: # COMMIT_SHA

最後に

今週はここまでにして、次回はk8sリソースの管理をhelmとkustomizeに分けるようにしたことGitOpsの導入やIstioの導入について書いていこうと思います。