渡辺です。 JenkinsをAmazonLinuxにインストールする場合、次のようなコマンドを実行します( 公式Wiki より)。 sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo sudo rpm --import https://jenkins-ci.org/redhat/jenkins-ci.org.key sudo yum install jenkins 要は、yumのリポジトリの追加と gpg鍵を登録して、yumでインストールします。 Ansibleのcommandモジュールやshellモジュールを利用すれば簡単に自動化できますが、冪等性を保つためにも標準モジュールを利用する方がベターです。 というわけで、yum_repositoryとrpm_keyを使
概要 Ansibleを使っていて、 sambaのユーザパスワード BASIC認証のパスワード など、パスワードを管理して使いたい場合が時たまあると思います。 そんな時にいつも使っている方法を紹介します。 パスワード管理方法 1. Ansible Vaultで暗号化する 基本的にパスワードの類はAnsible Vaultで暗号化して使用します。 ansible_sudo_pass: として SUDOパスワードを入れておくと、SUDOパスワードの省略ができて便利です。 private.ymlにパスワード類を記載し、Ansible Vaultで暗号化する ### sudoパスワードとsambaのパスワードを記載 % vim private.yml + --- + ansible_sudo_pass: sudo_password + samba_user: samba + samba_pass:
久しぶりにansibleをやっているわけですが、.bash_profileに書いたPATHが反映されないなあ、と思って色々調べてみました。 どういう事が起きたか ansibleのドキュメントを見てみる 2通りの解決策 shellモジュールを使う時は必ずログインシェルとして実行する メリット デメリット ansible.cfgにexecutableを追加してしまう メリット デメリット 雑感 どういう事が起きたか 今回rbenvのplaybookを書いていて気づきました。 大まかにrbenvのインストールは以下の流れになります。 rbenvをgit cloneする。 ruby-buildをgit cloneする。 ~/.bash_profileにrbenvのバイナリへのパスとrbenvの初期化コマンドを追記する。 rbenv install 2.2.2する。 rbenv global 2.2
はじめに Ansibleを使うようになってしばらく経ちましたが、たいへん便利なツールだなと思っています。 ベストプラクティスだったり真面目に頭を働かせることもありますが、言われないと気づかないだけの地味なトラップみたいなものもあるのでそちらをまとめてみたいと思います。 各種バージョン 現在 yum の epel-testing リポジトリから入手できる最新の Ansible を使います。 [root@controller ~]# cat /etc/centos-release CentOS release 6.7 (Final) [root@controller ~]# python --version Python 2.6.6 [root@controller ~]# ansible --version ansible 2.0.1.0 config file = /etc/ansible
毎回あれー?ってなってドキュメント読んだりググったりするんだけどうまく見付けられないので書いておく。 Ansibleはデフォルトだとtaskの実行が全ホストで失敗しない限り続く。言いかえると、あるタスクがあるホストで失敗したらそのホストについては以降実行されないが、成功した他のホストについてはplaybookの実行は継続される。 これは特に分散ストレージのセットアップなどにおいて、大変よくない。 よくないので1台でもtaskの実行に失敗した時点で止めたいというタスクには以下のように書いておく。 - hosts: ippai max_fail_percentage: 0 tasks: - name: .... failしているホストのパーセンテージが max_fail_percentage を「超えた」場合にplaybookが停止するので、1台でも fail したら即座に止めたい場合は 0
はじめに こんにちは植木和樹@上越妙高オフィスです。 複数台のサーバーにyum updateする時には、各サーバー1台ずつにsshでログインしてコマンドを実行するのではなく、ansibleを使って実行することが推奨されます。これは実施した作業内容や作業ログをログとして残すのが容易なためです。 ただ、yum updateのように時間がかかる処理をansibleから行ってしまうと、タイムアウトが発生して処理が中断してしまいrpmの不整合が発生するという残念な事態になってしまいます。 今回はそんな残念な事態を回避するための子ネタをお送りしたいと思います。 ansibleでのタイムアウト ansibleはsshを用いてサーバーへコマンドを送り、その処理結果を待って成否を判定します。この際コマンドの実行に時間がかかるとsshがタイムアウトしてしまい、処理途中でコマンドが強制終了してしまうことになりま
とても初歩的なことでハマってしまったので、今後忘れないためにもしっかり書いておく。 目指せ30分以内編集 今回の事象 ハマったこと Ansibleでtomcatを起動するスクリプトを実行。 okの確認、pidファイルの作成も確認できていたが、ログインしてみると起動できていなかった。 ログインしたサーバーで起動スクリプトを叩くと起動できる。 debugで出力した結果も、環境変数が指定できていない等の問題はなさそう。 原因 起動コマンドに"&"をつけてバックグラウンドで起動していたが、 sshのコネクションが切れたため、プロセスも終了していた。 Ansibleはsshでコネクションを張り、命令を実行という基本的な流れを忘れていた/(^o^)\ 解決策 nohupつけて起動 もう少し詳しく 実際にはただこれだけの無知なお話ですが、流れを詳細に。 実行命令 AnsibleのPlaybook内で以下
Ansibleでシェルの設定ファイル(以下、bashを使用する前提で記述する)に設定の追加が必要なソフトウェア(rbenvやnodebrew, VirtualenvWrapperなど)をインストールする場合、以下のように書いても上手く動作しない。 # ~/.bashrc(~/.bash_profile) にrbenvの設定を追記する - name: Set rbenv config copy: src=files/bashrc dest=~/.bashrc # ~/.bashrcに書き込んだ設定を読み込む - name: Load rbenv setting shell: source ~/.bashrc executable=/bin/bash - name: Install ruby 2.1.2 shell: rbenv install 2.1.2 && rbenv rehash &&
はじめに 本資料は多数のドキュメントにバラバラに書かれているAnsibleのplaybookに指定可能なアトリビュートの一覧とそれぞれの簡単な解説である。 アトリビュートとは、playbookに記述することのできる各種のディクショナリキーのことである。と言っても現在のところこれが定まった呼び方というわけではない。Ansible v2のソースにAttributeと書かれているのでここでもそう呼ぶことにしたものである。 アトリビュートにはplayに指定できるもの、taskに指定できるもの、どちらにも指定できるものがある。 playあるいはtaskって何? って話は http://docs.ansible.com/glossary.html を参照のこと。 要はplaybookはplayのリストで構成されており、playの中のtasksアトリビュートやhandlersアトリビュートなどに記述する
渡辺です。 セキュリティを高めるなどの理由で対象インスタンスにEIPを付与しない場合、SSHは踏み台(Bastion)経由となります(参考: Amazon VPC環境にメンテナンス用の踏み台サーバを構築する)。 踏み台サーバのある構成でAnsibleを利用する場合、ansible.cnfのssh_connectionでssh_argsを設定しましょう。 ssh_configの準備 はじめにsshのconfigファイルを作成します。 これは、~/.ssh/configに設定するファイルの一部と考えて良いでしょう。 Ansibleのファイルと一緒にバージョン管理する方が良いと思うので、Ansibleのプロジェクトルートにおくことをおすすめします。 Host bastion HostName 52.52.xxx.xxx User ec2-user IdentityFile ~/.ssh/prd.
渡辺です。 シェルスクリプトの中では、コマンドは可能な限りフルパスで記述することが望ましくなります。 しかし、環境によってコマンドのパスは異なる事があるため、スクリプトファイルに固定で記述することもできません。 このような場合、環境毎の変数をvarsに用意し、include_varsステートメントを利用します。 awsコマンドのパスを定義する AWS CLIのコマンドはAmazon Linuxでは/usr/bin/awsとなり、Ubuntuでは/usr/local/bin/awsとなります。 はじめにvarsディレクトリの下にそれぞれファイルを用意して定義します。 # RedHat.yml --- path_to_awscli: /usr/bin/aws # Debian.yml --- path_to_awscli: /usr/local/bin/aws これらのファイルを読み込めば、変
目的 vSphere Client からぽちぽちせずに ESXi を操作したい ansible を使うことで構成管理と自動化も視野に 最終的には VM の自動作成をしたいなと 初めての方は以下も先にご確認下さい Ansible で ESXi を操作してみる[初期テスト] http://qiita.com/hirofumihida/items/f1b5fce4322dc664d95d 構成 (2016/03/06 時点) ansible 2.0 mac os x el capitan ubuntu 14.04 $ sudo pip install ansible $ ansible --version ansible 2.0.1.0 $ sudo pip install pysphere $ sudo pip show pysphere --- Name: pysphere Version:
Ansible Tutorial July Tech Festa にて開催されたハンズオンの資料が公開されていたことに刺激され、Chef の代わりに Ansible を使う資料を作りました。 Ansible を使って WordPress サーバーのセットアップを行い、ServerSpec でテストを行います。 まだ Ansible を試し始めたばかりで自分の勉強がてら書いています。 Puppet にも Chef にも乗り遅れたので Ansible に飛び乗ってみようかと。 GitHub Repository Ansible Tutorial Wiki 2013年08月13日 一段落 コピペで動かないところを全体的に修正しました。今後は 詳細ページ Wiki を充実させていきます 2013年09月09日 role についての追記しました 2013年12月22日 リニューアル Ansible
ものすごく今更ながら、実践Vagrantを見ながら、Vagrantを試してる。 実践 Vagrant 作者: Mitchell Hashimoto,Sky株式会社玉川竜司出版社/メーカー: オライリージャパン発売日: 2014/02/21メディア: 単行本(ソフトカバー)この商品を含むブログ (5件) を見る ついでに気になってたDigitalOceanも試したかったので、 VagrantとSSDなVPS(Digital Ocean)で1時間1円の使い捨て高速サーバ環境を構築する - Glide Note - グライドノート を参考に、DigitalOceanにVagrant+Ansibleで環境を構築する方法を試したので、メモ。 Vagrantのインストール Download Vagrant - Vagrantからバイナリをダウンロード。 Ansibleのインストール プロビジョニングに
AnsibleはChefやPuppetと同様に冪等性(べきとうせい)に配慮した構成管理ツールです。YAMLで記述したプレイブックのファイルが1つあれば動き、SSHさえ繋がれば対象サーバーにクライアントは不要、といったシンプルさが支持され、近年ユーザーを増やしています。 そのシンプルさは仮想マシンを利用した開発環境の構築にもうってつけに思えます。と言うことで今回はAnsibleをVagrantのプロビジョナーに使って開発環境を構築しました。 Ansibleの公式サイト Ansibleのインストール Ansibleはコントロールマシンに入っていればよく、セットアップ対象のサーバにはAnsibleのクライアントなどは不要です。SSHで接続さえできればOKです。今回のケースでは開発マシンのMacをコントロールマシンとし、Vagrantによる仮想マシンをセットアップ対象とします。 Ansible自体
Host foobar-web-1 Host 192.168.0.1 Host foobar-web-2 Host 192.168.0.2 Host foobar-db Host 192.168.0.3 Host foobar-dev Host 192.168.0.4 Host foobar-staging Host 192.168.0.5 Host foobar-web* # WEB のみ 鍵が違う IdentityFile ~/.ssh/id_rsa-foobar-web # 最初に見つかったものが使われるので、デフォルトは下に書く Host foobar* # 全てのホストで、User は hoge User hoge IdentityFile ~/.ssh/id_rsa-foobar
Ansibleではinventoryに対象ホストを定義します。 適用したいインフラ構成が複数ある場合、playbook毎にグループ化してください。 グループ化した場合、変数はそれぞれのgroup varsに定義できます。 詳しくは、前回のエントリーを参照してください。 inventoryの構成方法には幾つかのパターンがあります。 対象とするシステムの規模や特徴にあわせて選択しましょう。 なお、パターンを整理するにあたって、Ansibleのインベントリファイルでステージを切り替えるを参考にしました。 ベーシックパターン 開発環境・検証環境・本番環境といった目的毎に環境を作る必要がなく、ひとつの環境(本番環境)のみの場合は、inventoryファイルもひとつで十分です。 hostsという名前のファイルを作成し、inventoryを定義しましょう。 構成は次のようになります。 . ├── gro
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く