LoginSignup
4
2

More than 5 years have passed since last update.

@yamachan360(Toshio Yamashita)

Bluemix環境で動作するWordPressのための自動化されたパイプライン (Automated Pipeline for WordPress in Bluemixの翻訳)

Posted at

米国 developerWorks サイトの developerWorks Recipes に「Automated Pipeline for WordPress in Bluemix」という興味深い投稿があったので、試しつつざっと訳してみます。

最初に

基本は翻訳なので、基本的な著作権は元原稿の作者・所有者にあります。感謝はできれば元ページへお願いします。wuretaさんに感謝！

元原稿にないコンテンツ、つまり私が作成した全ての文章、画像、コード等は Creative Commons Zero ライセンスです。元原稿由来の制限がない限り、自由に活用してください。内容は確認しつつ訳していますが、全て無保証です。勘違いや翻訳のミスはコメント欄で指摘をお願いします。

概要

対象読者: 中級者

この記事(レシピ)の目的は、Bluemix環境におけるDevOpsパイプラインの構成のしかたを説明することです。それによりWordpressをベースとしたアプリケーションを構築し、開発環境に自動的にデプロイし、それをテストおよび本番環境にプロモートすることができるようになります。

構成要素

このレシピは IBM Bluemix のコンセプトに関する基礎知識、パイプラインの構成、PHP および Wordpress の基礎知識を前提としています。

ステップ･バイ･ステップ

1. 本番環境を用意する

このレシピで紹介するのは、WordPressをホストする3つの異なった環境のための、自動化されたパイプラインを構築するための基礎的な実例です。製品と自動化に関する幾つかの技術的な懸念事項への対応策を示すのが主目的なので、このレシピでは全ての環境(開発環境、テスト環境、本番環境)は1つの同じスペースに属し、また1つのデータベースを共有します。

最初のステップでは、Bluemix環境で動作するWordPressを構築しデプロイする (Deploy and configure WordPress in Bluemixの翻訳) レシピを完了してください。その結果、WordPressが動作する環境を得るはずで、これを本番環境として使用します。

image.png

【訳注】上の2つのアプリは今回のレシピに関係ないのでスルーしてください、すみません

ノート：あなたの経験と必要に応じて、リソースやアクセスを取り扱うため異なったスペースにある分離された環境に配置したり、それぞれの環境に応じてデータを独立させるため異なったデータベースを利用するなど、異なった戦略をとってもかまいません。

2. テスト環境スタブを作成する

このステップではテスト環境に使用するPHP CloudFoundryアプリケーションを作成します。カタログ を開き、CloudFoundryアプリにあるPHPビルドパックをクリックします。

image.png

アプリ名は元となるアプリの名前にTestを追加し「WordpressSampleJPTest」を入力します。

image.png

【訳注】自動的にセットされるホスト名は念のため小文字に変更しています

このレシピでは全ての環境を同一スペースに置くため、このアプリケーションは「dev」と呼ばれる前回と同じスペースに配置します。しかし、あなたは別なスペースを使用するという別な戦略を使えることは忘れないでください。「作成」ボタンをクリックしてこの手続きを完了します。

image.png

「接続」エリアまでスクロールし、「既存に接続」ボタンをクリック。

image.png

以前に作成した「Compose for MySQL」インスタンスを選択し、右下にある「接続」ボタンをクリック。

image.png

「アプリの再ステージ」ダイアログが表示されますので、「再ステージ」をクリックして継続します。

image.png

このアクションの後、ダッシュボードに移動して新しいアプリケーションが作成されていることを確認しましょう。

image.png

3. 開発環境スタブを作成する

このステップでは開発環境に使用するPHP CloudFoundryアプリケーションを作成します。「WordPressSampleJPDev」というアプリ名で、ステップ2と同じ方法で作成します。

以下は作成後の確認画面です。

image.png

4. パイプラインを構成する

ダッシュボードに移動し、(以前にツールチェインを作成した)本番環境を探してください。このレシピでは「WordPressSampleJP」です。

