初めてのAnsibleプレイブック作成

先日、Ansibleに関するふわっとした理解を書きたした。

blog.mtb-production.info

今回は、Ansibleの簡単なプレイブックを作ってみました。

そもそも、Ansibleのチュートリアルは色々ネットに出てるんですけど、結局なんか長くて、気になることが多くてモヤモヤしてしまう感じがありました。

というわけで、とりあえず今の理解で、簡単にプレイブックを作ってみようと思います。

やることは以下のような感じ。

• ansibleのクライアントはMac OS Xにする。（楽なので）
• ansibleのサーバーは、vagrantで用意する。（楽なので）
• ansibleでやることは、ユーザー作成だけにする。（とりあえず動かせることを確認したいので。）

まずは、Ansibleをインストールする。 そのために、venvでPythonのローカル環境を作って、pipでインストールしよう。

$ python3 -m venv ansible
$ . ansible/bin/activate
(ansible)$ pip install ansible
...（略）
Successfully installed MarkupSafe-1.0 PyYAML-3.12 ansible-2.4.0.0 asn1crypto-0.23.0 bcrypt-3.1.4 cffi-1.11.2 cryptography-2.1.1 idna-2.6 jinja2-2.9.6 paramiko-2.3.1 pyasn1-0.3.7 pycparser-2.18 pynacl-1.1.2 six-1.11.0
(ansible)$ ansible --version
ansible 2.4.0.0
  config file = None
  configured module search path = ['/Users/myuser/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /Users/myuser/work/ansible/lib/python3.6/site-packages/ansible
  executable location = /Users/myuser/work/ansible/bin/ansible
  python version = 3.6.1 (default, Apr  4 2017, 09:40:21) [GCC 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.38)]

なんかインストールできた様子。

よし、次に行こう。

vagrantで接続するサーバーを用意する。

(ansible) $ vagrant init ubuntu/trusty64
...略

(ansible) $ vagrant up
...略

(ansible) $ vagrant ssh
Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 3.13.0-110-generic x86_64)
...略

vagrant@vagrant-ubuntu-trusty-64:~$

とりあえず、構築するゲストOSが用意できた。

ここから、vagrantで立ち上げたゲストOSにsshで接続する。

まずは、vagrantで立ち上げたゲストOSにIPアドレスを付与するために、 Vagrantfile 設定を修正。（デフォルトの設定ファイルの中でコメントアウトされてるので解除する。）

config.vm.network "private_network", ip: "192.168.33.10"

そして、sshで接続するために、sshの設定を追記する。

~/.ssh/config に以下を追加した。 （鍵のパスは、 vagrant init したフォルダから見て .vagrant/machines/default/virtualbox/private_key にあったので、そこに通した）

Host 192.168.33.10
    IdentityFile /path/to/vagrant/private_key
    User vagrant

なお、設定はこの辺りを参考にさせてもらった。 VagrantでAnsibleのPlaybookを作るためのローカル環境を作る - Qiita

とりあえず、Ansibleで接続する前にターミナルからssh接続してみる。

$ ssh 192.168.33.10
Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 3.13.0-110-generic x86_64)

....
vagrant@vagrant-ubuntu-trusty-64:~$

接続できた。

次に、このゲストOSにansibleから接続できるようにする。 ansibleの場合、接続先は、inventryというファイルに書くらしいので、書いてみた。

(ansible) $ cat inventory
192.168.33.10

そのあと、Ansibleから疎通確認を行う。

(ansible) $ ansible all -i inventory -m ping
192.168.33.10 | SUCCESS => {
    "changed": false,
    "failed": false,
    "ping": "pong"
}

成功した様子。

よし。 プレイブックを作っていく。今回は、userを作りたいのでこのあたりを参考にする。

user - Manage user accounts — Ansible Documentation

ansibleのプレイブックの形式は、yamlというフォーマット。user.ymlを作った。

- hosts: all
  become: yes
  tasks:
    - name: make user
      user:
        name: sample_user

全てのホスト （hosts: all） で、sudo して（become）、sample_user を作るというymlのつもり。（少しこの辺りで試行錯誤した。）

これを実行する。

(ansible) $ ansible-playbook user.yml -i inventory

PLAY [all] *****************************************************************************************

TASK [Gathering Facts] *****************************************************************************
ok: [192.168.33.10]

TASK [make user] ***********************************************************************************
ok: [192.168.33.10]

PLAY RECAP *****************************************************************************************
192.168.33.10              : ok=2    changed=0    unreachable=0    failed=0

成功した様子。

