Amazon Linux 向けに書いた Ansible Playbook を Amazon Linux 2 に対応させようと思ったのですが、facts を見ても区別できる要素がありません。必要なところだけ抜き出すとこんな感じです。 # Amazon Linux "ansible_distribution": "Amazon", "ansible_distribution_major_version": "NA", "ansible_distribution_release": "NA", "ansible_distribution_version": "2017.09", # Amazon Linux 2 "ansible_distribution": "Amazon", "ansible_distribution_major_version": "NA", "ansible_distri
本連載の第4回、第5回では「Ansible応用編」と題して、Ansibleの応用的な使い方やTipsについて詳しく解説していきます。前回(第4回)は、Ansibleのベストプラクティスに沿ってPlaybookを再整理する方法を紹介しました。今回は、Ansibleの持つ各種機能を活かしたPlaybookの効率的な記述方法やつまずきやすいポイントの回避方法を紹介します。 Playbookを効率的に書く 同種の処理をまとめる 同じ処理を何度も実行する際には、Loop構文を使うことで処理をまとめて記述できます。処理をまとめることで記述を簡潔にし、Playbookのメンテナンス性を高めることができます。 基本的なLoop構文 基本的なLoopの記述方法は、以下のようになります。「with_items」アトリビュートに、YAML記法のシーケンス(配列に相当)形式で定義しておくと、実行時に各要素が順次展
TypetalkのSREの二橋です。今回は、Gossの紹介をしたいと思います。 TypetalkではサーバーのテストにServerspecを利用していました。機能的には申し分なかったのですが、サーバーの台数/環境/テストの項目が増えるにつれて、ツールの実行速度やメンテナンス性に改善が必要になりました。Gossに乗り換えることで問題が解消されました。 サーバーのテストとは? サーバーのテストとは、サーバーの状態が意図したものになっているか検証するものです。例えば、以下のような項目を検証します。 意図したパッケージのバージョンがインストールされているか? 意図したサーバーと通信できるか? 意図したポートが待ち受けているか? 意図したユーザー/グループが存在するか? 意図したプロセスが動作しているか? 意図したファイルに指定した記述が存在するか? Serverspecで困っていたこと ①テスト実
How to use ansible-playbook from python code - Ansible playbookをPython コードから実行するPythonAnsible Overview 基本はこれ。 https://hawksnowlog.blogspot.com/2018/06/call-ansible-playbook-from-python.html ただし、こちらの記事の記載の通り既存のplaybookが完成している場合、 互換性がないので使えない。 python nativeで最初から作るならば問題ないが、 既にAnsibleで作ってしまった環境を徐々に移行していくためには 当面、ansible-playbookを実行する必要がある。 従ってpython native コードに求められる機能は主に二つ。 ansible-playbook を読み込める(実行でき
概要 GCEの無料枠ありインスタンス f1-micro でWordPressを動かしたい f1-micro がDebian 9.5だったので、Dockerのdebian:9.5ベースのコンテナでWordPressが動くようなansible playbookを書いてみる バージョン情報 Ansible 2.7.0 Debian 9.5 MariaDB 10.1.26 nginx 1.10.3 PHP 7.0.30 (ホスト)Mac 10.13.6, Docker for Mac 18.06.1 成果物 ansible-examplesではRHELベースでのplaybookしかなかった。Debian向けのPlaybookについては現在PRが出ているがマージされていない。 PRのコードを動かしたところいくつか動かなかった点があったので修正したのが上記のコード。 ハマった点 nginx, php-
はじめに 同じパッケージであるにも関わらず、ディストリビューションで名称が違う場合があります。またインストールパス/設定ファイルのパスが微妙に違う場合があります。 たとえばApache2.4のパッケージ名は、CentOS7の場合は「httpd」ですが、Amazon Linuxの場合は「httpd24」となります。タスクごとにwhen句で指定しても良いのですが、同じ値を複数個所で使う場合はPlaybookが煩雑になります。 このような場合、ディストリビューション/OS環境ごとに変数をあらかじめ定義し、切り替えられたら便利です。またこの制御をグローバルに行う(≒Role呼び出し元のPlaybookで制御する)のではなく、Roleに閉じた範囲で制御できた方が見通しが良くなります。 このようなケースの解決策を以下にまとめます。 TL;DR vars(roles/????/vars/main.yml
はじめに GCE上のプロセスをStackdriverで監視していて、プロセスが落ちたらSlackにアラートを飛ばす・・・・ ちゃうねん!アラートが飛ばすことが目的じゃなくて、サービスをいち早く復旧させるのが目的やねん! どうせAlert飛んだあとにやることは、systemctl status XXXXXでステータス確認して、sudo systemctl start XXXXXをするだけじゃん。 ということで、Stackdriver+Gitlab-CI+Ansibleを連携させて、アラートを飛ばすだけじゃなく、サービスを復旧させる仕組みを構築してみようと思う。 チームのメンバーがSlack botでもいい感じに自動復旧の仕組みを作ってる記事があるので、Slack botでやりたいんだよ!俺は!っていう人は↓を参考にすると幸せになれる。 Stackdriverとslackbotでサービス自動復
require 'nokogiri' file '/tmp/test.xml' do content lazy { x = File.open(path) { |f| Nokogiri::XML(f, &:noblanks) } x.at_xpath('/foo/bar').content = 'new_val' # 値の設定 x.at_xpath('/foo') << Nokogiri::XML::Node.new("bar2", x) # 子供の追加 x.at_xpath('/foo/bar2'). content = 'val2' # 値の設定 x.to_xml } end Rubyのnokogiriライブラリーを使用する。 xmlファイルをNokogiri::XML::Documentクラスのオブジェクトとして読み込む。noblanksオプションは、読み込み時にxmlを読みやすくす
2. テスト用ドキュメント https://docs.ansible.com/ansible/latest/dev_guide/testing_units.html#testing-units 3. unitテストで使うソース 3-1. 作成したモジュール 前回作った output_name.py に手を入れてみます。 sum という関数を作って引数を足して戻すだけの関数を付け加えたものに対してユニットテストをしてみます。 イメージを持ってもらうということで簡単なものにしています。 #!/usr/bin/env python # -*- coding: utf-8 -*- # Copyright: (c) 2018, sky_joker # GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licens
2. テスト用ドキュメント 以下は、Ansibleモジュールのテスト用ドキュメントです。 https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_general.html https://docs.ansible.com/ansible/latest/dev_guide/testing_sanity.html 3. 作成したモジュール テストを実行するために簡単なモジュールを作ってみました。 以下は name に指定した文字列を辞書で返すだけのモジュールです。 #!/usr/bin/python # -*- coding: utf-8 -*- # Copyright: (c) 2018, sky_joker # GNU General Public License v3.0+ (see COPYING or
[DEPRECATION WARNING]: Invoking "yum" only once while using a loop via squash_actions is deprecated. Instead of using a loop to supply multiple items and specifying `name: {{ item }}`, please use `name: ['git', 'gcc']` and remove the loop. This feature will be removed in version 2.11. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg. 要はループを使うなと言うわけですが、squas
if has('vim_starting') set nocompatible set runtimepath+=~/.vim/bundle/neobundle.vim/ endif set number imap <C-j> <esc> nnoremap <silent><C-e> :NERDTreeToggle<CR> call neobundle#begin(expand('~/.vim/bundle/')) NeoBundleFetch 'Shougo/neobundle.vim' NeoBundle 'Shougo/neosnippet.vim' NeoBundle 'Shougo/neosnippet-snippets' NeoBundle 'tpope/vim-fugitive' NeoBundle 'kien/ctrlp.vim' NeoBundle 'flazz/vim-
/root/ansible |-- group_vars # グループで使用する変数を定義 | `-- test-servers |-- hosts # インベントリファイル |-- redmine.yml # コマンド実行時に指定するプレイブック `-- roles |-- apache # Apache設定用role | |-- tasks | | `-- main.yml | `-- templates | `-- redmine.conf |-- common # 共通role(OSの設定等) | `-- tasks | `-- main.yml |-- postgresql # PostgreSQL設定用role | |-- files | | `-- pg_hba.conf.diff | `-- tasks | `-- main.yml |-- redmine # Redmin
Ansibleを環境毎に使い分ける やりたいこと 環境毎にansibleを使い分ける dev /stg verifiロールで実行環境のenvを表示させて確認する 検証時のAnsibleディレクトリ構造とplaybook ├── bastion.yml ├── group_vars │ ├── all │ ├── env_dev │ │ └── main.yml │ ├── env_stg │ │ └── main.yml │ └── role_bastion ├── inventory │ ├── dev │ └── stg └── roles └── verifi └── tasks └── main.yml
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く