カテゴリー: 技術メモ2

TableauServerのインストール時に気をつけること. 過去の経緯からかライセンス,サイトロールの関係が結構カオス. 増築しました感がかなりある. ライセンス,サイトロール,パーミッションの3要素からアクセス権が決まる. 複雑... 1. キャッシュサーバの構成. 1. 実体はCacheServerプロセス. 1. クエリと実行結果のペアをキャッシュする. Webブラウザの操作によりクエリが実行されるときにキャッシュを更新. 1. 可用性(性能)を上げるにはキャッシュサーバプロセスを複数のノードに構成する. 1. tsmコマンドで構成を変更. tsm data-access caching set -r . 規定値は全キャッシュ. 有効時間(value)を指定可能. 1. プロセス分散の適用 1. 分散パターンは3種類. シングルノード,マルチノード,高可用性. 高可用性はマルチノードのより冗長なサブセット. 1. マルチノードにおいて\"最初のコンピュータ(初期ノード)\"だけ他のノードと扱いが異なる. 初期ノードにしかインストールできないプロセスがある. 1. サブスクリプション/メールアラート 1. 「ビュー」「ワークブック」の\"イメージ\",\"PDFスナップショット\"を定期的に作成しメールで送信する機能. 1. 自分自身向けか(所有者,プロジェクトリーダー,管理者であれば)人向けにサブスクライブできる. 1. [検索]-[全てのワークブック]-[ツールバー]-[サブスクライブ] 1. サブスクリプションを受け取るには[画像]と[画像/PDFのダウンロード]パーミッションが必要. 1. アカウントをメールアドレスとして読んで送るため受け取るアカウントがメールアドレスでないといけない. 1. サイト構成オプション 1. ユーザー数,[ユーザー]から確認. 1. ストレージ容量,[サーバーのステータス]-[サーバーディスク空き容量].過去30日間のディスク使用量,先月のディスク使用量推移.GBと%. 1. サイトサブスクリプションの有効化-[設定]-[サブスクリプション]-[ユーザーにワークブックおよびビューのサブスクライブを許可する] 1. サイトサブスクリプションの編集-[タスク]-[サブスクリプション]-[アクション]-[スケジュールの変更]/[件名の変更]/[空きビューモードの変更]/[サブスクリプションの解除] 1. プロジェクト構成オプション-[検索]-[プロジェクト]-[共有]/[名前の変更]/[移動]/[パーミッション]/[所有者の変更]/[削除] 1. ユーザの構成オプション-[ユーザ]-[各ユーザ]-[設定] 1. サブスクリプションタイムゾーン -> スケジュールのタイムゾーン設定 1. 抽出,フロー,スケジュールされた更新 -> ジョブのアップデートがあったときにメール通知するか否か 1. サブスクリプション一時停止通知 -> 繰り返しエラーを検知したときにサブスクリプションが止まる -> メール通知するか否か 1. データアラート一時停止通知 -> 繰り返しエラーを検知したときにデータアラート通知が止まる -> メール通知するか否か 1. 誰がユーザーを追加できるか? 1. 前提として十分なユーザーライセンスとロールライセンスが必要 1. サーバ管理者サイトロールはユーザを追加できる. サイト管理者サイトロールはサーバ管理者サイトロールを持つユーザが許可した場合に限りユーザを追加できる. 1. ユーザーの制限とライセンス 1. コアベースライセンスの場合,定義した数のCreatorライセンス,無制限のExploreライセンス 1. ユーザーベースライセンスの場合, ライセンスに所有可能なユーザーの最大数が記載. 1. コアベースライセンスからユーザーベースライセンスへの移行(ライセンス変換)が可能. 1. ユーザーの追加 1. ユーザの追加体系は大枠でサーバーレベル,サイトレベルの2種類.サイトが1つの構成では自動的にサーバレベルの体系が適用. 1. サイトが2つ以上の場合,サーバレベル/サイトレベルの並列.サーバ管理者のみがサーバレベル追加可.[サーバーユーザー]と[サイトユーザー]の2通りの画面に入れる. 1. ライセンスタイプとサイトロール 1. ライセンスタイプはユーザ毎に定義. ユーザにどのサイトロールを割り当てるかにより必要なライセンスタイプが異なる. 1. サイトロールはユーザ毎に定義. マルチサイトではサイト毎に異なるサイトロールを持てる. あるサイトではCreatorサイトロール,別のサイトではViewerサイトロール.など. 1. サイトロールはユーザが持ち得る最大の権限. だが, ユーザがサイトロールの最大の権限を利用できるかは,コンテンツ毎に設定されたパーミッションにより決まる. 1. 管理者レベル 1. サーバ管理者=>TableauServerでのみ利用可能.全リソースに対する無制限のアクセス権. 1. サイト管理者=>TableauOnlineではこれのみ利用可能. サーバ管理者がサイト管理者にユーザの管理/サイトロール,サイト追加を許可するかを決定できる. 1. パブリッシュ可能/不可能な人物 1. Creatorライセンス-サーバ管理者/サイト管理者Creator/Creator => 可能 1. Explorerライセンス-サーバ管理者/サイト管理者Explorer/Explorer(パブリッシュ可能) => 可能 1. Explorerライセンス-Explorer => 不可 1. Explorer(パブリッシュ可能)についてはCreatorに纏わる権限(データソースへの接続など)に制限がある. 1. ローカル認証/ActiveDirectory経由のインポート 1. ローカル認証時のユーザ追加 - [新規ユーザー]押下. ローカル認証時にユーザ名の重複を避けるために電子メールアドレスをユーザ名として使うと良い. 1. ActiveDirectoryを介したインポート - TableauServerでActiveDirectory認証をおこなう設定をしている場合,ドメイン名無しでActiveDirectoryユーザを入力できる.フルネーム禁止. 1. パーミッション 1. パーミッションの構成 1. コンテンツ/プロジェクトに対して, ユーザ/グループに許可/不許可を与える. 1. パーミッションの段階的構成. Lv1.プロジェクトレベルに設定/ Lv2.コンテンツレベルに設定. プロジェクトに設定したパーミッションはサブコンテンツとネストされたプロジェクトに適用. 1. パーミッション設定画面の使い方. 上ペインで[ユーザ]/[グループ]を選択する. => 下ペインに該当ユーザの有効なパーミッション一覧が表示される/編集できる. 1. 下ペインのパーミッショングリッドのセル(許可/不許可が表示される部分)にカーソルを合わせると, 許可/不許可の理由が得られる. 1. プロジェクトのパーミッションロック => コンテンツ, ネストされたプロジェクトのパーミッションをカスタマイズできないように保護する. 1. 種類 => \"許可\",\"拒否\",\"未指定\". 1. 複雑にしないために => ユーザではなくグループに対して設定すべき. コンテンツではなくプロジェクトに設定すべき. 1. パーミッションの詳細 1. プロジェクト 1. ビュー => 許可の場合,プロジェクトを表示できる. プロジェクト内のコンテンツに関してではなく, プロジェクト自身の表示に関する. 1. パブリッシュ => Tableau Desktop, Tableau Prep Builderからプロジェクトにコンテンツをパブリッシュできる. コンテンツの移動,Web作成時の保存にも必要. 1. ワークブック 1. ビュー => 許可の場合,ワークブックを表示できる. 1. フィルター => 許可の場合,ビュー内のフィルターを操作できる. 不許可の場合,フィルターが表示されない. 1. コメントの表示 => 許可の場合,ワークブック内のビューに関連付けられたコメントを表示できる. 1. コメントの追加 => 許可の場合,ワークブック内のビューに対してコメントを追加できる. 1. イメージ/PDFのダウンロード => 許可の場合,ワークブック内のビューをPNG,PDF,PowerPointとしてDownloadできる. 1. サマリーデータのダウンロード => ユーザはビュー内や選択したマーク内の集計データを表示したり, CSVとしてDownloadできる. 1. データソース 1. ビュー => 許可の場合,サーバ上のデータソースを表示できる 1. 接続 => 許可の場合,Tableau Desktop,Tableau Prep Builder,データに聞く,Web編集でデータソースに接続できる. 1. データソースのダウンロード => 許可の場合,サーバからデータソースを*.tdsxとしてダウンロードできる. 1. 上書き => 許可の場合,データソースをパブリッシュしサーバ上のデータソースを上書きする. 1. 削除 => 許可の場合,データソースを削除できる. 1. パーミッションの設定 => 許可の場合,パーミッションルールを作成して編集できる. 1. Tableauのセキュリティモデル 1. プロジェクト 1. コンテンツへのアクセスを整理,管理するために使用するコンテナ. プロジェクト単位で権限を処理する. 1. 階層. 上位プロジェクトを作成できるのは管理者のみ. 所有者とプロジェクトリーダが上位プロジェクトの下にネストされたプロジェクトを作成できる. 1. 所有者とプロジェクトリーダはプロジェクト,コンテンツ,下位プロジェクトに対してアクセス権を持つ.

