リリース/構成管理: 概要編 – 「若手エンジニアのためのDevOps入門」(6)

こんにちは、山本和道です。
本記事は連載「若手エンジニアのためのDevOps入門」の第6回です。

第1回	インフラエンジニアにとってのDevOps
第2回	Webアプリでの開発環境構築
第3回	バージョン管理システム
第4回	継続的インテグレーション/デリバリー
第5回	DevOpsのための道具箱: APIを使いこなす
第6回	リリース/構成管理: 概要

第5回はクラウドなどが提供するAPIの利用方法などについて扱いました。今回から数回に分けて継続的デリバリーを行う上で大きな役割をもつリリース/構成管理について扱います。

クラウド時代の構成管理

継続的デリバリーに取り組む上でデリバリー先となるサーバなどのインフラリソースの調達/環境構築/構成管理を素早く行うことは重要です。せっかく開発/テストを素早く行っても実際に動かせる環境を整えるのに時間がかかれば、それだけプロセス全体にかかる時間が長くなってしまいます。

素早いインフラリソースの調達/環境構築/構成管理を行うには、インフラを都度調達するのではなく初回環境構築時のみ調達して以後使い回す方法などが考えられますが、この方法を採用した場合は突発的なアクセス増などでサーバの増強/増設が必要になった際の対応に時間がかかることとなります。

もちろんあらかじめ予備機を用意しておくといった方法で回避できますが、その分インフラ調達コストが増えることになります。

他方、近年ではクラウドのような時間単位で気軽にリソースを調達できる仕組みが整ってきており、必要になった都度素早く調達する、いわゆるオンデマンドな調達が可能になっています。

システムの特性(負荷の増減の仕方やシステム自体の変化/進化の起こりやすさ)などにもよりますが、クラウドの特徴を生かしたインフラ利用を行うことで調達コストをかけずに素早くプロセス全体を回せる仕組みの構築が容易になっていますので、利用できる場合は是非利用してみましょう。

オンデマンドな調達/環境構築/構成管理を行うには

必要になった都度調達〜構成管理を行うということは、環境構築/構成管理作業を何度も行う必要があるということです。極端な例だと、テスト/確認用のサーバのために毎日環境構築し都度捨てるというような利用方法も考えられます。

このように頻繁な作業を行う場合、ボトルネックになりがちなのが「人」の作業です。

クラウドでの調達作業はコントロールパネルをブラウザなどで利用して必要となるサーバやネットワーク/ストレージの設定などを行うことも多いかと思いますが、手作業で行うとオペレーションミスの可能性もありますし、時間もかかりがちです。

オペレーションミスについてはマニュアルの充実や複数人で確認しながら作業するといった形でミスの発生を減らそうという対策も考えられますが、前回の記事で扱ったようにクラウドでは通常はAPIが提供されていることが多いですので、APIを利用してプログラム(機械)に処理させることで繰り返し実行する処理でも高い再現性を持ってミスを少なく行うことができます。また、調達後の環境構築/構成管理についても同じことが言えます。

こうしたAPIなどを用いてプログラム = コードでインフラ調達や環境構築などを行う取り組みは「Infrastructure as Code」と呼ばれています。各種書籍や対応ツールも充実しており、すでに「Infrastructure as Code」十分な実用段階に入ったと言えるでしょう。

ChefやAnsible、Terraformといったツールについては耳にしたことがある方も多いと思います。Terraformについては次回、Ansibleについては次々回の記事で実習含めて扱う予定です。

ツールを利用した調達/環境構築/構成管理の流れ

利用するツールにより方法は異なりますが、概ね以下のような流れになることが多いでしょう。

調達するインフラのコード化
サーバやデータベースなどの構成管理のコード化

中にはDockerなどのコンテナツールなどを利用して、アプリケーションと環境をパッケージングすることで複雑なOSの構成管理をせずともコンテナを配置するだけ、というような場合もありますが、その場合でもコンテナを配置する先については確保/構築が必要なことが多いですので、この流れで解説を行います。

調達するインフラのコード化

例えばWebサーバとDBサーバによるWebアプリの場合、以下のようなインフラリソースが必要になります。

