AWXサーバの外からansibleでジョブを実行する

この記事は MicroAd Advent Calendar 202120日目 と Ansible Advent Calendar 2021 - Adventarの 7日目の記事です(空いててもったいないので埋めました)。

qiita.com

adventar.org

はじめに

以下の記事の補足になります。

yassan.hatenablog.jp
yassan.hatenablog.jp

PRをベースとしたダッシュボード運用をしていると任意のタイミングでリポジトリの状態とダッシュボードを同期したい場合が出てきます。

例えば以下。

  • CIジョブが失敗して再実行したい
  • 本番ダッシュボードを削除・壊して復元できない

上記などの状況からどうしても同期取りたい場合が出てきます。
その場合、空コミットを追加しPR作成することで同期できますが、コミットログも汚れてしまいます。

また、ローカルからansible-playbookコマンドを実行する場合、Vault変数を復号するために復号用パスワードが必要になります。
その場合、Grafana運用者以外のユーザにも復号用パスワードを公開することになり具合が悪いです。さらに、ローカルから実行してしまうと「いつ・誰が・何を」と言った大事な実行履歴も残らないので困りものです。

そこで、AWXのジョブテンプレートを用意して、ユーザ及びCIサーバからの実行をAWX経由で実行するようにしてみます。

環境

前提となる環境は以下の通りです。

  • ansible-core v2.11(v2.9でも動きます)
  • AWX v13.0.0 (多分、v13以降でも大丈夫)
  • Jenkins(CircleCIやGitHub ActionsでもOK)

概要

今回は以下のAnsible Collectionの awx.awxを使います。

galaxy.ansible.com

こちらを利用することで、CIサーバからAWXのジョブを実行出来るようになります。 また、AWXにジョブを作成する事でAWXのWebUIからユーザーが任意のタイミングで実行も可能になります。

前準備

AWXのCollectionを利用できるようにするためのセットアップを行います。

まず、 collections/requirements.yml に以下のようにして追加。

---
collections:
  - name: awx.awx
    version: "13.0.0" # 利用しているAWXに合わせて指定

上記のversionは、 galaxyの awxのページInstall Version にあるドロップダウンリストのVersionを指定してください。 また、指定するVersionは、利用しているAWXのVersionに合わせて近いものを使うのが良いです(互換性の問題を回避する目的で)。

collections/requirements.yml に定義するのは、AWXがデフォルトで参照するCollectionのパスとなっています1

また、ローカルで実行したい場合は以下のコマンドでinstall出来ます2

# ansible-core v2.11以降
ansible-galaxy collection install -r collections/requirements.yml

Playbookの作成

awx_launch_job.yml を以下の様に作成します。

---
- hosts: "{{ grafana_group }}"
  gather_facts: false
  connection: local

  tasks:
    - name: ジョブの起動
      awx.awx.tower_job_launch:  # v19の場合は tower_job_launch→job_launch
        tower_host: "{{ awx_host }}"
        tower_username: "{{ awx_user }}"
        tower_oauthtoken: "{{ vault_awx.awx_oauth_token }}"
        name: "{{ job_name }}"
        extra_vars:
          revision: "{{ revision }}"
          grafana_group: "{{ grafana_group }}"
      register: job

    - name: "Wait for job max {{ job_timeout }}s"
      awx.awx.tower_job_wait:  # v19の場合は tower_job_wait→job_wait
        tower_host: "{{ awx_host }}"
        tower_username: "{{ awx_user }}"
        tower_oauthtoken: "{{ vault_awx.awx_oauth_token }}"
        job_id: "{{ job.id }}"
        timeout: "{{ job_timeout }}"

モジュール awx.awx.tower_job_launch を使うことでAWXのジョブを実行出来ます3

また、 awx.awx.tower_job_wait を使って待っているのは、CIジョブを以下の順番で実行するので、各ジョブが終わるのを待ち合わせするために設定しています4

  1. import-datasources
  2. import-notification-channels
  3. import-dashboards

どちらのモジュールでも利用している tower_oauthtoken に指定する値は、事前にVaultの暗号化変数として{{ vault_awx.awx_oauth_token }}に格納します5

また、実行する際は、Makefileに以下を定義して実行を簡略化します。

SHELL=/bin/bash
REVISION := $(shell git rev-parse --short HEAD)

# Grafanaにダッシュボードを反映する
# AWX job: grafana-import-dashboard を実行する
# 例: make import-dashboards group=prod
.PHONY: import-dashboards
import-dashboards:
    ansible-playbook -i inventories/inventory \
        --vault-id .vault_password \
        awx_launch_job.yml \
            --extra-vars role_name=import_dashboard \
            --extra-vars job_name=grafana-import-dashboard \
            --extra-vars grafana_group=$(group) \
            --extra-vars revision=$(REVISION) \
            --extra-vars job_timeout=600;

※他にも role_namejob_name を変更して他のロール分(import-datasourcesimport-notification-channels)も定義します。

AWX側の設定

以下のようにしてAWXからジョブテンプレートを作成します。
また以下は import_dashboard の分ですが、別途、他のロール分(import-datasourcesimport-notification-channels)も作成します。

f:id:yassan0627:20211220161327p:plain
ジョブテンプレートの設定例

注意点としては、上図の右下隅にある「起動プロンプト」にチェックを入れないと実行出来ないので忘れずにチェックしてください。 また、手動で実行したい場合は、追加変数に grafana_grouprevision を追加して実行してやればOK。

CI側のフローの設定

特に前回から変更は無いです。Makefileダッシュボードやデータソース、通知チャンネルのimportを実行するMakeターゲットをAWXジョブからの実行に変更しているので特にここでは変更点がありません。

詳細は前回の記事を参照して下さい。

yassan.hatenablog.jp

最後に

これでPRを使わずに実行履歴を残しつつダッシュボードの更新が出来るようになりました。
とは言え、PRベースに更新出来ないのでレビューが出来ず、また、更新意図を残せないのであくまで緊急事態用というところです。

全体を通した今後の改善点

現状、Grafanaのダッシュボード・データソース・通知チャンネルを毎回すべて更新してしまいます。 理想的には更新を検知して、更新ファイルだけ反映するような対応があるとより早く同期できたりします。 ただ、git diffで更新差分を使うアイディアもあるのですが差分をキレイに出すのが難しいです6

他にも、今回の仕組みではダッシュボードを削除する仕組みが無いので、リポジトリから削除して後、GrafanaのWebUIから手動で削除する必要があるので若干面倒です。

改善ポイントについて良案があれば是非教えて下さい!


  1. 詳細は 14. Projects — Ansible Tower User Guide v3.8.5 を参照。
    また、 GitHubのAWXのdoc にも説明があるので参考になります。

  2. ansible-core v2.11未満の場合は、 install オプションに -f がないと2回目以降でエラーになります。
    ただし、 ansible/ansible#65699 にて検討されて、ansible/ansible#73336で、v2.11より -u オプションが追加されています。

  3. パラメータの詳細は awx.awx.job_wait を参照下さい。

  4. パラメータの詳細は awx.awx.job_launch を参照下さい。

  5. この辺の説明は前回の記事を参照して下さい。
    yassan.hatenablog.jp

  6. mainブランチとの差分を使うと後から作成したPRを先にマージすると差分を取れなくなる問題があります(rebaseしたら治りますけど)。