ソースはオンラインヘルプ. なんとなくFileMakerServerを思い出した. 1. 事前準備 1. 組織全体でDesktopとServerのバージョンを揃える. 2020.2など. 1. プロダクトキーを取得しておく. 1. クリーンな環境にインストールする. 理由はパフォーマンス,セキュリティ,相互運用性. 1. インストール手順 1. Setupファイルを実行 1. インストールパスの設定 (規定:C:Program FilesTableauTableau Server) 1. ゲートウェイポートの設定 (規定:80) 1. 取得済みのプロダクトキーを登録する 1. アイデンティティストアとSSO 1. ローカル/ActiveDirectory 1. ActiveDirectoryの構成 => Domain:完全修飾子(FQDN)/NetBios:FQDNの一番左のノード 1. ローカル認証 1. アイデンティティストア内のユーザ名は権限・パーミッションと紐づけられている. 1. 認証が検証された場合にTableauServerはTableauリソースへの認可をおこなう. 1. パスワードは直接保存されない. ハッシュ値が保存される. 1. SAML (SecurityAssertionMarkupLanguage) 1. セキュアなWebドメインがユーザ認証と認可データを交換するXML規格. 1. 外部のアイデンティティプロバイダ(IdP)とSAML2.0でユーザ認証できる. 資格情報はTableauServerが持たない. 1. サーバ全体のSAML認証, サイト毎のSAML認証. 1. Kerberos 1. KDC(キー配布センター)の使用に依存した3要素認証プロトコル 1. ActiveDirectoryのKerberos環境でKerberos認証をサポート. KerberosがTableau Serverへの認証を処理する. 1. ユーザはADDomainController(Kerberos KDC)にログイン. KerberosKDCからチケットを取得. チケットを使用してTableauにログイン. 1. Kerberos認証はユーザ認証のみ.コンテンツ等の内部許可,認可は処理しない. 1. OpenID Connect 1. GoogleなどのIdPにサインインできるようにする標準認証プロトコル. 1. IdPにログイン後, TableauServerに自動的にTableauServerにサインインする. 1. Tableau ServerはOpenID Authorization Code Flowのみをサポートする. 1. 信頼できるチケットと認証 1. TableauServerのViewを含むURLを開く. Webサーバは信頼できるTableauServerにユーザ名を送る. 1. TableauServerは受けたPostが管理下のIPアドレスか否かを確認しOKであればチケットを発行してWebサーバに応答する. 1. Webサーバはチケットを含むビューのURLを生成しブラウザに返す. 1. ブラウザは返ってきたURLをTableauServerに送る. 1. TableauServerはチケットを引き換えてセッションを作成しビューの最終的なURLをクライアントに返す. 1. SSL の設定方法 1. SSLの範囲 1. 外部HTTPトラフィックに対してSSLを使用する. 1. Client(Desktop,Web,tabcmd)/Server間のトラフィックに対してSSLを使用する. 1. コンポーネント間とリポジトリの間の全てのHTTPトラフィックをSSL化する. 1. ユーザ認証にSSLを使用する. ホストされているコンテンツのパーミッションや認証処理には使用されない. 1. SSL証明書の要件. PEM,X509X,SHA-2. 対応するkey,chainも必要. ワイルドカード証明書も可能. 1. 設定手順 1. キーファイルとCSRを生成. 1. TableauServer内のビルトインWebサーバ(Apache)ディレクトリでopensslコマンドを実行. 1. CAにCSRを送信してSSL証明書を取得. 1. キーファイルとSSL証明書をTableauServerに設定. 1. クラスタのSSL構成. \"最初のノード\"にのみゲートウェイプロセスが存在. このノードでのみSSL設定が必要. 1. Gatewayが複数ある場合はロードバランサにSSL設定. 手前にパススルーロードバランサを配置し個別にSSL設定もできる. 1. 証明書を C:Program FilesTableauTableau ServerSSL に保存. 1. TSM Web > [構成] > [セキュリティ] > [外部SSL] > [外部WebサーバのSSL] > [SSLでサーバ通信を有効にする]を選択 1. 証明書ファイル(.crt,.chain)をアップロードし,必要であればkeyfileのパスコードを入力. 1. マルチノード構成の場合, 最初のノードへの操作だけで必要な全てのノードに証明書が配布される. 1. [保留中の変更を保存] -> [変更を適用して再起動]. 1. 単一マシン環境インストールのベストプラクティス 1. 全てのプロセスが1台のマシン上にインストールされたスタンドアロンの単一サーバノード. 1. 8コアCPUの場合 1. VizQL Server : 2 instances (物理コア数/4) 1. Backgrounder, CacheServer, DataServer : 2 instances 1. その他のプロセス: 1 instance each. 1. サイレントインストール 1. オンラインヘルプ上の表記は「自動インストール」 1. オンラインコミュニティでサポートされているPythonスクリプト(SilentInstall.py)を実行する. 1. 自動インストールの実行に必要な追加構成情報を用意 1. config.template.json, registration.template.json, secrets.template.json 1. templateをhomeにコピーし編集 1. 最初のノードでSilentInstall.pyを実行する. 実行パラメタに追加構成情報ファイルのパスを渡す.