ok=2 となっているのが気になる。 何回か試行錯誤してる中で、 ok=1　と出ている箇所もあるので、何かしらのOKの個数なのだと思うけど、何が2なのかは、わかっていない。

きちんとユーザができているか確認してみよう。

(ansible) $ vagrant ssh
Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 3.13.0-110-generic x86_64)
....

vagrant@vagrant-ubuntu-trusty-64:~$ sudo su sample_user
sample_user@vagrant-ubuntu-trusty-64:/home/vagrant$

ユーザはできている様子だった。

とりあえず、Ansibleで動かすことができるようになった。 次は、もうちょっと詳しいことをやりたい。

アジャイルサムライをちょっと読みました。１

アジャイルサムライを読んでいます。

今のところは、全体の５分の一くらいを読み進めています。

アジャイルサムライ−達人開発者への道−

今回も本を読んでいて個人的に後で見返したいことを箇条書きで書き出しておきました。

以下に書いてある内容に気になることがあった人は、実際の本を読むといいと思います。

• アジャイルの前提について
  • 完了とは、リリースして価値を届けること。作業を完了することではない。
  • 要求はプロジェクトの進行中に集めていくもの。
  • どうすれば要求を固定できるかではなく、どうすれば変化に対応できるか。
  • やるべきことは、常にリリースできることよりも多い。
  • やり方はたくさんあって、どれか一つを使えばいいという話ではない。
• アジャイルなプロジェクト
  • 役割が曖昧であり、肩書きも役割も関係がない状態になっている。
  • チームが成果に責任を負っている。
  • すべての工程が途切れずに連続する
• チームのアジャイル化について
  • 全員同じ仕事場に集めることはチームのアジャイル化を促進する
  • 顧客に積極的に関わってもらうことは、チームはアジャイル化を促進する
  • 顧客に積極的に関わってもらうために、問題を解決して、こまめに報告すること。
  • そして信頼の貯金を貯めること
• アジャイルプロジェクトの役割
  • 役割に人を合わせるのではなく、人に役割を合わせていくこと。
  • チームメンバーにソフトウェアを顧客に説明させること
  • 役割分担は、ざっくりいうと「何を作るか決める人」と「どうやって作るか決める人」に分かれる
• アジャイルプロジェクトを始めるにあたって
  • プロジェクトの最初の方で手強い質問をすること
  • 手強い質問をするために、インセプションデッキを構築すること
  • インセプションデッキは、プロジェクトがなんであるかを説明するものである。
  • インセプションデッキには、１０個の課題がある

今日はここまで。

djangoでjsonのレスポンスを返す方法

djangoでjsonのレスポンスを返す方法を探した。

同じことを今後もググるように思うので、ここに書いておきます。

なお、djangoのバージョンは、1.11.6です。古いと、ちょっと違ったような。

views.py に以下のように書く。

from django.http.response import JsonResponse

def json_view(request):
    return JsonResponse({"key":"value"})

すると、以下のように結果が返る。

{"key":"value"}

便利ですねえ。

アジャイルプラクティスを読んで得た教訓

アジャイルプラクティスと言う本を読んだ。ザッと。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

この本、2007年の本なんですね。

開発方法論、プロセス、プラクティス、システムとか、戦術的な話に興味があります。 で、アジャイルプラクティスという本を読みました。

読んでいて、雑多に個人的なメモをとっていたので、あとで自分が見返すために文章に整形して書いておきます。

前置きですが、他の人が読むとわかりにくいかもしれません。

以下が個人的に本に書いてある達人開発者の習慣を読んで僕が得た教訓です。

• 時間がかかっても正しいことをすること。
• 古い習慣があることに気づくこと。また、習慣という理由で採用しないこと。ただし、古いという理由で不採用にしないこと。
• 問題の根本を理解するまで質問すること。質問をする前に、その質問に意味のある根拠を考えておくこと。
• 設計は様々な選択肢を考えて話し合う場であることを理解すること。やったことのないことを厳密に定義しても意味がないことに気づくこと。コーディングに入ったら設計は白紙に戻ったと考えること。
• どんな設計になったか、どんな計画になったか、より、設計や計画をメンバーとともに行ったことが大切であることに気づくこと。
• 必要になるまで実装しないこと。作る前からどう使うかを考えること。
• 複雑さは、努力の成果ではないことに気付こう。良い設計は見ていて気持ちが安らぐものであることを知ろう。
• コードは少しずつ書くこと。常にコーディングをきれいにできないか考えること。
• オブジェクト指向は、オブジェクトに処理を命ずる、というのを理解すること。
• アーキテクトもコーディングをすること。設計はコーディングの段階で成長していく。アーキテクトがコーディングしないというのは成長機会を失っていることに気付こう。
• アーキテクトの仕事は、ソフトウェアから不可逆性を排除する方法を見つけて、アーキテクチャを取り除くということを理解すること
• コードを共有するときは段取りがあることを理解しよう。まず、週単位や月単位にコミットするのはおかしい。コミットは意味のあるまとまりですること。
• 人を責めても成果は出ないし、プロセスに従えば成果が出るわけでもないことに気付こう。そして、仕事は、人を責めることでもプロセスに従うことでもなく、成果をあげることであると気付こう。
• 自分が学んだことをチームに共有しよう。チームの身の丈にあった方法で情報教諭しよう。ほんとうにパワポが必要かを考えよう。

