Hrix.carrier

投稿日 編集日

ここ数日、心臓の調子が悪いと感ずる。

投稿日 編集日

中畑清のファミリー・ヒストリーというテレビ番組をNHKでみた。
実家が貧乏で苦労した、乳牛の畜産農家だったのがおかずがないので、麦飯に牛乳かけて食べた、と語られていたが今の時代だと却って麦飯牛乳おいしそうに感じた
本人身長185cmもあるし、少なくとも栄養的には貧しくはなかったんじゃないかと思えた。

投稿日 編集日

このサイトの作り方

手軽にブログサイトのようなものを作りたく、githubの機能と静的ページ出力のhexoというフリーソフトで作りました。

  1. linux環境を作る（私はwindows7+vagrant+virtualboxで作りました)
  2. node.js(nvm)をインストールする
  3. hexoをインストールしてブログを作る
    • デザインをいじるためtheme(casper)を追加でインストールしました
  4. github pages機能を使うためhrix.github.ioというリポジトリを作る
  5. 上記リポジトリをlinux環境にclone
  6. hexoでできたファイルを全部cloneしたディレクトリに移し、リポジトリに追加
  7. _config.ymlを編集して調整しhexoを立ち上げる。(hexo server)
  8. ローカル環境でmdファイルをプレビューしながら編集（utf8で保存すること）
  9. 静的ページ(html)発行（hexo generate）
    • theme以下のcssを直した場合、一度全部消して（hexo clean）からgenerateしないとcssの変更は反映されないようです
  10. ソースのmdも含めてgithubにpush
    • https://github.com/hrix/hrix.github.io　がリポジトリになります。
    • hexoで静的ページだけをデプロイする仕組みもあるようですが、全部一つのリポジトリに入れることにしました。
      そのため、http://hrix.github.io/public/　がトップページになりますが、今回は気にしません。

感想

  • hexo便利
    • シンプルで動作が軽快なので楽しい
    • 設定ファイル（_config.yml）分かりやすい
  • github, mdファイルを使えることは必要
  • でも全部で無料できる。

その後

  • hexo3に対応
    • いったん全部記事作り直し
    • hexo-serverが別モジュールになった

投稿日 編集日

インターネット前

  • 1991年、音楽を作りたくてMacintosh購入。※初めての自分のパソコン
  • 1993年、ダイヤルQ2のシステム、ハードメンテ、オペレーション担当※PCのハードウエア学ぶ
  • 1995年、転職してVBのプログラム習得（２６歳、遅咲きですね）
  • 1998年、横浜の外資系CD通販のインターネットベンチャーからWeb業界に。いろいろ身に付いた。

Web時代

  • 1999年　神保町のインターネット会社で働き始める。
  • 2000年　学校向けASP開発(IIS, VB, SQLServer)
  • 2001年　のべ40大学導入！（2～5百万/月が５年以上！　営業の人のおかげ）
  • 2005年　退社
  • 2006～2008年　辛酸
    プログラムはあまり書かず（ネットワーク、サーバ管理、外注管理など）
  • 2008年　横浜から京都に引っ越し株式会社イー・エージェンシー入社。
  • 2009年　グループ会社の株式会社コンフォート・マーケティングに転籍
  • 2011年　株式会社イー・エージェンシーに転籍
    いろいろ勉強し直し、インフラエンジニア的な仕事に落ち着く

投稿日 編集日

自社プロダクト部の平井です。インフラ担当の一人です

インフラ担当って何をやっているのか？　少し分かりにくいのと、新しいことも取り入れながらやっていっていますので、仕事のご紹介したいと思います。

インフラエンジニアとは？

仕事として分けると大きく二つ、

  • サーバ構築
  • 日々の運用
    があります。
    前者は、インフラ設計、新しいサーバの立ち上げ、後者は、稼働中のサーバの監視、メンテナンス、トラブル対応、セキュリティ対策になります

今までこれらを手を動かして作業している部分が大きかったのですが、少しづつプログラム開発のようなコード化を進めていっているのでそちらを紹介します。

インフラのコード化ついて

以前、もう一人のインフラ担当が以下のような事例紹介を発表しました。

インフラ構築の自動化・量産化。e-Agencyのクラウドプロダクト部における Chef 導入事例を紹介
http://www.e-agency.co.jp/column/20140724.html