サーバ2台
WebサーバとDBサーバを繋ぐスイッチ
WebサーバへのグローバルIPアドレスの割り当て
Webサーバ用のDNSレコード

ツールにより扱えるリソースが異なりますので、ドキュメントなどを参照しながら調達するインフラリソースのどの部分をコード化するかを決定します。コード化する範囲がある程度決まったら早速コードを書いていくことになります。

クラウドの場合は初期費用が不要な場合も多いですので、少しコードを書いたら実際にそのコードで構築してみる、といったことも出来ます。利用するツールの流儀に従いつつ、小さい単位に分割しながら(例えばサーバだけ、スイッチだけ、など)コードを書いていくのがオススメです。

なお、Terraform + さくらのクラウドの場合は以下のようなコードとなります。
(コードの詳細は次回以降扱いますのでここでは理解しなくて構いません)

# Webサーバの定義
resource sakuracloud_server "web" {
  # スペックなどを記載
}
# DBサーバの定義
resource sakuracloud_server "db" {
  # スペックなどを記載
}

# WebサーバとDBサーバを接続するためのスイッチの定義
resource sakuracloud_switch "switch" {
  # スペックなどを記載
}

# DNSレコードの定義
resource sakuracloud_dns_record "record" {
  # IPアドレスなどを記載
}

ツールが対応していないリソースについては別途APIを呼び出すスクリプトを書いたり、その部分だけ手作業にするといった対応が必要となることがありますので、できるだけ必要なリソースがカバーされているツールを選定しましょう。

環境構築/構成管理のコード化

こちらもコード化する範囲を決めてからコード化していくという流れになります。大抵のツールにはモジュールといった公開されている再利用可能な部品/ライブラリがありますので、それらをうまく活用することでより少なく見通しの良いコードとなるはずです。

なお、AnsibleでWebサーバ(Nginx)の構成管理を行う場合は以下のようなコードとなります。
(先ほどと同じく、コードの詳細は次回以降扱いますのでここでは理解しなくて構いません)

- name: Nginxの構成管理
  hosts: web
  become: True
  tasks:
    - name: Nginxインストール
      yum:
        name: nginx
        state: present

    - name: Nginxサービス起動/自動起動の設定
      service:
        name: nginx
        state: started
        enabled: true

一旦コード化して動作確認を行っておけば後はプログラムにて繰り返し実行出来ますので、CIサーバで実行できるようにするなどDevOpsプロセスへの組み込みが容易に行えるはずです。

デザインパターンの活用

クラウドの活用やInfrastructure as Codeについてはすでに多数の方が取り組んでおり、様々なグッド/バッドプラクティスが蓄積されてきています。それらをまとめ、概念/手法に対して名前をつける、いわゆる「デザインパターン」というものも存在します。開発側の方であればGoFのデザインパターンなどは耳にしたことがあるかもしれません。

例えば、先ほどの例ではAnsibleでWebサーバのインストールを行なっていましたが、Webサーバ自体は毎回の構築で必ず必要になる部分です。この場合、毎回サーバ構築時にWebサーバをインストールするのではなく、あらかじめある程度の環境構築を行なったイメージを用意しておき、毎回の実行時は用意したイメージを起点にアプリケーションの配置など毎回更新される部分だけ適用する、といった方法があります。

この方法は「ゴールデンイメージ」と呼ばれ、よく利用される方法です。

こういったパターンはクラウドプラットフォームや利用するツールによって違いがありますので、それぞれの環境/ツールごとにベストプラクティス/デザインパターンといったキーワードで情報収集しておくのがオススメです。

ゴールデンイメージについては次々回Ansibleを扱う際にさくらのクラウドでのPackerを利用したゴールデンイメージの作成の実習を予定しています。

当記事ではリリース/構成管理について以下のような内容を扱いました。

クラウドの活用でオンデマンドな調達が行えるようになってきた
オンデマンドな調達を行うことで頻繁に作業が必要になる
頻繁な作業では「人」の作業がボトルネックになってくる
頻繁な作業をプログラムで扱うためのインフラ構築のコード化、いわゆる「Infrastructure as Code」

次回はInfrastructure as Codeの実習として、クラウド上のインフラの調達をコード化できる「Terraform」について扱います。

以上です。