この記事 Tableau未経験者がTableauを扱う仕事をすることになったのと, 合わせてServer Certified Associate資格の取得が必要になったためいつものごとく学びの軌跡を記録していく. マルチノード高可用性のための設計を学ぶというモチベ 潰しが効く系ではないのだが, 実際にインストールして設定しようとすると知らなければならないことが並んでいる. 使わないけれど知識として並べてある, という一部のベンダー資格とは違う印象がある. 通常,いきなりマルチノードで高可用性が..とかにはならないはずだがどこかで入門レベルが存在しなければならない. 最小構成/シングルノード構成/マルチノード構成へとスケールできるアーキテクチャになっていることを理解することが結局のところスケールを前提とした入門になり得ると思う. あるシステムのシステム構成がここまで明らかになっているのも珍しい印象. マルチノードと高可用性実現のため, レイヤやコンポーネントが想像以上に分離していて, スケールさせる際の自由度の素になっている. スケールのための設計をゼロベースで学んだ経験がないため,自分が自作するレベルのシステムのアーキテクチャではここまで分解しないな,というのは当然あったが, 正直かなり設計の勉強になった. 対策 過去問が公開されていたり,公式参考書があったりはしないため,試験のための習得にはなりづらい. マルチノード化による高可用性を実現するためのアーキテクチャを学ぶ機会と捉えれば,結構モチベになると思う. (そんな人いるんでしょうか..w) 試験のシラバスが項目単位で並んでいる. この項目を自分の言葉で説明できることが当面のゴール. 言葉で説明する深さについては,暗記が不要という難易度調整が入っておりそれほど深くなくてよいと思う. 結果として「ロジックを自分の言葉で説明できること」がゴールになり得る. 個人的な感想を書くと,もはやかなり覚えてしまっている気はする. 当面は「学びの軌跡」。合格したときに「合格体験記」としてまとめなおす. この投稿を入り口として各詳細を別記事として書いていく予定. 1セクションを1記事として扱い合計4から5記事で詳細を完結する予定. 当面は合格体験記ではなく勉強の記録なので、資格試験合格のために ここに流入してしまった人は抜けて他読んだ方が学びになると思います. TableauDesktop TableauServerはTableauDesktopで作ったワークブック等をサーバ上で共有する仕組みであることから, 多くの記述においてTableauDesktopの知識が前提となる.TableauDesktopで一通り何ができるかを学んだ方が良い.ポチポチで全てやれちゃう範囲と深さがあればTableauServerの理解には不足ないと思う. 試験の概要 Server Certified Associate試験の概要は以下の通り。 合格基準が75%。ベンダー資格としてはこんなものか、若干高いかも。 択一だけでなく多肢選択も含まれるので、結構落とせない。 問題数80問に対して90分。問題多い。合格体験記を見る限り時間が不足しがちな試験。 試験範囲に以下みたいな記述がある。難易度の調整パラメータかな。 組織は、タスクを効果的かつ効率的に遂行することを、当然のように従業員に期待するようになりました。Tableau は、時間が成功に欠かせないコンピテンシーであると考えており、そのためこの試験にも時間制限が設けられています。 Tableau ServerはLinux,WindowsServerいずれのインストールも対応しているが試験はWindows。 個人的にはLinuxが良いのだけど仕方がない。OS違うのに試験同じにできるのかね..。 オンラインヘルプが参照可能。だが時間無いので記憶の照合くらいにしか使えなさそう。 どこに書いてあるかを記憶しておくことが必要。 Tableu資格の特徴は, 試験開始までの準備でリモート先の試験官と英会話が必要なこと。 提供言語として日本語が用意されているが,これは問題が日本語であるということ. 試験時間: 90 分 合格基準: 正答率 75% 問題数: 80 得点: 自動採点 設問形式: 択一、複数回答、正誤 提供言語: 英語、日本語、中国語 (簡体字)、ドイツ語、フランス語、ポルトガル語 (ブラジル)、スペイン語 (インターナショナル) プラットフォーム: Tableau Server がインストールされた Windows 仮想マシン オンラインヘルプ: 参照可能 Readingはそこそこ問題ないのでこっちは良いのだけど,試験官とSpeaking/Listeningとか不安。 試験本体までのやりとりは以下のような感じらしい。むー。 試験官にweb電話をかける ガイダンスが始まる web通話環境に問題ないことの確認が入る 本人確認：受ける試験が正しいか、パスポートをwebカメラに見せて欲しい,etc 環境確認：PCは充電器に接続されているか、部屋に一人でいるか、机の上を見せて欲しい、途中退出はダメ,etc リモートで指定されたPC環境にログインされ試験開始 なんとか試験本体までたどりつかないと。 ここから先は普通のベンダー試験。 試験範囲 記事執筆時点の試験範囲は以下。 評価するスキル 準備セクション。全体の20%。把握するためにペタペタ貼っていく。 ところどころ,当製品と関係ない一般的な知識が書かれているな..。 ユーザーエクスペリエンス - ユーザーインターフェイス - ナビゲーション トポロジ - クライアントコンポーネントを特定する - サーバーコンポーネントを特定する - 連動する仕組みを説明する バージョン - 以下を理解する: - Tableau Server の現行バージョンを特定する方法 - Tableau Server の最新リリースをどこで入手できるか - Tableau Server のリリースノートをどこで参照できるか ハードウェア最小要件 - 以下を理解する: - RAM 要件 - CPU 要件 - ハードディスク要件 ソフトウェア要件 - サポートされるオペレーティングシステムを列挙する - 以下を理解する: - ブラウザ要件 - メールアラートのオプション - ウィルス対策の懸念事項 - SMTP サーバーを特定する - 起こりうるポートの問題を知る - 専用サーバーの目的と利点を説明する - クラウドで稼働させる際の検討事項を特定する ライセンス発行 - ユーザーベースライセンスを理解する - 異なるライセンスタイプを説明する - ライセンスタイプがどのようにサイトロールにマップするか説明する サーバープロセス - Tableau サービスマネージャーとTableau Serverプロセスをそれぞれ説明する - 以下を理解する: - インストール直後の既定のプロセス数 - 複数インスタンスのプロセス - プロセス間のワークフロー - 分散環境と高可用性環境におけるプロセス - ロードバランサーの目的 データソースの特定 - 必要なポートを特定する - 必要なデータベースドライバーを特定する - 以下の相違点を理解する: - ファイル、リレーショナル、キューブ - 抽出とライブ接続 - パブリッシュされたデータソースの利点を説明する インフラストラクチャネットワーク - ネットワークレイテンシーの意味を理解する - 動的 IP アドレスのリスクを説明する インストールと構成というセクション。全体の25%。 ActiveDirectoryというワードだけで不安になる。 Linux構成が選べるけどWindowsServerを選んだ方が良い気がしてきた。 内容的には妥当な感じ。 インストール - インストールの手順とオプションを理解する: - インストールパス - ゲートウェイポート - アイデンティティストアと SSO のオプションを理解する: - 外部 (Active Directory) とローカル - 信頼できるチケット - SAML - Kerberos と OpenID Connect - 自動ログインオプションの影響を説明する - SSL の設定方法を理解する - 単一マシン環境のインストールに関する Tableau のベストプラクティスを理解する - サイレントインストールを理解する Tableau Server の構成 - キャッシュ設定を理解する - 以下の方法を理解する: - プロセス分散の適用 - メールアラート/サブスクリプションの設定 - オプションで行えるカスタマイズの設定 - 以下を説明する: - サイト構成オプション - ユーザー数 - ストレージ容量 - サイトサブスクリプションの有効化および編集の方法 - プロジェクト構成オプション - グループとユーザーの構成オプション - 誰がユーザーを追加できるかを理解する ユーザーの追加 - ライセンスタイプとサイトロール - 管理者レベル - パブリッシャーレベル - Active Directory またはローカルを介したインポート セキュリティ - 以下のセキュリティ構成を説明する: - サイトレベル - プロジェクトレベル - グループレベル - ユーザーレベル - データソースレベル - ワークブックレベル パーミッション - 以下を理解する: - システムパーミッションの構成 - パーミッション設計の細部 - Tableau のセキュリティモデル - 許可、拒否、なしの違いを説明する 管理というセクション。全体の36%。 たぶんここが本丸だろう。 以下の方法を理解する: - データ接続を維持する - スケジュールを作成する - サブスクリプションを作成、編集、削除する - サーバー分析を実行する - バックアップと復元を完了する - クリーンアップを実行する - ユーザーを追加、削除、非アクティブ化する - ライセンスを更新する - 起動、停止、再起動する - tsm と tabcmd を使用する - REST API を使用する - ログファイルを処理する - 埋め込みを理解する - Desktop ライセンスの使用状況を監視する - ワークブックとデータソースのリビジョン履歴を管理する 以下の方法を説明する: - 複数の方法でサーバーのステータスを確認する - メールアラートを確認する - データドリブンアラートを設定する - 組み込まれた管理ビューを利用する - カスタム管理ビューを作成する - パフォーマンスの記録を作成する - ネストされたプロジェクトを作成する - サイトおよびサイト管理者のオプションを扱う エンドユーザーとシステム管理者の機能の比較 エンドユーザー機能 以下を理解する: - 表の推奨 - ビューとデータソースをパブリッシュする - ワークブックの名前を変更する - Web でビューを操作する - Web 作成と編集 - ビューの共有方法 - データソースの認証 - 抽出のキャッシング トラブルシューティングというセクション。全体の13%。 ブラウザでのサードパーティ Cookie の要件を理解する 以下の方法を理解する: - Tableau ユーザーまたは Tableau 実行サービスアカウントのパスワードをリセットする - レポーティング用のログファイルをパッケージ化する - tsm を使用してサイトのリソースを検証する - 検索インデックスを再構築する - メンテナンス分析レポートを使用する - サポートリクエストを作成する/開く 移行とアップグレードというセクション。全体の6%。 - アップグレードプロセスを理解する - クリーン再インストールを実行する方法と理由を説明する - 異なるハードウェアに移行する方法を説明する - 後方互換性を理解する おわり 正直どんな風に聞かれるのかがわからないことが一番やっかい. オンラインヘルプを参照可能なので暗記する必要はないのだが, 時間を考慮すると覚えておいてオンラインヘルプで確認するというフローが現実的ではないか. 上から順に流していくと気づくことがある. 実際にインストール,セットアップしようとすると知らなければいけないことが並んでいる. 使わないけど知識として並べてある、という他資格とは印象が違う. あまり潰しが効く技術ではないので,良くも悪くも使い方のガイドとして使うべきだろうと思う.