CIOpsでGrafanaダッシュボードを運用していく~ansible実装編~

この記事は Ansible Advent Calendar 2021 の6日目の記事です。

adventar.org

はじめに

以下の続きとなります。

yassan.hatenablog.jp

以下で紹介するロールをどう使うか、メリットなどは前回の記事を参照ください。

Grafanaダッシュボードを更新する際に利用するAnsibleモジュールの紹介

Grafana向けにCommunity.Grafanaという Ansible Collectionがあるのでこちらを利用します1

docs.ansible.com

今回作成するロールについて

今回は以下の名前でロールを4つ作成します。

  • import_datasource (データソースをGrafanaに反映する)
  • import_notification_channel (通知チャンネルをGrafanaに反映する)
  • export_resources (Grafanaからダッシュボードを取得する)
  • import_dashboardダッシュボードをGrafanaに反映する)

また、ダッシュボードを更新する際は処理の順番に注意が必要です。
先にダッシュボードで必要となるデータソースや通知チャンネルを更新する必要があるので実行順序に注意が必要です。

また、ロールの全てについては紹介しません。今回はtaskの実行部分の紹介のみとし、moleculeのシナリオなどは省略します。

import_datasource(データソースをGrafanaに反映する)

データソースは community.grafana.grafana_datasource を利用して追加・更新します。

グループ変数の設定

Grafana毎に必要なデータソース用の変数を以下のように設定します。

---
# group_vars/prod/datasources.yml
datasources:
- name: "Prometheus Sample"
  is_default: true
  type: prometheus
  access: proxy
  orgId: 1
  url: http://prom.example.com:9090/

- name: "Elasticsearch Sample"
  type: elasticsearch
  orgId: 1
  url: http://es.example.com:9200
  database: "[monitor-]YYYY.MM.DD"
  interval: "Daily"
  time_field: "@timestamp"
  es_version: 70
  max_concurrent_shard_requests: 5
  additional_json_data:
    logLevelField: "log.status"
    logMessageField: "log.message"

- name: "PostgreSQL Sample"
  type: postgres
  orgId: 1
  host: pg.example.com:5432
  database: digdag1xx
  user: digdag
  password: "{{ vault_grafana.pg_pw }}"

- name: "MySQL Sample"
  type: mysql
  orgId: 1
  host: mysql.example.com:5432
  database: grafana03_devel
  user: grafana
  password: "{{ vault_grafana.mysql_pw }}"

ロールの処理

main.yml は以下の通り、グループ変数 {{datasources}} を実行処理の import_datasource.yml に渡してデータソース単位に更新します。

---
# roles/import_datasource/tasks/main.yml
- name: Grafanaホストにデータソースをインポート
  include_tasks: import_datasource.yml
  with_items: "{{ datasources }}"

import_datasource.yml ではデータソースのimportするための記述となりますが、 ds_type 単位に設定を書くと記述量が大量になってしまいます。 そこで、1タスクで community.grafana.grafana_datasource で用しているパラメータをすべて列挙しています。
また、 {{datasources}} で定義していない項目は default(omit) で利用しないようにしています。

---
# roles/import_datasource/tasks/import_datasource.yml
- name: "Import datasource :{{ item.name }}"
  community.grafana.grafana_datasource:
    grafana_url: "{{ grafana_url }}"
    grafana_api_key: "{{ vault_grafana.grafana_api_key | default(omit) }}"
    grafana_password:  "{{ vault_grafana.url_password | default(omit) }}"
    grafana_user:  "{{ vault_grafana.url_username | default(omit) }}"
    access: "{{ item.access | default(omit) }}"
    additional_json_data: "{{ item.additional_json_data | default(omit) }}"
    additional_secure_json_data: "{{ item.additional_secure_json_data | default(omit) }}"
    basic_auth_password: "{{ item.basic_auth_password | default(omit) }}"
    basic_auth_user: "{{ item.basic_auth_user | default(omit) }}"
    client_cert: "{{ item.client_cert | default(omit) }}"
    database: "{{ item.database | default(omit) }}"
    ds_type: "{{ item.type }}"
    ds_url: "{{ item.url }}"
    enforce_secure_data: "{{ item.enforce_secure_data | default(omit) }}"
    es_version: "{{ item.es_version | default(omit) }}"
    interval: "{{ item.interval | default(omit) }}"
    is_default: "{{ item.is_default | default(omit) }}"
    max_concurrent_shard_requests: "{{ item.max_concurrent_shard_requests | default(omit) }}"
    name: "{{ item.name }}"
    org_id: "{{ item.orgId }}"
    sslmode: "{{ item.sslmode | default(omit) }}"
    state: "{{ item.state | default(omit) }}"
    time_field: "{{ item.time_field | default(omit) }}"
    time_interval: "{{ item.time_interval | default(omit) }}"
    tls_skip_verify: "{{ item.tls_skip_verify | default(omit) }}"
    tsdb_resolution: "{{ item.tsdb_resolution | default(omit) }}"
    tsdb_version: "{{ item.tsdb_version | default(omit) }}"
    use_proxy: "{{ item.use_proxy | default(omit) }}"
    user: "{{ item.user | default(omit) }}"
    validate_certs: "{{ item.validate_certs | default(omit) }}"
    with_credentials: "{{ item.validate_certs | default(omit) }}"

import_notification_channel(通知チャンネルをGrafanaに反映する)

通知チャンネルは、community.grafana.grafana_notification_channel を利用して追加・更新します。

グループ変数の設定

Grafana毎に必要な通知チャンネル用の変数を以下のように設定します。

---
# group_vars/prod/notification_channels.yml
notification_channels:
- name: "info notice slack"
  type: slack
  uid: "c80pnXDvYq"
  recipient: "#info"
  orgId: 1
  is_default: true
  include_image: true
  disable_resolve_message: false
  url: https://hooks.slack.com/services/XXXX/YYYY/ZZZZZ
  token: "{{ vault_grafana.slack_token_info }}"

- name: "grafana Info mail"
  type: email
  orgId: 1
  uid: "EQ8Pn7paaX"
  is_default: false
  include_image: true
  disable_resolve_message: true
  reminder_frequency: ""
  email_addresses:
    - "issue@example.com"
  email_single: false

ロールの処理

データソースの場合と同様です。

main.yml では、グループ変数 {{notification_channels}} を実行処理の import_notification_channel.yml に渡しています。

---
# roles/import_notification_channel/tasks/main.yml
- name: Grafanaに通知チャンネルをインポート
  include_tasks: import_notification_channel.yml
  with_items: "{{ notification_channels }}"

import_notification_channel.yml も同様です。
community.grafana.grafana_notification_channelのパラメータ にある項目を1つにまとめて記述します。

