tubone

tubone

Boyaki makes a new world


 Recent posts  6 / 53

SepOctNovDecJanオムロン HV-F312で腰の痛みをなくすGithub Actionを使って、簡単CIを作ってみるChromeDriverがGoogleChrome v76 に対応していないらしい。Googleデータポータルを触ってみるHyper-vにMetasploitableの仮想マシンを立ててみるNightwatch.jsでE2Eテストを回したときにうまく動かないたった一つの理由particles.jsをVue.jsで使ってかっこいいページを作るGitPitchを使ってMarkdownからプレゼンテーションを作ってBadgeをレポジトリに貼るSentryを使ってフロントエンドのエラーを確認するJSON Resume + API With GitHubを使って、さくっと職務経歴書チックなもののAPIなど作ってみるGitHubに30日間草を生やし続けた感想Netlify Formを使って、簡易Contact Formを作ってみる10/1は天下一品の日Ansible + Serverspecを使ってMacの環境構築を自動でする (Ansible編)Ansible + Serverspecを使ってMacの環境構築を自動でする (Serverspec編)今日のラーメン台風の時の我が家のセンサー(netatmo)の値をZabbixで見る究極の謝罪はSlackのスタンプを活用しよう! ~明日から使えるSlackスタンプスニペット集~ハロウィーンはえちえちでチンパンジーなイベントじゃない。GitHubと向き合うイベントだ昔ながらのラーメンたべたい珠玉の一杯。たくさん残業した日はこのラーメンを食べろ!スープの衝撃!ここまでうまいスープはあるのか!?なラーメンGitHubに草を生やし続け90日が経ったので感想を書くGoでAWS Lambdaを動かして、GitHubAPIv4(GraphQL)を叩いてみた感想Hadoopゾウさんについて本気出して考えてみたNuxt.jsでparticles-bg-vueを使うNuxt.jsのmodulesをCompositionAPIで使ってみる(@nuxtjs/toast編)くろおびらーめん with チャーシュー飯Nuxt.jsのmodulesをCompositionAPIで使ってみる(@nuxtjs/toast Global Option編)Nuxt.js + Composition APIでVuexのStateをReactiveに使う方法【初学者】Juliaを使って円周率を求めるデスクのかわいいやつら面倒なことはPythonにやらせよう@GitHub API v4を使ったリリース実績取得Gatsby.jsで作ったブログに読み終わるまで○○分を追加した話Google広告設定でみる属性情報であなたをもっと知ろう!Blog用に新しいLogo作った話今年1年を振り返ってGoのEchoでJaegerを使ってボトルネックを調査するGatsby.jsで作ったBlogの投稿をGitHubの草にして表示させるWeb Developer Roadmap 2020を眺めながら今年の目標(Frontend)をだらだら考えるの会AWS X-RayでLambdaのトレースをしつつ、Datadog APMに連携するElixirでパラレルな負荷試験ツールを作るMonWedFri
Elixirでパラレルな負荷試験ツールを作るAWS X-RayでLambdaのトレースをしつつ、Datadog APMに連携するWeb Developer Roadmap 2020を眺めながら今年の目標(Frontend)をだらだら考えるの会Gatsby.jsで作ったBlogの投稿をGitHubの草にして表示させるGoのEchoでJaegerを使ってボトルネックを調査する今年1年を振り返って


 SearchBox

Search your interesting by Algolia in this blog.


 All 145 Tags