docker on vagrant Docker for Macが遅いので,Webのコード書くのはvagrant+ansibleで済ませていたのだけれども, vagrant上にdockerを立てることでLinux上で走らせるのと同レベルの速度を得られるようなので, docker on vagrantを立ててdockerに入門してみる。 Web開発していない人から見ると,なんでdocker使わないの? ってことなのだが, 気持ちは以下の通り. 工夫無しだと1度試したら2度とやりたくないレベルで使い物にならない. Docker For Macが遅い：対策の実験 Macのdockerが遅いストレスから解放されよう ansibleで自動化してたから手間に気づかなかったけど, 公式がイメージ配ってるんだから,手間なしなのはdocker. 本番環境と開発環境を揃えにくいかなとも思うけど, AWS ECS的なものもあって,そもそもdockerだけで完結する世界が主流になりそうな感. docker on vagrantで遅さを回避できるので, 言い訳してないでアップデートしていく.. なぜ遅いのか Docker for Macは, AlpineLinuxベースのHyperkitVMの上で透過的にContainerを扱う. Mac上でDockerコマンドを実行すると,透過的にHyperkitVM上に反映される. Macの上で直接Containerが動いているのではなくこのVMの上でContainerを動かしている. HostとGuestのファイルシステムをマウントする観点ではvagrantも同じで, 実際,VagrantfileでマウントオプションとしてNFSを指定したとしてもNativeよりかなり遅い. ファイルシステムの対称性がある分,vagrantはHostとGuestをSyncする方法に手を入れやすく, HostとGuestのファイルシステムをNativeと同等レベルの速度でSyncする手段を導入できる. この仕組みによると, vagrantの上でDockerを動かすパフォーマンスがNative並に速くなる. Mutagen HostとGuestのファイルシステムをSyncするためにMutagenを利用する. Overviewによると,Mutagenは双方向の同期ツールで,低レイテンシをうたっている. もともとHostToGuestというよりはLocalToCloudの統合を目指している感じ. キーボードを打ってから反映されるまでのラグが気になる, とかOSが違う場合のアレコレ(permissionとかシンボリックリンックとか),とか, そういうところの解消を目指している様子. エージェントレス,TCP,でリモートへの導入コストが少ないのが良い. VagrantにはMutagen over SSHの形を取る. インストール手順 こちらが参考になりました。わかりやすく,手順通りやれば10分かかりません. Vagrantを使う「Mac最速のDocker環境」を初心者向けに解説【遅いMac for Dockerを卒業】 とりあえず箱だけ作った.Laravelだと分かりづらいのでRailsで試したところ激しく速かった. 副次的な効果として、Macを汚さないのでお砂場にぴったり.

