How to spend bad holidays of the weather
My Family likes sing at karaoke but That is prohibited in Tosu-shi, Saga. So My Family does karaoke using Joy Sound of PS3 in a house.

izzy's playlists!
Show & Tell

No title available

No title available
YOU ARE THE REASON

祝日 / Permanent Vacation
Alisa U Zemlji Chuda

⁂
noise dept.
Sade Olutola

Discoholic 🪩
wallacepolsom
$LAYYYTER
i don't do bad sauce passes
Aqua Utopia|海の底で記憶を紡ぐ
we're not kids anymore.

tannertan36
KIROKAZE

PR's Tumblrdome
h

seen from Israel

seen from Malaysia

seen from United States
seen from Germany
seen from United States

seen from Canada

seen from United States

seen from Malaysia

seen from Germany

seen from Spain
seen from United States

seen from Germany

seen from Germany

seen from Germany

seen from Malaysia

seen from United States
seen from Malaysia

seen from Serbia
seen from Brazil
seen from Germany
@tshst
How to spend bad holidays of the weather
My Family likes sing at karaoke but That is prohibited in Tosu-shi, Saga. So My Family does karaoke using Joy Sound of PS3 in a house.
Happy New Year 2018
The same as last year, I was able to see the sunrise on New Year's Day. I hope this year will be a good year too.
My Goals for 2018
Taking 600 points in TOEIC
Writing a blog in English every week
Writing code in Python three times a week
I don't like to continue but I continue to make an effort.
Ansibleでwindowsを操作する
対象
windows server 2012 R2(GCPのイメージ)
環境
python 3.5.2 / ansible 2.3.1 / pywinrm 0.2.2
事前確認
windowsをansibleで操作する場合、windowsのwinRMサービスが起動している必要があるため、サービスが利用できる状態か確認を行う
サービスが起動していても、ファイアウォールで閉じられていたら接続できないので、winRMが使用するポートhttp(5985), https(5986) が接続できる状態にあるか確認を行う
Basic認証の許可
デフォルトでは、winrmではBasic認証は許可されていないため、許可しておく
PowerShellを管理者権限で起動し、以下のコマンドを実行する
Set-Item -Path "WSMan:\localhost\Service\Auth\Basic" -Value True
設定の確認は以下のとおり、"Set"を"Get"に変えて、Value以降を削除するとOK
Get-Item -Path "WSMan:\localhost\Service\Auth\Basic"
windows server の設定に関しては、こちらの記事で紹介されている通り、スクリプトをダウンロードして実行するでも良いかと思います
pythonのmoduleインストール
ansibleからwinRMへ接続するために、 「pywinrm」をインストールする
求められるバージョンは、pywinrm >= 0.2.2
pip install pywinrm
インベントリの追加とgroup_varsの設定
hosts(インベントリ)
[windows] 104.198.117.44 [windows:vars] ansible_user=xxxxxxxxx ansible_password=xxxxxxxxxxxxx ansible_port=5986 ansible_connection=winrm ansible_winrm_server_cert_validation=ignore
接続テスト
ansible windows -i inventories/hosts -m win_ping -vvv
ansible 2.3.0だとbytesとstringに関するエラーがでる
ここに記載の通りで、win_pingのバグということで、ansibleを2.3.1にupgradeして解決
どうしてもうまくいかない場合は、windows serverの再起動をオススメします。
実行結果
META: ran handlers Using module file /Users/tshst/.anyenv/envs/pyenv/versions/3.5.2/lib/python3.5/site-packages/ansible/modules/windows/win_ping.ps1 <104.198.117.44> ESTABLISH WINRM CONNECTION FOR USER: xxxxxxxxx on PORT 5986 TO 104.198.117.44 EXEC (via pipeline wrapper) 104.198.117.44 | SUCCESS => { "changed": false, "ping": "pong" } META: ran handlers META: ran handlers
簡単なplaybook
どんなことができるかは、こちらのモジュール一覧を見てみてください
それ以外にも、PowerShellでできることはなんでもできそうな気がしますが、今のところ学ぶ気にはならないですw
group_varsに変数をまとめて記載する
先程、hostsに記載していた内容を新規作成したgroup_vars/windows.ymlに記載する
管理上やっているだけで、特にやらなくても動くと思います
ホスト名を変更する
ansibleディレクトリ直下に以下の内容で、windows.ymlファイルを作成する
--- - name: windows hostname setting hosts: windows gather_facts: false tasks: - win_domain_membership: domain_admin_user: "{{ ansible_user }}" domain_admin_password: "{{ ansible_password }}" workgroup_name: hoge hostname: hogemoge state: workgroup register: domain_state - win_reboot: when: domain_state.reboot_required
動作確認
% ansible-playbook -i inventories windows.yml -vvv Using /Users/tshst/OneDrive/src/github.com/tshst/develop/ansible/ansible.cfg as config file PLAYBOOK: windows.yml ********************************************************************************************************************************************************************************************************************************************** 1 plays in windows.yml PLAY [windows hostname setting] ************************************************************************************************************************************************************************************************************************************ META: ran handlers TASK [win_domain_membership] *************************************************************************************************************************************************************************************************************************************** task path: /Users/tshst/OneDrive/src/github.com/tshst/develop/ansible/windows.yml:6 Using module file /Users/tshst/.anyenv/envs/pyenv/versions/3.5.2/lib/python3.5/site-packages/ansible/modules/windows/win_domain_membership.ps1 <104.198.117.44> ESTABLISH WINRM CONNECTION FOR USER: tshpaper on PORT 5986 TO 104.198.117.44 EXEC (via pipeline wrapper) changed: [104.198.117.44] => { "changed": true, "reboot_required": true } TASK [win_reboot] ************************************************************************************************************************************************************************************************************************************************** task path: /Users/tshst/OneDrive/src/github.com/tshst/develop/ansible/windows.yml:14 <104.198.117.44> ESTABLISH WINRM CONNECTION FOR USER: tshpaper on PORT 5986 TO 104.198.117.44 EXEC (via pipeline wrapper) attempting post-reboot test command 'whoami' <104.198.117.44> ESTABLISH WINRM CONNECTION FOR USER: tshpaper on PORT 5986 TO 104.198.117.44 EXEC (via pipeline wrapper) changed: [104.198.117.44] => { "changed": true, "rebooted": true, "warnings": [] } META: ran handlers META: ran handlers PLAY RECAP ********************************************************************************************************************************************************************************************************************************************************* 104.198.117.44 : ok=2 changed=2 unreachable=0 failed=0
リモートデスクトップで接続した状態で、実行すると再起動の処理の後に、強制再起動されて、「おー」となるので、おすすめです!
『ゆとりの法則』を読んで
きっかけ
この本に出会ったきっかけは、はっきりと覚えていないのだけど、スライドシェアを見ている中で紹介されていた。この本を読みたいと思ったのは、6月から新しい職場で2ヶ月振りに働くにあたり、前職で時間に追われていたのを思い出したから。何かヒントが得られるといいな〜と思い購入した。
ゆとりの法則 - 誰も書かなかったプロジェクト管理の誤解
特に興味をもった内容について
忙しさよりビジネスを 『ゆとりとは、変化に投資する手段である』読めば納得できるんですが、今までそういった視点で考えたことも無かったので、とても参考になりました。今の時代、変化にどれだけ柔軟に対応できるかがビジネスでは重要だと思うのですが、ある一定の人材だけが対応できてもあまり意味はなく、全員がそのように対応できるべきで、それを実現するために『ゆとり』が必要なんだと思いました。
変化のタイミング 『変化を導入するのにはるかに適した時期は、健全に成長している期間である』本書ではグラフをもとに説明されており、成長期を越えて下り坂になってきてから慌てて変化を導入しようとしては抵抗勢力が多すぎてダメだと。なぜ、健全に成長している時に変化を導入するべきかという理由が、『導入しやすいから』だった。私的には、健全に成長している時の方が『ゆとり』があり、変化を受け入れやすい状態にあるって事なのではないかと勝手に理解しました。
中間管理職の存在意義 中間管理職だったので、とても興味があった。それこそ存在意義ってなんだろう?と日々考えてました。本書では、『中間管理職の重要な役割は、再生である』と書かれてました。なぜか?変化は中間層で起こり、再生に必要な「有意義な変化を計画して、実行すること」は中間管理職にしかできないから。そういった役割を中間管理職に求めている企業がどれだけあるのか。求められなくても、次はそういった事を意識してやっていこうと思った。
全体を通して
この本自体は2001年に発売されたものだが、内容自体は今の時代でも十分に通用すると感じた。問題点提起では共感することが多く、解決に向けた考え方や方法などが記載されているので、多くのヒントを得ることができた。具体例をもとにいろんな角度でプロジェクト管理に必要な要素について書かれており、数値化できる部分は可能な限り数値化されているので、読んでいてすごく説得力があった。現在管理する立場にある方やこれから管理する方におすすめの本です。
Ansible実行環境をAnsibleで構築する
この記事でやること
Ansibleの実行環境をGCEに作成する
GCE Dynamic Inventoryを使用して環境構築を行う
GCEインスタンスの準備
事前準備
認証情報の渡し方は、前回のブログの中の secrets.pyファイルを利用する で行います
ansible-playbook実行前にsecres.pyへのPATHを環境変数で指定する必要があります
使用しているシェルの設定ファイルに追加しておくのが手間が省けてよいかと思います
export PYTHONPATH=/Users/tshst/credentials
GCEインスタンス用のPlaybookを作成する
以下の内容を gce-create-server.yml 等Playbookとして .yml ファイルに保存する
--- - name: create instance hosts: localhost connection: local gather_facts: no vars: machine_type: f1-micro image: centos-7-v20170426 zone: asia-northeast1-a state: present vars_prompt: - name: "iname" prompt: "Please input create instance name." private: no confirm: no - name: "state" prompt: "Please input state of instance." default: present private: no confirm: yes tasks: - name: ansible server create instance gce: instance_names: "{{ item }}" machine_type: "{{ machine_type }}" image: "{{ image }}" zone: "{{ zone }}" state: "{{ state }}" tags: "{{ tname }}" metadata: '{"sshKeys":"ansible:ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNyQh5SbMsOnzUvsRbwl9mrv8ztmcGjH4o8lMBN8DDXNmIxSGQ9j1/jd9In6OHa1pVmgSx7A1B6fdY37dXgPZprrMwr55/dRNM1FcX4RtJCVQDrDOdGnm/Osl1Y7us4woP3sghxF5WxICbN0io0y7N6U3VrQl1Oaf4n3K3CCVBcAnawrK/8aClQ2gQtyVuCY5vKUrXxWOqDVyOkNyKq6ZValWV6Uos3bRrusAjuXyh3fj4TsvIy4x11hIYfdqdklU+Q0z/3KzYcHGDVuQqaMDgBRaorSiBIihLfEOpVVkyBFg7MQGflX//BYnf1XAoyHSMUD/gagGy0swdQIGSM5jR ansible"}' with_items: - "{{ iname }}"
補足
vars_prompt は変数をプロンプトで入力するための設定
1個のPlaybookでいろんなサーバを作りたかったのと、--extra-varsでの指定のほうが面倒そうだったので使っている
作成だけでなく、その他のステータスも柔軟に指定したかった(頻繁に削除することが多かった)ので、stateも vars_prompt を使っている
instance_namesの取得にループ処理(with_items)を使っているのは、複数の同一roleのサーバを同時に構築するため
metadateでインスタンス作成時にsshの公開鍵を登録しているのは、以降のインスタンス作成後にリモートサーバに対してansibleを実行するため
tname については、グローバル変数として使用したかったので、Playbook内で変数は指定せず、 コマンドプロンプトから、 --extra-vars で指定するようにしている
GCEインスタンスの作成
ansible-playbook gce-create-server.yml --extra-vars='{"tname": "ansible"}'
Dynamic Inventoryの準備
gce.pyとgce.iniの取得
ansibleの本体に含まれているので、ansibleのリポジトリをクローンする
ghqの場合
ghq get https://github.com/ansible/ansible.git
gitコマンドの場合
git clone https://github.com/ansible/ansible.git
contrib/inventory配下に該当のファイルがあるので、ansibleのymlファイル等があるディレクトリの同じ階層にでもコピーする
私の環境では、Dynamic Inventoryと通常のInventoryを両方扱いたいため、 inventories ディレクトリを作成して、そのディレクトリ配下にコピーしている
コピーするファイルのパス(以下は、私の環境でのパスになります)
$ ls -l ~/OneDrive/src/github.com/ansible/ansible/contrib/inventory/gce* -rw-r--r-- 1 tshst staff 3025 Apr 29 13:52 /Users/tshst/OneDrive/src/github.com/ansible/ansible/contrib/inventory/gce.ini -rwxr-xr-x 1 tshst staff 18013 Apr 29 13:52 /Users/tshst/OneDrive/src/github.com/ansible/ansible/contrib/inventory/gce.py
ansibleディレクトリの構成(抜粋)
├── ansible-server.yml ├── ansible.cfg ├── inventories │ ├── gce.ini │ ├── gce.py │ └── hosts
gce.iniファイルの変更
gceインスタンス作成時にも使用した secrets.py ファイルのパスをファイル名も含めて libcloud_secrets に指定する
libcloud_secrets = /Users/tshst/credentials/secrets.py
gce.pyの修正
python3では、ダウンロードしたファイルをそのまま使用することができなかったため、python3で使用できるように修正する
修正内容
修正後のファイル
動作確認
listオプションを付けてスクリプトを実行
./inventories/gce.py --list
以下のとおりインスタンスの値が取得できればOKです
{"centos-7-v20170426": ["ansible001"], "status_running": ["ansible001"], "f1-micro": ["ansible001"], "asia-northeast1-a": ["ansible001"], "_meta": {"stats": {"inventory_load_time": 0.8180139064788818, "cache_used": false}, "hostvars": {"ansible001": {"ansible_ssh_host": "35.187.223.200", "gce_uuid": "deffc7e3b4051481ff7bb97219ded46ad8f4138c", "gce_id": "5037858432732860749", "gce_network": "default", "gce_image": "centos-7-v20170426", "gce_private_ip": "10.146.0.2", "gce_machine_type": "f1-micro", "gce_tags": [], "gce_status": "RUNNING", "gce_public_ip": "35.187.223.200", "gce_zone": "asia-northeast1-a", "gce_description": null, "gce_metadata": {}, "gce_subnetwork": "default", "gce_name": "ansible001"}}}, "network_default": ["ansible001"]}
Ansible実行環境のPlaybook作成
ファイルとディレクトリ構成について
├── gce-create-server.yml # 基本となるPlaybookファイル ├── inventories # インベントリのディレクトリ │ ├── gce.ini # DynamicInventory用の設定ファイル │ ├── gce.py # DynamicInventoryスクリプト │ └── hosts # 通常のインベントリファイル ├── roles # roleディレクトリ │ ├── ansible # ansible環境構築用のroleディレクトリ │ │ ├── tasks │ │ │ └── main.yml │ ├── base # インスタンス作成後にOSの基本的な設定やパッケージのインストールを行うroleディレクトリ │ │ ├── tasks │ │ │ └── main.yml │ ├── base-gcp # インスタンス作成時にgcp側の基本的な設定を行うためのroleディレクトリ(firewall設定とか) │ │ ├── tasks │ │ │ └── main.yml
roleディレクトリの作成
ansible-galaxy init --init-path="roles" ansible ansible-galaxy init --init-path="roles" base ansible-galaxy init --init-path="roles" base-gcp
先程作成したgceインスタンス作成のPlaybookを以下のように修正する
--- - name: create instance hosts: localhost connection: local gather_facts: no vars: machine_type: f1-micro image: centos-7-v20170426 zone: asia-northeast1-a state: present vars_prompt: - name: "iname" prompt: "Please input create instance name." private: no confirm: no - name: "state" prompt: "Please input state of instance." default: present private: no confirm: yes tasks: - name: ansible server create instance gce: #instance_names: "{{ hostname }}" instance_names: "{{ item }}" machine_type: "{{ machine_type }}" image: "{{ image }}" zone: "{{ zone }}" state: "{{ state }}" tags: "{{ tname }}" metadata: '{"sshKeys":"ansible:ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNyQh5SbMsOnzUvsRbwl9mrv8ztmcGjH4o8lMBN8DDXNmIxSGQ9j1/jd9In6OHa1pVmgSx7A1B6fdY37dXgPZprrMwr55/dRNM1FcX4RtJCVQDrDOdGnm/Osl1Y7us4woP3sghxF5WxICbN0io0y7N6U3VrQl1Oaf4n3K3CCVBcAnawrK/8aClQ2gQtyVuCY5vKUrXxWOqDVyOkNyKq6ZValWV6Uos3bRrusAjuXyh3fj4TsvIy4x11hIYfdqdklU+Q0z/3KzYcHGDVuQqaMDgBRaorSiBIihLfEOpVVkyBFg7MQGflX//BYnf1XAoyHSMUD/gagGy0swdQIGSM5jR ansible"}' with_items: - "{{ iname }}" register: gce - name: Wait for SSH come up wait_for: host: "{{ item.public_ip }}" port: 22 delay: 10 timeout: 60 with_items: "{{ gce.results[0].instance_data }}" when: state == "present" - name: Add host to groupname add_host: hostname: "{{ item.public_ip }}" groupname: "{{ tname }}" with_items: "{{ gce.results[0].instance_data }}" when: state == "present" roles: - base-gcp - name: base role and "{{ tname }}" role exec hosts: "{{ tname }}" connection: ssh become: True remote_user: ansible roles: - base - "{{ tname }}"
Ansible実行環境のRole作成
先程作成したRoleをそれぞれ作成していく
base(インスタンス作成後にOSの基本的な設定やパッケージのインストールを行うroleディレクトリ)
今回は特に設定はしない
今後共通でインストールするパッケージが出てきたらその際に追加する
ansible(ansible環境構築用のroleディレクトリ)
今回のメインのRole
ansible/tasks/main.yml
--- # tasks file for ansible - name: install rpm packages yum: name: "{{ item }}" state: present with_items: - git - "@Development Tools" - readline-devel - zlib-devel - bzip2-devel - sqlite-devel - openssl-devel - name: git clone become: False git: repo: "{{ item.repo }}" dest: "{{ item.dest }}" with_items: - repo: git://github.com/yyuu/pyenv.git dest: /home/ansible/.pyenv - repo: git://github.com/tshst/develop.git dest: /home/ansible/develop - name: bashrc upload become: False copy: src: files/bashrc dest: ~/.bashrc - name: check python installed vars: python_version: 3.5.2 stat: path: "/home/ansible/.pyenv/versions/{{ python_version }}/bin/python" register: present_python - name: python install become: False vars: pyenv_root: /home/ansible/.pyenv python_version: "3.5.2" environment: PYENV_ROOT: "{{ pyenv_root }}" PATH: "{{ pyenv_root }}/bin:{{ ansible_env.PATH }}" shell: "{{ item }}" args: chdir: /home/ansible with_items: - "pyenv install {{ python_version }}" - "pyenv global {{ python_version }}" when: present_python.stat.exists == False - name: ansible install become: False vars: pyenv_root: /home/ansible/.pyenv environment: PYENV_ROOT: "{{ pyenv_root }}" PATH: "{{ pyenv_root }}/shims:{{ ansible_env.PATH }}" pip: name: "{{ item }}" state: present with_items: - ansible - apache-libcloud - name: secrets file upload become: False copy: src: ~/credentials/ dest: ~/credentials - name: mode change of secrets file become: False file: path: ~/credentials/secrets.py mode: "u+x,g+x,o+x" - name: secrets file replace become: False replace: dest: ~/credentials/secrets.py regexp: 'Users/tshst' replace: 'home/ansible'
各タスクについての説明と補足は以下の通りです
name: install rpm packages
pythonインストール(build)に必要なパッケージとpyenvインストールのためのgitをyumでインストール
name: git clone
git cloneでpyenvのインストールと、自身のansibleのベースディレクトリをインストール
ansibleユーザの権限で用意したいため、 become: False にしています
name: bashrc upload
pyenvの環境を整えるためにbashrcをアップロード
bashrcの中身は以下の通り環境変数の設定のみです
# pyenv setting export PYENV_ROOT="${HOME}/.pyenv" if [ -d "${PYENV_ROOT}" ]; then export PATH=${PYENV_ROOT}/bin:$PATH eval "$(pyenv init -)" fi # ansible credentials setting export PYTHONPATH=~/credentials
name: check python installed
pythonがインストールされているか事前に確認
pythonがインストールされている状態だとディレクトリが存在するというエラーを回避するために設定
register に設定した変数にチェックコマンドの実行結果を入れて、以降のタスクで利用している
name: python install
pythonのインストール
pythonがインストールされていないときのみ実行される
shellモジュールを使って、pyenvコマンドでインストールしている
enviromentはpyenvへのPATHがどうしてもうまく通らなかったために設定を行っている
chdirについては、pyenv local した場合に必要になりそうと思い設定したままになっている
name: ansible install
pipでansibleとapache-libcloudをインストール
enviromentはpipへのPATHがどうしてもうまく通らなかったために設定を行っている
name: secrets file upload
GCPの環境でansibleを実行するためのファイルをアップロード
name: mode change of secrets file
secrets.pyは実行権限が必要なため設定を行っている
directory_mode の設定でディレクトリを再帰的にコピーしようとしたが、以下のエラーが発生したため権限を付与するタスクを1個追加して
mode must be in octal or symbolic form
name: secrets file replace
必要に応じてsecrets.pyの設定を変更
私の場合は、ローカル環境で使用している同じファイルを使用しているため、アップロード後にインスタンス上のパスに変更している
Ansibleサーバの構築
--extra-vars にtag名を指定して実行
構築(present)したいインスタンス名を入力後、Enterを2回押します(defaultはpresent)
2回実行するのは、削除時(absent)を入力する際にオペレーションミスの発生頻度を落とすためです
% ansible-playbook -i inventories ansible-server.yml --extra-vars='{"tname": "ansible"}' Please input create instance name.: ansible01 Please input state of instance. [present]: confirm Please input state of instance. [present]:
実行結果
PLAY RECAP ******************************************************************************************************************************************************************************************************************************************************************* 35.190.231.92 : ok=10 changed=8 unreachable=0 failed=0 localhost : ok=4 changed=3 unreachable=0 failed=0
課題
まだまだ個人の環境に依存する記述があるので、もっと一般化したい
重複している変数があるので、それぞれRoleの vars あたりにまとめる
いろんなRoleを増やしていく
シンプルで汎用性のあるものを作るって難しい
AnsibleでGCEインスタンス作成
AnsibleとGCP
この記事では、Ansibleを使ってGCPのインスタンスを作成します
環境準備
AnsibleのGCPのドキュメント
これをベースに環境を用意していきます。
この環境で使用しているPythonとAnsibleのバージョンは以下の通りです
Python: 3.5.2
Ansible: 2.3.0.0
apache-libcloudのインストール
gceモジュールが apache-libcloud ライブラリを使用するためインストールします
% pip install apache-libclou Collecting apache-libcloud Downloading apache_libcloud-2.0.0-py2.py3-none-any.whl (4.5MB) 100% |████████████████████████████████| 4.5MB 197kB/s Collecting requests (from apache-libcloud) Downloading requests-2.13.0-py2.py3-none-any.whl (584kB) 100% |████████████████████████████████| 593kB 1.1MB/s Installing collected packages: requests, apache-libcloud Successfully installed apache-libcloud-2.0.0 requests-2.13.0
GCPのGUIでサービスアカウント作成と証明書のダウンロード
サービスアカウントの作成(service_account_email)
鍵の作成と証明書のダウンロード(credentials_file)
鍵の作成
作成語自動でファイルがダウンロードされる
ダウンロードされたファイルは以下の credentials_file として使用する
各種ファイルの準備
認証に必要なファイルを ~/credentials ディレクトリにまとめる
サービスアカウントの証明書ファイル(credentials_file)
ダウンロードされたファイルを ~/credentials に移動する
cacertファイル
MacOSでansibleを使っている場合に限る
ここから cacert.pem をダウンロード
~/credentials のディレクトリ構成
/Users/tshst/credentials ├── ansible-42861101992b.json ├── cacert.pem └── secrets.py
認証情報をAnsibleに渡す方法は3つある
GCEモジュールに引数として認証情報を渡す
secrets.pyファイルを利用する
環境変数を使って、モジュールに認証情報を渡す
以下でそれぞれの方法でGCEのインスタンスを作成してみる
GCEモジュールに引数として認証情報を渡す
playbookの vars に値を設定する
以下通り gce.py という名前でplaybookを作成する
--- - name: create instance hosts: localhost connection: local gather_facts: no vars: service_account_email: [email protected] credentials_file: /Users/tshst/credentials/ansible-42861101992b.json project_id: decoded-vision-166013 machine_type: f1-micro image: centos-7-v20170426 zone: asia-northeast1-a state: present tasks: - name: launch instances gce: instance_names: sample service_account_email: "{{ service_account_email }}" credentials_file: "{{ credentials_file }}" project_id: "{{ project_id }}" machine_type: "{{ machine_type }}" image: "{{ image }}" zone: "{{ zone }}" state: "{{ state }}"
実行結果
secrets.pyファイルを利用する
secrets.pyの作成
GCE_PARAMS = ('[email protected]', '/Users/tshst/credentials/ansible-42861101992b.json') GCE_KEYWORD_PARAMS = {'project': 'decoded-vision-166013'}
作成したファイルは以下で設定するPYTHONPATHで指定するディレクトリ配下に設置する
secrets.pyのPATHの設定
export PYTHONPATH=/Users/tshst/credentials
ディレクトリはどこでも問題ない
gcp.ymlの修正 設定されていて問題になることはないと思うが、 secrets.py の動作確認のため、削除しておく
削除した状態
実行結果
環境変数を使って、モジュールに認証情報を渡す
認証情報を環境変数に入れる
export [email protected] export GCE_CREDENTIALS_FILE_PATH=/Users/tshst/credentials/ansible-42861101992b.json export GCE_PROJECT=decoded-vision-166013
secrets.pyをへのPATHを設定した環境変数を動作確認のために削除しておく
$ export PYTHONPATH= $ echo $PYTHONPATH $
実行結果
Ansible徹底入門輪読もくもく会 #1で発表してきた
発表資料
感想
#0 の参加に続いて2回目です。 前回参加した時に「Ansible徹底入門」は持っておらず、じゃんけんで勝った人1名にプレゼントだったのですが、 見事に勝ちまして、本書で学んだことを今回アウトプットしました。 参加者はクラウドをメインに使っていらっしゃる方々が多く、オンプレをメインにやっていた私からすると、参加して話を聞いているだけで勉強になります。 まだまだAnsibleについては初心者の域を出ないので、これから日々学んでいこうと思います。 発表の中で書いた「もっと便利にできそう」という部分は、アーキテクチャの案はあるので、検証環境作っていきたいと思います。 毎回場所を提供頂いているオルターブースさんには感謝です。
CIRASUではインフラ技術について勉強会を開催しているので、 Ansibleに限らずインフラ周りの技術に興味のある方はぜひ参加してみてください。 いろんな知見が得られると思います。
次回までには見せれるものを作るぞ!
Ansibleに再入門した話
Ansible徹底入門
再入門の経緯
Ansible徹底入門 輪読会 #0 に参加させて頂いた際に、じゃんけんで見事勝ちまして本書を頂ける事になりました。今までは、 puppet を使う機会が多く、Ansibleに関しては、一時的な作業で使用する事が主でした。作業を終わらせる事が目的なので、その作業に必要なAnsibleの知識をサイトで調べて利用してました。なので、Ansibleの特徴でもある 冪統制 などは全く考えた事がなく、また、Ansibleに関する知識がすごく断片的になっていました。本を頂いたのも何かの縁だと思うので、これを機に基礎をきっちり身に付けようと思ったのが、Ansibleへの再入門の経緯です。
本書の構成
CHAPTER 1 - 4 : Ansibleのインストールからnginxをインストールして起動するまでの基本的なAnsibleの技術的な構成要素についての解説
CHAPTER 5. : CHAPTER1-4の集大成として、wordpress環境をansible-playbookで構築する
CHAPTER 6 - 9 : 各種パブリッククラウドにおけるAnsibleの活用事例
CHAPTER 10. : Ansibleにおけるテスト
感想
CHAPTER 1 - 4 まで読了しての感想です。今まではAnsibleについて知っていたので、インストール部分はさらっと流しましたが、主要なOSすべてについて説明されていて、丁寧に書かれている印象を受けました。また、本だけ読むのではなく、実際に手を動かしながら進める事ができる構成になっていたので、なるほど!と体験しながら進める事ができて理解が深まったと実感してます。これからAnsibleを始めたいと考えている方や私のように再入門したいなと考えていらっしゃる方におすすめです。
学習内容の備忘録
GitHubのCommit履歴
memo
SREとITILの違い
疑問に思っていたこと
SREという言葉が流行りだして、blog記事だったり、Googleのサイトだったりで内容を読んでいると、昔ITILを勉強していたことを思い出し、何が違うのだろうという疑問がわいた。
ITILの構成要素とSREが担当する要素の比較
SRE本から抜粋した一般的なSREが担当するもの
In general, an SRE team is responsible for the availability, latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning of their service(s).
ITILSRE事業継続性管理-パートナーシップとアウトソーシング-事業の利益のための情報通信技術(ICT)の継続的改善と活用efficiencyサービスデスク-インシデント管理emergency response問題管理monitoring構成管理-変更管理change managementリリース管理-サービスレベル管理latency / performanceITサービス財務管理-可用性管理availabilityITサービス継続性管理capcacity planningICTインフラストラクチャ管理-アプリケーション管理-セキュリティーマネジメント-
ITILの一部分
対応表から、SREが担当する要素はITILに含まれているということがわかった。
疑問に抱いていたことの回答としては、SREはITILの一部分ということになるのではないかと思う。
当てはまる項目をざっと見る限り、「SRE」という名の通りサービスの信頼性に関連する部分に特化しているように見えた。ちなみに自分達(ホスティングサービスのインフラチーム)はというと、2つの項目を除いてITILのすべての項目を実際に業務としてやっていた。
自分達にあったもの
Googleと比較しても仕方ないので、SRE本の中で今の自分達にあっているものや、これから役に立つであろうものをピックアップして、現在のチームや組織に導入していく必要があると感じた。
何はともあれ、まずは英語力アップですな。
Close call!!
Today, my relatives gathered and had a good time with delicious meals. Especially I enjoyed dancing by children. To the great pleasure, on the second day "continuation" was about to be cut off. I will write an article about SRE tomorrow.
Happy New Year 2017 I hope the New Year finds you in excellent sprint!! Because I worshiped the sunrise from my neighborhood, it seems to be a good year. My Goal for this year is “continuation”. First of all, to read the “SRE” i am reading now until the end.
And as much as possible to write sentences in English. And update the blog once a day. “Persistence pays off.”
リポジトリ管理
リポジトリの管理が煩雑になりがちだったので、ghqを使って管理するようにした。管理する場所については特になかったので、こちらを参考にして~/src配下で管理するようにした。
ghq install
~/.zshrcにGOPATHとGoの実行バイナリへのPATHを追加
$ export GOPATH=$HOME $ export PATH="$HOME/bin:$PATH" $ exec $SHELL -l
gitconfig設定
$ git config --global ghq.root ~/src
ghqインストール
$ go get github.com/motemen/ghq
試しにlistを拾ってみる
$ ghq list github.com/codegangsta/cli github.com/daviddengcn/go-colortext github.com/mitchellh/go-homedir github.com/motemen/ghq github.com/motemen/go-colorine
よさげ。 次はインタラクティブフィルターなどと呼ばれているらしい pecoとfzfをインストールして連携させてみます。
Pycharmの設定
基本的な設定
こちらを参考に剳せて頂いております
Pluginのインストール
Vimのキーバインドを使いたいのでこれをインストール
asciidocが気になったのでインストール
メモの環境としても使いたかったので、Markdown + GFMをインストール
Goの開発環境としても使いたかったので、インストール
一旦この状態で使ってみます
開発言語の管理
anyenvという選択
もともとpythonを触ることが多く、pyenvだけで良かったのですが、rubyを使う機会が出てきたり、個人的にGo言語を学びたいという気持ちもあり、それぞれを別で管理するのは面倒だなと思い、anyenvでの管理にしました。
install
本家のマニュアルに従って進めます
$ git clone https://github.com/riywo/anyenv ~/.anyenv $ echo 'export PATH="$HOME/.anyenv/bin:$PATH"' >> ~/.your_profile $ echo 'eval "$(anyenv init -)"' >> ~/.your_profile $ exec $SHELL -l
Goのインストール
goenv install 1.7.1 goenv global 1.7.1
Rubyのインストール
rbenv install 2.3.1 rbenv install mruby-1.2.0 rbenv global 2.3.1
Pythonのインストール
pyenv install 3.5.2 pyenv global 3.5.2
次はPycharmあたりを設定していこうと思います。
vimのパッケージ管理
NeoBundlの後継
知らぬ間にいろんなものができているようで、NeoBundleの後継が出ていたのにびっくり。ということで、今までNeoBundleで行ってきたパッケージ管理をdein.vimで行うように設定していきます。
dein.vimインストール
$ curl https://raw.githubusercontent.com/Shougo/dein.vim/master/bin/installer.sh > installer.sh $ sh ./installer.sh ~/.vim/dein
dein.vim設定
~/.vimrcに以下の設定を追加した
" dein setting let s:dein_dir = expand('~/.vim/dein') let s:dein_repo_dir = s:dein_dir . '/repos/github.com/Shougo/dein.vim' if &compatible set nocompatible endif if !isdirectory(s:dein_repo_dir) execute '!git clone [email protected]:Shougo/dein.vim.git' s:dein_repo_dir endif execute 'set runtimepath^=' . s:dein_repo_dir call dein#begin(s:dein_dir) " plugin add "#------------------------------------------ call dein#add('Shougo/dein.vim') call dein#add('Shougo/neocomplete.vim') "#------------------------------------------ " plugin end call dein#end() if dein#check_install() call dein#install() endif filetype plugin indent on
最近の傾向とか調べつつpluginを強化していこうと思います。
zshの環境を整える
必要なパッケージのインストール
$ brew install zsh zplug
zshへの切り替え
/etc/shellsにzshを追加
/usr/local/bin/zsh /bin/bash /bin/csh /bin/ksh /bin/sh /bin/tcsh /bin/zsh
chshで変更
$ chsh -s /usr/local/bin/zsh Changing shell for tshst. Password for tshst:
新しくターミナルを開くとzshに変更されており、.zshrcの作成を勧められるので作成しとく
$ touch ~/.zshrc
初めてのzplug
いろいろと積み重ねてきた設定ファイルなんかは手元にあるのですが、一度m捨て去って一からか整えようと調べていたらpluginの管理ツールがあるようなので使ってみようと思いインストール
ここを参考に~/.zshrcに以下の設定を記述した
## zplug setting source /usr/local/Cellar/zplug/2.3.1/init.zsh #-- zsh-syntax-highlighting zplug "zsh-users/zsh-syntax-highlighting" #-- zsh-completions zplug "zsh-users/zsh-completions" #-- zsh-autosuggestions zplug "zsh-users/zsh-autosuggestions" #-- zsh-git-prompt zplug "olivierverdier/zsh-git-prompt"
設定後、~/.zshrcを再読込する
$ source ~/.zshrc zsh compinit: insecure directories, run compaudit for list. Ignore insecure directories and continue [y] or abort compinit [n]? y
プラグインをインストールする
$ zplug install Installing... zsh-users/zsh-completions Installing... zsh-users/zsh-autosuggestions Installing... zsh-users/zsh-syntax-highlighting Installing... olivierverdier/zsh-git-prompt Installed! zsh-users/zsh-syntax-highlighting (4.33s) Installed! zsh-users/zsh-completions (6.06s) Installed! olivierverdier/zsh-git-prompt (6.30s) Installed! zsh-users/zsh-autosuggestions (8.38s) ==> Installation finished successfully! [zplug] |install| total wall-time 8.738862 sec.
プラグインを有効にする
$ zplug load
各パッケージについて
zsh
coreパッケージ
zsh-syntax-highlighting
This package provides syntax highlighing for the shell zsh. It enables highlighing of commands whilst they are typed at a zsh prompt into an interactive terminal.
zsh-completions
Additional completion definitions for Zsh.
zsh-autosuggestions
Fish-like fast/unobtrusive autosuggestions for zsh.It suggests commands as you type, based on command history.
zsh-git-prompt
A zsh prompt that displays information about the current git repository. In particular the branch name, difference with remote branch, number of files staged, changed, etc.
一旦ここまでにして不便になったら随時アップデートしていきます。 次はvimだな
macのパッケージ管理ツール
brewのインストール
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
commandlineツールも自動でインストールしてくれるので便利
Downloaded Command Line Tools (macOS Sierra version 10.12) for Xcode Installing Command Line Tools (macOS Sierra version 10.12) for Xcode Done with Command Line Tools (macOS Sierra version 10.12) for Xcode Done.
インストール後の状態は空っぽ
$ brew list
下準備完了