---
# roles/import_notification_channel/tasks/import_notification_channel.yml
- name: "Create slack notification channel :{{ item.name }}"
  community.grafana.grafana_notification_channel:
    grafana_url: "{{ grafana_url }}"
    grafana_api_key: "{{ vault_grafana.grafana_api_key | default(omit) }}"
    url_password:  "{{ vault_grafana.url_password | default(omit) }}"
    url_username:  "{{ vault_grafana.url_username | default(omit) }}"
    uid: "{{ item.uid }}"
    name: "{{ item.name }}"
    org_id: "{{ item.orgId }}"
    is_default: "{{ item.is_default }}"
    include_image: "{{ item.include_image }}"
    disable_resolve_message: "{{ item.disable_resolve_message }}"
    reminder_frequency: "{{ item.reminder_frequency | default(omit) }}"
    type: "{{item.type}}"
    slack_url: "{{ item.url | default(omit) }}"
    slack_token: "{{ item.token | default(omit) }}"
    slack_recipient: "{{ item.recipient | default(omit) }}"
    slack_mention_users: "{{ item.mention_users | default(omit) }}"
    slack_mention_groups: "{{ item.mention_groups | default(omit) }}"
    email_addresses: "{{ item.email_addresses | default(omit) }}"
    email_single: "{{ item.email_single | default(omit) }}"

import_dashboardダッシュボードをGrafanaに反映する)

ダッシュボードを追加・更新するには community.grafana.grafana_dashboard のImportを利用します。
また、フォルダに分けてダッシュボードを登録することになるので、合わせて community.grafana.grafana_folder も利用します。
さらに、既存のダッシュボードの一覧を変数として取得する grafana_dashboardのLookup Plugin も利用します。

グループ変数の設定

Grafana毎に必要なダッシュボード用の変数を以下のように設定します。
こちらにはImport/exportの対象となるダッシュボードのフォルダ名を列挙します。

また、 Dashboard HTTP API の "Create / Update dashboard" にあるようにデフォルトフォルダがGeneralなのでこれは必ず入れておきます。

---
# group_vars/prod/dashboards.yml
gf_folder:
  - General
  - XXXXX

ロールの処理

ダッシュボードフォルダ以下のダッシュボードは以下のファイルパス上に保存しています。

dashboards/(グループ名)/(フォルダ)/(ダッシュボードのUID).json

そこでフォルダ以下の全てのJSONファイルパスを取得して、ダッシュボード1つずつGrafanaにimportします。

mail.ymlでは、対象のダッシュボードのフォルダのリストとなるグループ変数 gf_folder をループして、ファルダを作成します(import_folder.yml)。
次にダッシュボードも同様にgf_folderを使ってimportしていきます(import_dashboard.yml)。

---
# roles/import_dashboard/tasks/main.yml
- name: フォルダ
  include_tasks: import_folder.yml
  with_items: "{{ gf_folder }}"
  loop_control:
    loop_var: folder

- name: ダッシュボード
  include_tasks: import_dashboard.yml
  with_items: "{{ gf_folder }}"
  loop_control:
    loop_var: folder

フォルダのimport(import_folder.yml)について、グループ変数 gf_folder から対象のフォルダ名がループで渡ってくるので、それをもとにフォルダをimport(作成)します。ただし、デフォルトで入っている General については不要なので実施内容にしている(無視して実行するとエラーになります)。

---
# roles/import_dashboard/tasks/import_folder.yml
- name: "{{ folder }} をGrafanaに作成"
  community.grafana.grafana_folder:
    url: "{{ grafana_url }}"
    grafana_api_key: "{{ vault_grafana.grafana_api_key | default(omit) }}"
    url_password:  "{{ vault_grafana.url_password | default(omit) }}"
    url_username:  "{{ vault_grafana.url_username | default(omit) }}"
    name: "{{ folder }}"
    state: present
  when: "folder != 'General'"

最後にダッシュボードは、フォルダ単位にダッシュボードをimportします(import_dashboard.yml)。
まず、ダッシュボードのJSONファイルを dashboards/prod_grafana/(フォルダ) 以下から fileglob を使って取得します。そして取得したリストでloopしてダッシュボードを1つずつimportしています。

---
# roles/import_dashboard/tasks/import_dashboard.yml
- name: "{{ folder }} のダッシュボードをGrafanaに反映"
  community.grafana.grafana_dashboard:
    grafana_url: "{{ grafana_url }}"
    grafana_api_key: "{{ vault_grafana.grafana_api_key | default(omit) }}"
    url_password:  "{{ vault_grafana.url_password | default(omit) }}"
    url_username:  "{{ vault_grafana.url_username | default(omit) }}"
    state: present
    overwrite: yes
    commit_message: "Push hash: {{ revision }}"
    path: "{{ _json_file_path }}"
    folder: "{{ folder }}"
  loop: "{{ lookup('fileglob', playbook_dir + '/dashboards/' + grafana_group + '/' + folder + '/*.json', wantlist=True) }}"
  loop_control:
    loop_var: _json_file_path

export_resources(Grafanaからダッシュボードを取得する)

既存のダッシュボードを取得するには community.grafana.grafana_dashboard のExportを利用します。 さらに、既存のダッシュボードの一覧を変数として取得する grafana_dashboardのLookup Plugin も利用します2

グループ変数の設定

import_dashboard で紹介したグループ変数 gf_folder を使うので割愛します。

ロールの処理

大まかな処理の流れとしては、Grafanaから根こそぎダッシュボード情報を取得してfactsに保存する。
その後、保存したfactsを使ってダッシュボード1つずつloop変数に入れて回しながらダッシュボードのフォルダ単位にディレクトリを作成しつつ整形してJSONファイルに変換しています。

---
# roles/export_resources/tasks/main.yml
- name: ダッシュボード情報を取得
  include_tasks: get_all_dashbords.yml

- name: JSONファイルに変換
  include_tasks: export_dashboard_to_json.yml
  with_items: "{{ __dashboards }}"
  loop_control:
    loop_var: dashboards

では、掘り下げていきます。

まず、get_all_dashbords.yml ではGrafanaサイトからダッシュボード情報をfacts __dashboards に保存します。

---
# roles/export_resources/tasks/get_all_dashbords.yml
- name: すべてのダッシュボードをfacts __dashboards にセット
  set_fact:
    __dashboards: "{{ lookup('grafana_dashboard', 'grafana_url=' ~ grafana_url + ' ' + 'grafana_api_key=' ~ vault_grafana.grafana_api_key | replace('==', '') ) }}"

次に、実行処理となる export_dashboard_to_json.yml についてです。 大まかには、1つのダッシュボード情報が 変数 dashboards に入ってるのでGrafanaにフォルダ→ダッシュボードの順でimportします。

まず、ダッシュボードJSONファイルを出力するパスを作成します。 「変数 dashboards にあるフォルダ名」と「確定しているGrafanaグループまでのパス({{ playbook_dir }}/dashboards/{{ grafana_group }})」を組み合わせて、facts export_dir にフォルダまでのパスを取得します。

次に、作成したexport_dirを使ってJSONファイルの出力先のフォルダを作成します。

