サーバインフラ業務やDevOpsを効率化する共通開発基盤 - GDE のご紹介
こんにちは、フリーランスでDevOpsやバックエンドの開発をやっている松野です。
GNUSでは日々大小様々なプロジェクトが立ち上がっています。
開発に携わるフリーランスメンバーは経験豊富な方が多く、立案〜プロトタイプ開発〜本開発というサイクルが高速に進行しています。
各プロジェクトの使用言語やソフトウェアスタックは様々であり、サーバインフラへの要求も多様です。
このような状況で、開発者が機能実装に集中出来る環境をいかに素早く提供出来るかが、プロジェクトを成功に導く大きな鍵だと思います。
開発環境やサーバインフラをその都度構築していくとなると、インフラ業務の負担は増大し続けることになってしまいます。
やがてプロジェクトの要求する開発スピードに追いつく事が難しくなり、結果として開発業務を遅延させることに繋がってしまいます。
そのため、開発環境の準備やサーバインフラの構築・メンテナンス業務は高効率で行う必要があります。
こういった問題に立ち向かうべく、GNUSでは開発環境とサーバインフラをある程度共通化する試みを行っています。
今回はGNUS内で開発基盤の共通化を目指している GDE をご紹介します。
GDE ではプロジェクトごとに発生するインフラ業務の負荷軽減のため、極力インフラ作業を自動化するように努めています。各種作業自動化のため GDE では下記3つの要素を基本に設計しています。
・IaC(Infrastructure as Code)
・Kubernetes
・CI/CD
それぞれ順番に概要をご説明します。
IaC(Infrastructure as Code)
サーバインフラの構成管理ツールとして GNUS ではTerraform(https://www.terraform.io/) を使用しています。
前述の通り、プロジェクトによって使用するソフトウェアやサービスも様々です。
基本的には module で共通部分の定義を行い、その上でプロジェクト特有の部分を別途定義するという運用を考えています。
どこからどこまでを Terraform の管轄に置くか、というのは常に悩ましい問題です。
ただ module 内でプロジェクト特有の事や複雑な事をやってしまうと module の汎用性がなくなってしまうので、ネットワークや権限周り、Kubernetes クラスタの設定など出来るだけ抽象度・汎用性の高いものを共通部分に記述するようにしています。
├── main.tf
├── modules
│ ├── container-registry
│ │ ├── container-registry.tf
│ │ └── variables.tf
│ ├── iam
│ │ ├── iam.tf
│ │ └── variables.tf
│ └── kubernetes
│ ├── cert-manager
│ │ ├── main.tf
│ │ ├── manifests
│ │ │ └── cert-manager.yaml
│ │ ├── outputs.tf
│ │ └── variables.tf
│ ├── gke
│ │ ├── gke-service-account.tf
│ │ ├── main.tf
│ │ ├── outputs.tf
│ │ ├── variables.tf
│ │ └── vpc-network.tf
│ └── ingress-nginx
│ ├── main.tf
│ └── variables.tf
├── outputs.tf
├── terraform.tf
└── variables.tf
Terraform で構成管理を行うメリットとしては以下を特に実感しています。
・インフラをコードとして変更管理が出来る
・チーム内で Pull Request による構成変更時のコードレビューが可能になる
・開発環境、ステージング環境、本番環境といった複数の環境へのデプロイもコマンド一発で出来る
Kubernetes
GNUSでは様々な言語やソフトウェアスタックを用いていると先程述べました。
ですが一貫して各プロジェクトのアプリケーションは Docker コンテナ内で実行するようにしています。
Kubernetes は各クラウドベンダーもサポートしており、Anthos のようなマルチクラウドでクラスタを構成するようなソリューションもあります。
プロジェクトの規模に応じて一貫して安定したコンテナオーケストレーションのプラットフォームとして安心して使用できています。
CI/CD
GNUS ではソースコードリポジトリに GitHub を使用していることもあり、SaaS型CI/CDでも代表的な CircleCI を活用しています。
GitHub の特定のブランチへの push やマージをトリガーにビルドやテスト、デプロイといった各処理を自動化しています。
GitHub 上のブランチとデプロイ先のサーバ環境を一定のルールで決めておくことで、特定のブランチに push すれば特定の環境にデプロイする、といった branch filter を設定しています。
今回はGNUSのプロジェクトで運用を行っている開発インフラの概要をご紹介いたしました。
今後も増え続けるビジネスのニーズに合ったサービスをいち早く提供出来るよう、より一層これらの基盤を整えていきたいと思います。
これからもGNUSでは各マガジンで、開発マネジメント手法や、テックトレンドなどについて書いていく予定です。ぜひ、フォローをお願いします!
この記事が気に入ったらサポートをしてみませんか?