ぼやき 19JavaScript 12GitHub 7ラーメン 6Vue.js 6TypeScript 6デブ活 5Nuxt.js 4React 3Gatsby.js 3Ansible 3Serverspec 3Mac 3自動テスト 3AWS 3Python 3Auto Provisioning 3GitHub Action 2Go 2Netlify 2Lambda 2GraphQL 2ChromeDriver 2Chainer 2Write Code Every Day 2toast 2CompositionAPI 2test 1particle.js 1GitPitch 1GitHub Badges 1Azusa Colors 1E2E Test 1Sentry 1監視 1JSON Resume 1GitHub Pages 1Resume 1CV 1 1weed 1Selenium 1Netlify Form 1GoogleChrome 1Contact Form 1Travis 1天下一品 1健康 1Gatsby 1腰痛 1Headless CMS 1GitHubAction 1Azure Devops Build Pipeline 1netatmo 1台風 1IoT 1センシング 1Google Apps Script 1API FLASH 1SlackAPI 1Clasp 1CI 1Jest 1Unit Test 1Slack 1Stamp 1ハロウィーン 1Nim 1docopt 1CLI 1昆布 1Googleデータポータル 1BI 1Google Analytics 1仮想化 1Hadoop 1ゾウ 1AWS認定ソリューションアーキテクトプロフェッショナル 1資格 1勉強法 1Hyper-v 1metasploitable 1RNN 1LSTM 1Chat BOT 1アイマス 1デレマス 1ひなこのーと 1Deep Learing 1OpenCV 1機械学習 1CNN 1分類学習 1顔認識 1powerShell 1particles-bg-vue 1particle 1Proton 1particles.js 1modules 1E2Eテスト 1Nightwatch.js 1チャーシュー飯 1Composition API 1Vuex 1ストアパターン 1ギター 1DTM 1エフェクター 1ATELIERZ 1Caparison 1VOCALOID 1Julia 1円周率 1初心者 1The Gauss–Legendre algorithm 1Leibniz formula for π 1早稲田 1かわいい 1恐竜時代 1ことり隊 1GitHub API v4 1リリース実績 1Estimated Reading Time 1あと何分 1Google広告設定 1Google 1属性情報 1Persolal Data 1Logo 1SVG 1Server 1Seti@Home 1振り返り 1Frontend 1Web Developer Roadmap 2020 1Echo 1Jaeger 1ボトルネック調査 1Elixir 1Load Test 1React Calendar Heatmap 1X-Ray 1Datadog 1APM 1
この記事は367文字1.8で読めます

毎回Macの環境構築めんどくさい

開発用MacBookの構成管理がしたくなり、AnsibleとServerspecを使って作りました。

記事が長くなりそうなので、今回は前半戦ということでAnsibleの設定について解説します。

Table of Contents

Ansible

Img

AnsibleとはPython製のOSS構成管理ツールです。

便利なモジュールが多数用意されており、パッケージのインストール、コンフィグの書き換え、サービスの立ち上げ、有効化etc.. 様々な構成をYaml形式でパパっとかけることがポイントです。

また、冪等(べきとう)性、つまり何回実行しても結果が変わらないことを保証したり、エージェントレスで構成管理対象のサーバに事前インストールが必要ないことが評価されている点です。

MacでAnsibleを使う

ローカル環境であるMacの構成管理にもAnsibleが使えます。

ansible_connectionというパラメータをlocalにすることで、localhost上のマシンに対してコマンドが発行できるのでそれをうまく使います。

また、Macでパッケージをインストールするときにたびたびお世話になるHomebrewもAnsibleのモジュールにちゃんと用意されていますのでそちらを使います。

Homebrewでのインストールは次のように定義します。

- name: 'Install Git'
  homebrew:
    name: 'git'
    state: 'present'

簡単そうですね。では早速作っていきましょう。

├─ansible
│  └─mac
│      ├─inventory
|      |  ├─default
│      │  └─group_vars
│      │      └─local
│      ├─playbooks
│      └─roles
│          └─dev-tools
│              ├─tasks
|              |   |
|              |   └─main.yml
|              |   └─hoge.yml
│              └─vars
|                 └─main.yml

Ansibleのディレクトリ構成は上記のようにしてます。

Ansibleのplaybookを作るにはざっくり3つの手順を取ります。

  1. 接続先情報をまとめたInventoryを設定
  2. 実際の構成情報を記載したRoleを設定
  3. InventoryとRoleをひとまとめにしたplaybookを設定

では早速Inventoryの設定から進めていきます。

Inventoryを設定する

Inventoryは複数のサーバをグルーピングして、同時にプロビジョンするためにサーバの接続情報をまとめておくコンフィグです。

今回はMacに適用するため、接続先情報はlocalとなります。

inventoryをコマンドで指定しない場合にdefalutで設定されるdefalutファイルに下記を設定します。

inventory/defalut

[local]
localhost

これで、特にInventoryを指定しない場合はlocalhostとして接続がされます。また、InventoryGroupとしてlocalを指定しているため、group_vars/localにlocalとして共通の変数を定義することもできます。

今回は複数サーバで共有させる変数が見当たらないので特に設定しません。

inventory/group_vars/local/ansible.yml

ansible_connection: 'local'

と設定しておけばいいです。

Roleを設定

次にRoleを設定していきます。

今回は特にRoleを分ける必要もないのですが、たとえば

  • 開発者のMac
  • デザイナーのMac
  • 運用者のMac

とそれぞれインストールするアプリが異なる場合、全員に共通して入れたい設定やAさんは開発者兼デザイナーで両方のアプリが入れたいなどの要求もある場合はそれぞれ

  • dev-tools
  • design-tools
  • ops-tools

みたくRoleをわけておくのがセオリーです。

さて、今回は開発者用のRoleだけつくればいいことにしますので、

dev-toolsだけ用意します。

