- プロダクトマネージャー(AI)
- ブリッジエンジニア
- ★東京・大阪/CS/MG
- Other occupations (78)
-
Development
- ブリッジエンジニア
- オフショアPJマネージャー
- ブリッジSE/オフショア開発
- エンジニアオープンポジション
- Webエンジニア(大阪PHP)
- フロントエンドエンジニア
- Javaエンジニア(楽楽明細)
- ブリッジSE(大阪)
- PM(楽楽シリーズ)
- テックリード(大阪/PHP)
- フロントエンドマネージャー候補
- プロジェクトマネージャー
- エンジニアリングマネージャ
- AI導入エンジニア
- プロダクト開発部長
- Web Engineer
- Webエンジニア
- フロントエンド(リーダー)
- Mobile Engineer
- Android/iOSアプリ
- 社内SE(大阪/セキュリティ)
- インフラエンジニア
- インフラエンジニア/マネージャ
- DevOps Engineer
- 社内SE(データエンジニア)
- 戦略企画・データマネジメント
- QAリーダー/マネージャー
- システム企画
- 品質管理/技術支援チーム
- AI/機械学習エンジニア
- データ基盤エンジニア
- Engineering
- UIデザイナー(リーダー)
- コーポレートデザイナー
- UIデザイナー
-
Business
- プロダクトマネージャー(AI)
- 導入支援/導入コンサルタント
- 開発マネージャー
- プロダクトマネージャー
- PdM(楽楽シリーズ)
- PMMプロダクトマーケティング
- プロジェクトマネージャ(大阪)
- プロダクトセキュリティ
- 技術推進部長
- IR
- 総務
- 労務
- HRBP
- データマネジメント・マーケ戦略
- 経営企画
- コーポレート広報
- 内部監査(業務監査)
- フィールドセールス
- ITセールス(広島)
- フィールドセールス(法人営業)
- 営業企画(イネーブルメント)
- ITセールス(名古屋)
- セールスマネージャー
- 法人営業/カスタマーサクセス
- フィールドセールス(名古屋)
- 法人営業
- フィールドセールス(東京)
- 営業企画(戦略立案)
- ITセールス
- ビジネスオープン
- ITセールス経験者
- オフラインマーケティング
- オンラインマーケティング
- 製品企画/プロダクトマーケ
- 製品企画/法要件(楽楽明細)
- ブランド企画
- 営業推進リーダー(楽楽精算)
- マーケティングリーダー
- CSマーケティング
- マーケティング担当
- ブランド企画・ブランディング
- Other
デベロッパーのkyosimotoです。
Ansibleをバージョンアップ作業の自動化ツールとして導入するための手順、おすすめ構成などについて紹介させていただきます。
目次
- 目次
- なぜAnsible
- どんな感じ?
- Ansibleの基本
- 実行方法
- 実行イメージ
- マシン要件
- ファイル構成
- ディレクトリ構成(サンプル)
- playbook(サンプル)
- ファイル構成のポイント
- 検証環境の準備
- 検証環境の説明
- 検証用仮想マシンの構築手順
- 仮想サーバにSSH接続する
- Ansible実行環境の構築
- Ansibleのインストール
- SSH接続設定
- 検証用仮想マシンのミドルウェアセットアップ
- WEBサーバの構築 (Apache2.2 + PHP7.1)
- DBサーバの構築(PostgreSQL9.6)
- WEB/DBサーバの連携チェック
- プロジェクトディレクトリ作成
- バージョンアッププロジェクト用のディレクトリ作成
- Inventoryの作成
- Inventoryの作成(補足)
- Playbookの作成
- ansible.cfgの作成
- Roleの作成
- ミドルウェアの起動
- (補足)ミドルウェアの起動
- ミドルウェアの停止
- ミドルウェアのバージョンアップ
- playbookの実行
- 最後に
なぜAnsible
私は担当サービスのバージョンアップ作業を自動化するため、シェルベースのスクリプトを開発・運用してきました。 スクリプト導入により、ほとんどの作業は自動化され、運用コストは大幅に削減されました。
半面、バージョンアップスクリプトの属人化が課題となっており、リリース時のトラブルが起きた場合に、作業担当者による 原因調査と復旧作業が難しい状態となっています。
シェルスクリプトで作成したバージョンアップスクリプトには、フレームワークのような拘束力が無く、長い運用の中でイレギュラーケースに対応したコードやフラグが追加され、複雑化の道をすすみ続ける可能性があります。
さらには、今のところこの複雑化したスクリプトをポジティブに学習したいという人はいません。問題が起きたとしても、開発担当者に聞けばすぐに解決できるからです。
私は属人化を解消するためには、シェルスクリプトによる実装をやめ、学習コストが低く複雑なコードを生まない自動化ツールの導入が必要と考えており、この要件にマッチしたAnsibleを導入提案することになりました。
どんな感じ?
今のところメリットと感じているのは下記3点です。
- 学習コストが低い
設定ファイルはYAMLという形式で記述します。設定ファイルがシンプルで、初めての人でも内容をすぐに理解できると思います。
運用作業用のモジュールが充実していますので、プログラミング書くことも読むこともほとんどありません。 - 導入コストが低い
管理対象サーバには余計なツールやデーモンをインストールする必要がありません。
SSHとPythonさえ使えれば、Ansibleからの操作が可能ですので、運用チームへも提案しやすいと思います。 - 運用コストが低い
少しの工夫で設定ファイルをそのまま手順書として扱うことができます。
Ansibleの基本
実行方法
Ansibleの実行コマンドは以下の通りです。
Inventoryには、サーバ名やIPアドレスなどの管理対象ノードの情報、Playbookには管理対象ノードで実行するタスクを記述します。
実行イメージ
Ansibleは、上記コマンドを実行するとPlaybookの内容をPythonのプログラムに変換します。
変換されたプログラムファイルは、Inventory(インベントリ)に記述された管理対象ノードに転送後に実行されます。
マシン要件
ファイル構成
私のお勧めするファイル構成サンプルを紹介します。
ディレクトリ構成(サンプル)
playbook(サンプル)
以下、playbookファイルの内容です。
- myapp_verup/versionup.yml
ファイル構成のポイント
ファイル構成を考える上で、お勧めするポイントは下記2点です。
- playbookを日本語で記述する playbookのタスクを日本語化することで、設定ファイルの可読性が上がる、playbookがそのまま手順書/ドキュメントになるという点でメリットが大きいと考えています。
- バージョンアップ作業に集中する。
バージョンアップ作業以外のタスクを含めないようにします。
例えば、サーバ構成管理や冪等性のための実装を行うと、Ansibleの設定は複雑化します。 複雑化は属人化を進行させますし、(Serverspecなど)ツールを使ったテストなども検討する必要がでてくるでしょう。
検証環境の準備
ここからは、Ansibleの検証用環境の構築手順について記載します。
検証環境の説明
仮想マシンの構築に Vagrant + Virtualbox を利用します。 検証用に構築するサーバは以下の通りです。
ホスト名IPアドレスOSMW/Toolcontrol192.168.33.100CentOS 6.9Ansibleweb192.168.33.101CentOS 6.9Apache2.2 + PHP7.1db192.168.33.102CentOS 6.9PostgreSQL9.6
別のディストリビューションで検証したい場合は、Vagrant Cloudよりboxイメージを検索し、後述する「vagrantinit」コマンドの引数に指定してください。
検証用仮想マシンの構築手順
仮想サーバにSSH接続する
Windowsの場合は、ターミナルソフトで接続します。
Ansible実行環境の構築
AnsibleのインストールとSSH設定の手順について記載します。
Ansibleのインストール
SSH接続設定
接続先サーバへのSSH接続を簡単にするためSSH設定を記述します。
検証用仮想マシンのミドルウェアセットアップ
バージョンアップ手順の検証用に、予めミドルウェアをセットアップします。
WEBサーバの構築 (Apache2.2 + PHP7.1)
DBサーバの構築(PostgreSQL9.6)
WEB/DBサーバの連携チェック
プロジェクトディレクトリ作成
ファイル構成の項目で紹介したAnsibleプロジェクトを作成していきましょう。
バージョンアッププロジェクト用のディレクトリ作成
Inventoryの作成
Inventoryでは、管理対象ノードのホスト名、またはIPアドレスとグループの定義を行います。 ファイルはINIファイル形式で記述します。
- myapp_verup/development.ini
Inventoryの作成(補足)
Inventoryを本番環境用、ステージング環境用、開発環境用に分けて管理することで バージョンアップ対象の切り替えできるようにします。
以下サンプルです。
- myapp_verup/product.ini (本番環境用)
・myapp_verup/staging.ini (ステージング環境用)
Playbookの作成
Playbookには、バージョンアップ手順を記述します。
(どのサーバでどんなタスクをどのような順番で実行するかを記述します)
- myapp_verup/versionup.yml
ファイルはYAML形式となりますので、拡張子は「yml」、1行目は「---」としてください。
2行目以降にバージョンアップ手順を記述します。書き方のルールは以下の通りです。
ansible.cfgの作成
Ansibleの動作設定を記述するファイルで、INI形式で記述します。
- myapp_verup/ansible.cfg
Roleの作成
Playbookのrolesディレクティブに記述したタスクの実態をrolesディレクトリの配下作成します。 例えば、「Cronを起動する」というタスクは、roles/Cronを起動する/tasks/main.yml に、処理内容を記述します。
ミドルウェアの起動
service コマンドが準備されているミドルウェア(デーモン)であれば、「service」モジュールを使って以下のように記述します。
- myapp_verup/roles/cronを起動する/tasks/main.yml
・myapp_verup/roles/apacheを起動する/tasks/main.yml
・ myapp_verup/roles/postgresqlを起動する/tasks/main.yml
(補足)ミドルウェアの起動
service コマンドが提供されていないミドルウェアの場合は、「shell」モジュールと「wait_for」モジュールで実装することもできます。
shell モジュールは終了ステータスコードが0以外は、すべてエラーとして処理を中断しますので注意が必要です。 ステータスコードが0以外でも処理を継続する場合には、下記サンプルを参考にしてください。
ミドルウェアの停止
service コマンドが準備されているミドルウェア(デーモン)であれば、「service」モジュールを使って以下のように記述します。
- myapp_verup/roles/cronを停止する/tasks/main.yml
myapp_verup/roles/apacheを停止する/tasks/main.yml
myapp_verup/roles/postgresqlを停止する/tasks/main.yml
ミドルウェアのバージョンアップ
RPMがyumコマンドでバージョンアップできる場合は、「yum」モジュールを利用して「latest」の状態に更新します。
- myapp_verup/roles/apacheをバージョンアップする/tasks/main.yml
myapp_verup/roles/phpをバージョンアップする/tasks/main.yml
myapp_verup/roles/postgresqlをバージョンアップする/tasks/main.yml
リポジトリ管理されていない(カスタムRPMをつかっている)場合は、以下設定を参考にしてください。
※ディレクトリ構成については公式ページのBest Practices の「Directory Layout」を参考にしています。
- myapp_verup/roles/Apacheをバージョンアップする/tasks/main.yml
・myapp_verup/roles/Apacheをバージョンアップする/templates/httpd.conf.j2
※ 上記変数部分は、例えばInventoryファイルに記述した変数の値に自動で 置き換えることができます。
・myapp_verup/roles/Apacheをバージョンアップする/vars/main.yml
playbookの実行
実行結果は以下の通りです。
日本語で書いたタスクがそのままターミナル上のログに出力されていることが確認できます。
(/tmp/ansible.log にも出力されます。)
最後に
本記事は、運用チーム向けにAnsibleを使ったバージョンアップ自動化提案後に書いた記事です。
本番運用が開始されれば、いろいろと課題はでてくると思いますので、知見がたまりましたら
改めて情報を共有させていただこうと思います。
以上、ありがとうございました。