どれくらい大変なのか、その後どのように実践していったか、途中経過をお知らせします。

コード化の実践状況

以前の手作業と、コード化作業との比較ですが、以下のような特徴があり、インフラチームのエンジニアと情報共有がグンと進んで来ているのを実感できています。

  • 一度作った手順（レシピ）をリポジトリ（Githubなど）に置いて再利用ができる
  • どういう設定をしたか、いちいちサーバに入って確認しなくてよい（記憶に頼らなくてよい、メモの漏れも気にしなくて良い）といったメリットがあります。反面
  • レシピを書かないといけないので、最初は手で立ち上げるよりかは時間がかかる。

サーバ構築

新規でサーバを立ち上げる場合は原則、Chefで構築したものを投入するようにしています。
具体的には主にミドルウエア（Apache, Nginx, MySQL, Ruby, PHPなど）のインストールを今まで手作業でやっていたものをChefに置き換えています。

日々の運用

監視部分はNagios, Muninといったツールをカスタマイズして使っています。これらの設定ファイルはGithubで履歴管理をしています。
不定期のメンテナンスでログインする場合、サーバ台数が100台以上になってきて、こちらも手作業が辛くなってきているので、ansibleというツールを使っています。こちらも手順がコード化できます。
ansibleはchefとかぶるツールではあるのですが、Chefと違って手作業でインストールしたサーバに対しても簡単に適用できるということで、全てのサーバに対してやる作業に使っています。

Chefはきちんと整理して共有しやすくしてくれるツール。ansibleは運用を楽にしてくれるツールという使い分けになります。
しかし手でも同じことをやった経験があった方が、これらのツールになじみやすいと思います。

その他

  • SSL証明書の運用
    暗号化と身元確認をまとめてやってしまっているもの。事務手続きもあるしちょっと特殊な扱いになります。
  • その他
    トラブル対応やセキュリティ対策、インフラのテストもこれから改善していきたい課題になります。

サーバ構築コード化の課題

　設計に関して、我々はサーバベンダーの選定はどこかに固定はしていません。固定するとコード化はしやすくなりますが、それよりもサーバの種類によってベンダーも使い分け（コーヒーで言うとブレンド）のメリットを感じています。運用中のアプリの造りも疎結合だったりします。

  • オンプレミス（ラック借り）→最近はなくなりつつあります
  • 専用サーバ→クリティカルなもの、特殊な設定が必要なもの
  • VPS→テスト、監視用サーバなどクリティカルではないもの（安く済ませられるというメリット）
  • クラウド→これがメインになりつつあります
  • その他Webサービス（AWSのS3など）
    • DNSのレコード管理のコード化はAWSのRoute53を使えば、比較的簡単にできるのでそろそろやりたいところです。

といった感じでサーバの役割に応じて使い分けています。
なので、サーバの起動、OSインストール、ネットワークの設定をどうしていくかは、これから考えていかなければいけない課題です。

まとめ

　インフラ業務をプログラムと同じように全てコード化できると、開発と運用がより近づき、今までよりレベルの上がった世界にいけると感じています。
インフラチームも開発と一緒になって生産性を上げて何かを成し遂げていきましょう。

投稿日 編集日

SSLの深刻な脆弱性「FREAK」というのが話題になっています。
対策できていない場合、SSL通信が乗っ取られる危険があるので関係するWebサーバはチェックしておくとよいです。

これのチェック方法・対応ですが
CentOS6/Apacheの組み合わせであれば、以下のような対策が考えられます。

①適当なサーバから問題の暗号形式になっていないかチェック

1
$ openssl s_client -connect [対象のドメイン]:443 -cipher EXPORT

※結果

handshake failureとでて15行ぐらいで終わったら問題なし、
そうではなく、たくさん暗号が出て
Server Temp Key: RSA, 512 bits
など出たら、問題ありです。
※Apacheの場合ssl.conf（CentOS6）ではデフォルト
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
となってあってこれが効いていれば問題なしですが、
設定の仕方によって無効になってしまっている場合もあるので
SSLCipherSuiteを有効になるよう調整するなど確認が必要です。

②（CentOS6/7）2015/1/21にopensslのモジュールアップデートが出ているのでアップデートする

1
# yum update openssl
0%