JSONファイルの出力先のフォルダパスが決まったので一時的に tmp.json として、GrafanaからExportします。 書き出したJSONファイルは1行になっているのでPRする際に差分が取りにくくレビューしづらいので整形して出力します。 また、JSONファイル名は、他のダッシュボードのファイル名と衝突しないようにダッシュボードのUIDを使うことで回避しています。

---
# roles/export_resources/tasks/export_dashboard_to_json.yml
- name: JSONファイルの出力先ディレクトリ変数
  set_fact:
    export_dir: "{{ playbook_dir }}/dashboards/{{ grafana_group }}/{{ dashboards.folderTitle | default('General') }}"

- name: "{{ export_dir }}を作成"
  ansible.builtin.file:
    path: "{{ export_dir }}"
    state: directory
    recurse: true

- name: "Export dashboard :{{ dashboards.title }}"
  community.grafana.grafana_dashboard:
    grafana_url: "{{ grafana_url }}"
    grafana_api_key: "{{ vault_grafana.grafana_api_key | default(omit) }}"
    url_password:  "{{ vault_grafana.url_password | default(omit) }}"
    url_username:  "{{ vault_grafana.url_username | default(omit) }}"
    org_id: 1
    state: export
    uid: "{{ dashboards.uid }}"
    path: "{{ export_dir }}/tmp.json"

- name: "JSONファイルを読み込み"
  command: "cat {{ export_dir }}/tmp.json"
  register: raw_json_contents

- name: "仮出力したJSONファイル raw_json_contents を facts __dashboard_json_contents に格納"
  set_fact:
    __dashboard_json_contents: "{{ raw_json_contents.stdout | from_json }}"

- name: "__dashboard_json_contentsを整形してJSONファイル出力する"
  copy:
    content: "{{ __dashboard_json_contents | to_nice_json(indent=2) }}"
    dest: "{{ export_dir }}/{{ dashboards.uid }}.json"

- name: "rm tmp.json"
  ansible.builtin.file:
    path: "{{ export_dir }}/tmp.json"
    state: absent

Grafanaとの認証に関する注意事項

各ロールでは、Grafanaにアクセスする際は認証が必要になります。
Grafana v7.4以降を利用している場合は、認証にパラーメタ grafana_api_key を利用します。 しかし、Grafana v7.0辺りの古いバージョンを利用している場合は、認証にパラーメタ grafana_usergrafana_password を利用するので注意してください。

# 例
- name: "Import datasource :{{ item.name }}"
  community.grafana.grafana_datasource:
    grafana_url: "{{ grafana_url }}"
    grafana_api_key: "{{ vault_grafana.grafana_api_key | default(omit) }}" # v7.4以降はこれだけ
    grafana_password:  "{{ vault_grafana.url_password | default(omit) }}"  # v7.0以前はこっちを使う 
    grafana_user:  "{{ vault_grafana.url_username | default(omit) }}"      # v7.0以前はこっちを使う

特に、 roles/export_resources/tasks/get_all_dashbords.yml で利用している grafana_dashboardのlookupプラグインの記述方法が異なるのでご注意ください。

最後に

次回は、 @Endyさんの「 Ansible初心者向けの学習ロードマップ」(12/8)とのことです。楽しみですね!


  1. 各モジュールの利用方法は、Collectionの各モジュールのExamplesも参考になりますが、GrafanaのCollectionのあるリポジトリのtest環境が非常に参考になります。
    github.com
    他にも、各処理は最終的にはHTTP APIを使って処理しているので、以下のドキュメントの調べたいロールのAPIを参考にすると良いです。
    HTTP API | Grafana Labs

  2. Tips: Lookup Plugins: grafana_dashboard について
    set_factsでダッシュボードの情報を根こそぎディクショナリ変数に変換出来る。
    community.grafana.grafana_dashboard の情報よりも以下の実装を直接見た方が分かりやすいです。
    https://github.com/ansible-collections/community.grafana/blob/main/plugins/lookup/grafana_dashboard.py
    また、上記の実装を見てわかるように Folder/Dashboard Search HTTP API | Grafana Labs を叩いていることがわかります。

CIOpsでGrafanaダッシュボードを運用していく

この記事は MicroAd Advent Calendar 2021 及び Ansible Advent Calendar 2021Ansible Advent Calendar 2021 - Qiita の5日目の記事です。

qiita.com
adventar.org

はじめに

Grafana(だけじゃないはず)ダッシュボードを運用して、沢山グラフが増えてきた際に、こんな困りごとは無いですか?

  • 「このダッシュボードのグラフ壊れてるんですけど」
  • 「このグラフってなんでXXXがYYYYに変更されるんだ?」
  • 「そもそもこのダッシュボード or グラフってなんで追加したんだっけ?」
  • 「新しいバージョンで動くか検証したい」

以上のようにダッシュボードが増えるほど運用が大変になります。
Grafanaのダッシュボード自身はGrafanaの機能としてバージョン管理しているので簡単に戻すことは可能ですが、作成者が意図した状態を常に保っていて欲しいものです。

そこで、CIOpsでPRベースにGrafanaダッシュボードを管理する方法をご紹介します。

環境

今回の記事は以下を前提としています。

項目 Ver.
OS CentOS7以降、Ubuntu20.04以降
S/W Docker v20.10、Docker Compose v2.2.1
Grafana v8.2.5
ansible-core v2.11.6(v2.9でも動きます)
Jenkins(CircleCIでもGitHub Actionsでも何でも)

検証環境の用意

弄り倒すGrafanaを用意します。
以下のリポジトリに検証環境をおいているのでそちらを参考にしてください。

github.com

やらないこと

Grafanaのユーザーやチーム、プラグインの管理は対象外とします。 あくまでダッシュボード及びダッシュボードに必要なデータソースや通知チャンネルが対象となります。

また、データソースや通知チャンネルをgrafanaから取得する機能が利用するモジュールにないので諦め。

運用方法

今回のダッシュボード運用のために、通常利用する本番用とダッシュボードの開発用の2つのGrafanaを用意します。
また、ダッシュボードやデータソース、通知チャンネルといった情報を管理するためのリポジトリを用意します。

大まかにダッシュボードを更新する際の流れは下図の通りです。

f:id:yassan0627:20211205065905p:plain
ダッシュボード更新の流れ

具体的にはダッシュボードを更新する場合は以下の手順で更新します(上図の番号とは連動してません)。

  1. 本番Grafanaから更新したいダッシュボードをExport → View JSON → Copy to Clipboard
  2. 開発Grafanaにて、サイドバーの「+」→Create→importを選択し、クリップボードにコピーしたJSONを「Import via panel json」に貼り付けて「Load」を押下
  3. Optionにて、Folderを本番Grafanaと同じFolderを選択し、警告を無視して「Import(Overwirte)」を押下
  4. 開発Grafanaにて自由に更新する
  5. 手順1の様にしてダッシュボードをJSONファイルにExportする ※但し、ファイル名はダッシュボードのuid1とします(重要です)
  6. 管理用リポジトリにてbranchを作成
  7. 作成したbranchにて、DLしたJSONファイルを dashboardsに配置(無い場合は新規追加)
  8. 利用するダッシュボードが新たにデータリソースを変更・追加している場合は、別途 group_vars/XXX/datasources.yml に追加
  9. PR作成してレビューしマージ
  10. (マージ時にJenkinsにてAnsible使って本番Grafanaにダッシュボードを反映)