やりたいことは以下の2つ。 ansibleでaws-cliをインストールする ansibleでインストールしたaws-cliでs3コマンドを打てるようにする なお、相手には既にpipがインストールがしてあるものとします。 ansibleを実行するために最小構成でPythonをインストールしたもののpipは入れていない、 という状況であれば、先にpipをインストールする必要があります。 リージョン、S3のkey,secretは仮に以下とします。 事前にAWSのコンソールで設定,取得してください。 region: ap-northeast-1 s3.key: AHJKOKODAJOIFAJDJDIOA s3.secret: AugioaiARJOIfjop20FJIOADOiFJAODA ファイル達 構成は以下の通りです。(※)のファイルが核心です。 stagingとかになってますが、もちろん成立する範囲で修正してください。 ├──provision.yml (※) ├──ansible.cfg ├──group_vars │ └───staging.yml (※) ├──hosts | └───staging ├──host_vars | └───default.yml └──roles └─awscli (※) ├─templates | └─config.conf.j2 | └─credentials.conf.j2 └─tasks └─main.yml group_vars/staging.ymlに設定を書きます。 user: ubuntu s3: region: ap-northeast-1 # S3.region key: AHJKOKODAJOIFAJDJDIOA # S3.key secret: AugioaiARJOIfjop20FJIOADOiFJAODA # S3.secret roles/awscli/templates/config.conf.j2にaws-cliの設定を書きます。 s3.regionが評価され値が入ります。相手の~/.aws/configに配置します。 [default] output = json region = {{s3.region}} roles/awscli/templates/credentials.conf.j2にs３の設定を書きます。 s3.keyとs3.secretが評価され値が入ります。相手の~/.aws/credentialsに配置します。 [default] aws_access_key_id = {{s3.key}} aws_secret_access_key = {{s3.secret}} rokes/awscli/tasks/main.ymlに状態を定義します。 内容は以下の通りです。 1)　aws-cliがpip installされた状態 2) ~/.aws/以下に設定ファイルがコピーされた状態 --- - name: install aws-cli pip: name: awscli - name: create .aws dir file: dest: /home/{{user}}/.aws state: directory owner: \"{{user}}\" group: \"{{user}}\" - name: copy config template: src: config.conf.j2 dest: /home/{{user}}/.aws/config owner: \"{{user}}\" group: \"{{user}}\" - name: copy credential template: src: credential.conf.j2 dest: /home/{{user}}/.aws/credentials owner: \"{{user}}\" group: \"{{user}}\" ~ ~ Playbook(provision.yml)は以下の通りです。 - hosts: remote_machine remote_user: \"{{ user }}\" gather_facts: \"{{ check_env | default(True) }}\" become: yes become_method: sudo roles: - { role: awscli } 実行結果 Playbookを実行します。 $ ansible-playbook -i hosts/staging provisiong.yml 相手のユーザディレクトリに.awsというディレクトリが作られ、中にファイルが作られます。 ~/ └─.aws ├─config └─credentials 相手側でaws s3 lsコマンドを打って設定しろと言われなければ成功です。 $ aws s3 ls 2019-10-20 11:11:20 hogehoge おわり。

vagrantを知っていてこれからdockerに入門する方向のチートシートを書く。 dockerコンテナの方が小さいので基本的に粒度が合わないが、 対称性を重視して似た機能を並べてみた。 コマンド一覧(vagrant list-commands)からメジャーなのをピックアップした。 Dockerコンテナのネットワーク設定等、概念違いで比較しづらいものは除いた。 また、各コマンドにはパラメタが必要だが煩雑になるため省略した。 vagrant box / docker image操作 vagrant docker boxの一覧vagrant up imageの一覧docker images boxの追加vagrant box add */*imageの追加docker pull imageの詳細docker inspect * boxの削除vagrant box remove *imageの削除docker rmi * boxの更新vagrant box update */*imageの更新docker pull * 全boxの更新vagrant box update imageからbox初期化vagrant init * imageのタグ設定docker tag * vagrant 仮想マシン操作/コンテナ生成/起動/停止 vagrant docker 仮想マシン起動vagrant upコンテナ生成/起動docker run コンテナバックグラウンド実行docker run -d コンテナ起動docker start 仮想マシン終了vagrant haltコンテナ停止docker stop 仮想マシン再起動vagrant reloadコンテナ再起動docker restart 仮想マシン一時停止vagrant pauseコンテナ中断docker pause 仮想マシン再開vagrant resumeコンテナ再開docker unpause 仮想マシン削除vagrant destroyコンテナ削除docker rm 仮想マシンステータス表示vagrant status 全マシン一覧vagrant global-status稼働コンテナ一覧docker ps -a 仮想マシンログインvagrant ssh スナップショット(vagrantのみ) vagrant スナップショット作成vagrant snapshot save * スナップショット復元vagrant snapshot restore * スナップショット削除vagrant snapshot delete * スナップショット一覧vagrant snapshot list dockerコンテナはホストと共有する範囲が大きく、全環境で完全に同じように動かすことは 難しいかもしれない。 vagrantとdockerは排他的な存在ではなく、vagrant上にdockerコンテナっていう構成もありえる。 Vagrantfile, Dockerfile関連は次回...