よし、書いた。

2007年の本だし、ちょっと話が古いなと思う部分もあると思うけど書いた。

ここに書いてあることなんて当たり前でしょ。と思うように成長していきたい気持ち。

factory_boyについての現状の理解を吐き出す

ここ２日くらい、しばらくぶりにユニットテストを書いている。と言っても、そもそもユニットテストを書いた経験は少ないので、ユニットテストってどう書くんだっけ。と言うところからの再開だった。

開発は、いつものようにPythonとdjangoで、ユニットテストを書く中でfactory_boyを使っている。その中でfactory_boyってなんだっけ、となった。少し期間が空くと忘れてしまう。前も同じような疑問をもった記憶があるし、思い出すのに時間がかかったり、時間短縮のために再び人に聞いたり、と、なかなか効率が悪い感じがある。一回やったことは、二回目以降にサクッと思い出してサクサク進めたい。

と言うわけで、次に使うときにサクッと思い出せるように今の理解を書き出しておこうと思う。

• factory_boyは、ユニットテストを書くときに便利。
  • factory_boyは、factoryパターンのクラスを作るための抽象クラスのライブラリ
  • factory_boyを使うとdjangoのmodelにfactoryパターンを適用できる
    • factoryパターンを適用すると、インスタンスの生成とインスタンスの属性や振る舞いを切り離せる。
    • 要するに、インスタンスのテンプレが作れるような感じ。
  • factory_boyを使うと、ユニットテストがデータベースの変更に強くなる。
    • factory_boy（と言うかfactoryパターン）を使わずにユニットテストを書いていると、データベースのカラム追加の時とか辛くなる。
    • 例えば、djangoでデフォルト値の無い、nullが許可されてないカラムを追加すると、そのモデルを使ってテストしてる部分を全体的に修正することになる。辛い。
    • 事前に作ったテストデータを使ってる時はそのテストデータも修正が必要になって、さらに辛い。
  • factory_boyを使うと、楽にテストデータを作れる。
    • 例えば、別のテーブルと依存関係をもつデータを作るとき、依存先のテーブルに参照するデータがないと、データを作れない。ユニットテストのテストケース１つ１つに対して、毎回作るのはわかりと辛い。factory_boyで、依存先のデータを勝手に作るテンプレを書いておけば、あとは勝手にテンプレを作るようにできる。
    • あと、文字列を自動で生成して、レコードを増やすようなのも楽にできる。factory_boyで、ランダム文字列を生成して属性につめるように書いておけばよい。
    • 最新のドキュメントを読むと、build_batchというメソッドを使って、一括で大量のデータを作ることもできる様子
  • データベースの変化に強いユニットテストを作るためにfactory_boyは便利。
    • 逆にほとんどデータベースが変化しないようなシステムでfactory_boyは必要か？と言われると、別に必要ではない。
    • そもそもfactory_boyは、必要かどうかの話ではなくて、使っておくと便利になる。という話。
    • そして、factory_boyそのものを導入するのはそこまで難しくないし、システムがほとんど変化しないとしても、RDBを使ってリレーションが複雑になるならfactory_boyを使っておく方が開発の効率は上がる。今のところ、あんまりいれない理由は思い浮かんでいない。

今日のところの理解はこんな感じです。

Ansibleって結局なんなんや。と思ってた話

コードのインフラ化をあんまりよくわかっていない。もっと理解を深めたい。 それで、Ansibleって結局、何なの？って思ってた。 というか、Ansibleと同じ時期に、vagrant、Docker、docker-compose、fabric、terraformあたりを知ることになり、混乱が加速した。こいつら何が違うんだ！というのが僕の想いだった。

とりあえず、今日はAnsibleが何なのか、という部分の理解がだいぶ進んだ。というわけで、今のところの理解を書いておく。