また、本番Grafanaがリポジトリと乖離すると運用が崩れます。
そこで、夜中にリポジトリダッシュボード、データソース、通知チャンネルを全て本番Grafanaと同期して防止します。

この運用の良い面と課題

良い面

  • 動作保証しているリポジトリの状態を常に保つことが出来るので「なんか知らんけど壊れてた」を防止
    • 補足:Grafanaにはダッシュボードのバージョンがあるので戻すのも簡単ですがどこが壊れてない場所かは探さないといけない
  • PRレビューをするのでダッシュボードの更新経緯を残しておけるし、誰かの目が入るので属人性を緩和できる
  • ダッシュボードの更新をIaCしたことで、別のホストで検証用に立ち上げたGrafanaや手元の環境にシュッとダッシュボード一式を用意出来る
  • PRレビューでダッシュボードの差分がコードで出るのでGrafana上でのパッと見で分からない点に気づくことが出来る

課題

  • 更新する際に本番GrafanaからダッシュボードをExportして開発GrafanaにImportするなど、更新が若干手間

では、具体的な話に入っていきます。

リポジトリの構成

リポジトリの構成は以下の通り。

.
├── collections
│   └── requirements.yml
├── dashboards/  ・・・・ダッシュボードの更新に使うJSONファイルの置き場所
│   ├── devel/  ・・・・グループ毎にダッシュボードのフォルダ名と同じように構成する
│   │   ├── General/
│   │   └── XXXXXX/
│        :
├── group_vars/  ・・・・グループ毎に必要な変数
│   └── devel/
│       ├── general.yml ・・・・・GrafanaのURLなど各ロールで共通して利用する変数
│       ├── dashboards.yml  ・・・ダッシュボードの取得・更新に必要な変数
│       ├── datasources.yml ・・・データソースの更新に必要な変数
│       ├── notification_channels.yml ・・・通知チャンネルの更新に必要な変数
│       └── vault_grafana.yml ・・平分で保存したくないものをすべてここに変数として保存
│        :
├── inventories/
│   ├── inventory
│   └── local
├── roles/
│   ├── XXXXXX/  ・・・必要になるロール
│            :
├── .vault_password ・・復号用PWファイル(リポジトリには含まない)
├── playbook.yml  ・・・実行用Playbook
├── view_secret.yml ・・暗号化変数を復号して中身を確認するPlaybook(管理用)
├── requirements.txt
├── Jenkinsfile ・・・・CI用の設定ファイル(今回はJenkins Pipelineをつかうので)
├── Makefile  ・・・・・各種コマンドはmakeで実行
└── ansible.cfg

※末尾が / で終わっているものはディレクトリ

ポイント

  1. ロールの実行に必要な変数は、対象のGrafana毎にグループ変数を用意して個別に設定を分ける
  2. Grafanaのトークンや通知チャンネル・データソースのクレデンシャル情報といった平文で保存すると都合の悪いものは、 vault_grafana.yml に暗号化変数として定義
  3. GrafanaダッシュボードのJSONファイルは、dashboards/ 以下にダッシュボードのフォルダと同じ名称でディレクトリを作成し、グループ・フォルダ毎に保存
  4. 毎回ansibleコマンドを打つのがめんどいのでmakeを使って簡略化(これはCIを定義する際にもCI側定義を楽にできます)

具体的な実装方法について

ロールを適用するには

以下のPlaybookを使って、ロールを適用します。単純に変数 role_name で指定したロールのみを変数 grafana_group にあるグループのみに適用します。

---
# playbook.yml
- hosts: "{{ grafana_group }}"
  connection: local
  gather_facts: false
  become: false
  vars:
    ansible_python_interpreter: "{{ python_interpreter | default('/usr/bin/python3')}}"
  roles:
    - "{{ role_name }}"

また、インベントリ(inventories/inventory)は以下のようにしています。

# inventories/inventory
# 本番用Grafana
[prod]
prod-grafana.example.com

# 開発用Grafana
[devel]
devel-grafana.example.com

上記をもとに ansible-playbook コマンドを使って実行します。
また、 playbook.yml で利用する各変数は追加変数として --extra-vars を用いて指定しています。

例えば、ロール名 export_dashboard を グループ prod に適用する場合は以下の通り。

$ ansible-playbook -i inventories/inventory --connection=local \
        --vault-id .vault_password \
        playbook.yml \
            --extra-vars role_name=export_dashboard \
            --extra-vars grafana_group=prod ;

ただ、毎回上記のコマンドを打つのがめんどくさいのでMakefileに以下ように追加します。 すると、 make export_dashboard group=prod だけで済むようになります。

.PHONY: export_dashboard
export_dashboard:
  ansible-playbook -i inventories/inventory --connection=local \
      --vault-id .vault_password \
      playbook.yml \
          --extra-vars role_name=export_dashboard \
          --extra-vars grafana_group=$(group) ;

シークレット情報の扱いについて

データソースや通知チャンネルには、一部、平文で保存してはいけないパスワードやトークンなどが含まれます。 Gitリポジトリで管理するので、そのまま記述出来ません。

そこで、Vault変数を用いて暗号化し、実行に内部で復号して利用します。
今回はencrypt_stringを用いて、YAMLファイルに埋め込む暗号化変数2をもちいます。

以下がその例です。

---
# group_vars/devel/vault_grafana.yml
vault_grafana:
  grafana_api_key: !vault |
    $ANSIBLE_VAULT;1.1;AES256
    36353963333633386231333964343035346539633430646434333931656634663064306164336663
    3632393562643635343062336531653162383835653633620a366561383465393930306130623434
    37656362393038376533323533613530313938306262366463343433363666323662306562653264
    6130356262316233300a616135616535643536346138626133343231333232323730663539376237
    34383430316265303062613233326438303932626330356339663962353634333263373633666538
    63323335653832356636326565656230303661626335623132356230613434616164363836666266
    65646232353137643732303535613066653739363639303263393937613465373364393738623264
    32613662346639393964

上記のように定義することで、必要な箇所で "{{ vault_grafana.slack_token_test }}" として呼び出し可能になります。

暗号化変数の登録方法について

登録は以下のようにコマンドを実行して、暗号化変数を生成します。 また、事前に .vault_password を作成して中に暗号化キーを入れておいてください。

$ ansible-vault encrypt_string \
        --vault-id .vault_password \
        --stdin-name "hoge_token" ;
Reading plaintext input from stdin. (ctrl-d to end input, twice if your content does not already have a newline)
himitsu
hoge_token: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          35613234613332316261383133343830346230343938343765326237623037393435396166633830
          3839373538376361616538666135316134343935636363370a643839666537323539316133346238
          63636137363165343035303032613461356363626134656465323237626435353138386663656135
          3239343634323937610a393835333438653738363133323764376161323665643736323664633466
          6266