また、各RoleにはTaskというプロビジョニングの実行単位があります。

例えば、Pythonを入れるTask、Node.jsを入れるTaskという具合です。

AnsibleではTasksディレクトリのmain.ymlが読み込まれるため、各Taskごとに分けたYamlmain.ymlでIncludeして上げればいいわけです。

roles/dev-tools/tasks/main.yml に

- include: 'tools.yml'
- include: 'git.yml'
- include: 'nodejs.yml'
- include: 'terraform.yml'
- include: 'python.yml'
- include: 'ruby.yml'
- include: 'docker.yml'

とIncludeさせるだけです。かんたんです。

Homebrew

上記にも書いたとおり、AnsibleではHomebrewモジュールが用意されているため、

roles/dev-tools/tasks/nodejs.yml

- name: 'Install nodenv'
  homebrew:
    name: 'nodenv'
    state: 'present'

と記載すればインストールが実現できます。

また、用意されているモジュールを使うことで、すでにインストール、設定済みでも

エラーにならずプロビジョニングが終了しますのでなるべく使えるモジュールがないか探しましょう。

PATHの通し方

構成の中でいくつかPATHを通す必要があり、bash_profileに環境変数のexportを記載する必要がでてきました。

# bash_profileに書きたい
export PYENV_ROOT="${HOME}/.pyenv"
export PATH=${PYENV_ROOT}/bin:${PYENV_ROOT}/shims:${PATH}

if [ -d "${PYENV_ROOT}" ]; then
    eval "$(pyenv init -)"
    eval "$(pyenv virtualenv-init -)"
fi

そのようなときに役立つのがinlinefileblockinlineです。

roles/dev-tools/tasks/python.yml

# inlinefile
- name: 'Add PATH'
  lineinfile:
    dest: '~/.bash_profile'
    line: '{{ item }}'
  with_items:
    - 'export PYENV_ROOT="${HOME}/.pyenv"'
    - 'export PATH=${PYENV_ROOT}/bin:${PYENV_ROOT}/shims:${PATH}'

# blockinline
- name: 'Setup pyenv-virtualenv'
  blockinfile:
    dest: '~/.bash_profile'
    block: |
      if [ -d "${PYENV_ROOT}" ]; then
        eval "$(pyenv init -)"
        eval "$(pyenv virtualenv-init -)"
      fi

のように呼び出すだけでbash_profileに冪等性を保ったまま、コンフィグを書き込むことができます。

inlinefileとblockinlineの違いは一行か複数行かということです。

blockinlineで複数行を記載するとblockの中身の順番が担保されます。

shell

モジュールが見あたらなく、プロビジョニングができないときは仕方なくshellモジュールを使うことができます。

roles/dev-tools/tasks/python.yml

- name: 'Install Python 3.6.1'
  shell: 'pyenv install 3.6.1'
  ignore_errors: yes

ただし、冪等性は保たれないため、すでに環境ができていた場合、エラーになってしまう可能性があります。

少し乱暴ですが、ignore_errors: yes を使うことでエラーがでても読み飛ばして次のタスクに進むことができます。

今回はignore_errors: yesした部分をServerspecで確認する形でOKとしてます。

変数の管理

変数を管理したくなったらvarsに記載することでtask側でも呼び出すことができます。

vars/main.yml

git:
  name: "foobar"
  mail: "hoge@example.com"

と記載し、

- name: 'Set git name'
  shell: 'git config --global user.name "{{ git.name }}"'

- name: 'Set git mail'
  shell: 'git config --global user.email "{{ git.mail }}"'

と宣言すれば利用できます。

playbookの設定

Ansible最後はplaybookです。

とはいったものの、roleとinventoryを紐付ければいいだけですので、

playbooks/my-mac.yml

- hosts: 'local'
  roles:
    - 'dev-tools'

とすれば出来上がりです。

これで

ansible-playbook playbooks/my-mac.yml

のように実行すればansibleの実行が可能です。

Makefileで一発実行

仕上げにMakefileをディレクトリルートに作り、煩わしいコマンドから解放されましょう。

Makefile

TARGET = $1
CD_ANSIBLE = cd ansible/${TARGET}
CD_SERVERSPEC = cd serverspec/${TARGET}

setup:
	@${CD_ANSIBLE} && \
	ansible-playbook playbooks/my-mac.yml

のように設定しました。

これで、

make setup TARGET=mac

で実行可能になりました。

結論

長くなったのでServerspecは次項で話します。

Ansibleはディレクトリが複雑なイメージがありますが、意味を理解すれば簡単です。

みなさまもMacの構成管理にトライしてみてください。

˚