タグ

ブックマーク / int128.hatenablog.com (5)

  • GitとJenkinsを使ってChefを運用する - GeekFactory

    Chefはリポジトリをバージョン管理する仕組みを持っていますが、チームでの協調作業を考えるとバージョン管理システムを使う方が運用しやすいと考えます。稿では、GitとJenkinsを使ってChefを運用するための1つのパターンを考えます。 以下があることを前提とします。 Chef Server Chef Client Gitリポジトリ Jenkins 基的な考え方 CookbookをGitリポジトリで管理します。開発者がgit pushすると同時にChef ServerのCookbookが更新されるようにします。これにより、GitリポジトリとChef Serverが同期されるようになります。 また、後続ジョブとして各サーバでChef Clientが実行されるようにします。ビルドパイプラインを組むことで、Staging EnvironmentにおけるChef Client、Producti

    GitとJenkinsを使ってChefを運用する - GeekFactory
  • nginxでLDAP認証を使う - GeekFactory

    Webアプリや共有フォルダなどの認証を必要とする場面が増えてくると、ユーザ管理のコストが無視できなくなります。Active DirectoryやLDAPでIDを統合すると、運用者はユーザ管理が楽になり、利用者はシングルサインオンで快適になります。たとえ自分しか使わない環境であっても、一括でパスワード変更できたり、簡単に認証を設定できるメリットは大きいでしょう。多くのアプリがLDAP認証に対応しています。 この記事ではnginxLDAP認証を使う方法を説明します。.htpasswdによる認証とは異なり、IDとパスワードはWebサーバでは管理しません。LDAPサーバのリポジトリで管理します。 今回は以下のミドルウェアを使いました。 Amazon Linux 2011.9 OpenLDAP 2.4.23 nginx 1.0.12 nginx-auth-ldap LDAPを準備する OpenLD

    nginxでLDAP認証を使う - GeekFactory
  • サーバとL2スイッチの接続を冗長化する設計の基本 - GeekFactory

    インフラを設計する上で冗長化による信頼性向上は避けて通れない道です。サーバとL2スイッチの接続を冗長化する設計については意外と情報が少ないのでまとめてみました。変なこと書いてたらご指摘ください。 インフラ設計の基は単一障害点(SPOF)を取り除くことです。構成要素のうち1つが故障してもサービスを維持できるように設計します。構成要素は以下のものが挙げられます: CPU マザーボード メモリ ローカルディスク 電源 FC-HBA NIC LANケーブル L2スイッチ ・・・ ただし、これらすべての故障に備えようとすると費用対効果が割に合わないので、ローカルディスクから下を冗長化する構成が一般的と思います。絶対に止まってはいけないサービスは別ですけどね。 冗長化の種類 サーバを冗長化するにはクラスタを組みます。クラスタはActive-ActiveとActive-Standby(HA)の二種類に

    サーバとL2スイッチの接続を冗長化する設計の基本 - GeekFactory
  • 公開SSHサーバの安全性を高める5つの設計 - GeekFactory

    出先からサーバをメンテナンスするには、SSHサーバをインターネットに公開する必要があります。SSHはデフォルトではIDとパスワードだけでログインできてしまうため、狙われやすい侵入経路の一つです。 ここではSSHサーバの安全性を高める設計を挙げてみます。 公開するポートを22番から変更する。 他サーバから独立したネットワーク(DMZ)にSSHサーバを配置する。 SSHサーバの表裏にファイアウォールを設置し、裏側を通って他サーバにログインする。 ログインシェルをchroot-jailで実行し、可能なことを制限する。 認証ログを監視する。 定期的にセキュリティアップデートを適用すること、推測されにくいIDやパスワードを使うことは言うまでもありません。地道な運用作業は重要です。 VMにおける実現方式 自宅サーバのようにスペースや静音性に制約がある環境では、独立したサーバを設置するのは困難です。また

    公開SSHサーバの安全性を高める5つの設計 - GeekFactory
  • OpenIDを個人のWebサイトで活用する - GeekFactory

    個人のWebサイトでOpenIDを活用する方法を考えてみます。 IDとパスワードによる認証では、サービス提供者と利用者の間で秘密情報(パスワード)を共有しておく必要があります。共用パスワードを使ったり、利用者に初期パスワードを発行したりしていると思います。前者は人性が確認できない問題があり、後者は利用者の手間が大きい問題があります。 必ずしもサービス提供者が秘密情報を保持しておく必要はなく、秘密情報による人識別は他者に委譲できます。認証をIdPに委譲することで、サービス提供者はIDのみ知っていればよく、認可のみ実装すればよいことになります。 例:mixiにいる友達の間でWikiを共有する デザインや拡張性の問題で、自前でWikiを立てている人も多いと思います。例えばPukiwikiではpukiwiki.ini.phpにIDとパスワード(のハッシュ)を書く必要がありますが、OpenIDで

    OpenIDを個人のWebサイトで活用する - GeekFactory
  • 1