稼働中のEC2を落とさないでALB下で切り替えた作業記録を書いてみます。 こちら↓の方が詳しく書いてあります..。今回書いた記事の特徴は以下となります。 AutoScalingグループを使わない ALBの下で切り替える deploy手順をAWSの外に用意する [clink implicit=\"false\" url=\"https://qiita.com/keitakn/items/6abe6c971e4dec3b69ef\" imgurl=\"https://camo.qiitausercontent.com/08bed869c98443e0474ce8ce78bdbe964a09f1e9/68747470733a2f2f71696974612d696d6167652d73746f72652e73332e616d617a6f6e6177732e636f6d2f302f37313839392f62303437313164612d623035362d313262662d646164612d3439653930333231663366342e6a706567\" title=\"AWS CodeDeploy でEC2のBlue/Greenデプロイを作成する\" excerpt=\"AWS CodeDeploy を使ってBlue/Green デプロイの仕組みを構築する為の手順を紹介します。Blue/Greenデプロイとは？現在稼働している環境と別にもう1つ稼働環境を作成し、ロードバランサー等のルーティングを新環境に向けるデプロイ方法です。常にリクエストを受けている稼働中のサーバを置き換えるよりも安全にデプロイ可能なのがメリットになります。\"] [arst_adsense slotnumber=\"1\"] 現状と動機 WPCoreアプデとセキュリティパッチはマメに当てないといけないと痛感して、 仕方なくBlue Green的な方法を導入してみた。 ALBの下にWebサーバ1台。Webサーバの下にDB用EC2が1台(非RDS)。 アップデート対象はWebサーバのみ。 Webサーバ内でWordPressが12個、SNIで動いてる。 x.smallクラス。CloudWatchを見るとLoadAverageは常時30%くらい。 全てのサイトで、pluginでファイルとDBをS3にバックアップしている。 localで開発/WPCore,plugin update/動作確認後、止めずにansibleでdeploy。 deploy実行前に\"メンテナンス中\"に設定。deploy完了後に解除する。 アップデート中は管理画面操作禁止を通達。 deploy、パッチ当てでコケると、S3から戻すまで止まる! S3から戻らないと終わる。 やったこと deploy、アップデート時にのみ、WebサーバのEC2をコピーする。 ALBのターゲットグループにコピーしたEC2を追加する。 元のEC2に対してansibleでdeployする。 元のEC2に対してパッチアップデートする。 ALBの先を元のEC2に戻す。 コピーしたEC2を削除する。 メディアライブラリにファイルをアップロードすると差分が発生するため、 元EC2と一時EC2のファイル達を同期させないといけないけれど、 メンテ中は、管理画面操作を禁止できるという状況であることと、 もともとEC2が1台なのでその仕組みを作っていないから、それは2台以上に増えたときに..。 AMI作成 まずAMIを作成。AMIとはAmazon Machine Imageの頭文字。 [clink implicit=\"false\" url=\"https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instances-and-amis.html\" imgurl=\"https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/images/architecture_ami_instance.png\" title=\"インスタンスと AMI\" excerpt=\"Amazon マシンイメージ (AMI) は、ソフトウェア構成 (オペレーティングシステム、アプリケーションサーバー、アプリケーションなど) を記録したテンプレートです。AMI から、クラウドで仮想サーバーとして実行される AMI のコピーであるインスタンスを起動します。以下の図に示すように、1 つの AMI の複数のインスタンスを起動することができます。\"] 手順は以下。 ダッシュボードからコピーしたいインスタンスを選択 アクション->イメージ->イメージの作成を選択 デフォルトだと、AMI作成時にコピー元インスタンスが自動的に停止し、コピー後に自動的に再起動する。 \"再起動しない\"にチェックをいれることで、コピー元インスタンスの停止/再起動を抑止できる。 \"再起動しない\"にチェックをいれないでAMIを作成すると、コピー元が止まってしまうので注意! イメージの作成を押下すると、作成処理が始まる。 EBSが30GiBだと、完了まで1時間程度要してしまった。 ダッシュボード -> AMI から AMIの作成状況を確認できる。 ステータスが available になれば完了。 インスタンスの起動 作成済みAMIからインスタンスを起動する。 ダッシュボード -> AMI を開く 起動したいAMIを選択する アクション -> 起動を押下 すると、インスタンスタイプを聞かれる。 進捗状況はEC2ダッシュボードで確認できる。 ALBのターゲットグループ変更 既にALBのターゲットグループに元EC2が属していて、 セキュリティグループが正しく設定済みで、ヘルスチェックが通っている前提。 現状、ALBの下は元EC2だけなので、AvailabilityZoneは1種類だけ。 ダッシュボード -> ターゲットグループ そこに、新しく作成したインスタンスを追加する。 新しいインスタンスのセキュリティグループを旧インスタンスに合わせて ALBからのInboundを受けられるようにすること。 新しいインスタンスのヘルスチェックが無事通って2台構成になった図。 元のEC2をターゲットグループから削除 元のEC2をターゲットグループから削除する。 EC2ダッシュボードのモニタリングタブをみて、CPU使用率などに変動があることを確認する。 元のEC2に対してゴニョゴニョする ALBのターゲットグループから外れた元のEC2に対してdeployなりパッチ当てを実行する。 元のEC2にElasticIPを当てておけば、再起動してもIPアドレスは変わらない。 この手順においては、新規作成したEC2にElasticIPを当てる必要はない。 元のEC2のセキュリティグループを0.0.0.0/0:80からアクセスできるようにして、 hostsにElasticIPを書いてアクセスするなどの方法で、元のEC2にアクセスする。 このためだけにALBを作って置いておくとそのALBに対して課金されてしまう。 新規作成したEC2を無料枠でやったりしてスペックが低いとパフォーマンスが下がる。 非稼働のEC2に当てたElasticIPで課金される。 一時EC2をターゲットグループから外し、元のEC2を投入する 上の手順を逆から実施。つまり、一時EC2をターゲットグループから外し、元のEC2を投入する。 [arst_adsense slotnumber=\"1\"]

HTTPSを強制するために .htaccess に細工をするのは有名。例えば以下のような書き方が王道。 RewriteEngine on RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L] これをそのままElasticBeanstalkにデプロイするとリダイレクトループが発生する。正確に書くとリバースプロキシ（ロードバランサ）が有効になっている場合にリダイレクトループが発生する。 原因 原因についてはココが詳しい。ざっくりまとめると、 ロードバランサが443へのアクセスを80へのアクセスに変換する .htaccess内の RewriteCond ${HTTPS} が永遠に on にならず、リダイレクトの度にRewriteRule が走ってしまう 元々のアクセスが https か http のどちらかが分かれば良いのだが、上記の挙動のせいで、https にリダイレクトしたとしても http からアクセスされたことになり、これが永遠に繰り返されてしまう。 解決策 （記事主さんが）無茶苦茶泥臭く挙動を追跡したところ、ロードバランサに到着した元のアクセスが http のときに限り、X-Forwarded-Proto というヘッダが付与され値が入るらしい。なので、X-Forwarded-Protoヘッダの内容を http か https かの判断基準にすれば良い、というのが基本的なアイデア。本人も言っているが、it\'s just an empiric result... である。 その .htaccess が以下 RewriteEngine On # Force HTTPS RewriteCond %{HTTP:X-Forwarded-Proto} !=https RewriteRule ^/?(.*) https://%{HTTP_HOST}/$1 [R,L] これを ElasticBeanstalkにデプロイすると見事に動作する。 [arst_adsense slotnumber=\"1\"] 開発環境との共存 開発もAWSで行っていればこれで良いのだがそうでない場合も多いと思う。 上記のAWS用.htaccessを非AWSな開発環境に持ってくると今度は RewriteCond %{HTTP:X-Forwarded-Proto} !https が常に真になり、リダイレクトループが発生する。 あっちが立てばこっちが立たない！ いろいろ試行錯誤した結果、以下なら両立できた。(2017/7/8訂正) RewriteEngine On # Force HTTPS RewriteCond %{HTTPS} !=on RewriteCond %{HTTP:X-Forwarded-Proto} !=https RewriteRule ^/?(.*) https://%{HTTP_HOST}/$1 [R,L] 根拠となる X-Forwarded-Proto がとっても経験的！なので、いつの日か使えなくなる日が来るかもしれない。 [arst_adsense slotnumber=\"1\"]

