11. プロジェクト¶
Project (プロジェクト) は、Tower で表される Ansible Playbook の論理コレクションです。
Playbook および Playbook ディレクトリーをプロジェクトのベースパスに手動で配置するか、Tower がサポートするソースコード管理 (SCM) システム (例: Git、Subversion、Mercurial) に Playbook を配置することで、Playbook と Playbook ディレクトリーを管理できます。
注釈
デフォルトで、プロジェクトのベースパスは /var/lib/awx/projects ですが、Tower 管理者によって変更されている可能性があります。これは /etc/tower/settings.py で設定されます。設定が正しくないとインストールを無効にする可能性があるので、注意してこのファイルを編集してください。
このメニューには、現在利用可能なプロジェクトの一覧が表示されます。プロジェクトの一覧は、ステータス、名前、または タイプ で並び替え、検索できます。一覧表示されている各プロジェクトについて、編集および削除アイコンを使用してプロジェクトのプロパティーを編集したり、プロジェクトを削除したりできます。
ステータス はプロジェクトの状態を示し、以下のいずれかになる可能性があります (特定のステータスタイプでビューをフィルターできることにも留意してください)。
- 新規: ソースコントロールの更新が作成されましたが、キューに入れられていないか、まだ開始されていません (今後非推奨となります)。
- 保留中: ソースコントロールの更新がキューに入れられていますが、まだ実行されていません (今後非推奨となります)。
- 待機中: ソースコントロールの更新が更新/依存関係について待機中です。
- 実行中: ソースコントロールの更新が進行中です。
- 成功: このプロジェクトの最後のソースコントロールの更新が成功しました。
- 失敗: このプロジェクトの最後のソースコントロールの更新が失敗しました。
- エラー: 最後のソースコントロールの更新ジョブの実行に失敗しました (今後非推奨となります)。
- 取り消し: このプロジェクトの最後のソースコントロールの更新が取り消されました。
- 未更新: このプロジェクトはソースコントロール用に設定されていますが、更新されていません。
- OK: プロジェクトはソースコントロール用に設定されていませんが、正常に実施されています (非推奨になる予定)。
- 不明: プロジェクトがプロジェクトベースパスの
/var/lib/awx/projectsにありません (手動またはソースコントロールで管理されたプロジェクトで適用可能です)。
アクション では、以下のアクションを選択できます。
- 更新: このプロジェクトに設定されている場合は、ソースコントロールから即時の更新を起動します。
- スケジュール: このプロジェクトに設定されている場合は、ソースコントロールから更新をスケジュールします。
- 編集: プロジェクトを編集します。
- 削除: プロジェクトを削除します。
注釈
認証情報タイプが「手動」のプロジェクトでは、SCM タイプの認証情報として再設定されない限りソースコントロールベースのアクションを更新したり、スケジュールしたりすることはできません。
11.1. 新規プロジェクトの追加¶
新規プロジェクトを作成するには、以下を実行します。
ボタンをクリックします。これにより、プロジェクトの作成 ダイアログが起動します。
- 以下のフィールドに該当する詳細を入力します。
- 名前
- 説明 (オプション)
- 組織 (プロジェクトには 1 つ以上の組織がなければなりません。ここで 1 つの組織を選択してプロジェクトを作成し、プロジェクトの作成後にさらに組織を追加できます。)
- SCM タイプ (手動、Git、Subversion、または Mercurial のいずれかを選択します)。詳細は、本書の Playbook の手動による管理 および ソースコントロールの使用による Playbook の管理 を参照してください。
注釈
各プロジェクトパスは 1 つのプロジェクトのみに割り当てることができます。以下のメッセージを受信する場合、プロジェクトパスが既存プロジェクトのパスにすでに割り当てられていないことを確認してください。
All of the project paths have been assigned to existing projects, or there are no directories found in the base path.You will need to add a project path before creating a new project.
- 完了したら 保存 をクリックします。
11.2. パーミッションの使用¶
プロジェクト、インベントリー、ジョブテンプレートおよびその他の Tower 要素の読み取り、変更および管理機能を提供する、このプロジェクトに割り当てられるパーミッションのセット (ロールベースのアクセス制御) は権限とも呼ばれています。
この画面には、選択されたユーザーに現在利用できる権限の一覧が表示されます。権限の一覧は、名前、タイプ、または ロール で並べ替え、検索できます。
11.2.1. パーミッションの追加¶
パーミッションを特定ユーザーに追加するには、以下を実行します。
ボタンをクリックすると、「パーミッションの追加」ウィザードが開きます。
- アクセス権を持ち、特定のロールを割り当てるユーザーまたはチームを指定します。
- クリックして、ユーザーまたはチームの名前の横にある 1 つまたは複数のチェックボックスを選択してこれらを選択します。
ダイアログが拡張し、選択する各リソースのロールを選択できます。
- 提供されるドロップダウンメニューの一覧からロールを選択します。
- 管理者 は権限の読み取り、実行および編集を許可します。
- 使用 は、ジョブテンプレートでのプロジェクトの使用を許可します。
- 更新 は、SCM 更新からのプロジェクトの更新を許可します。
注釈
チームとユーザー間を切り換える必要はありません。複数のロールを複数のユーザーまたはチームの両方に一度に割り当てることができるため、
ちなみに
キー ボタンを使用して、選択したリソースに適用されるそれぞれのロールのヘルプテキストを表示します。
「パーミッションの追加」ウィザードの拡張されたセクション 2 のボタンをクリックし、それぞれの Tower オブジェクトのロールの割り当てを確認します。
終了したら 保存 をクリックします。「パーミッションの追加」ウィザードが閉じ、選択された各リソースのロールが割り当てられ状態でユーザーおよびチームの更新プロファイルが表示されます。
特定リソースのパーミッションを削除するには、そのリソースの横にある「関連付けの解除 (x)」ボタンをクリックします。
これにより確認ダイアログが起動し、関連付けの解除の確認が求められます。
ボタンをクリックして通知を作成します。
11.4. Playbook の手動による管理¶
- Playbook を保管する 1 つ以上のディレクトリーをプロジェクトのベースパス (例: /var/lib/awx/projects/) に作成します。
- Playbook ファイルを作成し、これを Playbook ディレクトリーにコピーします。
- Playbook ディレクトリーおよびファイルが、Tower サービスを実行するのと同じ UNIX ユーザーおよびグループで所有されていることを確認します。
- パーミッションが Playbook ディレクトリーおよびファイルについて適切であることを確認します。
プロジェクトパスを追加する際に問題がある場合は、プロジェクトディレクトリーおよびファイルのパーミッションおよび SELinux コンテキスト設定を確認します。
警告
Ansible Playbook ディレクトリーをベースプロジェクトパスに追加していない場合、Tower から以下のメッセージが送信されます。
適切な Playbook ディレクトリーを作成し、SCM から Playbook をチェックアウトするか、または Playbook を適切な Playbook ディレクトリーにコピーしてこの問題を修正します。
11.5. ソースコントロールの使用による Playbook の管理¶
- SCM タイプ ドロップダウンメニューの一覧から適切なオプションを選択します。
- 以下のフィールドに該当する詳細を入力します。
- SCM URL: ヘルプ
テキストの例を参照できます。
- SCM ブランチ: オプションで Mercurial の SCM ブランチ、SCM ブランチ、タグまたは Git のリビジョンを入力します。
- リビジョン #: オプションで Subversion のリビジョン # を入力します。
- SCM Credential (SCM 認証情報): 認証が必要な場合、適切な SCM 認証情報を選択します。
- SCM 更新オプション:
- クリーニング: 更新の実行前にローカルの変更を削除します。
- 更新時の削除: 更新の実行前にローカルリポジトリーを完全に削除します。リポジトリーのサイズによっては、更新の完了までにかかる時間が大幅に増大します。
- 起動時の更新: このプロジェクトを使用してジョブを実行する場合には、ジョブの開始前にローカルリポジトリーの更新を実行します。ジョブの生成速度がプロジェクトの同期速度を上回る場合のジョブのオーバーフローを避けるため、これを選択して、特定の期間 (秒単位) 以前のプロジェクトの同期をキャッシュするようキャッシュタイムアウトを設定することができます。
- **保存**をクリックしてプロジェクトを保存します。
ちなみに
Github リンクを使用すると、Playbook を簡単に使用できます。使用を開始するには、
helloworld.ymlファイル (https://github.com/ansible/tower-example.git より利用可能) を使用します。このリンクから、Ansible Tower Quick Start Guide の説明に従って手動で作成されたものに非常に似ている Playbook を追加することができます。これを使用しても、システムが変更されたり、破損することはありません。
11.6. ソースコントールからのプロジェクトの更新¶
ボタンをクリックして、既存の SCM ベースのプロジェクトを更新します。
注釈
ソースコントロールを使用するためにプロジェクト設定を追加した直後に「同期」が開始され、設定されたソースコントロールからプロジェクト詳細の取り込みが実行されることに注意してください。
- ステータス にある丸い点 (左端のプロジェクト名の横) をクリックして、更新されたプロセスについての追加の詳細を確認します。
3. To set a schedule for updating the project from SCM, click the 
button.
This will navigate to the Schedules screen.
この画面には、選択された プロジェクト で現在利用できるスケジュールの一覧が表示されます。スケジュールの一覧は、名前 で並べ替えできます。
スケジュールの一覧には以下が含まれます。
- 名前: スケジュール名をクリックすると、スケジュールの編集 ダイアログが開きます。
- 初回実行日時: このタスクの最初にスケジュールされる実行
- 次回実行日時: このタスクの次回にスケジュールされる実行
- 最終実行日時: タスクに終了日時が設定されている場合、これはタスクの最後にスケジュールされている実行になります。
スケジュール 画面の右上にあるボタンを使用して以下のアクションを実行できます。
- 新規スケジュールの作成
- このビューの更新
- アクティビティーストリームの表示
11.7. 新規スケジュールの追加¶
新規スケジュールを作成するには、以下を実行します。
- ボタンをクリックすると、Add Schedule (スケジュールの追加) ダイアログが開きます。
- 以下のフィールドに該当する詳細を入力します。
- 名前 (必須)
- 開始日 (必須)
- 開始時間 (必須)
- ローカルタイムゾーン: 入力した開始時間はこのタイムゾーンの時間になります。
- UTC Start Time (UTC 開始時間): 開始時間 + ローカルタイムゾーンで計算されます。
- 繰り返しの頻度: 選択する頻度に応じて適切なスケジュールオプションが表示されます。
SCHEDULE DESCRIPTION (スケジュールの説明): 選択したローカルタイムゾーンで設定されたスケジュールとスケジュールされたオカレンスの一覧を確認できます。
ご用心
ジョブは UTC でスケジュールされます。ジョブが 1 日の特定の時間に繰り返し実行される場合には、夏時間 (DST) へ/からの切り替えがあると、ローカルタイムゾーンに合わせてこれらのジョブのスケジュールは移動する場合があります。基本的に、Tower はスケジュールの保存時に UTC に対してローカルタイムゾーンベースの時間を解決します。スケジュールが適切に設定するには、スケジュールを UTC 時間で設定する必要があります。
- 終了したら、保存 をクリックします。
ON/OFF トグルボタンを使用して、アクティブなスケジュールを停止したり、停止したスケジュールをアクティブにしたりできます。
プロジェクトのスケジュール概要画面には、初回、次回および最終実行のスケジュールについても表示されます。
アクション 列では、スケジュールについてのいくつかのアクションを選択できます。
- スケジュールの編集
- スケジュールの削除
11.8. Ansible Galaxy サポート¶
プロジェクト更新の終了時に、Tower は <project-top-level-directory>/roles/requirements.yml の roles ディレクトリーで requirements.yml というファイルを検索します。このファイルが見つかると、以下のコマンドが自動的に実行されます。
ansible-galaxy install -r roles/requirements.yml -p ./roles/ --force
このファイルにより、Galaxy ロールや、独自のプロジェクトと共にチェックアウトできる他のリポジトリー内のロールを参照できます。この Ansible Galaxy サポートの追加により、これを実行するために git サブモジュールを作成する必要はなくなります。
requirements.yml ファイルの構文についての詳細および例については、Ansible ドキュメントの Advanced Control Over Role Requirements を参照してください。