OSS ベースの自宅クラウドの構成
はじめに
クラウドといえば AWS, Azure, GCP の 3 大クラウドベンダーが主流ですが、現在は様々な機能に特化したクラウドネイティブな OSS プロジェクトが存在しているため、それらを組み合わせることで自宅でも各ベンダーで提供されているようなサービスと同等の機能を持つクラウド環境を構築することが可能となっています。
今までいくつかのコンポーネント（主に CNCF のプロダクト）を記事にしてきましたが、個々の記事だけでは各コンポーネントが全体の内どのような機能を果たしているか見通しづらい部分もあります。
そこで、この記事では自宅で使用しているものや今まで記事にしたものについて、各コンポーネントを機能毎に分類してそれぞれの役割について俯瞰します。
機能別の分類図
早速ですが自宅で使っているものや記事にしたプロジェクトを機能毎に分類した図が以下になります。
なお、各機能 (Provisioning や Monitoring 等) についてはあくまで独自の判断に基づいています。
機能別のコンポーネントの概要図。
今まで取り扱ったプロジェクトのロゴを並べるとそれっぽい感が出る。
Infrastructure
まず何をするにもコンポーネントを動作させたり作業を行ったりするサーバー(物理 PC や仮想マシンなど)やネットワーク、ストレージ等を備えた環境が必要になります。
自宅では openstack 上で物理 PC に仮想マシンを構成し、その上に kubernetes クラスタを構成し k8s 用の OSS を試す構成にしています。
Openstack
openstack はプライベートクラウド環境を構築するための仮想化プラットフォームです。openstack を利用することで物理 PC の上にスペックの許す限り複数台のハイパーバイザー型仮想マシンを構築することができます。
自宅の環境では minis forum のミニ PC 上で All-in-One の openstack を構築し、検証用の仮想マシンを動かしたり消したりしています。
openstack にもいくつか構築手段がありますが、 docker コンテナ化された openstack コンポーネントを Ansible でインストールする kolla ansible を使うのが一番楽かと思います。
Kubernetes
言わずと知れたコンテナオーケストレーションのスタンダードです。有名なので説明は割愛。
Provisioning
ここでの Provisioning は上記の openstack 上に VM やそれに付随するリソースを作成する作業を指します。様々な検証や運用を行う際には影響を最小限に抑えるため個々の環境を分離することが望ましいです (要らなくなったらすぐに削除して作り直せるし、既存の環境に影響が出ると復旧が面倒なため)。しかし、その度に VM の作成、削除や依存ツールのインストールを手作業で行うのは面倒なので処理を自動化する必要があります。
Provisioning や IaC の分野で広く使われている Ansible や Terraform には主に次のような特徴があります。
- 宣言的にリソースや処理を記述できる。
- 処理を何回やっても同じ結果が得られることが前提 (冪等性)。
- module が豊富に用意されているため処理を 1 から作る手間が少ない。大抵は標準の処理や community が管理しているモジュールやプラグインで対応可能。
自分で必要な処理を行うスクリプトみたいなものを書いてもいいのですが、上記の性質から処理の追加や管理が容易なので自宅の環境構築ではこれらを使っています。
Terraform
Terraform は IaC を実現するための有名なプロダクトです。Terraform Openstack provider を使うことで Openstack 上で仮想マシン等のリソースを作成できるので、予め決まったスペック、フレーバー、floating IP address 等のプロパティを指定した仮想マシンを作成したり、不要になった際にまとめて削除できます。
Ansible
検証用に作成した仮想マシンで検証用ツールのインストールやデバッグの効率化のための設定（シェル補完やホストの名前解決の設定など）を行うのに Ansible が有効です。
terraform でソフトウェアやミドルウェアの Provisioning を行うのは（できなくもないが）不便な点があるので、インフラの構築は terraform, ソフトウェア、ミドルウェアのセットアップやその他汎用的な自動化処理は Ansible というように使い分けています。
Repository
Repository はコードや資料、コンテナイメージの保管に使用します。
Gitlab
ソースコードなどを保存する git レポジトリ。有名なので説明は割愛。
Distribution
コンテナイメージを保管するためのプライベートレジストリ。元々は docker registry という名前でしたが、管理団体が CNCF に変わった際に Distribution という名称に変更されたようです。
docker で構築できるので、手っ取り早くプライベートレジストリを構築、使用する場合はこちらを使っています。
Harbor
harbor もコンテナイメージを保管するためのプライベートレジストリです。イメージ補完のコアな機能分は Distribution と同じですが、web UI やアクセスコントロール、イメージの脆弱性スキャンツールの統合など本番環境にも使える様々な機能がついています。docker や kubernetes で利用可能。
CI/CD
ここではビルド、テスト等の integration や対象環境へのデプロイを包括的に行えるツールやプラットフォームを CI/CD に分類しています。
Concourse
Concourse はクラウドネイティブな CI/CD プラットフォームであり、Github Action や CircleCI のようにコマンドベースで実行する処理を記述することで CI/CD を実現できます。
concourse について書いた記事は以下を参照。
Tekton
Tekton もクラウドネイティブな CI/CD プラットフォームであり、コマンドベースで実行する処理を記述することで CI/CD を実現できます。
tekton について書いた記事は以下を参照。
Argocd
Argocd も k8s で GitOps の理念に基づいたデプロイを実現するのにおなじみのツールです。
Flagger
k8s へのデプロイについて、少なくとも自宅環境ではマニフェストの手動デプロイや helm, Argocd 等を使ったデプロイで充分ですが、 Canary デプロイや Blue/Green デプロイ等のより高度なデプロイを試してみたい場合は Flagger が使用できます。
flagger について書いた記事は以下を参照。
Stackstorm
stackstorm はイベント駆動形で様々な処理や連携を行うワークフローエンジンです。CI/CD 専用というよりはもう少し汎用的な処理の自動化として利用できますが、イメージのビルドやテスト、デプロイ等も作り込むことによって可能なためここでは CI/CD に分類しています。
stackstorm について書いた記事は以下を参照。
Observability
クラウドの環境では多数の VM やコンテナといったワークロードが動作するため、それらが正常に動作することを保証するためにモニタリングが不可欠となります。
Logging
言うまでもないですがエラー発生時の原因分析、トラブルシュートやイベントの監視など様々な面でログ収集が重要です。基本的には VM や k8s に Logging エージェントを入れて別のログ監視基盤で一元管理する構成が基本になるかと思います。
Logging エージェントもいろいろ選択肢はありますが、以前の記事では Elastic stack の一部である Filebeat を使った方法について紹介しました。
Metrics
メトリクスも CPU, メモリ、ストレージ使用率やネットワークの IN/Out などワークロードの使用状況や状態変化を監視するのに重要です。
メトリクス収集エージェントもこれまた色々選択肢がありますが、現在は各種 exporter で公開されたメトリクスを prometheus を使って収集する方式が広く使われている印象があります。
以前の記事では prometheus と thanos で k8s のクラスタを収集する方式について記載しました。
Tracing
Tracing では opentelemetry を使って tracing データの収集を行い、jaeger で可視化する構成が広く使われている印象があります。記事は以下。
Data Storage
Observability 内の各要素はデフォルトではデータを長期間保存するようになっていないものが多いため、収集したデータを長期間保存したり、一元管理・参照するためにはデータを保管するデータストレージが必要となります。
とはいっても、例えば filebeat の場合は elasticsearch でデータ保存する等、保存先としてよく用いられるデータストレージには定番のものが決まっているため、特に理由がない限りはそちらを使うのが良いと思われます（情報検索が容易なため）。
Elasticsearch
Logging の filebeat と tracing の jaeger に関してはデフォルトで Elasticsearch への送信をサポートしているため、データ保存先には Elasticsearch がおすすめです。
Elasticsearch 自身も強力な検索や分析、aggregation 機能を持ち、後述の kibana との連携で参照や可視化が可能です（機能が豊富すぎて使うのが大変ですが）。
Minio
prometheus 自体は 多種の Remote storage への書き込みに対応しており、この中に elasticsearch も含まれています。
一方、thanos はオブジェクトストレージにデータを長期保存する形式であるため、OSS のオブジェクトストレージである minio が使用できます。
また、minio 自体は S3 互換のオブジェクトストレージなのでメトリクス専門というわけではなく一般的なデータ保存先としても使用できます。
Visualization
Observability を考える上での重要な点として、蓄積したデータを必要な時に適切な形式で参照できるということも大切です。
データストレージの種類に応じてよく使用される分析・可視化ツールというのもだいたい決まっているので、こちらも特に理由がない限りはそちらを使うのが良いです。
Kibana
Kibana は elasticsearch とよく組み合わせて使用されます。kibana 自体が Elastic stack のプロダクトの一部であるので elasticsearch との親和性が良く、蓄えられたデータを様々条件で参照・分析できます（こちらも機能が豊富すぎて使うのが大変）。
Grafana
Grafana は prometheus (thanos) とよく組み合わされて使用されます。prometheus のメトリクスを検索する PromQL を使用して必要なメトリクスをフィルタしたり独自のダッシュボードを作成して必要な情報のみを柔軟に可視化することが可能です。prometheus の他、Relational DB や Time Series DB など 多種のデータソースにも対応しています。
Security
近年では DevSecOps のような用語もあるように言わずもがな Security は重要ですが、自宅の環境をネットワークに公開しない場合には正直そこまで気にしなくてもいい感はあります。
とはいえ重要であることは変わりないので、本番での運用を意識するような場合は Security 面にも意識を配る必要があります。
Trivy
Trivy はコンテナイメージの脆弱性検出や IaC、マニフェストファイルの不備をスキャンするための OSS ツールです。
Trivy について書いた記事は以下を参照。
Other
上記のカテゴリに当てはまらないものは other に分類しています。
Litmus
Litmus は k8s クラスタ上に意図的に障害を注入し、現構成の可用性や回復力を評価するためのカオスエンジニアリングフレームワークとなっています。
カオスエンジニアリングが自宅環境で必要になることはほぼないと思いますが、対象の pod に負荷をかけたり node を落としたりとなかなか面白い動作を試すことができます。
また、大規模な環境で実際にカオスエンジニアリングを取り入れている企業もあるため、それらの雰囲気を掴むためにやってみるのもあり。
Litmus について書いた記事は以下を参照。
Identity Management
サービスが増えるにつれてユーザーやグループ、認証情報などの管理はより大変になっていきます。例えば、概要図の中では gitlab, harbor, stackstorm, elasticsearch, minio, grafana が内部てユーザー情報を管理するサービスとなってますが、新しいユーザーを追加したくなった時にそれぞれのアプリケーションに個別にユーザを追加したり、ユーザの役割に応じたロールやパーミッションを設定する、ユーザーのパスワードを更新する際に新しいパスワードを反映させる、不要となったユーザーを各サービスの登録情報から削除するといった作業はかなり面倒な工程になってきます。
そのため、サービスや組織の規模の拡大に合わせて、このようなユーザーやそれに付随するグループ等の情報、アクセス制限といった Identity を効率的に管理するためのアプリケーションの重要性が増してきます。
LDAP
LDAP はサーバー内で管理されるユーザーを効率よくクエリするためのプロトコルであり、これを利用してユーザーや組織を一元管理する機能を持つアプリケーションやソフトウェアは LDAP サーバーと呼ばれます。Active Directory のようにユーザーを一元管理し、ユーザーの固有情報 (~ identity) に基づいて関連サービスと統合することで効率的な運用を実現するのに役立ちます。
LDAP サーバーにはいくつか種類があり、それぞれ機能や特徴が異なります。
- OpenLDAP
- FreeIPA
- 389 Directory Server
- LLDAP
上記のうち LLDAP について書いた記事は以下を参照。
Authelia
Authelia は認証・認可サーバー、アクセスコントロール、OpenID Connect によるシングルサインオンなどの機能を有するアプリケーションです。LDAP と組み合わせてユーザーを効率的に管理し、OpenID Connect で各アプリケーションと連携することで管理の手間を軽減することができます。
Authelia について書いた記事は以下を参照。
Hashicorp Vault
Hashicorp Vault はユーザーのパスワードを始めとした各種機密情報を保管する Secret Manager です。サービスが増えるに連れて管理者ユーザーのパスワードやサービス間認証に使用する情報、証明書、トークンなど厳密に扱うべき情報も増えますが、それらを一元的に管理・保護することができます。
Vault について書いた記事は以下を参照。
おまけ
AWS サービスとの対応
紹介した OSS の機能と AWS のサービスを対応付けると表のようになります。
機能的にやや微妙なものは ? にしてます。
| OSS | AWS Service |
|---|---|
| Tekton Concourse |
CodeBuild |
| ArgoCD Flagger |
CodeDeploy |
| GitLab | CodeCommit, etc |
| Harbor Distribution |
ECR |
| StackStorm | EventBridge, Step Functions, etc |
| Kubernetes | EKS |
| Minio | S3 |
| Elasticsearch, Kibana | OpenSearch |
| Grafana | Managed Grafana |
| Filebeat | CloudWatch agent (logs) Firelens |
| Prometheus | CloudWatch agent (Metrics) Managed Service for Prometheus |
| Jaeger | CloudWatch agent (Trace) X-Ray |
| OpenTelemetry | AWS Distro for OpenTelemetry |
| Ansible | System Manager? |
| Terraform | CloudFormation, etc |
| Trivy | ECR Image Scan, etc |
| Litmus | Fault Injection Service |
| LDAP | ? |
| Authelia | Cognito?, IAM? |
| Hashicorp Vault | Secrets Manager |
おわりに
自宅の環境や記事にしてきたコンポーネントを機能別に分類し、それぞれの役割や立ち位置について整理しました。俯瞰的に見ることで各コンポーネントがどの領域の機能をカバーしているのか、どの機能が不足しているのかが視覚的に認識することができます。
クラウドベンダーのサービスは基本的に使う分だけ課金される一方、自宅クラウドはいくら使っても無料です（PC の電気代はかかりますが）。CI/CD や Observability を試してみたいけど費用が気になるという人や自分で手を動かしてサービスの仕組みを理解したい人は自宅クラウドの構成を検討してみるのもいいかもしれません。
Discussion