Certbotを使って Conoha+Kusanagi(nginx/centos7) に無料でSSL/TLC証明書をインストール・自動更新する方法は過去に書いた。\"無料でSSL/TLC証明書を手に入れる\" CertbotサイトにOSとWebサーバの組み合わせを入力すると対応するインストール手順が表示される。メジャーな組み合わせであれば証明書の取得から自動更新まで全自動でやってくれる。 2016年7月現在、AWS(EC2)は未対応のため、Certbotツールを使って試行錯誤する必要がある。Certbotの一次情報をもとに何とかやってみたので記録を残しておく。 AWS(EC2)にCertbotでSSL/TLC証明書をインストールする ElasticBeanstalkのロードバランサに取得した証明書を登録しhttpsでアクセスできるようにする 自動更新のセットアップを行う AWS(EC2)にCertbotを使ってSSL/TLC証明書をインストールする いくつか前提がある。 ドメインは取得済みであること。 ドメインがElasticBeanstalkのIPアドレスを指すようにRoute53を設定済みであること。 EC2インスタンスにSSHでログインできるようにしておく。 Certbot利用時、外部からEC2インスタンスにhttpでアクセスを受ける。ElasticBeanstalkにRoutingを変更するようなアプリがデプロイされているとアクセスが失敗するのでDocumentRootにindex.phpがあるだけという状態にしておく。 SSL/TLC証明書をインストールするだけなら443番を開けておく必要はない。ロードバランサはデフォルトの80番だけ開けていれば良い EC2インスタンスのrootパスワードが設定済みであること AWS CLIがインストール済みであること。 IAMで証明書登録ポリシーを付与済みであること。 さっそくEC2インスタンスにログイン。基本的にec2-userで作業する。 一応下記を実行。 $ sudo yum install epel-release Loaded plugins: priorities, update-motd, upgrade-helper Package epel-release-6-8.9.amzn1.noarch already installed and latest version Nothing to do Certbotをダウンロードする。 $ wget https://dl.eff.org/certbot-auto $ chmod a+x certbot-auto Certbotを実行してみる。その際、--debugオプションを付けないと怒られる。would like to work on improving it と言っておきながら --debug がmust。きっと実行内容がCertbotに送られるのだろう。 $ ./certbot-auto WARNING: Amazon Linux support is very experimental at present... if you would like to work on improving it, please ensure you have backups and then run this script again with the --debug flag! 指示通り、--debugオプションを付けて実行してみる。 $ ./certbot-auto --debug ... Installed: augeas-libs.x86_64 0:1.0.0-5.7.amzn1 dialog.x86_64 0:1.1-9.20080819.1.5.amzn1 libffi-devel.x86_64 0:3.0.13-11.4.amzn1 python27-tools.x86_64 0:2.7.10-4.120.amzn1 system-rpm-config.noarch 0:9.0.3-42.27.amzn1 Complete! Creating virtual environment... Installing Python packages... Installation succeeded. Requesting root privileges to run certbot... /home/ec2-user/.local/share/letsencrypt/bin/letsencrypt --debug Version: 1.1-20080819 Version: 1.1-20080819 No installers are available on your OS yet; try running \"letsencrypt-auto certonly\" to get a cert you can install manually いろいろインストールされる。/home/ec2-user/.local/share/letsencrypt/ 以下にPython27 が入る。今回の試行錯誤では自力でPythonを上げなかった。たぶん、自力でPythonのバージョンを上げなくてもコレが使われるんじゃないか。 肝心のインストーラはインストールされず、\"letsencrypt-auto certonly\"というコマンドを実行せよ、と出る。が、これはtypo。 No installers are available on your OS yet; try running \"letsencrypt-auto certonly\" to get a cert you can install manually ディレクトリを移動する。 $ cd /home/ec2-user/.local/share/letsencrypt/bin ここにある certbot コマンドを叩く。ドメイン名、メールアドレスを指定する。 sudo ./certbot certonly -d hoge.com --agree-tos -m hoge@hoge.com --debug すると、中途半端にグラフィカルな画面が表示される。簡易Webサーバを起動するか、現在のWebサーバのDocumentRootを教えるか、2択となる。簡易Webサーバだとどうしても上手くいかなかった。Webサーバを上げたまま(ElasticBeanstalkのヘルスチェックがOKの状態)、DocumentRootを指定すると上手くいった。 うまくいくと、以下のようなメッセージが表示される。 IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at /etc/letsencrypt/live/arst.me/fullchain.pem. Your cert will expire on 2016-09-29. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run \"certbot renew\" - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let\'s Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le /etc/letsencrypt/live に証明書が作られている。なお、live には ec2-user でアクセスできない。ここでrootに昇格。 $ su - # cd /etc/letsencrypt/live # ls hoge.com # cd hoge.com # ls cert.pem chain.pem fullchain.pem privkey.pem ElasticBeanstalkのロードバランサに証明書を登録する AWS CLI経由で証明書を登録する。その際、IAMにてポリシーを追加しておく必要がある。過去エントリを参照のこと。成功するとJSONで登録情報が返る。ここでは、HogeCertification という名前で登録を行っている。 $ aws iam upload-server-certificate --server-certificate-name HogeCertification --certificate-body file://cert.pem --private-key file://privkey.pem { \"ServerCertificateMetadata\": { \"ServerCertificateId\": \"ASCAI***********A6F5GI\", \"ServerCertificateName\": \"HogeCertification\", \"Expiration\": \"2016-09-29T01:57:00Z\", \"Path\": \"/\", \"Arn\": \"arn:aws:iam::281631559249:server-certificate/HogeCertification\", \"UploadDate\": \"2016-07-01T03:10:18.440Z\" } } ElasticBeanstalkのロードバランサの設定で、証明書欄から HogeCertification を選べるようになる。選んで 443/HTTPS を通すようにすれば、晴れて https://独自ドメイン/ で ElasticBeanstalk の URL が開く。 証明書の自動更新 更新自体はcertbot renewコマンドで行う。certbot renewコマンドは/var/www/html/.well-known/以下にファイルを置いて外部から開きにくる。困ったことに、CakePHPやLaravelアプリをデプロイしているとフレームワークのルーティング機能により上手くいかない。 以下の戦略で対応する。 certbot renew 時だけ、DocumentRoot を アプリ用からcertbot用に切り替える Laravel等のように DocumentRoot がサブディレクトリにオフセットされている場合に対応する ElasticBeanstalkで自動生成される環境を見ると、/var/www/html が /var/app/current へのシンボリックリンクとなっている。Certbot renew を叩くときだけ、シンボリックリンクを差し替える。 $ cd /var/app $ sudo mkdir -p certbot/project/public $ sudo chown -R webapp:webapp certbot $ cd /var/www $ sudo ln -s -f /var/app/certbot html また、certbot用の.well-knownディレクトリが /var/www/html 直下に作られる仕様になっている。DocumentRootはさらに project/public にオフセットされているため、/var/www/html/project/public/.well-known が /var/www/html/.well-known を指すようにシンボリックリンクを作成する。 $ cd /var/app/certbot/project/public $ sudo ln -s ../../.well-known この状態で certbot renew --dry-run を叩くと無事成功する。 $ pwd /home/ec2-user/.local/share/letsencrypt/bin $ sudo certbot renew --dry-run ** DRY RUN: simulating \'certbot renew\' close to cert expiry ** (The test certificates below have not been saved.) Congratulations, all renewals succeeded. The following certs have been renewed: /etc/letsencrypt/live/ikuty.com/fullchain.pem (success) ** DRY RUN: simulating \'certbot renew\' close to cert expiry ** (The test certificates above have not been saved.) シンボリックリンクの作成は一度だけで良いが、アプリ用とCertbot用のシンボリックリンク張替は都度必要となる。 以下のシェルスクリプトをcronで叩けば良い。 #!/bin/bash cd /var/www sudo unlink html sudo ln -s -f /var/app/certbot html cd ~ pwd sudo ./.local/share/letsencrypt/bin/certbot renew --debug cd /var/www sudo unlink /var/www/html sudo ln -s -f /var/app/current html 不要な更新は実行されないため、1日2回の頻度で実行してよい旨、ドキュメントに記述がある。 Note: if you’re setting up a cron or systemd job, we recommend running it twice per day (it won’t do anything until your certificates are due for renewal or revoked, but running it regularly would give your site a chance of staying online in case a Let’s Encrypt-initiated revocation happened for some reason). Please select a random minute within the hour for your renewal tasks.

