もう 2018 年だけど, Jenkins + Docker + itamae + Serverspec でインフラ CI っぽいことをやってるのでメモ - ようへいの日々精進XP
やってること メモ Jenkins を動かす環境 Docker イメージ itamae レシピ Serverspec テスト Jenkins の準備 プラグイン Docker 周り ジョブ infra-itamae の設定 infra-serverspec の設定 動いてる図 Build Pipeline ログ 以上 やってること 今更かもしれないけど, ギョームで以下のようなことをやって, ここ数日で運用も回ってきた気がするのでメモしておく. itamae のレシピを amazonlinux コンテナに適用 適用したコンテナに対して Serverspec でテスト 1 と 2 を Jenkins のビルドパイプラインで流す 3 が正常に終了したら, pull request を作成, 又はマージ master ブランチのレシピをサーバーに手動で適用 Jenkins のポテンシャルと it
ISUCON7予選1日目にチーム「ババウ」で参加して最終スコアは205148でした - このブログはURLが変更になりました
Webサービスをいい感じにパフォーマンスチューニングするコンテスト ISUCON7予選1日目に @netmarkjp, @ishikawa84g, @matsuu でチーム「ババウ」にとして参加しました。最終スコアは 205148 でした。 考察 netmarkjp 例年通りの役割分担がしっかり機能して気持ちよくできた 視点を変えたり休憩とったりがいい感じにできた 去年の何もできなかった無念は多少供養できた 練習をきちんと活かせた ベンチが安定しててすごくよかった BGMは東京スカパラダイスオーケストラでした matsuu トラフィックがボトルネックになる問題をなかなか解決できずにいたが、Cache-Controlにpublicを入れることを思いつけた 304応答が安定して発生しない理由が生成される画像の更新日時がサーバ毎に異なるためであることに気づけた自分を褒めてあげたい tcpdump
プロビジョニングツール Itamae を速くする - Qiita
TL;DR Itamae を使ってプロビジョニングしていたけど実行時間が長くて困っていた ssh接続を使いまわすように改造したら40分かかっていたのが2分くらいになった（20倍の高速化） 問題 Itamae は内部的にサーバー側でコマンドを実行するところが多いみたい コマンドを実行するたびに ssh で接続、コマンド実行、ssh 接続を切断、している（実際に仕事をしているのは Specinfra） 1つ1つのコマンド実行時間は長くても数秒なので、TCPソケットのリソースがきれいに開放されるよりも早い（印象） ソケットリソースが少しづつ逼迫し、スローダウンしていく（ように見える） def create_specinfra_backend Specinfra::Backend::Ssh.new( request_pty: true, host: ssh_options[:host_name],
mitamaeでrecipeのロードエラー時にデバッグしやすくした - Islands in the byte stream
一部のプロジェクトでmitamae (itamae on mruby) を使ってるんですが、自分が書いているときはともかく他人が書いているmiamaeでrecipeのロードエラーが発生すると、mruby-ioレベルでもmitamaeレベルでもファイル名を出力してくれなくてこれはデバッグできないぞという状態でした。 問題は2つのレイヤーであって、 mruby-io がopenの失敗時にファイル名を出力しない mitamaeのロガーは読み込んだレシピを実行するときはログを吐くが、ロードの前あるいは失敗時の処理がない 低レイヤーのmruby-ioはopenは失敗時にファイ名名を出力すべきだし、miamaeレイヤーでもレシピの読み込みは非常に重要なのでもっと詳細にログに出してほしいところです。なおmitamaeレベルでのレシピ読み込みエラーはopen由来とも限らないので、どちらか一方ではなく両方の
itamae | itamae運用に関する備忘録 - Qiita
itamae運用に関する備忘録、本来はドニュメント等にあるはずの事に過ぎないが、必要な時に探すのが面倒なので、自分用にまとめておく。 実行に関して レシピが実行されるのは、未適用の時 説明は不要だと思うが、itamaeを向けて実行した時に、レシピが未適用だったら問答無用に適用される 適用済みのレシピを再度適用させるのは、レシピの内容が変更された時 一度適用されたレシピを、再度itamaeを向けて実行しても、レシピの内容に変更がなければ、適用されない。つまり、何度実行しても、勝手にアップデートがかかるような適用はされない。 レシピの内容が変更されていなくても、関連ファイルの内容が変更されれば、適用される レシピの中で、template等を使用してファイルを配置する場合などでは、レシピが全く変更されていなくても、そのsourceファイルが変更されていれば、適用される。 通常のレシピ適用ではパッ
既存のローカル認証サーバーをldap認証への切り替えに挑戦してみる - Qiita
概要 通常のローカル認証(shadowパスワード)認証のサーバーを、ログインとsudoをldap認証に切り替え、sshdもパスワード認証から公開鍵認証のみに変更してみる (OSの再起動なしで挑戦する) 本編 基本的にitamaeで作業を行いレシピはgithubに上げてある 事前に確認 ldap認証済みのサーバー側 # ldap認証のユーザー $ id ldusr01 #=>uid=20001(ldusr01) gid=20001(ldapgroup) groups=20001(ldapgroup) # 接続テスト $ ssh -i id_ldusr01_ed25519 ldusr01@localhost #=> ログインOK # ローカル認証のユーザー $ id localuser id: localuser: no such user # ldap認証のユーザー $ id ldusr01
マネーフォワードのItamae Tips | Money Forward Engineers' Blog
こんにちは。 インフラエンジニアの村上です。 マネーフォワードでは、プロビジョニングツールに Itamae を活用しています。 本稿では「Itamaeってこんなこと出来るんだよ」を幾つか紹介します。 レシピの依存管理をする レシピはミドルウェア単位等で作ると思いますが、依存関係があるケースありますよね。 Itamaeは、依存管理は include_recipe を使う事になります。 では、「依存先のバージョンアップがあった時に、自分自身も再度インストールしなおしたい」などの場合はどうするのでしょうか。 subscribes という機能がこれらをサポートしてくれます。 サンプルコードは以下になります。 NginxのレシピにOpenSSLやGlibが依存しています。 require File.expand_path('cookbooks/itamae_helper.rb') APP_NAME=
Packer + itamaeでDockerfileのないDockerライフ - Qiita
Dockerは Dockerfile という独自のDSLで記載されたファイルからDockerイメージを作成するのだが、 普段かいてるitamae使えないかなと思ったらどうやら Packerというものと組み合わえるといけるらしい Packerを使ってChef/Puppet/AnsibleでDockerのイメージをつくる ただ僕が普段使っているのはItamae。。。Packerでは現状対応してないという。 Packerとは？ VagrantとかTerafformとかを作っているHashicorp社製のソフトウェア 複数のプラットフォームのマシン、コンテナイメージを1つの設定ファイルから作成できる。 身近な例でいうと AMIの作成をコマンド一発で作れるようになる。 他にもbuild先を切り替えるとGCEとかVMwareとかのイメージが作れるようになる お題 rubyの2.3.1が動いていてrai
itamae具体例10選〜寒空のlinuxコマンドを添えて〜 - Qiita
目的 訳あって、既存のitamaeを読みながらitamaeを使わずに環境構築をしていました。 検索で「itamaeコード itamae」とか「linuxコマンド itamae」とかよく打っていたのですが、記事は「実行できることとitamaeコードまとめ」のようなものが多く、すぐにはlinuxコマンド=itamaeコードがパッと結びつけられませんでした。なので、自分の作業に沿ってになりますが、セットで書いていきたいと思います。 もし「itamaeってなんだ！」の場合はこちら。 iptablesとSELinuxを停止＆無効化 ファイアーウォールを無効化、セキュリティ管理してくれるモジュールを無効化します。 ＞itamaeでのこれは・・・ service 'iptables' do action [:disable, :stop] end include_recipe 'selinux::dis
mitamae の高速化 - eagletmt's blog
itamae と比較して mitamae のメリットをシングルバイナリ以外にも作りたいなと思って mitamae の高速化を進めている。 高速化の方針は「できるだけ Ruby (mruby) のプロセス内で実行する」というもの。 itamae と mitamae の差の一つに SSH サポートや Docker サポートがあって、itamae は SSH 越しに実行したり Docker コンテナに対して実行したりできるが、mitamae はローカルのみをサポートしている。 mitamae では未実装なだけかと思ったが、既に一部の実装がローカル実行前提のようだったので、だったらその前提で外部コマンドを使わずに Ruby でファイルの存在などをチェックすることで高速化できるだろうと考えた。 実は itamae のときにも同じことをやろうとしていて実際に ちょっとだけ作ってみていた んだけど、うま
RubyなしでItamaeレシピを実行できる「itamae-go」を作った - k0kubun's blog
Goとmrubyを使ってitamae-goを作った github.com Pokemon Goが流行っていたので流行に乗じてItamae Goを作った。 というのは冗談で、手元の開発環境のセットアップにitamaeを使っているのだけど、まっさらな環境でitamaeを実行したい時にRubyやitamaeをどういれるかについて考えるのが面倒なので、Rubyなしで実行できるitamaeを作った。Goで実装し、mrubyでレシピを読むことによりRubyなしでの実行を実現した。 インストール方法 Releasesにバイナリを置いてあるのでこれをダウンロードする。基本的には環境セットアップ用のシェルスクリプトからこれをcurlなりwgetなりでダウンロードして使うことを想定している。 なんか動かなかったらgit cloneしてmakeすればその環境用のバイナリが作れるはず。 *1 使い方 普通にita
ItamaeとServerspecを使ったサーバ構築と自動テストを試してみた - 日記っぽい何か
まえがき こんにちはじょにーです。夏休みの自由研究です。 前から触ってみたかったItamaeと、Serverspecによるテストを行える環境を作ってみました。 こえむさんによる Itamae + Serverspec でサーバ構築・テスト自動化 総仕上げ！ | こえむの編集後記 こちらを参考に（というかほぼそのままなぞって）CentOS7にてItamaeとServerspec によるインフラ構築を試した記録です。 ほぼそのままなぞっただけですので、本来は記事として書くようなことでもないのですが、 特に予備知識なくそのままなぞった際に、うまくく動かないところがありましたので、トライアンドエラーを繰り返してかつそのまま記載しています。そのあたりの試行の参考になればいいなという感じです。 手順 IDCFクラウドにてCentOS7.1の仮想サーバーを2台準備しました admin01 node01
#itamae_meetup で「itamaeを楽しく使うための工夫」について発表してきた - k0kubun's blog
Itamae meetup #1 で発表した 趣味でちょくちょくコミットしているItamaeという構成管理ツールの第一回Meetupがあり、Itamaeについてどこかで話したいな〜とずっと思ってたので話してきた。個人的には、僕が作った機能のうち特に最近実装した以下のものを各位に使ってもらうことによって、Itamaeレシピの書かれ方やItamae自体をいい感じにしていきたくて発表した。 itamae generate cookbook https://github.com/itamae-kitchen/itamae/pull/176 include_recipeの.rb省略 https://github.com/itamae-kitchen/itamae/pull/166 bundle gemの命名規則に従ったresource pluginの自動require https://github.
Vagrant+CentOS ゲストOS内にItamae をセットアップする | バシャログ。
三大キャリアからIIJMioに切り替えたら、通信速度が気持ち遅めになり通信料が節約できてるtanakaです。 今回はVagrant + Itamae の話をします。ローカル開発環境を構築するときには Vagrant + vagrant-itamae プラグイン をよく使います。しかし自動化になれて Resource の数が増えてきて変更点がなくても10分以上かかることが多くなりました。 そこで仮想マシン内にItamae環境を作り、sshログイン後ローカルで itamae local コマンドを実行する用にしたところ、10～20秒に短縮できましたので方法をご紹介します。 前提 プロジェクトのディレクトリにファイルは以下のように配置されているものとします。 ├── Vagrantfile └── itamae ├── recipe.rb └── node.json Vagrantfile に次
Itamae、Auto Scaling、CodeDeployを用いてdeployフローを刷新した話。そして板前をprovisioningした話。 - SmartNews Engineering Blog
その上で、新しく作り上げた deploy フローについて、雑な絵になりますが概略図を以下に示します。 主要な登場人物は Itamae Auto Scaling CodeDeploy GitHub / Circle CI となります。それぞれ追って説明をしていきます。 https://github.com/itamae-kitchen/itamae Itamae は @ryot_a_rai さんが作られた LightWeight な Chef like な OSS です。Chef で実現できた事のうち、 recipes の部分のみを切り出したようなシンプルなツールになっています。 (こちらの発表資料より引用) 弊社内で蓄積された Chef 関連のリソースを再利用・再整理するために粒度がちょうど良かったこともあり、Itamae を用いて provisioning の定義を書き直すことにしました
プロビジョニングツールをChef-soloからItamaeに替えてみました - yuumi3のお仕事日記
Chef から Itamae ？ EY-Officeではサーバーソフトの構築を行うプロビジョニングツールとして現在は Chef-solo を使っています。しかし Chef-solo は終了するらしいのですが、その移行先が良いように思えず悩みながら使い続けてきました。 そんなとき登場してきた Itamae はシンプルでとても魅力を感じました。詳しくは クックパッド開発者ブログのItamae記事 をご覧下さい。 今回時間があったので、EY-Officeの開発支援サーバー (Redmine, Git/Gnatara, CI ...)の全プロビジョニングをChefからItamaeに置き換えてみました。書き換えたレシピは約700行です、そこで感じた事を書きます。 Itamaeの良いところ、良くないところ 1. 情報が貧弱 まず良くない点ですが、Chefのドキュメント に比べると情報の量、質ともに低い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://post.simplie.jp/posts/35
GitHub - sue445/itamae-plugin-recipe-tig: Itamae plugin to install tig
Learning Configuration Management Tool / Itamae Meetup 2015
Itamaeを楽しく使うための工夫
