とあるマイクロアプリケーションサーバを立ち上げる必要があり、構成を考えました。
基本設計として、本記事にまとめることにします。
既に自宅サーバ(Windows10)にDocker、Coder、GitLabを導入しており、今回も活用します。
要件としては、下記３点です。
- 一度仕組みを作れば、スケールアウトや別環境での再構築が容易
- いつでもどこでも開発や作業を可能にする(開発環境でCoderを利用する)
- 開発環境から検証、本番環境への移送もCoderのターミナルでのコマンド実行で完結させたい
目次
システム構成
まず、システム構成です。
なるべくIaC(Infrastructure as a Code)な構成とします。IaCは、IT基盤をソースコードで構築、管理する考え方です。
IaCの利点は、IT基盤構築の自動化です。
従来、ミドルウェアインストール、設定は手順書を作成して手動で行う方法が一般的でした。手動の場合、同じような機能が複数サーバで必要な場合、工数は2倍、3倍と必要になります。
IaCの実現には、インフラ技術者にも多少のプログラミングスキルが必要ですが、一度仕組みを作成すれば、サーバ構築の自動化が可能になります。
管理主体がソースコードのため、IT基盤をGit等でバージョン管理することも可能です。
本構成では、IaCを実現するためのツールとして、DockerとAnsibleを採用しています。
開発から本番デプロイまでの流れ
開発から本番デプロイまでの流れは以下です。
- Coderの開発環境を利用して、開発サーバ(Dockerコンテナ)上でサーバアプリを開発する
- 開発環境で動作確認を行い、問題なければGit Push
- Git Pullで最新のアプリを取得し、Ansibleで検証サーバに向けて、構築、デプロイ手順を実行する
- 検証環境で動作確認を行い、問題なければ、本番サーバに向けて、構築、デプロイ手順を実行する
Ansibleで検証サーバと同一環境を本番サーバに適用できるようにする
検証サーバと本番サーバを同一構成にしたければ、検証サーバのVMイメージを本番環境にすれば早そうですが、厳密には、検証サーバと本番サーバは構成が異なるため、そのまま利用はできませんし、そもそもVMイメージのアップロードは手動になるので面倒です。
Ansibleを利用すれば、構築パラメータを検証、本番で分けることができる上、コマンドを実行するだけで構築やアプリケーションのアップデートが完了します。
検証サーバを構築して、問題なければ、同じ手順で本番サーバにも適用します。
Ansibleで手順書を管理し、コマンド一つで環境を自動構築できるようにします。
なお、サーバアプリケーションは、Azure Functionsのコアツールを利用して作成しており、スケールアウトしたくなった場合は、Azure Functionsに載せる算段です。
別環境に移動する場合もAnsibleが活躍することは間違いないでしょう。
Coder(Code Server)でオールインワンな開発環境を用意
開発～本番デプロイまでは、すべてCoder内で完結させます。
Coderの開発環境は、インターネット公開しているため、家にいなくても開発可能です。
ただし、検証サーバのインフラ部分だけは、Coderで構築できないので、手動でUbuntu Serverを立てる必要があります。
OSインストール直後のタイミングで、VirtualBoxのスナップショットを取得しておけば、Ansibleの実行で問題があって最初からやり直したい場合にスナップショットで巻き戻すというやり方が可能です。
GitLabはバックアップ兼、移送の中継点とする
GitLabでソース管理を行いますが、バックアップも兼ねて自宅サーバ内の別ドライブにデータ保管しています。
これにより2つのディスクが同時に破損しない限り、片方のディスクからデータを戻すことができます。
また、Gitの仕組みをアプリのデータ移送手段として活用します。
今回の場合は、開発サーバコンテナ内のアプリケーションをAnsibleコンテナに移送する必要がありますが、Gitコマンドでバックアップを取りつつ移送を行います。
本番サーバは、VPS上にあり、LAN外でGitLabとの直接通信が不可のため、Ansibleによるデプロイを実施します。
AWX(Ansible Tower)を立てるほどでもない
Ansibleをより簡単に実行するため、AWXやAnsible Towerを用意するのが一般的なやり方と思います。
AWXは、GUIでAnsibleの実行を複数ユーザ間で簡単に管理、実行するためのシステムです。
本システムでは、運用者は自分一人のため、Ansible実行時はコマンド実行することにします。
ただし、Docker越しのAnsibleのコマンドがものすごく長くなるため、ラッパーシェルを用意します。
まとめ
この構成が一番良いとは考えていませんが、比較的保守、運用が楽な構成と思います。
当方インフラ技術者として働いていますが、最近では、パブリッククラウドのSaaSを組み合わせてシステムを構成するパターンが増えてきています。
今回のシステムもSaaSを使えば、Web画面をポチポチで完了してしまいますが、パブリッククラウドは個人利用するには高価(月額数千円)です。
適切にスケール計算したVPSを利用すれば、安価(月額数百円～)ですので、マイクロサービスを個人利用したい場合には、今回の構成が向いていると思います。
コメント