今後も何度か同じことを調べそうなので忘備録としてまとめておく。手順をstep by stepで記述するが、それぞれ分量が多いので以下の通り章立てを行ってエントリを分割する。 VPC構築編 VPCの作成 VPC、NetworkACL、SecurityGroupの確認、タグ付け VPCのDNSホスト名を有効にする サブネットの作成、タグ付け インターネットゲートウェイの作成、タグ付け、VPCにアタッチ パブリックサブネット用RoutingTableの作成 パブリックサブネット用RoutingTableにインターネットゲートウェイの関連付け 作成したサブネットをパブリックサブネット用RoutingTableに繋ぎかえる RDS構築編 MySQLの設定変更(DBパラメータグループの作成) DBサブネットグループを作成 RDS用セキュリティグループの作成 RDSインスタンスの作成 エンドポイントの確認、疎通確認 Elastic Beanstalk構築編 環境の構築 .ebextensionsによるカスタマイズ Laravel5アプリデプロイ編(本エントリ) gitリポジトリからclone .envの編集 アプリで使うDBのダンプファイルをRDSにコピー Laravelインストーラの準備 Laravel本体のインストール ビルトインサーバでの疎通確認 Elastic Beanstalkへのデプロイ gitリポジトリからclone 通常 Laravel5 にはデフォルトの .gitignore が作られており、Laravel本体は.gitignoreに登録されている。まず、アプリをcloneし、そのあとでLaravel本体をインストールする。 どこか、Laravel5の要件を満たすところでgitリポジトリからcloneする。 $ pwd /home/ikuty/www/ $ git clone ssh://servername/var/git/project.git project .envの編集 アプリケーションの設定を変更する。/config 内に各種設定ファイルが配置されているが、laravelでは.envを変更することで /config内のenv()関数に展開される仕組みになっている。だから、/config 内の各種ファイルを直接変更する必要はない。/config 内も git の構成管理に含めても良い。 cloneした先でenvを編集する。.env_example をリネームすると楽。 APP_KEY= *** 次項で示すようにキーを生成する DB_HOST : RDS編で設定したRDSエンドポイントを指定する DB_DATABASE, USERNAME, PASSWORD : RDS編で設定した各種設定を指定する APP_ENV=local APP_DEBUG=true APP_KEY=**** APP_URL=http://hoge.com/ DB_CONNECTION=mysql DB_HOST=rds-endpoint DB_PORT=3306 DB_DATABASE=hogedb DB_USERNAME=hoge DB_PASSWORD=fuga CACHE_DRIVER=file SESSION_DRIVER=file QUEUE_DRIVER=sync キーを生成する。以下のコマンドで .env の APP_KEY が差し替わる。 $ php artisan key:generate アプリで使うDBのダンプファイルをRDSにコピー 本来は Migration を使うべきだが...。Migration を利用しないでDBを作ってしまった場合は泥臭くやる...;;まず、ダンプ。 $ mysqldump -u hoge -p appdb > appdb.sql RDS側にDBを作成し権限を付与しておく。 $ mysql -h [rds-endpoint] -u hoge -p $ > CREATE DATABSE appdb; $ > GRANT ALL ON appdb.* to hoge@localhost; $ > FLUSH PRIVILEGES; $ > SHOW DATABSES; $ > ... RDS上のDBにダンプしたsqlを流し込む。 $ mysql -h [rds-endpoint] -u hoge -p -D appdb < appdb.sql Laravelインストーラの準備 composerを利用する。パスを通す。本エントリ作成時の最新は version1.3.3。 $ composer global require \"laravel/installer=~1.1\" $ echo \'export PATH=~/.composer/vendor/laravel/installer:$PATH\' >> ~/.bash_profile $ source .bash_profile $ laravel Laravel Installer version 1.3.3 Laravel本体のインストール composerが準備できたらcomposer installでLaravel本体をインストールする。 $ cd project $ composer install ビルトインサーバでの疎通確認 この状態でビルトインサーバを立ち上げ、疎通確認を行う。 $ cd project php artisan serve --host hoge.com Laravel development server started on http://hoge.com:8000/ Elastic Beanstalkへのデプロイ Elastic Beanstalk構築編にて、環境の準備が出来ているものとする。 eb deploy コマンドにより、カレントディレクトリ以下のファイルをデプロイする。また、.ebextension に DocumentRoot を設定する。カレントディレクトリと DocumentRoot の組み合わせを正しく設定する必要がある。 まず、DocumentRootを設定するため、.ebextensionディレクトリを作成し、設定ファイルを作成する。 $ pwd /home/ikuty/www/ $ mkdir .ebextensions $ cd .ebextensions $ vi 01_documentroot.config 01.documentroot_config は以下の通り。YAMLとして記述する必要がある。空白とタブの扱いがシビアなので、タブが入らないように注意する。ファイルの先頭の\"01\" は、ファイルが解釈される順番を表す。.ebextensions 内に、01,02,... のように設定を複数配置できる。 option_settings: - namespace: aws:elasticbeanstalk:container:php:phpini option_name: document_root value: /project/public DocumentRoot を /project/public と設定した場合に正しい構成になるように、カレントディレクトリを移動し、eb deployを実行する。~/www に移動して、/project 以下をデプロイすれば良い。 $ cd ~/www/ $ eb deploy Creating application version archive \"app-160630_130423\". Uploading: [##################################################] 100% Done... INFO: Environment update is starting. INFO: Deploying new version to instance(s). INFO: New application version was deployed to running EC2 instances. INFO: Environment update completed successfully. 設定が正しければ2分弱で完了する。