Encryption successful

必要なのは以下の部分だけで、これをコピーして group_vars/devel/vault_grafana.yml に追加していけばOK。

hoge_token: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          35613234613332316261383133343830346230343938343765326237623037393435396166633830
          3839373538376361616538666135316134343935636363370a643839666537323539316133346238
          63636137363165343035303032613461356363626134656465323237626435353138386663656135
          3239343634323937610a393835333438653738363133323764376161323665643736323664633466
          6266

以下のように追加します。

---
# group_vars/devel/vault_grafana.yml
vault_grafana:
  grafana_api_key: !vault |
    $ANSIBLE_VAULT;1.1;AES256
    :
  hoge_token: !vault |
    $ANSIBLE_VAULT;1.1;AES256
    35613234613332316261383133343830346230343938343765326237623037393435396166633830
    3839373538376361616538666135316134343935636363370a643839666537323539316133346238
    63636137363165343035303032613461356363626134656465323237626435353138386663656135
    3239343634323937610a393835333438653738363133323764376161323665643736323664633466
    6266

また、これも以下のようにMakefileに追加すます。

.PHONY: generate-vault-string
generate-vault-string:
  ansible-vault encrypt_string \
      --vault-id .vault_password \
      --stdin-name "$(name)" ;

登録したVault変数を確認するには

登録後に正しく値が入っているか確認するためにPlaybookを作成します。

---
# view_secret.yml
- name: Execute a role
  hosts: localhost
  gather_facts: no
  pre_tasks:
    - name: Include variables
      include_vars: 
        dir: "{{ target_dir }}"
        ignore_unknown_extensions: true
        
  tasks:
    - name: view vault string
      debug:
        var: "{{ lookup('vars', item) }}"
      loop:
        - target_vault

上記のPlaybookを以下のように実行します。登録時と同じようにmakeから実行できるようにします。 また、利用方法は make view-vault-string dir=group_vars/devel name=vault_grafana のようにて実行します。

.PHONY: view-vault-string
view-vault-string:
   @ansible-playbook -i inventories/inventory \
      --vault-id .vault_password \
      view_secret.yml \
          -e target_dir=$(dir) -e target_vault=$(name)

CIについて

今回はJenkins Pipelineを使うので、以下のように定義します。

pipeline {
    agent {
        label 'worker'
    }
    triggers {
        // 毎日0am(JST)のどっかで実施
        cron '''TZ=Asia/Tokyo
        0 0 * * *'''
    }
    environment {
        ANSIBLE_VAULT_PASSWORD = credentials('vault_password_ansible_ci')
    }
    stages {
        stage('定期更新: prod-grafana') {
            when {
                // 定期実行のみの処理(masterのみ)
                branch 'master'
                triggeredBy 'TimerTrigger'
            }
            steps {
                println "Execute Test Node [${NODE_NAME}]"
                // Pythonの仮想環境のSetup
                sh '''
                    export HTTP_PROXY=http://XXX:8080
                    export HTTPS_PROXY=http://XXX:8080
                    make init
                    make init-test
                '''
                // 本番環境の更新
                sh '''
                    echo $ANSIBLE_VAULT_PASSWORD > .vault_password
                    source .venv/bin/activate
                    make import_notification_channel group=prod
                    make import_datasource group=prod
                    make import_dashboard group=prod
                '''
            }
        }
        stage('Update: Grafanaリソース') {
            // 課題:変更差分からグループと対応するGrafanaリソースをパース出来てないので
            //    changesetでcheckしてprod決め打ちでmasterマージ時に更新する
            // → masterへのmergeリクエストの際に、変更差分がpatternにマッチした場合に実行
            when {
                branch 'master'
                changeset pattern: '^group_vars/prod/.*|^dashboards/prod/.*', comparator: 'REGEXP'
            }
            steps {
                println "Execute Test Node [${NODE_NAME}]"
                // Pythonの仮想環境のSetup
                sh '''
                    export HTTP_PROXY=http://XXX:8080
                    export HTTPS_PROXY=http://XXX:8080
                    make init
                    make init-test
                '''
                // 本番環境の更新
                sh '''
                    echo $ANSIBLE_VAULT_PASSWORD > .vault_password
                    source .venv/bin/activate
                    make import_notification_channel group=prod
                    make import_datasource group=prod
                    make import_dashboard group=prod
                '''
            }
        }
    }
}

ポイントは以下の通り。

  • Vault変数を復号するためにJenkinsのクレデンシャルに vault_password_ansible_ci として、本番GrafanaのAdminロールのAPIキー3を登録している
  • 定期的に同期を取るように TimerTrigger を使って実行
  • マスターへのマージ時に本番Grafanaのグループ変数やダッシュボードに更新が入った場合に同期を行う
    • ただし、個別に更新が出来てないので全て同期をとってます

次に、各ロールで実行するansibleのtaskの記述方法を説明するのですが、長くなってきたので今回はこの辺で。

続きは、 Ansible Advent Calendar 2021Community.Grafanaを利用する話を書いていきます。楽しみが増えました(?)ね。

次回のアドカレは、以下のとおりです。

楽しみですね。それではまた明日。


  1. JSONファイルの末尾に “uid”: “l3KqBxCMz” のような形式で記述している。 cf. Dashboard HTTP API | Grafana Labs

  2. 詳しい説明はこちら:Ansible Vault — Ansible Documentation

  3. 作成方法はこちら: Create API Token - Authentication HTTP API | Grafana Labs

Win10でネイティブにAnsibleを実行したかった件

f:id:yassan0627:20210508153841p:plain

結論

Windows Frequently Asked Questions · ansible/ansible にある通り、現状、Windowsから直接Ansibleは実行出来ない(但し、WSL経由ならいける)。

Can Ansible run on Windows? No, Ansible can only manage Windows hosts. Ansible cannot run on a Windows host natively, though it can run under the Windows Subsystem for Linux (WSL).

環境

-- --
エディション Windows 10 Pro
バージョン 21H1
インストール日 2020/08/23
OS ビルド 19043.964
エクスペリエンス Windows Feature Experience Pack 120.2212.3740.0

モチベ

Win10 Homeで、VagrantHyper-V使ってVM起動する際に、 初回の作業(特定のユーザ作ってSSH鍵追加したり、dnf updateとか)がダルいので自動化したい、、、

んで、Provisionerにちょうどよいのないかなぁとドキュメント読んでたら、 VagrantのProvisionerにAnsibleが使えるって事で試そうとした。

www.vagrantup.com

やった事

pythonのインストール

以下にある通り、パッケージをDLってインストール。 www.python.jp

仮想環境の作成&ansibleのインストール

ansibleがwinネイティブに使えるなら他にも使いたいので、venvを使って環境を分ける。

❯ py -m venv --without-pip .venv
❯ .venv\Scripts\activate.ps1
❯ curl https://bootstrap.pypa.io/get-pip.py
❯ py get-pip.py
❯ py -m pip install -r requirements.txt

requirements.txt