image.png

本番環境アプリケーションをクリックして概要画面を開き、「継続的デリバリー」ボックスにある「ツールチェーンの表示」ボタンをクリックします。

image.png

次に、「Delivery Pipeline」ボックスをクリックします。

image.png

以下の図のようなデフォルトのパイプラインが表示されるはずです。

image.png

Deploy Stageの再構成

開発環境へ自動的にデプロイするため「Deploy Stage」を再構成します。この環境ではWordPressの構成で特別なテーブルのプリフィックスを付与することで、データベースを共有するものの、テーブルのデータは異なった環境では共有しないように設定します。

【訳注】テーブルのプリフィックスに関しては $table_prefix : データベーステーブル名の接頭辞 を参照してみてください。ジョブで書き換えているのは以下の部分だとおもわれます

image.png

以下を実行しましょう。

  1. 「Deploy Stage」ボックスの歯車アイコンをクリック
  2. 「ステージの構成」オプションを選択
  3. トップタイトルをクリックして「Deploy Stage」から「Deploy Development Stage」に変更
  4. アプリケーション名を「WordPressSampleJP」から「WordPressSampleJPDev」に変更
  5. デプロイ・スクリプトの欄のスクリプトを
    #!/bin/bash
    sed -i "/\$table_prefix/c \$table_prefix = 'wpdev_';" wordpress/wp-config.php
    cf push "${CF_APP}"
    に変更
  6. フォーム最後にある「保存」ボタンをクリック

image.png

以下が実行結果です。

Deploy Test Stageの作成

image.png

WordPress上のデータの混在を避けるため、テスト環境のための異なったテーブルスペースを構成した新しいステージを作成する必要があります。しかしこの場合は自動化はできず、開発チームは再生アイコンでそれを手動で起動し、コードをテスト環境にプロモートする必要があります。

以下を実行しましょう。

  1. 「ステージの追加」をクリック
  2. 名称に「Deploy Test Stage」を入力
  3. ステージ・トリガー欄で「このステージが手動で実行されたときにのみジョブを実行」を選択
    image.png
  4. フォーム上部の「ジョブ」タブをクリック
  5. 「ジョブの追加」をクリック、そしてジョブタイプの選択で「デプロイ」を選択
    image.png
  6. アプリケーション名を「WordPressSampleJP」から「WordPressSampleJPTest」に変更
  7. デプロイ・スクリプトの欄のスクリプトを
    #!/bin/bash
    sed -i "/\$table_prefix/c \$table_prefix = 'wptest_';" wordpress/wp-config.php
    cf push "${CF_APP}"
    に変更
  8. フォーム最後にある「保存」ボタンをクリック
    image.png

以下が実行結果です。

image.png

Deploy Production Stageの作成

最後に、本番アプリケーションをデプロイするための手動で起動するステージを作成します。これは標準のWordPressテーブルのプリフィックスを使用します。

以下を実行しましょう。

  1. 「ステージの追加」をクリック
  2. 名称に「Deploy Production Stage」を入力
  3. このステージが手動で実行されたときにのみジョブを実行」を選択
  4. フォーム上部の「ジョブ」タブをクリック
  5. 「ジョブの追加」をクリック、そしてジョブタイプの選択で「デプロイ」を選択
  6. フォーム最後にある「保存」ボタンをクリック

以下が最終的なパイプラインの構成です。

image.png

5. Prepare Git

