脱法シェル芸でマシンがトリップする案件が増加したため、名称を危険シェル芸に変更したら、変更後に危険シェル芸を試してさらにトぶ人間が増加。 それで・・・あのー宣伝で申し訳ないんですが・・・「シェルスクリプト高速開発手法入門」も・・・お願いします・・・ http://www.amazon.co.jp/dp/B00LBPGFJS
![【試さないで】危険シェル芸【違法(脱法)シェル芸を勧められたり、 身近な人が持っていたりしませんか?】](https://cdn-ak-scissors.b.st-hatena.com/image/square/904957540b566445019bc32ab99808a716f003e4/height=288;version=1;width=512/https%3A%2F%2Fs.tgstc.com%2Fogp3%2F0018df706b646ef86c6ebf7e80d57d5d-1200x630.jpeg)
脱法シェル芸でマシンがトリップする案件が増加したため、名称を危険シェル芸に変更したら、変更後に危険シェル芸を試してさらにトぶ人間が増加。 それで・・・あのー宣伝で申し訳ないんですが・・・「シェルスクリプト高速開発手法入門」も・・・お願いします・・・ http://www.amazon.co.jp/dp/B00LBPGFJS
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
StorageGatewayってなんじゃ?(Gatewayインスタンスの冗長化:GlusterFS編) StorageGatewayのiSCSIボリュームをEC2にマウントし、アプリケーションシステムの中で使おうとする場合、冗長化という課題が持ち上がってきます。 ここで、いくつか冗長化の可能性を考えてみました。 マルチパス(☓) その場合、iSCSIとしての冗長化に合わせると、マルチパスという方法があるようです。 イメージとしては、以下のような感じでiSCSIターゲットであるgatewayインスタンスに複数のIPを付与し、それぞれの接続先の複数のデバイスを1つのデバイスとして認識させ、1つの接続が切れても他のNICで接続ができる方法です。 これはそもそもGatewayインスタンスの冗長化ではなく、ネットワーク・インターフェースの冗長化になりますが、ちょっと試してみます。 2番目のENIIを
今回は、iSCSIターゲットをマルチパス接続するときのターゲット構成の話です。 ESXi の検証環境を構築するときなど、 Windows Server + Microsoft iSCSI Software Target を iSCSIターゲット(iSCSIサーバ)として利用することが多いと思います。 Microsoft iSCSI Software Target 3.3 http://www.microsoft.com/ja-jp/download/details.aspx?id=19867 iSCSIターゲットに対してマルチパス(複数経路)を構成するときは、 下記の構成を取ることが一般的ではないかと思います。 ターゲットへの接続経路の1系と2系は別のIPサブネットにする 同一サブネットに2つずつ(iSCSIイニシエータ側2つ/ターゲット側2つ)IPを用意しても マルチパスになりますが、
近年、ソフトウェア開発を取り巻く環境が急激に変化してきています。ネットワークの整備や、コミュニケーションツールの進化に伴い、リモートワークやインターネット上での協業も盛んに行われるようになってきました。チームメンバー全員の住んでいる国が違う、といったこともあるかもしれません。 しかし物理的に離れた環境で働くと、今まで対面で行っていたコミュニケーションを別の手段で代替しなければなりません。SkypeやGoogleハングアウトなどのビデオ通話、HipChatやSlackなどのチャットアプリを利用することで仕事上必要なコミュニケーションは取れるようになりますが、ソフトウェア開発に関わる状況確認は別のツールを使う必要があります。 特にオペレーションは、いつ、誰が、どのような対応をしたか把握していたいですよね。 このような課題を解決する一つのスタイルとして、「ChatOps」があります。ChatOp
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く