• Ansibleは、サーバーの構築を支援してくれる何か。

  • Ansibleは、サーバーを構築するために使えるコマンドを冪等性を考えてモジュール化しようとしている何か。
  • 冪等性というのは、何回実行しても、同じ状態になる性質のこと。１回デプロイしても、２回デプロイしても、同じ状態になる、ということ。
  • Ansibleは、サーバーを構築する時に必要な情報を整理するためのフレームワークも含んでいる何か。
  • Ansibleは、Ansibleの書き方（yml）で書いている構築用のコマンドをシェルで実行していくだけ。
  • Ansibleは、サーバーの状態を定義しないこともできる。Ansibleを使ったから、必ずサーバーが同じ状態になるわけではない。Ansibleが触らないファイルや設定を手作業で修正したら、それはそのまま残る。
  • Ansibleでコード化した後に残るのは、デプロイの時に何をやるか、の流れ。

• Ansibleは、サーバーそのものの用意はできない。OSのインストールとかもできない。ハードウェアの設定もできない。

  • Ansibleでは、Vagrantのboxのようにサーバーのイメージがあるわけではない。VirtualboxのようにOSイメージがあるわけでもない。Ansibleは、構築（デプロイ）の時にやることを整理する環境とツールが用意されているだけ。イメージは何もない。
  • 例えば、AWSのEC2でアプリケーションサーバーを作る時には、Ansibleの活躍は、AWSのEC2インスタンスを作ってssh接続できるようにしてから。
  • Ansibleがインスタンスを作ることはできない。
  • Ansibleでは、sshで接続した後にやっていく作業を、手順にまとめていくことができる。それがプレイブックと呼ばれる。

• Ansibleは、インフラエンジニアが、インフラをコード化する時の障壁を軽減する。

  • おそらく、Ansibleがないときは、次のよう話があったと思う。

    • 「インフラの構築をスクリプト化したい」→「シェルスクリプトで書けば？」→「もっとモダンな言語で書きたい」
    • 「インフラの構築をモダンな言語でスクリプト化したい」→「Chefで書くぞお！」→「僕、RubyわからないしChef、よくわからないんですけど。（ChefはRubyライクな書き方をする）
    • 「インフラの構築をモダンな言語でスクリプト化したい」→「僕はfabricでデプロイするぞお！」→「僕、Pythonわからないしfabricもよくわからないんですけど。」

  • そんな中で、Ansibleが登場した。

    • なんかよくわからんけど、ymlっていう優しい書き方をしている。
    • インフラエンジニア的には、PythonでもRubyでもPHPでもないので平和だし、どれを使う会社にいってもスムーズに使えるから、楽。
    • 構築する時に実行可能な各モジュールのインターフェースがymlで記述するフォーマットに統制されていて、考えることが減った。
    • 各モジュールでインフラのコード化をする時に、障壁になる冪等性の考慮をしやすいインターフェースになっている様子。
    • バックグラウンドがPythonコミュニティだからか、ドキュメントがすごく豊富。
    • Ansibleいいじゃん！！

というわけで、Ansibleが普及した。

なおAnsibleが登場したに書いてあることは僕の予想です。

ボリュームがあって、やる気が出ない時にやる気を出す質問

Pythonの公式ドキュメントを読もうと思ってました。でもボリュームが多くて、なかなかやる気になりませんでした。

こないだ先輩に言われた質問をぶつけて考えて見たら、読む気になってきたのでその話を書きます。

概要

• 具体的なPythonの話は出てきません。
• こうやったら読む気になった話が書いてます。
• やりたいことはあるけど、実際にやる気にならないことがある人に役に立つ話です。

内容

以下のような流れで考えが進んだらやる気が出ました。

1. Python公式ドキュメント読もうと思った。
2. Python公式ドキュメントのトップページを見た。
3. 量が多くてやる気でないと思った。
4. どこを読んだ方がいいか考えたら、ほとんど全部読んだ方がいいと思った。
5. 正直、全部は読むのしんどいと思った。
6. 逆に１つしか読めないならどこを読むか考えてみた。
7. 個人的には言語リファレンスを読みたいと思った。
8. あとのやつは、言語リファレンスが読み終わった後に考えることにした。

太字の場所がポイントです。

まとめ

やりたいことがたくさんあったり、やろうとしてることが大きい場合、着手するにはエネルギーが必要です。

でも、そのたくさんのやる事のうち、１つしかできないならどれをやるか？と考えてみると、着手して前に進めることができます。

おそらくいろんなことにも応用できると思うので、応用していきたいと思います。