flake8
pytest
cryptography
jmespath == 0.9.5
PyYAML >= 5.4.1

ansible-base <2.11,>=2.10.7
yamllint >=1.25.0
ansible-lint >=5.0.0
python-vagrant >= 0.5.15

上手くいくかと思ったけど、以下のエラー

❯ py -m pip install ansible-base==2.10.9
Collecting ansible-base==2.10.9
  Using cached ansible-base-2.10.9.tar.gz (6.0 MB)
Requirement already satisfied: jinja2 in c:\users\yassan\vargant\hoge\.venv\lib\site-packages (from ansible-base==2.10.9) (2.11.3)
Requirement already satisfied: PyYAML in c:\users\yassan\vargant\hoge\.venv\lib\site-packages (from ansible-base==2.10.9) (5.4.1)
Requirement already satisfied: cryptography in c:\users\yassan\vargant\hoge\.venv\lib\site-packages (from ansible-base==2.10.9) (3.4.7)
Requirement already satisfied: packaging in c:\users\yassan\vargant\hoge\.venv\lib\site-packages (from ansible-base==2.10.9) (20.9)
Requirement already satisfied: cffi>=1.12 in c:\users\yassan\vargant\hoge\.venv\lib\site-packages (from cryptography->ansible-base==2.10.9) (1.14.5)
Requirement already satisfied: pycparser in c:\users\yassan\vargant\hoge\.venv\lib\site-packages (from cffi>=1.12->cryptography->ansible-base==2.10.9) (2.20)
Requirement already satisfied: MarkupSafe>=0.23 in c:\users\yassan\vargant\hoge\.venv\lib\site-packages (from jinja2->ansible-base==2.10.9) (1.1.1)
Requirement already satisfied: pyparsing>=2.0.2 in c:\users\yassan\vargant\hoge\.venv\lib\site-packages (from packaging->ansible-base==2.10.9) (2.4.7)
Building wheels for collected packages: ansible-base
  Building wheel for ansible-base (setup.py) ... error
  ERROR: Command errored out with exit status 1:
   command: 'C:\Users\yassan\vargant\hoge\.venv\Scripts\python.exe' -u -c 'import io, os, sys, setuptools, tokenize; sys.argv[0] = '"'"'C:\\Users\\yassan\\AppData\\Local\\Temp\\pip-install-4p46nnmv\\ansible-base_68e8945aa34749959f5671f4bb8c4177\\setup.py'"'"'; __file__='"'"'C:\\Users\\yassan\\AppData\\Local\\Temp\\pip-install-4p46nnmv\\ansible-base_68e8945aa34749959f5671f4bb8c4177\\setup.py'"'"';f = getattr(tokenize, '"'"'open'"'"', open)(__file__) if os.path.exists(__file__) else io.StringIO('"'"'from setuptools import setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' bdist_wheel -d 'C:\Users\yassan\AppData\Local\Temp\pip-wheel-tymwpqt_'
       cwd: C:\Users\yassan\AppData\Local\Temp\pip-install-4p46nnmv\ansible-base_68e8945aa34749959f5671f4bb8c4177\
  Complete output (951 lines):
  running bdist_wheel
   :
  creating build\lib\ansible_test\_data\sanity\yamllint
  copying test\lib\ansible_test\_data\sanity\yamllint\yamllinter.py -> build\lib\ansible_test\_data\sanity\yamllint
  creating build\lib\ansible_test\_data\sanity\yamllint\config
  copying test\lib\ansible_test\_data\sanity\yamllint\config\default.yml -> build\lib\ansible_test\_data\sanity\yamllint\config
  copying test\lib\ansible_test\_data\sanity\yamllint\config\modules.yml -> build\lib\ansible_test\_data\sanity\yamllint\config
  copying test\lib\ansible_test\_data\sanity\yamllint\config\plugins.yml -> build\lib\ansible_test\_data\sanity\yamllint\config
  creating build\lib\ansible_test\_data\setup
  copying test\lib\ansible_test\_data\setup\ConfigureRemotingForAnsible.ps1 -> build\lib\ansible_test\_data\setup
  copying test\lib\ansible_test\_data\setup\docker.sh -> build\lib\ansible_test\_data\setup
  copying test\lib\ansible_test\_data\setup\remote.sh -> build\lib\ansible_test\_data\setup
  copying test\lib\ansible_test\_data\setup\windows-httptester.ps1 -> build\lib\ansible_test\_data\setup
  creating build\lib\ansible_test\config
  copying test\lib\ansible_test\config\cloud-config-aws.ini.template -> build\lib\ansible_test\config
  copying test\lib\ansible_test\config\cloud-config-azure.ini.template -> build\lib\ansible_test\config
  copying test\lib\ansible_test\config\cloud-config-cloudscale.ini.template -> build\lib\ansible_test\config
  copying test\lib\ansible_test\config\cloud-config-cs.ini.template -> build\lib\ansible_test\config
  copying test\lib\ansible_test\config\cloud-config-gcp.ini.template -> build\lib\ansible_test\config
  copying test\lib\ansible_test\config\cloud-config-hcloud.ini.template -> build\lib\ansible_test\config
  copying test\lib\ansible_test\config\cloud-config-opennebula.ini.template -> build\lib\ansible_test\config
  copying test\lib\ansible_test\config\cloud-config-openshift.kubeconfig.template -> build\lib\ansible_test\config
  copying test\lib\ansible_test\config\cloud-config-scaleway.ini.template -> build\lib\ansible_test\config
  copying test\lib\ansible_test\config\cloud-config-tower.ini.template -> build\lib\ansible_test\config
  copying test\lib\ansible_test\config\cloud-config-vcenter.ini.template -> build\lib\ansible_test\config
  copying test\lib\ansible_test\config\cloud-config-vultr.ini.template -> build\lib\ansible_test\config
  copying test\lib\ansible_test\config\inventory.networking.template -> build\lib\ansible_test\config
   :
  copying test\lib\ansible_test\config\inventory.winrm.template -> build\lib\ansible_test\config
  error: symbolic link privilege not held
  ----------------------------------------
  ERROR: Failed building wheel for ansible-base
  Running setup.py clean for ansible-base
Failed to build ansible-base
Installing collected packages: ansible-base
    Running setup.py install for ansible-base ... error
    ERROR: Command errored out with exit status 1:
     command: 'C:\Users\yassan\vargant\hoge\.venv\Scripts\python.exe' -u -c 'import io, os, sys, setuptools, tokenize; sys.argv[0] = '"'"'C:\\Users\\yassan\\AppData\\Local\\Temp\\pip-install-4p46nnmv\\ansible-base_68e8945aa34749959f5671f4bb8c4177\\setup.py'"'"'; __file__='"'"'C:\\Users\\yassan\\AppData\\Local\\Temp\\pip-install-4p46nnmv\\ansible-base_68e8945aa34749959f5671f4bb8c4177\\setup.py'"'"';f = getattr(tokenize, '"'"'open'"'"', open)(__file__) if os.path.exists(__file__) else io.StringIO('"'"'from setuptools import setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' install --record 'C:\Users\yassan\AppData\Local\Temp\pip-record-9tp3_0q8\install-record.txt' --single-version-externally-managed --compile --install-headers 'C:\Users\yassan\vargant\hoge\.venv\include\site\python3.6\ansible-base'
         cwd: C:\Users\yassan\AppData\Local\Temp\pip-install-4p46nnmv\ansible-base_68e8945aa34749959f5671f4bb8c4177\
    Complete output (949 lines):
    running install
    running build
    running build_py
    creating build
    creating build\lib
      :
    copying test\lib\ansible_test\config\inventory.winrm.template -> build\lib\ansible_test\config
    error: symbolic link privilege not held
    ----------------------------------------