パイプラインを使用する前に、アプリケーションのコードをgitリポジトリに反映させる必要があり、この最初のアクションを通じてマスターブランチが作成されます。そのために以下を実行します。

  1. ツールチェーンからOrion Web IDEにアクセスします
    image.png
  2. IDE左側のバーにあるGitアイコンをクリックします
    image.png
  3. git コメントを入力します
  4. 右上にある「コミット」ボタンをクリックします
    image.png
  5. そして変更をリモートのgitサーバーに届けるため、「プッシュ」ボタンをクリックします。実行が完了すると「発信」欄にあったコミット情報が「履歴」欄に移動します
    image.png
  6. パイプラインに戻り (WordPressSampleJP アプリケーション -> ツールチェーンの表示 -> Delivery Pipeline) 結果を確認します。Build stageが起動されており、Deploy Development も実行されています。
    ノート:パイプラインの実行には数分かかります
    image.png
  7. Deploy Test Stageの再生アイコンをクリックし、コンテンツをこの環境にプロモートします。数分待ってから結果を確認しますが、以下のようになっているでしょう。
    image.png

6. 全ての環境でWordPressを初期化する

この時点で、開発環境とテスト環境が有効化されていますが、これらの環境ではWordPressの初期化がまだ実施されていません。Bluemix環境で動作するWordPressを構築しデプロイする (Deploy and configure WordPress in Bluemixの翻訳) レシピの ステップ5 WordPressのインストール で説明したアクションをそれぞれ実施する必要があります。

【訳注】コードや設定はパイプラインで反映されたのですが、WordPressの設定を格納するデータベースはプリフィックスで分離されていることを思い出してください。個々のサイトごとに初期化が必要です。

  1. http://wordpresssamplejpdev.mybluemix.net/wordpress/wp-admin/install.php にアクセスしインストールを完了します
  2. 「日本語」を選択し「続ける」ボタンをクリック
  3. フォームに入力し(サイトのタイトル、ユーザー名、パスワード、メールアドレス)「WordPressをインストール」ボタンをクリック
  4. 「ログイン」ボタンをクリックし http://wordpresssamplejpdev.mybluemix.net/wordpress/wp-login.php サイトにログインして結果を確認する
  5. http://wordpresssamplejptest.mybluemix.net/wordpress/wp-admin/install.php にアクセスしインストールを完了します
  6. 「日本語」を選択し「続ける」ボタンをクリック
  7. フォームに入力し(サイトのタイトル、ユーザー名、パスワード、メールアドレス)「WordPressをインストール」ボタンをクリック
  8. 「ログイン」ボタンをクリックし http://wordpresssamplejptest.mybluemix.net/wordpress/wp-login.php サイトにログインして結果を確認する

Bluemix環境で動作するWordPressを構築しデプロイする (Deploy and configure WordPress in Bluemixの翻訳) レシピにおける作成の過程で、本番環境は既に有効で初期化されています。しかし今回設定したパイプラインの正式なプロセスで再度デプロイしてみましょう。そのためにはパイプラインに戻り(WordPressSampleJP アプリケーション -> ツールチェーンの表示 -> Delivery Pipeline)、Deploy Production Stageの再生アイコンをクリックし、ジョブ完了を待ちましょう。

image.png

ついに、我々はgitと統合された自動化されたパイプラインと、テスト環境と本番反映のみに手動で反映させる手動のトリガーを入手しました。以下はこのレシピの成果で、3種類の操作可能なWordPress環境がそれぞれ異なったコンテンツを表示しているスクリーンショットです。

image.png

image.png

image.png

さいごに

このレシピでは以下が可能なことを示しました。

  • Bluemix上でWordPressコードの変更を検知できるGitと統合された自動化されたパイプラインを構成する
  • それを更に自動的に開発環境に反映する
  • (開発作業の実施後に)プロジェクトメンバーが開発環境からテスト環境への反映を手動で開始できる
  • (動作テストの実施後に)プロジェクトメンバーがテスト環境から本番環境への反映を手動で開始できる
  • これら全ての環境が同じデータベースを用いつつ、異なった独立したテーブルのデータを保持する(なので各環境のコンテンツは互いに影響しない)

次のステップ

  • モニタリングや処理能力の自動拡張サービスの利用を検討する
  • より良いアクセスとリソースのコントロールのため、異なったデータベースに独立したデータを配置する、異なったスペースを利用する、など他の戦略を検討してみる
4
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
4
2