ERROR: Command errored out with exit status 1: 'C:\Users\yassan\vargant\hoge\.venv\Scripts\python.exe' -u -c 'import io, os, sys, setuptools, tokenize; sys.argv[0] = '"'"'C:\\Users\\yassan\\AppData\\Local\\Temp\\pip-install-4p46nnmv\\ansible-base_68e8945aa34749959f5671f4bb8c4177\\setup.py'"'"'; __file__='"'"'C:\\Users\\yassan\\AppData\\Local\\Temp\\pip-install-4p46nnmv\\ansible-base_68e8945aa34749959f5671f4bb8c4177\\setup.py'"'"';f = getattr(tokenize, '"'"'open'"'"', open)(__file__) if os.path.exists(__file__) else io.StringIO('"'"'from setuptools import setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' install --record 'C:\Users\yassan\AppData\Local\Temp\pip-record-9tp3_0q8\install-record.txt' --single-version-externally-managed --compile --install-headers 'C:\Users\yassan\vargant\hoge\.venv\include\site\python3.6\ansible-base' Check the logs for full command output.

結論にある通り、FAQ見たら動かないとの事。。残念。

Can Ansible run on Windows? No, Ansible can only manage Windows hosts. Ansible cannot run on a Windows host natively, though it can run under the Windows Subsystem for Linux (WSL).

参考

スマイルゼミタブレット3をAndroidタブレット化&ファミリーリンク対象にする話

子供がスマイルゼミをやってたのだけど、4月から辞めることにしたので、Androidタブレット化して使おうって事でやってみたがハマりどころがあったのでメモ。

前提

型番: SZJ-JS201 のスマイルゼミタブレット3

Androidタブレット化する

Androidタブレット化するのはむっちゃ簡単。
以下の通りにやったら良いだけ。

smile-zemi.jp

ファミリーリンクの対象となるように子供のアカウントを使う

ここでハマった。
おそらくスマイルゼミタブレット3のAndroid OSのバージョンが、 v5.1 系で有ることが一番の原因だろう(Justsystemさん、updateしてくれないかなぁ)。

何も対策しない状態だと、子供のアカウントを追加しようとして、保護者アカウントで承認する辺りでコケる。
対処方法は、以下。

  1. 保護者のアカウントで一旦、アカウントを追加。
  2. Google Play 開発者サービス」を含む、スマイルゼミタブレット3にあるアプリをすべてアップデート
  3. 設定→ユーザー設定→アカウントから、今使っている保護者のアカウントを削除
  4. 子供のアカウントでログイン

詳細は 以下の「お子様のアカウントでログインできない場合」って箇所を参照。

お子様の Android デバイスでのログイン - Google For Families ヘルプ

Androidタブレット化してみて

OSが古いのでいつまで使えるかなぁ感が否めない。
また、タブレットとしてのスペックもメモリ 2GB LPDDR3、フラッシュメモリ 16GBとそこまで期待出来ない。

実は、Z会に乗り換えたのだけど、Z会側のスペックを満たしてなかったので、使い回し出来なかったのが残念。。

KVMスイッチ サンワサプライ 400-SW032 の使用メモ

在宅勤務が今後も続くって事で、以下の状態だったので、

んで、実際に買ってみてのメモ。 amzn.to

結論

使えるかどうかって話だと、Windows10(自作マシン)とUbuntu 20.04LTS(ThinkPad T480s)の環境で使ってますが、問題なく使えています。

利用環境

キーボードは Lenovo のワイヤレスのUSキーボードを使ってます。 www.lenovo.com

マウスは、Logicoolの MX Master 2S

amzn.to

ただ、KVMに指してるのは、キーボードだけ。
理由は、マウスがUnifyingレシーバーを使っているのでこのKVMスイッチでは対応していないためです。
とは言え、MX Master 2S自身に、切り替えボタンがあるので特に困ってない(対応してれば便利ですが)。

注意点(というか忘れやすいのでメモ)

切り替えキー変更の際は、 IMEオフにして Ctrl+F12 → Tキー
🚨 IMEオンの際は、変更出来ない

まとめ

  • (メーカー動作保証外だけど)Windows10↔Ubuntu20.04で利用可能
  • 切り替えキーは、 デフォルト Ctrl2回だが、ScrLock2回に変更も可能
    • 変更の際は、IMEオフにするのを忘れない事
  • BluetoothやUnifyingには非対応
  • 標準じゃないキー、いわゆるメディアキー(ボリュームUPとか)は使えない
  • 特にタイピングに追いつかないとかの現象は、Win/Ubuntuどっちでも発生してない

切り替えキーで切り替え出来るのはホント便利。
有線マウスとかならマウスも込みで切り替え出来るのでもっと便利そう。

まぁ、以下の機能のあるお値段手頃なキーボードあればそっち使うかも。 * Win/Linuxで切り替え機能 * US配列 * ワイヤレス * テンキーレス(矢印キーやHome、とかは分離してるテンキーだけ無い こういうの ) * ミュートON/OFFとかメディアキー有り

やっさん的Ansible role開発をmolecule使って始めるテンプレ

adventar.org この記事は、上記の6日目の記事です。

ロールを追加する際に、 molecule を使うと非常に便利です。テスト(verify)を書かないにしても、テストドライバーを使ってdockerやvagrantなどの仮想環境にroleを適用してみて途中でエラーになったり、templateの生成が想定が違うなどを実際に確認出来るので、まずははじめることをオススメします。

いつもroleを作成する際にやってる一連の流れを紹介。 XXは〇〇すると良いよ!など、アドバイスあれば教えて下さい!

  • 前提
  • 初期構築
    • 仮想環境(venv)の用意
  • 始めるとき
  • roleのテンプレを使って初回分を作成
  • roleにシナリオを追加する場合
  • さいごに
  • 参考

前提

OS:CentOS7 or Ubuntu 20.04 LTS

molecule 3.2.1 using python 3.8 
    ansible:2.10.4
    delegated:3.2.1 from molecule
    docker:0.2.4 from molecule_docker
    vagrant:0.6.1 from molecule_vagrant

また、roleを含むリポジトリRoles — Ansible Documentation にあるように以下の構成とします。

# playbooks
site.yml
group_vars/
    group_xxx/
host_vars/
    xxxx.example.com/
roles/
    xxx/
        defaults/
        files/
        handlers/
        library/
        meta/
        tasks/
        templates/
        vars/
    yyy/
     :
続きを読む